先日の記事で暑いですねとか書いたわけですが。
なんか寒いですね(笑)
気温がめっちゃくちゃで体調を壊しそうなgmatsuです。
CEDEC2017で感じたこと
昨日の8/31にCEDEC2017に行ってきました。
CEDEC自体は初参加、且つセッションの場への参加も初めてだった事もあり少し緊張しましたが、様々な企業の方々の貴重なお話を聞くことが出来てとても勉強になりました。
また、エンジニアとしての仕事への取り組み方を改めて考えさせられた一日でした。
朝から晩まで5セッション程参加したのですが、とても濃い有意義な時間を過ごせましたよ。
ユニティ、チョットデキルTシャツ欲しかったな…。
今回の記事ではCEDEC2017のセッションで自分が感じた事を書いてみたいと思います。
多機能なエディタがあると便利
そんなエディタがあると便利なんてのは当たり前ではありますが、エディタを作り込む事の重要性に関しては改めて考えさせられました。
マップやオブジェクトを配置するレベルエディタ、会話やシナリオの流れを管理するフローチャートエディタ等、ゲーム制作においては様々なエディタがあります。
また、独自に開発した物、既存の物等もあると思います。
今回私が参加したセッションではエディタに関してのお話をされている方が多くいらっしゃいました。
エディタA
- レベルエディタとしての機能、移動ルートの設定、各種フラグの操作、倍速モード、○○スキップ機能等。
- リアルタイムでゲームをプレイしながらの設定の反映が行える。
- 最初はタイトルAに使用していたが、タイトルB、Cでも使うことが出来ているので再利用性も高い。
エディタB
- レベルエディタとしての機能、タスク機能、バグ報告機能。
- タスク機能が非常に優秀で、タスクから担当者、該当ファイル、関連ファイルの情報が全て引き出せる。
- もちろんゲームをプレイしながらのリアルタイム反映も可能。
私は今までレベルエディタくらいしか作った事がありませんでしたし、それ以外の機能を持ったエディタを作成しようと思っても
あの機能はあったら便利だけどめんどいし… ゲームの規模が小さいしエディタにそんな力入れてもなあ…
などの理由から最低限の機能を持った物しか作ったことがありませんでした(マップチップの配置だけとか)。
しかし、セッション後はゲーム制作の規模などは関係なく、便利なエディタはあった方が良いのではと思うようになりました。
そもそもエディタを良い点とは、
多くのデータを量産したいから
だけだと思ってました。
エディタの本質としてはそうなのかもしれませんが、便利なエディタであれば更に多くの良い点がありました。
- ゲームを起動しながらデータの設置、修正が行える為、ビルドの回数が減り作業効率が上がる - タスク機能によりデータ１つ１つの進捗が把握出来るようになる
ゲームをプレイしながらデータを作ることが出来れば、動いていない画面でぽちぽち作るよりもデータ設定が考えやすいですし、ビルドの回数が減ることはとても嬉しいです。
タスク機能があればデータの作成漏れ等も発生せずに済みますよね。
デバッグログの収集
デバッグログは皆さんどこまで取ってますか？
１．プログラムを打つ ２．動かす ３．落ちる ４．さーどこで落ちたのかなー！
私はよくこんな事してました。
現在の業務ではエラー時にログがテキスト保存されるようになっているのでログが確認出来るようになっていますが、個人で制作する際はそこまでしてなかったので落ちてから勝負みたいな事をやっていました。
どこで落ちたのか、何が原因で落ちたか、これを探る為にprintf()を設置したりして、どこまでプログラムが進んでいるかチェックしたりしたなあ…。
これじゃ開発速度が落ちる一方ですよね。
セッションで紹介されていたデバッグログの保存方法では以下のような事が行われていました。
a. エラーログと一緒にスクリーンショットも保存 b. エラーが作業タスクに登録される
「a.」はエラーが発生した際のエラーログと一緒に、その場面をスクリーンショットに残しているという物でした。
これによりどの箇所でエラーが発生したのかが分かるため、修正すれば良い箇所も把握しやすくなるという物です。
「b.」の機能はとても面白く、便利だなと感じました。
エラーが発生したら、その箇所の担当者の作業タスクにエラー修正のタスクが追加される
これにより他の担当者やテスターがテストプレイをしたエラーを即担当者に知らせる事ができる機能です。
単にエラーを知らせるだけでなく、エラーが発生した箇所からどのデータがどう不正だったのか、それはどのファイルのデータなのか、またそのファイルはどのファイルと関わり合いのあるファイルなのかまで登録されるもの。
この仕組を実装した事により担当者はその原因を修正するだけで良くなったそうです。
ここまで作り込めたら確かに本来の作業に集中できるなと感じました。
そういえばデバッグログは何もエラーのログだけじゃなくて、ゲーム内の様々な情報を把握する為のものとしても使われているわけです。
次のような機能が入っているエディタもありました。
a. メモリ使用量把握 b. 各オブジェクトの配置分布 c. ゲームオーバーになった理由、場所 d. コリジョン抜けがあった箇所
こんな事を知る事が出来ます。
上記のログ機能で私が一番驚いたのは、数値、文字としてのログではなくワールドマップのような表示で把握出来ることでした。
メモリの使用量が許容できない箇所には✕印を付けたり、オブジェクトがある場所にはマークが付けられたり…。
ワールドマップを見ているような形で、フィールドのどの位置で上記の事が起きているのかを把握する事が出来るという物でした。
「ログ」という言葉を聞くとそれは数値、文字としてしか確認出来ないと思っていましたが、絵として見ることが出来ればコレほど理解、解析が容易になる物はないなと感じました。
ゲーム開発に対する考え方
今回のCEDECでは開発の手法だけでなく、開発に対する考え方を改める事ができました。
エディタやログ出力を作ることに対して、
今までは
エディタがあったら -> データ作りが楽 デバッグログがあったら -> 不具合の確認が楽
と考えていましたが、
これからは
エディタが便利だったら -> 何度もデータ作りをしなくても良く、面白さを追求する事に注力できる デバッグログがあったら -> 不具合の確認に時間を割かず、面白さを追求する事に注力できる
という事なのである、と考えを改める事ができた。
どのセッションでもお話されていた方々は口々に言っていました。
面白いゲームを作ることを目的としているから
エディタ、デバッグログ、それらを作り込む事は単に作業が楽になるということではなく、それが面白いゲームを作ることになるんだと話してくれました。
更に具体的に言えば、
面白さを追求するクリエイティブな作業に時間を使えるように、 人が行わなくても良い事は極力減らす仕組みを作る
とお話されていました。
エディタ、ログ出力の仕組みを作ることがめんどくさいなと思って居た自分が恥ずかしい…。
CEDECに参加する前は正直他の人のセッションを聞いた所で何か良いことがあるんだろうか、大きな企業の人の話を聞いたって自分には理解できないんだろうなとか思ってましたが、今はとても良い経験が出来たと思っています。
来年も行けるといいな。
来年こそはユニティTシャツゲットだぜ。
