今年の（来年の）年賀状企画に、と思っていたデザインが
思い通りに行かず挫折。

楽しみにしてくれている読者の方もいるようなので
なんとか次のデザインを考えたいが、
実現できる範囲で、ある程度面白味があるものってのは難しい。

去年の（今年の）デザインは一番評判がよかったけど
一番手間がかからなかった。こういうのがいいのかもしれない。

休日になるとよくレトルトカレーを温めて食べるわけですが、
レトルトを温めただけの鍋は洗うべきなのか否か。

お湯を煮立てただけだから汚れていないといえばいないんだけど、
レトルト袋表面が清潔かというと、その保障はないわけで。
汚い成分が湯の中に混ざりこんで鍋を汚しているかも。

とか思いながら、毎回、水でゆすぐだけで片付けます。

自作ゲーム「ネイビーミッション」を
Ver.1.25にバージョンアップ。

Ver.1.24で出た撃沈後のBGMが
鳴らなくなってしまうバグの修正です。
公開後もいろいろ改造しているので

新要素追加　→　バグ発生　→　バグ修正　→　新要素追加

の永久ループに陥ってます。いつ終わるのか。

とか言いながら、次回Ver.1.26で
新ミッションが追加されることになりました。
新たに追加する２つの敵が参戦した５つのミッションを追加です。
処理がやや重いのと、単独ではやや弱いかもしれませんが
他の敵と混戦すると強いです。

もうさすがに年賀状作らないとヤバい。
間に合わなくなる。でもデザイン思いつかない。
なんのアイデアも降ってこない。ハガキは用意しちゃったのに。

ところで、この寒い中、ポカリスエットを常備して飲んでると
ものすごくトイレが近くなることを発見しました。
さっき行ったのにまた行きたくなる。

２００５年 窓の杜大賞の結果が発表されました。

ウゴツールは第３位となる「銀賞」を頂くことになりました。
２００３年のときの「フロントライン」では
ノミネートだけで入賞を逃しましたが、
今回は銀賞ということでプリンターまでもらえるようです。

投票してくださった方を含め、ウゴツールのユーザーの方、
どうもありがとうございます。
（結果を見ると、全体の投票数って「窓の杜」レベルでも
　意外と少ないんだなぁ、という印象です）

危うく年が明けるところでしたが、
なんとかメタクロ年賀状の作成に成功しました。
もうこうなったらフリーの年賀状素材を
印刷するだけにしようかと思ってたのですが
唐突にアイデアがわき、今回もオリジナルです。

恒例ですが、また希望される読者の方に
年賀状を出そうと思います。
市町村の合併が多発し、変わりまくる郵便番号に対応するために
最新の筆まめも買いました。住所印刷もバッチリです。

という事で年賀状が欲しい読者の方、
「年賀状希望」という件名で
自分の住所（郵便番号必須）と氏名（できれば本名）を
私までメールしてください。
本文は特に必要ありません。
集めた住所は私以外は見ません。

応募はひとり一通とし、
応募者多数の場合は早い者勝ちになります。
当選者の発表は年賀状の発送をもって代えさせていただきます。
応募〆切は年賀状がなくなり次第です。

ご応募、お待ちしております。

昨日、出勤と同時にゆっくりと雪が降り始め、
駅に着いた直後に急に強くなり、みるみるうちに積もった。
まさに積もる過程を眺めた感じ。

で、兵庫県南部は雪慣れしていないので
そこらを走る車もチェーンとか全然つけてない。
スタッドレスタイヤすら履いていない。
上り坂をギュルギュル空回りしながら登ろうとする無茶ぶり。
なぜそこまでして車に乗るのを選ぶのか。

歩いている立場としては、降ったばかりの新雪の部分は
よくグリップするので歩きやすいが、
午後以降に雪がとけ、夜にまた凍った部分がヤバイ。
ピッケルもなしで下り坂をどうやって踏ん張り、
上り坂をどうやって上るのか。
したくもないのにムーンウォークになってる。

さらに建物の入り口の大理石の階段、
雪がとけて濡れていたし、「すべりやすいです」と
張り紙までされていたのを見たのに、すべった。
すべらないようにと思いながら足を置いたのに普通にすべった。
もう少しで派手に転倒するところだったけど、なんとか耐えた。

