digger

• 主人公
• パーティメンバー
• モンスター
  • シンボルが種族を示す。ロボット、戦車、珠、ドラゴン、ライム
  • 種族・レベルごとの敵
  • ダンジョンのボス
• NPC
  • アイテム屋、装備屋、市民、合成屋

• 街を拠点に、遺跡の3つの珠を手に入れる

• ゲームは街からスタートする。街では売買でき、会話からヒントを得られる
• 遺跡のボスを倒すと珠を手に入れ、次の遺跡が選択できるようになる
  • ゾンビも考えたが、目標が生き残ることなので、方向付けの手間が増えそう。遺跡はわかりやすい
• 3つ手に入れるとラスボスと戦いゲームクリア
• クリア後は100階ダンジョン

• ローグライク
• シンボルエンカウント
• RPG的戦闘
• 合成

• 全体: 3つの珠を集める
• 短期: 敵を倒して先に進む、出口を探す
• 落ちているアイテムを拾ったり合成することでより強くする
• キャラを成長させる

• 種類の異なるダンジョンを進む
• 戦略的な動き。AIの挙動や地形を理解して、生存可能性を高める
• 数値を管理する。装備品や行動のボーナスをうまく使って生存可能性を高める
• 資源を管理する。重さ、装備品の制約があるなかで、生存可能性を高める

ゲームは様々なアイテムを含む。

• 防具。アーマー、服、帽子、靴
• 装飾品。指輪、お守り
• 盾
• 近接武器
• 銃器
• 消耗品。回復薬、栄養剤、ロケット弾
• 素材、売却物
• 食料
• キーアイテム。珠、鍵

アイテムには重さがある。 アイテムはテーブルにより決定する。

• 敵を倒すと経験値を得てレベルアップする
• レベルアップして能力が上がったり、生存に役立つより強力な方法を使えるようになる
• 階を降りるごとにレベルと難易度が上がる。たまにレベルより強い敵に出会うことがある
• 理不尽な偶然でプレイヤーを殺さない

• ゲームオーバーになった場合、得たアイテムやキャラクターを失う

• ASCII

• 一切ない

• Rust, rltk
• OpenGL, Web Assemblyに変換しブラウザでプレイできる
• ローカルでの実行形式もサポートする

• 無料で公開する

• プレイは英語
• ソースコードや開発用ドキュメントに日本語を含む

1章と2章に分ける。

• 1章: ストーリー性のある、低層の複数のダンジョン
  • ストーリー重視
  • 時間制限がある
    • 条件を満たしていないとゲームオーバー
    • 条件を満たしているとボス戦、勝利すると2章に突入
  • 仲間を増やせる
  • 仲間キャラクターに対する掘り下げ
  • 各ダンジョンではイベントによって進行する
• 2章: ストーリー性のない、1つの100階ダンジョン
  • やりこみ要素
  • より多様なアイテム、モンスター
  • ボス・イベントは存在しない

is_some() が便利。

if ecs.read_storage::<Player>().get(source).is_some() {
  ...
}

RLTKは同時に同じリソースを読み書きすることがないので、競合を心配する必要がない。read, writeが分かれているので、readだけだと並列実行して高速化したりもする。

ステータスを返し、単にシグナルに徹する関数がある。本処理はシグナルを元に別でやる、というような分け方。そうすることで責務の分離ができ、かつシグナル側で共通化しやすい。本処理は全く別だが、シグナル自体は共通のことは多い。たとえば、使う、捨てるなどのアイテム画面。各種アイテム画面で表示する中身は異なるが、返したい内容は選択アイテムで同じ。キーボードハンドルも共通。違いはアクションだけ。

• gui/cheat_menur.rs file is an easy refactor:

なぜできるかわからない。特定できないように見える。

let player_entity = ecs.fetch::<Entity>();

getで特定のpoolを取得できる。

let target_pools = pools.get(wants_melee.target).unwrap(); # targetにはEntityが入ってる

entityを削除する。

ecs.delete_entity(entity).expect("Unable to delete");;

entities.delete(entity).expect("Delete failed")

entityに付属したcomponentを削除する。

let entity = ecs.fetch::<Entity>();
combatants.remove(*entity);

let mut battle = ecs.write_storage::<Battle>();
battle.clear();

fetchを使って取得すると、個別に取るのでイテレーションできない。entitiesだとイテレーションできる。

let entity = ecs.fetch::<Entity>();

