GearHead の迷宮。Mecha, メック, そして Mech / The Labyrinth of GearHead RPG
目次 (Index)
GearHead-1 の しみてい版 日本語化(v0.835) と らふ版 日本語化(v1.010+J0.01alpha4) と SDL版 日本語化(v1.100+JP008) の成果の集大成として、 原作最新版（執筆時点で GearHead v1.100）への対応、 「CUI」（原作では「ASCII モード」と呼ばれる）と 「SDL」と 「422氏&らふ（l0ugh）氏によって追加された表示モード(MS-Windows専用GDI使用)」の 表示３モード対応、 多OS対応、 多言語対応、 GearHeadスレ勇士達の助力の元にバグ修正、 各種ちょっと便利かもしれない機能を大量に追加、 任意のスクリーンサイズに対応、 各種チート機能を追加、 GearHead-2 から口径機能のバックポート、 不正なメモリアクセスを行うバグの治療、 を行いました。
I18N GearHead-1 is developped based on the achievement of the Original GearHead-1, the shimitei's branch, l0ugh's branch and a Group of Jpananese Spoilers branch.
I18N GearHead-1 can be used with a lot of languages and a many OS.
"Combining Character" (Devanagri, Thai, Japanese, et al.) are not completely supported. But "Precomposed Character" are supported. Please use "Precomposed Character" instead of "Combining Character", when "Combining Character" cause something incorrects.
And, "Languages written from the right to the left (bidi RTL)" (Arabic, Hebrew, Near Ancient Japanese, et al.) are supported, but not tested enough.
"Languages written from the up to the down" (Mongolian, Another style of Chinese/Japanese/Korean, et al.) are not supported.
CUIモード（ASCIIモード）とSDLモードが、 FreeBSD でも GNU/Linux系でも MS-Windows でも動作する様になりました。 Macintosh や Mac OS X や Solaris や OS/2 等は、 私が所有しておらず、 また開発協力者あるいは動作確認報告も登場していないので、 確認できていません。 GLモードは、やる気が無いので対応しません。 また、従来の日本語版にあったバグを、発見された物は全て修正しました。
I18N GearHead was tested on FreeBSD, GNU/Linux and MS-Windows 2k/XP. But, I18N GearHead was not tested on Mac OS X, Solaris and OS/2, because of I have no such OS or computers.
誤解しない様に長ったらしい注釈：(Features of each branches of GearHead-1)FreeBSD/i386 6.3-RELEASE では、ビルドして、 CUI, SDL 共に起動する事まで確認済。
FreeBSD/amd64 6.3-RELEASE では、 32ビット互換モードでビルドするか FreeBSD/i386 上でビルドした物が、 CUI, SDL 共に起動する事まで確認済。
FreeBSD/amd64 10-CURRENT では、 CUI, SDL 共に起動する事まで確認済。
MS-Windows win32（32bit系）では、ビルドして、 CUI, SDL 共に起動する事まで確認済。
GNU/Linux/i386 では、ビルドして、 CUI, SDL 共に起動する事まで確認済。
GNU/Linux/amd64 では、ビルドして、 CUI, SDL 共に起動する事まで確認済。
それ以降、プレイ中の挙動等は動作確認中……、 移植作業で力尽きました。
ロケールは EUC-JP と UTF-8 と CP932 を確認済。
Mac とか SunOS とか Solaris とか MS-DOS は、 試験できる環境が無いため未確認。
メックのデータや、シナリオのメッセージを自作する時の注意。
GearHead は、様々な計算機や色々なOSで動作する様に作られているので、 互換性の確保の為、注意が必要です。
コンパイル時に、よくあるかもしれないトラブル集：FAQ
コンパイルに必要な物：Required Softwares to Compile It
実行に必要なライブラリ： Required Libraries When Running GearHead
コンパイルの仕方： How to Compile
$ cd GearHead $ for FOO in *.pas *.inc *.pp */*.txt > do > mv $FOO $FOO.org > nkf -Lu < $FOO.org > $FOO > touch -r $FOO.org $FOO > doneを、csh系のシェルからなら、
% cd GearHead % foreach FOO (*.pas *.inc *.pp */*.txt) foreach? mv $FOO $FOO.org foreach? nkf -Lu < $FOO.org > $FOO foreach? touch -r $FOO.org $FOO foreach? endします。
% bzip2 -dc gearhead1100i18n.src.diff.bz2 | patch -p1 -N % bzip2 -dc gearhead1100i18n.txt.*.diff.bz2 | patch -p1 -Nとします。
% bzip2 -dc gearhead1100i18n.src.diff.bz2 | patch -p1 -N % bzip2 -dc gearhead1100i18n.txt.*.diff.bz2 | iconv -f eucjp -t utf-8 | patch -p1 -N内部処理用の文字コードを ShiftJIS にする場合は、
% bzip2 -dc gearhead1100i18n.src.diff.bz2 | patch -p1 -N % bzip2 -dc gearhead1100i18n.txt.*.diff.bz2 | nkf -Lw | iconv -f eucjp -t sjis | patch -p1 -N内部処理用の文字コードを CP932 にする場合は、
% bzip2 -dc gearhead1100i18n.src.diff.bz2 | patch -p1 -N % bzip2 -dc gearhead1100i18n.txt.*.diff.bz2 | nkf -Lw | iconv -f eucjp-ms -t cp932 | patch -p1 -Nとします。
% /bin/sh ./build.sh sdl clean buildとします。
% /bin/sh ./build.sh cui clean buildとします。
% ./arenaもしくは
> arena.exeLet's enjoy.
GearHead の存在を知ったのは 2005年下半期頃。 Roguelike方面で名前が出されていた。 どんな物か調べ始めたのは 2006年２月。 web で検索すると、JunkMetal（鉄屑）方面でも名前が出ていた。 でも手を出したのは 2008年２月だったり。 そして JNetHack for PC-9801 の時と同様、 移植を行う所から始まり……、 そしてまたもや移植で力尽きる。
バトルテックのブームにも メックウォーリアーのブームにも乗れなかったので、 メックのネタが、まるでわからない。
JNetHack に比べて、 日本語化データ集が大きい割に、 日本語化パッチが小さくてコンパイル時間がやたら早いと思ったら、 イベントやシナリオの処理は独自スクリプト言語を使っているのね。 その結果、プログラム本体は小さくなるけれども、 かわりにシナリオ・メッセージデータは大きくなっている。
……、そのキー配置は「ローグライク」では無いと思うのだが。 「ローグライクキー配置」といったら、 hjkl で、ついでに yubn、走る時は大文字。 テンキーを使う様では偽ローグライクキー配置。
そもそも GearHead って、 死ぬ様な目に遭っても死なない （救急病院に担ぎ込まれて助かった事になる）ので、 それは Roguelike ではないと言う話もある。 個人的には、 死んでも死なずにいくらでもやり直せる辺り Roguelike の本流ではないけれども、 ランダムなシナリオ、ランダムなマップ、ランダムな登場人物、と言った辺りで Roguelike の思想を受けているので、 Roguelike の傍流だとは思う。 それ以前に、Roguelike であろうがなかろうが、どうでもいいと思う。
本格派ローグライクキー配置を真面目に検討すると、 Look, Help, UseScenery, AddressBook の４つが、かぶる。 Help は ?、Look は /、UseScenery は a、AddressBook が +。 Attack, CalledShot, FullSpeed が、再びかぶって、 ……きりがないな。 まるっきり最初から再配置した方が良さそう。
……、こんなんでどうだろう。NormSpeed g 前進 FullSpeed G 全速前進 TurnLeft [ 左旋回 TurnRight ] 右旋回 Stop @ 停止 Dir-UpLeft y Dir-Up k Dir-UpRight u Dir-Left h Dir-Right l Dir-DownLeft b Dir-Down j Dir-DownRight n ShiftGears : ギアチェンジ Look / 調べる AttackMenu E 攻撃メニュー QuitGame Q ゲーム終了 Talk c 話す Help ? ヘルプ SwitchWeapon w 武器変更 CalledShot t 狙い撃ち Recenter C 中央表示 Get , 拾う Inventory i 持ち物 Equipment P 装備 Enter > 入る PartBrowser B 部位表示 LearnSkills W スキル習得 Attack A 攻撃 SelectMecha M メック選択 UseScenery a 周辺物使用 Messages x メッセージ SaveGame S セーブ Enter2 < 出る CharInfo \ キャラクター情報 FirstAid e 応急手当 ApplySkill Z スキル使用 Eject q 緊急脱出 Rest . 休憩 History V メッセージ履歴 FieldHQ I (メックの装備を変更) Search s 探索 Telephone T 電話 SwitchBV z 連射数変更 Reverse = 後進 SwitchTarget ; ターゲット変更 RunToggle - 速度変更 AddressBook r 電話帳 ToggleDrawWall 0 壁表示切替
ドアの閉め方が判らなくて、ソースとかシナリオデータとか探した。 UseScenery らしい。 ……、ドアの処理までシナリオマクロになっているのね。
あらためて思うが、日本語版の移植をした方々って、 よくこれだけの量を翻訳したものだと、つくづく驚嘆する。 GearHead の場合、他の Roguelike よりも特にメッセージが多いから……。
オンライン版ギアヘッドが欲しいと言うのは同意。 でもやる余裕など無い。 開発とプレイの両方の意味で。
まず、何はともあれ、ソースコード中に日本語を直接記述すると、 日本人以外には扱えなくなりますし、 違う OS を使っている人が扱えなくなります（再移植が必要になる）。 メッセージ分離型ローグクローンの要領で、 MsgString() 使うか、I18N_MsgString() を実装するかして、 外部ファイルに吐き出す必要があります。
上記の文中でも何度も言っていますが、 漢字を使う言語を UTF-8 で記述すると文字数制限が（略）、 ShiftJIS や CP932 で記述するとコンパイルできなかったり Pos() かますと日本語２バイト目を ASCII と誤判定して文字列データが壊れてしまったり 文字列の先頭からパースしないと文字の区切りが（略）、 ISO2022 はロッキングシフトの扱いが面倒だし 文字列の先頭からパースしないと文字の区切りが（略）、 EUC だと文字列の先頭からパースしないと文字の区切りがわからないし（略）、 UTF-16 な WideChar型はコンパイラの対応が不完全で表示できなかったり（略）、 さあ、どれがマシだ？。 文字列の扱いを、全て C型文字列に交換すれば文字数制限は無くなりますが、 ソースの変更量が莫大な量になります。 覚悟を決めて C型文字列に変更すれば、余計な制限は無くなるのですが。
ソース中の StatName や KeyMap など、 配列変数で記述されているメッセージは、 シナリオデータでの参照用タグとしても使われているため、 直接翻訳してしまうと、 プロット機能が動かなくなるとか、キーカスタマイズができなくなるとか、 問題が発生します。 よって、画面に表示する直前に、翻訳しなくてはなりません。
同様に、メックデータやパーツデータやアイテムデータやモンスターデータでも、 Name <> タグや Caliber <> タグなどは、 名前の定義だけではなく参照用タグとしても使われているため、 タグの内容をそのまま翻訳してしまうとシナリオが動かなくなります。 その為、GearHead-1 I18N では、 オリジナル表記のタグと、翻訳後のタグの両方を持ち、両方のタグを検索する、 と言う方針をとりました。
言語によって語順が違う為、 ReplaceHash() を多要素対応版に交換する必要があります。 オリジナル版の ReplaceHash() は語順固定専用なので注意、 メッセージデータを見ると一見多要素対応にも見えますが、 単に ReplaceHash() をネストして呼び出しているだけです。 ReplaceHash() を多要素対応にした後、 既存のメッセージデータも語順可変用に書き換えないといけません。
gears.pp の SAtt系関数では、< と > を特殊用途に使用しています。 文字列中に < や > が含まれていると、処理がこけます。 それから FormatChatStringByGender() では % を特殊用途に使用しています。
オリジナルの ExtractWord() は、スペース(#$20)を単語の区切りとして処理し、 １つの単語は１行の中で表示しようとします。 従って、日本語の様に、 文の先頭から最後尾まで一切スペースを含まない文字コードの場合、 １文丸ごと１行で表示しようとするか、 多バイト文字コードの途中で切ってしまうかして、 画面からはみ出たり文字化けを起こしたりします。
オリジナルの ExtractWord() の呼び出し側は、 単語毎に分割された文字列を再連結する際にスペースを挿入します。 よって、ExtractWord() を日本語・多言語化するだけでなく、 ExtractWord() を呼び出した側の再連結部分も 日本語・多言語化する必要があります。
オリジナルのままだと、文字列の表示に必要な幅を計算する際に、 Length() の返値をそのまま使っています。 多バイト文字コード対応の処理に書き換える必要があります。
オリジナルのままだと、文字列の表示がはみ出す場合のトリミング処理として、 Length() して Copy() している為、 多バイト文字コードの途中で切ってしまう場合があります。
上に述べてきた様な、「特に危ない処理」は、 texutil.pp に集中していたかと。
FreePascal の Write() や WriteLn() は、 OS によっては２バイト文字コードの表示に対応していない場合があります。 また、多バイト文字コード（UTF-8 や EUC の３バイト文字など）の表示には 一切対応していないと思われます。
ファイル名は、英数以外は適当にエンコーディングした方が無難かと思われます。
これまでのところ、翻訳する時、固有名詞は英語表記のままにする、 と言う方針が立っています。 翻訳担当者によって訳が違うとプレイしていて意味がわからなくなるし、 翻訳単語を決定するにも意見が乱立してまとまらないし、 r と l の違いがわからなくなるとか、 微妙なニュアンスが、とか。 色々あって。
そもそも根本的なプログラムの作り方の問題がありまして。 オリジナルのソースでは、 「とある一群の処理の最初に静的変数にポインタを代入してから、 分岐した先でその静的変数を使って処理を行う」 と言うソースの書き方が頻繁に行われているのですが。 ソースをじっくりと追いかけていくと、
ということを行っている問題があります。 世に「不正なメモリアクセス」 （英語に訳すと Memory Access Vulnerability かな？） と言われるものです。 ……。 これの完全で簡単な解決方法って……無いのだよね。 「スマートポインタもどき」の処理を実装するか。 地道に全てのソースを読んで治すか。 あるいは諦めて「プレイを終了するまでメモリ解放をしない」 ようにしてしまうか。 ……、 拙作版では、この３種を混合して対策としています。
win32 にて fpc-2.2.4以降を使うと、cui(ASCII)版にて文字化けしました。 fpc-2.2.2 を使って下さい。
すまん、あと何があったか忘れた。