夏は夏でやたら暑く、１０月になっても暑かったくせに
冬は冬でこの寒さはなんなのか。異常。

今回のメタクロ年賀状は募集の瞬間から
かなりの勢いで応募が集まり始め、
例年に習った当初の読みをかなりオーバーしそうだったので
急遽、５０枚の年賀ハガキを追加購入しました。

できる限り全員に配布したいのですが、
今ある分をオーバーするとさすがに終了です。

応募の中に、必要事項が欠けているものが
ちょくちょくあるのですが、配達可能か不安なので
応募順序の後ろにまわさせてもらいます。
当選については元旦に届いたことでサプライズして欲しいので
こちらから必要事項を問い合わせることはしません。
届く人は届きますし、届かない人は届きません。

久しぶりにエプソンプリンターがフル稼働しております。
まだ応募は受け付けています。
詳細は１２月２３日の９時１３分のプチメタをご覧ください。

メリークリスマスなのですが、
バイクで走ろうと思って家から出たら
雪が降ってきたので引き返しました。

今日食べたのはサンドイッチと台湾ラーメンということで
まったくクリスマスにちなんでいません。

サンタさんは着々と世界を巡っているようなので
そのうち私の家にもXbox360を置いていってくれるはずです。

中越典子がやっぱりかわいい。
元気な感じと、おでこをまったく隠さないところがいい。

それよりも、あんなデカいフランスパン一本を
昼食に買ってくる課長ってどうなの？

来年のために壁掛けのカレンダーを買った。

なのにクラブニンテンドーから
プラチナ会員限定で非売品のカレンダーが送られてきてしまった。
全員プレゼントで非売品だったから期待していなかったのに
予想外に大きくて、デザインもいい。

しかしお金を払って買ったカレンダーを
お蔵入りにするのは勿体なさすぎる。
そして６畳の部屋にカレンダー２もいらない。

というわけで、ニンテンドーカレンダーは
ゼルダもカービィも知らない父の部屋にもらわれていきました。

DirectXプログラマ向けプチメタ。

３Ｄプログラミングにおいて
速度面の向上はなによりの課題である。
勉強するにしたがって、できることは増えるけど
そのすべてをゲームに導入すると重すぎてゲームにならない。
できる限りで導入するためには
現在の処理を可能な限り軽くし、
追加できる余地を増やすことである。

ということで、個人的に勉強した中で吸収した速度向上ヒント。
間違っていればご連絡を。

----------------------------------------------------
●１．扱うポリゴン数を減らす
言わずもがな、であるが
ポリゴンが増えれば頂点数が増え、
塗りつぶすピクセル数も増え、
光源計算や行列計算の負担も飛躍的に増加する。
ポリゴンは可能な限り減らすべし。
個人的には６０fpsのゲームにおいて、
１フレームに１万〜１万５千ポリゴンを上限と考えている。

●２．テクスチャ画像を小さくする
テクスチャ画像が大きくなると、それだけ転送量の負担が増える。
ヘルプを参照する限り、可能な限り小さくて
正方形のテクスチャがベスト。
どうしても大きくなるなら２５６×２５６ピクセルにする。

●３．ミップマップテクスチャを使う
テクスチャ画像が小さい方が速いのは前述したが、
遠方にあるテクスチャには詳細な内容は不要なので
実際のテクスチャ画像を縮小したものを用意しておいて
それを距離に応じて使い分けるようにすれば
遠方のテクスチャには小さい画像を使用しているのと同様になる。
そのため、テクスチャ画像の読み込み時に
数段階の縮小画像（ミップマップ）を用意する処理をする。
メモリ負担は当然ながら増えるが、速度には代えられない。
（DirectX側で作成されたミップマップは
　たまに汚い場合があるので、うまく使い分ける）

●４．視界外はカリングする
カメラから見えていない部分は自動的に非表示になるが、
最終的に画面外に出るか判断されるまでに
行列計算、光源計算、テクスチャ処理、Ｚバッファ処理などが
行われてしまうと思われる。

