金代の商人・孔微尼(こんびに)

# 民明書房風解説文生成プロンプト

## 1. 代表的な例
「この技の創始者 宋家二代 呉 竜府(ご りゅうふ)は、正確無比の打球で敵をことごとく倒したという。この現代でいうゴルフスイングにも酷似した打撃法は、運動力学的観点からいっても弾の飛距離・威力・正確さを得るために最も効果的であることが証明されている。ちなみにゴルフは英国発祥というのが定説であったが、最近では前出の創始者 呉 竜府の名前でもわかるとおり、中国がその起源であるという説が支配的である。」
民明書房刊「スポーツ起源異聞」より

## 2. 「民明書房」の基本情報
### 基本設定
- 漫画「魁!!男塾」に登場する架空の出版社
- 1926年(大正15年/昭和元年)創業
- 創業者は大河内民明丸
- 中国の武術書などを専門的に出版

### 特徴的な解説手法
- 写実的な絵や学術的な解説
- 現実感あふれる語り口
- 荒唐無稽な内容を学術的に説明
- 実在の事象と架空の説明を絶妙に組み合わせる

### 作中での位置づけ
- 紹介される技や拳法は作中世界では実在する
- 一般人には信用されていないが、男塾関係者には重要な文献として扱われる

## 3. 解説文作成の要素

### 1. 核となる要素
- 現代の一般的なカタカナ外来語(ターゲット語)を1つ選択
- その外来語に音が近い漢字名(人名や技名)を作成
- 漢字の音読みからターゲット語への自然な音の変遷が説明できること

### 2. 歴史的背景
- 中国の特定の時代設定(例:唐、宋、明、清など)
- 具体的な地名の使用
- その時代における社会的背景との整合性

### 3. 説得力のある詳細
- 人物の肩書きや役職
- 具体的なエピソード
- 技法や道具の詳細な説明
- 数値や段階などの具体的な記述

### 4. 伝播の説明
- 発祥地から他地域への広がり
- 意味や用法の変遷過程
- 異なる文化圏での解釈の変化

### 5. 学術的な体裁
- 書籍名の明記(「〜録」「〜秘伝」「〜全書」など)
- 民明書房からの引用という形式
- 専門用語や漢語の適切な使用
- 「運動力学的観点」のような科学的装いの付与

### 6. 文体のルール
- 終盤で現代のカタカナ語との繋がりを明かす
- 「〜という説が支配的である」といった断定を避ける表現の使用
- 荒唐無稽でありながら、一定の説得力を持つ論理展開
- 既存の定説を否定してから新説を展開する手法

## 4. 注意点
- 選択するカタカナ語は、日本で日常に使われる一般的な外来語であること
- 音の同一性を最も重視すること
- 現代の用法や意味に沿った歴史的背景を作ること
- 既存の定説を覆すような驚きの展開を含めること
- 一見すると学術的に思える説明を加えること

このプロンプトに従って、架空の歴史的解説を生成してください。生成の際は、まず使用するカタカナ外来語を明示し、その後で解説文を作成してください。

Claude 3.5 Sonnetによる生成例:

「金代の商人・孔微尼(こんびに)は、『商道奇書』によれば、驚異的な商才で「百刻商店」という革新的な商売法を確立したことで知られる。開封の繁華街で活動した孔微尼は、人間の生命力には100刻(現代の時間で約24時間)周期の波があることを発見。この原理を応用し、昼夜を問わず営業する特殊な商法を開発したという。

特筆すべきは「百刻陳列法」と呼ばれる商品配置術である。店内の気の流れを完全に制御し、顧客の購買意欲を最大限に高める秘術とされた。さらに、「八門金鎖陣」という独特の店舗配置により、一度入店した客は不思議と必要以上の商品を購入してしまうという。この技は『商術秘伝』において「入店せし者、財布の紐、自ずと解く」と評されている。

最も恐るべきは「生気吸収術」である。孔微尼は昼夜営業による店員の疲労を解決するため、客の生気を吸収して店員に分配する禁断の技を編み出した。これにより店員は不眠不休で働き続けることが可能になったという。現代の『コンビニ』の語源は、実はこの「孔微尼」の名に由来するという説が、近年の商業人類学で注目を集めている。特に、コンビニ店員が不可思議な体力で深夜勤務を続けられる現象は、生気吸収術の影響ではないかと指摘されているのである。」

民明書房刊「商道奇術考」より


「宋代の拷問官・郃烙歌(からおか)は、『刑罰奇書』によれば、囚人から最も効率的に自白を引き出す手法として「声刑術」を確立したことで知られる。開封の裁判所に仕えた郃烙歌は、人間の声帯から発せられる特定の周波数が、聴覚器官に耐え難い苦痛を与えることを発見。この原理を用いて、囚人に強制的に特殊な音程で歌を歌わせ続ける拷問法を開発したという。