let entities = ecs.entities();

position componentをremove + InBackPackをinsertで、落ちているアイテムをインベントリへ入れた扱いにする。自由にcomponentを付け外せる。

for pickup in wants_pickup.join() {
    positions.remove(pickup.item);
    backpack
        .insert(pickup.item, InBackpack { owner: pickup.collected_by })
        .expect("Unable to insert backpack entry");

    if pickup.collected_by == *player_entity {
        gamelog
            .entries
            .push(format!("You pick up the {}.", names.get(pickup.item).unwrap().name));
    }
}

モジュールを組み合わせる方式でプログラムを設計する。

例えば、あまりよくないのは、敵という属性があってエンカウント可能にしたり、移動方法を決めることだ。それを、敵という属性、エンカウント可能という属性、移動方法の属性を作り、組み合わせて生成できるようにする。各機構は独立していて、変更しやすい。さらに、組み合わせることで新しい動きができる。

let player = ecs
    .create_entity()
    .with(Position { x: player_x, y: player_y })
    .with(Renderable {
        glyph: rltk::to_cp437('@'),
        fg: RGB::named(rltk::YELLOW),
        bg: RGB::named(rltk::BLACK),
        render_order: 0
    })
    .with(Player{})
    .with(Viewshed{ visible_tiles : Vec::new(), range: 8, dirty: true })
    .with(Name{name: "Player".to_string() })
    .build();

let monster = ecs
    .create_entity()
    .with(Position { x: x, y: y })
    .with(Renderable {
        glyph: rltk::to_cp437('g'),
        fg: RGB::named(rltk::YELLOW),
        bg: RGB::named(rltk::BLACK),
        render_order: 0
    })
    .with(Monster {})
    .with(Name{name: "Goblin".to_string() })
    .with(AiMove{})
    .build();

ファイルから読み取った値を元に生成できると、データとロジックを分割できる。

キューイング、リクエストと実装の分離。ダメージ発生、アニメーション発生、アイテム使用、をイベントとして同じように扱う。トリガー、対象、効果の組み合わせることで再利用性しやすくなる。リクエスト側は詳細を知ることなく扱えるため、コードが読みやすくなる。

なんらかのパラメータ変更を即座、何ターンかに渡ってもたらすものはeffect。永続的な属性、容れものを表すものはcomponent。がよさそう。

今はすべて1つのダンジョンになっていて、B2は森、B3は洞窟、というように固定されている。ダンジョンを選択して入るタイプとは合わないので、対応させる。

• 街
• ダンジョンA(B20)
• ダンジョンB(B10)
• ダンジョンC(B100)

というように最大階層も変えたい。街の出口で選択できるようにすれば良いか。クリアするごとに選択肢が増える。今のマップ関係の実装がよくわかってないんだよな。depthはあるものの、内部的なものっぽい。

現在のコマンドのstate遷移は複数の味方キャラに対応してない。

戦闘や行動によってスキルが上がり、生存に有利な補正がかかる。

4つのスロットがあり自由に装備できる。同じ部位の装備はできない。

たくさん拾ったときに表示があふれるので。複数あるアイテム系で共通の処理・表示・操作にしたい。

シードを指定すると同じマップを生成できる。デバッグで便利。

アニメーションを入れる。とくに戦闘に背景画像を設定してから、急に明度が変わるので目にも悪い。

自動テストをやりたいが、どうやったらいいのかわからない。ログをテキストファイルに書き出すようにすれば、チェックできるのでは。結局正しく挙動しているかはわからないが、実行時エラーにならないのはわかる。

cargo installでもすぐ実行できるようにする。

追加はchapter63が参考になりそう。

https://bfnightly.bracketproductions.com/chapter_63.html

周囲の概略を表示する。アイテム、敵、階段だけを視界内に限定すれば。

視野限定をやめれば、実装しなくてよさそう。

いまいち理解してないままだ。

ピンと来てない。

• レア度の実装
• 色を変える

探索がだるいので、可視状態にする。アイテムや敵は視界内でないと見えない。

アイテムを拾えない+階段が発見できなくなるので、階段上に生成しなくするか、常に階段を上に表示する。

いちいちentitiesから取り出すのが面倒。だいたいの場合戦闘用エンティティも絡むのでコードが複雑化する。簡単にアクセスできるようにしたい。

ロゴ表示とかするとそれっぽい。

ドラクエ8にあったような感じで。

