素早く動き、見切りをつける
(engineersneedart.com)- 1991年前後の未完成Macゲームを復元する過程で、アイデアを素早く実装してみて、面白さや完成の見込みが乏しければ思い切って打ち切る開発スタイルが繰り返されていた
- 当時の一覧には27本のタイトルがあったが、実際に公開されたのは5本で、残りは約18か月のあいだに作られた高速プロトタイプに近かった
- スプライトベースのゲーム向け共通シェルのおかげで新しい実験のコストは低く抑えられ、サウンド・ハイスコア・セーブ機能は可能性が確認された後回しにされていた
- kite-fighting、K-10、Thief of Baghdadのような実験は、操作の面白さ、ゲームの目的、1人開発者が抱えられるアートと実装量を基準に継続するかどうかが判断された
- 捨てたプロジェクトも無駄ではなく、Fisher–Yates shuffle、画面の色深度切り替え、衝突判定、三角関数のルックアップテーブルのようなコードは後のプロジェクトで再利用された
古いMacゲームプロジェクトの復元
- 約35年前に書いたゲームファイルを古いハードドライブから復元していく中で、発売作よりもほとんど完成しなかった実験作のほうがより興味深い対象として残っていた
- 過去に公開していたsharewareゲームはディスクイメージにまとめて Soft Dorothy Software — Early Shareware Projects に公開した
- このディスクイメージは、Basilisk II、Sheepshaver、MiniVMacのような68KまたはPPC Macエミュレータにドラッグ＆ドロップして使える形式になっている
- Casady & Greeneが1991年にパブリッシングしたGlider 4.0関連のソースとビルドツールは、Casady & Greene Projects のディスクイメージに含まれている
- AirBikesは完成していれば未来的なレーシングゲームになっていたはずだが、実際には未完成のまま残った
27本のタイトルのうち発売は5本だけ
- 1991年ごろに作った文書には、各ゲームのcreator code、名前、状態が整理されていた
- creator codeはOS X以前のMacintosh時代における非常に大ざっぱなbundle identifierのようなもので、各アプリケーションで固有である必要があった
- 一覧には27本のタイトルがあり、そのうち発売されたのは5本だった
- 残りの大半は高速プロトタイプだった
- これらのプロジェクトは約18か月のあいだに作られていた
- 一覧作成時点では同時に3本のタイトルを作業中だったことが記録されている
- UnMaskというユーティリティも公開したが、作成に10分ほどしかかからなかったツールだったため、分析対象からは外してよいものとして扱われている
高速プロトタイピングのやり方
- 毎日深夜までコーディングしながら多くの実験を作り、スプライトベースのゲーム向け共通シェルによって新しいプロトタイプ制作のコストを下げていた
- 新しいゲームスケッチでは、主にMacPaintでスプライトやアートを作る時間が必要で、固有の入力方式・ゲームメカニクス・物理実装にはいくらかコードが必要だった
- サウンド、ハイスコア、セーブゲームのような機能は最初から作らず、生かす価値のあるゲームにだけ後から実装する方針だった
- 核心は、アイデアが実際に面白いかを素早く確認することにあった
- 紙の上に書かれたアイデアが面白そうに見えることと、実際に遊んで面白いことは別かもしれない
- 操作と物理だけを数日で実装しても、続ける価値があるかどうかは確認できた
面白さを素早く確かめる基準
- kite-fightingゲームは、数日のうちに飛ばす操作と物理を実装してテストできる
- 凧を操縦すること自体が難しすぎるなら、そのゲームを楽しめる人は少ない可能性が高い
- 戦闘要素がなくても、凧を飛ばすだけで面白ければ可能性はある
- アーケードゲームJoustは、敵が現れる前でもflapボタンで飛び回る操作そのものが面白かった
- ゆっくり羽ばたくべきときと、素早く上昇しようとして必死にボタンを押すときの両方がプレイ感を形作っていた
- 紙飛行機が散らかった家の中で床の通気口を使って揚力を得るゲームも、部屋を進みトーストなどを避けるという目的を理解する前から、ある程度は面白さがあった
- K-10はKansas highway 10にちなんだ別のレーシングゲームだったが、プロトタイプ段階を越えられなかった
打ち切るか続けるかの判断
- 一部のゲームは初期実装までは進んだものの、その先に何をすべきかが明確ではなかった
- 一覧にはいくつかのゲームに**
<no point>**と冷徹に書かれていた
- 一覧にはいくつかのゲームに**
- プラットフォームゲームThief of Baghdadは、魔法の絨毯に乗って跳び回る部分は面白かったが、その次にゲームの目的が何になるのかが不明瞭だった
- 1人で開発する条件では、可能性がありそうでも完成まで1年以上かかるプロジェクトを続けるのは難しかった
- Dungeons and Dragons風のスプライトベースadventureゲームは魅力的だったが、プレイヤーの武器ごとの動作、モンスター、呪文効果、戦闘システムまで必要となり、作業量が大きかった
- 剣で突いたり防いだりする動きを作ったあとには、メイス・弓・マントのようなバリエーションまで追加する必要があり、アート負担が膨らんでいく
もう一度取り出し、コードも再利用する
- 保留しておいたゲームは完全に死んだプロジェクトではなく、ソース・リソース・プロジェクトファイルを見つけられれば再び取り出せる
- Thief of Baghdadは約18か月後にカラー版として再始動し、Scheherazadeという名前を得て、ある程度の目的も見え始めていた
- 2度目の試みでも、最終的には説明しがたい魅力が十分に生まれず、再び中断された
- 保留したプロジェクトのコードは、その後の作業で再利用できた
- Fisher–Yates shuffle algorithm
- 初期Macでモニタの色深度を変更するコード
- polygon-point衝突コード
- 高速な三角関数のためのsineルックアップテーブル
- dot-productとcross-productのルーチン
- こうしたプロトタイプ作業は無駄とは見なされていなかった
Appleでも続いた反復スタイル
- 1990年代が進むにつれindie Mac game developerの時代は終わりに向かっているように見え、Californiaへ行ってAppleで働かないかという提案を受けて承諾した
- Apple入社後は、余暇時間にApple以外のプロジェクトをしてはいけないと理解していた
- 厳密には、業務外コーディングをするには管理者の書面による許可が必要だった
- Appleはゲーム事業をしていなかったので許可を得られた可能性もあったが、申請して却下される可能性が気がかりだった
- ゲームではない業務プロジェクトでも、高速プロトタイピングのやり方は続いた
- 他の同僚たちはホワイトボードで設計を繰り返し、コードを書く前に慎重に計画していた
- 自分はまず飛び込んでコンパイルしながら反復するやり方を好んだ
- 素早くコードを組み上げてボトルネックを早く見つけ、必要ならプロジェクトをほぼ最初からやり直す、という進め方が繰り返された
- プロジェクトを3回ほど始めてはやり直した後でも、慎重に設計していた同僚たちがコードを動かし始めるのとほぼ同じ時期に、十分によい状態へ到達することがよくあった
- 最終的なコードリビジョンはたいてい単純化であり、最初からコードを大きく変えられる状態として扱うことで、どう整理すべきかの感覚を得ていた
- Bloom Filterを勧める同僚に対し、実データが小さすぎて性能向上がほとんどなく、コードベースの複雑さだけを増やしたので、すでに捨てたと答えられた経験もあった
Always Be Iterating
- 退職が近づくころには、Appleで貢献する社員であり同僚でもあったと感じられるようになった
- 1人で夜通しコーディングしていた時代と違い、一緒に働いたエンジニアたちこそがApple勤務で最も良かった部分だった
- 一緒に働いた人の中には、自分より桁違いに優れたプログラマもいた
- 自分は最も速いプログラマの1人だったという感覚があり、その週の会議デモ用プロトタイプが必要なら、2つのバージョンを作れるような人間に近かった
- 娘たちに繰り返し伝えていた言葉は**A.B.I.**だった
- “Always”
- “Be”
- “Iterating”
- つまり“Always Be Iterating”
- 発売されなかったゲームのプロジェクト、ソース、ツールはディスクイメージとして整理され、GitHubで公開されている
- Volume 3も予定されているが、各プロジェクトを“release”可能な状態に整える作業があるため、公開時期は約束されていない
1件のコメント
Hacker Newsのコメント
1989年ごろにプログラミングを始めて以来、放置したプロジェクトが少なくとも十数個、多ければ百個ほどあり、そのほとんどがゲーム。大半はMac PlusやMac LC向けに作っていて、記事に出てきたものと似たメカニクスやアートスタイルのものも多かった
リリースしたり参加したりした数少ないプロジェクトは、自分という人間の影のように感じる。履歴書や職歴も同じだ。初期に成功を積み上げる機会がなかったせいで実現しなかった、夢見た人生を生きるはずだった完全な存在の指紋のようなものだ。だからベーシックインカムは人間の潜在能力を10倍、100倍に高め、サービス経済から主体性と自己実現へ移行させ、それぞれが余剰所得を生み出せるようにしてくれると思う。あと、Pararenaも本当によく遊んだ
あなたの周囲では違ったのかもしれないし、あなたの国ではそういうやり方をしていなかったのかもしれない。複数のゲームに取り組むことと、ひとつに集中して仕上げることの違いは何なのか気になる。ベーシックインカムがあれば、完成したプロジェクトが出てくるほど、しかも一時的ではなく継続的にこういうことができるのだろうか。親になる時期や幼少期のような人生のある段階ではベーシックインカムは理にかなっているが、自分を見つけていく時期には責任が役に立つと思う
こういう考え方は本当に理解しがたい。魔法のようなベーシックインカムは、働かない大衆のための最低賃金になるはずだが、それがどうして持続可能で、しかも良いものになり得るのだろう
理論上はきちんと完成させる選択肢もあったが、そうしようとすれば組織は破産していただろうから、あくまで理論上の選択肢にすぎなかった。仕事で使い、私生活でもやむなく使っているソフトウェアの状態を見ると、周囲のみんなも同じような人生を送っているように思える。幸いユーザーには選択肢がないので、ひどいものを買うか、何も買わないかのどちらかだ。私たちはひどいものを売っても安全でいられる
私が働いてきた多くの会社はこんなふうに回っている。エンジニアは目新しくて派手な新機能を作り、それがリリースされ、みんなが喜ぶ。数か月後にはバグが山ほどたまる
元の開発者たちはすでに別のチームへ移っている。建前は「サイロを壊す」だが、実際には「誰でも置き換え可能にする」に近い。プロジェクトを引き継いだエンジニアは、また別のチームに渡されるまで保守とバグ修正をしなければならない。ひどい話だ
しかも「最低限実用可能」は「実用不可能」から一歩離れているだけだ。すべてのプロジェクトがイカロスのようになり、翼が溶ける前に太陽へどれだけ近づけるかを試すことになる
[1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
引き継いだ人たちは意思決定をする資格に欠けており、私の大きな構想は脇へ追いやられ、その機能をめぐる無能ぶりを見せつけられるのは耐えがたかったし、今でもくだらないバグが出るたびに腹が立つ。十分に調整する時間があるときに警告していたのに、そうなったのだからなおさらだ。それでも重要な教訓は得たし、次は頑固な人に見えたとしても引き下がらずに戦うと断言できる
インディー開発者にはよく合うし、ある程度は大企業にも適用できる。この哲学は、意味のある時間を費やすに値する機能や製品を見極めるのに向いている。むしろ、あなたが描写した状況は、元記事が提案するやり方に従わなかった直接の結果だとさえ言える
最近はレトロ開発に戻って作業している。最初にプログラミングを覚えた 68K Macintosh 向けのソフトウェアを作っている
古い本や comp.sys.mac.programmer の投稿、Soft Dorothy や GliderPro のようなソースコードをたくさん掘り返した。古いコードを新しい目で見るのは不思議な体験だ。昔の Mac がなぜあれほど頻繁に落ちていたのか、単に「メモリ保護がなかったから」という説明以上の理由も見えてくる。筆者が言っていたように1ビットアートも好きで、1ビットアートを投稿する Twitter アカウントのリストを管理している。抜けている人がいたら教えてほしい: https://twitter.com/i/lists/1578111923324944397
制約のあるシステム向けにプログラミングする良さは、選択肢を絞ってくれることだ。適切なライブラリさえ引っ張ってくれば何でもできる現代的な体験から離れる、よい休息になる。ときどき計算能力が凍りつき、よく理解されたシステム向けのソフトウェアだけがますます良くなっていく世界を想像する。Mac 68K のような古いシステムでは、ハードウェアの進歩があまりに速くて目が回るほどだった。68020 や 80386 のような新しいプロセッサが出ると、その潜在力をきちんと生かす何かを作る時間はせいぜい数年しかなかった。遅れすぎると、新しいハードウェア世代向けの新しいソフトウェアと競争しなければならなかった
Handle などを扱うラッパー関数も作りたくなる。それでも言ったとおり、現代のオペレーティングシステムと比べると Toolbox がどれほど単純だったかには驚かされる。こうしてまたレトロ開発をやってみるのは本当に楽しい
ブログ全体がすばらしい。見て回る価値のある興味深い内容がたくさんある
何かを捨ててもかまわないし、捨てたプロジェクトからでも学べるし、一部は再利用できる。自分にとって突破口になった瞬間は、終えられるくらい小さく作ると決めたときだった。終わらせる技術を育てる助けになったし、これは別個の技術で、身につけるのが難しい。あまりに長くて大変なプロセスの終わりにしか起きないから、そこまでたどり着けることがほとんどないためだ。ビデオゲームを作る自分の友人たちは皆、自分のエンジンを書くところから始めて、レベルエディタを作る頃には燃え尽きてしまう。ツール作りのようなことで多くを学ぶけれど、皮肉なことにそれはすでにできることに近く、肝心のゲームは作れない。大聖堂を建てながら石工の技術を学ぶようなもので、終わりを見ることはないだろう。失敗しようがないほど小さく始めて、そこから少しずつ大きなプロジェクトへ進むべきだ
今 Unity のプロジェクトを進めているが、RTS スタイルの建物配置システムをどう作るのが最善か考えて苦労していた。いつものように飛び込む代わりに、プレイヤーが建物を配置する必要自体がなくなるようにゲームコンセプトを変えることにした。試してみると、自分が作ろうとしていたものにはむしろそのほうが良いユーザー体験だった。最初は「次の反復で建物システムを追加しよう」と自分に言い聞かせていたが、今ではたぶんやらないと思う
削ることはほとんどいつもより良い。小さな出発点を本当に完成させることは、次の反復のためのニトロメタンのようなものだ。100% まで到達してこそ次の番がずっと良くなる。80% で止まると、また岩を丘の上まで押し戻さなければならない感覚しか残らない
アクセシビリティの仕事をするようになってから、その多くを取り出して、アクセシブルに作り直した。かなり古い Bootstrap のバージョンを使っているものもあったので、最新の Bootstrap へのアップグレード作業も一緒に行った。古いデザインをアクセシブルに修正するだけでも本当に多くを学んだ。サイトやアプリケーションを評価するときに何を見るべきかについて、はるかに良い視点を得られたと感じている。自分が作っていたものがどれほどアクセシビリティに欠けていたかに気づくきっかけにもなった
John のゲームは、子どもの頃に Mac で初めてプログラミングを学んでいた自分にとってインスピレーションだった。Glider をたくさん遊んだし、Pararena はもっと遊んだ。あの響くような起動サンプルはいまでも頭に焼き付いている
ResEdit でそれらのゲームのリソースフォークをいじっていた時間のほうが、おそらくずっと長かっただろう。たくさんは終えられなかったが、小さなシェアウェアゲームをいくつか完成させて AOL に載せた。数か月後、遠いカリフォルニアから小切手が郵便受けに届いたときは本当に驚いた
初期の Mac 時代は本当に特別な時間で、一人の開発者でも創造力と時間さえあれば何かを作って世に出せるという感覚があった。こういう文章を書いて思い出の中に送り返してくれてありがとう。引退生活を楽しんでいることを願っている
初期のコンピュータユーザーであり初期の開発者でもあった私たちにとって、すべてが新しかったから特別だったのだろうか？ それとも、あの頃の空気には何か違うものがあったのだろうか。私が作った小さなゲームを気に入ってくれてうれしい。カリフォルニアから届いたあの小切手が、今のあなたのキャリアが何であれ、その道へ押し出すきっかけになったのかもしれないとも思う
この記事の目標がプロジェクトを捨てることを普通のことにすることだとしたら、それが良い考えなのかはよく分からない。他のことを全部脇に置いても、とてつもない時間の無駄になり得るし、「それでも学んだことはある」という言葉だけでは正当化できない。終わらせるにしても学ぶべきではないのか
誰もやったことのないことなので、進めながらやり方を探り、途中でかなり多くのミスもしている。動画で強調されている点の一つは、こういうことが起きたときにチームがただ止まって同じことをもう一度やり直したりしないということだ。進められるだけ進めて完全に壊し、材料を思う存分実験する機会にする。
彼はこれがどれほど素晴らしいかを長く語っている。完成され磨き上げられた製品を作る道筋に乗っていたなら試さなかったことを自由に試せるので、扱っている材料の振る舞いをより深く学べるまたとない機会を活用しているのだ。すでにゴミになってしまったものをこれ以上ひどく壊すのは難しいので、これ以上リスクを取るとも言いにくい。
成功だけを重視するのではなく、学習と実験を重視する考え方が、自分の仕事で本当に卓越するための最良の方法の一つだという指摘はその通りだと思う
ChatGPTは「素早く作れ、そして決して公開するな。公開するときまでは」と要約していた
ときどき、どこにも進まないプロジェクトにしがみついて、十分に努力すればどこかへ行けるはずだと思ってしまうが、楽しくもなく新しく学ぶこともない状態になる。「終わらせなきゃ、終わらせなきゃ」と自分を追い込んで、「なぜ？」と自問すると、たいていは終えられないことへの恐れのためか、あるいはつらい時期と失敗したプロジェクトの時期を区別できないのではないかと怖れているからだ。どちらにせよ、失敗したときに解放感を覚えたことがあまりにも多い。やり直す機会になる
スクリーンショットのピクセルアートのいくつかは本当にすばらしい
個人的には、小さなものを公開してから反復するか捨てるかしたほうが、ずっと多くを学べたし稼げた
このやり方は気に入っているし面白いが、組織レベルではもっと難しそうに見える。私たちがプロジェクトや技術について発見することの多くは、実際のプロジェクトが動く規模での実現可能性に関わっていて、小さな実験では必ずしも表れない。
ときには技術的な問題ではなく、「ここにいる大半の開発者にこのやり方を理解してもらえるか」のような問題だったりもする。だからといって、こうした試みをもっと減らすべきだという意味ではない。小さなプロジェクトを試しながら学べることはある。ただし、大規模でも機能する保証はない
私の問題は単純に時間だ。仕事を終えて家に帰ると、コンピューターの前に座るのがいちばん嫌だ。
週に二日の休みも家事で埋まってしまうので、それでもやはりコンピューター画面の前には座りたくない
あなたのようにできる人がうらやましい。今の業界は、技術とプログラミングを人生のすべてにしている人だけを求めるカルトのように感じる。要求そのものが嫌だというわけではないし、職業倫理もあるし、うまくやりたいとも思っているが、期待値はかつてなく高く見える。
画面を見なくてもいい趣味を持てるくらいの職業安定性が得られることを願っている。近いうちに金属加工をやってみたい