MSX追懐記

3Dダンジョンロールプレイングゲーム　第24回目です。

さて、今回からは残りのスクリプト命令を組み込んでいきます。
これがないと、イベントが作成できませんので、先に全部組み込んでしまいます。
今回の3Dロールプレイングゲームで必要な命令は、残り6つ。


「GI」は、宝箱を開けた際に、青い鍵を所持させます。
「LI」は、青・赤鍵を使った際に、持ち物から消します。
「CI」は、宝箱とゲートで、それぞれの鍵を持っているかチェックします。宝箱のイベントのフラグを「CF」で調べても代用可。
「IS」と「IN」は説明要らずですね。
武器屋と道具屋は、売る物が異なるだけで命令は同じです。商品点数が多ければ、武器屋と防具屋を分けてもいいですね。
「BE」は、ボス戦闘を開始します。

まず事前準備として、以前に公開した「アイテムデータ登録ツール」で仮の道具データを登録します。
仮でもデータを入れておかないと、「IS」等ちゃんと動いているかのテストが出来ません。
同様に、「BE」テスト用に敵データも仮で登録します。

次回は、一番大変であろう「IS」を組んでいきます。

今回3Dロールプレイングゲーム作ってて気付いたんですが、私はマシン語でフロッピーディスクを制御したことがありませんでした。
おおー、驚愕の事実です。

そういえば、ファイルの読込などは全てBASICで行ってからマシン語コールしていたので、そう言われればそうかも。
ロールプレイングゲームなんかも、マップ変更する度に一度BASICに戻ってた気がします。

特にやり方が分からないとかの理由で、そうしていた訳ではありません。
それで困らなかったので、する必要がなかった、しようと思わなかった。というのが、正直なところです。

うーん、確かにマシン語からどうやってファイルを読み込むのか、知識として持っていない…。
今更そんな事に気付くとは…。
一度マシン語からディスク制御できるか試してみます。
上手くいったらLaboratoryのテーマに挙げようかな。

これが出来れば当時の自分を超えるのか！？

3Dダンジョンロールプレイングゲーム　第23回目です。

さて、開発順序として先に戦闘以外をすべて完成させる事にします。
前回書いた通り、戦闘のみ別プログラムにする可能性が出たからです。（2023年10月4日記事参照「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第21回」）

と、言う訳で今回は残りのスクリプトを組むための準備として、メッセージ中に変数の値を表示する仕組みを考えます。
メッセージ中に変数の値を表示とは何か？
代表的な例は、ロールプレイングゲームならば必須のステータス表示ですね。
あとは、戦闘時のダメージ表示なんかですね。

実は、この2例、表示方法が異なるのです。
ステータス表示は右詰め。
ダメージ表示は左詰め。
シューティングゲームの得点表示とは異なり、頭の「0」は消す「ゼロサプレス」も必要です。

以前に「Laboratory」でやった、Laboratoryテーマ��5「16ビットアドレス値の10進数表示」の表示部分を改造します。
そのままのロジックで表示させると、


これを改造し「ゼロサプレス」すると、


更に改造し、変数&HD005に桁数を代入しコールすると、指定桁数で右詰め表示されます。
桁数「4」で表示すると、


更に、変数&HD005に「0」を代入しコールすると、左詰め表示されます。


これが出来れば、ステータス表示（右詰め）や、店屋の商品値段表示（右詰め）、戦闘のダメージ表示（左詰め）等が出来るようになります。

改造内容は下記の通り。
16進数→10進数変換ロジックは、ほぼいじっていません。


表示ロジックは大幅に改造してあります。
直接VRAMに描き込まず、メッセージ表示ワーク内に、&HD005の値に応じて格納するように改造しました。

「ゲーム製作」カテゴリの、全記事の記事タイトルをルールに則って変更しました。（2023年10月6日記事参照「ゲーム制作記事タイトル記述ルール」）

