MSX追懐記

3Dダンジョンロールプレイングゲーム第4回目です。
今回はダンジョンの描画パターンを考えていきます。
見える範囲を狭くしたのでパターンはかなり絞られます。
前回言った通り、エリアを5つに分けて考えます。


まず、右側�Xから考えていきましょう。
パターン１、壁がある。

パターン２、壁がなく�Wが壁

パターン３、壁がなく�Wの壁なし

この３パターンですね。
次に、右側�Wを考えます。
パターン１、壁がある。

パターン２、壁がなく、その先は壁

パターン３、�Vが壁

他パターンとして、「壁がなく、その先は壁なし」が考えられますが、これは最初に決めたダンジョンの構造上有り得ません。
このパターンが発生するのは正面�Vに壁がある場合のみですので、その場合パターン３となります。
と、言う事でこちらもこの３パターンです。
次に、中央�Vを考えます。
パターン１、�Vが壁

パターン２、�Vは壁なし、その先は壁

パターン３、�Vは壁なし、その先は壁なし

こちらも３パターンです。
�Tと�Uは、それぞれ�Wと�Xと同じになりますので、それぞれ３パターンです。
と、言う事は色分けした各エリアそれぞれ３パターンずつ、計15パターンの画像を用意すれば良いと言う事です。
次回はFONTを描いて、実際の画像をイメージします。

次はこれ。


大きめのアニメーションするキャラクタの種類をなるべく多く出してみました。
悪い癖が出て、ゲームバランス調整していません。

3Dダンジョンロールプレイングゲーム第3回目です。
今回はダンジョンの描画範囲を考えていきます。

まず、3Dダンジョンでどこまで先が見えるのかの範囲を決定します。
今回は描画パターンを抑えるため、2歩先の前面の壁までが見える範囲とします。


その先は真っ暗で見えなくします。
「もっと先が見えた方が良いんじゃないの？」と思われるかも知れませんが、演出的にもあまり先が見えない方が3Dダンジョンぽくていいのではないでしょうか？
しかも、範囲を広げると描画するパターン数が増えるので管理が大変です。
完成後プレイするとわかるのですが、手間をかけた程ゲーム性に影響がなくがっかりします。（経験談。自己満足感はあります。）
それよりかは、プレイする側としては迫力ある大画面（上部2/3）で高速な3Dダンジョン描画の方が、体感的にもインパクトが大きいです。
まぁ、近代建物系の3Dダンジョンなら、明るいので先まで見えないと逆に不自然かも知れませんが…。

では、2歩先までの描画なら、なぜパターンが抑えられるのか？
具体的に説明すると、まず、平面図に�ｂ�付け分かりやすくします。


次に、平面図に付けた�ｂﾉ対応する様に、3D図にも�ｂ�付けます。


これを見てもらえれば分かりやすいと思いますが、見える範囲を広げると、色分けしたエリアが細分化されどんどん増えていきます。
管理が大変といった意味お判りいただけたでしょうか？

では、次回は各パターンを考えます。

いよいよ高校3年生…。
進路について、考えなければならない学年なのですが…。
相変わらず、ゲーム制作を続けていました。
勉強もせずに！

私が通っていた高校は一応進学校でしたので、就職と言う選択肢はありませんでした。
就職組は、学年でも家業を継ぐ2名ほどだった覚えがあります。
大学へ進むか、はたまた専門技術を学ぶために専門学校へ進むか…。
今と違い、昔はそれなりの学力がないと大学へ進むことはできませんでした。（ボーダーフリーなんてなかったです。）
まぁ、他県には偏差値の低い大学もあるにはありましたが…。
私は数学が得意で、テストでも90点以下を取ったことがないくらいでしたが、それ以外の教科はボロボロでした。
（そりゃ勉強していないから記憶教科は、お察しの通り。）
特に英語。
「何で日本にいるのに英語なんか話さなきゃならんのだ！」って言ってた口です。
となると当然、全教科を学習しなければならない公立は無理です。
家の事情もあり家を出ることが出来なかったので、通える範囲にある大学は無理な国立大学か、私立文系大学、若しくは専門学校しかありませんでした。

と言う訳で、私はほぼ迷わずコンピューターの専門学校へ進むことを決めました。
その当時、コンピューター技術者が慢性的に不足しており、就職に有利になると考えたからです。
それに、プログラミング仲間がたくさんいるだろうと、根拠もなく思っていたりもしました。

現在、ツール集として「SPRITE EDITOR」「FONT EDITOR」「MAP8 EDITOR」の3種類を公開しています。
実は、開発したツール集は全部で9種類あります。
残りは


「MAP16 EDITOR」と「TONE ORGAN」のみ、今後公開予定です。
「VOICE RECORDER」は、当時流行った音声合成用のツールで、ラジカセからセリフを録音し、MSXにセリフをしゃべらせるツールです。（コンパイルの「魔導物語」などが有名）
今公開しても需要がないので非公開です。
「GRAPHIC TOOL」はMSX2以降用の、直線描きに特化したグラフィックツールです。
当時、私のSCREEN5でグラフィックを描く時の手順は、
�@紙に絵を描いて、サランラップに描き写します。
�Aそれをモニタに貼り付けます。
�Bサランラップの元線を、グラフィックツールでなぞって描いていきます。
だったのですが、グラフィックツールで元線をなぞる時直線を使うのですが、通常のグラフィックツールだといちいち直線ツールを選択しなければならず面倒くさいので、直線に特化したツールを制作しました。
ケベロンシリーズはこのツール使って描いていました。
こちらも需要がないので非公開です。
「ILLUST TOOL」は、MSX2以降用のSCREEN5の裏画面のデータをカラーパレット調整し保存するツールです。
例えば、あるゲームの裏画面の画像データを見たい時に使います。
用途的に怪しいので非公開です。
「COPY TOOL」は、単純なフロッピーディスク複製ツールです。
こちらも需要がないので非公開です。

