Fellow Traveller が主催した Story-Rich Showcase、X のタイムラインで流れてきて気になって見た。20本以上のナラティブゲームを一気に発表するイベントで、インディーゲーム好きとしてはそれだけで普通に楽しい。ただエンジニアとして見ると、ちょっと別の角度でハマるポイントがあった。
Ambrosia Sky というゲームの話が刺さった。もともと3エピソード構成で作っていたのに、3月に「2エピソードで終わりにします」とアナウンスして、8月6日に第2話を無料アップデートで出す。価格も $14.99 から $24.99 に上げる。こういう情報を読んでいると、「ゲームの設計変更ってソフトウェアのスコープ変更とまったく同じ構造だな」と思う。
自分が今個人開発で作ってる CLI ツールも、最初は3フェーズで機能追加する計画を立てていた。でも2フェーズ目を実装し終わったところで、「3フェーズ目って誰のためにあるんだっけ?」ってなった。Ambrosia Sky の開発チームも同じ判断をしたんだと思う。スコープを減らしてでも出したほうがいい、という決断。
問題はその判断をどこでするか、だ。自分の場合、フェーズ定義を README の `## Roadmap` に書いていたせいで、削除するたびに「約束を破っている」感覚が出る。最初から issue や milestone で管理して、公開ロードマップにしないほうがよかった。Ambrosia Sky が3月にアナウンスしたのは、おそらくそういうコミュニケーション設計の失敗を後追いで修正したかたちだと思う。
Citizen Sleeper と Citizen Sleeper 2 が Switch 2 対応版を6月25日に出す、という話も面白い。既存の Switch 版を持っているユーザーは追加料金なしでプレイできる、と書いてある。これ、ライセンスモデルの話で、SaaS だと「既存プランユーザーに新機能を無料開放するか有料にするか」の判断と同じ構造だ。
Demonschool の Switch 2 対応の説明では「マウスサポートとフレームレート改善」とある。これ、単純にビルドターゲットを増やしただけじゃなくて、入力デバイスの抽象化を後からやった、ということだ。最初の設計で入力レイヤーを分離していなかったら、えぐい工数になるはず。自分が Electron で作ったツールを Web に移植しようとしたときに同じ目に遭った。イベントハンドラが node の API にベタ依存していて、全部書き直すことになった。
あのとき素直に adapter パターンを挟んでおけば、こういうことにはならなかった:
ゲームの「プラットフォーム対応」って、エンジニア的には「抽象化レイヤーを最初に入れたかどうか」の話なんだよな、と改めて思った。後から足すのは本当に苦しい。
Desktop Explorer というホラーパズルゲームは7月17日リリース、Demonschool の DLC は「今年中」と濁している。この違いも実務的に読める。確定できる理由が揃っているものは日付を出して、そうじゃないものは「今年中」で逃げる。自分もライブラリの release note に「next minor で対応します」と書いて3ヶ月放置したことがある。ユーザーからそっとクローズされた issue が今でも心に刺さっている。
日付を出せるかどうかの判断軸は、自分の中では「QA フェーズが終わっているか」だ。コードが書けている状態と、リリースできる状態は別物だ。インディーゲームも同じで、ゲームが動くことと、ストアに出せることはたぶん別のフローがある。
今回の Showcase 全体を見ると、Fellow Traveller は 20本以上のゲームを一度に発表している。パブリッシャーとして「まとめて可視化する」イベントを作ることで、個々のゲームのマーケティングコストを分散させている。自分も個人開発のアウトプットを月イチでまとめて Zenn に投稿する習慣をつけようとしているのは、同じ発想だ。一本一本バラバラに出すより、まとまりとして見せたほうが反応が来やすい。
ナラティブゲームの話を読んでいたのに、最終的に自分のリリース管理の見直しが頭に浮かんだ。そういう読み方しかできないのは職業病だと思う。とりあえず今夜は CLI ツールの CHANGELOG を書き直す。
エピソードリリースのキャンセルって、設計の失敗じゃないのか
Ambrosia Sky というゲームの話が刺さった。もともと3エピソード構成で作っていたのに、3月に「2エピソードで終わりにします」とアナウンスして、8月6日に第2話を無料アップデートで出す。価格も $14.99 から $24.99 に上げる。こういう情報を読んでいると、「ゲームの設計変更ってソフトウェアのスコープ変更とまったく同じ構造だな」と思う。
自分が今個人開発で作ってる CLI ツールも、最初は3フェーズで機能追加する計画を立てていた。でも2フェーズ目を実装し終わったところで、「3フェーズ目って誰のためにあるんだっけ?」ってなった。Ambrosia Sky の開発チームも同じ判断をしたんだと思う。スコープを減らしてでも出したほうがいい、という決断。
問題はその判断をどこでするか、だ。自分の場合、フェーズ定義を README の `## Roadmap` に書いていたせいで、削除するたびに「約束を破っている」感覚が出る。最初から issue や milestone で管理して、公開ロードマップにしないほうがよかった。Ambrosia Sky が3月にアナウンスしたのは、おそらくそういうコミュニケーション設計の失敗を後追いで修正したかたちだと思う。
Switch 2 対応という「プラットフォーム追加」の工数感覚
Citizen Sleeper と Citizen Sleeper 2 が Switch 2 対応版を6月25日に出す、という話も面白い。既存の Switch 版を持っているユーザーは追加料金なしでプレイできる、と書いてある。これ、ライセンスモデルの話で、SaaS だと「既存プランユーザーに新機能を無料開放するか有料にするか」の判断と同じ構造だ。
Demonschool の Switch 2 対応の説明では「マウスサポートとフレームレート改善」とある。これ、単純にビルドターゲットを増やしただけじゃなくて、入力デバイスの抽象化を後からやった、ということだ。最初の設計で入力レイヤーを分離していなかったら、えぐい工数になるはず。自分が Electron で作ったツールを Web に移植しようとしたときに同じ目に遭った。イベントハンドラが node の API にベタ依存していて、全部書き直すことになった。
あのとき素直に adapter パターンを挟んでおけば、こういうことにはならなかった:
# 悪い例: platform 直叩き
fs.readFileSync('/tmp/config.json')
# 良い例: storage abstraction を挟む
const config = await storage.get('config')ゲームの「プラットフォーム対応」って、エンジニア的には「抽象化レイヤーを最初に入れたかどうか」の話なんだよな、と改めて思った。後から足すのは本当に苦しい。
ナラティブゲームのリリース戦略と個人開発のリリース戦略は似ている
Desktop Explorer というホラーパズルゲームは7月17日リリース、Demonschool の DLC は「今年中」と濁している。この違いも実務的に読める。確定できる理由が揃っているものは日付を出して、そうじゃないものは「今年中」で逃げる。自分もライブラリの release note に「next minor で対応します」と書いて3ヶ月放置したことがある。ユーザーからそっとクローズされた issue が今でも心に刺さっている。
日付を出せるかどうかの判断軸は、自分の中では「QA フェーズが終わっているか」だ。コードが書けている状態と、リリースできる状態は別物だ。インディーゲームも同じで、ゲームが動くことと、ストアに出せることはたぶん別のフローがある。
今回の Showcase 全体を見ると、Fellow Traveller は 20本以上のゲームを一度に発表している。パブリッシャーとして「まとめて可視化する」イベントを作ることで、個々のゲームのマーケティングコストを分散させている。自分も個人開発のアウトプットを月イチでまとめて Zenn に投稿する習慣をつけようとしているのは、同じ発想だ。一本一本バラバラに出すより、まとまりとして見せたほうが反応が来やすい。
ナラティブゲームの話を読んでいたのに、最終的に自分のリリース管理の見直しが頭に浮かんだ。そういう読み方しかできないのは職業病だと思う。とりあえず今夜は CLI ツールの CHANGELOG を書き直す。