CALENDAR
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31     
<<  2017 - 01  >>

PROFILE
同人誌 電子書籍版
さよならハドソン


ドラクエとFFと
ToHeart


誰得ゲームライフ


ときめきメモリアル
の時代

イースI・II製作メモ

頒布ページ
頒布中
LINKS
NEW ENTRIES
CATEGORIES
COMMENTS
    スターソルジャー30周年記念(5)/終
  • いわさき (01/04)
TRACBACKS
OTHERS
SEARCH BOX
POWERED BY
POWERED BY
ぶろぐん
DESIGN BY
ブログンサポート

天外ⅡのCDROMはなぜ60分だったのか?
Twitterでつぶやいた話をちょっとまとめて置いておく。
このカテゴリ、書いたの久しぶりだ。
『天外Ⅱ』の容量は60分で出来上がっているのだけど、どうして60分になったのかについては書いたことがなかったので、忘れないうちにメモしておく次第。

『イースⅠ・Ⅱ』を作ったころ、すなわち1989年ごろのCDROM黎明期には、容量は時間換算で60分までしか使ってはいけないことになっていた。

当時雑誌などで良く書かれていた540メガバイトの容量は60分換算。
CDは1秒に75セクターのデータがやってくる。1セクタは音楽CDでは2352バイト、CDROMでは2キロバイト(2048バイト)。
なのでCDROMでは2*75=150だから、1秒150キロバイト。
150*3600(3600秒=60秒*60分=1時間)=540000キロバイト。
1000キロバイト=1メガバイト。
540000/1000=540メガバイトというわけだ。

本来、RED BOOK、つまり音楽用のCDでは74分入るわけで、どうして14分も短かったのか?
当時はCDの生産技術そのものも黎明期だったので、60分を超えて、トラック間が縮まるとディスクの読み取り精度が保証できないなんて理由だったと聞いていた。要はエラーが怖いからフルに使えないって話だ。

実際に『イースⅠ・Ⅱ』を作る時、72分のディスクを作ってくれと言ったら、最初は65分以上の量産経験がほぼなくダメだと拒否されて、交渉した結果70分でまとまったという経緯があるし、そもそも僕のプロのキャリアのほとんど最初のCD-iでもシカゴやデモインズで常にリードエラーと読み取り精度は問題とされて議論の対象になっていたので、リードエラーを恐れたって話は間違いないと思う。

と、ここまでは話の枕。



続きを読む▽
|| 21:24 | comments (1) | trackback (0) | ||

このエントリーをはてなブックマークに追加
1991年6月 仕様削減
「あーいいよ、季節のグラフィック削ろう。グラフィックはなくても成り立つんだよ」

市ヶ谷の天外2開発室で、開発のメインメンバーが集まって会議をしている中で、桝田さんが面倒くさそうに、少し投げやりな口調で言っていた。
僕は猛烈に機嫌が悪くなっていた。

山根がついにギブアップし、このままでは天外2のグラフィック(特にマップ)は間に合わないと言った瞬間だった。

オリジナルの天外Ⅱの企画では、全マップに季節があり(春夏秋冬)、イベントも季節に合わせて設計されていた。

だからシナリオは、秋の飛騨から話が始まり、冬の京都の北で絹と会って、春から夏に向かって進み、大文字で終わる、つまり桝田さんは季節の移り変わりを楽しんでもらうために、秋⇒冬⇒春⇒夏と、季節ごとに京都に戻ってきて、また出て行く、シナリオ上の構成をとっていた(なんでか夏からスタートするとか書いてたので修正)。

大きなカッコイイポイントとしては、秋から冬に向かう所で、京都の北に移動した所で大江山にたどり着く所で雪が降り、雪の大江山で絹を救い出す…なんて展開になっていた。


続きを読む▽
|| 20:46 | comments (0) | trackback (0) | ||

このエントリーをはてなブックマークに追加
天外2の復活する宝箱やフラグについて
最近(確か年末あたりだったような…)、ちょろっと聞かれたことで、天外2でどうして宝箱の中身が復活したり、砂に飲み込まれないように話しかけなかった村人も消えてしまうのか、について。