特筆すべきは「烙歌十八声」と呼ばれる特殊な音程体系である。囚人は定められた音程で歌い続けることを強要され、外れた場合は背後の処刑人から即座に体罰が加えられた。さらに、複数の囚人に異なる音程を割り当てて同時に歌わせる「群声拷問」は、その凄惨な光景から「地獄の合唱」とも呼ばれ、最も恐れられた刑罰の一つとされる。

驚くべきことに、郃烙歌は罰として歌わせる楽曲を厳密に記録。「烙歌音律集」として編纂された曲目は、後に娯楽として密かに歌われるようになったという。現代の『カラオケ』の語源は、実はこの「郃烙歌」の名に由来するという説が、近年の音楽人類学で注目を集めている。特に、カラオケで不調和な音程で歌う者が周囲から制裁を受けるという習慣は、烙歌十八声の残滓ではないかと指摘されているのである。」

民明書房刊「刑罰文化史考」より


「金代の護身術の達人・孫澎支(そんぽんじ)は、人体の柔軟性を極限まで高める秘技「軟体功」を編み出したことで知られる。『柔体秘伝』によれば、孫澎支は幼少期に暗殺者に襲われた際、偶然にも体を極限まで柔らかくすることで致命傷を回避。この体験を基に、人体を自在に伸縮させる特殊な呼吸法と筋肉の操作法を確立したという。

特筆すべきは、孫澎支が開発した「澎支圧縮法」である。これは体内の気を操り、一時的に体積を十分の一まで圧縮した後、瞬時に元の大きさに戻すことで、相手の攻撃を無効化する驚異的な技である。さらに、圧縮時に蓄えた反動を利用して、「弾腰拳」という特殊な打撃を繰り出すことも可能だったという。

孫澎支は晩年、自身の肉体を研究材料として科学者たちに提供。その際に記録された「人体圧縮復元実験」の詳細な記録は、後に西方に伝わり、弾力性を持つ新素材開発の着想となった。現代の『スポンジ』という言葉は、実は「孫澎支」の名に由来するという説が、近年の材料工学研究において注目を集めている。特に、スポンジの圧縮復元特性が、澎支圧縮法の記録と酷似している点は、両者の歴史的連関を強く示唆しているのである。」

民明書房刊「奇術秘伝考」より


「古来より伝わる『労役秘録』によれば、宋代の商業都市開封で活躍した商人、阿爾巴伊徒(あるばいと)は、短期労役の効率的な運用法を確立したとされる。阿爾氏は、繁忙期に応じて労働力を柔軟に配置する「阿爾八役法」を編み出し、これにより商業活動の大幅な効率化を実現した。この手法は、労働者の技能を八段階に分類し、必要に応じて適材適所に配置するという画期的なものであった。

後に明代の経済学者・王明徳によって体系化された「阿爾八役法」は、季節や時間帯による労働需要の変動に対応する革新的システムとして評価され、シルクロード経由でヨーロッパにまで伝播したという。ドイツ語のArbeitの語源は、実はこの阿爾巴伊徒の名に由来するという説が、近年の出土資料により有力視されている。

なお、現代の『アルバイト』という言葉は、この阿爾八役法が日本に伝来し、語源となった阿爾巴伊徒の名前がドイツ語経由で再び日本に入ってきたものである。労働力の柔軟な運用という本質は、千年の時を超えて現代に継承されているのである。」

民明書房刊「東亜商業文化史論」より

時流に負けてBlueskyアカウントを作る

Twitterでいつか英語アカウントを作りたいなと思ったまま作ってなかったのでBlueskyで作ることにした。英語アカウントだとそもそもタイムラインが違いすぎるので、体験がXと比較できない。

Bluesky CEOのJay Graberによると、Blueskyには現在2000万人以上のユーザーがおり、1日100万人以上のペースで増加中だそうだ。プロモーションに影響されないカスタムアルゴリズムによるフィード機能などがBlueskyの強みだ。

ただ将来的にBlueskyが収益化を目指す段階になった時に、フィードアルゴリズムが広告表示に向けた最適化などでゆがめられる可能性はある。今後ユーザー数が伸びていった時に、今の強みがそのまま残るかどうかは現時点では分からない。

Blueskyが現在の分散型プロトコルであるAT Protocolを使い続けてくれるのであれば、サードパーティクライアントなどでユーザ側でタイムライン制御が継続できるかもしれない。プロトコルを変えるのはユーザーの反発も大きそうだしやらないと思うけど、確信は持てない。

現状Blueskyのユーザー数はXには遠く及ばないので、Xから移行する必要性はそれほどない。でもこの機にX以外のテキストベースSNS体験をしておくのも悪くないかもしれない。

私の心を揺さぶったプログラミング言語

'Programming Languages That Blew My Mind'というブログ記事で、8歳からプログラマーとして活動しているDavid Tellerさんが、人生で出会った革新的なプログラミング言語について紹介している。

BASIC

