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      
<<  2014 - 06  >>

PROFILE
同人誌 電子書籍版
Re:ゼロから始める
ゲームシナリオ


ライトニング伝説


さよならハドソン


ドラクエとFFと
ToHeart


誰得ゲームライフ


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

イースI・II製作メモ

頒布ページ
LINKS
NEW ENTRIES
CATEGORIES
COMMENTS
    イースⅠ・Ⅱ通史(3):『リグラス』から『ロマンシア』
  • タムロ (02/03)
    イースⅠ・Ⅱ通史(1):PC88MkⅡSRの発売
  • tamuro (01/05)
  • おお! (01/03)
TRACBACKS
OTHERS
SEARCH BOX
POWERED BY
POWERED BY
ぶろぐん
DESIGN BY
ブログンサポート

FF10の話(8) - FFⅧ・その3 声のないゲームの問題
またまた期間が開いてしまったのだけど、夏コミまでには終わらせて、夏コミでは本にしたいと思っていたりする。

というわけで、FF10の話を書くシリーズの第8回。
シリーズは以下。
FF10の話(1) - それは1991年から始まった
FF10の話(2) - ヘラクレスの栄光Ⅲの衝撃
FF10の話(3) - ファイナルファンタジーⅦ・その1
FF10の話(4) - ファイナルファンタジーⅦ・その2
FF10の話(5) - ファイナルファンタジーⅦ・その3(終)
FF10の話(6) - ファイナルファンタジーⅧ・その1
FF10の話(7) - ファイナルファンタジーⅧ・その2

本編に入る前に簡単な注意。
このシリーズは『FFⅦ・Ⅷ・Ⅹ』について、もう超ネタバレのレベルで話が進んでいる。だからプレイしたことがなくて、そしてプレイする予定がある人は、ここから先はあまり読まないことをオススメしておきたい。

前回、FF8のストーリー構造について説明して「出来は良かったと思う」という話を書いたわけだけど、反面、評価が高いゲームではなかったという話も書いた。
そして最後で

また、FF8では「声がない」という問題が、とても大きくなり始めたシリーズでもあったのが、それが評価が高くならない理由になりはじめていた…と思うのだけど、それについては次回で。

と、書いたけれど、どうしてこれが問題になっていたのかを書く前に、少しまずゲーム内のボイスの話を書いておきたい。


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

このエントリーをはてなブックマークに追加
続・PCエンジン版R-TYPEの話
遥か遠い昔、PCエンジン版R-TYPEのコトという記事を書いたのだけど、最近、これについてTwitterで聞かれて「どうしてオーバークロックになるのか?」という説明がうまく出来なくて、ずっと考えていたのだけど、どうしてこれがオーバークロックになるのか、うまい(と思う)説明を思いついたので、説明してみたい。

まず縦1ドット、横Nドットの紐のように細い横長の画面があると考えて欲しい。
当時のゲームマシンは今のように複数画面分のフレームバッファを持たず(持てるわけもないメモリ事情だった)、この1ドットの横長の線を水平帰線期間毎に、1ドットずつ下に下りながら、だいたい250回ほど描くことで画面を作っていた。
この1ドットの線をラインバッファと呼ぶ。ここで1本のラインバッファを作るのではなく、スプライト用のラインバッファバックグラウンド(背景画面)用のラインバッファがあり、この2つを水平帰線期間毎に描画して、合成して画面を作っている…と想像して欲しい(この説明は正確には違うのは百も承知だ)。

ブラウン管テレビの原理や垂直帰線期間・水平帰線期間といったコトについての説明は勘弁していただきたい。
ココとかココとか、なんか比較的わかりやすいと思う。


そしてPCエンジンが横256ドットモードで動いているとする。
バックグラウンド(背景画面)のラインバッファは当たり前だけど256ドット。
次にスプライトはというとPCエンジンのスプライトは最大横が32ドットになるので、32ドット*16個が最大になり、512ドット分ということになる。
つまりPCエンジンの256ドットモードでは、256+512=768で、水平帰線期間毎ごとに最大768ドット分の絵を描くことになる。

では、これが320ドットモードになるとどうなるのか?
バックグラウンドが320ドットになるので320+512=832ドット。
832ドット分の絵を描くことになり、256ドットモードより、64ドット増えることになる。
ところが水平帰線期間は一定の長さで変わらない。
だから追加の64ドット分を描くために、832/768=1.08で、8%ほど速いスピードで描画することが要求される。すなわち8%ほど速いスピードでVRAMやイロイロなところにアクセスすることになる。
そして、8%ほどいろんなところに速くアクセスする(可能性がある)のは、当時使われていたRAMの保証の範囲を超えていた。
だからNECに「使っちゃダメ!」と、怒られたわけだ。

ここでスプライトの幅が32ドット最大だったことを思い出して欲しい。増えた64ドットはスプライト2つ分。なので横に並ぶスプライトの数を最大14個に設定すると…768ドット分の描画になり、256ドットモードと同じ描画量で済むことになる。

かくして、PCエンジンの320ドットモードではスプライトは14個しか並ばなかったわけである。

|| 18:59 | comments (0) | trackback (0) | ||

このエントリーをはてなブックマークに追加
インディーズゲーム"sumo boy"の事
僕が本当にほんのちょっとだけ関わっているインディーズゲーム、"sumo boy"について。

去年の夏過ぎに linkedin で「インディーズに興味があるか?」とメールが飛んできたことから、この話は始まる。

メールを飛ばしてきたのは TAPRR スタジオの"Chris Laurent"ってヤツ。
僕は「あるある、でも俺、これから忙しいから spare timeはあんまないよ」と返事を返した。

それで聞いたタイトルが"Sumo Boy"で、これからレベルデザインをやるんだ付き合えないか…みたいに話は進んでいったのだけど、年末から年始にかけて、本当に忙しくて、あまり付き合うことが出来なかった。
そこらへんが残念なんだけど、開発は進んでいき、とうとう人様に見せられるようになり、kick starterまで辿り着いたワケである。

興味がある方、ぜひ⇒ Sumo boyのKick Start
ちなみに1オーストラリアドルはだいたい95円なんで、100円で計算するとわかりやすい。

なお、日本語版もChrisは作りたい、って言っているので、ローカライズのお手伝いもしたいと思っている。

|| 22:38 | comments (0) | trackback (0) | ||

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