今週月曜日から修行が始まりました。
新しい環境にビクビクしながらもなんとか一週間を終える。。。。。

今回の制作はC/C++での開発。
AndroidでのJavaやiPhoneでのobjective-C、
UnityでC#、
WindowsでのC/C++など、勉強はしていたものの現場でのコンシューマー機によるC/C++は世界が違った…！！

今回はこの業界でのベテランの方の下で仕事をするので
あらかじめその方が用意していたフレームワークの上での開発ですが、それでも難しい。


今回の修行ではそのフレームワークの作り方、コンシューマー機での考え方を学習します。


今週一週間で学習したのは
・テンプレートの多用には要注意、STL、boostとかは使わないほうが無難
テンプレートを多用した開発は失敗に終わる、デスマの原因になる可能性が非常に高いらしいです。
もちろん使って便利な部分もあるけれど、という付け足しの上で。
土台を作るには便利だが、それ以外の場面で使わないほうが良い、特にゲーム部分の実装では。

・クラスの関係はシンプルに
多重継承をしまくったり、継承関係が複雑になりすぎると追いづらいのであまりオススメはしないと言われました。


・実装内容はなるべく隠蔽化
ヘッダーに記述する内容が多いと、後の仕様変更に対応しづらくなっていく（わけではないけど面倒になっていく）そうです。
ヘッダーにはできる限り公開する内容のみを記述し、隠蔽する内容はソースに記述。
この関係からクラスをソースに直接記述するのが非常に多いようです。



・システムは汎用化せずに、利用用途は開発者にわかりやすいように、そして変更しやすいように。
例えば というような記述をすることによって、そこに引数を指定するだけでその色に変更できるという関数であったとします。
しかしこれを何千回も書く可能性もあるし、色変更するにあたって仕様が変わればすべてに変更をかけなければいけない。
非常に大変なので
というような感じで「どういう内容なのか」が開発者には明確で、
フェードカラーが255,255,255→240,240,240のように変更されるとしても一箇所をかきかえるだけで良い。
つまり引数を指定せずに「そいつを呼べばそいつの内容が実行される」ようにすること

というふうに教わりました。
(まぁこれはいろいろな場所で使うことを考えれば最終的にこう考えて当然とも言えますが…)
ただ、ここで一点教わったのは「汎用化してもどうせ汎用されない、決まった使われ方しかされないことが多い」ということ、
ここで変にこだわるのはプログラマーのマスターベーションに過ぎず、そういうことは日曜プログラマーでやってなさい、
というアドバイスをいただきました。


・宗教にはこだわらない
まぁこれは言うまでもなく。


・マクロはうまい感じに使う。
ヘッダーにはなるべくマクロは記述しないほうが良いと言われました。
さらに言うのであれば、ソース部分の限定的な使い方をしたほうが良い、とも。
defineしたら必ず使用後にundefする、
ローカル変数と同じように一時的にしか利用しないものは、最後にちゃんと片付ける。そうすればバグは起きない
上手に使えば恐れるものではないが、あまり多用しようと考えないように、とも言われました。



まぁこんな感じです。
「お客さんが納得のいくものを作るのが第一なのであってプログラムを書く事はその過程に過ぎない」
「お客さんはプログラムのことなんてわからないし、技術的な説明をしたってわからない。それなのに技術的に拘るのは愚策である」
「時間は有限でそれまでに完成品を用意しなければいけない」
「コンシューマーはPCのように莫大なメモリもないし、OSと言えるほどのものでもない。当然PCと同じ感覚では動かない」
「コンシューマーでのアプリ部分で発生し得るバグ、エラーはすべて開発者の責任である」


AndroidやiPhone、はたまたWindowsなんかはどれもOSなので、
そこでの開発しかしていなかった人間にとっては未知の世界とも言えます。


ベテランの方のアドバイスをしっかり聞くことができる今の間に、
昔の人のやらかしたミスや失敗談を取り入れながらも今後も学んでいければいいですね。



ではでは

せんちゃ さんが書きました:実際のところ、テンプレートはあまり使わないほうが良い、とは言われましたがフレームワーク部分にはアロケータやファンクタ、
StringクラスなどSTLとほぼ同等のものをテンプレートを使って作成していたのを見ています。

テンプレートは、(プリプロセッサではない)コンパイラ埋め込みのマクロだと理解すれば良いのではないでしょうか。
要するにどのようにインライン展開されるのかを把握して使う分には問題無いし便利だと思います。
限定されたスペックの上で開発するには意識せざるを得ないですね。

STLやboostは中身を把握できないから使わないわけです。
処理系やライブラリの更新で生成されるコードが想定外に変化すると困りますから。

私がゲーム業界にいたころでコンシューマと言うと、セガサターンやプレステーションだった時代。
C言語が主流だっただけに、当時はライブラリという概念で作ってましたな～
フレームワーク？　うーん、、そういう呼び方はしてなかったと思うけど、
同じジャンルをいくつか出していると、ゲームの進捗とかシナリオとか、進め方は大体決まっちゃうのでそういう意味では、固定化している部分がありましたね。
要はつぶしがきく作り方を心がける？という感じでしょうか (^^;

もう今じゃ全てのジャンル出尽くしてない？と思えるほどゲームがあふれているので、全く一からフレームワークみたいなものを作ることってないんじゃない？
あ、でも自分で作れるぐらいになれ、とか言われちゃってますかね？

ISLeさん
なるほど、アドバイス感謝です。

へにっくすさん
フレームワークというよりはなんでしょうか、
確保した分のインスタンスはすべて確保されて、開放するときにすべて解放される、
メモリ管理をなるべくプログラマー側が意識しなくても良いように設計されたシステムの上で設計している
という感じと言ったほうが正しいでしょうか。。。
いわゆるタスクシステムというものですね。

それによって実際にハード側が提供しているAPIはすべてラッパーされており、データリストにインスタンスを追加すれば画像が表示されたり、
入力された際のレスポンスハンドラを実装したり…
入力制御から音楽の再生APIまですべてラッパーされており、
そういった土台を今はフレームワークと呼んでいる感じですね。



＞もう今じゃ全てのジャンル出尽くしてない？と思えるほどゲームがあふれているので、全く一からフレームワークみたいなものを作ることってないんじゃない？
聞いていないので何とも言えないですが、全く一からというよりは一回作ったシステムを使いまわしているとは思います。
土台の設計自体はどんなマシンでも実現できるようなものなので。。。
ただ、用意された部分はすべて元をたどると自社開発(というよりは私の上司に当たる方が一人で作ったようです)のようです。