最後の最後で非表示になっても恩恵が少ないので、
視界外に出ていると判断できるモデルは
行列計算などの前から処理をスキップすべき。
カメラ位置を頂点とするピラミッド型の範囲が視界なので
各モデルやビルボードにおいて、
そこから完全に出ているかどうかを調べる。

部分的に非表示にできるよう、地形に関しても
ある程度ごとに分割した部品化して作成する。
丸ごと１つの塊として作ると部分的な非表示ができなくなる。

●５．不透明であるならカメラに近い物から描画する
Ｚバッファの働きによって、すでに描画されている物よりも
奥に存在する部分の描画はスキップされる。
逆に考えれば、なるべくスキップされる確率が上がるよう、
カメラに近い物から描画していけば
早めに視界を覆う部分が多くなり、
描画の負担軽減の可能性が高くなる。

ただし、カラーキーやアルファブレンドを使っている物は例外で
逆に遠方の物から描画していかないと
描画結果がおかしくなる（これはまあ、常識）。

●６．メッシュは読み込み時に最適化する
DirectXにおけるOptimize系メソッドを使うと
指定条件に応じて最適化してくれる。
体感できるほどの変化を感じた経験はないが、
多少なりとも速くなるなら、やって損はない。
（一部モデルにおいて不具合が出るので
　指定する条件には注意する）

●７．プログレッシブメッシュにする
低ポリゴンでモデルを作ったとはいえ、
遠方にある場合でも同じ詳細度で表示するのは無駄である。
プログラム側でポリゴン数を変化させられる
プログレッシブメッシュを導入し、
カメラとの距離に反比例させて変化させれば
遠方にあるメッシュはプレイヤーが気づかない程度に簡略化でき、
処理の負担も軽減する。

●８．映像関係のデータはビデオメモリに乗せる
言うまでもないが、メッシュやテクスチャなどのデータは
映像処理として使用されるのでメインメモリよりも
ビデオメモリに存在する方がデータの行き来が速い。
ビデオメモリの不足などの理由がなければ
読み込み時にビデオメモリにロードしているはずである。

●９．頂点バッファを使用する
同様にビルボードなどの平面ポリゴンの頂点データも
描画のたびにメインメモリ（簡単に言えば変数）から
データを渡すよりも、ビデオメモリに展開している方が
メインメモリから行き来するデータ量が少なく、速度が向上する。
そこで頂点バッファを作成し、あらかじめ頂点データを代入して
描画時には何番目の頂点データをどれぐらい使用するか、という
必要最小限の内容だけを伝える。

ただし、頂点データを変更するためには
頂点バッファをロックしなければならないが
速度低下の恐れがあるので頻繁に行うべきではない。
そのため、変更する予定のない頂点データのみ、
頂点バッファに代入するようにする。

●１０．判定の回数や精度を下げる
衝突判定に関して、レイを使うなどの精度の高いもので行う場合も
すべてのキャラクタにおいて処理していくと速度に響く。
はじめに球判定などでラフチェックをし、
それで衝突したモデルに対してのみレイ判定を行うなど
詳細な判定をする回数をできる限り少なくする。

一瞬で着弾する銃弾の判定などは貫通弾でないなら、
発射地点にもっとも近いものから調べていけば
衝突判定が真になり次第、判定のループから抜けられる。

地形との判定に関しても、いくつかのブロックに区分けし、
そのブロック内に存在する
障害物のインデックスを保存した配列を用意しておき、
主人公が存在するブロックの中の障害物とだけ判定をすれば
衝突する可能性がない障害物との無意味な判定を避けられる。
これは、大量の敵との判定などにも応用可能。
毎フレーム、どのブロックに何番の敵が存在するかを調べ、
主人公と関わる可能性があるキャラとだけ判定処理を行う。

●１１．フレームスキップを導入する
好き好きではあるが、３Ｄゲームにおいては
処理落ちが発生するとかなり操作性が悪くなる。
そこで処理が間に合わないときには描画を休むようにする。
ただし、一定時間における変数の変化量が同じになるよう、
なんらかの工夫をする。

