はじめまして！！
しがないシステムエンジニアをしております、negimaと申します。
まず手始めにnegimaとはどんな人間（？）なのかをご紹介させていただいたうえで、
技術的なお話をさせていただこうと思います。
事の始まりは中学時代
プログラムに興味を持ったのは中学の頃。
とある国語教師にQuickCのフロッピーディスクを頂いた事がきっかけとなります。
当時はまだPC-9801全盛期の頃、100MBのハードディスクがあればなんでも入ると信じていた、そんな時代。
最初は学校にあるPCで動かしていたのですが、なんとか家でできないものかと親に相談。
その時親に購入してもらったPCがNEC PC-9821Cb（通称キャンビー）の初代で、ディスプレイと本体が一体型となっているPCでした。
決してPCが安くない当時、親に情報処理の勉強をしたいという事を嘆願し、購入してもらいました。
確か当時プリンター付きで30万近くしたんではないかと…
因みにこのPCを選んだ理由はただ一つ！テレビとしても使えるから（煩悩万歳）
ここから、先生に貰ったQuickCと、図書館にあったCの本を片手にプログラムの勉強を進めていくことになります。
高校進学となり、当時実家の近くで情報処理科があるのが、商業高校と、情報処理系に強いもう１校でした。
実家が商店をやっていた事もあり、商業高校の情報処理科へ進む事を選択しました。
親にはこれからはプログラムでソフト（ゲームとか）を作るのが普通になるから、プログラムの勉強ができる情報処理科のある高校へ進学したい！
と相談し、無事商業高校の入学許可を貰う事ができました。
…本当の理由は、中学で好きだった子がその高校に行く事を知ったからだったりしますがネ！（煩悩万歳２）
目覚めし高校時代
高校では、COBOLでプログラムの勉強をしていました。
流石は商業高校といったところでしょうか。
プログラムの授業は本当に好きで、自分で書いたコードが思った通りに出力されずに四苦八苦しながらも、解決できた時の爽快感はたまりませんでした。
その裏で、英語の苦手がどんどん増大し、赤点ギリギリを彷徨う事に…
そんなこんなで高校を卒業後、次に向かおうと考えたのはゲームのプログラム開発のカリキュラムのある都内の某専門学校。
一度親と一緒に体験入学会に行くことで、無事入学の許可をもらえました。
これで、当初目指していたゲーム開発への道が開ける事になります。
…まぁ、ゲーム系に拘らず情報処理系なら地元にもあったわけですが。
あえて都内の学校を選んだのは親から離れたかったからなんですがね（煩悩万歳３）
専門時代の神々
専門では、開発用プレイステーション（通称黒ステ）でのゲーム開発学んでいました。
そこでは２年間を通して大きく２つの課題に向かう事になります。
課題１：最強のオセロＡＩを作成せよ！
昨今よく見かけるようになったＡＩなわけですが、それを作成せよとの課題です。
この頃よく使われていたのは、盤面に点数を付けて有効な手を出すというものでした。
その点数付けの為に色々なルールを適用させていきます。
最終的に多くの強いルールを適用できたものの勝ちというわけです。
そこで私が取った戦法は…
強い〇〇の打ち筋を真似れば強いんじゃね？ （〇〇には、人／ＡＩ／定石 が入ります）
でした。
ようは、盤面からの最善手をデータ化し、それをパターンマッチングで取り出すという方法です。
この方法のネックは、
- 検索結果を素早く導き出せるか
- いかに有効なデータを大量に作れるか
の２点です。
１については、盤面のシリアルデータを4方向分作ってサーチしてやればよさそうです。
２についてですが、普通にやったら非常に時間を費やす事になります。
が、自分の時間をあまり割きたくない（できるだけラクがしたい！）ので、
幸い対戦相手は同じ教室の学友、数１０名程度。
練習試合と称して、学友の作ったプログラムと戦わせてデータを集めれば、
そこそこいい勝負ができるのではないか？
という事で、初期は私の打ち筋と定石をデータ化し、
学友の実装を待って、以降は練習試合をすることで成長させていきました。
試合ではかなりいい線行きましたが、パターンマッチングの弊害で、
パターンに無い手を打たれると、とたんに弱くなる（デフォルトは角の周囲以外から優先でとるように組んでいるだけ）
という感じで、結果は４位で終わりました。
私の作ったプログラムは全ての履歴を取り込むように作ったため、データが最適化されておらず、
ゴミデータにマッチしてしまい、自ら死にに行く事も見受けられました。
データ蓄積とデータの最適化が足りなかったのが、本課題の反省点ですね。
課題２：ポリゴンモデルを斜め回転させる動きを必ず取り入れたゲームを作れ！
正確には斜め60°で回転させるというもので、当時先生がおっしゃるには、
この角度で回転させているゲームは今のところ（1998年当時）存在しない！！ それに、これが実装できればかなり自然な挙動を表現できる！！
とおっしゃっていました。
回転処理をするためには、座標を行列計算すれば導き出せるということで、早速行列計算を使って斜め回転用の座標を算出して、モデルを回すサンプルを作るわけですが、
回転させればさせるほどモデルがどんどん小さくなったり大きくなったりしてしまいます。
ここでピンとくる方は、それなりにプログラムをやってる方かな？
私の通っていた商業高校では数学は普通科高校に比べて深くまではやりません。
当然行列計算もやってません。
なので、関数に変数を突っ込んだ結果何が起こっているのか当初は見当つきませんでした。
そこでとった対策が、
「回せば回すほど大きさが変わるなら、あまり回さないゲームであればごまかせるのでは！」
でした…なんだろう、この「パンがなければケーキを食べればいいじゃない」的な…
根本的な解決になってませんが、いつまでも悩むくらいなら先に進もうという苦肉の策でした。
そんなこんなで思いついたゲームは
- 六角形を3等分して3等分したパネルを六角形の枠で選択
- 選択した六角形それを60°回転させて、六角形が同じ色になったら消える
というパズルゲーム
これなら、モデルの回転は最大180°まで、
且つ、絵を描くのが苦手な私でもパネルの色は単色でよい！
という事で、頑張って作っていたのですが…
パネルを回転させるところまではうまくいきましたが、
消えた後の動作が実装できず、お蔵入りのまま卒業と相成ってしまいました。
結局最後まで、モデルの大きさが変わってしまう問題も解決しないままでした。
さて、ここまできて、最初のモデルの大きさが回転で変わってしまう問題の原因がわかりましたでしょうか？
答えは、
行列計算した結果を次の行列計算に使ったから
です。
行列計算は積算を使うので、小数点以下が切り捨てられていきます。
その結果切り捨てられた数字分どんどん誤差が大きくなり、
モデルが大きくなったり小さくなったりしていったわけですね。
やるのであれば、常にベースの数字から計算していかなければならなかったわけです。
小数点以下が存在する計算をする場合、押さえておかなければならない基本中の基本の考え方ですね。
まぁ、正直に計算で出す方法もありますが、
例えば30fpsで１回転させるのであれば、
30分割した基本のxyz座標データを最初から用意して、
計算するコストを減らすって方法もありますね。
その後就活も始まりますが、当初目指していたゲーム会社に行くことなく、
就職説明会に来ていた普通のシステム開発会社へ入社が内定する事となります。
ラクをしたいという思いの通り、特に苦労することなくここまでトントン進んでいきます。
今にして思えば、ダメ元で大手受けとけばよかったかなというのが、唯一の後悔でしょうか。
そして社会人へ…
社会人になった私はそこで、より実践的な経験を積む事になります。
まず最初に…
といきたいところですが、ここで時間がきてしまったようです。
こんな感じで社会に出た私ですが、その後数々の経験を得てどれだけの事ができるようになったのか。
次回から各案件での経験を元にご披露できればと考えております。
それでは、次回
猫はきまぐれさん
をお楽しみに！