カウンタに追加して、何かを達成した or 達成してない のバッジ型の実績を実装する。

死ぬと味方でもbattle entityが消えてしまうので、再生成しないといけない。味方は消さないようにしたいが。

動作確認用。いくつか前に戻って確認したいことが割とある。WASMを同じページに展開すればよさそう。

刀とかライフルとか。

実行すると強制終了する。

• 地形判定

同じ形にした。

• 単独RSpec
• カバレッジ

メッセージエリア、ステータスエリアなどウィンドウにエリアを追加する。

game_objectを構成するもの。直に起動されることはなく、object_poolにもaddされない。

今はすべてfield_stateでやっているが、characterのcomponentでやるようにする。

とりあえず敵をランダム移動できるようにする。

statsを作ってそこにmessageを入れることで対応した。

めんどいので。

その日の気分で書きがちなところに基準ができた。必須だな。

地形判定とは異なる。オブジェクト層で起こる反応。 game_objectとmapではやり方が異なる。

範囲がわかりづらいのでつけたいが、横方向がずれてる。 最初の一行だけ正しくて、改行以降はインデントがセットされてない、みたいな状況か。

 aaa
aaa
aaa

かな。

一行ずつ出力することで解決した。

2つ目state。 まだ内容はない。

対応の必要なし。

メインウィンドウにすべて表示してたが、分割したほうがやりやすそうなので分割する。 マップウィンドウ、メッセージウィンドウとか。

その場合、ウィンドウ構成がモードによって変わる。どうやって表現すればよいだろう。 うーん、やっぱり面倒なのでメインウィンドウに座標挿入でよさそう。

stateによって使い回せるしな。

バトルディッガーにしようとうっすら考えてたが、さすがに丸パクはできないので、混ぜよう。 そろそろどういう仕様にするか決めないといけない段階。

合成システムはカンタンに実装できて奥深そうなんだよな。 なのでシステム的にはディッガーよりハタ人間。

• アイテム合成

Press Start 2p

横幅的には一番

misaki font

日本語対応

updateはAIキャラが動かない。 drawは全員消える。

game_objectにupdate, drawメソッドがあると、componentのdraw, updateが上書きされるため起こる。 ai_inputはcomponentでupdateを使って入力を生成してるが、player_inputはbutton_downのため、問題が起きたり起きなかったりする。

drawでは機能しないのはなぜだ。処理の順番か。field_stateの処理の順番を並べ替えるとできた。 object_pool.draw map.draw の順番にしないといけない。

game_objectのアイテムと、所持品としてのアイテムをどう分ければよいだろう。 少なくとも単語を分けることが必要そう。

pickupはいいセンいってるが、動作っぽい。 まあいいか。後からどうするか明確になってからで。

表示文字をキャラによって変える必要がある。 inputによって分岐するようにした。

画面追加だけできした。あとはカーソル移動とかか。

CDDAみたいに、設定類はすべてjsonかymlにする。 キャラクターは完了。とはいえシルエットだけなのでそんなにパラメータはない。 一応はできたが、これがtype objectと自信がもてない。characterはマップのシルエットとして使うくらいだからあまり必要性ないんだよな。

getchでなんとなくターンぽくなっているが、移動以外でもターンが進んでしまう。 ターンが進むのは移動だけでよさそう。ローグライクだったら攻撃でも進むが、このゲームにはない。

player_inputかつ、移動ができたときだけexecuteフラグをオンにする。

カーソル移動はメンドイのでしない。

コードで直に地形判定をしているため。 地形用のクラスに切り分ける。 Terrainオブジェクトは状況非依存。つまり草地タイルはすべて同一。 なので、Terrainオブジェクトの格子にするのではなく、Terrainオブジェクトへのポインタにする。

• 地形情報にアクセスするために、worldから取る必要がなくなる。
• タイルから直にアクセスできるように。

まず文字列のマップをオブジェクトのマップにする。 どうやってやればいいんだ。

作ろうと思ったがどうしよう。どういったプロパティを持つか。

• アイテムの中身

とりあえずイメージしやすいように名前を取り出せるようにする。 フィールドオブジェクトしては名前くらいしか必要でない。

アイテムを拾ったとき、インベントリに追加する。 フィールドのはアイテムだが、それから別のオブジェクトにするか。

消費物、素材は単なる数値だが、装備はさまざまなパラメータを持った別オブジェクトだ。