「ダウンロード」のサンプルに、
Laboratoryテーマ��23「選択肢メニューを開いて、選択したい」その�@
Laboratoryテーマ��23「選択肢メニューを開いて、選択したい」その�B
のサンプルを掲載忘れていましたので、追加しました。

「技術資料」カテゴリを新設しました。
グローバルメニューにも追加しました。

「ダウンロード」に追加で新規公開したゲームやツール、サンプルの記事へのリンク追加、「Laboratory」テーマメニューの公開分記事へのリンク追加。

それ以外は、画像の貼り直しや、記事の誤記の修正程度です。

このブログは、MSXでのプログラミングをメインとしており、ハードウェア的な事に関しては解説しない方針でした。
（私の下手な説明より、解り易く詳細に説明されている方がたくさんいますので…。）
しかし、プログラミングの説明過程で、どうしてもハードウェア的な事も説明しなければならない時（主にBIOS等）は、表など用いて解り易く説明するよう心がけています。
ただ、せっかく説明したのに記事に埋もれてどこへ行ったのか分からなくなるともったいないので、新たに「技術資料」カテゴリを作り、インデックス代わりにリンク集を作ります。
技術的な記事が増えれば、随時追加していきます。

突然ですが、「ゲーム制作」カテゴリの記事タイトルの記述ルールを決めます。
現在、「3Dダンジョンの考え方〇」となっています。
ゲーム製作を始める際、何も考えず付けたタイトルですが、現在もこれが続いています。
これを、「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第1回」に変更します。
これだと一目でゲーム制作の記事だと分かるし、「BLOG RANKING」のように〇番号が表示エラーになるサイトでも、ちゃんと表示できるようになります。

本業が忙しく、余り時間が取れないので、他の記事の修正と併せて順次改訂していきます。
全記事改訂が終わったら改めて報告します。

うーん、他のカテゴリも解り易いように、タイトルにカテゴリ名を表記した方が良いかな？
時間があれば検討してみます。

3Dダンジョンロールプレイングゲーム第22回目です。
そういえば「詳細設計」と「シナリオ」を載せるのを忘れてました。

詳細設計とは、その名の通り詳細を決める事です。
具体的に言うと、敵を攻撃した時のダメージ値の計算式や、攻撃ミスの確率、会心の一撃の確率など、ゲームの根幹に係る設計の事です。
他には、
・アイテム毎の攻撃力や防御力、値段
・プレイヤーのレベルアップ時の能力向上値、魔法習得
・アイテム所持数（32個）、魔法習得数（6種）
・敵のパラメータ
など、多岐に渡ります。
これを決めておかないと、変数をいくつ確保するかなどが、決まりません。

ほぼ全てのパラメータ値を、今回は「ドラクエ�T」と同じで行きます。
計算式出展：『GCGX』
https://gcgx.games/dq1/damage.html
「攻撃力」＝「ちから」、「防御力」＝「素早さ÷2」で計算します。
あと、「ドラクエ�T」に兜はないので、盾の防御力と金額を半分にし、同値で兜を用意しました。

ダメージ計算


レベルアップ値


次に武器。（アイテム区分「1」）


次に盾。（アイテム区分「2」）


次に鎧。（アイテム区分「3」）


次に兜。（アイテム区分「4」）


次に道具。（アイテム区分「9」）


次に魔法。


最後に敵。


次にシナリオです。
今回はマップが小さいので、シナリオはほぼないに等しいです。
シナリオとは、要するに謎解きのようなものです。
何もないのも寂しいので、サンプルに一つ宝箱を用意します。
イベント数は6個。


ルートはこうです。
・道具屋さんに赤い鍵が売られている。（高額）
・宝箱がある。（ゲートで赤い鍵を使うまでは「何かある気がする。」で宝箱発見できず。）
・宝箱は赤い鍵で開く。
・宝箱の中身は青い鍵だった。
・道中、鍵のかかったゲートがある。（赤い鍵を使うと「遠くで何かの仕掛けが動いたような音がする…。」となり、宝箱が見付かるようになる。）
・ゲートは青い鍵で開く。

