ローグライク攻略＆開発雑記

2023年12月16日22:00

カテゴリ: 変愚蛮怒; ローグライク

変愚蛮怒3.0.0 進捗状況 2023総集編 (技術編)

この記事はRoguelike Advent Calendar 2023 の16日目の記事です

https://adventar.org/calendars/9031

こんにちは、Hourierです

技術編と銘打っておきながら年末進行の都合でそんなに細かく書けない状態です

備忘録的な設計はGitHub のWiki にまとめているので、併せてご参照下さい

この1年何やってたかというと大半がリファクタリングです

まぁそれは3年前から何も変わっていないのですが、逆に言えば「3年経ってもまだまだ作業中」ということを意味します

3年あればどうにでもなるだろうというのは素朴に考えれば大抵合っていますが、残念ながら変愚蛮怒の泥沼は想像以上に深かった、ということです

単純に、ボランティアベースの活動であるが故に全員の作業スピードが不安定であることも問題の長期化に拍車をかけてしまっています

では今年のテーマは何だったのかというとズバリ「モデル化」です

この辺がその第一歩だったように思いますが、「フィールド変数がpublicなせいでどこでもget/setできる」という、非オブジェクト指向言語の欠陥を見事に踏み抜きまくっていました

「同一処理が何箇所もコピペされていて見通しが悪すぎる」という問題が起こり、その結果「何をやっているのか分からないので保守できない」に発展していました

「何十ファイルも同時に追跡しないとアイテム強化ルーチンを把握できない」とか

(これはC時代に分割しまくった名残でもありますが、当時は「ファイルが長すぎて誰一人読む気が起きないし誰も修正したがらない」というもっと重篤な問題が起きていました)

変愚蛮怒の前身であるZangband が更新停止した理由もこういう問題が遠因だっただろうという話は一度ならずDiscord でも出てきました

この辺りにようやくメスを入れ、「フィールド変数を外から引っ張り出してあれこれする」から「クラス内でできることはクラス内でやる」という、まともなカプセル化の道を歩み始めました

しかしあまりにも道が半ばで先は全く見通せません

多少でもコーディング能力がある方はぜひ開発チームにいらして下さい

むしろなくても1から教えます

去年の今頃に比べれば見違えるような綺麗さのコードにはなりました

それどころか「半年前のコードはもう見たくない」というレベルでモダナイズを続けているプロダクトでもあります

先進技術に触れてみたいという方も大歓迎です

Discord にてお話頂ければ誰かしら案内をするはずですので、ぜひ覗いてみて下さい

2023年12月10日21:00

カテゴリ: 変愚蛮怒; ローグライク

変愚蛮怒3.0.0 進捗状況 2023総集編

この記事はRoguelike Advent Calendar 2023 の9日目の記事です

https://adventar.org/calendars/9031

前日はだらだらさんの「秘術の特異点を実装した時に考えたことと考えなかったこと」でした

こんにちは、Hourierです

ブログ更新が年1になってすみません……~~HUNTER×HUNTER よりはマシ~~

GitHub にコミュニティ機能があったりコード差分が可視化されやすかったりで敢えてブログに書くほどの記事って中々ないんですよね

ということで年に1回しかできないこと──そう「総括 ~~in 榛名ベース~~」を行います

以下、「最新のコード」とは12/3 時点のβ2を指します

2023年最初のリリースはα74から始まりました

最新は上記の通りβ2です

αはホットフィックス (リリース直後に発覚した緊急バグの修正)も含めて91まで伸びました

またβは無印 (実質β0)から始まっています

途中夏休み等で開発メンバーが全員不在になってリリースが滞ったりもしつつ、合計21回のリリースを行いました

ちなみにGitHubでリリースノートがまともに整備されたのはα64、2022/07/31 のできごとです

色々集計しやすくなって便利の極みです

ということで簡単に集計してみました

予想通りというかバグ修正とリファクタリングばっかしてんなお前

リリース番号	リリース日	PR数	自分のPR数	新機能数	自分の新機能数
α74	01/08	21	4	0	0
α75	01/22	25	2	7	0
α76	02/05	4	0	0	0
α77	02/19	10	0	3	0
α78	02/21	2	0	0	0
α79	05/01	31	23	1	1
α80	05/02	3	0	0	0
α81	05/03	9	5	0	0
α82	05/05	5	3	1	1
α83	05/14	16	9	1	0
α84	05/28	25	15	1	1
α85	06/11	37	25	7	5
α86	06/25	27	7	2	0
α87	07/09	30	9	4	0
α88	07/23	17	9	1	0
α89	08/07	5	2	0	0
α90	10/16	25	10	1	0
α91	10/18	5	2	0	0
β0	10/30	10	4	0	0
β1	11/12	19	10	1	0
β2	11/26	8	4	0	0

合計：	N/A	334	143	30	8

今年1年のPR (Pull Request≒1作業)に占める新機能率は9.0%！

自分担当に限れば新機能率5.6%！！