単にオブジェクトを配列に追加するだけだが、仮で完了。

衝突関係がややこしくなってきたのでテストで確かめることにする。 アイテム、キャラクタ(Ai, Player)

オートプレイさせたい。 system spec的な。 実際のキーボード入力をシミュレートする。

今はgetchで止まるのでできない。直にbutton_downを受け付けるようにするとかできないか。 そもそもgetchがよくない説もある。アニメーションは一切できないからな。 入力は任意でよくしたい。入力しなくてもゲームループは進む。 ターンベースだろうと、ゲームループは回すほうが表現豊か。

テストのときはゲームループを手動で進めればよいのでは。 キーボード入力はできないが、直に入力すればいい。一応できた。

プレイヤーがいちいちbundle installとかしなくていいようにexeとか実行形式にしたいが、どうすればいいんだろう。 ruby-packerというのがあるらしい。 これで各環境用にコンパイルするようにすればいい。

大変そうなので断念。

素材系のときは、オブジェクトは保持せず単にカウントアップするだけにする。 武器とか消費アイテムはオブジェクトとして保持する。

item_typeにcountを保持することにした。やや不自然だが、itemから直に数を増やす操作ができたり、問い合わせがカンタンだ。いちいち初期化しておく必要もない。

今はそれぞれ別のオブジェクトになっているので、共通オブジェクトにする。 jsonで読んでそれを各自インスタンス変数に入れるみたいなことってできるのかな。一気に全インスタンスを配列に入れ、配列をインスタンス変数にするとできる。

正確にいうと、item_typeが共通である。itemオブジェクト自体はユニークである。取得して消えたり座標を持ってるから。

たとえば’c’はどのstateでも終了にしたい。

抽象クラスに移動した。

経路選択をどうすればよいのだろう。斜めにターゲットがあるときどうやってジグザグを判定するか。

戦闘モードへ遷移する。

まず戦闘のまえにこっちからやろう。 連れてる仲間、HP,SPを表示する。

接触したときにフラグを立てて、stateに入る。 wants_to_{}系か。 直にstateを変更するというより、フラグを使ってstateを間接的に移動する。 wants_to_meleeの個別要素にアクセスできない。

wants_to_attackを入れておいて、systemを一度回せばいいかな。 一度実行するたびにメッセージを表示して、enterの入力待ちにする。

今はエンカウントシンボルと敵が1対1なので、自由度が低い。 battle_entityを作って戦闘は完全にそっちに移す。

wants_to_encounterで元entityを保持してるので、そこから削除できないか。

• 既存の戦闘部分は使わないので消す
• 遠距離アイテムは消す

今は100％なので、確率で失敗してターンを進行させる。

2体いるときは2体で真ん中に、倒して1体になったら1体で真ん中寄せにする。

wants_to_meleeが残っていて、おかしくなっていたよう。 ターンごとに、リセットするようにした。 確実に前の状態を残さないようにするとバグになりにくそう。

現在は、combat_stats, monsterコンポーネントを持つものを敵の戦闘エンティティとしている…みたいな感じ。 わかりにくいので直したい。

combat_stats を持つ=戦闘エンティティで問題ない。monster, playerがあるのは区別が必要なので仕方ない。 なのでOK。

チュートリアルのパーティクルはマップ用。 positionにライフタイムのあるentityを配置して、擬似的にアニメーションにしている。 entityにすることで、map描画システムを使い、map上を上書きする形で表示できる。 戦闘ではprintしてるので、そのまま使うことはできない。printごとに座標計算して指定してるので、重ねるためにはロジックをコピペしないといけない。

builderの実装方法は参考になりそうなので、とりあえずコピペ追加。

戦闘に入るとダメージが反映される。 field_stateでdamage_systemが動いてないためだった。

チュートリアルの内容。 LEX paintがWINEでうまく実行できない。 変換ツールもうまく機能してないので、いったんチュートリアルのを流用して後回しか。システムだけ入れてコメントアウト。

分離した。影響範囲が広い。

装備品のownerがキャラになっていたため、インベントリに表示されてないというものだった。 装備中のものはownerが各戦闘用entityになり、装備してないとownerはplayer_entityになる。 party_entityとかにしたほうがいいかもな。 ややこしい。

hc = hunger_clock.get(entity);

のように、entityさえわかっていればgetで属性をコンポーネントを取得できる。いちいちforに長く書く必要がない。

戦闘関連のリファクタをした。あまりよくないな…。

