それ自体が楽しい小規模ゲーム制作
(abagames.github.io)- 小規模ゲームとは、10分以内で終わり、ブラウザで気軽に遊べるゲームのことであり、短く作る過程そのものが創作の楽しさになりうる
- 350本以上、1年間で139本を制作した経験は、短い制作サイクルがアイデアの実験と反復学習を大きく増やすことを示している
- 早ければ約2時間、難しくてもおよそ10時間前後で作れるが、アートワークに深く入り込むと投入時間はいくらでも膨らみうる
- 小規模ゲームは大きなプロジェクト前の練習として扱われがちだが、優れた小さなゲームは規模とは別に固有の品質と魅力を持ちうる
- 新しいメカニクスを考え、自分のスタイルとして落とし込み、他人に見せるところまで含めて、ゲーム開発の重要な楽しみになる
10分ゲームがもたらす素早い制作リズム
- Small Games Manifesto は、小規模ゲームを10分以内で終わり、Webブラウザで遊ぶのに適したゲームと定義している
- この基準に合うゲームを 350本以上 作っており、パターン化した制作方法で1年間に139本のゲームを作った経験もある
- 例として挙げられているゲームは、どれもブラウザですぐに遊べる形になっている
- 赤いバーを同じ長さに切りそろえるシンプルなゲーム
- タップでロープを切り、画面下部に触れさせないようにするゲームで、スマートフォンのようなタッチパネル端末でも楽しめる
- 魅力の核心は 短い開発時間 にある
- 早ければ約2時間で作れる
- 難所があってもおよそ10時間前後で作れる
- アートワークに深く入り込むと投入時間はいくらでも増えていく
- ここでいう小規模ゲームは、Game A Week のように毎週新しいゲームを作る試みから生まれるゲームに近い
- 開発者側も限られた時間で作らなければならないため、自然と小さなゲームになる
- 制作時間が短いため、さまざまなアイデアを気軽に試せて、風変わりなゲームを作ってテストする過程そのものが楽しみになる
大作の予行演習を超える価値
- 小規模ゲームはしばしば、より大きく洗練されたゲームを作るための 準備段階 として扱われる
- Make and release lots of small games before making a big one は、最初から大きなゲームを作るとモチベーションを失ったり、何年も費やした末に見たくもない結果になることがあると警告している
- しかし小さなゲームにも固有の魅力があり、How To Make Good Small Games は優れた小規模ゲームの存在と、その作り方を論じている
- その記事の12の考え方は、規模と品質 を切り分けて捉えている
- ゲームの品質は規模と独立しており、大きなゲームほど気を配るべき要素と失敗の可能性が増える
- 品質は感情的な射程とも別であり、短編と長編小説で成功条件が異なるように、小さなゲームにも別個の基準がある
- ゲームは自ら成功条件を定義するのだから、その条件を受け入れたうえで良し悪しを評価すべきである
- 新しいキャラクターやメカニクスはすべてプレイヤーへの約束であり、ゲームはその約束を果たすときに成功する
- より小さな約束をするほど成功しやすくなり、10個や100個のアイデアよりも、3つのアイデアを満足のいく形に育てるほうが容易である
- 約束は興味深く楽しい形で果たされるべきであり、その過程で個人のスタイルが現れる
- 約束を過剰に果たしすぎず、適切なタイミングでゲームを終えるべきである
- フォームファクターもゲームの約束の一部であり、プレイヤーに見せる情報を減らし、起動直後に遊べるようにすると期待値が変わる
- 「Demo」や「Prologue」といった名前で未完成のゲームを出す前に、なぜ完成前に公開しようとしているのかを考えるべきである
- ゲームを複数のエピソードに分けて長期間リリースする方法は、ほとんどの場合よい近道ではない
- バズを気にする必要はなく、小さく具体的な目標は小さく具体的な観客を引き寄せる
- 継続的に自分を満足させ、本当に良いと思えるゲームを作れているなら、すでに多くのゲーム開発者よりずっと先に進んでいる
作る過程そのものの楽しさ
- これに加えて13番目の考えとして「Have fun :)」が提案されている
- 新しいメカニクスを思いつき、自分のスタイルを反映させてゲームに統合する過程が楽しい
- ほどよい人数の人に作ったゲームを遊んでもらい、楽しんでもらえれば、さらに大きな満足が得られる
- 小規模ゲーム制作はゲーム開発能力の向上だけでなく、さまざまなアイデアを思いつき、実験し、喜びと失望のあいだを行き来する体験にもなる
- 成果物を他人に見せる瞬間まで含めて、小さなゲーム作りは それ自体で楽しい開発活動 として残る
1件のコメント
Hacker News のコメント
ゲームデザインとゲーム開発はまったく別物だと学んだ。
どんなメカニクスがよく組み立てられていて、プレイヤーを引きつけるのかを知るには創造性が必要で、開発には容赦ない実行力が必要。
だから序盤は既存のゲームをほぼそのまま作り直し、小さな変更だけを入れるのがいいと思う。1つの技術をきちんと身につけてから次の段階に進めるから。
最近作業したゲームの自由配置版: https://li-quoridor.vercel.app/ まだ作業中。
デザインは反復改善が必要で、そのためには開発が必要。プロとして作られるゲームで最初の構想どおりに出るものはほとんどなく、ほぼ完成したバージョンでさえ面白くなさすぎて捨てられることがしばしばある。
でも目標がゲームデザインなら、まずゲームメカニクスを紙のプロトタイプで作ってみるのがいい。
ターン制ゲームの多くは、家にある物と、友人たちがどう動くかを定めたルールだけで、テーブルの上でテストできる。
RPGのように計算の多いゲームでは、プレイヤーが実際には体験しない数学計算に足を取られないよう、ノートPCで小さな計算機スクリプトを走らせればいい。それでも「計算機スクリプト」はゲームエンジンよりずっと単純。
反射神経ベースのビデオゲームはプロトタイプがより難しいが、物理的な動きのあるゲームになぞらえてテストできる。新しいFPSの設計を、ペイントボール、エアソフト、レーザータグの上に、実写ロールプレイ式のルール変更として載せて試すような形。
プレイヤーのアバターが超人的なプラットフォームゲームやアドベンチャーゲームではメカニクスを直接試すのは難しいが、攻撃の脅威半径の円のような紙の基準表は作れる。レゴ、とくに可動部品のあるTechnicで物理ジオラマを作り、紙の基準表でコースが少なくとも成立するかを試すようなやり方。
この方法は前の戦略と違って、ゲームが面白いかまでは教えてくれないが、毎回新しいアイデアをプログラミングせずに既存のゲーム案を反復改善するのには使える。
実際のプログラミングなしでプロトタイプを作るのがほぼ不可能なのは、照明、鏡、錯視などを現実世界の物理に合わない形で扱う、芸術性の強いゲーム。最初のゲームとしてそういうものを設計しようとはしないほうがいい。
ゲームデザインはゲームの青写真を作る過程で、ゲーム開発は実際にゲームを建てる作業。そしてゲームデザインは予想よりはるかに難しい。
数年前に https://learnopengl.com/ を追ってみて、とても興味深かったが、生産性を出すには既存のエンジンを使うべきな気がする。
プログラミング経験はあるが、ゲーム開発やデザインの知識はまったくない人に合う本やチュートリアルはあるだろうか？
そうした変更だけで、戦略やプレイスタイルがどれほど劇的に変わるのかが面白い。Wordleの派生作を作ったが、予想よりはるかに多くのユーザーを引きつけた: https://www.polygonle.com
すばやく作るゲームのモデルはかなり楽しい。
パンデミック初期にいくつかゲームを作ったが、それぞれたぶん30分ほどでできた。幼い子どもたちがどのUnicode絵文字を使うか選ぶ形でプロセスに参加し、作った時間よりずっと長くそのゲームで遊んだ。
投稿された記事のゲームほどの完成度ではないが、子どもたちがマウスとキーボードに慣れるきっかけになった。
自分で作ってみるのは間違いなくおすすめ。楽しい。
https://alexsci.com/games/ 特定の画面サイズでしか動かず、一部はキーボードが必要で、説明もない。
今8歳の息子が、今でもときどき、絵文字を選んで数字を入力するとその数だけ画面に表示する「ゲーム」を開いてほしいと言う。
「面白い」ゲームではないが、父親が作って、自分も仕組みに関わったということが、子どもたちにとってはものすごく大きい。
同じ著者による別の興味深い記事に “Joy of small game development” があり、ここで議論されていた: https://news.ycombinator.com/item?id=37799387
昨日はこの著者が作った1D pacmanというゲームが1,700点以上を獲得して話題になり、ここで見られる: https://news.ycombinator.com/item?id=38845510
これだけでも、この人が本当に自分の話していることをよくわかっている証拠に見える。
Bevyでゲームを作り、学んだことをすべて記録しながらRustをかなり学んだ: https://taintedcoders.com/
ゲームが小さいほど最後まで完成させられる可能性が高くなる。たいていはまず動きが楽しく感じられるように作り、その周囲にゲームらしい概念を付け足していった。
1人で作業するときは、ゲームよりシミュレーションから作るのも強くおすすめする。動き出して生きているように見えるのを見るだけで本当に楽しい。新しいエンジンを学ぶたびにboidsを作るのはすばらしい練習になる。
文章だけだとわかりにくいかもしれないが、著者のすべてのゲームはここでプレイできる。
[1] http://www.asahi-net.or.jp/~cs8k-cyu/
さらに、含まれているゲームメカニクスごとにゲームを分類して整理したページもあり、個人的にはこちらのほうが面白い。
[2] https://abagames.github.io/action-mini-game-mechanic-tags/index.html
小さなゲームは本当に楽しい
実際、私のパンデミック中の課題は小さなゲームを作ることだった。ついにこういうものを試してみる時だと決めた
結局、まずタイルマップを切り出して注釈を付けるツールを作り https://tmt.computerpho.be/、それを使って最小限のブラウザ都市シミュレーター https://pc.computerpho.be/ を作った
これらの作業は、ブラウザ向けの単一ファイル「アプリ」を作る実験でもあったので、それもまた楽しかった
連休中に Playdate SDK（https://sdk.play.date）を触ってみたが、著者が言っているような小さなゲームには本当に向いている
小さな1ビット画面と約150MHzのCPUという制約が、できることを強く制限するが、むしろかなり解放感がある。分析麻痺は減り、実行は増える
同じ精神で見る価値があるもの: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
ゲームを作るというアイデアが本当に好きで、それがプログラミングを始めるきっかけだった
数日間 SDL2 にかじりついて夢中で作ることほど楽しいことはあまりない。lazy foo のチュートリアルと過ごした時間は、最高の思い出の一つだ
https://lazyfoo.net/
仕事を辞めたあとゲームを作っていて、人生でも指折りに楽しい時間を過ごしている
以前はゲーム作りがとても重荷に感じられたが、少し前に何でもゲームメカニクスにできるのだと気づいた。ルールはない。強いて言うなら、楽しくなければならないというルールだけだ
数か月前に Baldurs Gate 3 をプレイして、大きな刺激を受けた。RPGは長く遊んできたが、本物の「TTRPG」はやったことがなく、子どもの頃は主にJRPGを遊んでいた。DnDも知ってはいたが、現実でやってみたいとは思わず、なんとなく「ちょっと微妙」なもののように感じていた
でもBG3をプレイして、「RPG」が何を意味するのかを本当に理解した。あのゲームはすべてを噛み合わせてくれた