A language designed to make programming simple.

  • Mind blown: Programming my own games!
  • Mind blown: Arrays (or DIM, as they were called)!
  • Mind blown: GOTO!
  • Mind blown: GOSUB!

Original, line-based, Basic is dead, but its legacy lives on in VB.Net, VBA, but also in more subtle manners in today’s dynamic languages (Python, JavaScript, etc.)

  • 初めて自分でゲームをプログラミングできた感動
  • 配列やGOTO、GOSUBなどの基本概念との出会い
  • 現代の動的言語PythonJavaScriptなど)にその遺産が生きている

という点がBASICの良さとして挙げられている。

私もプログラミングの入り口は、BASICでのゲームプログラミングだったので、その感動はよく分かる。ただ初めて出会った唯一知っている言語だったので、プログラミング言語としての感動があったかと言われると、そこはよく分からない。行番号やGOTO、GOSUBなどのBASICとして特徴的な機能も、プログラムにはそういったものがあって当たり前だと思っていたし、それこそ関数とかいう概念が頭の中にないので、GOTOがあるのになんで元の場所に戻るGOSUBという命令が別にあるんだろう、とか思っていた。

(Turbo) Pascal

  • Mind blown: A programming tutorial!
  • Mind blown: An IDE!
  • Mind blown: The compiler can actually help you find your errors!
  • Mind blown: A debugger that is actually useful!
  • Mind blown: Structured programming!
  • Mind blown: Units (aka “modules”)!
  • Mind blown: Object-Oriented Programming (although it wasn’t very useful in the libraries)!
  • Mind blown: A UI toolkit!
  • Mind blown: Dynamic memory allocation!
  • Mind blown: A community of developers (also, SWAGS)!
  • Mind blown: Memory overlays!

まともなIDEがあるプログラミング言語に初めて触ったのがTurbo Pascalなのも全く同じだ。BorlandのTurboシリーズは強力なIDEと高速なコンパイル時間が魅力で、BASICのラインエディタや実行時の簡略なエラーメッセージと比べて、格段の進化を感じた。

Pascal自体も近代的な構造化プログラミングを適切に教えてくれる良い言語だったが、Delphiで触れたオブジェクト指向的な部分はまだよく理解できなかった。あとブロックでいちいちbeginendを書くのが面倒、とかいう理由もあり、その後触れたTurbo Cの方を愛用していた。

x86 ASM

  • Mind blown: Memory addressing!
  • Mind blown: The stack is an illusion!
  • Mind blown: Interacting with the graphics adapter directly!
  • Mind blown: Interrupts!
  • Mind blown: Registers!
  • メモリアドレッシング、スタック、レジスタの概念
  • グラフィックアダプターとの直接的なやり取り
  • 割り込み処理の理解

x86アセンブラは私もPC-9801時代に扱っていた。が、私はその前にBASICの次の言語として、PC-6001Z80アセンブラを扱っていた。理由はBASICが遅かったから。マイコン時代のゲームプログラマアセンブラ機械語に手を出す理由のほとんどはパフォーマンスだろう。

PC-6001時代はハンドアセンブルで、アセンブラ機械語へ手作業で変換していた。16進数への変換やジャンプ先アドレスの計算をミスると、すぐにリセットがかかりプログラムが吹き飛ぶというスリリングな環境だ。今から考えるとよくそんな面倒なことをしていたなという感じだが、そのおかげで各命令の実行が何クロックかかり、どういう命令を使えば最短で処理ができるか、みたいなところを詳細に見ることができた。

アセンブラは、それ自身もレジスタの取り回しやx86のセグメントの扱いなどが難しいが、そこからアクセスする機種固有の仕組みにも難しいところがあった。主にグラフィックス周りで、PC-6001だとVRAMの制御、MSXだとVDPによるスプライト処理、PC-9801GDCやEGCなどのグラフィックスコントローラ制御など。この辺のハードウェア固有の仕組みを直に触れるのも、アセンブラの楽しいところであった。

Java

  • Mind blown: A standard library that felt like it contained everything I needed!
  • Mind blown: A documentation that was meant to be understood by its users!
  • Mind blown: The JVML!
  • Mind blown: A UX toolkit that was very simple to use (even if the results were disappointing)!
  • Mind blown: Synchronization as a language primitive (even if wasn’t necessarily a great idea)!
  • Mind blown: finally!
  • Mind blown: Just in Time compilation!
  • Mind blown backwards: Understanding how finally was implemented in the JVM.
  • 包括的な標準ライブラリ
  • わかりやすいドキュメント
  • JITコンパイル
  • 同期化のプリミティブ

私がオブジェクト指向をちゃんと学んだのはJavaからだった。当時は適切なインターフェースや継承の設計、カプセル化を行うことが分かりやすいコードを書く上で重要だった。関数型プログラミングへの潮流が高まっている最近のベストプラクティスとはだいぶ異なるが、分かりやすいクラス設計とは、みたいなことを色々考えるのは楽しかった。

