一週間ちょいでついなちゃんゲーを作ったよ感想記事

ついなちゃんのボイスロイド発売一周年を祝うボイロついな誕に向けてTuina*12というゲームを制作、公開しました。

 

こういう見た目のゲームです。

制作したゲームのスクリーンショット。シンプルな見た目が数少ないウリ

 

この記事はそのゲームの制作裏話と、自分としての反省点を見返すための備忘録となります。

スポンサーリンク

制作期間と制作理由

一週間と二日程度で作りました。

 

たしか、ボイロついな誕の話を聞いたのが、一つ前のゲーム制作記事にも書いたVOICEゲームジャム6が終了した少し後。

 

「もうそろそろボイロついな誕やで!!」とついなちゃん公式が言っているのを見て、「ふーん、そうなのか(他人事)」と思っていたのですが。

 

 

考えてみれば、一週間は小さなゲームを作るには十分な期間だし、ついなちゃんには上記ツイートで自作を宣伝してもらった恩義がある。

なにより、その時「何かゲームを作りたいな」と思っていた。

 

主な制作理由はそれくらいです。

 

それら一つ一つでは行動へ繋げるには弱い事柄でも、複数あれば自分を動かす力になりうるもの。

自分をゲーム制作へと向かわせる大義名分として、これらの要因を持ち出した形になりますね。

作品コンセプト

ゲームを作ると決めたのならば、次に考えるべきは「どんなゲームを作るのか」。

 

残念な事実ですが、僕はぱっとオリジナリティあふれて作りやすそうなゲームアイデアが浮かぶ人ではないので、過去に遊んだゲームからオマージュ元を探すことにしました。

 

それで思いついたオマージュ元と、使おうと考えている素材やらを合わせて錬成したのがこのゲーム。

 

Tuina*12 タイトル画面のスクリーンショット

 

知ってる人はこのタイトルだけでピンとくるかもしれませんが、今作は名作パズルフラッシュゲームの一つ、Cursor*10のオマージュとなっています。

ゲームシステムも同作を参考に、「過去の自分と協力して先に進む」パズルにまとめました。

 

Flashがまだ元気だった頃、Cursor*10はとても楽しく遊ばせてもらった経験があり、それを自分でも一度作ってみたかったんですよね。

 

前作に引き続き、空どうふさんの可愛い立ち絵を使うことは当初から決まっていたので、その立ち絵を活かす方向で翻案。

十字キーでキャラを操作するオーソドックスなシステムに、プレイヤーゴーストと協力するシステムをかけ合わせた見た目になりました。

 

出来たものを見てみると、Cursor*10そのものというより、それを原作としてフロムソフトウェアが出した己の信ずる道を征けに近くなったかもしれませんね。

 

当然ながら、己の信ずる道を征けのほうが圧倒的にクオリティが上なので、もし本作を遊んで「もっとこのシステムのゲームを遊びたい」と感じた人がいましたらそちらを遊んでみるのはいかがでしょうか。

反省点

前作で「二週間という期間は短い」と感じていたのだから、今作のほぼ一週間という期間はさらに短かった。

 

開発期間が短ければ、犠牲になる部分もまた多くなるというもの。

そんなこんながあって、個人的な反省点もいっぱいです。

 

  • 自前で移動処理を作るのはやっぱり大変
  • 操作性の良いゲームにするのも大変
  • 自分で書いたクソコードに自分の首を絞められる
  • 納期優先で恥ずかしいコードを書く経験
  • 公開時に間違えて前作のゲームデータをアップロードしてしまって死

自前移動処理の大変さ

今回も制作ツールとして使用したGodotには、RPGツクールなどのような「標準装備のグリッド移動システム」がありません。

そのため、グリッド移動のゲームを作りたいならば自作の必要性が生まれてきます。

 

今作は「過去の行動をゴースト化して再生する」システムがあるので、それを実現させる上ではグリッド移動のほうがやりやすかったのが一つ。

 

もう一つは漠然と「グリッド移動のゲーム作ってみたいなあ」程度の気持ちで、グリッド移動を採用した、のですが。

これは大きな反省点でした。

 

ゲームというのは元々作るべき部分が多いので、自作するべき処理はなるべく少なくするべきなんですよね。開発期間が限られているなら特に。

Godotに組み込まれているシステムをなるべく活かして、「楽」をできる構造を考えるべきでした。反省。

操作性の良いゲームにする大変さ

