toho-like-js のソースコードを読む 5
進捗
TalkState ClearState GameOverState ShootingState
わかったこと
StageState からは 各要素の Manager インスタンスを通して要素を操作する。
toho-like-js のソースコードを読む 4
進捗
StageState を読んだ
わかったこと
1.ビット演算子でフラグ管理するの便利(キーの押下、SEの再生等)
2. 画面各要素のマネージャーインスタンス初期化時に、initDrawerを呼んでる
3.キー押下は一旦 KeyFlagQueue に格納され、キュー先頭から使用されていく
StageStateが持つ各シーン
ShootingState
ゲーム画面
TalkState
ボスキャラとの会話シーン
ClearState
ステージクリア
GameOverState
ゲームオーバー
画面の各要素
BackGround
Fighter
FighterOption
Enemy
Boss
Effect
Bullet
Bomb
EnemyBullet
Item
SpellCard
各要素毎に下記のクラスが存在する
Drawer
Factory
Manager
View
Element
FreeList
わからんこと
1.lag の役割(恐らく multiplay 用だと思う)
2.KeyFlagQueue クラスの必要性(恐らく通信プレイの同期のため)
3.viewScore で本来の score から表示の際に調整入れてる理由
toho-like-js のソースコードを読む 2
進捗
LoadingState.js(ローディング画面)を読んだ OpeningState.js(オープニング及びStart・Replayセレクト画面)を読んだ GameState.js(各シーンの基底クラス)を読んだ
わかったこと
LoadingState.js
1.LoadingState で各画像, BGM, SEを読み込み 2.読み込みカウントが最大になったら、Game オブジェクトに通知 3.Game オブジェクトは通知を受けてシーン切り替え
OpeningState.js
1.中でさらにロゴシーン・タイトルシーンのインスタンスを持つ。 2. OpeningStateはそれらの管理を行う
toho-like-js のソースコードを読む 1
進捗
index.html を読んだ
Game.js を読んだ
わかったこと
1.index.html で Game インスタンスの作成及び run をしている
2.Gameインスタンスは各シーンの管理及び、BGMや画像、描画用canvasなどのグローバルなデータを管理している
3.Game インスタンスは requestAnimationFrame を再帰的に呼び出して再描画を行っている
4.Game オブジェクトは各シーンに引き渡され、各シーンのインスタンスから使用される
5.Game インスタンスが各シーンのインスタンスを持ち、各シーンインスタンスが Game オブジェクトを持つので、GCの実装によってはメモリリークする
6.シーンの切り替えは、Gameインスタンスのメソッドによって行う
各シーン
LoadingState.js
ローディング画面
OpeningState.js
オープニング画面
ReplaySelectState.js
リプレイ選択画面
CharacterSelectState.js
キャラクターセレクト画面
StageState.js
ゲーム画面
PostReplayState.js
リプレイ投稿画面
EndingState.js
エンディング画面
StaffRollState.js
スタッフロール画面
GameState.js
各シーンの基底クラス
情報処理学会のゲーム情報学の論文を読む
さいです。
ミーハーなので論を文して読み始めました。
情報処理学会で発表された論文は2年以上前の論文は
無料で読めます。最近の論文も、1つ600円ほどで
読むことができます。
言語が日本語かつ研究報告であればそれほどページ数も
多くないので論を文して読みたいみなさまの入門にも
便利です。
今日は2013年〜2009年頃のゲーム情報学の研究報告で
面白いのをちらほら紹介します。
コンピュータ大貧民における手札推定の有効性について
http://id.nii.ac.jp/1001/00092709/
コンピュータゲームの研究では、囲碁や将棋と同じ頻度で
大貧民も 研究対象として取り上げられる。囲碁や将棋が
完全ゲーム (プレイヤー同士が得られる情報が互いに同じ)
である一方、大貧民は不完全ゲーム(相手の手札など
一部得ることのできない情報が存在する。)なので。
機械学習を用いた棋力の調整方法の提案と認知科学的評価
http://id.nii.ac.jp/1001/00092712/
機械学習により将棋AIに「人間らしい」プレイを学習させる。
強いだけのAIではなく、人間がプレイしていて楽しいAIを
目指すアプローチ。
プレイヤの効用を学習し行動選択するチームメイトAIの構成
http://id.nii.ac.jp/1001/00090385/
人間がプレイして楽しいAIとして、上記論文は
敵AIについての論だったが、こちらは味方(チームメイト)を、
RPG形式のゲームを使って論してる。
完全プレイのためのデータベースのサイズの削減
http://id.nii.ac.jp/1001/00080940/
完全ハッシュ関数とウェーブレット木を用いて
「どうぶつしょうぎ」の完全プレイのデータベースを
846MB -> 54.8MB に圧縮する。
TCGにおけるシャッフル手法に関する計算機実験を用いた考察
http://id.nii.ac.jp/1001/00073008/
人間の手によるシャッフル方法には、ヒンズーシャッフルや
ファローシャッフル、ディールシャッフルといった方法が
あるが、それらをコンピュータでシミュレートして
ランダム性について実験した論。
強化学習による評価関数の獲得における報酬設定について http://id.nii.ac.jp/1001/00069716/
コンピュータがゲームを行う上で、コンピュータの取る戦略を
どのように評価するかを考えなくてはならない。
教科学習をゲームの評価関数として使用する場合、
その戦略におけるゲーム終了後の局面の勝敗を報酬として
評価し、途中局面の報酬を 0 とするのが一般的だが、
途中局面にも報酬を与えるとどうなるか実験した論。
将棋プログラムの大規模並列実行
http://id.nii.ac.jp/1001/00069710/
コンピュータ将棋プログラムは強力なマルチコアGPUと、
膨大な主記憶装置によって実行されることで、
プロ棋士を破るレベルの強さを実現している。
こうした1台のPCの性能に頼るのではなく、複数台のPCを
クラスタ構築して、演算を行う実験を論した論。
課題として通信遅延及び負荷分散が述べられている。
終わり
アブストラクトと結論だけ読んでてもそれなりに楽しい。