JVMが実現するWrite Once, Run AnywhereもJavaの面白い特徴だ。一度書いたコードがそのままいろんな環境で動くのはとても画期的だった。ただ、ガラケーのような貧弱な環境までJavaでカバーしようとしてたのは、今考えると頑張りすぎのような気もする。バイトコードレベルでの最適化、コンパクト化を考えながらJavaのコードを書くのは、それはそれで面白かったが。

Prolog

  • Mind blown: Teaching the program how to think!
  • プログラムに「考え方を教える」という新しいアプローチ
  • SQLC++のテンプレートシステムに影響を与えた

Prologハノイの塔がやたら短くかける言語、というのが最初の印象だった。それを実現しているのは、命題の宣言的記述、単一化、バックトラックなどの他の言語にない特徴であり、その異質さがPrologの楽しさでもある。

Prologを語るうえではカット演算子(!)は外せない。カット演算子Prologのバックトラックを制御するためのもので、バックトラックで戻る選択肢を削除する。これはパフォーマンス改善のために導入されているものだが、うまく使わないとプログラムの挙動も変わってしまうという困りものだ。また、宣言的に書かれたプログラムに手続き的な観点が入ってしまい、理解がとても難しい。カット演算子は、理想と現実の狭間に生まれた演算子で、Prologの面白くも悩ましいポイントを表している。


著者は上記以外の言語として、HyperCard、(O)Caml、Coq、Erlang、The π-calculus、Opalang、Rustを挙げている。これらの言語は私はあまりなじみがない。私個人として追加するとしたら、Viscuit、ActionScript、TypeScriptかなあ。

Viscuit

レンズという仕組みで、現在の絵の状況を、どのような絵の状況に変化させるかを宣言するビジュアルプログラミング言語がViscuitだ。絵を2つ並べるだけでそれがコードになるという点がとてもユニークである。

Viscuitはある意味ビジュアルなPrologとも言えよう。視覚的なパターンマッチングを繰り返すことでアニメーションを実現するのがViscuitで、論理式の単一化で推論を実現するのがPrologだ。Viscuitは画面全体にルールを同時適用する並行処理、Prologはバックトラックを含む逐次処理という点は異なるが、どちらも宣言的なルール群がコードになっている点が共通点である。

ActionScript

私が触ったActionScriptはver.3.0で、ECMAScriptの流れを組む素直な言語だ。クラスの記述などJavaに似ているところも多く、言語として特筆すべき点はあまりない。

ActionScriptの特徴と言えば、言語が死んだことだ。正確にはその言語のターゲット環境であるFlash Playerが死んだ。他の言語でも外部環境の変化に応じてゆるやかに衰退していくことはよくあるが、ActionScriptは2020年のFlash Player配布終了に向けて急速に衰退した。

ActionScriptを今から使おうという人はいないと思う。ただその経験者の心の中に、Flashを使ったゲームやアニメーション制作のノウハウが残るのみである。

TypeScript

TypeScriptはオプショナルな型付けと型推論によりバグの早期発見と強力なコード補完を可能にした言語だ。トランスパイラとして機能し、書かれたコードをJavaScriptに変換する。JavaScriptが持つ弱点をそのまま引き継いでいるところはあるが、その辺に注意して使えば、柔軟性と堅牢性のバランスが取れたよい言語だ。

あるプログラミング言語により使いやすい糖衣構文などを加えて、トランスパイラで変換するというアプローチはCoffeeScriptで知った。当時はJavaScriptをターゲットとしたAltJSが多数開発されたが、TypeScriptが圧倒的な支持を得て主流となった。

追記

いくつか興味深いプログラミング言語を忘れていた。

Elm

ElmはWebUIのための純粋関数型言語である。WebUIというドメインに特化してシンプルに作られていたため、Haskellなどの他の関数型言語と比較して理解が容易だったように思える。

ElmはElmアーキテクチャと呼ばれるWebUI設計手法を取り入れていたのだが、それがver.0.16からver.0.17でガラッと変わったのも面白いポイントだった。0.16までで使われていた関数型リアクティブプログラミングは0.17で採用されなくなり、subscriptionに基づく手法に置き換わった。より直感的で使いやすい方法が見つかったので次からそれに乗り換えます、というのは通常の言語ではなかなかお目にかかれない。Elmのような、開発者個人の理念に基づいて設計が行われている言語ならではの特性である。

Befunge

Befungeはいわゆるesolangに含まれる、実用性を目指していないジョーク言語だが、その最大の特徴はコードが2次元のグリッド上に配置されることだ。プログラムカウンタも単に増加するのではなく、2次元上を上下左右に動く。グリッドの各キャラクタが命令を表していて、プログラムカウンタの方向を変える命令もある。

Befungeで実用コードを書く人はいないが、オーディオプログラミング言語というドメインにおいては、ORCAなどの実用的な2次元コード言語も存在する。