２Ｄシューティングなどにおいてはフレームスキップは
気づかないうちのゲームオーバーを生むので
毎フレーム描画し、処理が間に合わない場合でも
処理落ちさせる方が好まれる。
----------------------------------------------------

最新版Ver.1.28のネイビーミッションでは
２と５以外はすべて導入済み。
さらに速くなる余地があると思うけど
そこはまだ技術や知識が追いつかず。

ただ、一度導入できれば今後作る３Ｄゲームにも流用できるので、
チャレンジする価値は大きい。
苦労した割に体感するほど速くならない場合も多いが
徐々に最適化されていくプログラムが嬉しい。

「新曲なのにaikoの歌が同じに聞こえる病」が
なかなか治りません。

「安藤美姫がかわいいのかかわいくないのかわからない病」にも
かかっています。治療中です。

ゲームプログラミングに興味のある中学生から
メールが来たので、せっかくですからここで返事します。

よく、
「フロントラインのようなゲームを作るにはどうすれば〜」
「どんなソフトを使って作ったのですか？」
「僕も作ってみたいです」
と割と気軽に言われることが多いのですが
ゲームをプレイするのと同じ楽しさではゲームは作れません。
脳みそが鼻から出そうになることも多々あります。
学校の授業抜きには作れないので
授業は真面目に受けましょう。ホントに。

ゲームプログラムを知らない中高生のための
ゲームプログラミング講座（２Ｄゲーム編）。
〜第１回〜

もっとも基本的な２Ｄゲームに至る
最初の基礎の基礎ステップだけ説明します。
プログラムする環境によって違う部分もありますが
とりあえず意味さえわかってもらえればいいので
そのあたりは抜きにします。



まず絶対に知っておかないといけないのは座標です。
画面や画像の中の特定の場所を示すために
横と縦の２つの方向、すなわちＸ軸とＹ軸で表現します。
数学の授業のときとはＹの方向が違うかもしれません。

画面の左上、画像の左上の角がＸもＹもゼロなので
（０，０）と考えます。



なので、（１００，１５０）なら、このあたりでしょうか。
単位はピクセル、つまり画素です。
携帯のカメラで画素画素言ってるのは画面の粒のことです。

私がよく使う画面設定は
横６４０ピクセル、縦４８０ピクセルなので
６４０×４８０＝３０７２００画素。だいたい３０万画素です。
少ないように感じますが、
今の携帯ではまだ表示しきれないサイズです。
カメラでは２００万画素の写真を撮影できても
それを一気に表示するサイズの画面はまだ携帯についていません。

さて、特定の場所以外に範囲を示すときもあります。
円や三角形などの形は扱いにくいので
プログラムでは長方形を使って範囲を表します。



その場合、このように左上と右下を座標で指定します。
これでどの場所にあるどんな大きさの長方形かわかります。
右上と左下の座標が必要ないことはわかってもらえるでしょうか。
（長方形だからといって４つそれぞれの角の座標を指定するのは
　無駄なだけです。プログラマ的な考え方ではありません）


「画像Ａ」

さて、画像を用意するとします。
この画像をどこからどこまで表示するかを
さっきの長方形を使って指定します。
丸ごと表示するなら、左上と右下の座標は
それぞれ（０，０）と（６４０，４８０）になります。
（正確には右下は（６３９，４７９）であるが、
　諸事情により気にしない）

画面も同じ大きさだとすると、この画像を
ぴったり画面に表示すれば、背景として見えるはずです。
ということは画面の（０，０）に表示すればいいことになります。

そこで表示の命令を使って、画面に画像を表示させます。

Draw(0，0，画像A，0，0，640，480)

適当に作った命令ですが、割と本物もこんな感じです。
「Draw」というのが表示するための命令の名前で、
カッコ内がそれに必要なデータです。

最初の「0，0」が画面内で表示したい場所。
その次の「画像Ａ」がどの画像を使用するか。
その次の「0，0，640，480」が画像の中の使用する範囲です。
（範囲を指定する長方形の左上と右下のＸＹ座標）

これで画面に背景として画像が表示されるはずです。

とりあえず、第２回につづく

ゲームプログラムを知らない中高生のための
ゲームプログラミング講座（２Ｄゲーム編）。
〜第２回〜