グリッド移動を自作したことによって生まれた問題が、操作性の悪さ。

具体的にはこのあたりが、制作者としても微妙だなあと感じている部分。

 

  • 移動直後にキューブを叩く処理が行われないタイミングがある
  • 上下左右の移動が重く、スムーズに動かせない
  • 特定のタイミングで「再度移動キーを押し直さないと移動を開始しない」ことがある

 

「微妙だと感じてるなら直しなさいよ」と思う人もいるかもしれません。

いやまあ、その通りではあるんですが。

 

前述の通りグリッド移動を自作しているので、操作性の悪さは僕が書いたクソコードに起因しているわけであり。

それを直すとなると、グリッド移動周りそのものを直したほうが早くなる。

 

すると、あらなんということでしょう。

クソ匠のせいで、一週間でゲームが完成する目処がさっぱり立たなくなってしまうではありませんか。

 

なので完全な修正は諦めました。

ゲーム制作ってほんとむずかしいですね(しんみり)

自分で書いたクソコードに自分の首を絞められる

クソコードといえばこういうバグがありました。

いや、過去形で書くべきではないかもしれません。

 

過去の行動を元にしたプレイヤーゴースト行動が、実際のプレイヤー行動とずれる」、というバグ。

ゲーム性がこわれるような重大バグが制作中に見つかっており、それが修正できたかできないか、未だ僕としてもわからないんですよね。

 

恐らく、「移動終了後の再移動入力検知処理」と「扉移動による移動処理」の競合を起因としたバグだと思うんですが。

自分で書いたクソコードとクソコードが絡み合っていて、期間内では抜本的改革が行えそうになかった。

 

「特定条件化では高頻度で発生する」から、
「特定条件化では低頻度で発生するかも? 簡易的なテストでは起きなくなった」程度まではなんとか発生頻度を抑えたのですが。

「もう絶対に起きない」とは口が裂けても言えません……。

 

短期間ゲーム開発は一に妥協、二に妥協、三四がなくて五に妥協。

どこまで妥協するか、どこまでこだわりを入れるかのバランスを取る戦いだと感じてなりません。

実績: 納期優先で恥ずかしいコードを書く

妥協の産物といえばこういうのもありました。

 

Godotではオブジェクト指向的な構造がなされていて、

基本的に「親要素から子要素を触るのはしやすくても、子要素から親要素を触るのは難しい」仕組みになっています。

 

なので、オブジェクト同士の配置をいかに整理し、いかに扱いやすい状態にするかが制作側の腕の見せ所。

 

他方で、今作の開発終盤にこういう出来事がありました。

  • Room5に配置したGoalPlateにプレイヤーが触れたらクリア処理を行う
  • クリア処理では親要素が持つ「クリア時の残り時間」を取得して、最終スコアを算出したい
  • RoomContainer -> Room5 -> GoalPlateという入れ子になっていて、RoomContainerまでいかないと「クリア時残り時間」が取れない

出来の悪いパズルかな?

 

こういうややこしい状態にならないようにすること。

また、もしなったとしても気持ちよく解きほぐせるアイデアを出せるのが良いプログラマといっても過言ではないでしょう。

 

僕はあまり良いプログラマとは呼べないので、

GoalPlateからのシグナルをRoom5で受けて、そこから更にRoomContainerへとシグナルを放つ」愚直なやり方で妥協しました……。

 

制作期間残り二日といったところで、とにかく時間がなくて、つい……。

 

「時間がない時間がない」と焦るばかりに怪しいコードを書いて、その怪しいコードでまた時間を奪われるような悪循環に陥る。

とても悲しい、悲しい経験をしました。

実績: 公開データを間違える

完成後にも、僕は時間がない焦りから失敗を繰り返してしまいます。

今作Tuina*12のゲームデータと間違えて、
前作mini_one_puzzleのゲームデータをアップロードしてしまったんですねえ!

 

ああ、思い出したら憂鬱になってきました。

絵に描いたようなヒューマンエラーを引き起こしてしまうとは、かなしいなあ……。

 

不幸中の幸いながら、ボイロ同人ゲーDiscordに所属してる人から「アップロードファイル間違えてますよー」と親切な言葉をいただくことができ、すぐに修正できました。多謝。

今作制作でのよかった所集め

探そうと思えば、さらに反省点を見つけることができそうですが。

 

悪い部分だけ見ていてもバランスが悪いので、