コンパイル後のブラウザ表示。何回か試したが、うまくいってない。

ゲーム内容と関係しないので、追加しない。

• アイテムの色

dispatcher modelの導入。長い章。

呪い装備機能は追加しないので、ざっと見るだけ。

chapter65。回数や効果ターンは実装しない。効果のターン数は、後の戦闘でいりそう。フィールド画面ではいらないので、スルー。

原因不明。

thread 'main' panicked at 'Tried to fetch data of type "alloc::boxed::Box<dyn shred::world::Resource>", but it was already borrowed mutably.', /home/green/.cargo/registry/src/github.com-1ecc6299db9ec823/shred-0.10.2/src/cell.rs:268:33

スタックトレースを出して、怪しいところをスコープに入れると解決した。なぜコンパイラで検知できないのかはよくわからない。

Chapter66。アイテムなしで使用できる魔法を追加する章。覚えるアイテムを使うと、魔法が使えるようになるタイプ。これも後回しになりそう。今のところフィールドで何か使えるようにする予定はないが、戦闘で似たようなことをやるはず。

武器による状態異常なども実装している。

• マップを作成
• スポーンを改良(MasterTable)
• 複数タイルを専有するボス。当たり判定やAI調整
• レベルアップ時のステータス調整

該当しなさそうなので、ほぼ実装なし。

• 近寄ったときの自爆攻撃
• アイテム追加

• Chapter69
• 武器の拡張が参考になる
• アイテムのテンプレート。+1とか+2を別アイテムとしていちいち追加しなくていいようにする
• 武器のeffectを別にしてトレイトとしてまとめる。たとえばname: venomous, effect: [damage_over_time: 2“]と定義しておく
• トレイトとテンプレートを組み合わせて、多くのバリエーションを生み出す

• Chapter70
• 飛び道具

ターゲット周りがあまりよくわからない。あまり利用できそうなところはなかった。

ここでいうログは実績のやつ。セーブにも保存されるようにする。シンプルで参考になる。

• 現在のフォントでは長い文章を読みづらいので、ログだけ別のフォントにする
• まずrltkの全機能を知らないと、よりよい機能を選択できなそう
• フォント変えるとだいぶ印象が変わった。工夫のしがいがあるところに気づかないので、既存のものをプレイしてみる必要がありそう
• 巨大なguiファイルをモジュール分割

73章。systemをマルチスレッド対応にして高速化する。あとでやる。

マップ追加だけ。とくに見るところはないのでスキップ。

1ターン離れないと、敵が消えない。もう一度エンカウントすることはないので、何かしら違うのだが。

• run_systemを一度実行すると敵シンボルは消えドロップアイテムが見えるのだが、その座標に1ターン経過しないと移動できない状態になる
• run_systemsを2度実行すると自然な状態になる。よくわからない
• delete_the_deadがターンの関係で敵が消えてないのでは

生死判定、勝利判定でごちゃついていて、どこにあるかわからない。かつ、フィールドでのそれらと混ざっていて危険。

それぞれsystemに分割したが、うまく動かない。1ターン進めないと、死体が消えない、戦闘勝利判定が入らない。困った。ステートも切り替わらないな。ほかのシステムとの連動が、イメージと異なるようだ。

• 逃げるのは機構が別なのでできる。mainファイルから正しくstateが切り替わっている
• プレイヤーの体力判定も動いてない
• サンプルのdelete_the_deadもsystemになっていないことはヒントか。run_systemで実行せず、state共通で毎ループ実行するようになっている
• とはいえあとちょっとでできそうなんだよな。問題は死体が消えず体力が1ターンマイナスになることだけだ。ecs.maintain()をすると削除できるようになった。system内でのentity削除は、ecs.maintain()を実行しないと削除されないようだ
• とはいえ、アイテムドロップにecsが必要でsystemでどういう対応すれば良いかわからず

use super::{ gamelog::BattleLog, Attributes, Combatant, Equipped, InBackpack, LootTable, Map, Monster, Name, OnBattle, Player, Pools, Position, RunState, }; use specs::prelude::*;

pub struct DamageSystem {}

