Unityで作業していると、”Hold on…(busy for hh:mm:ss)”のプログレスバーが出て、放っておくといつまでも消えなくなる症状に悩まされていた。ツールバーのメニューなどをクリックすると消えるので深刻ではないが、スクリプトを少し編集するたびに出るので作業効率を悪化させてしまう。
ゲームプロジェクトのファイルパスに全角文字を使わないように直したところ症状が出なくなった。
Unityで作業していると、”Hold on…(busy for hh:mm:ss)”のプログレスバーが出て、放っておくといつまでも消えなくなる症状に悩まされていた。ツールバーのメニューなどをクリックすると消えるので深刻ではないが、スクリプトを少し編集するたびに出るので作業効率を悪化させてしまう。
ゲームプロジェクトのファイルパスに全角文字を使わないように直したところ症状が出なくなった。
ゲームを作るというのはゲームという分野で考えれば「作る側」の立場を意味する。
しかし、ゲームという分野に限定せずにソフトウェアという分野で考えるとUnityやUnreal Engine、その他のツールをただ使えるだけではなくて作れるようでなければ「作る側」に立っているとは言えない。
そんなことを考え始めてたまにはUnityを離れて何か学習しようと思ったが、理解していない事があまりに多すぎる気がしてめまいがしてきた。
例えばVisual Studioなどを立ち上げて、新しいプロジェクト→Windowsアプリの作成とクリックしていくと、とりあえず真っ白なウィンドウが表示されるだけのコード一式が勝手に作られるのだが、これも結局与えられたツールを使っているだけだ。本当の意味での「作る側」はこのVisual Studioのようなツールそのものを作れる人を指すはず。プロジェクトの作成サンプルは他にも様々なパターンが用意されているが、自分はそれらの使い道を全て理解する事すらできていない。
だからといって作る側という考えを極端に突き詰めると、パソコンやCPUを自分でゼロから作るという話になりかねないが、それは自分のやりたいこととは違う。プログラミング言語自体を自分で新たに作るというのも違う。
作りたいのはコンテンツなのかツールなのかを考えて学ぶ事を線引きしないと時間が足りないように思う。世間の優秀な人が優れたツールや部品を作ってくれているなら、それを上手く使いこなせば良いのではないか。車輪の再発明も学習のためなら無駄ではないが、限られた時間で何を学ぶかという優先順位は意識しておくべきでは。
そんな仰々しい話をする以前に、コンテンツすらまともに完成させたことが無いのが今の自分なわけだが…。昨今、ゲームを作って公開するためのツールや環境は整っているので、やるかやらないかという意思の問題のはず。
各種ツールの使い方を完璧に理解するのも楽ではない。ツールの使い方を覚えることが目的にならないように、必要な機能を見極める事も意識するべきかもしれない。ツールはあくまで手段である。
前回に続き、スコアを加算する機能を追加したが他には特筆するべき進捗が無い。
そもそも何を競うゲームなのかも決まっていない。手を動かすよりアイディアを出すことにも時間をかけるべきかもしれない。
少しずつ機能を追加中。
今後追加したいものは下記。
背景やキャラクターのモデルは凝ったものを作ると途端に作業量が増すと思われる。そもそも技術やセンスが無いのが厳しいところ。
前回作成した敵機を画面下方向に移動するようした。Rigidbodyを取り付け、空気抵抗をゼロにし、画面下方向へのベロシティを設定しているのみ。これをプレハブ化して画面上部のランダムな位置から生成するようにした。
この程度の内容なら集中してやれば10分足らずできたのではないかという気もする。週末のまとまった時間を当てにせずに、毎日必ずソースコードをいじるという習慣を付けるべきなのかもしれない。
敵の射撃や生成の間隔、移動速度などで変わるが今の設定で自分が操作すると蜂の巣にされてしまう事が分かった。
自機の位置を補足しながら弾を撃ってくる敵を作った。自機の攻撃で破壊できる。
Edit→ProjectSettings→Physics→LayerCollisionMatrixから衝突判定を行うレイヤーを設定できる。自機も敵も同じだが衝突判定を考えないと自分で撃った弾が自分に当たってしまう。
次にやるのはエフェクトや効果音を作るとか、敵が動き回るようにするとかだろうか。
というか、もっと作業の効率を上げなければいけない気がする。
最近だれてしまい、ちょっとブランクがあったがUnityでの作業を再開。予約しておいたダイイングライト2はまだ一度も起動していない。ちょっとした気分転換のつもりでも起動しようものなら、当分他の事が手につかなくなる気がする。
何とか開発負荷の少ないもので一つの作品を完成させるために仕切り直すことにする。一人称視点とか立体的なマップとかにするとハードルが高くなるので、俯瞰視点のゲームを作ろうとしている。とりあえず自機の移動と方向転換を実装して、プレハブを基に弾を撃つ機能を実装。自機の方向に関係なくワールド座標のZ軸方向に弾が飛んでいたが、transofm.forwardとするべきところをVector3.fowardとしていたのが原因だった。初歩的な間違い。
Unityではキーボード、マウス、ゲームパッド諸々の入力設定は、
プロジェクト名\ProjectSettings
のフォルダにあるInputManager.assetに記録される。プロジェクトを新規作成するごとに設定するのが面倒な場合は過去のファイルと差し替えることで設定を引き継ぐことができる。
加えてスクリプトもテンプレート化するか、または汎用性の高い作りにすると更に作業を効率化できるはず。自分の場合、毎回プロジェクトを新しく作成するごとに似たようなスクリプトを一から作り直しているような気がする。
ゲームを作ることを考えると、ジャンルによって難易度や難しさの性格が異なる。
テキストアドベンチャーは恐らくコーディングが一番簡単と思われるが、その代わり文章、画像、音楽などの素材が作品の良し悪しを大きく決めるのでコーディングとは異なる労力と技術が必要と思われる。
横スクロールアクションとかプラットフォームゲームと呼ばれるタイプのものはアクションの挙動や当たり判定をリアルタイムで処理するのでアドベンチャーより難しい。UnityではRigidbodyとかColliderとかの既存の機能である程度の事はできるだろうけど、理解が浅いと応用が効かないだろう。大抵の場合、キャラが飛んだり走ったりするなどのアニメーションも作る必要がある。アニメーションと当たり判定に大きなずれが無いように気を使う必要もある。
昔ながらのシューティングゲームは自機も敵機も動きが直線や円などの単調なものでも違和感が無い。戦闘機などが飛ぶ姿をモチーフにするとアニメーションはほとんどの場合は不要。
シューティングはシューティングでもTPSやFPSとなると、キャラクターが入り組んだ通路を歩き回ったり、プレイヤーを見つけると攻撃したり、見失うと探したりと動きが複雑になる。大まかなアルゴリズムを考えるだけでも複雑そうだが、これを立体空間で行うとなるとどうやって動いているのか自分には想像がつかない。目的地に直線移動でたどり着けない場面は多々あると思われるが、移動経路をどうやって決めているのか。空間表現が3Dの場合はキャラクターモデルだけでも複雑だが、走ったり撃ったりする動作も3Dでアニメーションさせるのでこれも複雑になる。ただ、少なくとも人間よりは機械の方が動きは単調で、ポリゴン数が少なく角張った形状でも違和感が無いと思われる。四角や丸や立方体などの単純な形状でもゲームは作れるが、最低限の雰囲気作りは必要なのでモチーフ選びも難易度に関係してくる。
その他に効果音やBGMを用意する問題もある。Unityであればアセットストアで買うというのも一つの手だろうけど、なるべくオリジナリティが欲しいところ。
何かゲームっぽいものを作りたいとぼんやり考えつつ、漫然と開発用ツールなどの書籍を読んだりして学習してきたが、そもそも何を作るかが決まっていないと気付いた。何を作るか具体的な事を決めないまま、何かのゲームで見たような要素の上辺を真似しても、完成系が明確でないと頓挫するだけだ。何を作るかが決まらないと作りようが無い。本やネットからノウハウを学ぶ事は出来ても、自分が何を作りたいか、何を作るべきか、何を作れるかは自分で考えるしかない。作りたいものを作るのに技術や知識が必要なら学習する意味があるが、学習事態を目的にしても作品はできない。作りたいものの企画なり仕様なりを具体的に決める必要がある気がする。開発環境とかツールとか言語とかは手段であって、何を作るかが目標になる。
しかし未だににこんなことを書いているといつまでスタート地点でもたついているのかとも思う。明日から本気出すって言っているのと変わらない気もする。