ここからは今回制作で(比較的)良かった部分、今後に繋がりそうな発見をした部分を書き残しておきましょう。

 

  • 過去のプレイヤー行動を再生する仕組み自体は上手くいった
  • 色数を抑えた省力的デザインの強み
  • Exo2フォントってかっこいいね(フォント素人並感)
  • パチモンロゴ程度ならさっと作れる事実の発見
  • Godot 3.2ではグリッド形式でのz-index調整が行いにくい
  • 今作で初めてAnimationTreeを導入してみたが、これが便利だった
  • Area2D.monitoringだとかArea2D.monitorableより、CollisionShape2D.disabledを切り替えたほうが処理が安定するっぽい?

過去プレイヤー行動の再生処理

前述した、過去行動再生異常バグもありましたが。

 

それを抜きにしてみると、この「プレイヤー行動の記録/再生」処理はそこそこいい感じに作れました。

  • ユーザー操作を保存しやすいenum形式に変換する
  • ユーザー入力に応じて、専用の領域へとユーザー操作を保存・格納する
  • 次の周回が始まる際、「保存された操作を忠実に行うオブジェクト」を生成、行動を開始させる

 

これらの処理はゲームコンセプトを立てたときからどう作るか考えていた内容。

それだけに、これらを上手く作れたことはよきよき。

 

惜しむらくは、「過去プレイヤーの移動ルートを塞ぐと棒立ちする」動きを利用したパズルを用意できなかったことですかね。

難易度が跳ね上がる上に、「十二人のプレイヤーで部屋を攻略していって、最後まで到達する」ゲーム性とちと相性が悪そうだったのでボツにしました。

 

いやらしい詰み状態に行き着いてしまうパズルはやはり、リトライ回数が限られているゲームより「いつでも何度でもやり直せる面クリア型のパズル」に向いているのではないかと思ったので……。

色数を抑えた省力的デザインの強み

制作したゲームのスクリーンショット。シンプルな見た目が数少ないウリ

上はこの記事冒頭でも張ったスクリーンショットですが、このゲームは全体として「シンプルな色合い」を念頭において画像を用意しました。

 

それは主に、こういった意図あってのものです。

  • 他の色が薄いとついなちゃんの立ち絵が映えるかな?
  • そもそも色彩センスに自信がないし、色を探すのも面倒くさい
  • 困ったらとりあえずオマージュ元の方向性を真似る

 

「カラフルな色を調和させる自信がないので色数を減らす」のは、世の色彩センス自信ないマンたちにとってのあるあるネタではないかと思うのですが。

僕もその例に漏れず、多くの色を使うのが怖くて仕方ありません。

 

なので、今作のタイル画像・オブジェクト画像を自作するにあたって、徹底的に色数を減らすことにしましたが。

「まあ違和感はないかな」くらいに思ってもらえてたらいいなあ……と夢想する次第であります。

Exo2フォントかっこいい

個人的に、フォント選びはデザイン鬼門の一つだと捉えています。

 

普段何気なく目にしているものだけれど、実際自分で何を使おうか選ぼうとしてみると、これがさーーっぱりわからない。

わからないのだとしても、わからないなりに自分の引き出しを漁って相性の良さそうなものを見繕うしか無いのがまたつらみ。

 

このゲームにおいては、主にこういった意図でフォントを決めました。

  • メインフォントはExo2-ExtraLightにする
  • 日本語フォントとして、Exo2と相性が良さそうなフォントを探す

 

その結果がこんな感じ。

Tuina*12 タイトル画面のスクリーンショット

日本語フォントにはMplus-2p-lightをあてがいました。

素人目に見て、Exo2-ExtraLightと字体・太さがかけ離れていないと判断したためです。

 

Exo2を知ったのは、かねてより親交のある穂積さん新サイトを制作した際に、穂積さんから「このフォントを使って欲しい」と指定されたことからでした。

クールでスタイリッシュな印象。それでいて、ライセンス的にもとても優しいフリーフォント。

 

タイトル画面を作ってる時にその存在を思い出して、

これはCursor*10オマージュのゲームへ使用するには良いのではないかとひらめいた採用しました。

 

この記事をお読みになっているあなたとしては、このフォント選択にどういう印象を持ちましたでしょうか?

違和感を覚えられていないのならば良いのですが。

 

このへんの勘所がなんともわからないので、デザイン関係は苦手やねんな……。

フィート: あなたはパチモンロゴ程度ならさっと作ることができる

