前回の上遠野さんに引き続き、インターンシップ接触編の様子と、
その中で感じたことをお伝えしていきます。
同じプログラマーを目指す方だけではなく、それ以外の志望の方にも
参考になるブログを目指して頑張りたいと思いますので、よろしくお願いいたします。
前回のブログにて紹介された仕様書も完成し、2週目の末からいよいよ開発に入りました。
今回私たちが開発するのは、「増殖」と「連鎖」といったキャラクターの能力をうまく活用して、
様々なギミックをクリアしていく2Dパズルアクションゲームです。
キャラクターやマップなどのグラフィックは上遠野さんが、プログラムに関しては私が、
それ以外の部分に関しては2人で協力して開発を進めています。
開発をスタートするに当たって、まずはタスクの割り出しと、
全体スケジュールの作成を行いました。
タスクの割り出しとは…
ゲームを作るために必要な作業(タスク)と、
その作業を終わらせるのに必要な時間を全てリストアップすることです。
ここで漏れがあると、そもそも正しいスケジュールを作成することができません。
しっかりと取り組む必要があります。
次にスケジュール作成です。
割り出した全てのタスクについて、どういった順番で、いつどれをやるか、を決めていきます。
どの機能をいつ作るか、画像はどれを先に作って欲しいか、
これはこの後でないとできないから先にこちらを済ませる必要がある、
といったように多くのことを考えながら、スケジュールを立てる必要があります。
私も上遠野さんもスケジュールを立ててゲーム開発に取り組むのは初めてであり、
どの作業にどれ位の時間がかかるのか、優先度はどのように付ければ良いのかなど、
想像できないことはたくさんありました。
そこで、過去にインターンシップに参加されていた方や社員の方に話を伺い、
作業にかかる時間の目安や実際の開発における作業の順序例を教えていただき、
それらを参考にして無事にスケジュールを立てることができました。
実際にスケジュールを立てて開発を進めていくと、
次に行う作業がわかっていることや、現在の状況が
進んでいるのか、または遅れているのか把握しやすく、
開発をスムーズに進められています。
複数人数によるゲーム制作においては、コミュニケーションが重要となります。
それぞれのイメージや優先順位が違ったまま開発を進めてしまうと、
作成している途中や作成後に修正が必要になってしまい、
その分開発が遅れてしまいます。
実際に今回の開発を開始したとき、画像をどのような形で
やり取りするのか、という点でコミュニケーションが足りませんでした。
その結果、一度作成した画像を別の形で作り直してもらう、
という作業が発生し、その後予定していた作業が遅れてしまいました。
そのため、予め決められる部分は話し合って決めておき、
また開発の途中で新たに発生した疑問点なども出来るだけ
早めに相談するようにしています。
▲さんかくアニメーションのイメージや優先順位を話し合っています。
今回の開発で最初に取り掛かったのは、
プレイヤーが操作するキャラクターの動作です。
今私が一番苦戦しているのは、キャラクターと、地面や壁といった
地形がぶつかった場合の当たり判定、及びぶつかった場合の処理です。
当たり判定に関しては発動編2期生の杉川さんのブログに
詳しく書いてありますので割愛させていただき、
今回はぶつかった場合の処理の重要性についてお話しします。
たとえばキャラクターが壁にぶつかった場合、次のような動作が考えられます。
・作用反作用の法則で、壁と反対方向に弾かれる
・壁にくっついた状態で壁を押し続ける
これらは一例であり、他にも色々な動作が考えられますが、
キャラクターやゲームのシステムなどを考慮して、一番合っていると
思ったものを選択していきます。
当然アニメーションを作るときにも考える必要がある部分ですので、
2人でどのようにするか予め話し合った上で、
ある程度形になったところで確認を行うようにしています。
これは上で述べたように、それぞれのイメージを共有することで
イメージのズレをなくすこと、また実際に動いているものを見ることで
おかしな部分を見つけること、の2つを主な目的としています。
サイバーコネクトツーのインターンシップでは、今回作成した
プログラムをプロのクリエイターの方々に実際に確認していただき、
様々な意見をいただくことが出来ます。
今回のチェックでは主に以下の2つの指摘をいただきました。
・「なぜそのようなプログラムを書いたのか」
「ただ動くから」、というだけで書くのではなく、
「ここはこういう処理だから、この方法が良い」というように
しっかり理由を考えることが大切とのことです。
・「他の人にとって分かりやすいプログラムを書く」
プログラムにコメント(説明)が無い、名前を見ても動きが想像できない、
といった他の人が見てわかりにくいプログラムを書いてしまうと、
実際に仕事をするときに多くの問題が発生してしまいます。
この2点はどちらもゲームを作る上だけでなく、プログラマーとして
プログラミングを行う上で重要な基礎の部分であり、
出来る限り早く身につけたいと思います。
まだ始まったばかりという印象が強いインターンシップですが、
すでに4週目に入り、半分が過ぎようとしています。
そろそろα版の提出日も近づいて来ていますので、
インターンシップ生2人で力を合わせ、サイバーコネクトツーの
クリエイターの方々から様々な意見をいただき、
より良いゲームを作り上げたいと思います。
これから2ヶ月間、インターンシップで学んだことを皆さんにお伝えしますので、
是非見守っていただければと思います。
このブログが、インターンシップに参加しようとしている方、
またはお悩みの方にとって、情報収集の手がかりになれば幸いです。
まず初めに、サイバーコネクトツーが開催している
"インターンシップ〜接触編〜"とは一体どんなものなのか、
説明させていただきます。
インターンシップ〜接触編〜とは、
サイバーコネクトツーの現役クリエイターによる指導の下、
出されたお題を元に2ヶ月間で一本のゲームを作り上げ、、
2Dゲーム相当のゲーム制作をできる能力を身に付けることを目的とした
実践的な体験の出来るインターンシップです。
接触編は、サイバーコネクトツーが開催しているインターンシップの中でも、
応募条件にゲームの制作経験は求められないので、サイバーコネクトツーで
開催されている他のインターンシップと比較すると参加しやすい条件になっています。
(ただし、ゲーム制作の経験の有無は選考の判断基準になります)
しかし、その代わりに"絶対にゲームクリエイターになる!”
という強い意志を持っている方"という項目が必須条件です。
ここに大きな自信のある方は、次回是非応募してみては如何でしょうか。
出社一日目でまず体験したのは、毎週月曜に行われている、
サイバーコネクトツー福岡本社と東京スタジオの全スタッフが参加する朝礼です。
その場でインターンシップ生としてご紹介いただき、
一人ずつ意気込みと挨拶をしました。
福岡本社に居る方だけでも優に100名を超えており、
ましてやあこがれているプロのクリエイターの方々を前にして、
お恥ずかしながら声が震えてしまいました。
しかし、皆さんの前で意気込んだことで、
自分で挙げた、2ヶ月間で可能な限り情報を吸収して、今の自分を10倍以上に成長させる。
という目標の言葉の重みがより一層増し、身が引き締まりました。
朝礼の後、これから2ヶ月間指導をして下さる担当の方々との顔合わせをし、
早速これから作るゲームのお題が発表されました。
私たち接触編3期生の制作するゲームのお題は...
「増殖」と「連鎖」です。
皆さんならこの言葉を聴いて何を思い浮かべますか?
人それぞれ出るアイディアは千差万別だと思います。
二人だけのチームという状況で、意見がまとまり易い利点もありますが、
反対にアイディアを見つめる視点が少ないことが心配されます。
そこで私たちは、色んな社員の人たちに意見を頂きに、開発室へ向かいました。
お話をするきっかけにもなりますので一石二鳥です!
やはりプロのクリエイター、私たちに見つけられなかった
増殖と連鎖に関する新鮮なアイディアが沢山挙げられ、
企画出しの刺激になりました。
そうやって色んな方向からアイディアを集め、長い試行錯誤を重ね、
最終的に、「増殖と連鎖という特技を持つキャラクターを使って迷路を進む」
パズルアクションゲームに決定しました。
企画の方向性が決まったら、続いてゲームの詳細を決めていきます。
しかしこれがまた難しいのです...。
つい要素を追加したくて、あれもできて、これもできると
ゲーム要素を挙げていくと、複雑極まりないゲームになってしまいます。
「プレイヤーが操作できることはシンプルで判りやすく!」
複雑すぎるゲームは、操作時にプレイヤーが混乱してしまい、
楽しさを感じることができるまでに時間がかかってしまいます。
「ゲームデザインはプレイヤーが気持ちよく遊んでもらえる環境を作ることが大切だ」
というアドバイスをいただきました。
この判りやすさについては、後の仕様書を書く時にも大きく関係しています。
仕様書とは、ゲームの内容やシステムを事細かく説明したものです。
最初に提出した仕様書には、文による説明を詰め込みすぎていて、
「プレイヤーが何ができて、キャラクターがどのような行動をするのかイメージがつかない。」
と指摘を受けました。
イメージがつきやすいように説明と共に絵も入れ、
さらにレイアウトも見直してもらい、このように改善されました。
仕様書は、初めて見る人にもゲーム画面が想像できるものでなくてはなりません。
たとえゲームのアイディアが面白くても、その良さを伝えられる
プレゼンテーション能力がなければ、そもそもそのアイディアが伝わりません。
ゲーム制作には必要不可欠な能力なのだと学びました。
福岡に来てから、新しい知識を学ばない日は一日も無く、
初日まっさらだった私のノートが、すでに埋まりつつあります。
プロの方から一対一に近い状態で学べる状況なんて、
普通には考えられない状況です。
それを念頭に置きながら、折角得たチャンスをフルに活用し、
ここで得られるものは全て吸収する意気込みで毎日を過ごそうと思います。
それでは、最後まで読んでくださってありがとうございました。
次回はプログラマー志望の池谷さんが担当です。
お楽しみに!
サイバーコネクトツーで人事を担当しております中松と申します。
11月25日(月)より、『インターンシップ〜接触編〜』第3期生
2名が実習を開始しています!
今回のインターンシップ『接触編』は、11/25〜1/24の2ヶ月という期間で、
サイバーコネクトツーの現役のクリエイターによる指導のもと、ゲーム制作のための
実践的なスキルを身につけてもらうことを目的としたインターンシップです。
本ブログでは、そのインターンシップの内容と、インターンシップ生たちが、
ゲームクリエイターに求められる能力を、実践を通じ身に付けていく
成長の過程を、皆様にお伝えできればと思います。
それでは、インターンシップ生たちのご紹介です。
| 名前 | 上遠野 莉奈 |
|---|---|
| 志望職種 | アーティスト |
| 学校等 | 東北芸術工科大学 |
| 意気込み | インターンシップの2ヶ月間で可能な限り情報を吸収して、今の自分の10倍以上に成長し、キャラクターアニメーターとしてサイバーコネクトツーに合格するために頑張ります! |
| 名前 | 池谷 公紀 |
|---|---|
| 志望職種 | プログラマー |
| 学校等 | 久留米工業高等専門学校 |
| 意気込み | 今回のインターンシップで、具体的な志望職種を定め、サイバーコネクトツー合格に向けて自分の武器となるようプログラミングスキルを磨きます。 |
今秋より、週1回、木曜日に、インターンシップ生たちの活動と生の声を、たっぷりお届けいたします。
お楽しみに!
先週のβ版提出前日に、サイバーコネクトツーのゲームデザイナーの方に実際にゲームをプレイしていただき、
以下のようなご意見・ご指摘等をいただきました。
頂いたご意見と、それについての改善点は以下の通りです。
1移動する際にプレイヤーから引っ張ってしまう
これは、プレイヤーを飛ばすという先入観から、初めてプレイするユーザーの方は、
プレイヤーを中心に引っ張るものと勘違いする方が出てしまうからです。
このゲームは、引っ張った距離に応じて飛距離が決まるので、
プレイヤーから引っ張ると飛距離が短くなってしまい、高い壁をうまく上れません。改善点
引っ張った距離だけでなく、そこに「タメの要素」(指で長押しする)を追加することで、
少ない距離でも遠くに飛べ、距離でも調節できるようにしてより快適にプレイできるようにしました。2テンポが悪く感じてしまう
このゲームでは制限時間を設けており、時間が過ぎると無条件でゲームが終了してしまうことから、
プレイヤーが「プレイヤーの移動速度が遅いのにゲームオーバーになってしまう」
というストレスを感じてしまうのだと考えました。改善点
制限時間を過ぎた時点で終了とせず、0秒になった後、さらに何かしらのダメージを受けたときに
ゲームオーバーとなるようにしました。
また、0秒になった際は、画面で警告を知らせるようにし、緊張感を与えるようにしました。3ギミックのジャンプ台を用いた時に"やらされている感"を感じてしまう
ジャンプ台は、乗った際に決まった場所へ自動的に飛ばされるようになっているのですが、
画面外に飛ばされる際に着地した場所がゴールだったりアイテムがあったりなど、
自分が操作しなくても結果が一緒になるので、自分でプレイしている感が損なわれてしまっていました。改善点
プレイヤーに操作感を感じてもらうため、ただジャンプ台を配置するだけでなく、
ジャンプしている途中に敵やギミックを配置することにより、
ゲームをプレイしている感を損なわないように配慮したステージを作り上げていくようにしました。
▲さんかくジャンプ台の先にギミックを配置
このように、提出前に大きな修正を行いましたが、この度、
無事β版の提出を終えることができました。
α版と違って、すべてのステージが実装されており、起動からゲームクリアまでが一通りできるようになりました。
ゲームの完成度として日々上がっているという実感がありますので、残り1週間で、
プレイして頂く皆さんが「面白い」と思えるゲームを実現できるように頑張って行きたいと思います。
β版提出の次に待っているのは、マスター版の提出です。
マスター版とは、ゲームとしてのパラメータ調整も終え、デバック作業も完了しており、
キチンとした形でゲームが遊べる状態になっているものを言います。
このマスター版に向けて最後の追い込みとなる訳ですが、社内のスタッフの方から
「1週間後に控えたマスター提出までに下記を実装する」という課題が出されました。
課題内容は、
という2点です。
課題内容をクリアすることで、よりゲームをプレイした時の「気持ち良さ」や「やりがい」などが生じて、
繰り返しプレイしていただける作品になっていくと思いますので、
メンバーの作業分担を明確にして実装にこぎつけたいと思います。
さて、インターンシップも残り1週間を切りました。
その中で感じた、私の今までと今後のことについてお話したいと思います。
私が、初めて「ゲームを作りたい」と思うようになったきっかけは、
中学生の時に友人とみんなで楽しくゲームで遊んでいて、
自分もみんなを楽しませるゲームを作りたいと思い、それ以来ゲームを作る職に就きたいと思いました。
しかし、そう思ったまま、実際に行動に移すことができず、大学に入って初めて自分のパソコンを持ったぐらいでした。
大学では、主にプログラミングを中心とした学習をし、そこでプログラムの基礎部分を習得して、
研究内容をまとめてゲーム会社に応募をしました。
しかしその時は、希望していた職業に就けず、一般企業に勤めることとなりました。
勤め始めてから半年が過ぎた頃に、実際にクリエイターとして勤めている方の話を聞いて、
もう一度、悔いを残さないようにもう一度頑張ってみようと思い、
現在の専門学校に入学をし、そこで頑張った甲斐あって現在のインターンシップに合格し、今に至ります。
インターンシップでは、プロのクリエイターの方々とお話をする機会が多く、実際の現場の雰囲気も体感できて、
今後の自分にとって良い経験になったと思います。
この経験を生かして、長年抱き続けた「ゲームクリエイター」になる夢を実現していきたいと思います。
今回の記事で、東京インターンシップ4期生メンバーのブログは終了となります。
この2ヶ月間は、技術だけでなくゲーム制作に対する気持ちや心構えなど多くのことを学ぶことができました。
長いようで短い期間ではありましたが、ゲームクリエイターを目指す身としてはとても有意義な期間でした。
これまで、ブログ記事を見ていただきまして本当にありがとうございました。
]]>このゲームは『おもちゃのパチンコの様に引っ張る操作でプレイヤーを飛ばし、
敵を倒しながらゴールへ向かう』ゲームです。
引っ張る操作は画面のどこからでもできます。
そのため、最大距離引っ張るためには、画面上部から下部へ向けて引っ張る操作が必要なのですが、
どうしても、初めてプレイされた方はプレイヤーキャラクターを中心に引っ張るために、
引っ張りきれないままタッチパネルの枠に達してしまいあまり飛べない、という様子が見られました。
またジャンプの際に、飛ぶ先が見えづらいという問題もありました。
実は、これらの問題は、先々週の段階で分かっている事でした。
「これはまずいな」とは思っていたのですが、良い案が浮かばないため、
それよりも他の部分の実装を優先させ、解決できないままでいました。
先週の進捗報告会で改めてその問題について指摘され、その際プレイしていただいたゲームデザイナーの方に、
「引っ張る時にカメラをズームアウトしては?」という提案を頂きました。
そうする事で「縮尺が大きくなり、少しの引っ張る動作で長い距離を引っ張っているように
出来るのではないか」という事です。
進捗報告会後、話し合いの中では、
「引っ張る操作を画面上半分から始めるよう限定し、最大距離で飛ばしやすくするのはどうか。」
「操作ではなく表示について言えば、先が見えにくいという問題の解決として
ズームアウトするのではなく、進行方向にカメラを動かすという方法があるのではないか。」
など様々なアイデアが出ました。
それに対して、指導担当の方から、
「プレイヤーキャラクターを端に置くことで、プレイヤーキャラクターからの操作をしにくくさせ、
別の点からの操作を示唆するのはどうか。」
という案を頂きました。
そして最終的に、解決策として、下記の二つの案が出ました。
<一つ目>
従来どおりの操作を前提とし
・ カメラを進行方向に向けて移動し、前方を見渡せるようにする
・ プレイヤーキャラクターを画面端に置くことで、プレイヤーキャラクター中心の操作では
上手く飛べないようにして、 画面全体で操作できることを示唆する▲さんかく一つ目の案(画面上部からの操作重視)
<二つ目>
プレイヤーキャラクターを画面の中心に置いての操作を許容し、
・ 引っ張り操作時にカメラをズームアウトする事で遠くが見えるようにする
・ 引っ張った距離あたりの飛距離を増やし、プレイヤーキャラクター中心の操作でも
飛距離が問題ないようにする▲さんかく二つ目の案(プレイヤーキャラクターが画面中心の操作重視)
今回は、後者の案を採ることにしました。
プレイして頂いた方に多く見られたのが、「最初にプレイヤーキャラクターをタップし、
次に、移動が引っ張ることであるとわかると、プレイヤーキャラクターを中心に引っ張る」
という操作を行うというものです。
ならば、「そのまま素直に操作できるようにしたほうがわかりやすいのでは」
と、考えたからです。
ただし、これが正解というわけではなく、もっと良い方法もきっとあると思います。
けれども、その時最適だと思う事に決めていかなければ、ゲームはいつまでたっても完成できません。
決めた結果、後に修正が必要になるにしても、それが駄目だった、というフィードバックにはつながります。
何日も何日も悩んでしまうより、ある程度まで考え、
仲間や社員の方に相談して案が絞られたら、
さっと選択してしまったほうが結果的には良い場合が多いと感じています。
今回の案を採用する過程が、まさにそういったケースでした。
自分が2週間棚上げしていた事が、たった1日で解決したのです。
今回の操作部分の変更というのはタスク量としては小さいですが、
それでも決定にかかる時間として、2週間と1日という差は馬鹿になりません。
自分一人で考えるのには限界があります。
様々な人の知恵を借りるという事は、今回のように直接答えを得られる事もあります。
また、そうでなくても
違った視点からの意見は、考えを膨らませるきっかけともなりえる大切な事
だと感じています。
▲さんかく操作感チェックの様子
このゲームにはジャンプ中に敵を攻撃でき、敵を自分の近くで倒すほどスコアが高くなる、
という仕組みがあります。
それについて、先週の進捗報告会で、
■しかく プレイヤーにとって攻撃する事は移動する事より難しい
■しかく その攻撃するタイミングによってスコアを判定されるとなると、攻撃するという行為がさらに難しく感じられる
という事を指摘されました。
また「パズルアクション的にギミックを凝らしてみるとおもしろくなる」
という助言もいただきました。
それもあり、当初予定していたスピードアクション的な、いかに速く敵を倒してゴールに行くかというものより、
パズルアクション的な「ゴールするにはどうするか」を解かせる方向性が強まって来ています。
そうなってくると、組み込んであった「攻撃タイミングの判定によってスコアが変化するシステム」の扱いが
非常に難しくなってきました。
目標が、ハイスコア更新よりもステージクリアの要素が大きくなったため、重要性が薄くなってしまったのです。
ただし、これについてはレベルデザイン次第であることもあり、
追加するより実装済みの物を消す方が簡単なので、
もう少し先に結論を出そうと思っています。
背景について、前回の自分の記事で紹介しましたが、どうにも画面全体が見にくく、
その点についてサイバーコネクトツーのアーティストの方に相談したところ、
「 背景が原色系で前に出てきてしまい、プレイするのに重要な部分が白いので見にくい。
円と四角という形、同じパターンが繰り返されているので単調であるし、
同じ絵の繰り返しはどうしても手抜きを感じるし、奥行きを感じない。 」
という指摘を頂きました。
その上で「背景は立体物にしてしまってはどうか」とアドバイスいただきました。
背景の時計が埋め込まれたドアが以前は平面でしたが、現在は立体物になっています。
また遠景の明るさを抑え、手前側の足場が見えやすいよう調整しました。
やや地味になりましたが、実際にプレイしてみると、奥行きが感じられる背景なっています。
他のステージの背景も出来上がりつつあります。
▲さんかくステージ2の背景 ▲さんかくステージ3の背景とステージの様子
ステージ2はビル街、ステージ3は学校の廊下がモチーフとなっています。
ステージ2に関しては足場がビルであり、足場が背景を補完するようになっています。
今回のゲームは3ステージがさらにそれぞれ5マップに分かれている構造となっており、
背景はそのステージ毎に異なるようになっています。
現在制作中のゲームとは直接関係ない事になりますが、私の志望職種についてお話しします。
以前は、アーティスト志望という事になっていました。
これは、今回のインターン募集の際、アーティストとプログラマー、という区分で募集していたため、
という事もあってなのですが、実は本当に最近まできちんと志望が定まっていませんでした。
私は、昔から「ゲームが作りたい」と思っており、高専ではプログラミングを学び、
その後大学、大学院と3DCGの映像を中心に制作してきました。
そのためプログラムも書けるし、3DCGも作れるし、絵も多少は描ける。
けれどそもそもなぜそれらを始めたのかといえば「ゲームを作りたい」という動機からだったはずなのに、
ゲームデザイナーとして必要とされる事を専門的には学んでいないし、それ以外の部分についても、
どれも多少出来るという為に専門が無く、逆に何も出来ない状態になっていたのです。
そのため様々な職種の方にお話を伺ったりしながら、現在の自分の持っているスキルや、
やりたい事は何なのか考えた上で志望を定め、現在はゲームデザイナー(企画職)志望となりました。
プロのクリエイターの方々に相談に乗ってもらえたという事は、
インターンに来て本当に良かった事のひとつです。
自分の生活圏内にゲームを職業としている人がほぼおらず、
ぼんやりとした一般論的な事しかわからない状態だったので、
詳しく話を聞けたのは大きな収穫でした。
現在、ゲーム制作は佳境に差し掛かっています。
このゲームは、非常にレベルデザインの比重が高く、それ次第では面白くもつまらなくもなりえます。
このブログを書いている段階では、グラフィックスの作業を必死にこなしていますが、
出来るだけ早く自分の担当部分のレベルデザインへ取り掛かり、
このゲームを一人でも多くの方に楽しんでもらえるものにしたいと思います。
私がブログを担当するのはこれで最後ですが、ゲーム完成に向けて作業を頑張っていきたいと思います。
]]>β版への作業が始まり、私たちの制作はいよいよ佳境へ突入しつつあります。
この東京インターンシップも残り少なくなってまいりましたが、
今まで以上に気張っていこうと思います。
前回の安達さんの記事でも触れていましたが、β版とは
ゲームとしての要素が全て詰め込まれ、完成している状態であり、
β版が終わった後は調整やデバッグぐらいしかできません。
私たちに残されている作業は、主にレベルデザイン(ステージやマップの設計・構成)と、
それに必要なギミックやアイテム、敵などのプログラムとグラフィックです。
特にグラフィックは作業量が非常に多いです。
このままでは、グラフィックを担当している安達さんに作業量が偏ってしまうので、
プログラム担当の私も簡単なエフェクトやモーション作成などを手伝うことにより、
作業量の分担を図っています。
▲さんかく敵のグラフィックの途中経過。
▲さんかく敵のグラフィックその2。夢に出そうです。
また、社員の方にα版の評価をしていただいた際に、
「プレイヤーキャラの操作方法がわかりにくい」といったご指摘を受けました。
「画面をタップしながら引っ張って離す」という、
輪ゴムを飛ばすような一見シンプルな操作方法ですが、
ゲーム上でこの操作方法を示唆するのは意外と難しいです。
この操作方法をいかにしてプレイヤーに理解してもらうかといったところも、
β版までの課題となるでしょう。
レベルデザインとは、ゲーム中のステージやマップを設計、構成することです。
私たちのチームにレベルデザイナーはいないので、全員でステージを考えて作成することになります。
その中で私は序盤ステージの担当をすることになりました。
序盤ステージといえば、ゲームを始めたばかりのプレイヤーが遊ぶ
最もプレイ難易度の低いステージです。
しかし、そのステージをつくる難易度は低くありません。
なぜなら、作る側はデバッグを繰り返し行っている為プレイに慣れており、難易度の感覚が麻痺している、
つまり、そのステージが簡単なのか難しいのかが分からなくなっていることが多いため、
プレイヤーにとって適正な難易度を設定するのが難しいのです。
デバッグ中は問題ないと思っていたところが、
実はプレイヤーにとっては難しい箇所であったということもよくあります。
例えば下の画像をご覧ください。
これは、仮ステージのある場面で、中央のプレイヤーキャラの前に壁があります。
私は何回もプレイしていたので、この壁を難なく越えていました。
しかし、未プレイの社員の方にプレイしていただくと、
多くの方がこの壁で突っかかってしまい、とてもうっとうしそうでした。
一度後ろに下がると飛び越えることができますが、このゲームは操作性が特殊な上に制限時間もあるので、
そういった余計な行動をさせるのはストレスになってしまいます。
ゲームを制作している自分たち以外の方にプレイしてもらわなければ、
この壁が、初めてプレイする方にとってストレスの原因となる「魔の壁」であるということに気づけませんでした。
このように、レベルデザインは主観だけでは中々良いものが作れないので、
積極的に誰かにプレイしてもらうなどして難易度をこまめに確認する必要があります。
このゲームにおいて序盤ステージは、操作性に慣れてもらうという役割が大きいので、
まずは敵や落とし穴の数を控えめにして難易度はできるだけ抑え、
かつゲームの面白さを徐々に伝えていくといった工夫をしていこうと思います。
制作が進むにつれて、スマートフォンでの動作が重くなってきたため、
無駄な処理が生まれないように気を使うようになってきました。
しかし、Unityの仕組みについて深く理解していないこともあって、
どういった処理が重くてどういった処理が軽いのかが、イマイチわかりませんでした。
制作の後半では、毎週末、指導担当の方に進捗報告会を行っていますが、
そこで指導担当や社員の方々に色々なアドバイスをもらうことができるので
処理の軽減に関するテクニックなどについても詳しく教えていただきました。
本やネットでは調べるのが難しいことも教えていただけるので、非常に参考になりました。
▲さんかくアドバイスを元に処理の軽量化について話し合いました。
東京インターンシップが始まってからのこの1ヵ月半はとても短く感じましたが、
新しいことの連続で今までに無いほど濃い時間でもありました。
今回をもって私のインターンシップブログは最後となりますが、
制作はまだまだ続きますので今後も全力で制作に取り組んでいきます。
前回の安達さんのブログでも書かれていましたが、ついにα版提出を迎えました。
今回は、α版で感じたことと今後の目標について
皆様にお伝えの方をしていきたいと思います。
先日、無事にα版を迎えることができました。
▲さんかくα版ステージプレイ画面
完成しましたα版では、
・ 主人公が敵を攻撃して倒して行き、ゴールを目指していく。
・ プレイ成績によってステージ評価や次のステージに進めることができる。
・ BGMや、アクションを起こしたときに効果音が鳴る。
といったところまで実装ができております。
実際に、α版を指導担当者の方や社内スタッフの方々にプレイしていただいたところ、
下記のような評価・ご指摘を頂きました。
■しかく 操作方向が分かりづらい
■しかく ステージ構成がまだまだできていない
■しかく ゲームの流れが単調になっている
その後意見を踏まえ、改めて意識してプレイしてみると、
開発しているメンバーは、ゲームのルールを理解しているけども、
初めてプレイする方々には、操作方法(どうやってプレイヤーをジャンプさせるのか)を
全く伝えきれていないことに気づきました。
こういったことは、ある程度制作が進行していくと起こりうる問題なので、
今後、客観的に見てプレイしてみたり、
その度に社内スタッフの方々に直接ご意見ご指導等を頂いていこうと思います。
そして、私はプログラマーということもあり、指導担当者のプログラマーの方から
ソースコードについての評価もいただきました。
<良い部分>
・ソースコードできちんとコメントや整理がされていて見やすい
<悪い部分>
・まだまだ無駄な処理が多い
といった、私にとって今後精進していくべきコメントを頂きました
複数人での制作をするにあたり、他のメンバーのコードを見たり、
引継ぎをするときなどにコードを見たりすることも多々あるので、
自分以外の人が見たときに円滑に理解することができるように
注意する必要があります。
今後も他のメンバーが見たときに見やすく分かりやすく、無駄のないソースコードを
記述できるように慣れて行きたいと思います。
無事にα版を終え、次に待っているのはβ版です。
「β版」とは、α版と大きく違い、ゲームバランスの調整やデバッグ以外の全てが完成した状態で、
ゲーム内の全ての要素が詰め込まれたもののことです。
見た目も内容もα版とは、見違えてしまいます。
β版に向けてチームメンバーのそれぞれの作業項目を洗い出して、
再度スケジュール調整を行いました。
▲さんかくα版の内容を踏まえて、話し合いをします。
現状は、ただ敵を切って倒すだけとなっているので、
切ったときの敵の反応や、エフェクトといった、見た目でも楽しめるようにしていく必要があります。
例えば、
・ 敵を倒した後にやられモーションを入れる。
・ 消える瞬間にエフェクトが出てくる
などがあります。
α版の段階では、こういった部分に手が回っておらず、やや味気ない印象を私は感じました。
この印象を解消するためにも、限られた時間の中で実現できる演出等を
どんどん盛り込んでいきたいです。
素材も徐々に揃っていき、ステージも少しずつ見た目が変わってきました。
しかし、開発が進んでいく中で、PC上とモバイル端末上での性能の差が出てきました。
PC上では、問題なく滑らかに動作する部分も、
実際、実機(スマートフォン)上で動作してみると半分ぐらいの速度でなんともカクカク動いてしまいます。
このような問題解消も、プログラマーとしての腕の見せ所となってくる部分が強いので、
段階を踏んで直していきますと思います。
まず目をつけたのは、ポリゴンの数です。
「ポリゴン」とは、3Dオブジェクトを構成している三角形や四角形などの要素のことです。
Unityでは、プログラムをあまり知らない人や3Dを作ったことがない人でも
あらかじめ用意された、四角い箱や円などの簡単な3Dのオブジェクトを
ゲームの画面上に置ける機能が、初めから付いております。
その機能の中に板のオブジェクトを作り出すものがあるのですが、
これは、ゲーム中の背景やUIを表示したりするときなどに用いられたりします。
しかし、用途によっては自分で作った方がいい場合もあります。
実際に自分でプログラムを書いて作ったものと比較してみました。
▲さんかく(左)初期からUnityに備わっているプレート (右)自作したプレート
見た目でも十分に分かるかと思いますが、
ポリゴン数が大きく違います。100分の1の数になりました。
上の図では、左側が三角形200個、右側が三角形2個で3Dの板が作られています。
背景やUIなどの部分で用途によっては、凸凹のない四角い平面で表現する場合もある為、
2ポリゴンでも問題ない部分が多くあります。
意識しないでいるとポリゴンの数がどんどん増えていき、
知らず知らずのうちに処理が重くなってしまいます。
ポリゴンが多ければその分、リアルな3Dを表現できますが、
ポリゴンの数だけ分処理を行う必要があるために重くなってしまうのです。
こういった部分を考えながら、既存のものをそのまま使うだけではなく、
適宜自前で用意するのも大切だと思いました。
この1ヵ月は、新しいことを学んでいるということもあり
一日一日が大事な経験となっております。
次なるβ版提出に向けて、プレイしていただいた方が面白く感じるゲームにしていこうと
頑張って行きますので、今後もよろしくお願いします。
それでは、また次回をお楽しみに!!
]]>グラフィック素材をゲーム本編に組み込んでいる最中です。
大分見た目も整ってきました
プレイヤーキャラクターについてはアニメーションも設定されました。
やはり動きが付くと「ゲームを操作している」という感覚が強くなります。
▲さんかく現在のプレイ画面
ゲームシステムについては以前のブログなどでこれまでお伝えしてきた通りですが、
ストーリーや設定について、変化がありました。
企画についてサイバーコネクトツーのリードアーィストの方に相談した際、
「今回のゲームの目的は、敵を倒すと残り時間が増えるので、
それを利用しながら制限時間内にゴールすることです。」と説明したところ、
「時間を奪って進むなら、時計をモチーフとした敵にしたらいいのでは?」
というアドバイスを頂き、それをベースに
『不思議な空間に迷い込んでしまった主人公が元の世界に戻るために進んでいく』という
ストーリーとなりました。
また、当初の案であったブラックな表現はなくなり、
時計をモチーフにした敵を倒して進むゲームとなりました。
以前のブログでも紹介した通り、今回制作しているゲームの主な操作は二つで、
・ ジャンプして移動する
・ タイミングよく敵を倒す
ということです。
ジャンプ操作についてですが、前回の若井さんの記事にもありましたが、
ジャンプは完全に軌跡を表示して、どこに行くか判断してから飛べるようになっています。
企画段階では「操作の補助として、飛んでいく方向と距離を簡単に矢印で表示する」という方法のつもりでした。
その表示で予測できない部分は、プレイしていく中で、感覚で覚えてもらい、
上達する楽しさを感じてもらおうという考えです。
しかし、その方法で一度プログラミングしてもらい、動作をチェックしている途中で気がついたのですが、
タッチパネルで正確な操作というのはかなり難しく、
特定の位置に着地させようと思っても中々出来ず、イライラしてしまいます。
スマートフォンでの開発が初めてという事もあり、
どうしてもタッチパネルの挙動は実際にテストしないと分からないことが多いです。
今回は、軌道を完全に表示することでそのイライラを解消し、
ジャンプ操作が上達する楽しさよりも、最適な移動ルートを自分で探す楽しさを押していこう、という
狙いにしました。
しかし、いざ完全な軌跡を出そうとしても技術的な問題などで、
どうすればいいのか分からなかったりといったこともありましたが、
プログラマーの若井さんが方法を何とか見つけてくれたおかげで解決できました。
こういったことも、一人ではなく、チームで制作することの利点であり、
自分自身の成長にも繋がっていると思います。
▲さんかく進捗状況確認の様子
今回のゲームの中で『タイミングよく敵を倒す』というものがありますが、
敵を倒したタイミングの評価として、「Good」「Cool」「Excellent」 の3段階があり、
敵の近くで倒すほど評価が高く、スコアを稼げるというシステムになっています。
その『タイミングよく敵を倒す』という部分について、サイバーコネクトツーのゲームデザイナーの方に
アドバイスをお願いした際
「どういった基準で、どのタイミングで敵を倒すとその評価だったのか
明確にしないといけない」
という指摘を受けました。
なんとなく近くで倒しているから良い評価、遠めだから悪い評価、では、
プレイヤーには納得してもらえません。
そのため今回、プレイヤーキャラクターの周囲には攻撃範囲を示す半円を表示し、
その中を色分けしてどの距離で攻撃したらどの評価なのか視覚的にわかるようにしました。
しかし、チーム内で、プログラマーとのコミュニケーションが甘く、
その部分の重要性について伝え忘れてしまいました。
そのため、攻撃そのものはできるようになっていましたが、
範囲表示が後回しになっている状態でした。
しかし、攻撃範囲表示は重要な部分ですので、現在、優先で対応してもらっています。
このミスが起きた原因として口頭での確認不足もありますが、
プログラマー側のタスクに、私が『プレイヤーキャラクターの攻撃』としか記載しなかったことが
大きいのでは、と考えています。
もし『攻撃および攻撃範囲表示』などと表記し、
その重要性をきちんと伝えていればこのようなことは起きなかったでしょう。
タスクを切り分け、そういった記載をしたのは自分なので、その点反省しています。
当たり前ではあるのですが、「多分わかってくれるだろう」という考えでは
自分が思うほど相手にわかってもらえないことも多くあります。
今回は対応可能な範囲だったので何とかなりましたが、今後は気をつけて行きたいと思います。
先述のとおり、今回制作するゲームは『時間』が大きな意味を持つので、
時計というモチーフに、当初のイメージであったポップでカラフルな色使い、という方向性で制作する事にしました。
下図は、冒頭にあったプレイ画面の背景です。
カメラが移動した際、カメラの視差によって背景の画像の見え方に変化が生じて
奥行きが感じられるように、遠景と中景、近景に分割した3枚の画像を配置し、作成しています。
私は、普通のキャラクター物の3DCGをちゃんと作るのはこれが2回目で、
しかも前回はゲーム用ではなく、動画用だったので、
スマートフォンの制約を踏まえたうえでゲームのキャラクターを作るというのは、とても新鮮でした。
3Dの物体というのは、「ポリゴン」と呼ばれる面で構成されているのですが、
この面の数によりディティールの細かさの限界が決まってきます。
多ければ多いほど細かな造型ができますが、その分、動かすコンピュータのパワーが必要になってきます。
そのため、スマートフォンで遊ぶゲームでは、かなり制限があります。
サイバーコネクトツーのアーティストの方に伺ったところ、
今回のキャラ数なら大体の目安として一体あたり300〜600ポリゴン位ということで、
それ以内に収まるよう努力してみました。
▲さんかく制作中のプレイヤーキャラクターのモデルです。
作ってみた感想として、どこにどれだけポリゴンを割り当ててどこを削るのか、
ある程度慣れが必要だなと感じています。
仮で作成したモデルを社員の方に見て頂いた際には、
「ジャケットにある平らに近い部分はポリゴン数を削り、
その分をカクカクのスカートに割り当てる。」
「肩については関節を動かす際、変形に耐えられないのでもっと分割が必要。」
と、アドバイスを頂きました。
それに従って改善は行ったものの、それでも肩関節は多少無理をすると破綻してしまう等、心残りがあります。
また、他にもセオリーを知らないがために同じ工程を行ったり来たりしたり、
機能を知らないためボタンひとつで出来る事を複雑な手順でやろうとしたり等、
苦労はありましたが、何とか形になってきました。
α版提出が7月31日という事で、どのような反応がもらえるかドキドキです。
またその反応を踏まえて、ゲーム内容をより良くする為にまた頑張りたいと思います。
それではまた次回お会いしましょう。
]]>インターンシップ開始から早くも3週間が経過し、
私たちは現在1週間後に控えるα版に向けての制作を推し進めています。
α版とは、制作物の雛形が完成しそれを評価する段階のことです。
α版を経由することで、企画の仕様や方針を見直すことができます。
私たちが目標としているα版の形は、
「1企画の面白さを形にできており、
2ゲームとして最低限1ステージは遊べるようにする」
といったものです。
前回の私のブログ記事で述べたとおり、このゲームで楽しんでほしいのは
タイミングよく敵を攻撃するというところなので、
これを最優先に制作を進めて来ました。
基本的なシステムが完成し始め、実機であるスマートフォンでの
動作確認も始めています。
普段はプログラムの動作確認をUnity上で行っていますが
PCとスマートフォンは画面も操作方法もまったく違うので
システムを作りつつ、しばしば実機でテストプレイをし、
実際の操作感覚を確かめます。
いざ実機で動かしてみると、様々な問題が見えてきました。
スマートフォンの画面上ではキャラクターが思いのほか小さく感じたり、
派手目に作ってみたはずのエフェクトも地味に見えたりします。
操作感覚も、PC上ではマウスポインターを使っていたため器用な操作が可能でしたが、
画面が小さく、かつタッチパネルによって操作するスマートフォンでは
どうしても操作が大雑把になってしまいます。
グラフィックなどのリソースも、スマートフォンの処理性能を考慮して
作らなければなりません。
こういった問題をいかにクリアしていくかが、
今回のインターンシップの大きな課題のひとつとなるでしょう。
▲さんかく実機テストをしている様子。
前の私の記事でも少しだけ触れましたが、
このゲームはドラッグ&ドロップによる操作でプレイヤーキャラをジャンプさせ、
敵をタイミングよく攻撃して倒しながらステージを進んでいく
というものです。
前回の富板さんのブログ記事にも書かれていたとおり、
私はプレイヤーキャラの動作処理を担当しています。
▲さんかく開発中の画面。グラフィックはほぼ全て仮素材で作られている状態です。
空中に浮いているのが敵の仮グラフィック。
紫のラインのようなものはジャンプの軌道です。
キャラを引っ張って飛ばすという動作だけならば簡単に作れますが
プレイヤーキャラは文字通りプレイヤーの分身であり
プレイヤーに不自由を感じさせず思い通りに動くように作らなければなりません。
いざ作ってみると、自分が想像していた操作感と違っていたり、
自分がいいと思っていることでも、仲間にやらせてみると「イマイチ」と
言われることも多いです。
また、プレイヤーキャラはどうしてもほかのプログラムと頻繁に干渉しなければならないので、
こまめにプログラマー同士で仕様を話し合う必要があります。
このようにゲーム開発は報告と相談の連続であり、技術職といえど
コミュニケーションを大切にすることが良いゲームをつくることにつながるのだと
実感しました。
▲さんかくことあるごとに仲間に動作を確かめてもらいます。
この3週間は新しいことの連続で、あっという間に時が過ぎてしまいました。
新しい場所や開発環境にも慣れ、制作に身が入るようになりましたが
当初の緊張感を忘れずに努めて行きたいと思います。
最後までよろしくお願いいたします。
それではまた次回
]]>前回の安達さんのブログに引き続き、インターンでの体験や様子を
お伝えしていきたいと思います。
このようなブログの記事を書くことは、今までなかったことではありますが、
ブログをご覧になっている皆さんに、私たちの体験をお伝えできたらと考えています。
前々回の若井さんのブログにも書かれておりましたが、
今回の制作は、Unityを用いてのスマートフォン向けゲーム開発です。
その課題に対して私は、
「初めての"Unity開発"」「初めての"スマートフォン向けゲーム開発"」
「初めての"他学校の方との共同制作"」 など、
と多くの初めてがいっぱいあります。
私は、今までパソコン上で動くゲームを制作するのがメインだった為に、
スマートフォンでの開発は、新鮮な気持ちで臨んでいます。
こういった状況で学ぶこともいっぱいありますし、
とてもやりがいのある制作になると思いますので、頑張っていきます。
▲さんかくUnityを用いて作業中
ゲームを作っていく上でプログラマーが行う作業は、
プレイヤーの動作や画面上に表示する、音を再生させる など、
書ききれないほど幅広くあります。
今回の制作では、プログラマー2人での作業となり、
それぞれの作業分担が今後の制作進行にも影響を及ぼすので、
話し合って下記のような作業分担となりました。
■しかく冨板担当箇所
・ゲーム全体の流れを制御する。
・敵キャラクターの移動や攻撃といった動作を作る。
・ゲーム中に音を再生させるプログラムをつくる。
・制限時間やスコアなどゲーム中に表示される画像などを制御するプログラムをつくる。■しかく若井さん担当箇所
・プレイヤーのジャンプや攻撃などのアクションをつくる。
・ステージギミックの動作を制御するプログラムをつくる。
・ステージ中に出現するアイテムの効果を反映させるプログラムをつくる。
このように細かく作業分担を行い、
それぞれの作業がお互いに干渉する部分を最小限にすることで、
作業効率を上げて行きたいと思います。
そして、お互いのスケジュールをこまめにチェックして、
進行具合を確認し合うことも大切にしていきます。
作業をしていく上で、自分ひとりの力では、どうしても解決できないことが出てきます。
そういった場合、一人で考え込むのではなく、
一緒に作業するメンバーやプロのクリエイターの方々からアドバイスなどを頂いて、
いち早く問題を解決していくことが大切です。
しかし、自分が「どういった部分がわからないか」を把握していないと
相手に相談してもうまく伝えることはできません。
こういった場合に自分の中で、問題が起きた経緯や結果をあらかじめまとめておくなど、
相手に伝える前準備が必要です。
現在私は、敵の動作を作っておりますが、そこで思っているとおりに動いてくれないことがよくあります。
起きた問題についてメンバーと相談する際に、結果だけを言ってもうまく伝わりませんでした。
よくよく考えてみると、「何をした結果、その問題が起きているのか」が伝えられていないので
相手も問題を理解できていないようでした。
そのため、以下の3つをまとめてから相談するようにしました。
・自分の作りたい処理内容 :
「こういったことをしたいと思っているので、」
・自分の作ったプログラム内容と現状起きている問題 :
「こういったプログラムを組んだら、こういう問題が起きた。」
・その問題に対しての自分なりの解答 :
「こういうふうに改善しようと思うが、どう思うか。」
こうすることで、お互いに話の内容を理解でき、スムーズに話を進めることができました。
このように、相手にいち早く理解してもらえるように心がけることが
いち早く問題解決をする上で重要であると感じました。
▲さんかくお互いに相談している様子
ゲームを制作していくなかで、指導担当者の方から
「画面に表示されるもの(Unity上で画像の位置、エフェクトの出るタイミング など)
を、アーティストの方が直接調整できるようにするのも、
プログラマーとして大切な仕事である」
というお話をお聞きました。
私は、今までチームで制作してきたゲームのパラメーターの調整などは、
アーティストの方が、要望を紙にまとめたものを見ながら、行っていました。
調整した後、実際にプレイしてみると、見た目やゲームバランスで違和感がある
こともあるのですが、その都度、アーティストがプログラマーに調整を依頼していました。
このやり方では、アーティストの方にも余計な時間をかけてしまっていました。
他職種の方々にも扱いやすくし、作業効率を上げていくことも
プログラマーとしての腕の見せ所ですので、今後も、心がけて作業を行っていきます。
あっという間に2週間が経ってしまい、
一日一日がとても新鮮な日々を過ごしております。
2ヶ月間といった決して長くはない期間での制作は、大変ではありますが、
得られる経験もとても大きいものですので、今後も精一杯がんばっていきます。
それでは皆さん、また次回のブログでお会いしましょう。
]]>
