某プログラマが某有名ファミコンゲームのソースをgitに公開したの巻 | Colorful Pieces of Game
ツイッターでポロっとつぶやいたのだけど、ここでも記事をば。 某プログラマが34年前に発売された某有名ファミコンゲームのソースをgitに公開したので、以下にリンクを置いておく。 GitHub - omuanko/nnjhtrkn: Famous Ninja game for NESFamous Ninja game for NES. Contribute to omuanko/nnjhtrkn development by creating an account on GitHub. 某プログラマからの箴言は以下。 ■某プログラマ ちなみに びるど とおりますうご(www act65 を cpm86 エミュで 試してみた ソース見られるの恥ずかしい いまさらおそいか ちなみに act65は つけてないよ どっかで ひろってね ところで、イマドキな方には全く理解できないことがいろいろあるだろう
「当たらなければどうということはない」問題::Colorful Pieces of Game
「当たらなければどうということはない」は、言うまでもなくシャアの名セリフだけど、これは実はある種のゲームでは大問題になるという話。 プロ向けの話で、普段は会社の人間にしかしゃべらないようなコトだけど、なんとなく書いておくことにした。 今まで仕事をしてきて「こいつは出来るようになる！」と思ったヤツが、運営をしているゲームで起きて、困って聞いてきた話なので、一般的におこる問題なのだろうと思ったから、ここにメモっておく次第だ。 RPGやSLGなど、キャラごとに属性があるゲームでよくあるパターンで「敵の攻撃は当たるけれどHPや防御力が超高い」と「HPや防御力は低いけれど、敵の攻撃が当たりにくい」というのがある。 ここは分かりやすく前者をタンク型、後者をシーフ型と呼んでおく。 そして、たいていは（特に運営があるゲームでは）シーフ型が有利になりすぎるというのが、当たらなければどうということはない問題。
バイトサイズゲームの理屈::Colorful Pieces of Game
最初は、ツイッターで書こうかと思ったけれど、内容が複雑で長いのでメモ書き的にブログ記事にした。 タイトルのバイトサイズゲームってのはなんなのか？ 英語表記は、bitesize と一単語。 「一口サイズ」とか「スゴく小さい」とかって意味で、まあこの単語は"bite-size"でふたつの単語がひっついた言葉。 具体的にはスマートフォンで海外のパブリッシャー、有名なあたりはvoodooとかketchappとかが出しているミニゲームみたいなゲーム群のことを指している。 対象となっているユーザーは、たいていスーパーカジュアル層。 バイトサイズゲームは単純でコアゲームサイクルが短く、実質的に広告だけでビジネスが成り立つのが特徴だ。 一応課金のメカクニスも入れてはあるが、機能しているのはremove ad、つまり広告除去ぐらいのものだと思っておいた方がいい。 作り手からするとマネタイズに頭を悩ませなくて
ルーク・スカイウォーカー問題::Colorful Pieces of Game
最近、会社の若いゲームデザイナーに説明することがあったので、ついでと言っては何だが、ルーク・スカイウォーカー問題と呼んでいる古くて新しくて難しいゲームデザイン上の問題について、メモ書き代わりに残しておきたい。 尊敬するクリス・クロフォードがElectric GamingやCGDCの講演でスゴく語っていたゲームの持つ宿命的な問題だ。 「映画のヒーローのようになりたい」という、誰でも一度が持ちそうな夢を叶えるのは、テレビゲームのストーリー的な側面、シミュレータ的な側面、そしてインタラクティブメディアであることが組み合わさった、素晴らしい能力だ。 ところが映画のヒーローが立ちむかうクライマックスのような状況を本当にゲームで設定すると、ほとんどクリア不可能なうえに、クリア出来るようにすると別の問題が起こる、というのがこの問題のそもそも。 例えば（問題の名前に準じて）スターウォーズ EP4のラストバ
スプライトローテーションという技術::Colorful Pieces of Game
正しい呼び方があったわけでもないけれど、少なくとも僕はスプライトローテーションと呼んでいた技術について、ちょっと残しておこうというのが、今回のネタ。 おっそろしく古臭いハードの、おっそろしく古臭い技術で、残しておいたから「どうだ」ということでも全くないが、まあ後世のエミュレータを調べた人たちが「なんでこんなワケのわからんことをしていたんだ？」という疑問からは脱出することが出来るだろう。 めんどくさいので、以下の簡単な前提。 スプライトは、1980年代前半～1990年代半ばまでゲームで幅広く中心的に使われたグラフィックのハードウェア（および一部ソフトウェア）技術。 だいたい８ｘ８～64ｘ64ドットの矩形で、画面の座標を指定したら、速攻その場所に異動して、背景画面を壊さなくて、書き換え負荷がない神様みたいなモノ。透明色があったので、背景との重ね合わせも超カンタンである。ちなみにスプライトの指定
物理エンジンの恐怖::Colorful Pieces of Game
今では物理エンジンはunityやUEといった統合型ゲームエンジンが普及したおかげで使うのがとても簡単になったのだけど、これでカーレースのようなゲームを作ると、正しく動く車を作るのは実は超大変だって話をちょっと書いてみたい。 話は2007年に戻る。 2007年にメディアワークスを辞めるあたりで、韓国でPS2のゲームを作っている会社とつながりが出来、そこでカーレースを作ったのだけど、これが全オリジナルの物理エンジン＋3Dエンジンのゲームだった。 で、これを作る時に、いろいろとんでもない目に会ったおかげで、物理エンジンは万能ではないし、問題だらけだって知ったわけだ。 さて。 物理を使うゲームの作り方はいろいろあるのだけど、全部がいわゆる剛体物理で動き、フェイクはひとつもない、すなわちあらゆるものはフォースで動いているとする。そして物理エンジン内部のエミュレーションのΔTはフレームレート、すなわち
ハドソンがファミコンに参入するまで（５／終）::Colorful Pieces of Game
これは1983年春に始まり、1984年7月に終わる、ハドソンが史上初のサードパーティとして、ファミコンに参入するときの物語だ。 たくさんの当時の（がつくのが残念だが）ハドソンの方の協力を得て、ほぼ正しい歴史として記述できていると思いたい。 ただし、残念なことに、かなりの方から「自分の名前が文の中に出てくるのは歴史的なことだからいいけれど、誰が言ったかは分かるのはいやだ」といわれてしまったので、最初に名前を出してしまった野沢さん以外はハドソン関係者、ということで伏せておきたい。 さて本文。 1983年の秋までファミコンの売れ行きを見たハドソンは、これならイケるということで、サードパーティとしてファミコンに参入するべく、まずファミコンソフトの開発ツールを開発してから、任天堂との交渉に臨むことにした。 複数のハドソンの関係者によると、任天堂とハドソンの交渉があったのはハドソンが開発ツールを完成し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PCエンジン版『R-TYPE』30周年記念::Colorful Pieces of Game
桝田方式によるユーザーストーリーの作り方(1)::Colorful Pieces of Game