世のオープンソースでこんなにリファクタリング率の高いプロジェクトはそうそうないと思います

~~(普通は目を引くために新機能追加するんだけどね変愚は無理なの)~~

さて新機能というか機能廃止も含まれていますが、自分の機能変更を列挙してみましょう

固定アーティファクトの追加 (トロルズベーン、黒のガラドリエル)
羊皮紙の追加 (洞察の魔法大全×3、アーティファクトの伝承×3、宝の地図)
ウィザードコマンド強化 (帰還、アイテム生成、モンスター生成)
全コマンド強制確認機能削除
256色以下のモニタサポート削除

……しょっぱいな！！

しかも固定アーティファクトはリファクタリングを目的に「取り敢えず埋めた」ってレベルの大したことない品です

羊皮紙に至っては「誰得の巻物」専用ドロップなので見たことがないプレイヤーもいるかもしれません

おまけに「洞察の魔法大全」も「アーティファクトの伝承」もタイトル以外未翻訳というふざけた有様です

どなたか翻訳して下さい、私は「最大999個まで羊皮紙を追加できる機能」を開発した時点で力尽きました

もちろん「開発者にしかメリットのないリファクタリングだけしていた」のではありません

例えば：

分離/合体ユニークを気軽に追加できる設計改善 (正常に動作するモンスター種族定義を添えて追加要求頂ければ1日以内にコード面は実装可能！)
休憩ターン数を始めとした数値入力プロンプト改善 (※ 長期の改善項目で複数バージョンに跨るため上記には載せていない)
いくらかの高速化 (体感できるかどうかは不明)
英語版対応 (英語だと何も表示されなかったり汎用メッセージだったのを日本語と同様に拡張)

嬉しいことに海外プレイヤーも時折GitHubやDiscordでコメントしてくれているので、少しずつ変愚蛮怒の輪が広がっているのを感じます

この調子でどんどん活気が出てくると良いですね！

(なお作業はまだまだ完了する見込みなし……正式版のリリースは未定です)

明日はまだ埋まってないよ！

みんなも記事を書いてみよう！

タグ：: #変愚蛮怒開発; #ローグライク

2022年12月17日23:00

カテゴリ

変愚蛮怒3.0.0 進捗状況 C++編

こんにちは、Hourierです

今回はプログラミング経験者向けの技術的な記事です

そうでない方は「変愚の開発は何か大変やなー」くらいに思いながら見てもらえると嬉しいです

記事の記述は12/17 00:00 のものです

まずは構造体＆クラスです

ちょっと復習：

C言語においてクラスはなく、構造体しかありません

大きな違いは、「構造体に、そのフィールド変数を作成・更新・削除するメソッドを定義できない」です

そして構造体とクラスの違いは、C++においてはほぼありません

「アクセス修飾子がデフォルトでpublicになる (構造体)かprivateになる (クラス)か」だけです

構造体から構造体を派生させたり、構造体に純粋仮想関数を定義したりできます

また、変数をスタックに積むかヒープに積むかはプログラマが自分で決められます

コピー代入か参照代入かも決められます

これらが、C#やJavaにはない特徴です (※1、※2)

v2.2.1 (5e4acf9)では、以下のコマンドで調べる限り、構造体が24個定義されていました

v2.2.1 と微妙に違うのは、この時期はコード整形が全くされていなかったため、可能な限りカウント数を上げられるように調整しているためです

grep -rn --include='*.h' --include='*.c' "struct.*{" | wc -l

v3.0.0 α版時点では、同様のコマンドで195個定義されていました

grep -rn --include='*.h' --include='*.cpp' "struct .* {" | wc -l

クラスは250個です

grep -rn --include='*.h' --include='*.cpp' "class .* {" | wc -l

上記の通りこの2つはC++においてほぼ同等のものなので、20倍近くに増えたことになります

これは何故でしょうか

そしてそれを調べる前に、何故「ほぼ同等のもの」が両方運用されているかについてお話します

理由は以下の2つです

・C言語時代に激長関数を分離する時、構造体を定義することで長い変数スコープをフィールド変数に押し込んだ (変数スコープが長いという問題は以前残り続けているものの、関数の見通しは100倍以上良くなった)

・言語をC++に切り替えた時、ある程度意味を持つ運用にした (後述)

これらの歴史的経緯により、「メソッドを持たなくて良いような単なるデータ集合」は構造体に、「メソッドを持たせて状態管理を行うデータ集合」はクラスに定義するようになりました

何となく自然発生的にそうなった記憶があります

話を戻すと、構造体が増えたのは以下の理由によります

要するに「24個全部神構造体」とかいう、ルルイエの旧神達も裸足で逃げ出す~~気の弱い女性はその名を聞くだけで卒倒する茨城県みたいな~~魔境だったわけです

ゲームシステムに直接関係しない構造体も積極的に定義し、1関数 (最悪値2400行！！)を分割した
ゲームシステムに直接関係するにも関わらず、構造体の中に長々と定義されていたフィールド変数群を別な構造体に切り出した