impl<’a> System<’a> for DamageSystem { type SystemData = ( ReadStorage<’a, Pools>, ReadStorage<’a, Player>, ReadStorage<’a, Name>, ReadStorage<’a, Combatant>, Entities<’a>, WriteExpect<’a, BattleLog>, WriteExpect<’a, RunState>, );

fn run(&mut self, data: Self::SystemData) { let ( pools, players, names, combatant, entities, mut log, mut runstate, ) = data;

let mut dead: Vec<Entity> = Vec::new(); // Using a scope to make the borrow checker happy

for (entity, pools, _combatant) in (&entities, &pools, &combatant).join() { if pools.hit_points.current < 1 { let player = players.get(entity); match player { None => { let victim_name = names.get(entity); if let Some(victim_name) = victim_name { log.entries.push(format!(“{} is dead”, &victim_name.name)); } dead.push(entity); } Some(_) => { *runstate = RunState::GameOver; } } } }

/ HPが0になったentityの削除 / entity削除をしても存在し続けているように見える for victim in dead { entities.delete(victim).expect(“Delete failed”); }

/ 勝利判定 / if maybe_win { / check_battle_win(ecs); / } } }

pub struct WinSystem {}

impl<’a> System<’a> for WinSystem { type SystemData = ( Entities<’a>, ReadStorage<’a, Pools>, ReadStorage<’a, Monster>, ReadStorage<’a, Combatant>, WriteStorage<’a, OnBattle>, WriteStorage<’a, Equipped>, WriteStorage<’a, InBackpack>, WriteStorage<’a, Position>, ReadStorage<’a, LootTable>, WriteExpect<’a, rltk::RandomNumberGenerator>, WriteExpect<’a, BattleLog>, WriteExpect<’a, RunState>, );

fn run(&mut self, data: Self::SystemData) { let ( entities, pools, monster, combatant, mut on_battle, mut equipped, mut carried, mut positions, loot_tables, rng, mut log, mut runstate ) = data;

let mut dead: Vec<Entity> = Vec::new();

if (&entities, &pools, &monster, &combatant).join().count() == 0 { for (_entity, on_battle) in (&entities, &on_battle).join() { dead.push(on_battle.monster); } }

for victim in dead { log.entries.push(format!(“You win!”)); entities.delete(victim).expect(“Delete failed”); *runstate = RunState::BattleResult; on_battle.clear(); } } }

stateがごっちゃになっているので別にする。systemは別でやる。

• 複数の型をとりうるとき、orってどうするんだ。enumで。
• stateのenumをネストしたenumにすればよいのでは、と考えたがうまくいかず

GUI部分に書いている。全体的に分離されてないので、分離。

• systemにしたところ、また逃走成功時のエンティティ削除がうまくいかない
• エンティティ削除部分が実行されてないようで、逃走成功メッセージが出ない + 次の戦闘時に2体表示される
• 逃走では即stateが切り替わるようになってるから、そのへんな気もする。systemを使う場合だと、wants_run_away生成→ターン処理→逃走となり実行タイミングがよくわからないことになる。delete_the_deadと同じように、ターン処理を待たずに即実行したい感じなのでsystemにしない

なぜかダメージが通らなくなっている。

攻撃主と対象が同じのため、ダメージが通らなくなっていた。腹減り時のeffectの攻撃主をNoneに設定して完了。

多くてディレクトリがわかりづらくなっている。チュートリアルの最終盤にあったがまだやってない。

表示データが異なるだけで、操作は同じなので。引数でデータを選択できるようにした。

フィールドUIと同じ形式で文字を表示する。フィールドUIはチュートリアルのリファクタで共通化されている。はずなのだが、旧の部分が残っている気がする。

ターゲット選択部分は同じ関数なのに、フィールドと戦闘で結果に差が出る。戦闘の選択肢がBから表示され、若干表示が乱れている。対象をプレイヤーに限定したらおかしくなくなった。どうせ今は味方にしか意味のあるアイテムだけなので良い。

将来的にはアイテムに対象を味方単体、敵単体、味方全体、敵全体という風にもたせて、アイテムごとでそれらのターゲット選択画面を出す出さないを決めたい。

一緒くたにbattle.rsへ入っていてわかりづらいので、フィールドと同様に分割する。とりあえずフィールドとの共通化は考えないが、すでにアイテム使用は同じ関数になっている。

guiディレクトリをbattle用、フィールド用でさらに分けてもいいのだが、そんなに意味なさそうな感じもする。battleはそんなに多くないからな。

いちいち敵を探すのがだるいので目の前へ召喚できるようにする。

単に名前を変えるだけ。魔法は出てこない。