これを最初に考えておかないと、必要なアイテムや、イベントの配置場所が決まらないので最初に決めます。
ただ、最初は絶対に必要なイベントと、アイテムのみ決めておいて、後はそれに付属する形で決めていけばいいです。

以上で詳細設計とシナリオとなります。
実際はゲームに組み込んでテストプレイしながら値を調整していきますので、そこまでガチガチに決めておく必要はありません。
今回はすでにあるゲームの値をそのまま使っているので、調整も少なくて済むかと思います。

3Dダンジョンロールプレイングゲーム第21回目です。
前回、製作状況の進捗確認しました。
現在、BGM鳴らしながらマップ移動して、システムメニュー開いてメッセージを表示するまではできました。
後は大きく「敵との戦闘」、「プレイヤー関係」、「スクリプトの残り」の製作となります。

さて、ここで問題が発生しました。
プログラム見て気付かれている方もいるかとは思いますが、プログラム領域がなくなりそうです。
プログラム領域、&HC000~&HCFFFまでなのに、既に&HCA00まで使いました。
敵との戦闘、ただでさえ大きなロジックなので、&HCFFFまでではまず収まりません。
メモリ節約せずに突き進んできましたので、まぁ、仕方ないけど…。

解決策は2つあります。
�@変数領域を移動させプログラム領域を広げる。
�Aイベント進行は何とか残りのメモリでできそうなので、敵との戦闘だけ別プログラムにする。

実はどちらも大変です。
�@以前にも書いた通り、MSXには文字の置き換え機能がありません。
変数書き換えは、完全手作業なので大変です。
変換し忘れたら、当然暴走です。
ハンドアセンブルの厳しいとこです。

�A別プログラム化は、敵との戦闘になったら敵グラフィックの読み取りと同時に、敵戦闘プログラムもダウンロードし、実行する方法です。
まぁ、まだこちらの方が楽は楽かな…。

スマートな方法は当然�@です。
でも、技術的には�Aかな？（大した事ないけど…。）
イベント進行完成までに、どちらにするか考えます。

3Dダンジョンロールプレイングゲーム第20回目です。
今回はゲームの進捗管理をします。

【ゲーム製作進捗】

うーん、全体で30％と言ったところでしょうか…。
難関部分である、「敵との戦闘」が手付かずですので、まだまだ先は長いです。

MSXの良さって何だろう？
私はMSXとWindowsでしかプログラミングした事がないので大層な回答は出来ません。
しかし、SCREEN2のような独特な不便さ（8ドット毎2色）や、SCREEN1.5のような柔軟さはとても好きです。
MSX2のSCREEN5のような、解像度は低いが完全なグラフィックモードだと、今となってはMSXらしさがないと思うのは私だけでしょうか？

今回、本当に久しぶりにMSXで3Dロールプレイングゲームを作っていて感じたのですが、速度やらメモリやら画像やらの制約だらけの中での製作が、とても楽しく感じます。
逆に目新しささえ感じます。
MSX2で、SCREEN5以降を使うとMSX1での制約からはかなり解放されますが、私的にはMSXで開発する意味がなくなるので使いません。
もし、MSX2の機能を使うとしても、コナミの「スペースマンボウ」のようにSCREEN1.5を使い続けると思います。

画像出典: 『GameFAQS』　スペースマンボウ　MSX2版
https://gamefaqs.gamespot.com/msx/917251-space-manbow/images?pid=917251&img=6

色（16色→512色中16色）とSPRITE（横4枚並んだら5枚目以上は消える→8枚）、メモリ（VRAMの空き容量をメモリ化）の制約が外れるだけでも大きいです。

なにより、SCREEN5以降を使いゲーム製作するくらいなら、MSXではなくWindowsでゲーム制作します。