天外2のダンジョンやあちこちにある宝箱の中には「覚えているモノ」と覚えていないものがあったり、消えないように話かけなかった村人も消滅してしまうって仕様はPCエンジンのセーブデータの狭さに起因している。

PCエンジンのセーブデータは全部でたったの2KBしか容量がなく(2048バイト)、仮に全部使えたとして、かつビットのみでフラグを持つとして、そしてひとつしかセーブデータがない(他人が使わない)と仮定して、2048*8=16384個のフラグを保存することが出来る。

もちろん、on/offフラグはビット単位だw ビット単位のストリーム操作は基本だ。
そして、こんだけあれば…と思うかも知れないが、セーブファイル1個はマズいし、全部使い切るのもマズい。

そして天外2は5つのセーブデータを持つのが仕様。
(これは確か桝田さんか広井さんの要望で4人家族全員がプレイして一個余るって設定だったはず)

続きを読む▽
|| 22:04 | comments (6) | trackback (0) | ||

このエントリーをはてなブックマークに追加
天外Ⅱの戦闘システムについて(3/終)
前回、「どうしてフェイズ戦闘システムだったのか?」という話を書いたけれど、少し付け加えておくことがある。

フェイズ型の戦闘の眷属の中で、ファミコン版FFシリーズはウィザードリィの要素や他にもいろいろ加えた結構複雑なシステムだった、ということ。
FF1では先頭から順に攻撃されやすいというルールが入っていたし、FF2では前列・後列と攻撃範囲・弓矢や魔法と手持ち武器の違いといったものが入っていた。
これは多分、ドラクエと差別化するためだったと思うのだけど、これが後のATBといった複雑なバトルに進んでいく一因になったと思う。

と、ちょっと追加したところで、前回の話の続きで、今回とも関わる原理的な話を書いておく。
それは『フェイズ型の戦闘の行動解決の順序ってのは、なんなんだ?』という疑問だ。
例えば6秒1ターンで、全員がヨーイドンで動くなら、全員同じタイミングで動き出すはずだ。
だとすると「行動順序ってなんなのよ?」という疑問が出てくる。
これに対して、例えばスタート時の反応だって答えを出すことも出来るけれど、6秒に一度ずつヨーイドンしてるってのも、ムリクリも度が過ぎる。
そして、実はこの質問に対してゲームデザイナーからの答えが書かれている文を見たことがない。
どうしたってペーパー&ペンシルでは同時処理は出来ないのだから、しょうがないから逐次行動するときのために順番を決めている…って都合でしかないと思うのだけど、僕は一応これに対しての理屈はあって、ヨーイドンな順ではなく、本来は「その6秒の中のいつ行動を始められたのか?」だと考えていた。
つまり、動きの遅いヤツは例えば「前のターンからなんかまだやってて、動けるようになったのは2秒目からだった」みたいな解釈だ。
そして、これはチョッピリ、僕が最初にデザインした天外Ⅱの戦闘システムと関わっている。

続きを読む▽
|| 19:29 | comments (6) | trackback (0) | ||

このエントリーをはてなブックマークに追加
天外Ⅱの戦闘システムについて(2)
説明を始めると深入りして、面倒くさいから書きたくなかったのに、コメントで書かれてしまった上に「どうしてウィザードリィやドラクエがそういうシステムなのか?」を知らない人も沢山いることが、ツイッターとか見ていてわかった。
しょうがないので、話を一度前に戻して「なぜ、フェイズシステムなのか?」を解説するところから、今回は始めたい。

初代の(最近はクラシックというらしいけど)D&Dは、元々作った会社がTSRって有名なミニチュアール(フィギュアを使ったシミュレーションゲーム)だの、けっこーマニアックなボードシミュレーションを作っていた会社で、しかもD&Dは「ミニチュアールの戦闘ゲームにいろいろオマケのルールを付け足していったらRPGになりました」という代物なので、結構、戦闘がヘビーなゲームで、本来は方眼紙の上にフィギュアを置いてプレイし、距離だのなんだのまでルール化されているゲームだった。

続きを読む▽
|| 20:15 | comments (4) | trackback (0) | ||

このエントリーをはてなブックマークに追加