まぁ、色々作ってたんだなぁと思います。

過去制作したゲームタイトルを一覧化しました。
イメージディスク化に成功したもののみです。
今後公開していくタイトルの予定表みたいなものです。



おおー、意外に多いですね！
因みに、この表に記載していない物も含めると70本以上のプログラムを作成していました。
未記載の原因の大半は、未完成。
どんどんグラフィックやBGMに凝って行った結果、1本のゲーム製作にかかる期間が延び、集中力が持続できなくなり、完成しないゲームが増えていきました。

こうしてみると、1989年の制作が少ない！
後日「MSX回顧録」でも書くことになると思いますが、まず、国家資格試験が4回ありました。
当然この勉強にかなりの時間を取られています。
あと、専門学校に行ってゲーム友達が出来たことで、この時期クリエイターからプレイヤーになったこと。（直接的な原因はこっち。）
翌年またクリエイターの友人が出来たことで、クリエイターに戻りますがこの頃は酷かった…。

とはいえ、ゲーム制作はしていませんがツールの製作はしていましたので、全く何も作っていなかった訳ではありません。
1989年から作り始めて、ツールとして実用化レベルになったのが1990年だったと言う訳です。（全ツール大体Ver.1.2から実用レベル）
あと、製作途中のツール使って、思いつく限りのゲームのSPRITEや、FONTデータ作りまくって、結局そのゲームの製作は開始しなかったのもこの頃でした…。

3Dダンジョンロールプレイングゲーム第2回目です。
前回EXCELで描いたイメージだと、最奥の描画が歪になるので描き直しました。（2023年5月29日記事参照「【ゲーム制作】3Dダンジョンロールプレイングゲーム　第1回」）

少し道幅を狭く見せる事で奥へ向かう角度を付けて、歪さを解消しました。
このイメージで決定します。

次に平面マップを考えます。
今回は、奇数行と奇数列を壁とするダンジョンとします。

オレンジが奇数行と奇数列です。

こうする事で、描画パターンを抑制することが可能です。
次回は3Dダンジョンの描画範囲について考えます。

　【 全記事 】　

先日お伝えしておりました、「Laboratory」カテゴリ。（2023年5月20日記事参照「細かく修正�D」）
ここでは、マシン語プログラミングでアルゴリズム等が難しそうな課題を取り上げ、それについて試行錯誤していきます。

とりあえず、いくつかマシン語初心者が悩みそうな（実際自分も初心者のころ悩んだ）テーマをいくつかあげました。
これらについて取り組んでいきたいと思います。
ただ、特にこの表に拘らず随時追加していく予定です。
可能な限りサブルーチン化して、ロジックの中に組み込めばいいだけの状態で公開しますので、マシン語の内容理解していなくても使えるようにしたいと思います。

次はこれ。
高校2年生最後の作品になるだろうと考え、力を入れて制作しました！


BIOS（CHPUT：&H00A2）が非常に遅いので、これを使わずVRAMに直接書き込む方法に変更する事で、処理速度の向上が図れました。
「POP」と比較してみれば一目瞭然。
POP（CHPUT）は全体的にもっさりしているのが分かると思います。
遂に移動する巨大ボスキャラを実装しました！
良い感じです。

昨日も書いた通り、私はハンドアセンブルでずっとマシン語のプログラミングをしてきました。
ここまでのサンプルプログラム等を見ていただければすぐに解ると思いますが、BASICにDATAでマシン語コードを書き、POKE命令でメモリに書き込む方法です。（2023年5月13日記事参照「SPRITE EDITOR 活用方法」）

確か「BASICマガジン」でこのやり方を覚え、それ以来ずっとこの方法でやってます。（2023年3月28日記事参照「いざ、プログラミング！」）
この方法は、特にツールが要らないので手軽にできるメリットがあります。
逆に、マシン語コードは16進数（2進数）なのでコードを覚えるのが大変なのと、後で見直す時、コメントがないとプログラムを追い難いデメリットがあります。

ハンドアセンブルで特に大変なのが、飛び先指定です。
アセンブラ言語だとラベルが使えるので、ラベル指定しておけばアセンブルした際、自動で飛び先変更してくれますが、ハンドアセンブルだと、いちいち指定しないといけません。
一番面倒なのが、機能変更等でプログラムの途中にコード追加になった時です。
プログラムの間にコード追加するとアドレスが変わってしまい、飛び先が全部変わってくるので絶対にしたくありません。（と言うか、長いプログラムで最初の方に追加となるとまず無理！）
なので、その時は追加になったプログラムを無理やりサブルーチン化するか、最後に追加して本来入れないといけない部分から飛ばずかの2択でやっていました。
これをやると、後から追うのが尚一層困難になってしまうので、可能な限りサブルーチン化していました。

今からマシン語を始められる方は、小さな部品的なルーチンならハンドアセンブルでいいと思いますが、長いプログラムを書く時はアセンブラ言語を使う事をお勧めします。