アルゴリズム
Last-modified: 2019-06-26 (水) 15:44:51
概要
- コトダマンみたいなゲームを作るためのデータ管理の考え方を列挙したページです。
誰の役に立つかは分かりません。
盤面の情報管理
- データを保存しておく枠を文字数×複数だけ変数として用意する。
考え方としては9行×7列みたいな形。
配列を用いるならまた別の考え方になりますが私自身が理解できてないので省略。
- 以下に書く管理方法はあくまで例のひとつなので自身が管理しやすいようにする。
1行目:入っているひらがなの情報。ここにひらがなが入っていない時だけひらがなを入れられる。
2行目:元から文字が入っていたかのフラグ
3行目:シールドの耐久値
4行目:ウォールの耐久値
5行目:トゲを踏んだ際のダメージ、トゲが無いなら0にする
6行目:ビリビリブロックを踏んだ際のダメージ、ビリビリが無いなら0にする
7行目:チェンジマスの有無
8行目:特定の文字に変えたいならひらがなを指定、この変数はチェンジマス用の処理に書いたほうがいいかも。
9行目:弱体マスの効果
- ここまでの例は「ひとつのマスに複数のギミックを仕込める」ようにするための管理方法なので、もし一マスに一つだけでいいのであれば以下のようにするだけで良い
1行目:入っているひらがなの情報
2行目:元から文字が入っていたかのフラグ
3行目:ギミックID
4行目:耐久値・作動時のダメージ
言葉のコンボ
- 辞書としてひらがなの一覧が入った物を用意
辞書は区切り文字や改行などを利用して区切るようにする
- 左から文字数分だけのひらがなの塊として取得
- 1文字目と2文字目のひらがな・盤面情報を取り出し、辞書にその単語が含まれているかを検索
辞書を区切っておかないと関係ない物がその言葉として処理されるので注意
- もし言葉があったなら、あった事を変数に記録しておく
- ただし元から置かれていた場合は処理をスキップする
置かれていたかどうかの判定は2行目の変数を加算して使うと楽
文字数と2行目の合計数が同じになったら処理をスキップ
- 3の処理が終わったら、3文字目を先ほどの検索対象に加算して再度処理をおこなう
- 最後まで処理が終わったら、1文字目の処理を消して2文字目から3の処理をおこなう
- 最後の文字が1番目になった時点で処理を終了
結果の出力はコンボ中にやったほうが演出関係の不都合が無いと思われる。
ギミック作動
- シールド
- コンボの際に元から文字が入っているかどうかを取得し、入っていれば以下の処理を実行
- シールドの耐久値が1以上かを確認
- 1以上ならシールドの耐久値を減らす
- トゲ
- トゲのダメージを取得し、1以上なら以下の処理を実行
- そのマスの両隣の詳細を取得し、トゲに耐性が無ければダメージを受ける
もし毎回取得するのが重いのであれば、マス情報にさらに変数を用意してその中にキャラ情報を格納しておく
- コトダマンだと0か1しかないですが、せっかくなので百分率にしてお守りみたいなのを使うと耐性を得られるみたいなのも面白そう
- ビリビリブロック
- 大体はトゲと同じ、ただし以下の部分を変える
- コンボの際に新たに置いた内容の総数を取得
- ビリビリガード持ちの数を取得
- (置いた数-ガードの総数)×ビリビリブロックのダメージだけHPを減らす
- 演出面を考えるとコトダマンのゲーム上のような個別で処理する(もしくは詳細をDBに入れておき演出時に読み込む)方式のほうが処理が楽、ただ拘らないなら上記のやり方のほうが楽なはず
- チェンジ
- ひらがなを置いた際にチェンジマスかどうかを取得し、チェンジマスであれば以下の処理を実行
- チェンジマスの処理を書いてある処理へ飛ばしチェンジを実行する
- 弱体
- ダメージを与える際に発動させ、ダメージを減らす
- ウォール
- コンボ処理の際に毎回ウォールの耐久値を取得
- ウォールがあるなら処理を終わらせるフラグを立て、ウォールの耐久を減らしたうえでそこで処理を終わらせる
ただしウォールが1マス目にあり終わりにウォールが無い場合は処理を終わらせないよう別の処理を書く
- もしコトダマンとは異なる処理にしたいなら以下のような内容をお勧めします。
1.ウォールの耐久値を取得
2.ウォールがあるならウォール用のフラグに1を加算し、ウォールの耐久値を減らす
3.処理を終わりにせず次の文字を取得し判定。この際にフラグに1を加算し2以上であればコンボ数およびウォールの耐久値を減らさないようにする
弱点判定(テーマ)
- 弱点管理用の変数を敵体数分、条件を満たす単語を記録しておく変数を用意しておく。
- 各コンボ判定時におこない、弱点であればその部分の弱点フラグを1にする。一括でやると全員弱点判定になりバグる。
- コトダマン式かもじぴったん式かで処理方法を変える必要がある。
- コトダマン式
- 弱点を満たす表記があったならそこで処理を止める。
- 弱点を満たす表記がなければ一番上もしくは一番下にある物を取得する。上か下かは処理方法によって変わる。
- もじぴったん式
- まず完全一致する語を全て抽出する。
同じ言葉はまとめて並べておくと処理が早くなる代わりにアップデートをする時はアップデート前の辞書情報を全て保存しておく必要がある。
- 弱点を満たす表記があるなら弱点を満たす語からランダムに指定する。
- 弱点を満たす表記がなければ以下のどちらかにて指定する。
- テーマが付いていない物を取得し、その中から指定。全てにテーマが付いているなら全ての中からランダムに指定
- テーマの有無に問わずランダムに指定
弱点判定(文字数・ワード)
- 文字数取得は少しだけ重くなるので予めフラグを立てておき、必要な時だけ処理するようにする。
- コンボ判定時に文字数を取得し、指定文字数以上であれば弱点フラグを立てる。
さらにワードが弱点ワードと同じであれば弱点フラグを立てる。
解放したことばの記録方法
- 色々やり方があるので作りやすい方法で作るのが良いと思います。
幾つか案および利点・欠点を挙げておきます。
- 解放したことばを保存するデータベースを用意し、単語と使用フラグを用意して使用フラグの状態に応じて内容を表示する方法。単語の追加はデータベースに直接追加し単語情報と使用状況のデータベースの並び順を同じにする。
- 利点:ゲーム中の処理速度を手軽に早くできる。製作環境によるが連番で保存できるので製作が楽。使用状況だけ保存しておけばいいので他の情報を別データベースから読み込め、情報側のデータベースを調整するだけで解放したことば側の情報を更新できる。
- 欠点:アップデート前とアップデート後で内部状況が異なる場合があり、アップデート前の情報を記録しておかないとデータがバグる。指定用のデータベースを用意すれば多少改善できるが処理に無駄ができる。
- 注釈:私が実際に使っている手法。アップデート後に辞書側の更新が必要なのも若干致命的。
- 解放したことばを保存するデータベースを用意し、登録されている単語と比較し登録されている言葉よりも比較対象が若ければその位置に解放した物を追加する。また既に登録されているならそこで処理を止める。
- 利点:保存用データベースの更新を必要としない。管理コストが高くなるが、「辞書に内容を含むか判定→その内容の情報名に設定したオブジェクトファイルを取得→内容取得」の順で処理できるので上の手法よりも高速化できる。
- 欠点:利点に書いた処理方法のように「一ヶ所に同音異義語をまとめて配置」しないと処理が遅くなる。ソート機能を付ける場合に記録しておかなければならない情報が増える。追加方法の都合で環境によっては処理速度を求めた製作が困難。
- 解放したことばを保存するデータベースを50音の数だけ用意し、上記のいずれかの方法をおこなう
- 利点:表示が若干早くなる。
- 欠点:データベースの数が無駄に増える。
- 注釈:2番目の手法と組み合わせた物を恐らくコトダマンにて使っている。
- 解放したことばを保存するデータベースと解放したかどうかを判定するデータベース、過去に一度でもソートしたか判定するフラグを用意し、解放したかどうかの判定で引っかからなかった場合に解放したことばの一番前か一番後ろに追加する。その後必要に応じてソートを行い、人が見やすいようにする。ソートしたかどうかのフラグは処理速度を上げる為に用いる。
- 利点:現在の解放数さえ取得できていれば、追加するという行為に対してのみ最も処理が早い。
- 欠点:ソート量が多いと処理に時間がかかるので効率は悪い。
- もしソート機能を入れるなら処理方法をよく考えておく事。処理方法にバブルソートなんて使おうものなら処理が終わるまでに1ヶ月以上かかります。(体験談)
一番楽かつ処理速度がそこまでかからない方法はIDの0番から順に処理していき、表示用のデータベースに突っ込む方法かと思われます。