2次元コードのプログラムは、その実行時にプログラムカウンタが動き回る様子を見て取れるのが面白い。また2次元コードはビジュアル的にディスプレイ上で編集する場合に、狭い面積に多くの情報を詰め込みやすい。カルネージハートなどのプログラミングゲームにおいて採用されることがあるのは、そのような理由があるかもしれない。

Core War

前述のカルネージハート地球防衛軍II FAR SIDE MOON、HR2など、ゲーム内プログラミング言語はそのドメインがあまりにも特殊なため、言語自体もクセが強いものが多い。それらの中でもプログラミングというフィーチャーがむき出しになっているゲームと言えば、Core Warが挙げられるだろう。

Core Warでは、自分と敵の2種類のプログラムカウンタがメモリ上の機械語を実行しながら移動する。相手のプログラムカウンタに無効な命令を踏ませて全滅させれば勝ちだ。Core Warでは複数のプロセスを走らせることもできるが、プロセスが多くなればなるほど各プロセスの実行速度は低下する。これらの特性を考えながら、自らを守るために複製を作り、相手を探し出し倒すコードはどのようなものか、ということを考える必要がある。


他にもD言語C#Haxeなど愛用した言語は多々あるが、そのベースは他の言語に似ている、などの理由で今回は選ばなかった。あなたにとって「革新的!」「ヤバい!」と感じた、心のプログラミング言語は何ですか?

ワンボタンゲームを200個作ったのでそのうち111個を集めてミニゲーム集にした

いわゆるメイドインワリオ的な、短い時間で次々にワンボタンアクションミニゲームを遊ぶゲーム。成功数に応じて星がもらえて、新しいゲームをアンロックできる。HardやExpertにすると多くの星がもらえるがその分難しい。111個全てのアンロックを目指そう!

PCやスマホのブラウザからそのまま遊べるのでお気軽にどうぞ。 波長が合わないゲームは、アイコンをクリックして"Ban"すれば出現しなくなる。好みのミニゲームデッキにしよう!

ゲームのルールがよく分からんという時は、アイコンをクリックして"Play"すれば、そのゲームを時間無制限で遊べる。謎なルールのゲームにめげないで!


ともあれコツコツと作り溜めたワンボタンゲームが200個になった。

200個も作ると、入力がワンボタンに限られることを制約と考えることも無くなり、ワンボタンでもゲームとして成り立つような操作、動作、フィールド、リスク・リワードを自然と考えるようになる。上下左右キーで自機を操作という一般的なルールを封じられることで、自然とちょっと変わったゲームになるので、アイデア作成においては通常より楽な点もある。

ワンボタンゲームの操作に対する知見はそれなりに貯まったし、これら知見をLLMに与えてゲームの生成を補助させることもできたので、最近はちょっとルーチンワーク的に手癖で作っている感じもしないでもない。

それでも、ゲームを面白くするための、最後のパラメタやルールの調整は職人的な作業感があり楽しい。この辺のバランス感覚をつちかうところを大事にして、引き続きそれなりに作っていきたいところだ。

LLMを用いたガチャ指向ゲーム開発

自分の気に入るゲームが生成されるまでひたすらLLMを回す。これを仮にガチャ指向ゲーム開発と呼ぼう。

Claude 3.5 Sonnet のような高性能なLLMの登場で、LLMに簡単なゲームのアイデア作成からその実装までをさせることが可能になってきた。LLMから出てくるゲームの多くは、凡庸だったり、バランスが悪かったり、正しく実装できていなかったりする。でも、繰り返しLLMにゲームを生成させることで、面白い挙動をする、ゲーム一歩手前のコードを、稀に得ることができる。これを得るまでの行為がゲームガチャだ。

例えば、

上記のプロンプトに「fragile pillars」というテーマを与えると、以下のゲームを提案してくる。

Pillar Paraglider: Control a paraglider flying through a course of fragile pillars. The paraglider constantly descends. Press the button to ascend, but each press also sends a shockwave that can damage nearby pillars. Core mechanic: Balancing ascent with pillar preservation.


Pillar Paraglider: 壊れやすい柱のコースを飛行するパラグライダーを操縦します。パラグライダーは常に下降しています。ボタンを押すと上昇しますが、押すたびにショックウェーブが発生し、近くの柱にダメージを与える可能性があります。コアメカニズム:上昇と柱の保護のバランスを取ること。

このアイデアを詳細化し、実装させた結果、以下のゲームができた。これはClaudeの出力結果そのままである。

ボタンを押すと赤い自機が上昇し、同時に周囲に円状のショックウェーブを放つ。ショックウェーブは柱を破壊する。フラッピーバードの影響を受けすぎな感じはするが、挙動としてはなかなか面白いものが実装できている。