「画像Ｂ」

同様に、画像Ｂとしてゲームのキャラを描いた画像を用意します。
２人のキャラが描かれていますが、左側のキャラの範囲を示すなら
左上を（０，０）、右下を（５０，１００）とする長方形のはずです。



この画像を上記のように画面に表示したいなら
先ほどの表示の命令をどう書けばいいかわかりますか？

Draw(100，200，画像B，0，0，50，100)

になるはずです。

ここでうっかり、

Draw(100，200，画像A，0，0，50，100)

などとすると、キャラのはずなのに
さきほどの背景画像が表示されてしまいます。
これがいわゆる「バグ」です。
（この程度のバグなら一瞬で取れるのですが）


現在のプログラムは

Draw(0，0，画像A，0，0，640，480)　　　　　←背景の表示
Draw(100，200，画像B，0，0，50，100)　　　←キャラの表示

となっています。

これを

Draw(100，200，画像B，0，0，50，100)　　　←キャラの表示
Draw(0，0，画像A，0，0，640，480)　　　　　←背景の表示

と書いてしまうと、キャラが表示された後に背景が表示されてしまい、
キャラが上書きされて見えなくなってしまいます。
どの命令から行うかという順序も大切です。

ちなみに、実際には紫色の部分は消して表示します。
するとプレイヤーには、背景の前にキャラが立っているように見えます。




さらに、画像Ｂの中の右側のキャラを表示したい場合は
どういう風に命令を書けばいいかわかるでしょうか。

Draw(100，200，画像B，50，0，100，100)

です。範囲を指定する長方形の角の座標が変わるだけです。
これで右側の「足を開いたポーズ」のキャラが表示されます。

質問があればどうぞ。

さらに第３回につづく

ゲームプログラムを知らない中高生のための
ゲームプログラミング講座（２Ｄゲーム編）。
〜第３回〜

さて、プログラムを知る上で不可欠なもののうち
２つだけ紹介しておきます。

まず、「変数」。
好きな英数字で表現し、数字などを入れておくことができます。

たとえばＣという変数を作り、

C=3

とすれば変数Cには３が入っている状態になります。

C=C+2

とすると、３が入っていたＣに２が足され、それがまたＣに代入されるので
最終的には５が入った状態になります。


もうひとつが「if」文です。

if(条件){

}

という風に書き、条件の部分が正しい場合だけ
カッコの中が実行されます。
先ほどの例ならば

if(C==5){
　　C=3
}

と書いたりできます。
条件は「Ｃが５と等しいならば」ということを表しており、
この場合、変数Ｃには５が入っているので、条件が正しいことになり、
カッコの中の「C=3」が実行されます。つまり、Ｃに３が入ります。

if(C==5){
　　C=3
}else{
　　C=2
}

と書くと、条件が正しくない場合には
elseと書かれた後のカッコの中が実行されます。
つまり、変数Ｃに７が入っていた場合、条件が正しくないので
elseの方の中身が実行され、変数Ｃに２が入ります。


これと、第２回で紹介したキャラ表示を組み合わせて考えます。

変数Ｃにあらかじめ、０を代入しておき、

if(C==0){
　　　Draw(100，200，画像B，0，0，50，100)　　　←キャラの表示
　　　C=1
}else{
　　　Draw(100，200，画像B，50，0，100，100)　　　←キャラの表示
　　　C=0
}

と書けば、このプログラムが実行されるたびに
変数Ｃが１と０で入れ替わり、足を閉じたポーズのキャラと
足を開いたポーズのキャラのどちらかが交互に表示されます。
画面上ではキャラが歩いているように見えます。
これがアニメーションというやつです。

上記はものすごくそのまんまな書き方、
いわゆる「ベタ書き」という状態なので、
実際にはもう少しまとめたり、短く書き上げたりします。

表示命令の部分はややこしくなるのでおいておくとして、
たとえば

