【Unity】ゲーム開発で設計は大切だけどフォーマットにはこだわらないで

【Unity】ゲーム開発で設計は大切だけどフォーマットにはこだわらないで

もしあなたがIT系の会社でお仕事をしていて、しかもちょっとお堅い感じの開発方法をしたことがある場合、気をつけて欲しい点があるので共有します。

ゲームを作る時には設計を行いますが、もし設計書にきっちり書こうと思っているのならそれはやめた方がいいです。

IT系の会社だとドキュメントが大切なので、設計書をきっちり書くんですよね。これはこれで大切なんですけど、個人でゲームを作る時にこれをやると時間がもったいないです。

 

 

私の失敗~ガチな設計書フォーマット~

前いた会社を辞めた後、最初のアプリをリリースする時に会社で作っていたレベルの設計書を作りました。割とフォーマットなどもちゃんと作っていて、文書番号なども振っていました(笑)

なまじフォーマットがしっかりしているせいか、「しっかり決めないと!」と変に意識しちゃってなかなか作業が進まなかった覚えがあります。

机上だけでウンウン唸っている時間が多く、その時間を使ってアジャイル的に開発を進めていたらもっと早くできたのに……と涙を禁じ得ません。

Unityにめっちゃ慣れています! という人だったら机上でもある程度バシバシ決めていけると思いますが、まだ慣れてないうちは、設計でざっくりと方針だけ決めてUnityをいじっていた方が早く開発できると思います。

最初のうちは間違いなく設計の修正が入るので、フォーマットにこだわるとドキュメント修正のハードルが上がります。(改定履歴やコメントを残さないと……みたいな)

 

フォーマットはこだわらなくていいです

自分で作るゲームだったら、私はもうノートとペンしか使ってません。

走り書きレベルで、『一瞬で全体像を掴む ゲーム開発の攻略チャート』に書いた項目をざっくりと埋めたらすぐにUnityで作り始める、くらいの感覚でいます。

他の人と一緒に開発する時やお仕事を受ける時は必要なら設計書を書きますし、お客さんのフォーマットを伺ってそれに合わせて書きますが、個人で開発するという観点だと設計書のフォーマットにこだわるのはもったいないです。

設計で大事なのは設計した内容の方であって最低限読む人が分かる書き方であればフォーマットにはこだわらない方が良いです。

こんな記事を書いたのは、書類整理をしてたら最初のアプリの設計書を見つけたからなんです。(まさかの印刷までしているという徹底ぶり)

ご丁寧に表紙や文書番号、改定履歴、文書内のリンクなどがありました。

自分だけが使うものなのにここまでやってたことにドン引きです。この時間でコードをどれだけ書けたことか……。

 

ゲーム開発だと設計はどうせ変わる

ゲームを開発していて設計を変えた方が良くなることは日常茶飯事なので、設計を決めたら次のフェーズに進んでいくウォーターフォール方式の進め方より、設計したらすぐモック版を開発して動きを確認して、そのまま設計へフィードバックしていくアジャイル方式の進め方がおすすめです。

なので、その度にきっちりとしたフォーマットでドキュメントに残していると結構時間が取られちゃうんですよね。そうするとゲーム開発に回せる時間がどんどん減ってしまって、ゲームの完成がどんどん遅れて、いつの間にやらモチベーションが消滅……なんてことも。

「早さ」はゲーム開発でとても大切なので、その早さを妨害してしまう設計書のフォーマットへのこだわりはあの山の彼方まで投げ飛ばしてください。

 

まとめ

個人で開発するなら設計書のフォーマットにこだわらないのがおすすめ。紙に設計内容をざっくりと書いたら、Unityエディタを開いて開発を始めちゃいましょう。

設計を頑張ったとしても手戻りはある程度発生してしまうので、それだったらフットワーク軽く開発に着手して、その情報をフィードバックしちゃった方が良いと思います。

というわけで、今頭の中にあるゲームの設計を手元の紙に書き出しちゃって開発をスタートしましょう。

 

     

ゲーム開発の攻略チャートを作りました!

CTA-IMAGE

「ゲームを作ってみたいけど、何から手を付けていいか分からない!」


そんなお悩みをお持ちの方向けに、todoがアプリをリリースした経験を中心に、ゲーム作りの手順や考慮すべき点をまとめたe-bookを作成しました。ゲーム作りはそれ自体がゲームのように楽しいプロセスなので、「攻略チャート」と名付けています。


ゲームを作り始めた時にぶつかる壁である「何をしたら良いのか分からない」という悩みを吹き飛ばしましょう!