だが、このゲームには明らかにいくつかの問題がある。

  • 簡単すぎる。ボタンを連打していればショックウェーブで柱を無効化できる。自機が画面上端や下端に行っても何も起きないので、ほぼゲームオーバーにならない。
  • スコアリングシステムが安直である。単に進んだ距離がスコアになっているだけなので、リスキーな行動がスコアにつながったりしない。
  • 元々のコアメカニズムを実現していない。「上昇と柱の保護のバランスを取ること」とあるので、本来はショックウェーブで柱を壊さないようにするゲームにしたいのだろうが、そのように実装されていない。また、そのメカニズムを忠実に実装すると、当たり判定の大きい自機でプレイするようなストレスフルなゲームになる。

ガチャ指向ゲーム開発では、このように面白い挙動をする不完全なゲームを、どのようにしてゲームとしても面白いものに改良するか、このプロセスが重要となる。

今回のゲームでは、以下のように変更した。

  • 全方向に出る円状のショックウェーブは強すぎるので、自機に方向を付け、自機の前方向の限られた角度にのみショックウェーブが出るようにする。また、ショックウェーブは柱全体を破壊するのではなく、当たった部分のみを破壊する。また、自機が画面上端や下端に接触したらゲームオーバーとする。
  • 破壊した部分ごとにスコアを与える。また連続して破壊することで、スコアが増加するようにし、柱に向かって進むリスキーな行動で大きなスコアが得られるようにする。
  • コアメカニズムは無視する。「壊さないように」よりも「壊しまくる」ゲームの方が、一般的には楽しい。

その結果、ゲームは以下のようになった。

https://abagames.github.io/claude-one-button-game-creation/wavybird/screenshot.gif

柱にショックウェーブで穴を開けて進むゲームになった。若干難しすぎる感じはするが、最初のバージョンよりは、適切なリスクとリワードのバランスが実現できており、ゲームとしての完成度が上がっているだろう。

改良版とオリジナルのコード上の差異は以下の通りである。

こう見るとオリジナルのコードは跡形もなくなっているように見えるが、実際はオリジナルの枠組みを参考にして修正できるので、0から作るよりはだいぶ楽である。

音やタイトルを付けた完成版は以下になった。

これが現時点での、LLMを用いたガチャ指向ゲーム開発の実態である。果たしてこれが、人が普通にアイデアを考えて、それを実装するのと比べて楽か、と言われると、あまり楽では無い。ただ、LLMが提案してくるゲームを選別し、それをいかにして面白いゲームにするのか、というコンピュータからのお題に立ち向かうような開発プロセスは、従来の開発プロセスとは違った面白さがある。また、ゲーム開発と並行して、生成のためのプロンプト開発・改良を行う必要もあり、そこも合わせて楽しむことが、ガチャ指向ゲーム開発においては大切である。

将来的には何も考えずに「面白いゲームを作って」とLLMに言えば、いい感じのゲームが実装されて返ってくるようになるかもしれない。現時点だと、面白い挙動をするゲームを得るには数十回のガチャが必要とされるのが当たり前で、打率はかなり低いと言わざるを得ない。だが、以前のLLMではそもそも挙動として面白いものを返ってくることは皆無で、どこかで見たような凡庸なゲームしか出てこないことが当たり前であった。それがここ1年程度のLLMの進化によって、少なくともなにかの斬新さを感じられるものが生成されるようになったのは、良い兆候である。

LLMがこのまま進化を続ければ、出てくるアイデアの質が上がり、アイデアをコードとしてより正確に実装できるようになるだろう。また、上記で挙げたような問題点を指摘すると、それに応じてコードを修正できるかもしれない。そうすれば、より少ないガチャ回数と、より簡単な改良で、遊べるゲームが作れるようになるだろう。ガチャ指向ゲーム開発の今後の発展が楽しみである。

「お気に入りのビデオゲームを5つ挙げてください」

最近インタビューを受けたりプレゼンをしたりという機会がたまたま重なって、今までの自分のゲーム体験を振り返る機会が多くあった。

このインタビューでは、ポケコンから始まるマイコンとの出会い、ベーマガのゲームを打ち込んで遊んだ原体験、私から見た最近のインディーゲーム制作シーンを話した。

Tokyo Indiesのシューティングゲーム特集のプレゼンでは、今まで作ったシューティングゲームを元に、シューティングゲームのアイデアを考える方法の一案を話した。

2024年初頭に、1DパックマンPaku Pakuが海外圏で話題 になって、それをきっかけにmatt sephton さんからインタビューを受けた。ここでもマイコンベーマガ、あとはナムコアーケードゲームから受けた影響などを話した。

このインタビューでの質問の一つが「お気に入りのビデオゲームを5つ挙げてください」だった。これは答えるのが難しい。なにしろ今まで私が遊んだゲームの数は、数は、分からないが、たぶんたくさんだ。その中から5つを選ぶ。これは難しい。

なので何かの観点を置いて選ぶしかない。私は自分がゲームを作るに当たって影響を受けたゲーム、という切り口で以下を挙げた。

