■ [変愚蛮怒/開発][変愚蛮怒/スポイラー]激しく虚無招来

カオス領域の4冊目最高ランクの呪文「虚無招来」

• 虚無招来
  • 自分の周囲8マスいずれかに壁があると半径(14+d11 +レベル)の破壊(確率665/666) またはそのフロアの壁全て消失(確率1/666)の後, 100+d150のダメージを受ける. そうでない場合, 以下を順に.
    • 半径2, ダメージ175のロケットを8方向に打つ.
    • 半径3, ダメージ175の魔力の球を8方向に打つ.
    • 半径4, ダメージ175の放射性廃棄物の球を8方向に打つ.

地形を整備した状態で使うと、8方向連続ボール処理が結構な威力をはじき出してくれることは知る人ぞ知ると思われますが、今回のお題はこっちの方。

そのフロアの壁全て消失(確率1/666)

最終盤も最終盤で使えるようになる呪文で小並感の確率で発生する現象を調べるさらに物好きの＠さんも史上皆無ではないでしょうが、わざわざやるのはめんどい、ついでに言うならデバッグ上もチェックするのは色々しんどい。

ということでウィザードモードに新しく'@'で「任意のスペル効果を引き起こすコマンド」なるものを実装していくことを考えてみました。

実際に乱雑に実装され続けた各種のスペル効果全てを網羅するには結構手間と修正がかかりそうなので現状名ばかりですが、今回この処理を行うvanish_dungeon()関数を走らせてみた例をお見せしましょう。

これを実装したコミットはこ↑こ↓

おし、じゃあぶちこんでやるぜ。

デバッグコマンド許可後に、ctrl+aからさらに'@'を押します。

SPELL:とプロンプトが出るので"vanish dungeon"と通ずるっこんでやれば、該当処理を実行します。

左上から順番に崩れていくクッソ哀れな壁くんたち、ついでに目を覚ますモンスターくんたち。

全部一通り崩れてから視界も更新されます。

画面端の永久壁くんたちもこわれました。しかし、当然ながら進むことはできんようになっております。

大体こんな現象でした。以上。

関数名に関する余談

[Refactor] #38997 call_the_(void) に player_type * 引数を追加して call_the_void() 改名せざるを得なかった． / Add player_type * argument to call_the_(void) and rename to call_the_void() regretfully.

このコミットの通り、元々虚無招来の処理を実装していた関数は引数を持たなかったために、

void call_the_(void)

と小じゃれたセンスを醸し出していたのですが、今回延々と続くリファクタリングの観点から、player_type引数を付ける必要があり、このセンスを潰さざるを得ませんでした。ゆ る し て。

■ [ヴィーヤウトゥムノ]クラッコン先輩

■ [ヴィーヤウトゥムノ]色々バイクロプス先輩

■ [魚類版深夜の真剣お絵描き60分一本勝負]イトヒキエイ

■ [変愚蛮怒/開発]変愚開発日誌part300…Doxygenで2.2.1rから2.2.2-Refactoringの比較をちっとしてみる

はじめに

何かPart300とかになってますが、数え方いい加減な上に雑に続けてきただけなので何もめでたくないです。恥の多い開発を送ってきました。

去年のカレンダーで散々新要素にチャージマンとかマーフォークとか追加してたくせにそいつがバグ塗れだったり微調整だったり、単にサボっていたりで2.2.2リリース出来てません。

なにやってたんだヴォケと言われればリファクタリングです。必ずしもする必要はないのですが、将来の拡張性とか、ソースのライセンス絡みを更新するための書き起こし直しの検証とかを狙っていたりして泥沼にはまりました。

• 2.2.1r版直前のDoxygen解析(2.1.4表記は大嘘)
• 2019/12/06時点の2.2.2-Refactoring(2.2.1表記)

何年かぶりにDoxygenでデータ化したので何となく何やってきたか比較してみましょう。

ソースをそもそも分割したり整理してみている

• 変更前
• 変更後

2.2.1rくらいの時点で、もう200kB超えのファイルがだらだら並んでいたりしました。全くソース的に関係のないところに無関係の関数があったりしました。同じような、あるいは似たようなことをやる関数が別々に実装されていたり、もう辛抱たまらなかったので、切り分けたりしてました。

大体良くなったとは思うのですが、ヘッダファイルとソースファイルの宣言位置の齟齬とかはチケットで突っ込まれている通り、まだ残っていたりするので何とかします。

グローバル変数を各構造体にぶち込んで整理しなおした

• player_type変更前
• player_type変更後

グローバル変数上で関数の値渡しされていたりする悪夢とかは依然も何度か話した次第ですが、それに加えて

• どう見てもプレイヤー自身に属する要素がplayer_type構造体に含まれずにグローバル変数に放置されている。
• 逆に要らなさそうなのがplayer_typeに存在している

とか色々しんどいのが多かったのでこれを大分直したつもりです。

似たようなことをフロア構造体であるfloor_typeにもやったり、ゲーム全体に関する値はworld_typeとか突っ込んだりもしてます。

用語をあれこれ直した

例えば"cave"という表現が昔はあったわけですが、これが何を指すのかが

• キャラクター一個分のマス目を指す。(grid)
• フロア一つそのものを指す。(floor)
• 生成される部屋の中でも天然の洞窟状のものを指す。(generate_何たら付きの関数)

とか色々紛らわしいことになっていたので、()の通りに名称を変更したりしてました。置換処理に誤ってコメントの中身まで変えてしまった問題を外国人兄貴にチケットで突っ込み入れられたりしてます。大変申し訳ないと同時に、まだ注目してもらっている件を大変うれしく思ってもおります。

いつ終わるのかしら

正直まだわかんねえっす。これからのリアル事情と自身のおメンタルで大きくぶれます。ゆ る し て。