ゲームを作ったり、ゲームを遊びまくったりしている せっき～の生き様。 まずは目次をご覧ください
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
これは、2010年2月20日 に行われたセミナーの記事です。
第６回 IGDA 同人・インディーゲーム部会
「同人シューティングゲームの潮流
- 80年代から現代まで、変化から学ぶ実践的な普遍性 - 」
-------------------------------------------------------------------
●弾幕の科学――モデル化、生成、ランク、おもてなし
・弾幕とは 一体何か？
プレイヤーに 心地よく死んでいただくための 大量の弾達
→ 大量の弾 ＋ 極小の当たり判定
→ 俺ってすげーーー 感を演出
・弾幕の構成
おもてなし弾 ・・・ 多い 、 画面をにぎやかにする物
プレイヤーの行動を制限する程度
殺し弾 ・・・ 少ない 、 プレイヤーを殺すための弾
→ 昔のＳＴＧは、全て 殺し弾だった
・弾幕の始祖
＝ 怒首領蜂 １９９７年 （諸説別れるが）
→ 移行、弾幕ＳＴＧが大ヒットした
・なぜ、弾幕が人気出たのか？
→ あたかも プレイヤーが凄い事をしていると錯覚
幾何学的な美しさ
弾幕職人のおもてなしの心
＋ 作るのが簡単
→ ギミック無しで、多彩な攻撃を作れる
従来 ・・・ レーザー、炸裂弾、多関節 …
今 ・・・ 弾のパターンのみ
------------------------------------------
・更に 楽をしたい
→ 弾幕の自動生成を考えてみた
・モデル化する
→ パターン化 、そのパターンを組み合わせよう
・BulletML
ＸＭＬで、弾幕を記述
・Bulletsmorph
進化する 弾幕の遺伝子
→ 弾幕同士を掛け合わせ、新しい弾幕を生む
（ＸＭＬで記述した弾幕同士を自動で掛け合わせる）
→ これを使い、無限のパターンの弾幕が遊べるＳＴＧを作成
・自動生成の問題点
→ 避けられない弾幕が生まれる
・その対策として
リミッター ＝ 一定数の弾が出ると、いったん弾を撃つのを辞める
（難易度調整としても有効な手法だった）
弾幕ソースに工夫 ＝ ちゃんと隙間ができるように
ランク ＝ 難易度に応じて、弾密度を変化させる
弾幕の自動評価 ＝ ＡＩプレイヤーをたくさん場に出す
（ＡＩプレイヤーは自動で動く）
生き残ったＡＩプレイヤーの数を見て、その弾幕の難易度を評価
・自動生成ＳＴＧの夢
毎回 違うゲームが楽しめる
ステージを作るのが楽
→ しかし
自動生成ＳＴＧは、本当に面白いのか？
パターンＳＴＧ（従来の覚えゲー）の遊びはできないので、ウケるかどうか？
------------------------------------------
・最後に
今回の公演は、今回のために作った ”ＳＩＧＩｎｄｉｅ６ＭＬ”と言うプレゼンソフトを使って でした。
ちなみに、このプレゼンソフトの最大の特徴はと言うと・・・
スライドの好きな場所で、弾幕を出す事ができる と言う物でした。
わざわざ、この講演のために こんなものを用意してくるとは・・・
「同人シューティングゲームの潮流
- 80年代から現代まで、変化から学ぶ実践的な普遍性 - 」
-------------------------------------------------------------------
●弾幕の科学――モデル化、生成、ランク、おもてなし
・弾幕とは 一体何か？
プレイヤーに 心地よく死んでいただくための 大量の弾達
→ 大量の弾 ＋ 極小の当たり判定
→ 俺ってすげーーー 感を演出
・弾幕の構成
おもてなし弾 ・・・ 多い 、 画面をにぎやかにする物
プレイヤーの行動を制限する程度
殺し弾 ・・・ 少ない 、 プレイヤーを殺すための弾
→ 昔のＳＴＧは、全て 殺し弾だった
・弾幕の始祖
＝ 怒首領蜂 １９９７年 （諸説別れるが）
→ 移行、弾幕ＳＴＧが大ヒットした
・なぜ、弾幕が人気出たのか？
→ あたかも プレイヤーが凄い事をしていると錯覚
幾何学的な美しさ
弾幕職人のおもてなしの心
＋ 作るのが簡単
→ ギミック無しで、多彩な攻撃を作れる
従来 ・・・ レーザー、炸裂弾、多関節 …
今 ・・・ 弾のパターンのみ
------------------------------------------
・更に 楽をしたい
→ 弾幕の自動生成を考えてみた
・モデル化する
→ パターン化 、そのパターンを組み合わせよう
・BulletML
ＸＭＬで、弾幕を記述
・Bulletsmorph
進化する 弾幕の遺伝子
→ 弾幕同士を掛け合わせ、新しい弾幕を生む
（ＸＭＬで記述した弾幕同士を自動で掛け合わせる）
→ これを使い、無限のパターンの弾幕が遊べるＳＴＧを作成
・自動生成の問題点
→ 避けられない弾幕が生まれる
・その対策として
リミッター ＝ 一定数の弾が出ると、いったん弾を撃つのを辞める
（難易度調整としても有効な手法だった）
弾幕ソースに工夫 ＝ ちゃんと隙間ができるように
ランク ＝ 難易度に応じて、弾密度を変化させる
弾幕の自動評価 ＝ ＡＩプレイヤーをたくさん場に出す
（ＡＩプレイヤーは自動で動く）
生き残ったＡＩプレイヤーの数を見て、その弾幕の難易度を評価
・自動生成ＳＴＧの夢
毎回 違うゲームが楽しめる
ステージを作るのが楽
→ しかし
自動生成ＳＴＧは、本当に面白いのか？
パターンＳＴＧ（従来の覚えゲー）の遊びはできないので、ウケるかどうか？
------------------------------------------
・最後に
今回の公演は、今回のために作った ”ＳＩＧＩｎｄｉｅ６ＭＬ”と言うプレゼンソフトを使って でした。
ちなみに、このプレゼンソフトの最大の特徴はと言うと・・・
スライドの好きな場所で、弾幕を出す事ができる と言う物でした。
わざわざ、この講演のために こんなものを用意してくるとは・・・
[0回]
PR
これは、2010年2月20日 に行われたセミナーの記事です。
第６回 IGDA 同人・インディーゲーム部会
「同人シューティングゲームの潮流
- 80年代から現代まで、変化から学ぶ実践的な普遍性 - 」
-------------------------------------------------------------------
●９０年代 同人シューティングゲーム
「超連射６８Ｋ 開発日記 - 弾幕世代以前の９０年代ＳＴＧのこと」
・当時の環境
ファミリーベーシック 、 ＭＳＸ 、 Ｘ６８０００
→ スプライト機能が付いている
→ 動的ゲームが作りやすい
・９０年代前半
ゲームセンター ＝ ゲーマーの交流の場
→ 常連客コミュニティ
→ ハイスコア競争 （雑誌でも集計）
ＳＴＧは まだまだ花形
萌え要素など無い （コットンなど 一部例外はあるけど）
弾幕も無い
→ はりつき、超連射、速攻 が重要な時代
・９０年代中盤
模索の時代
格ゲーの台頭
東亜プランの倒産 、コナミ 他ジャンルへ移行 など
ゲーマーの交流の場として、草の根ＢＢＳが普及
Ｘ６８０００ユーザーが使命感のように ＳＴＧをたくさん作っていた
・当時、ＳＴＧは どんどん遊びにくくなっていった
→ ロケテストの弊害
→ ロケテスト中、ゲームマニアがやり込んだ
→ その結果を受けて、難しいゲームになってしまった
-------------------------------------
●超連射６８Ｋ の話
http://
コミケ参加を目標に制作
プログラム、ドット絵を１人で担当 ＋ 音楽１人
・Ｘ６８０００
スプライト １６＊１６ドットが １２８枚出せる
→ スプライト機能 実は貧弱だった
→ プログラムの工夫でカバー
３２キャラ同士の当たり判定だけでも 処理落ちしてしまう
→ プログラムで工夫
・表示するスプライトを増やす
水平割り込みを利用し、
上で描画したスプライトを走査線の下に持ってくる事で もう一度描画させる
→ これを利用し、スプライトを４倍の数 表示した
・衝突判定の高速化
画面上をグリッドに分け、必要あるオブジェクト同士のみ 判定を行った
-------------------------------------
●その後のＳＴＧの事
・９０年代後半の変化
Windows９５ がやってきた
→ 大半のソースが無駄となった
当時のWindowsは ゲームを作りづらかった
インターネットの到来
ゲーメスト廃刊
弾幕ＳＴＧが現れた
・スーパープレイが変化
ネット上の動画サイトで プレイヤー見えないように
→ そのスーパープレイが本物かどうか？ 保証できない
ＴＡＳ が出てきた
スーパープレイ のカリスマが低下
→ ＳＴＧは、人間がその手で出したスーパープレイ と二人三脚で進化していた側面がある
→ ＳＴＧを根底から揺るがす事に
・リプレイデータが本物かどうか？ を証明できない事
トッププレイヤーにとっては
”ネットに公開されているハイスコア、スーパープレイは信用できない”
→ いまだに ＳＴＧプレイヤーにとって競い合う場は ゲームセンターである
→ ネットに場を広げれば、競い合う相手はもっと増えるけど
・競い合う土俵に求められる特性とは？
明確なレギュレーション（ルール）がある事
そのレギュレーションに違反した物は １００％検出可能である事
→ 違反プレイヤーが０であっても、違反できる余地がある場合は
土俵として認められない
・どうすれば ＴＡＳを防止できるか？
リプレイデータの暗号化は無駄
→ その手の人はプログラマが多いため、解析されてしまう
ＴＡＳの弱点 ＝ 実プレイ時間が とても長い
→ それを計測できれば、検知できる
乱数を予測不可能にできれば
→ 乱数予測系のＴＡＳはできなくなる
・しかし、上の対策は完全ではない
ＡＩ利用のチートは 依然可能
→ 画像を解析して 弾幕を避けるＡＩとか
ゲームを早送りして、プレイ時間をごまかす
→ ＴＡＳ検知をだますことができる
→→ 今後とも 考えていかないといけない課題である
「同人シューティングゲームの潮流
- 80年代から現代まで、変化から学ぶ実践的な普遍性 - 」
-------------------------------------------------------------------
●９０年代 同人シューティングゲーム
「超連射６８Ｋ 開発日記 - 弾幕世代以前の９０年代ＳＴＧのこと」
・当時の環境
ファミリーベーシック 、 ＭＳＸ 、 Ｘ６８０００
→ スプライト機能が付いている
→ 動的ゲームが作りやすい
・９０年代前半
ゲームセンター ＝ ゲーマーの交流の場
→ 常連客コミュニティ
→ ハイスコア競争 （雑誌でも集計）
ＳＴＧは まだまだ花形
萌え要素など無い （コットンなど 一部例外はあるけど）
弾幕も無い
→ はりつき、超連射、速攻 が重要な時代
・９０年代中盤
模索の時代
格ゲーの台頭
東亜プランの倒産 、コナミ 他ジャンルへ移行 など
ゲーマーの交流の場として、草の根ＢＢＳが普及
Ｘ６８０００ユーザーが使命感のように ＳＴＧをたくさん作っていた
・当時、ＳＴＧは どんどん遊びにくくなっていった
→ ロケテストの弊害
→ ロケテスト中、ゲームマニアがやり込んだ
→ その結果を受けて、難しいゲームになってしまった
-------------------------------------
●超連射６８Ｋ の話
http://
コミケ参加を目標に制作
プログラム、ドット絵を１人で担当 ＋ 音楽１人
・Ｘ６８０００
スプライト １６＊１６ドットが １２８枚出せる
→ スプライト機能 実は貧弱だった
→ プログラムの工夫でカバー
３２キャラ同士の当たり判定だけでも 処理落ちしてしまう
→ プログラムで工夫
・表示するスプライトを増やす
水平割り込みを利用し、
上で描画したスプライトを走査線の下に持ってくる事で もう一度描画させる
→ これを利用し、スプライトを４倍の数 表示した
・衝突判定の高速化
画面上をグリッドに分け、必要あるオブジェクト同士のみ 判定を行った
-------------------------------------
●その後のＳＴＧの事
・９０年代後半の変化
Windows９５ がやってきた
→ 大半のソースが無駄となった
当時のWindowsは ゲームを作りづらかった
インターネットの到来
ゲーメスト廃刊
弾幕ＳＴＧが現れた
・スーパープレイが変化
ネット上の動画サイトで プレイヤー見えないように
→ そのスーパープレイが本物かどうか？ 保証できない
ＴＡＳ が出てきた
スーパープレイ のカリスマが低下
→ ＳＴＧは、人間がその手で出したスーパープレイ と二人三脚で進化していた側面がある
→ ＳＴＧを根底から揺るがす事に
・リプレイデータが本物かどうか？ を証明できない事
トッププレイヤーにとっては
”ネットに公開されているハイスコア、スーパープレイは信用できない”
→ いまだに ＳＴＧプレイヤーにとって競い合う場は ゲームセンターである
→ ネットに場を広げれば、競い合う相手はもっと増えるけど
・競い合う土俵に求められる特性とは？
明確なレギュレーション（ルール）がある事
そのレギュレーションに違反した物は １００％検出可能である事
→ 違反プレイヤーが０であっても、違反できる余地がある場合は
土俵として認められない
・どうすれば ＴＡＳを防止できるか？
リプレイデータの暗号化は無駄
→ その手の人はプログラマが多いため、解析されてしまう
ＴＡＳの弱点 ＝ 実プレイ時間が とても長い
→ それを計測できれば、検知できる
乱数を予測不可能にできれば
→ 乱数予測系のＴＡＳはできなくなる
・しかし、上の対策は完全ではない
ＡＩ利用のチートは 依然可能
→ 画像を解析して 弾幕を避けるＡＩとか
ゲームを早送りして、プレイ時間をごまかす
→ ＴＡＳ検知をだますことができる
→→ 今後とも 考えていかないといけない課題である
[0回]
これは、2010年2月20日 に行われたセミナーの記事です。
第６回 IGDA 同人・インディーゲーム部会
「同人シューティングゲームの潮流
- 80年代から現代まで、変化から学ぶ実践的な普遍性 - 」
-------------------------------------------------------------------
●８０年代 同人シューティングゲーム
「実体験に基づく、少人数制作によるシューティングゲームの提案」
・時代背景 当時のＳＴＧと言えば？
→ ゲームセンターのゲーム
ＰＣ８８「シルフィード」
→ 弾幕など無かった。
・講演者の紹介
→ ９０年前後に メインで活動していた
（今は 足を洗っている）
・８０年代のコンピューター （ＰＣ８８）
ＣＰＵが遅い
ＢＡＳＩＣ （インタプリタで遅い）
→ 画面上に 数個のキャラクターを動かすだけで処理がいっぱい
ツールや 情報が少なすぎる
（何千円もするツール や、雑誌頼り）
→ 敷居が高かった
→ しかし、ＢＡＳＩＣの とっつき安さは とても魅力
・ＢＡＳＩＣでＳＴＧを作るとしたら
→ ３キャラ動かすのが限界 （自機、敵、弾 で終わり？）
→ 制限の中で いかにゲーム性を出すか？
・アイデア勝負しよう！
→ タイトーの「バルーンボンバー」って 素晴らしいですよね！
---------------------
・当時の教訓から、初心者に向けて ゲーム開発の心得
・ ゲームの面白さのために、”ハードスペック”や”開発環境”の悪さは
いくつかのアイデアで その穴を埋めることができる
・ 様々なデータを 自分で作る事ができない？
→ ゲーム性には 絵や音は不要
（とりあえず、ゲームとしては 丸と四角でよい）
・ 一本でも 最初から最後まで、作り上げた経験は とても大きい
（まずは、大作より 必ず作れる第一作）
---------------------
・PC88STG 「ＧＵＮＣＲＩＳＩＳ」
・面データについて
決まったパターン、決まった場所に敵が出現 （例 グラディウス）
↑
↓
ある程度、ランダムのアルゴリズムから敵が出現 （例 ゼビウス）
→ 面データを 一つ一つ作っていくのは とても大きな作業量
→ 出現テーブルを作り そこからランダムで敵を出すようにした
（面ごとに、１０数種類の敵キャラを配置）
→ 更に、面固有の敵を用意することで ステージに個性を出した
・グラフィック
→ アスキー文字のみ ３＊３の大きさ固定
・そこからの教訓
制限がある環境の上でのゲームデザインをした
→ むしろ、何でもできるような環境で 何かを作る方が難しいのでは
→ 制限のある中で作った方が、新しい何かを生み出すことができるかも
・少ないデータで、多様な敵を作る
→ ものすごく強い敵は 作りやすい
問題は プレイヤーが頑張れば乗り越えられるくらいの敵を作るのが難しい
（１０バイトのパラメーターで いろいろ個性を出した
しかし所詮はパラメーター調整、より個性を特化したいときは プログラムで記述した方がよい）
・当時のゲームから 一部を修正して、新しいゲーム性を生んだ
→ 例） コナミの”レジャック” → PC88 STG「ジャレック」
「同人シューティングゲームの潮流
- 80年代から現代まで、変化から学ぶ実践的な普遍性 - 」
-------------------------------------------------------------------
●８０年代 同人シューティングゲーム
「実体験に基づく、少人数制作によるシューティングゲームの提案」
・時代背景 当時のＳＴＧと言えば？
→ ゲームセンターのゲーム
ＰＣ８８「シルフィード」
→ 弾幕など無かった。
・講演者の紹介
→ ９０年前後に メインで活動していた
（今は 足を洗っている）
・８０年代のコンピューター （ＰＣ８８）
ＣＰＵが遅い
ＢＡＳＩＣ （インタプリタで遅い）
→ 画面上に 数個のキャラクターを動かすだけで処理がいっぱい
ツールや 情報が少なすぎる
（何千円もするツール や、雑誌頼り）
→ 敷居が高かった
→ しかし、ＢＡＳＩＣの とっつき安さは とても魅力
・ＢＡＳＩＣでＳＴＧを作るとしたら
→ ３キャラ動かすのが限界 （自機、敵、弾 で終わり？）
→ 制限の中で いかにゲーム性を出すか？
・アイデア勝負しよう！
→ タイトーの「バルーンボンバー」って 素晴らしいですよね！
---------------------
・当時の教訓から、初心者に向けて ゲーム開発の心得
・ ゲームの面白さのために、”ハードスペック”や”開発環境”の悪さは
いくつかのアイデアで その穴を埋めることができる
・ 様々なデータを 自分で作る事ができない？
→ ゲーム性には 絵や音は不要
（とりあえず、ゲームとしては 丸と四角でよい）
・ 一本でも 最初から最後まで、作り上げた経験は とても大きい
（まずは、大作より 必ず作れる第一作）
---------------------
・PC88STG 「ＧＵＮＣＲＩＳＩＳ」
・面データについて
決まったパターン、決まった場所に敵が出現 （例 グラディウス）
↑
↓
ある程度、ランダムのアルゴリズムから敵が出現 （例 ゼビウス）
→ 面データを 一つ一つ作っていくのは とても大きな作業量
→ 出現テーブルを作り そこからランダムで敵を出すようにした
（面ごとに、１０数種類の敵キャラを配置）
→ 更に、面固有の敵を用意することで ステージに個性を出した
・グラフィック
→ アスキー文字のみ ３＊３の大きさ固定
・そこからの教訓
制限がある環境の上でのゲームデザインをした
→ むしろ、何でもできるような環境で 何かを作る方が難しいのでは
→ 制限のある中で作った方が、新しい何かを生み出すことができるかも
・少ないデータで、多様な敵を作る
→ ものすごく強い敵は 作りやすい
問題は プレイヤーが頑張れば乗り越えられるくらいの敵を作るのが難しい
（１０バイトのパラメーターで いろいろ個性を出した
しかし所詮はパラメーター調整、より個性を特化したいときは プログラムで記述した方がよい）
・当時のゲームから 一部を修正して、新しいゲーム性を生んだ
→ 例） コナミの”レジャック” → PC88 STG「ジャレック」
[0回]
これは、2010年1月24日 に行われたセミナーの記事です。
第５回 IGDA 同人・インディーゲーム部会
「ノベルゲーム制作実践テクニック -素材制作の技術と制作管理・宣伝のノウハウ-」
--------------------------------------------------------------------
●Artemis Engineで作るiPhone用ゲーム
・なぜ ｉＰｈｏｎｅなのか？
→ 稀少だから （同人アプリは かなり少ない）
→ 市場規模が大きい
（日本だけでも １００万台以上、全世界だと 数千万台
←→ 参考までに NintendoDSは１億台くらい）
→ ただし、収益を期待するには 英語対応必須
・Artemis Engine とは？
ｉＰｈｏｎｅ用 ノベル・ＡＤＶ スクリプトシステム
→ ＨＴＭＬ程度の 容易な記述
→ LUAスクリプトを用いて、拡張可能
・利用条件
→ 個人に対して フリー
→ ただし、不特定多数に向けて公開していない
（ユーザー全員に十分なフォローができないため）
→ 直接連絡をしてもらう事で対応
→ 現在、４０サークル程が使用している
→ アップルストアで公開されている 同人ノベルゲームは（知る限り）すべて Artemis Engineが使われている
・なぜ Artemis Engineが必要なのか？
アプリを開発するためには、Objective-C と iPhone-SDK の知識が必須
（技術者の数、開発のための情報が少ない）
商用のツールはあるけれども、フリーは これのみ
マルチプラットホーム
→ Windows上で開発可能。 （Windows上でスクリプトを書き、デバック可能）
→ ただし、アップルストアに上げる際のみ Macが必要
吉里吉里 ＋ ＫＡＧ に似たスクリプト文法
→ 移植作が作りやすい
Selene （Artemis Engineでアップした初めてのゲーム）
→ ４万１０００ダウンロード （１１ヶ月間で）
→ 日本語版のみだけど、３割くらいは 海外のダウンロードだった
更に詳しくは・・・
http://
↑のネットラジオを聞くと 良く分かります
--------------------------------------------------------------------
●短編ノベル制作のテクニック-ライティングからコミュニケーションまで
○何故 同人ノベルゲームは完成しないのか？
→ 作品の規模と、開発力がマッチしていない
→ プロジェクトが 長期化すると、失敗のリスク大
→ だから短編
・短編の利点
体験版の規模で、完成品になる
モチベーションを維持し続けられる
必要素材が少ない
完成までの見通しが立てやすい
デバッグコストも少ない
→ 長編制作の問題点が 全てカバーされている
・短編の欠点
短い話を作るのは難しい
ユーザーに物足りなさを感じさせてしまう
高い評価を得にくい
○短編作品の制作と、各コミュニケーション
・締めきりを設定する （コミケやイベントに向けてなど）
→ 締め切りまでに無理しないで揃えられる素材数を 逆算する
（徹夜、デスマーチを前提としない）
・テキスト量と 時間の関係
１００KByte ＝ プレイ時間１時間相当
１Ｍ ～ 1.5ＭByte ＝ アニメ２クール分に相当
→ 短期間制作では 現実的では無い
短編製作 ＝ 100K ～ 200KByte → プレイ時間２時間
→ 映画のような時間配分
そのためには？
・限られた素材で成立する世界観
→ 少人数 かつ、固定された空間が舞台
→ 例） 「N.E.D.E」
http://
世界最後の日を舞台に、世界を救うロボットのパイロットに選ばれた少年少女が どのような世界最後の日を過ごすのか？
→ 最初からクライマックスの舞台を持ってくる事で、話や舞台を少なく抑える事が出来た
・素材も工夫
→ １話で使う絵は１枚のみ、立ち絵を用意しない
→ オブジェクトの有無、アングルや焦点を変化させる事で 立ち絵の代わりとし 表現する事ができた
○宣伝とコミュニケーション
・一般向け同人ノベルゲームのユーザー
→ コアなファンが多い （自分も制作していたり）
→ ゲームに対して 消費しているのではなく、参加している と言う感覚が強い
→ こういった方々と一緒に作品を作れば 自然と二次宣伝等で作品が広がっていく
・ＷＥＢラジオ
自分の作品を宣伝するのではなく
制作者や制作方法にフォーカスを当てたラジオを配信している
→ 制作者の横のつながりを広げられる
http://
・ＳＮＳなどの活用
→ サークルメンバーの拡大や、サークルのファンを増やすきっかけになる
→ ＴｏＭｉＣｏ
http://
○完成品を作ると言う事
・未完成品は、どれほど良く出来ていても評価されない
・完成本としてリリースしたものは、良し悪しは別にして 一定の評価を得る事が出来る
・評価 ＝ 次回へのモチベーション
・ノウハウは 作品制作から生まれ、ノウハウだけでは作品は生まれない
・完成品を作ると言う事は、自分たちのノウハウを作ると言う事
・短編制作を通す事で 完成させる事を体験する
・まずは、高望みをせず 自分の作れる範囲の物で、出来る限りの完成品を作って欲しい
第５回 IGDA 同人・インディーゲーム部会
「ノベルゲーム制作実践テクニック -素材制作の技術と制作管理・宣伝のノウハウ-」
--------------------------------------------------------------------
●Artemis Engineで作るiPhone用ゲーム
・なぜ ｉＰｈｏｎｅなのか？
→ 稀少だから （同人アプリは かなり少ない）
→ 市場規模が大きい
（日本だけでも １００万台以上、全世界だと 数千万台
←→ 参考までに NintendoDSは１億台くらい）
→ ただし、収益を期待するには 英語対応必須
・Artemis Engine とは？
ｉＰｈｏｎｅ用 ノベル・ＡＤＶ スクリプトシステム
→ ＨＴＭＬ程度の 容易な記述
→ LUAスクリプトを用いて、拡張可能
・利用条件
→ 個人に対して フリー
→ ただし、不特定多数に向けて公開していない
（ユーザー全員に十分なフォローができないため）
→ 直接連絡をしてもらう事で対応
→ 現在、４０サークル程が使用している
→ アップルストアで公開されている 同人ノベルゲームは（知る限り）すべて Artemis Engineが使われている
・なぜ Artemis Engineが必要なのか？
アプリを開発するためには、Objective-C と iPhone-SDK の知識が必須
（技術者の数、開発のための情報が少ない）
商用のツールはあるけれども、フリーは これのみ
マルチプラットホーム
→ Windows上で開発可能。 （Windows上でスクリプトを書き、デバック可能）
→ ただし、アップルストアに上げる際のみ Macが必要
吉里吉里 ＋ ＫＡＧ に似たスクリプト文法
→ 移植作が作りやすい
Selene （Artemis Engineでアップした初めてのゲーム）
→ ４万１０００ダウンロード （１１ヶ月間で）
→ 日本語版のみだけど、３割くらいは 海外のダウンロードだった
更に詳しくは・・・
http://
↑のネットラジオを聞くと 良く分かります
--------------------------------------------------------------------
●短編ノベル制作のテクニック-ライティングからコミュニケーションまで
○何故 同人ノベルゲームは完成しないのか？
→ 作品の規模と、開発力がマッチしていない
→ プロジェクトが 長期化すると、失敗のリスク大
→ だから短編
・短編の利点
体験版の規模で、完成品になる
モチベーションを維持し続けられる
必要素材が少ない
完成までの見通しが立てやすい
デバッグコストも少ない
→ 長編制作の問題点が 全てカバーされている
・短編の欠点
短い話を作るのは難しい
ユーザーに物足りなさを感じさせてしまう
高い評価を得にくい
○短編作品の制作と、各コミュニケーション
・締めきりを設定する （コミケやイベントに向けてなど）
→ 締め切りまでに無理しないで揃えられる素材数を 逆算する
（徹夜、デスマーチを前提としない）
・テキスト量と 時間の関係
１００KByte ＝ プレイ時間１時間相当
１Ｍ ～ 1.5ＭByte ＝ アニメ２クール分に相当
→ 短期間制作では 現実的では無い
短編製作 ＝ 100K ～ 200KByte → プレイ時間２時間
→ 映画のような時間配分
そのためには？
・限られた素材で成立する世界観
→ 少人数 かつ、固定された空間が舞台
→ 例） 「N.E.D.E」
http://
世界最後の日を舞台に、世界を救うロボットのパイロットに選ばれた少年少女が どのような世界最後の日を過ごすのか？
→ 最初からクライマックスの舞台を持ってくる事で、話や舞台を少なく抑える事が出来た
・素材も工夫
→ １話で使う絵は１枚のみ、立ち絵を用意しない
→ オブジェクトの有無、アングルや焦点を変化させる事で 立ち絵の代わりとし 表現する事ができた
○宣伝とコミュニケーション
・一般向け同人ノベルゲームのユーザー
→ コアなファンが多い （自分も制作していたり）
→ ゲームに対して 消費しているのではなく、参加している と言う感覚が強い
→ こういった方々と一緒に作品を作れば 自然と二次宣伝等で作品が広がっていく
・ＷＥＢラジオ
自分の作品を宣伝するのではなく
制作者や制作方法にフォーカスを当てたラジオを配信している
→ 制作者の横のつながりを広げられる
http://
・ＳＮＳなどの活用
→ サークルメンバーの拡大や、サークルのファンを増やすきっかけになる
→ ＴｏＭｉＣｏ
http://
○完成品を作ると言う事
・未完成品は、どれほど良く出来ていても評価されない
・完成本としてリリースしたものは、良し悪しは別にして 一定の評価を得る事が出来る
・評価 ＝ 次回へのモチベーション
・ノウハウは 作品制作から生まれ、ノウハウだけでは作品は生まれない
・完成品を作ると言う事は、自分たちのノウハウを作ると言う事
・短編制作を通す事で 完成させる事を体験する
・まずは、高望みをせず 自分の作れる範囲の物で、出来る限りの完成品を作って欲しい
[1回]
これは、2010年1月24日 に行われたセミナーの記事です。
第５回 IGDA 同人・インディーゲーム部会
「ノベルゲーム制作実践テクニック -素材制作の技術と制作管理・宣伝のノウハウ-」
--------------------------------------------------------------------
●効率よく短期間でテキストアドベンチャーを作成する方法
飯島多紀哉（元 飯島健男）の講演
相変わらずですが、この人のしゃべりは 面白すぎです
・七転び八転がりでは、３ヵ月半で ノベルゲームを２本作りました。
→ １ヵ月で １００万文字 、 ３週間で ５０万文字
→ 上２つを 両方同じスタッフが掛け持ちで作りました！
→ スタッフ数は １０人
（余談だけど
スタッフ全員に 営業、広報もさせている
→ 「全クリエイターは 営業能力持っていない 生き残れないぞ」）
・同人でご飯を食べる事はできます
・何故 短期間制作なのか？
→ そもそも、人って モチベーションが持たない
→ ３ヵ月 ～ 長くて ６ヵ月 が勝負！
（如何に長期間でモチベーションを維持させるか？ なんて考えない）
・多人数で作る時の重要なこと
→ 全員が 全員の能力を把握する事
（自己申告によるものでは無く）
→ そして、それを全部管理する 管理者が大事
→ デスマーチが起きるのは、管理者が悪い
→ その人に無理な事を要求しない これもが大事
（そう言う意味で、全員の能力を把握する）
→ すると、自ずと円滑な開発になる
・初めての開発では、気心知れた人間と組んで作ろう
→ いきなりスーパープログラマが参加する なんてあり得ない
→ それよりは、気心知れた人間とやる方が良い
→ 作っている内に スキルは上がるもの
・プロとして欲しいスキル
→ シナリオ １日（８時間）５０００文字は書けないと厳しい
→ グラフィック キャラデザ １日に１体
背景、イベント絵 １日に１枚
→ １日に１枚描いてね と頼んでちゃんと描ける事が重要
→ プログラマ ツールが自作できる人
→ スクリプタ 簡単に判断しづらいので、実際に作ってもらう
・１週間のうち、２日は休みにする事
→ 休憩する意味でも、想定外の事が起きても対応しやすい と言う意味でも
・ シナリオを最初に 何KByte 作るか決める
→ プロットを決めたら、次は その分量
・長い制作期間を設定しない
→ なので、夏コミ・冬コミ合わせ と言うのは良くない
→ 作る内容・分量が確定したら 逆算して期間を確定する
→ そうせずに、長い期間だけ設定すると ダレてしまったりして作らず終いになる恐れが大きい
・開発期間の予備は重要
→ 必ず トラブルは起きる
→ 開発期間の３分の１は、予備期間としてあらかじめ設定しておく
→ 余力を持った状態で制作すれば、必ず成功する
・ゲームを作る事は 夢では無く、現実
と自覚する事が大事
・最低でも 最初の１週間 必ず日報を全員に出させる事
→ 全員の能力を見極められるように
→ スタッフ同士全員の 信頼感を作り上げる事が とても大事
第５回 IGDA 同人・インディーゲーム部会
「ノベルゲーム制作実践テクニック -素材制作の技術と制作管理・宣伝のノウハウ-」
--------------------------------------------------------------------
●効率よく短期間でテキストアドベンチャーを作成する方法
飯島多紀哉（元 飯島健男）の講演
相変わらずですが、この人のしゃべりは 面白すぎです
・七転び八転がりでは、３ヵ月半で ノベルゲームを２本作りました。
→ １ヵ月で １００万文字 、 ３週間で ５０万文字
→ 上２つを 両方同じスタッフが掛け持ちで作りました！
→ スタッフ数は １０人
（余談だけど
スタッフ全員に 営業、広報もさせている
→ 「全クリエイターは 営業能力持っていない 生き残れないぞ」）
・同人でご飯を食べる事はできます
・何故 短期間制作なのか？
→ そもそも、人って モチベーションが持たない
→ ３ヵ月 ～ 長くて ６ヵ月 が勝負！
（如何に長期間でモチベーションを維持させるか？ なんて考えない）
・多人数で作る時の重要なこと
→ 全員が 全員の能力を把握する事
（自己申告によるものでは無く）
→ そして、それを全部管理する 管理者が大事
→ デスマーチが起きるのは、管理者が悪い
→ その人に無理な事を要求しない これもが大事
（そう言う意味で、全員の能力を把握する）
→ すると、自ずと円滑な開発になる
・初めての開発では、気心知れた人間と組んで作ろう
→ いきなりスーパープログラマが参加する なんてあり得ない
→ それよりは、気心知れた人間とやる方が良い
→ 作っている内に スキルは上がるもの
・プロとして欲しいスキル
→ シナリオ １日（８時間）５０００文字は書けないと厳しい
→ グラフィック キャラデザ １日に１体
背景、イベント絵 １日に１枚
→ １日に１枚描いてね と頼んでちゃんと描ける事が重要
→ プログラマ ツールが自作できる人
→ スクリプタ 簡単に判断しづらいので、実際に作ってもらう
・１週間のうち、２日は休みにする事
→ 休憩する意味でも、想定外の事が起きても対応しやすい と言う意味でも
・ シナリオを最初に 何KByte 作るか決める
→ プロットを決めたら、次は その分量
・長い制作期間を設定しない
→ なので、夏コミ・冬コミ合わせ と言うのは良くない
→ 作る内容・分量が確定したら 逆算して期間を確定する
→ そうせずに、長い期間だけ設定すると ダレてしまったりして作らず終いになる恐れが大きい
・開発期間の予備は重要
→ 必ず トラブルは起きる
→ 開発期間の３分の１は、予備期間としてあらかじめ設定しておく
→ 余力を持った状態で制作すれば、必ず成功する
・ゲームを作る事は 夢では無く、現実
と自覚する事が大事
・最低でも 最初の１週間 必ず日報を全員に出させる事
→ 全員の能力を見極められるように
→ スタッフ同士全員の 信頼感を作り上げる事が とても大事
[0回]
プロフィール
ＨＮ：
せっき～
性別：
男性
職業：
ゲームプログラマ
自己紹介：
古いパソゲー、ボードゲーム、カードゲームを熱狂的に遊んでいます。
ついったー
http://twitter.com/seki_seki_seki
連絡先は
sekisekiseki（あっと）gmail.com
ついったー
http://twitter.com/seki_seki_seki
連絡先は
sekisekiseki（あっと）gmail.com
カテゴリー
最新記事
(10/24)
(02/17)
(12/20)
(12/07)
(11/29)
(11/15)
(11/02)
最新コメント
[06/24 www.linux.ca]
[06/23 linux.org]
[06/23 blackmarket-matches.com]
[06/23 Ucuz Davetiye]
[06/22 ロレックス デイトナ 8pダイヤ]
カウンター
ついったー