列車を中心とした運輸会社の経営シミュレーションゲームのトランスポートタイクーン。ライバル会社と競いつつ路線を拡張していく体験はこのゲームならではのもので、ゲームの中に世界が出来上がっている感覚を強く感じることができたゲームであった。今はオープンソース版のOpenTTD があるので、誰でも手軽に遊ぶことができる。

弾幕シューティングの元祖の一つとも言える怒首領蜂(初代)。特に大量の戦車と弾幕が押し寄せ、常に緊張感のある切り返しを要求される5面が好きで、この体験を自分でも再現したいというモチベーションがシューティングゲームを作るきっかけになった。

白と黒の属性を持つ自機と敵の組み合わせが、今までにないプレイフィールを実現したシューティングゲームである斑鳩。伝統的なジャンルであるシューティングゲームに新しいルールを持ち込むことで、これまでにない斬新で楽しいゲーム体験を生み出せるのだと実感した。

提督から毎ゲーム異なる報告を受けることで、ゲーム展開や世界地図がどんどん変わっていくシミュレーションゲームTHE ATLAS。ゲーム開発者本人ですらも予想できない展開を作り上げることができる、プロシージャル生成の技術に関心を持った。

ワイヤーフレームをベースとしたビジュアルと、BGMと連動して演奏しているかのように鳴る効果音が印象的な3DレールシューティングゲームRez。私のゲームでワイヤーフレームや、BGMと合わせてクォンタイズされた効果音を多用するようになったのは、Rezの影響が大きい。


自作ゲームへの影響、という観点で選んでも、5つは少ない。前述のナムコのゲームの数々や、ゲーム&ウォッチなどのより原体験に近いゲームなどは挙げきることがとてもできない。それでも強引に5つ選んでみると、今の自分を形成したゲーム体験のコアを抽出することができて面白い。

他の観点で選ぶ方法もある。

普遍的な面白さがある、つまり今遊んでもその面白さが変わらないという観点だと、私個人としてはこの5つ。ほかにもビジュアル、オーディオ、シナリオなどの観点で5つ挙げてみるのも面白いと思う。自分がゲームのどこに惹かれているのかということが、5つのベストゲームを選ぶプロセスを通じて分かるかもしれない。

「撃って」「○○する」ゲーム それがシューティングゲーム

4/17にTokyo Indiesでシューティングゲーム (STG)のアイデアを考える話をした。

プレゼンのスライドは以下の通り。でもほとんど口頭で話したので、このスライドだけ見ても何の話か分からない。なのでその補足を書こうと思う。

「撃って」「敵を倒す」ゲーム、それがSTG。当たり前である。でも本当にそれだけだろうか。

例えば「撃って」「四角を作る」ゲーム。これは何か。

画面上から迫る謎のブロックにブロックを発射して、四角にして消すゲーム、クォースである。でははたしてクォースSTGか。本家が「シューティング・パズルゲーム」と言っているので、STGであろう。ならば「〇〇する」は「敵を倒す」でなくてもSTGであるはずだ。

そういえば、私は今までいろんな「〇〇する」STGを作ってきた。

敵を倒すとその敵が落ちてくるのでそれを自機で拾う。するとその敵が自機にくっつき、敵に反撃を始める。どんどん敵をくっつけていくと、最終的に自機がボスよりも大きくなって、とんでもない火力で敵を圧倒できる。「くっつける」というアイデアSTGに取り入れることで、ちょっと変わったSTGになった。塊魂スカイキッドでもある。

  • 「撃って」「敵を落とす」ゲーム、Mu-cade

ムカデ状の自機と敵がいて、自機のショットを当てて敵を吹き飛し、ゲームフィールドから押し出して落として倒す。当時はまだ目新しかった物理エンジンSTGに取り入れた。


このように「〇〇する」を「敵を倒す」から別の内容に変えることで、ちょっと新しいSTGを作ることができる。「〇〇する」に何が入るかを考える、というのが、ゲームのルールやギミック、メカニクスを考える上での補助線になる。


ゲームフィールドにはライフゲームと、そのセル上を移動する敵がいる。自機はグライダーと呼ばれる、斜め方向に飛ぶライフゲームのパターンを発射し、それがフィールドのライフゲームに当たるとそこからセルの色を変えて汚染していく。ボタンを放すとその汚染されたセルと、そのセルの上にいる敵を破壊する。ライフゲームSTGの組み合わせだ。

  • 「撃って」「同色を貫く」ゲーム、COLOR ROLL

色分けされたバーが左右に移動しているので、色が揃った瞬間に撃つ。色を揃えるレイディアントシルバーガンや、ガンフロンティアのラスボスの回転遮蔽壁の隙間狙いあたりが発想元だ。

横向きの爆弾に当てると横方向に、縦向きの爆弾に当てると縦向きに誘爆する。なるべく多くの爆弾を巻き込みつつ、縦方向から自機の方に飛んでくる爆風をうまく避ける。

  • 「撃って」「崩す」ゲーム、RAID

