ユーザ用ツール

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン前のリビジョン
次のリビジョン		前のリビジョン
技術資料 [2024/02/20 06:53] – [条件語] araki技術資料 [2025/10/20 01:34] (現在) – [セーブデータファイル] araki
行 17: 行 17:
   * 音データファイル   * 音データファイル
   * メッセージファイル((QT版のみ))   * メッセージファイル((QT版のみ))
 +  * セーブデータファイル((保存された場合))
 ===== ゲームエンジン仕様 ===== ===== ゲームエンジン仕様 =====
  
行 182: 行 183:
 ===== 画面データ仕様 ===== ===== 画面データ仕様 =====
  
 +==== 部屋データ ====
 +
 +部屋データは、一部屋 0xa00バイト(2.5KB)からなり、各部屋は1KBの画像描画データおよび、0x500バイトの部屋固有のメッセージデータおよび、0x100バイトの特定のコマンドとメッセージとのリンク情報からなる。
 +
 +部屋にしても、ものにしても、FM-7上で、BASICを使って描画することを前提につくられている。
 +線を引き、色を塗るという動作を座標と色データの形で格納している。
 +
 +線の描画は繊細で、BASICで使っているであろうロジックに近しいもので描画しないと、色を塗るときの座標が想定している境界線とマッチしなくなる可能性がある。((実際PalmOSで実装したときに、内蔵の線描をつかったらpaintしたときに想定外のところが塗られてしまった。))
 +
 +このため、移植する際には、まずグラフィックスの描画ルーチンを実装し、データを実際に描かせてみてから先へ進めることにしている。
 +とはいえ、昨今は256x152のビットマップバッファを作って、それをターゲットの環境にレンダリングさせているだけなので、ほぼほぼ、問題なく動いている。
 +
 +=== 描画データ ===
 +
 +先頭には、トーンパターンが何色分定義されているのかが1byteで表されている。
 +トーンパターンは、1-6の色を指定されたパターンで置き換えるためのもので、カラーパレット機能のようなものである。
 +
 +その後ろに3バイト(BRG)のトーンデータが指定された数だけ続き、その後ろがようやく最初の描画データになる。
 +
 +描画を始める前に、描画域全体を青(色コード1)で塗りつぶす。
 +
 +(x,y)のポイントデータの羅列で、最初のペアから次のペアへの線を白(色コード7)で描いていく。
 +読みだした(x,y)がともに0xffなら線描パートは終わりである。
 +yだけが0xffの場合はそのペアを捨てて、次のペアを新しい始点として線を描いていく。
 +
 +続いて、(x,y,c)のペアで色塗りデータが続く。(x,y)ともに0xffなら色塗りは終了である。
 +
 +画像によっては、この後ろに、白線での輪郭描画、黒線での輪郭描画のデータが続き、最後にトーン処理を行う。
 +
 +トーンデータは最初に書いたように、パターン数+パターン数*3バイトのパターンデータとして登録されている。
 +最大で6 (カラーコード1-6に対応)のパターンがあり、対応するカラーコードを置き換えていく。
 +
 +PC-9801では、パターンデータのままに、縞模様を使った中間色画像として描画されたが、PalmOS以降ではそれらしい色に置き換えるように変更してある。
 +
 +PalmOSとAndroidには縞模様の中間色画像を表示する機能も付けてあるが、あえて表示する価値はないと思われる。
 +^ トーンデータ ^^^^^ 線画データ ^^^^^^^^^^^^^^
 +|n|t1(B)|t1(R)|t1(G)|...|x0|y0|x1|y1|...|xn|0xff|x0|y0|x1|y1|...|0xff|0xff|
 +
 +^ ペイントデータ ^^^^^^^^^ 白線データ ^^^^^^^^^^^^
 +|x|y|c|x|y|c|...|0xff|0xff|x0|y0|...|xn|0xff|x0|y0|x1|y1|...|0xff|0xff|
 +
 +^ 黒線データ ^^^^^^^^^^^^^^
 +|x0|y0|x1|y1|...|xn|0xff|x0|y0|x1|y1|...|0xff|0xff|
 +
 +== トーンデータ ==
 +
 +トーンデータは、3バイトを一組として、BRGの横8dot分のトーンパターンを定義している。
 +カラーコード1-6で描かれている部分をこのトーンパターンで置き換え、中間色表現による色表現を行う。
 +
 +要は、当該カラーコードのある点に対して、<code cpp>((b >> (7 - (x % 8)) & 1) | (((r >> (7 - (x % 8)) & 1) << 1) | (((g >> (7 - (x % 8)) & 1) << 2)</code> の色を置いていく(8色モードの場合)ことになる。
 +
 +なお、今どきの端末の多くはRGB565であったり ARGB8888であったりと、より多色を使った表示がかのうなので、あえて中間色を使う必要性は高くない。
 +
 +中間色は、要は、交互に色を並べることで、その中間の色に見せる(白+赤ならピンクに見えるように）というものなので、パターンのうち1が立っているビットの密度を数えて、それをB/R/Gそれぞれの色の輝度(0～7)と見なし、疑似的にRGB333の色コードとして変換、これをさらにRGB565やARGB8888に変換して表示している。
 +
 +
 +=== メッセージデータ ===
 +
 +メッセージデータは、部屋データのオフセット 0x500から0x500バイトの領域に配置される。
 +先頭からメッセージ番号0,1,2... と続く。
 +
 +メッセージは最初の2バイトがメッセージ長で、その後ろに長さ分のメッセージデータが続き、その後ろに次のメッセージが配置される。
 +メッセージはUTF-8でエンコーディングされている。
 +オリジナルとなったPC-9801版はShift_JISだったが、時代にそぐわないので、PalmOS版を作るときにすべてUTF-8にした。
 +メッセージ長はbig endianであるので、処理には注意。
 +メッセージ長0の文字列が現れたらメッセージは終わりである。
 +
 +メッセージ番号0のメッセージは、そのマップが表示されたときに表示されるメッセージで、それ以外のメッセージは、その場所で特定の動作をしたときに表示されるメッセージである。
 +その特定の動作は、コマンド・メッセージリンクで定義されている。
 +
 +^メッセージ長^^メッセージ^メッセージ長^^メッセージ^ ^終端マーク^^
 +|上位|下位|文字列0(UTF-8)...|上位|下位|文字列1(UTF-8)...|...|0|0|
 +
 +=== コマンド・メッセージリンク ===
 +
 +描画データのあと、オフセット0x400から0x100バイトのデータが、コマンド・メッセージリンクになる。
 +3バイト一組のデータで、動詞+目的語+メッセージIDである。
 +後続のメッセージ部のメッセージ数分だけのエントリーが存在している。
 +
 +その場所で、動詞+目的語の動作をしたときに、ID番目のメッセージを表示する。
 +
 +ただ表示するだけなので、ゲーム中で何ら作用を持たないものであることは明らかであるが、
 +こういう仕掛けを一所懸命しこんだであろう原作者たちの思いを表すものである。
 +
 +^リンクデータ0^^^ ^終端マーク^
 +|動詞|目的語|メッセージ番号|...|0|
 +
 +==== ものデータ ====
 +
 +ものデータは、落ちているものと○○先生の描画データである。
 +それぞれの描画データは0.5KBである。
 +
 +ものデータは、そのものがある部屋に来たときに、部屋の画像の上に表示される。
 +このことにより、任意の部屋にものを置けば、そのものが即座に表示されるし、拾えば即座に消える。
 +
 +なお、通常のアイテムの描画データの扱いは一意だが、先生だけは異なった処理を行う。
 ===== 語句辞書仕様 ===== ===== 語句辞書仕様 =====
 +
 +辞書ファイルは、0x200バイトの動詞領域および0x200バイトの目的語領域からなる。
 +語句は逆HAL符号((命名はわたし。))で符号化され、5bytesを一組としている。
 +
 +^0^1^2^3^4^
 +|符号化語||||意味|
 +
 +符号化語部分は最大4byteだが 0が現れたらその後ろは無視される。
 +先頭が0か0x200バイトを超えたらそれ以上はワードは存在しない。
 +
 +符号化されたワードをデコードすると英単語が得られる。
 +単語の意味するところは意味バイトが示している。
 +つまり、例えば look と see とに同じ意味バイトを割り当てることで、どちらの動詞が与えられても「見る」という意味として解釈できる仕組みになっている。
 +
 +目的語に関しても同様の構造になっている。
 +
 +===== 初期データ =====
 +
 +初期データは、以下の3つのパートからなる。
 +
 +  * マップ間のリンク情報(8bytes x 87)
 +  * アイテムの所在情報(12bytes)
 +  * フラグ(15bytes)
 +
 +スタート時に初期状態が読み込まれ、セーブ/ロード時にはこれらの情報が保存され読み込まれる。
 +つまり、ゲームのステータスのすべてはこの情報だけで完結している。
 +===== 音データ =====
 +
 +===== メッセージファイル =====
 +
 +
 +===== セーブデータファイル =====
 +
 +ゲームデータがセーブされるとセーブデータファイルが作成される。
 +セーブデータファイルはシステム間で互換性が保たれている。
 +ファイル形式で保存され、ファイルシステム経由でアクセスできる、M5版、Raspberry Pi Pico版、Windows版、Qt版、SDL2版、AvaloniaUI版では相互にセーブデータをコピーすれば他のプラットフォームでもそのままロードしてプレイすることができる。
 +
 +Web版は、ブラウザが管理するローカルDBに、Androidもシステムの提供するDB内に保存される関係で、他のプラットフォームとセーブデータをやり取りすることはできない。
 +
 +セーブデータは、コアシステムのワークとユーザデータ((マップ間のリンクデータおよびアイテム情報、フラグ情報))からなり、バイトデータの集合となっている。
 +データがすべてバイト単位であるため、エンディアンに関わらず、データに互換性がある。
 +
 +==== コアデータ ====
 +
 +コアデータはシステムの状態を保持している8bytesのデータ列である。
 +
 +^オフセット^内容^
 +|+0|現在のマップID|
 +|+1|ビューマップID|
 +|+2|直近の動詞|
 +|+3|直近の目的語|
 +|+4|選択された選択肢|
 +|+5|乱数値|
 +|+6|選択状態|
 +|+7|選択肢のメッセージID|
 +
 +多分、現在のマップIDとビューマップID以外は実は保存する意味はない。
 +
 +==== ユーザデータ ====
 +
 +ユーザデータは、マップ間のリンク、フラグ情報、アイテム情報の三つからなっている。
 +
 +=== マップリンク ===
 +
 +マップ間のリンクは、マップIDごとに、北、南、西、東、上、下、入、出の8bytesからなり、87部屋分のデータ配列となっている。
 +それぞれ、その部屋の各方向にはどの部屋がつながっているのかを部屋IDで表している。
 +
 +リンクはユーザの行動によって変化するので、断面データを見ても、ゲーム全体の正解ルートはわからないし、この先にどう変化するのかもわからないので、ゲーム攻略には多分使えない。
 +
 +=== フラグ ===
 +
 +フラグは、特定の動作が行われたかどうかや、消耗するアイテムの場合消耗度合いなどが記録されたデータで15bytesのデータである。
 +
 +=== アイテム ===
 +
 +アイテムは12種類存在している。
 +それぞれのアイテムがどこにあるのかの所在が記されている。
 +消費されて消えてなくなったのかどうかもここに記されている。
 +
 +データを改ざんして、すべてのアイテムを最初から所有している状態から始めることもできるだろうが、だとしても、それだけで攻略できるほどこのゲームはぬるくはない。
 +
 +仮にすべてのアイテムを保有した状態から開始したとしても、そもそも学校に入れないし、コアデータを改ざんして、学校内のどこかの部屋にいることにしたとして、それでもほとんどの行動はできない。
 +
 +アイテムを集めなくていいので行かなければならない場所は減るが、それでも必要なフラグを立てるための行動が求められるので、ほとんど難易度は下がらないだろう。
 +
 +
  
  

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also, you acknowledge that you have read and understand our Privacy Policy. If you do not agree, please leave the website.

More information