いくつも印象深いPRはありますが、いくつか挙げると以下の3つです

特にItemEntity::xtra1～5は、「メモリ制限がキツかった90年代にはある程度仕方なかったにせよ、エクストラとかいうふざけた命名のフィールド変数」には中々の殺意を覚えました

なお最悪は「my_fopen()」です、Zangbandのソースコードはプログラミングの教科書じゃねーぞ

https://github.com/hengband/hengband/pull/1548

https://github.com/hengband/hengband/pull/2197

https://github.com/hengband/hengband/pull/2841

C++へのコンパイルオプション切り替えは2021/05/02、α21版に行われました

そしてα22版からC++設計が本格的に始まりました

IRC時代から延々と議論がされていましたが、切り替えはその時まだ進みませんでした

具体的には以下の事由がありました：

C++で開発したくない心理的障壁
C#への切り替え要望 (主に私)
実際問題C++へ切り替えた時に出てくるであろうコンパイルエラー解消工数

しかし議論の場がDiscordへ移り、それに伴って、特に心理的障壁が新規開発者の流入でどんどん下がっていったことはおぼろげながら記憶しています

コンパイルエラー解消工数についてもその辺りで「頑張って背負おう」という話になっていきました

具体的には下記に挙げる予約語の調整が行われました

私はこの作業に直接携わっていませんが、メンバーによると「new」や「friend」という変数名がC++でのコンパイルを妨げていたとこのことです

その他諸々の微調整があったらしいですが詳細は私も知り及ばない部分があります

https://docs.oracle.com/cd/E19957-01/805-7888/6j7dtc219/index.html

そして大量の「ソースコードはC言語のまま＆ViewとModelは分離されないまま＆メソッドなき貧弱ドメイン構造体が大量定義されたまま」我々はC++時代に突入しました

構造体へ最初にメソッドを繰り込んだPRは↓です

https://github.com/hengband/hengband/pull/1016

この後、開発者の作業ペースや体調等の紆余曲折を経て、少しずつ基幹構造体 (src/system/ 以下の諸ファイル)へのメソッド注入は続きました

同時に、基幹構造体自体もC++化に伴って設計改善のために追加されていきました

この流れの中で、誰からともなく「メソッドが定義されたりコンストラクタが定義されているものはC++っぽくクラスと呼ぼう」という話が持ち上がりました

そのためには、単なるリネームで済む場合は良いのですが、場合によっては大規模なヘッダ順序入れ替えが必要でたいへん面倒な作業もありました

これらは気合と熱意で何とか処理してきた歴史があります

そんなこんなの事情でもって、構造体とクラスは我らが変愚蛮怒では混じっているという次第です

メソッド不要の単機能構造体は現在も不定期に増えており、変愚蛮怒から構造体がなくなる日は永遠に来ないと思われます

なお、ここまで長々と書いてきましたが、作業予定の方は順調に肥大化を続けております

本記事執筆時点で400個以上の未作業チケットが残っています

概ね週に10個程度のペースで増えていっている気がします

「絶対にC++のSTLで書き直した方が見通しが良くなる！」って思っても諸事情で中々進みません

主たる事情は「大作業を思いつく→コード調査をする→小作業が10個くらい出てくる→全部消化する→その頃には別な大作業を思いつく→以下無限ループ」です

部分最適をある程度進めないと、全体最適をかけた時にかなりの無理が生じるんですね

ただ日進月歩といいますか、部分最適はある程度進んできています

どこかの時点で加速度的に全体最適化を成し遂げるPRを複数出せる日は来るのではないかと想像しています

2024年頃には来ていると良いなぁ

無茶苦茶なバベルの塔を何とか穏便に解体するリファクタリング作業は、コンパイルが通らなかったり諸々のバグが起きたりして苦痛ですが、汚いコードが綺麗なコードになっていく快感じみたものは何物にも代えがたいものがあります

もし、「作業したい」でなくとも「詳細を知りたい」とか「今後の予定が知りたい」とか少しでも興味がありましたら、ぜひDiscordの開発チャンネルへお越し下さい

開発メンバー一同、両手を挙げて歓迎 ~~しつつ愚痴の延々とした垂れ流し~~すると思います！

※1 C#の構造体は以下のような特徴を持ちます

常にintと同様の値型であり左辺値へはコピー代入される (左辺値のプロパティを変えても元構造体のプロパティは変わらない。バグの温床)

継承できない

常にスタックへ積まれる (下手にListやDictionaryへ詰めると、ボクシングによりヒープとスタックを往復してCPU効率もメモリ効率も極度に悪化する。構造体しか使えない場合もいくつかあるので回避策もあるが、構造体かクラスか選べる状況下なら性能的例外を除きクラスで宣言するのがマスト)

※2 Javaには構造体という仕組み自体がありません。歴史的経緯・ネイティブコードとの相互利用・ネットワーク利用等の事情で似たような機能は色々ありましたが……

タグ：: #ローグライク; #変愚蛮怒; #開発