ブラウザ版。ブラウン管の背景画像を設定し、透過させたらすごくそれっぽくなった。

メインメニューと戦闘の画面を設定する。戦闘の背景はステージによって変化させたい。

主要OSでビルドしてリリースに添付する。

• Linuxではwayland関係で実行エラーになる。Windows(wine)はうまくいった。クロスビルド用のライブラリを使えばよいらしい
• Macではうまくいかなかったので無視。crossのビルド対象になかった

use rltk::BTermBuilder;

const SCREEN_WIDTH: i32 = 80;
const SCREEN_HEIGHT: i32 = 60;
const DISPLAY_WIDTH: i32 = SCREEN_WIDTH / 2;
const DISPLAY_HEIGHT: i32 = SCREEN_HEIGHT / 2;

let context = BTermBuilder::new()
    .with_title("Dungeon Crawler")
    .with_fps_cap(30.0)
    .with_dimensions(DISPLAY_WIDTH, DISPLAY_HEIGHT)
    .with_tile_dimensions(8, 8)
    .with_resource_path("resources/")
    .with_font("dungeonfont.png", 32, 32)
    .with_simple_console(DISPLAY_WIDTH, DISPLAY_HEIGHT, "dungeonfont.png")
    .with_simple_console_no_bg(DISPLAY_WIDTH, DISPLAY_HEIGHT, "dungeonfont.png")
    .build()?;

• 複数のフォントを設定することで、敵をアイコンにしつつ、UIのアルファベットはそのままにできるようだがわからない
• 日本語表示は数が多すぎるため厳しいよう。フォントと画像をマッピングしている仕組みはどうなっているのだろう。ひらがなカタカナでも難しいように見える
• 開始ディレクトリが変わるためか、ビルドがエディタからできなくなる。シェルからやらないと、ファイルが見つからないエラーになる
• ハンズオンを見る限り、フォントは単一のサイズというわけではない。アイコンフォントはでかくして、普通の文字フォントは小さくすることができる
• consoleごとにfontを設定し、入力対象のconsoleを切り替えることで複数のfontを両立できる。重なり順がある
• エディタビルドはcompile時にプロジェクトトップに移動することでできる。cdしないとresourceを見つけられずビルドエラーになる
• wasmをreleaseビルドして、ブラウザで確認すると空白になっている。ビルドは成功する
• jsのエラーを見ると、やはりfont関係のよう
• 解決できそうにない+レイヤーの複雑化を避けるために画像はあきらめる。もともとマストでやりたいことは戦闘時の敵キャラの表示だったが、これはデフォルトで入ってるフォントを小さくしたうえでxpファイルを表示することで達成できる
  • とはいえこうすると、透過ができない。背景はぴったり表示するので問題ないが、敵画像でこれやるとかなりださい
• あるいは、バイナリ実行のほうがうまくいくのであれば一時的にwasmは放棄するのもありか。先にバイナリビルドを実行できる体制を整えたい
• with_sprite_sheet が使えそうな予感
• exampleを参考にして、ディレクトリ指定を調整すると解決した
• WASMビルド以外で横線が入るのが気になる。EXWMでだけ発生するようだ。cinnamon環境のwineとバイナリ起動だと、横線は入らない

味方のコマンド選択結果、敵の自動選択の攻撃方法の2つの可能性がある。計算に使いつつ、ログに表示する。

最初の一人分しか表示されなくて、何人いるのかわかりにくいので。

キーボードで選択できるのは素晴らしいが、アイテムの説明を見られないのに気づいた。カーソル移動を実装しないといけなそう。アイテムの効果に加えて、フレーバーテキストも入れたい。

アイテム詳細の共通ツールチップを追加する。

• x, y, entityをmenusで入れる。guiで表示処理する。menuでitemsを使って使用したx, yが重要になる。
• マップのtooltipの場合は、直に渡さなくてもpositionで後から求めることができる。tooltipを常に表示する部分と、tooltipを追加する部分の2つがある
• メニューアイテムのtooltipの場合は、x, yは後からわからない。表示しているのと同じ箇所で、tooltipを有効にする必要がある

それぞれのOSですぐ実行できるようにする。

アイテムの説明文。フレーバーテキストというよりは、ちゃんとした説明。

アイテムを拾ったり使うと重量が反映される。が、店で売買したときは変わらない。

売買時にdirtyを追加するようにした。が、一歩歩かないと再計算されない。とりあえずこれで良い。