自機は高層ビル群に向かって降下していて、そのままだとビルに当たる。ビルの中腹を狙ってに爆弾を斜めから当てると、ビルを崩すことができる。

  • 「撃って」「戻ってきてやられる」ゲーム、HAVE IT COMING

自機のショットで上空の敵を倒せるが、ショットはそのまま放物線を描いて落ちてくる。これに当たると自機もやられるので、むやみやたらに撃つと危険だ。しかし、ショットが地面に落ちるとボーナスアイテムになるので、高得点を狙うならむやみやたらに撃って、気合で避けることが重要となる。


このように、撃つ目的、撃つことで起こる結果やリスクとリワードを工夫することで、新たなゲームを作ることができる。「撃つ」という行為を何のためにどのようなタイミングで行うのか、ということをプレイヤーに考えさせることで、新たな楽しみ方があるSTGを作ることができる。

ただしこれは全てのSTGについて考えるべきではない。特に撃つことにリスクを持たせることにはかなり慎重になる必要がある。敵を破壊する爽快感を前面に押し出したいのであれば、弾は撃ち放題、敵は壊れ放題にすべきで、そこに駆け引きを持ち込む必要は無い。怒首領蜂で敵を残してコンボをつなぐためにショットを小出しにするとか、斑鳩で同色の敵を撃つためにタイミング良く単発弾を撃つ、みたいなギミックはとても面白いが、これにストレスを感じるプレイヤーもいるはずで、全てのSTGがそうあるべきとは思わない。


  • 「撃って」「干渉する」ゲーム、COUNTER B

メタルブラックやGダライアスボーダーダウンなどで見覚えのある干渉球を単体でゲーム化した。自分と敵の攻撃がぶつかり合ってせめぎあうシチュエーションはたまらないものがある。

  • 「撃って」「まとめて倒す」ゲーム、THROW M

プーヤンで風船で降りてくる狼を肉でまとめて倒すところが好きで、そこだけ楽しみたかった。まとめて倒すと高得点は、昔ながらの伝統的なゲームルールといえる。

  • 「撃って」「遠くの敵を倒す」ゲーム、MORTAR

セガヘビーメタルが元ネタである。ヘビーメタルは縦スクロールシューティングで、画面外の敵を遠距離ミサイルで破壊できるという画期的なシステムがある。


このように他のゲームのフィーチャーの楽しさを借りるのも手である。このゲームのこのフィーチャーが楽しかったという思い出を心に、愛のあるオマージュをしよう。


  • 「撃って」「爆発させて敵を倒しながら爆風で自機の軌道を修正して敵を避ける」ゲーム、BOMB UP

  • 「撃って」「敵の戦車を破壊するけど地面に穴をあけることもできてそこで敵弾を避けられる」ゲーム、GRENADIER

  • 「撃って」「ついでにジャンプして地面に障害物ができるけどアイテムを取ると別の物を撃って障害物を破壊できる」ゲーム、R WHEEL


このように、撃つという行為にあまりに多くのギミックを詰め込むとプレイヤーが混乱する。小さなゲームならありだが、一般的なシューティングゲームでは避けた方が良い。


こういった「撃って」「〇〇する」というキーワードで考えたアイデアは、STGを作るうえで何の役に立つか。例えば、あるシューティングゲームを代表するコアメカニクスを考えるのに役立つだろう。ここでいうコアメカニクスとはメタルブラックでの解放ビーム、レイディアントシルバーガンにおけるチェーンボーナスなど、そのゲームを代表し、特徴づける仕組みのことを指す。インパクトのあるコアメカニクスを設定することで、ゲームの差別化に役立つ。

また、特殊なギミックを持つステージやボスを考えるのにも活用できる。ゲーム全体を通じて適用されるコアメカニクスではなく、特定のステージや、特定のボスなど、ゲームの部分で発生する仕組みにこれらのアイデアを取り入れることで、ゲーム展開にバリエーションを持たせることができる。例えば、グラディウスシリーズはステージごとにコアとなるギミックを持つことで、ステージごとに新たな体験をプレイヤーに提供している。

「撃って」「〇〇する」を題材にシューティングゲームのアイデアを考える話をした。この記事を見た方々に、ちょっと変わったシューティングゲームを作ってみるのも面白いかも?と思えてもらえたらうれしい。シューティングゲームというジャンルの枠にとらわれず、自由な発想でゲームデザインに挑戦することが、シューティングゲームの持つ可能性を広げるのに役立つはずである。シューティングゲームにはこんな楽しさもあるのか、という新鮮な驚きをプレイヤーに届けることで、よりシューティングゲームファンは広がっていく。シューティングゲームは長い歴史を持つジャンルである。だからこそ、その面白さやポテンシャルを、次の世代へと継承していければと思う。