このゲームは「ボイロついな誕」、すなわち「Voiceroid2 ついなちゃんの発売一周年」を祝うゲームとして制作したので、何かしらボイロ要素を入れたいと考えていました。

 

ゲーム性を変えずに要素を付け足すなら、「ゴールをついなちゃんパッケージにするのが良いかな」とはすぐ思いついたのですが。

 

無料配布するゲームだとしても、実際に販売されてるソフトのパッケージ画像をぶっこ抜いてきて配置するのはこう、さすがに、こう……。

リスク管理的にも制作モチベ的にもだめそうな感じだったので、代替となる「パチモン」を作ることにしました。

 

結局のところをいえば、ゲーム内の縮小表示ではつぶれてよく見えなくなってしまったのですが。

こういう画像を制作しましたよ、という供養も兼ねて掲示。

 

ボイスロイド通 Tuina-chanパッケージ画像。まごうことなきパロネタ。

 

目指したところは、「大筋は似せているが明らかにパチモンで、微妙なクオリティが笑いを誘う」パッケージ風画像。

 

幸いなことにうぃあの椅子さんのついなちゃん立ち絵にはVoiceroid2 ついなちゃんパッケージの「方相氏衣装/制服」のバリエーションがあったので、それを使用。

パチモンロゴの「ボイスロイド通」部分については、模倣元のロゴがシンプル系だったので、そう迷うことなく作れました。

 

「ついなちゃん」の元ロゴは凝っててパチモン化が一筋縄には行きそうになかったので、きりたんイタコさんのパッケージ画像を参考に、キャラの色合いを一部使ってのパチモン化を試みました。

 

パチモンロゴに使ったフォントは、たしかこれらだったはず(曖昧な記憶)

  • Mgen+ 1m Normal
  • Mgen+ 2p Normal
  • Jost* Medium

AHSロゴの代わりに赤色染色したついなちゃんマークを置いて、背景の紅葉柄再現はめんどくさかったので単色塗りにして完成!

 

かっちょいいロゴは難しくとも、微妙クオリティのパチモンロゴ程度ならさっと作れるという経験ができて、個人的には満足しています。

Godot 3.2でのz-index調整についての制限

このゲームを作っている最中に知りましたが、2020年11月現在のGodotにおいて、z-indexの適用上限は-4096~4096なんですね。

 

以下は参考リンク。

 

これは今作のように小さなゲームなら十分な値ですが、もっと大規模なゲームだと少し心もとない数。

YSortを使ったり相対的なレイヤー分けを行ったり、他の解決手段を考えて作ったほうがよさそう。

 

この知識を(大失敗なく)得られたのも良かったことでした。

AnimationTreeって便利だね

逆に、前作を作っている時にも知ってはいたけれど、今回初めて導入したのがAnimationTreeです。

 

ざっくり説明すると「攻撃アニメーションが終了した際、自動で待機アニメーションに戻る」用途のために使用しました。

これAnimationTreeなしだと、スクリプト側から逐次アニメーション表示を切り替える必要があって、アニメーションが増えるごとにややこしさが爆発しちゃうんですよね。

 

それがすっきり一つにまとめられて、「アニメーションAからB、またBからCへと変化したあと、待機アニメーションに戻る」なんてことも楽に実装できる。

実に使いやすい機能でございました。

当たり判定切り替え

Godotでの「当たり判定を一時的に無くして、また復帰させる」処理は幾つかの方法があるのですが。

 

今回は実験としてArea2D.monitoringArea2D.monitorableを使う方法を取りました。

それが災いしてか、「特定条件化で当たり判定が抜ける」バグが発生したりして。このやり方はあまり良くないことを学べました。

 

残念ながら試みは失敗に終わりましたが、実験という意味では成功です。

使ったことのない機能をお試しで取り込む機会として、短期間でのゲーム制作はうってつけ。

 

次に作るゲームではCollisionLayer機能を試したい所ですね……。

さいごに

ゲーム制作は辛くて苦しい場面もちょこちょこありますが、総合的にみるとなんだかんだで楽しいものですね。

僕がこれまでやってきたことの中でも、存外「向いてる」事柄だったりするのかもしれません。

 

これからも作ったり作らなかったり、一途に追いかけたり他のものに浮気したりしながら、ゲーム制作くんとは適度な関係を続けていきたいものですね。

といったあたりで、この備忘録記事はおわりとなります。

 

ごきげんよう。