ゲームを作ったり、ゲームを遊びまくったりしている せっき～の生き様。 まずは目次をご覧ください
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
2012年8月22日 にあった、ＣＥＤＥＣの講演についての記事です。
「コンシューマゲームでの挑戦！
ネットワークを活用したゲームの構築と運用「シェルノサージュ」の事例」
「シェルノサージュ」の具体的な運用例を中心にレポートしました。
ソースコードや遷移図を交えての話 ミドルウェアの紹介などもありましたが
文章ではまとめきれないため割愛しました。
すみません。
-------------------------------------------------
●まず 「シェルノサージュ」とは
ネットワークを活用したコミュニケーションゲーム
大きく以下の３つのパートに分かれます。
・コミュニケーションパート
イオンちゃんと コミュニケーション
アイテム採取や、アイテム生成を行う
→ クラウド （今回のテーマはコレ）
・シナリオパート
ゲーム本体には第一章のみが入っている。
シナリオは順次追加されていく。
→ 追加コンテンツ
（第２章までは無料、第三章以降有料）
・交流パート
他のプレイヤーとメッセージ送り合ったり、共同でミッションをクリアしたり
→ コミュニケーション
●「シェルノサージュ」のクラウド
ＰＳＶＩＴＡ のデータ
（例： 「着ている服」「疲れ具合」「機嫌」「交流履歴」「所持アイテム」 ）
→ ＰＳ３ 、スマートフォン 、ＷＥＢアプリ などの他の媒体で参照できる。
つまり
クラウド ≒ ネットワーク上のセーブデータ
こういう事もできるかも？？） （あくまで構想）
→ PSVITA でコミュニケーションゲームを遊び
→ スマートフォンで アイテム調合、ミニゲーム
→ PS3で、そのデータを使い RPG
クラウド機能は、様々な機種で同じ「世界」を創造できる。
●「シェルノサージュ」でクラウドにしているデータ
・ヒロイン情報
各種パラメータ、装備品 など
・アイテム情報
アイテム所持数、興味度、知識度 など
・イベント情報
ユーザーが発生させたイベント、選択肢情報
-------------------------------------------------
●クラウドの実装手法について
・クラウドと、通常のネットワーク通信の違い
通信手法 両方 ｈｔｔｐｓ
通信時アナウンス クラウド： しない （バックグラウンド）
通常： ダイアログ表示 （通信中です）
通信サイズ クラウド： 固定サイズ （シェルノサージュの場合 5000byte）
通常： 可変 （大体、100～30000byte くらい）
エラー時処理 クラウド： しない （オートリトライ）
通常： ダイアログ表示 （停止）
クラウドでは、ユーザーに通信している事を ユーザーに意識させない
・シェルノサージュの実装
特定のメモリに、通信データ領域 （5000byte）を用意している。
ゲームプレイをしパラメータなどが更新された場合、通信データ領域のメモリに書き込む。
→ 定期的に、通信データ領域のデータをチェックし
データが更新されたのを発見した場合、自動的にクラウドサーバーにデータを送信する。
・こんな所に注意
常にオンラインではない状況に どう対応するか？
移動中などで 途中切断が起きたとき、どうするか？
→ PSVITA内のデータと、サーバー内のデータは 常に整合性を保たれているように設計する必要がある。
-------------------------------------------------
●サーバー運用について
・サーバー構成
load balancer （負荷分散装置）
↓
APIサーバー × ２１ （状況によって 数を柔軟に変更）
↓
データベースサーバー × ４ （テーブルごとに 分けて格納）
●発売から いろいろなトラブルがありました。
大きな３つの原因について
１．データベースサーバーの処理超過
データベースの処理速度がおいつかない為、サーバーダウン
→ データベースサーバーが当初１つだけだったのを、４台に分割
→ テーブルを用途、負荷に応じて分割した。
（関連テーブルは同一サーバーに
処理が重いテーブルが入っているサーバーはテーブル数を減らす）
２．データベースから取得するレコード数が増大してサーバーダウン
例） 他のプレイヤーの妖精を検索
→ テスト時、数千で負荷テストをしても大丈夫だったけど
発売後は、数万～数百万になり 全然状況が違った
→ 取得数に必ず上限をつける。
（プレイヤー １０００人分検索したら 検索終了 など）
３．スクリプトの不可増大によるサーバーダウン
→ 永久ループを極力回避するスクリプトを組む
●技術的な注意点
・データベースに適切なインデックスを付ける
→ 検索カラムにインデックスを付けるだけで、処理が格段に早くなる
・フレームワークは データベースアクセス回数を調べる
・１回のレコード取得数は極力減らす
・Apacheの同時接続数、コネクションタイムの調整をする
→ 同時接続数を増やす → 高速化 しかし、クラウド料金跳ね上がり
切断時間を減らす → 検索にかかる時間が延びる （ユーザビリティが悪くなる）
●その他の注意点
・クラウド業者選択時は ２４時間電話サポートしている業者を
→ ゲームの場合、１時間でも停止すると大問題になる。
深夜のトラブルでも 早急な復帰ができる業者を
→ それができない業者の場合、最悪 サーバーの復帰が翌朝になってしまう恐れがあったり・・・
・リリース時にサーバーリソースをケチらない
→ 発売後の最初の１週間だけでも、サーバー台数は できるだけ最大数で
その後、最適な数にまとめていく
（クラウドサービスであれば、容易かつリーズナブルに変更できる）
「コンシューマゲームでの挑戦！
ネットワークを活用したゲームの構築と運用「シェルノサージュ」の事例」
「シェルノサージュ」の具体的な運用例を中心にレポートしました。
ソースコードや遷移図を交えての話 ミドルウェアの紹介などもありましたが
文章ではまとめきれないため割愛しました。
すみません。
-------------------------------------------------
●まず 「シェルノサージュ」とは
ネットワークを活用したコミュニケーションゲーム
大きく以下の３つのパートに分かれます。
・コミュニケーションパート
イオンちゃんと コミュニケーション
アイテム採取や、アイテム生成を行う
→ クラウド （今回のテーマはコレ）
・シナリオパート
ゲーム本体には第一章のみが入っている。
シナリオは順次追加されていく。
→ 追加コンテンツ
（第２章までは無料、第三章以降有料）
・交流パート
他のプレイヤーとメッセージ送り合ったり、共同でミッションをクリアしたり
→ コミュニケーション
●「シェルノサージュ」のクラウド
ＰＳＶＩＴＡ のデータ
（例： 「着ている服」「疲れ具合」「機嫌」「交流履歴」「所持アイテム」 ）
→ ＰＳ３ 、スマートフォン 、ＷＥＢアプリ などの他の媒体で参照できる。
つまり
クラウド ≒ ネットワーク上のセーブデータ
こういう事もできるかも？？） （あくまで構想）
→ PSVITA でコミュニケーションゲームを遊び
→ スマートフォンで アイテム調合、ミニゲーム
→ PS3で、そのデータを使い RPG
クラウド機能は、様々な機種で同じ「世界」を創造できる。
●「シェルノサージュ」でクラウドにしているデータ
・ヒロイン情報
各種パラメータ、装備品 など
・アイテム情報
アイテム所持数、興味度、知識度 など
・イベント情報
ユーザーが発生させたイベント、選択肢情報
-------------------------------------------------
●クラウドの実装手法について
・クラウドと、通常のネットワーク通信の違い
通信手法 両方 ｈｔｔｐｓ
通信時アナウンス クラウド： しない （バックグラウンド）
通常： ダイアログ表示 （通信中です）
通信サイズ クラウド： 固定サイズ （シェルノサージュの場合 5000byte）
通常： 可変 （大体、100～30000byte くらい）
エラー時処理 クラウド： しない （オートリトライ）
通常： ダイアログ表示 （停止）
クラウドでは、ユーザーに通信している事を ユーザーに意識させない
・シェルノサージュの実装
特定のメモリに、通信データ領域 （5000byte）を用意している。
ゲームプレイをしパラメータなどが更新された場合、通信データ領域のメモリに書き込む。
→ 定期的に、通信データ領域のデータをチェックし
データが更新されたのを発見した場合、自動的にクラウドサーバーにデータを送信する。
・こんな所に注意
常にオンラインではない状況に どう対応するか？
移動中などで 途中切断が起きたとき、どうするか？
→ PSVITA内のデータと、サーバー内のデータは 常に整合性を保たれているように設計する必要がある。
-------------------------------------------------
●サーバー運用について
・サーバー構成
load balancer （負荷分散装置）
↓
APIサーバー × ２１ （状況によって 数を柔軟に変更）
↓
データベースサーバー × ４ （テーブルごとに 分けて格納）
●発売から いろいろなトラブルがありました。
大きな３つの原因について
１．データベースサーバーの処理超過
データベースの処理速度がおいつかない為、サーバーダウン
→ データベースサーバーが当初１つだけだったのを、４台に分割
→ テーブルを用途、負荷に応じて分割した。
（関連テーブルは同一サーバーに
処理が重いテーブルが入っているサーバーはテーブル数を減らす）
２．データベースから取得するレコード数が増大してサーバーダウン
例） 他のプレイヤーの妖精を検索
→ テスト時、数千で負荷テストをしても大丈夫だったけど
発売後は、数万～数百万になり 全然状況が違った
→ 取得数に必ず上限をつける。
（プレイヤー １０００人分検索したら 検索終了 など）
３．スクリプトの不可増大によるサーバーダウン
→ 永久ループを極力回避するスクリプトを組む
●技術的な注意点
・データベースに適切なインデックスを付ける
→ 検索カラムにインデックスを付けるだけで、処理が格段に早くなる
・フレームワークは データベースアクセス回数を調べる
・１回のレコード取得数は極力減らす
・Apacheの同時接続数、コネクションタイムの調整をする
→ 同時接続数を増やす → 高速化 しかし、クラウド料金跳ね上がり
切断時間を減らす → 検索にかかる時間が延びる （ユーザビリティが悪くなる）
●その他の注意点
・クラウド業者選択時は ２４時間電話サポートしている業者を
→ ゲームの場合、１時間でも停止すると大問題になる。
深夜のトラブルでも 早急な復帰ができる業者を
→ それができない業者の場合、最悪 サーバーの復帰が翌朝になってしまう恐れがあったり・・・
・リリース時にサーバーリソースをケチらない
→ 発売後の最初の１週間だけでも、サーバー台数は できるだけ最大数で
その後、最適な数にまとめていく
（クラウドサービスであれば、容易かつリーズナブルに変更できる）
[0回]
PR
2012年8月22日 にあった、ＣＥＤＥＣの講演についての記事です。
「ゲームＡＩはプレイヤーを虜にできるか？
～アクションゲームにおいて、AIを使って華麗に誤魔化しつつ魅せる手法～」
テーマは
「ＣＰＵパワーを使い高度なＡＩを構築するわけではなく、
処理は軽くそれらしいＡＩ をいかに作るのか？」
です。
・気がつかなければＯＫ
・俺つえー感を演出
・ちょっとした工夫
・人間らしく見せるＡＩ
・賢く見えるＡＩ
について解説。
--------------------------------------------------
●気がつかなければＯＫ
ユーザーは自分が動かしているキャラに集中していて
敵ＡＩにはそれほど意識を向けていない と言う事を利用している。
画面外のキャラや 遮蔽物の向こうのキャラなど ユーザーの意識が向いていないＡＩを こっそりズルをさせる
→ 次の目的地にワープさせたり、一瞬で方向転換したり
実用例） プレイヤー vs 大量の敵 なアクションゲーム （無双的なゲーム）
ユーザーの目の前に 大量の敵がいるので、ユーザーの目を盗みやすい
ユーザーは近くの敵に意識を集中しがち
→ 離れている敵が こっそり高速移動している、こっそり武器を持ち替えている
→→ あくまで さりげなくする事がポイント
実用例） 戦闘機で撃ち合うゲーム （エースコンバット的な）
実は 弾が当たってから、避けている。
→ コツとしては、その時 派手な回避アクションをさせる。
→ そうすると、ユーザーは 「ギリギリでうまく避けたな あのＡＩやるな！」と感じる。
（実際は命中しているのに、紙一重で避けてるように見える）
→→ 最大の利点は、ＡＩが弾を避けるために 事前から予測して回避するよう移動する
と言うアルゴリズムを作らずに済む
--------------------------------------------------
●俺つえー感を演出
ユーザーに より熱中してもらうように
・複数の敵ＡＩの中から やられ役を決める
→ やられ役ＡＩは、わざと やられるような位置取りを行う。
→ そのＡＩがやられたら 次のＡＩをやられ役にして 繰り返す。
→→ 敵を連続して倒していけるので、ユーザーは気持ちよくなってくれる
→→ そのまま やられるために来たのでは 手を抜いているように見えるので
攻撃しにきたけど、うまくユーザーに 弾を当てれず そして撃たれた
と言う風な動きにする
そうすると、ユーザーは弾を華麗にかわしつつ 敵を倒したと感じ 更に気持ちいい
・状況によるＡＩの切り替え
ユーザーの腕を見て 難易度を裏でいじる
イージー強、イージー中、イージー弱
ノーマル強、ノーマル中、ノーマル弱
ハード強、 ハード中、 ハード弱
と、ユーザーには３段階に見せかけて 実は９段階用意していた
→ 適度な緊張感と手応え、クリアした時の気持ちよさをユーザーに与えた。
--------------------------------------------------
●ちょっとした工夫
普通のＡＩを より良いＡＩのように見せる手法
（ユーザーに対して印象付けをうまくする）
・初見を大切にする
登場シーンを ド派手でカッコよくする
→ そうするだけで、ユーザーは普通のＡＩなのに 一味違ったＡＩだと錯覚してくれる。
例） 同じＡＩなのだけど、パラメーターだけ若干強くした敵の場合
登場時に なんらかの特別なポーズを取らせるだけで 特別感を感じさせられる
・動き始めを丁寧に
開始の部分だけ別なＡＩのように振舞う。
（そこから後は 普段通りのＡＩ）
例） 登場の時だけ ジェットストリームアタックのように三位一体で現れた場合
その後は いつもどおりのＡＩなのに、なんか うまく連携攻撃されているように錯覚させられる。
（プレイヤーは 自分の操作に集中しているので、案外気づかない）
--------------------------------------------------
●人間らしく見せる
ユーザーに あたかも人間が操作しているかのように感じさせたい
→ しかし、それを真っ当に作ろうとした場合 かなりの労力と時間がかかってしまう。
そこで
・キーログによる 人間の操作テクニックを再現
ゲーム開発者が実際に操作して そのキーログを取る
そして、ＡＩに ここだ と言うタイミングで、キーログを再生させる
→ 凄いテクニックを見せつけられ ユーザーは関心
この手法は そもそもＡＩでは無いけれども 有効
・パラメーターによる 操作テクニックを擬似再現
人間が操作をする場合、テクニックを要するような場面
例えば 向こう岸にジャンプで飛び越えて進む場所で
絶妙なタイミングで２段ジャンプして 越えられる。
→ ＡＩに２段ジャンプのタイミングを判断させて 綺麗に飛び越えられるようにするアルゴリズムを用意するのは大変
（しかも、失敗すると 河に落ちてしまう）
→→ この時、こっそりジャンプ力のパラメータをこの時だけ２倍にして １回のジャンプで飛び越えられるようにする
→→ ユーザーは 「ちゃんと２段ジャンプで飛び越えているな 感心感心」と錯覚する
--------------------------------------------------
●賢く見えるＡＩ
・管理ＡＩと 個別ＡＩにわける
敵軍隊と 味方軍隊が戦い合うようなゲームにて
個別ＡＩ ・・・ 攻撃、防御、回避などのキャラの動き （キャラクター１人につき１個）
管理ＡＩ ・・・ 全体把握、状況判断、位置取り （１つの軍に１個）
状況判断して あそこに攻撃しろ、
ＨＰはヤバくなったので、あそこまで逃げて休め
と、管理AIが指示する。
個別ＡＩは、管理ＡＩからの指示を受けて その通りに行動する。
例）ステルス系アクションゲーム
個別ＡＩが 隠れたプレイヤーを発見した場合、
その個別ＡＩが管理ＡＩに伝える。
その後、管理ＡＩは 全体の個別ＡＩに プレイヤーを追いつけるよう指示を送る
例） 残りタイムがあるアクションゲーム
残りタイムがわずかで、自分の軍が負けているような場合
管理ＡＩが イチかバチかで、個別ＡＩ全部に 突撃の指示を送る
・管理ＡＩ同士で談合する。
無双系アクションゲームな、プレイヤーが所属する軍と 敵軍が戦うゲームにて
お互いの管理ＡＩが談合して、待ち伏せ や 先回り なんかを表現する。
例） 味方ＡＩ 「中央突破をするよー」
敵ＡＩ 「了解、じゃあ 中央の守りを固めます」
味方ＡＩ 「敵軍とぶつかったよ プレイヤーさん、頑張って！」
●このようなＡＩを作る際のチェック項目
ＡＩ 対 ＡＩ を行い、様子をながめる
・正確にゲームが進行しているか？
・地形にハマっていないか？
・理不尽な展開になっていないか？
・人間同士が戦っているっぽくなっているか？
・敵味方 連携しているっぽいか？
--------------------------------------------------
●まとめ
これらの手法は いつでもどこでも使えるわけではない
・リプレイ機能があるゲーム
・フリーカメラにできるゲーム
・複数プレイヤーが参加するゲーム
では注意が必要！
ごまかしている事を ユーザーにバレてはいけない
どこをごまかして、どこを正直にするのか？
見極めが重要
→ 華麗にごまかしましょう
→ ユーザーに 「面白い」「白熱する」「楽しい」と感じさせれば成功
→ 魅せるＡＩを！！
「ゲームＡＩはプレイヤーを虜にできるか？
～アクションゲームにおいて、AIを使って華麗に誤魔化しつつ魅せる手法～」
テーマは
「ＣＰＵパワーを使い高度なＡＩを構築するわけではなく、
処理は軽くそれらしいＡＩ をいかに作るのか？」
です。
・気がつかなければＯＫ
・俺つえー感を演出
・ちょっとした工夫
・人間らしく見せるＡＩ
・賢く見えるＡＩ
について解説。
--------------------------------------------------
●気がつかなければＯＫ
ユーザーは自分が動かしているキャラに集中していて
敵ＡＩにはそれほど意識を向けていない と言う事を利用している。
画面外のキャラや 遮蔽物の向こうのキャラなど ユーザーの意識が向いていないＡＩを こっそりズルをさせる
→ 次の目的地にワープさせたり、一瞬で方向転換したり
実用例） プレイヤー vs 大量の敵 なアクションゲーム （無双的なゲーム）
ユーザーの目の前に 大量の敵がいるので、ユーザーの目を盗みやすい
ユーザーは近くの敵に意識を集中しがち
→ 離れている敵が こっそり高速移動している、こっそり武器を持ち替えている
→→ あくまで さりげなくする事がポイント
実用例） 戦闘機で撃ち合うゲーム （エースコンバット的な）
実は 弾が当たってから、避けている。
→ コツとしては、その時 派手な回避アクションをさせる。
→ そうすると、ユーザーは 「ギリギリでうまく避けたな あのＡＩやるな！」と感じる。
（実際は命中しているのに、紙一重で避けてるように見える）
→→ 最大の利点は、ＡＩが弾を避けるために 事前から予測して回避するよう移動する
と言うアルゴリズムを作らずに済む
--------------------------------------------------
●俺つえー感を演出
ユーザーに より熱中してもらうように
・複数の敵ＡＩの中から やられ役を決める
→ やられ役ＡＩは、わざと やられるような位置取りを行う。
→ そのＡＩがやられたら 次のＡＩをやられ役にして 繰り返す。
→→ 敵を連続して倒していけるので、ユーザーは気持ちよくなってくれる
→→ そのまま やられるために来たのでは 手を抜いているように見えるので
攻撃しにきたけど、うまくユーザーに 弾を当てれず そして撃たれた
と言う風な動きにする
そうすると、ユーザーは弾を華麗にかわしつつ 敵を倒したと感じ 更に気持ちいい
・状況によるＡＩの切り替え
ユーザーの腕を見て 難易度を裏でいじる
イージー強、イージー中、イージー弱
ノーマル強、ノーマル中、ノーマル弱
ハード強、 ハード中、 ハード弱
と、ユーザーには３段階に見せかけて 実は９段階用意していた
→ 適度な緊張感と手応え、クリアした時の気持ちよさをユーザーに与えた。
--------------------------------------------------
●ちょっとした工夫
普通のＡＩを より良いＡＩのように見せる手法
（ユーザーに対して印象付けをうまくする）
・初見を大切にする
登場シーンを ド派手でカッコよくする
→ そうするだけで、ユーザーは普通のＡＩなのに 一味違ったＡＩだと錯覚してくれる。
例） 同じＡＩなのだけど、パラメーターだけ若干強くした敵の場合
登場時に なんらかの特別なポーズを取らせるだけで 特別感を感じさせられる
・動き始めを丁寧に
開始の部分だけ別なＡＩのように振舞う。
（そこから後は 普段通りのＡＩ）
例） 登場の時だけ ジェットストリームアタックのように三位一体で現れた場合
その後は いつもどおりのＡＩなのに、なんか うまく連携攻撃されているように錯覚させられる。
（プレイヤーは 自分の操作に集中しているので、案外気づかない）
--------------------------------------------------
●人間らしく見せる
ユーザーに あたかも人間が操作しているかのように感じさせたい
→ しかし、それを真っ当に作ろうとした場合 かなりの労力と時間がかかってしまう。
そこで
・キーログによる 人間の操作テクニックを再現
ゲーム開発者が実際に操作して そのキーログを取る
そして、ＡＩに ここだ と言うタイミングで、キーログを再生させる
→ 凄いテクニックを見せつけられ ユーザーは関心
この手法は そもそもＡＩでは無いけれども 有効
・パラメーターによる 操作テクニックを擬似再現
人間が操作をする場合、テクニックを要するような場面
例えば 向こう岸にジャンプで飛び越えて進む場所で
絶妙なタイミングで２段ジャンプして 越えられる。
→ ＡＩに２段ジャンプのタイミングを判断させて 綺麗に飛び越えられるようにするアルゴリズムを用意するのは大変
（しかも、失敗すると 河に落ちてしまう）
→→ この時、こっそりジャンプ力のパラメータをこの時だけ２倍にして １回のジャンプで飛び越えられるようにする
→→ ユーザーは 「ちゃんと２段ジャンプで飛び越えているな 感心感心」と錯覚する
--------------------------------------------------
●賢く見えるＡＩ
・管理ＡＩと 個別ＡＩにわける
敵軍隊と 味方軍隊が戦い合うようなゲームにて
個別ＡＩ ・・・ 攻撃、防御、回避などのキャラの動き （キャラクター１人につき１個）
管理ＡＩ ・・・ 全体把握、状況判断、位置取り （１つの軍に１個）
状況判断して あそこに攻撃しろ、
ＨＰはヤバくなったので、あそこまで逃げて休め
と、管理AIが指示する。
個別ＡＩは、管理ＡＩからの指示を受けて その通りに行動する。
例）ステルス系アクションゲーム
個別ＡＩが 隠れたプレイヤーを発見した場合、
その個別ＡＩが管理ＡＩに伝える。
その後、管理ＡＩは 全体の個別ＡＩに プレイヤーを追いつけるよう指示を送る
例） 残りタイムがあるアクションゲーム
残りタイムがわずかで、自分の軍が負けているような場合
管理ＡＩが イチかバチかで、個別ＡＩ全部に 突撃の指示を送る
・管理ＡＩ同士で談合する。
無双系アクションゲームな、プレイヤーが所属する軍と 敵軍が戦うゲームにて
お互いの管理ＡＩが談合して、待ち伏せ や 先回り なんかを表現する。
例） 味方ＡＩ 「中央突破をするよー」
敵ＡＩ 「了解、じゃあ 中央の守りを固めます」
味方ＡＩ 「敵軍とぶつかったよ プレイヤーさん、頑張って！」
●このようなＡＩを作る際のチェック項目
ＡＩ 対 ＡＩ を行い、様子をながめる
・正確にゲームが進行しているか？
・地形にハマっていないか？
・理不尽な展開になっていないか？
・人間同士が戦っているっぽくなっているか？
・敵味方 連携しているっぽいか？
--------------------------------------------------
●まとめ
これらの手法は いつでもどこでも使えるわけではない
・リプレイ機能があるゲーム
・フリーカメラにできるゲーム
・複数プレイヤーが参加するゲーム
では注意が必要！
ごまかしている事を ユーザーにバレてはいけない
どこをごまかして、どこを正直にするのか？
見極めが重要
→ 華麗にごまかしましょう
→ ユーザーに 「面白い」「白熱する」「楽しい」と感じさせれば成功
→ 魅せるＡＩを！！
[0回]
2012年8月21日 にあった、ＣＥＤＥＣの講演についての記事です。
『GRAVITY DAZE/重力的眩暈：上層への帰還において、彼女の内宇宙に生じた摂動』
携帯型エンタテインメントシステムゲーム機 PlayStation
Vitaにおけるオープンワールドゲームの作り方
講演内容を 大きく２つに分けて まとめました。
スクリプトについて です。
（データの管理の手法 については http://sekigames.gg-blog.com/Entry/243/ ）
-------------------------------------------------------------------
●スクリプトについて
Ｌｕａを使用した。
→ 「GRAVITY DAZE」では、スクリプトで全ての要素を管理しているため 大変重要
→ 複数の LuaState を同時に存在でき、並列に動けるようにした。
・SandBox
スクリプト１つの実行単位
（SandBox ＝ LuaState ＋ オブジェクト管理情報）
・スクリプトは プランナーが書いた
●なぜ こうしたか？
基礎研究に時間を費やしたため、イベントの作成などの期間は （デバッグ期間など含め）１年ほどであった
その１年の中で
ストーリーミッション ２１個
チャレンジミッション ２０個
その他イベント
を作成と、短い期間で 大量のイベントを同時作成する必要があった
・開発環境
Ｍａｙａ イベントセンサー
各種配置情報 などを設定
ＥＸＣＥＬ 簡易データベース
静的データ
Ｌｕａ 具体的なイベントの動き
・専用ツールは無かった
→ ツール開発に コストを割けなかった
→ それなら 専用ツールを必要としない作り方を考えた
（Ｍａｙａ と Ｌｕａ のみで作成）
すぐに作成を開始でき、ツールのメンテナンスコストが かからなかった点は良かった
（ただし、より大人数で開発する場合や 追加コンテンツなどをこの先も作り続けるタイプの開発の場合は 不向きだろう）
-------------------------------------------------------------------
●ゲームの要素全てを SandBox にしている
プレイヤー、敵キャラ、オブジェクト
タイトル画面、メニュー画面
イベントマネージャー
コミックデモ、ムービー
イベントシーン、ミッションシーン
などなど
●SandBox の特徴
SandBoxは独立しており、他のSandBoxに影響を与える事がないので
作業者は自分の管理している SandBoxだけを注意すれば良い
（バグったとしても、他の何かを壊さずに済む）
ゲームデータベースに シナリオ進行状態、各種フラグ、セーブデータに乗る情報 などが管理されていて
全てのSandBox は、ゲームデータベースを参照できる。
（SandBox同士がやり取りする場合は、SandBox経由）
手軽に 新しいイベントの追加、 仕組みの追加 ができた
共通スクリプト関数、各種テンプレート を用意して、量産効率を高めた
→ 初めてスクリプトを触れる人間でも 悩まずにできた
→→ 増員しやすい、スキル差が抑えられ 品質が均一に
-------------------------------------------------------------------
●実際のゲーム中のスクリプトの流れ
・例 タイトル画面
ゲームが起動すると、 プレイヤーキャラ と タイトル画面シーン の SandBox が生成される。
→ タイトル画面シーンSandBox は、タイトル画面の画面表示、BGM再生、メニュー処理 など 全て行う
→ ロードを選択
→ タイトル画面シーンSandbox は、ゲームデータベースに各種パラメーターを登録し
イベントマネージャーSandBoxを生成
その後、タイトル画面シーンSandBox は、自己消滅する。
→→ このように 各シーンを管理するSandBoxは、次のSandBoxに託した後 自子消滅していく作りになっている。
---------------------------
●イベントマネージャーSandBox について
ゲームデータベースの内容に基づいて、その状態に必要なSandBoxを一式用意する。
例） エピソード１３の開始状態だった とすると
イベントマネージャーSandBoxは
エピソード１３のイベント SandBox
エピソード１３の舞台の街 SandBox
エピソード１３用のモブキャラ SandBox
など 全てを生成。
エピソード１３のイベント SandBox に スタート信号を送る
その後、自己消滅
例） エピソード１３ をクリアした場合
エピソード１３のイベント SandBox が、ゲームデータベースに クリアしたと言う情報を書き込む
→ そして、イベントマネージャーSandBox を生成
→ イベントマネージャーSandBoxは ゲームデータベースを読み取り、エピソード１４のための SandBoxを準備する
例） 特別なイベントを持った人物に話しかけた場合
ゲームデータベース に 話しかけた と言う情報をセット
→ イベントマネージャーSandBox を生成
→ イベントマネージャーSandBoxは ゲームデータベースを読み取り コミックデモSandBox を生成
→→ コミックデモ開始
→ コミックデモ再生中の裏で イベントマネージャーSandBox を生成
イベントマネージャーSandBox は、コミックデモ終了後のシーンのための SandoBox を作っておく
-------------------------------------------------------------------
このように シーンの切り替え毎に 全てのSandBox を捨てて 作り直す と言うようにしています。
→ 生成に時間がかかるけれども、ムービーやコミックデモ を流している裏で行い
ローディング時間のような シームレスを阻害するような間を隠している。
しかし、ゲームオーバーからの復帰 チャレンジミッションが終了して通常のゲームシーン戻るとき のみ
ムービーやコミックデモで ごまかす事ができず 生成時間の間を生んでしまった。
→ 残念だけれども 構造上仕方なかった
( http://sekigames.gg-blog.com/Entry/243/ のまとめに戻ります）
『GRAVITY DAZE/重力的眩暈：上層への帰還において、彼女の内宇宙に生じた摂動』
携帯型エンタテインメントシステムゲーム機 PlayStation
Vitaにおけるオープンワールドゲームの作り方講演内容を 大きく２つに分けて まとめました。
スクリプトについて です。
（データの管理の手法 については http://sekigames.gg-blog.com/Entry/243/ ）
-------------------------------------------------------------------
●スクリプトについて
Ｌｕａを使用した。
→ 「GRAVITY DAZE」では、スクリプトで全ての要素を管理しているため 大変重要
→ 複数の LuaState を同時に存在でき、並列に動けるようにした。
・SandBox
スクリプト１つの実行単位
（SandBox ＝ LuaState ＋ オブジェクト管理情報）
・スクリプトは プランナーが書いた
●なぜ こうしたか？
基礎研究に時間を費やしたため、イベントの作成などの期間は （デバッグ期間など含め）１年ほどであった
その１年の中で
ストーリーミッション ２１個
チャレンジミッション ２０個
その他イベント
を作成と、短い期間で 大量のイベントを同時作成する必要があった
・開発環境
Ｍａｙａ イベントセンサー
各種配置情報 などを設定
ＥＸＣＥＬ 簡易データベース
静的データ
Ｌｕａ 具体的なイベントの動き
・専用ツールは無かった
→ ツール開発に コストを割けなかった
→ それなら 専用ツールを必要としない作り方を考えた
（Ｍａｙａ と Ｌｕａ のみで作成）
すぐに作成を開始でき、ツールのメンテナンスコストが かからなかった点は良かった
（ただし、より大人数で開発する場合や 追加コンテンツなどをこの先も作り続けるタイプの開発の場合は 不向きだろう）
-------------------------------------------------------------------
●ゲームの要素全てを SandBox にしている
プレイヤー、敵キャラ、オブジェクト
タイトル画面、メニュー画面
イベントマネージャー
コミックデモ、ムービー
イベントシーン、ミッションシーン
などなど
●SandBox の特徴
SandBoxは独立しており、他のSandBoxに影響を与える事がないので
作業者は自分の管理している SandBoxだけを注意すれば良い
（バグったとしても、他の何かを壊さずに済む）
ゲームデータベースに シナリオ進行状態、各種フラグ、セーブデータに乗る情報 などが管理されていて
全てのSandBox は、ゲームデータベースを参照できる。
（SandBox同士がやり取りする場合は、SandBox経由）
手軽に 新しいイベントの追加、 仕組みの追加 ができた
共通スクリプト関数、各種テンプレート を用意して、量産効率を高めた
→ 初めてスクリプトを触れる人間でも 悩まずにできた
→→ 増員しやすい、スキル差が抑えられ 品質が均一に
-------------------------------------------------------------------
●実際のゲーム中のスクリプトの流れ
・例 タイトル画面
ゲームが起動すると、 プレイヤーキャラ と タイトル画面シーン の SandBox が生成される。
→ タイトル画面シーンSandBox は、タイトル画面の画面表示、BGM再生、メニュー処理 など 全て行う
→ ロードを選択
→ タイトル画面シーンSandbox は、ゲームデータベースに各種パラメーターを登録し
イベントマネージャーSandBoxを生成
その後、タイトル画面シーンSandBox は、自己消滅する。
→→ このように 各シーンを管理するSandBoxは、次のSandBoxに託した後 自子消滅していく作りになっている。
---------------------------
●イベントマネージャーSandBox について
ゲームデータベースの内容に基づいて、その状態に必要なSandBoxを一式用意する。
例） エピソード１３の開始状態だった とすると
イベントマネージャーSandBoxは
エピソード１３のイベント SandBox
エピソード１３の舞台の街 SandBox
エピソード１３用のモブキャラ SandBox
など 全てを生成。
エピソード１３のイベント SandBox に スタート信号を送る
その後、自己消滅
例） エピソード１３ をクリアした場合
エピソード１３のイベント SandBox が、ゲームデータベースに クリアしたと言う情報を書き込む
→ そして、イベントマネージャーSandBox を生成
→ イベントマネージャーSandBoxは ゲームデータベースを読み取り、エピソード１４のための SandBoxを準備する
例） 特別なイベントを持った人物に話しかけた場合
ゲームデータベース に 話しかけた と言う情報をセット
→ イベントマネージャーSandBox を生成
→ イベントマネージャーSandBoxは ゲームデータベースを読み取り コミックデモSandBox を生成
→→ コミックデモ開始
→ コミックデモ再生中の裏で イベントマネージャーSandBox を生成
イベントマネージャーSandBox は、コミックデモ終了後のシーンのための SandoBox を作っておく
-------------------------------------------------------------------
このように シーンの切り替え毎に 全てのSandBox を捨てて 作り直す と言うようにしています。
→ 生成に時間がかかるけれども、ムービーやコミックデモ を流している裏で行い
ローディング時間のような シームレスを阻害するような間を隠している。
しかし、ゲームオーバーからの復帰 チャレンジミッションが終了して通常のゲームシーン戻るとき のみ
ムービーやコミックデモで ごまかす事ができず 生成時間の間を生んでしまった。
→ 残念だけれども 構造上仕方なかった
( http://sekigames.gg-blog.com/Entry/243/ のまとめに戻ります）
[2回]
2012年8月21日 にあった、ＣＥＤＥＣの講演についての記事です。
『GRAVITY DAZE/重力的眩暈：上層への帰還において、彼女の内宇宙に生じた摂動』
携帯型エンタテインメントシステムゲーム機 PlayStationVitaにおけるオープンワールドゲームの作り方
講演内容を 大きく２つに分けて まとめました。
主に データの管理の手法 についてです。
（スクリプトについてはこちら http://sekigames.gg-blog.com/Entry/244/ ）
-------------------------------------------------------------------
●まず オープンワールドの定義
ジャンル？
街を自由に移動できる？
ステージに境目が無い？
ロード時間に切れ目がない？
→ いろいろな物がシームレスに繋がっている と言う事
●『GRAVITY DAZE』のオープンワールド性について
・ゲームの世界が立体的な構造を持つ
水平方向に ±１ｋｍ
上下方向に ±７ｋｍ
の広さを持たせている。
（普通のゲームの場合 水平方向にのみ 世界が広がっているけれども）
・全方位アクション
重力方向を変える空間移動
主人公は壁に立てる。
→ 全方向に落ちて大丈夫なよう、コリジョンを設定
・大量のオブジェクトを配置
→ できるだけ壊せるようにした。
●オープンワールドのデータの持ち方について
ゲーム世界は、連続性のあるデータで構成されている必要がある。
→ 原点が１つだけ
プレイヤーの座標系も１つだけ
地形の連続性に従って、データを連続的に バックグラウンドで読み替えるように実装しないといけない。
-------------------------------------------------------------------
●オープンワールドを作るのは 難しい？
できるのだろうか？
→ やった事がない
（ボリューム的に） 作りきれるのだろうか？
（通常の開発では） ステージを分けるなどして、分割統治をしてトラブル解決するのだけれども それと全く逆のやり方だ
めんどくさそう、扱いにくそう
→ 特殊対応や、その場のごまかし が向いていない
全体として一定の水準を保たせた、厳しい品質管理が必要
全体ボリュームの見積がやりにくい
オープンワールドのゲーム作成は、チームにとって 大変なチャレンジだった。
●オープンワールドにして （結果的に）良かったこと
・世界は一つだけ と言う事
概念として 理解しやすい
一貫性に優れる
見た目の統一感
無駄な重複がない （一つの町に、同じ形の建物を置きたくない とか）
効率を重視するようになった
など、オープンワールドは 意外と良かった
-------------------------------------------------------------------
●広大な街を表現するデータ構造と読み込み戦略
・メモリに入りきらない
→ プレイヤーに移動に合わせて、エリア毎にデータを読み替えていく
→ ＡＡＢＢでエリア分割した。
（Axis Aligned Bounding Box 軸に並行な直方体)
・遠くまで見える
→ ＬＯＤが必要 （Level of Detail)
→ ワールドをツリー構造にして管理した。
・プレイヤーが高速で空を飛んで移動する
→ エリアを通り抜けた時や、読み込み遅延が起きた時に問題となるので
対応が必要
-------------------------------------------------------------------
●データ構造について
・ツリー構造にした
こんな感じ
エリア一つは 大体８０m
一つの街は、１２～３２個のエリアで構成されている との事
・アルゴリズム
（図は 灰色はダミーモデル 、青は 詳細モデル を示しています）
プレイヤーがエリア外に居る時、ダミーモデルを読み込む
→ 読み込みが完了次第、ダミーモデルを表示
プレイヤーが接近したら 詳細モデルを読み込む
→ ここで、子エリアのダミーモデルも読み込み始める
プレイヤーがエリア内に入ると、詳細モデルを表示する
→ 子エリアのダミーモデルを表示
近くにある子エリアの詳細モデルを読み込み
→ と、次々必要な詳細モデルを読み込み 出していく
（ダミーモデルは、詳細モデルを読み込み次第 捨てていく）
・プレイヤーが高速移動で通り過ぎた場合
→ 子エリアの読み込みを中止する
●まとめ
この仕組みはシンプルで、実装は容易だった
→ 概ね問題なかった
→ 後は データの調整、ブラッシュアップで うまくできた。
（重そうなところは エリアを分割したり など）
-----------------------------------------
●緊急読み込み処理 について
プレイヤーが高速移動している時に、データの読み込みが間に合わなかった時
→ 最悪、建物をすり抜けたり 壁に中に入ってしまったりする。
→→ 大問題
各エリアに「緊急読み込み発動領域」を用意した
→ このデータは 全てオンメモリ
→ プレイヤーが まだ読み込みが完了していない所の 「緊急読み込み発動領域」に侵入しようとした場合
ゲームを停止させ、データを完全に読み込み終了するまで待った。
（ゲームが 数フレーム ～ 数秒止まる）
→→ これは、あくまで緊急用処理
→→ 基本的には こういう事が起きないように レベルデザインを心がけてもらった
（しかし、メディアの読み込み状態に依存するため いつ問題が起きるかわからないので、必要な処理）
●最終的に どうなったか？
歩く速度なら 全く問題なし
もの凄い速度で飛ぶと （ゲーム終盤、キャラクターの成長によってなど） 間に合わない事も起きた
読み込みのスケジューリングの制御がうまくできない事もあり、１００％期待通りのスペックにはならなかった
→ 個人的には まだ足りない所を感じつつも、製品としては 問題ないレベル
→→ 今後とも 研究は継続して行っていく
-------------------------------------------------------------------
●パフォーマンスの最適化
とにかく 物が多い
→ 至るところで破壊可能
１エリアで １０００もの動くオブジェクトが
５０００ほどの背景オブジェクトがある
→ それらを全部ちゃんと動かしていたら、処理落ちでゲームにならない
・プレイヤーの周りの物しか動かさないようにした
→ プレイヤーの近くかどうか？ は、ＡＡＢＢによって判定
→ 近くにないオブジェクトは システムの大元から強制的に処理をさせないようにした
→→ プレイヤーから離れたオブジェクトは 地形を貫通するおそれある
（当たり判定チェックしないので）
遠くの敵はコリジョンチェックをせず、あらかじめ設定されたパスを動くのみ
物を遠くに投げた場合、遠くの電柱をすり抜けてしまったりする
→→ レベルデザイナー、ＡＩ担当者 は苦労した
プレイヤーから離れた場合、処理が行われない事を理解した上で 物を配置したり、ルーチンを書く必要がある
→→→ しかし、処理は物凄く速くなった！！！
●つまり
処理しない と言うのが一番早い
絶対的に数が多いので、思い切る所が必要
-------------------------------------------------------------------
●量産効率のためのスクリプトの利用
これについては、 http://sekigames.gg-blog.com/Entry/244/ にて まとめました。
-------------------------------------------------------------------
●まとめ
やってみて、オープンワールドのための 特別な技術 と言うのは無かった
（全て 既存のゲームで使う技術）
一番重要なのは、シームレスである事を 常に意識すること
「ＰＳ ＶＩＴＡで、オープンワールドを作ることは可能だ」 と言う事を証明することができた
→ 十分な性能、大きいメモリ、シリコンメディア
→→ オープンワールドは怖くない！！
『GRAVITY DAZE/重力的眩暈：上層への帰還において、彼女の内宇宙に生じた摂動』
携帯型エンタテインメントシステムゲーム機 PlayStation
Vitaにおけるオープンワールドゲームの作り方講演内容を 大きく２つに分けて まとめました。
主に データの管理の手法 についてです。
（スクリプトについてはこちら http://sekigames.gg-blog.com/Entry/244/ ）
-------------------------------------------------------------------
●まず オープンワールドの定義
ジャンル？
街を自由に移動できる？
ステージに境目が無い？
ロード時間に切れ目がない？
→ いろいろな物がシームレスに繋がっている と言う事
●『GRAVITY DAZE』のオープンワールド性について
・ゲームの世界が立体的な構造を持つ
水平方向に ±１ｋｍ
上下方向に ±７ｋｍ
の広さを持たせている。
（普通のゲームの場合 水平方向にのみ 世界が広がっているけれども）
・全方位アクション
重力方向を変える空間移動
主人公は壁に立てる。
→ 全方向に落ちて大丈夫なよう、コリジョンを設定
・大量のオブジェクトを配置
→ できるだけ壊せるようにした。
●オープンワールドのデータの持ち方について
ゲーム世界は、連続性のあるデータで構成されている必要がある。
→ 原点が１つだけ
プレイヤーの座標系も１つだけ
地形の連続性に従って、データを連続的に バックグラウンドで読み替えるように実装しないといけない。
-------------------------------------------------------------------
●オープンワールドを作るのは 難しい？
できるのだろうか？
→ やった事がない
（ボリューム的に） 作りきれるのだろうか？
（通常の開発では） ステージを分けるなどして、分割統治をしてトラブル解決するのだけれども それと全く逆のやり方だ
めんどくさそう、扱いにくそう
→ 特殊対応や、その場のごまかし が向いていない
全体として一定の水準を保たせた、厳しい品質管理が必要
全体ボリュームの見積がやりにくい
オープンワールドのゲーム作成は、チームにとって 大変なチャレンジだった。
●オープンワールドにして （結果的に）良かったこと
・世界は一つだけ と言う事
概念として 理解しやすい
一貫性に優れる
見た目の統一感
無駄な重複がない （一つの町に、同じ形の建物を置きたくない とか）
効率を重視するようになった
など、オープンワールドは 意外と良かった
-------------------------------------------------------------------
●広大な街を表現するデータ構造と読み込み戦略
・メモリに入りきらない
→ プレイヤーに移動に合わせて、エリア毎にデータを読み替えていく
→ ＡＡＢＢでエリア分割した。
（Axis Aligned Bounding Box 軸に並行な直方体)
・遠くまで見える
→ ＬＯＤが必要 （Level of Detail)
→ ワールドをツリー構造にして管理した。
・プレイヤーが高速で空を飛んで移動する
→ エリアを通り抜けた時や、読み込み遅延が起きた時に問題となるので
対応が必要
-------------------------------------------------------------------
●データ構造について
・ツリー構造にした
こんな感じ
エリア一つは 大体８０m
一つの街は、１２～３２個のエリアで構成されている との事
・アルゴリズム
（図は 灰色はダミーモデル 、青は 詳細モデル を示しています）
プレイヤーがエリア外に居る時、ダミーモデルを読み込む
→ 読み込みが完了次第、ダミーモデルを表示
プレイヤーが接近したら 詳細モデルを読み込む
→ ここで、子エリアのダミーモデルも読み込み始める
プレイヤーがエリア内に入ると、詳細モデルを表示する
→ 子エリアのダミーモデルを表示
近くにある子エリアの詳細モデルを読み込み
→ と、次々必要な詳細モデルを読み込み 出していく
（ダミーモデルは、詳細モデルを読み込み次第 捨てていく）
・プレイヤーが高速移動で通り過ぎた場合
→ 子エリアの読み込みを中止する
●まとめ
この仕組みはシンプルで、実装は容易だった
→ 概ね問題なかった
→ 後は データの調整、ブラッシュアップで うまくできた。
（重そうなところは エリアを分割したり など）
-----------------------------------------
●緊急読み込み処理 について
プレイヤーが高速移動している時に、データの読み込みが間に合わなかった時
→ 最悪、建物をすり抜けたり 壁に中に入ってしまったりする。
→→ 大問題
各エリアに「緊急読み込み発動領域」を用意した
→ このデータは 全てオンメモリ
→ プレイヤーが まだ読み込みが完了していない所の 「緊急読み込み発動領域」に侵入しようとした場合
ゲームを停止させ、データを完全に読み込み終了するまで待った。
（ゲームが 数フレーム ～ 数秒止まる）
→→ これは、あくまで緊急用処理
→→ 基本的には こういう事が起きないように レベルデザインを心がけてもらった
（しかし、メディアの読み込み状態に依存するため いつ問題が起きるかわからないので、必要な処理）
●最終的に どうなったか？
歩く速度なら 全く問題なし
もの凄い速度で飛ぶと （ゲーム終盤、キャラクターの成長によってなど） 間に合わない事も起きた
読み込みのスケジューリングの制御がうまくできない事もあり、１００％期待通りのスペックにはならなかった
→ 個人的には まだ足りない所を感じつつも、製品としては 問題ないレベル
→→ 今後とも 研究は継続して行っていく
-------------------------------------------------------------------
●パフォーマンスの最適化
とにかく 物が多い
→ 至るところで破壊可能
１エリアで １０００もの動くオブジェクトが
５０００ほどの背景オブジェクトがある
→ それらを全部ちゃんと動かしていたら、処理落ちでゲームにならない
・プレイヤーの周りの物しか動かさないようにした
→ プレイヤーの近くかどうか？ は、ＡＡＢＢによって判定
→ 近くにないオブジェクトは システムの大元から強制的に処理をさせないようにした
→→ プレイヤーから離れたオブジェクトは 地形を貫通するおそれある
（当たり判定チェックしないので）
遠くの敵はコリジョンチェックをせず、あらかじめ設定されたパスを動くのみ
物を遠くに投げた場合、遠くの電柱をすり抜けてしまったりする
→→ レベルデザイナー、ＡＩ担当者 は苦労した
プレイヤーから離れた場合、処理が行われない事を理解した上で 物を配置したり、ルーチンを書く必要がある
→→→ しかし、処理は物凄く速くなった！！！
●つまり
処理しない と言うのが一番早い
絶対的に数が多いので、思い切る所が必要
-------------------------------------------------------------------
●量産効率のためのスクリプトの利用
これについては、 http://sekigames.gg-blog.com/Entry/244/ にて まとめました。
-------------------------------------------------------------------
●まとめ
やってみて、オープンワールドのための 特別な技術 と言うのは無かった
（全て 既存のゲームで使う技術）
一番重要なのは、シームレスである事を 常に意識すること
「ＰＳ ＶＩＴＡで、オープンワールドを作ることは可能だ」 と言う事を証明することができた
→ 十分な性能、大きいメモリ、シリコンメディア
→→ オープンワールドは怖くない！！
[2回]
2012年8月20日 にあった、ＣＥＤＥＣの講演についての記事です。
「個性を持った将棋プログラムを目指してー強くするという目標を達成した後にー」
-------------------------------------------------------------
●はじめに
コンピューター将棋は ほぼ、十分強くなった。
２０１０年 女流王将 vs あから２０１０ で、勝利
２０１２年 永世棋聖（元名人） vs ボンクラーズ で、勝利
と、実力は プロの中堅程度
→ 強くすることは そろそろ終わり
強くなったコンピューター将棋の進むべき道は・・・
→→ 教育、解説、検討 など
→→ 今回のテーマは、楽しい将棋を演出する。
●楽しい将棋 とは？
接待将棋
→ 誰とでも いい勝負をする
人間に分からない程度に わざと悪い手を打つ
→ 鑑賞に堪える面白い対戦をする （良い棋譜を残す）
→→ コンピューター将棋に個性を持たせる
棋風
→ 棋風がある方が、興味を持たれやすい
（プロ棋士にも 棋風がある。 「光速流」とか 「緻密流」とか ）
-------------------------------------------------------------
●ＡＩ「あから２０１０」について
４つのプログラム（激指、ボナンザ、ＧＰＳ将棋、ＹＳＳ）の合議制（多数決）
→ ４つのプログラムには 個性があるように感じられた
→ 勝負としても、個性の存在がプラスになった可能性
（４つの棋風が バラバラに打ってくるので、読みづらくなってた）
●コンピューターにおける棋風とは？
コンピューターが打つ将棋には 棋風はない と言われているけれども
例） ボナンザ
→ ボナ攻め、ボナ囲い
（乱暴な攻め、特徴的な囲い 人間はまず打たない、特有な打ち方）
例） ボンクラーズ
→ 対戦した 永世棋聖コメント
「私が間違えるのを じっと手待ちしているわけです。
結局、最後に私が間違えてしまったのですが そう言う点では 大山康晴と対戦した感じですかね」
例） ４つのプログラムの傾向
ボナンザ ・・・ 派手・攻め 、 捌き重視 に突出
ＧＰＳ ・・・ 派手・攻め 、 捌き重視
ＹＳＳ ・・・ 駒得重視
激指 ・・・ 渋い・受け
と言う感じ
●棋風とは
人間がどう感じるか？
→ 対戦相手に個性を感じてしまう。
→ 個性を感じることで、愛着がわく
→ 棋風の数値化を試みることに
プロ棋士にインタビュー 棋風とは？
→ 経験に基づく、イメージのようなもの
直感的に指す手
戦略、戦型に依存しない打ち方
相手によって変化しない打ち方
→ 具体的に どういう物がある？
攻めか、受けか
直線的、曲線的
柔らかい、硬い など
→ 要素として どういう物が考えられる？
位置、動きに関する特徴
駒を使う頻度
自陣、敵陣に打つ駒の数 など
●駒の使い方を中心に、棋譜から特徴分析してみた
プロ棋士と、コンピューターＡＩとを見比べ
→ 全てのコンピューターＡＩは、桂馬と香車の頻度が高い
金の使用頻度多い
銀は「ＹＳＳ」以外 攻めの棋風に近い
ボナンザ 角の使用頻度少ない
激指 飛車 頻度少ない
ＧＰＵ 王をあまり動かさず、他のＡＩは よく動かす
など
●棋風 作れる？
→ この様に AIにも棋風はある と言えるが、
各プログラマは ＡＩを強くしようとして作っただけ
結果として 棋風が自然発生した。
→ 意図して 棋風は作れないのだろうか？
以下、各AI開発者より 各AIについての講演
-------------------------------------------------------------
●ＹＳＳ について
特徴： よくわからない局面では、受けを選ぶ
→ 受けつぶしに失敗すると そのまま敗北
受けつぶしに成功すると、相手はできる事がなくなり 投了せざる得なくなる
→ 人間には あまり好かれない棋風
なぜ、こんな棋風になったのか？
→ 水平線効果
→→ どうしても避けられない損害がある時に、それを避けようとして小さな損害を重ね
結果として大きな損害を被ってしまう現象
例） このままでは、飛車が取られる
→ 飛車を取られないために、歩を打って王手しよう
→ 歩を取られた！ けど、状況変わっていないので 結局、飛車が取られる
→→ 結果、歩を損しただけ
防ぐためには
→ 駒を捨てる手な場合 より深く延長して読む
駒を捨てる手は 初めから読まない
（駒を捨てる戦略が有効な時もあるので 難しいが）
一般的に 攻めの打ち方 と言うのは 初めに駒損する。
→ 駒得を重視するＹＳＳは 結果、守りの棋風となった。
-------------------------------------------------------------
●ＧＰＳ将棋
特徴： 攻撃的で 特に人間なら見送るような無理やりなても好んで指す
＜将棋プログラムができるまで＞
探索 ・・・ 王手や 詰みを深く読むようにした
↓
評価項目 ・・・ 王の周りを重視
↓ 攻め駒の数が、守備より多いか
↓
各項目の重みを棋譜から学習
→→ 探索、評価項目の部分の設定の仕方が ＧＰＳが攻撃的なＡＩになった大きな要因
・学習の過程で どこをどうすれば、結果 そのＡＩが強くなるのか？
は、プログラマ自身もわからない
→ ひとつ前のバージョンと対戦させてみて、勝ったら強くなっているので それを採用
後は、ボナンザなどの仮想敵となるＡＩと戦わせてどうなるか？
を繰り返す。
→→ 偏った変化に進んでいく
-------------------------------------------------------------
●ボナンザ
ボナンザの指針： チェスで成功している 力づく探索
（数の暴力に頼る方法で 強い将棋プログラムを作る）
評価関数： ５千万程度のパラメーター
詰め将棋、合議制などなど 一般的に将棋プログラムで使われているアルゴリズムは全て使用している。
→ 実際、強いプログラムで使われている技術は全て同じ物
学習で使用している棋譜も ほとんど同じ （世間に流通している棋譜は同じだから）
→→ では、なぜ違いが生まれるのだろうか？
→→ 開発思想 （YSSの場合、水平線効果を重視 など）
・学習の様子
ある手において、選択肢Ａ,Ｂ,Ｃの評価が ５，１，７ と得られたする
プロ棋士はＡと言う手を打ったならば、Ａの評価を上げ Ｃの評価を下げる
これをひたすら繰り返す。
・ボナンザ攻め、ボナンザ囲い について
棋風として定着しているらしく、Gogleで検索したなら ３万件、２万件 ヒットした
→ しかし、どちらも悪手である と言われる事が多い
→→ 仮説： 人間は 悪手にこそ個性を感じるのではないか？
「個性を持った将棋プログラムを目指してー強くするという目標を達成した後にー」
-------------------------------------------------------------
●はじめに
コンピューター将棋は ほぼ、十分強くなった。
２０１０年 女流王将 vs あから２０１０ で、勝利
２０１２年 永世棋聖（元名人） vs ボンクラーズ で、勝利
と、実力は プロの中堅程度
→ 強くすることは そろそろ終わり
強くなったコンピューター将棋の進むべき道は・・・
→→ 教育、解説、検討 など
→→ 今回のテーマは、楽しい将棋を演出する。
●楽しい将棋 とは？
接待将棋
→ 誰とでも いい勝負をする
人間に分からない程度に わざと悪い手を打つ
→ 鑑賞に堪える面白い対戦をする （良い棋譜を残す）
→→ コンピューター将棋に個性を持たせる
棋風
→ 棋風がある方が、興味を持たれやすい
（プロ棋士にも 棋風がある。 「光速流」とか 「緻密流」とか ）
-------------------------------------------------------------
●ＡＩ「あから２０１０」について
４つのプログラム（激指、ボナンザ、ＧＰＳ将棋、ＹＳＳ）の合議制（多数決）
→ ４つのプログラムには 個性があるように感じられた
→ 勝負としても、個性の存在がプラスになった可能性
（４つの棋風が バラバラに打ってくるので、読みづらくなってた）
●コンピューターにおける棋風とは？
コンピューターが打つ将棋には 棋風はない と言われているけれども
例） ボナンザ
→ ボナ攻め、ボナ囲い
（乱暴な攻め、特徴的な囲い 人間はまず打たない、特有な打ち方）
例） ボンクラーズ
→ 対戦した 永世棋聖コメント
「私が間違えるのを じっと手待ちしているわけです。
結局、最後に私が間違えてしまったのですが そう言う点では 大山康晴と対戦した感じですかね」
例） ４つのプログラムの傾向
ボナンザ ・・・ 派手・攻め 、 捌き重視 に突出
ＧＰＳ ・・・ 派手・攻め 、 捌き重視
ＹＳＳ ・・・ 駒得重視
激指 ・・・ 渋い・受け
と言う感じ
●棋風とは
人間がどう感じるか？
→ 対戦相手に個性を感じてしまう。
→ 個性を感じることで、愛着がわく
→ 棋風の数値化を試みることに
プロ棋士にインタビュー 棋風とは？
→ 経験に基づく、イメージのようなもの
直感的に指す手
戦略、戦型に依存しない打ち方
相手によって変化しない打ち方
→ 具体的に どういう物がある？
攻めか、受けか
直線的、曲線的
柔らかい、硬い など
→ 要素として どういう物が考えられる？
位置、動きに関する特徴
駒を使う頻度
自陣、敵陣に打つ駒の数 など
●駒の使い方を中心に、棋譜から特徴分析してみた
プロ棋士と、コンピューターＡＩとを見比べ
→ 全てのコンピューターＡＩは、桂馬と香車の頻度が高い
金の使用頻度多い
銀は「ＹＳＳ」以外 攻めの棋風に近い
ボナンザ 角の使用頻度少ない
激指 飛車 頻度少ない
ＧＰＵ 王をあまり動かさず、他のＡＩは よく動かす
など
●棋風 作れる？
→ この様に AIにも棋風はある と言えるが、
各プログラマは ＡＩを強くしようとして作っただけ
結果として 棋風が自然発生した。
→ 意図して 棋風は作れないのだろうか？
以下、各AI開発者より 各AIについての講演
-------------------------------------------------------------
●ＹＳＳ について
特徴： よくわからない局面では、受けを選ぶ
→ 受けつぶしに失敗すると そのまま敗北
受けつぶしに成功すると、相手はできる事がなくなり 投了せざる得なくなる
→ 人間には あまり好かれない棋風
なぜ、こんな棋風になったのか？
→ 水平線効果
→→ どうしても避けられない損害がある時に、それを避けようとして小さな損害を重ね
結果として大きな損害を被ってしまう現象
例） このままでは、飛車が取られる
→ 飛車を取られないために、歩を打って王手しよう
→ 歩を取られた！ けど、状況変わっていないので 結局、飛車が取られる
→→ 結果、歩を損しただけ
防ぐためには
→ 駒を捨てる手な場合 より深く延長して読む
駒を捨てる手は 初めから読まない
（駒を捨てる戦略が有効な時もあるので 難しいが）
一般的に 攻めの打ち方 と言うのは 初めに駒損する。
→ 駒得を重視するＹＳＳは 結果、守りの棋風となった。
-------------------------------------------------------------
●ＧＰＳ将棋
特徴： 攻撃的で 特に人間なら見送るような無理やりなても好んで指す
＜将棋プログラムができるまで＞
探索 ・・・ 王手や 詰みを深く読むようにした
↓
評価項目 ・・・ 王の周りを重視
↓ 攻め駒の数が、守備より多いか
↓
各項目の重みを棋譜から学習
→→ 探索、評価項目の部分の設定の仕方が ＧＰＳが攻撃的なＡＩになった大きな要因
・学習の過程で どこをどうすれば、結果 そのＡＩが強くなるのか？
は、プログラマ自身もわからない
→ ひとつ前のバージョンと対戦させてみて、勝ったら強くなっているので それを採用
後は、ボナンザなどの仮想敵となるＡＩと戦わせてどうなるか？
を繰り返す。
→→ 偏った変化に進んでいく
-------------------------------------------------------------
●ボナンザ
ボナンザの指針： チェスで成功している 力づく探索
（数の暴力に頼る方法で 強い将棋プログラムを作る）
評価関数： ５千万程度のパラメーター
詰め将棋、合議制などなど 一般的に将棋プログラムで使われているアルゴリズムは全て使用している。
→ 実際、強いプログラムで使われている技術は全て同じ物
学習で使用している棋譜も ほとんど同じ （世間に流通している棋譜は同じだから）
→→ では、なぜ違いが生まれるのだろうか？
→→ 開発思想 （YSSの場合、水平線効果を重視 など）
・学習の様子
ある手において、選択肢Ａ,Ｂ,Ｃの評価が ５，１，７ と得られたする
プロ棋士はＡと言う手を打ったならば、Ａの評価を上げ Ｃの評価を下げる
これをひたすら繰り返す。
・ボナンザ攻め、ボナンザ囲い について
棋風として定着しているらしく、Gogleで検索したなら ３万件、２万件 ヒットした
→ しかし、どちらも悪手である と言われる事が多い
→→ 仮説： 人間は 悪手にこそ個性を感じるのではないか？
[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ダイヤ]
カウンター
ついったー