if(C==0){
　　　Draw(100，200，画像B，0，0，50，100)　　　←キャラの表示
else{
　　　Draw(100，200，画像B，50，0，100，100)　　　←キャラの表示
}
C=1-C

などと書いたりします。
変数Ｃに０を代入したり１を代入したりする部分を１行にまとめました。
要するに「Ｃに０が入っているときは１を代入」し、
「Ｃに１が入っているときは０を代入」すればいいので
どちらの場合であっても「１−Ｃ」を変数Ｃに代入すればいいのです。
うまく引き算が働き、両方の場合を１行で表現することができてます。

フロントラインなどの場合はアニメーションが多く、
攻撃や歩行、防御などの状況によっても見た目が変わるので
このあたりの管理はもっとややこしく、２００倍ぐらい苦労します。
画像をたくさん用意すればアニメーションはなめらかになりますが、
その分メモリを圧迫したり、プログラムが複雑になったりするので
決して「棒人間だから簡単に済む」わけではないのです。


そろそろ終わりたいが第４回につづく

ゲームプログラムを知らない中高生のための
ゲームプログラミング講座（２Ｄゲーム編）。
〜第４回〜

あとはキーを押すことでキャラが移動すれば
ゲームになってきます。

そこで

Draw(100，200，画像B，50，0，100，100)　　　←キャラの表示

さきほどの表示の命令の中の
画面のどの部分に表示するかという位置を指定する部分に
変数を使います。

Draw( X，200，画像B，50，0，100，100)　　　←キャラの表示

Ｘ座標を指定する部分に100の代わりに
変数Ｘを書きました。変数Ｘにあらかじめ１００を代入しておけば
状況は変わらないはずです。

これを踏まえて、

Draw(0，0，画像A，0，0，640，480)　　　　　←背景の表示
Draw( X，200，画像B，50，0，100，100)　　　←キャラの表示
X=X+1

とすれば、変数Ｘが毎回大きくなっていくので
だんだん画面の右方向にズレて表示されます。
これが移動です。

カンのいい人は、それまでに描いたキャラの画像が
残像のように残ってしまう、と心配するかもしれませんが、
背景画像を毎回上書きしているので、
以前までのキャラの画像は描き潰されてしまうので大丈夫です。

これだと勝手にキャラが動いているだけなので

Draw(0，0，画像A，0，0，640，480)　　　　　←背景の表示
Draw( X，200，画像B，50，0，100，100)　　　←キャラの表示
if(カーソルキーの右を押していれば){
　　X=X+1
}

という風にします。
これで右のキーを押したときだけ変数Ｘの値が増加するので
右のキーを押すことでキャラが右移動するように感じます。

縦にも移動したい場合はＹ座標の方も変数にしてしまいます。

Draw( X，Y，画像B，50，0，100，100)　　　←キャラの表示

これで変数Ｘ、変数Ｙを増減すれば
上下左右、好きな方向に移動させることができます。

ここで難しいのはナナメ移動です。

X=X+1
Y=Y+1

とすればＸとＹが両方とも大きくなり、
ナナメ移動する、と思うでしょうが
それでは４５度の角度に限定されてしまいます。
たとえば３０度の角度に移動したい場合は
変数Ｙは変数Ｘに比べて
少なめに増やさなければいけなかったりします。
それ以外の角度に関しても、それぞれの角度に合った割合で
ＸとＹを増減すべきです。
その辺になると、どのぐらいの量を増減すべきか
正確にパッと思いつきません。
そこで三角比であるサインやコサインを使ったりします。
（具体的な利用方法はここでは説明しません）

数学で三角比が出てきたときには何の役に立つのか、と
思った人もいるかもしれませんが、
正直言って、三角比がなければゲームは全滅します。
私が作ったすべてのゲームにサイン、コサイン、タンジェントが
なんらかの形で利用されています。しっかり勉強しましょう。


やっと最終回につづく

ゲームプログラムを知らない中高生のための
ゲームプログラミング講座（２Ｄゲーム編）。
〜最終回〜

ここまでで出てきたプログラムはあくまで例えなので
このままでは動きません。
実際にはこういったプログラムを
実行ファイルに変換してくれるソフトが必要です。
（「コンパイラ」や「開発環境」などと呼びます）
私は「Microsoft Visual C++ .NET」を使っています。

長くなりましたが、こういった考えを
もっともっと積み重ねていくと
やっと簡単なシューティングゲームあたりが
作れるようになります。
アクションやパズルはもう少し難しくなり、
３Ｄゲームになると、
さらに高いステップに上らなければいけません。

「○○ツクール」といったシリーズが広まったために
ヒョイヒョイと操作したり、何かの設定をするだけで
ゲームが出来上がると勘違いしてしまう人が出てきたりしますが
正直、ものすごく地味でややこしくて勉強ばかりの作業です。

４回にわたって説明したゲームプログラムの基礎の基礎ですが、
こういう内容を読むと２種類の反応に分かれます。
「うえー、面倒くさー。やりたくないなー」
「なるほど、もっと勉強してみたい。
　自由に作れるようになりたいなー」
といった感じです。

前者の反応の人にはゲーム作りは向いていません。
何かを作る仕事において「面倒くさい」と思う人は無理です。
面倒でやりたくもない作業を数ヶ月続けて
ゲームを完成させるなんて辛いだけです。

逆に後者の反応の人は楽しくてたまらないです。
ゲームをプレイするより作っている方が好きになり、
誰にも指示されていないのに作り続けます。
（ちなみにこれまでのプログラム解説が今、理解できるかどうかは
　素質とはほとんど関係なく、好きか嫌いかの方が大切です）

私は後者の人間だったので、専門学校に入り、
毎日毎時間そんな作業ばかりの生活が天国に思え、
なんの義務もない今でもゲーム作りがやめられません。

ただ、こうやってゲームを作り、それを公開して
その結果だけを見ている人にとっては
開発中の、脳みそを雑巾しぼりされるような苦労は伝わりにくいので
「○○を△△すればもっと面白くなると思います」
「××を追加すればどうでしょうか」
とあっさり意見されたりします。

中には
「結果はどうあれ、ちょっと試しに作ってみてよ。念のため」
という気持ちを暗に秘めている人もいるかと思います。
せっかく意見したのだから、採用して欲しいという気持ちは
十分にわかります。

が、やはりゲーム開発がこれだけ辛い以上、
やった作業の分だけの結果が出て欲しいと思いますし、
出来上がったゲームのデキが私の評価にもなるわけですから、
相当に考えないと導入に踏み切るかどうかは決められません。

もし、ものすごくいいアイデアを私が気づかずに流してしまったり、
逆に私が面白いと思って開発したゲームが
まったくウケなかったりすれば、
それはそのまま私の信用を失い、評価を下げるわけです。
その責任を意識した上で、新しいゲームを作り、
それをボツにするか公開するか、
どうバージョンアップするかを考えています。
一部のユーザーの人にとっては
意に反した行為があるかもしれません。

でもやはり私が納得したものを作っていきたいのです。
意見が採用されないのがどうしても我慢できないなら
「自分で作ってください」としか言えません。
逆に言えば、自分で作るなら
誰にも文句を言われない「はず」ですし、
自分の思うように作れる「はず」なのです。

自分の考えたゲームや演出を実現させるには技術が必要なので
私は今でも毎日勉強しています。
学校で勉強したことは確かに役立つのですが、
それだけではできることが少ないのです。
もっとすごいことを、もっとカッコいいことをやりたいと思うなら
さらに勉強するしかないのです。

もし、その覚悟があるならゲーム作りの道も悪くないと思います。
中学生ならば、学校の勉強を真面目にがんばり、
いろんな映画やテレビや本やマンガを見てセンスを鍛え、
ゲームをプレイするときは、
開発者の工夫を見抜くようにしましょう。

偏見を持たず、人の批評に流されず、
特定のジャンルに偏らずにいろんなゲームを遊んで
自分なりの感想を持ち、
いいところと悪いところを明確に分析しましょう。
私がプチメタにしょっちゅうゲームや映画の感想を書いているのは
その辺を常に鍛えておくためです。

長くなりましたが、今日の授業はこれで終わります。

自作ゲーム「ネイビーミッション」を
Veer.1.26にバージョンアップ。

今回は新しい敵を加え、ミッションも増えました。
以前、５つと書いてましたが、
結果的に７つのミッションを追加しました。

新しい敵のアイデアは
ユーザーの方の意見を元にさせてもらいました。
もちろん私なりの工夫も多く入っていますが、
ユーザーの方からひらめきをもらったのは確かです。

ただ、新しい敵は原理的に、状況によって
どうしても処理が重くなるのが
既知の問題としてあります。

次のVer.1.27である程度、緩和するように工夫がされますが
現段階では難易度が上がるにつれて
かなり重くなるかもしれません。

それなら今回のバージョンで工夫しておけば、と思うかもですが
新しい敵の追加というのはプログラム的に大工事なので、
それとともに処理軽減のための大工事も同時に行うと
何か問題が出たときに、どちらの大工事に原因があるのかが
かなり特定しにくいからです。
大工事はそれぐらい、バグの出る可能性を持っています。

さらに、以前から一度はやろうと思っていた
レンズフレアの処理を追加しました。
太陽を見るとリアルにまぶしく感じてもらえるはずです。
ゲームとして支障が出過ぎないようにしたつもりです。

また楽しんでもらえれば幸いです。


あと、バーガーメーカーもバグを見つけたので
Ver.1.10にバージョンアップ。

DVD「ｇ＠ｍｅ．」

うわー面白い。久しぶりにちゃんと作られた邦画を観た。
最初は「まあ、よく出来てはいるかな」程度だったのに
中盤でなぜタイトルが「ゲーム」なのかがわかるあたりからが
急速に面白くなる。

主要キャラは３人ぐらいなのに見飽きないのは
やはり俳優たる実力。
テンポもよく、展開も大きく、飽きさせない１２０分。
さりげないミスリードが非常に面白い。

何も考えず、何も知らないで観るのがよい。
そして仲間由紀恵はかわいい。

ロボコン２００５、面白い。

はしごくぐり、平均台、ハードルといった、
攻略法が違う３つの障害を
同一のロボットで乗り越えていくアイデアがたまらない。
あまり注目されていなかったが、
ラストでバトンを受け取り、自動で垂直な壁を登って
穴の位置に合わせてバトンを差し込む自動ロボットも素晴らしい。

何回やっても同じように障害を突破できる
安定性のあるハードウェアは、とてつもなく難しい。

ゲームしてたら唐突に思いついて
ネイビーミッションを改造。
２時間ぐらいで作れると思ったネタなのに
表示関係の洗練が難しく、４時間もかかった。

というわけで、Ver.1.28あたりから
ミッション０が少し変わります。やや深みが増すといいのですが。

ニンテンドーDSのソフトを新品で買ったときの
透明フィルムが開けにくすぎ。みんなどうやってるの？

お菓子とかにある、片側を切るためのリボンも封入されてない。
指で破ろうにもピチピチ。ハサミを使うのは邪道。
なんとか折りたたんでいる部分をめくったりして開けてるけど、
短く切れたりしてなかなか開けない。早くゲームしたいのに。

同じくXboxの新品ソフトも開けにくい。
透明フィルムは簡単だけど、
開ける側に貼ってあるシールが剥がしにくすぎ。
一気に剥がそうとすると脇の部分だけで切れる。
肝心な部分は剥がれてない。開かない。

実感は全然わきませんが、もう今年も終わりです。
明日からは西暦を書くところには２００６、
平成を書くときには１８と書かなければいけません。
「知名度を上げる」という私の永遠のテーマのために
来年もがんばっていきたいと思います。

メタクロ年賀状も今回は例年の約３倍の応募があり、
最初に用意していた分を大きく上回ってハガキを購入しました。

ただ、応募の必須項目が欠けているものが結構ありました。
名前や住所が欠けているものは
届けることができなくなるので選考外にさせていただきました。

「年賀状希望」という件名が抜けているものに関しても、
たとえ住所氏名などが書かれていても
こちらで勝手に年賀状への応募と断定して発送すると
ただのダイレクトメールになりかねないので選考外になりました。

郵便番号抜けに関しては選考の下位に回したので
当選の確率が低くなっています。
それらを総合し、応募先着順から発送しました。
当選した人には、おそらく元旦に到着するはずです。

前回のデザインは歴代で一番評価が高かったですが、
だからといって今回の内容に
あまり期待しすぎないでください。普通です。