2nd.md (6814B)
1 --- 2 ## 記事 3 なぜ1年でゲームを完成させようと思っても当然のように4年以上かかるのか 4 5 ## 内容のまとめ 6 タイトルにはゲームとあるが、この記事では「Big Things」という本で紹介されているゲーム以外の内容を含む失敗論を、筆者なりに解釈し、ゲームを引き合いに出して、まとめたものである。 7 以降「Big Things」は本書と記述し、また、本書の日本語版のタイトルである冗長で過度に刺激的な文面は使用を控える。 8 まず、冒頭で記事の筆者が示したアンケートにより、タイトルにもある通り、1年で完成させようと思ったゲームが4年かそれ以上、もしくは未完成に終わることがありふれたことであると示した。 9 そのうえで、本書に出されているデータとしての事実を引き合いに出して、それはゲーム以外の巨大な国家規模のプロジェクトでも同じであることを示している。 10 このようにして、タイトルで示された問題がいかに重大なものであるかを(規模の大きな例を持ち出して)示して、理由に引き込む(≒理由を聞いてもらう)ように誘導している。 11 筆者が示している理由の第一点目は、前例のない行動をするからというものである。ここではオリンピックを例に出して、前例がないにも関わらず政治的利益のために実行されてしまう場合が後を絶たないと言っている。 12 記事の筆者はこの話をゲーム開発に対して言い換えをしており、新規のゲームサイクル(ゲーム内システムのフォーマット)の発明を誰もがしたがることが、同様な失敗を招いていると言っている。 13 これを回避する策として筆者が挙げている方策は、既成のゲームサイクルに磨きをかけることに注力することである。 14 しかしながら、これらの議論に対して 15 > だがこれはまだ序の口だ。 16 17 と一切の流れを遮った上で、第二点目の失敗理由を述べている。 18 筆者は、第二点目の失敗理由が一つの巨大なモノを作ろうとするからだとしている。 19 本書で述べられている(と記事の筆者がしている)「Small Things戦略」という、小さなモジュールに分けて繰り返し大量に作ることで解決できるものと、そうでないものがあるとし、 20 記事の筆者は、ゲーム開発は様々な依存関係から小さなモジュールに分けることのできないものであると述べている。 21 また、本書では天災という急激でどうしようもない破壊的変更が加えられる事象についても言及があり、それをゲーム開発ではエンジンやプラグインのアップデートに置き換えられると記事の筆者は述べている。 22 しかし、記事の筆者は昔から言われている言葉などを例に取り、難しいけれどゲーム開発でもSmall Things戦略をとることがふさわしいと述べている。 23 また、天災を避けるという意味で、ゲーム開発は早期に終わらせることが推奨されるとの見解を本書の内容から出している。 24 25 これらの記述の末、記事は筆者のゲーム制作のやり方について述べ始める。 26 筆者はもともとの予想から何倍もコスト(ゲーム開発では時間)が掛かってしまう事実を鑑みて、あらかじめ納期の半分程度のコストで完成することができるような設計にする方策を述べている。 27 28 最後にまとめとして、自分の経験をふんだんに交えながら、リスクを取らずに気長に、そして短くゲーム開発をするという方向性を示す形で記事を終えている。 29 30 ## 感想・コメント・質問など 31 32 Small Things戦略に関して、私もGitHubで開発する際には、大まかな仕様とかモジュール毎の連携をMermaidでReadme.mdに記述してから、大枠のプログラムに開始することが多々あります。自分がどこまで書いたか、どんなことを考えてモジュールを書いてたのかわからなくなるんですよね。 33 実装予定の機能も、issueを自分で立てておかないと忘れちゃいますし。 34 ただ、私はローコード開発の人間でも、バイブコーディングの人間でも、AI盲信プログラマー()の人間でもないので、そういう意味で、依存関係の管理などは非常にやりやすい環境だということは自覚しています。 35 RustではCargo.tomlでモジュールの依存関係をバージョンを指定して記述できますし、Next.jsでもpackage.jsonで同様のことをできます。 36 これは、私がLINE ヤフーでインフラエンジニアのインターンシップに行ったときに、聞いた話なのですが(もしこの感想を公表される際は会社名を伏せていただけると幸いです)、プログラムの仕様に関する裁量を持つ人間について尋ねると、そんな人間はいないとのことでした。 37 どういうことかと云うと、社内のプライベートクラウド(それも日本最大規模)には要求される仕様があり、それを統括した目標と仕様が決定されます。それをチームで噛み砕いて、一つ一つの仕様に落とし込んでいくので、裁量を持つ人間は居ないということらしいです。 38 アーキテクチャの記事の言葉を借りると、チーム全員がアーキテクチャ(を与える人間)であるということであって、自律的に社内政治が行われていることではないかなと思いました。 39 とても小さなプロジェクトやインディーゲーム開発に於いては、他人とコミュニケーションをとる必要も、仕様を公表する必要もないのでそこが疎かになりがちなので、このような記事を書く方がいらっしゃるのかなという印象を持ちます。 40 依存関係の解決はUbuntuのメンテナーのやっていることを見れば一目瞭然ですが、非常に難しいものです。私はSlackwareというLinux OSを使っていたので、自分で解決した経験があってとても身に染みます。 41 GNUやそれに近しいプログラム群はそれぞれが、モジュールとして一つ一つのプロジェクトが行うことが明確になっているので、自然的に?ソフトウェア工学に基づいた統制が取れているのかなと思ってみています。