雑談

[dic]

メリークリスモスバーガー！


・・・


はい寒くなったところで質問、雑談？のトピックを立てます



多くの人がここのプログラムを参考にして状態遷移については
mode という変数を用意しておいて
switch( mode ) で状態を切り分けるという方法が多いかなと勝手に想像してます
そこで、そのほかの方法でもできるので、なぜか気になり、納得いかないというか
気分がスッキリ晴れません
私の場合、class Base というクラスを作りこれに public: virtual void Move(); という仮想関数を作って
class Title : public Base とBaseを継承させて Titlte::Move() と仮想関数をオーバーライドさせて
Base *title = new Title();
// ループで
title->Move();
として状態遷移を実現してます
ポリモーフィズムを使うことで動的にBaseオブジェクトからTitleクラスのMoveを呼び出します

なんというかモヤモヤしたものがあるんですが
やり方１では簡単で初心者向き
やり方２ではちょっと複雑、でも骨組みができると簡単
やり方３は複雑、C/C++の知識が必要
というような、評価をしているようなサイト、もしくは書籍ってないものなのでしょうか？

いくら、いろんな手法でやってもプログラムはほとんど裏方で誰にも気づかれないので
どんなに努力しても報われない、そんな気がしているのです
そこらへんどうなのでしょうか？
プログラムは手段であって、実行ファイルが完成すれば書き方なんてどうでもいい
という考えが会社などでも通用してるのでしょうか？

[ぬっち]

1年ほど前に読んだもので、今ちょっと見れない状態なのではっきりと覚えていませんが、「ゲームプログラマになる前に覚えて起きたい技術」に状態遷移の話がわりと詳しく載っていた気がします。
当時の私は、switchばかり使っていてクラスでの状態遷移を知らなかったので大変参考になったのを覚えています。

覚えてる限りでは、switchによる状態遷移の実装は簡単だけどbreakのし忘れによるバグが危険とか、クラスを用いた状態遷移は継承など面倒な機能を使わなければならないとか、そんなことが書いてあった記憶があります。
dynamic_castの説明もその時にしていた気がするのですが、ちょっとそのあたりは覚えてません^^;

[softya（ソフト屋)]

なんというかモヤモヤしたものがあるんですが
やり方１では簡単で初心者向き
やり方２ではちょっと複雑、でも骨組みができると簡単
やり方３は複雑、C/C++の知識が必要
というような、評価をしているようなサイト、もしくは書籍ってないものなのでしょうか？

私は見たことがありませんので、それは自分で確かめるしか無いでしょう。
でも作っているとだいたい危険なパターンは見えてくると思います。
switchよりは、関数ポインタや継承したクラスを使ったほうがバグの出る確率として安全だと思いませんか？
どっちが安全で書きやすいかそれだけです。
後は使う人の技術力の問題だけですので、多人数の場合はそれも考慮したほうが良いでしょう。

いくら、いろんな手法でやってもプログラムはほとんど裏方で誰にも気づかれないのでどんなに努力しても報われない、そんな気がしているのですそこらへんどうなのでしょうか？
プログラムは手段であって、実行ファイルが完成すれば書き方なんてどうでもいいという考えが会社などでも通用してるのでしょうか？

プログラムの様々なテクニックの大半はバグを避け、開発効率を上げるために考えられているモノが多いです。
個人ならともなく多人数が使ってバグが発生が少なく使いやすいのがゲーム会社としては理想の状態遷移ですので、そうなるとだいたい形態は絞られてくるのではないでしょうか。
動けばOKなんてのは前時代的な考えとゲーム会社では捉えます。
でったデバッグ時に地獄は見たく無いですからね。

[ISLe]

いくら、いろんな手法でやってもプログラムはほとんど裏方で誰にも気づかれないので
どんなに努力しても報われない、そんな気がしているのです
そこらへんどうなのでしょうか？

報われるとはどういうことなのでしょうか。
フレームワーク化して使い回すことで開発効率があがりますけど、そういうことではないのでしょうか？
定型のコードを書かなくて済むようになってどんどんメインのソースファイルがシンプルになっていくのは楽しいですけど。

プログラムは手段であって、実行ファイルが完成すれば書き方なんてどうでもいい
という考えが会社などでも通用してるのでしょうか？

同じ言い方でも心構えが180度違いますね。
会社では、新しい技術を取り込むよりもバグ発生のリスクが少なく確実に動くものを作れるほうが良い、という意味で「書き方なんてどうでもいい」なのです。

むかしケータイアプリ(Java)でクラスは4つまでという縛りのあるメーカーがありました。
そういうときはswitchしか使えないですね。

[dic]

>>ぬっちさん
私も本屋でその本を見かけて立ち読みしたんですが、あまり有益な情報ではないなぁ・・・と思ったので
購入しませんでした
いろいろ細かいことがかかれてたことは覚えてますが内容までは覚えてないです
本を書くのは大変で、さらに売れるとなるともっと大変ですね

>>softya（ソフト屋) さん
たしかに、ちいさなコードミスを防ぐという作用もありますね
評価ばかりに目がいってて気がつきませんでした
たしかにテクニックの大半はバグを避け、開発効率を上げるものですね
将棋のように、定石ができるように、効率を求めていったらこうなっていたという形でしょうね
何年も続くソフトウェアならなおさら保守的に考えても、パターンとして認識するのはいい考えですね

>>ISLeさん
フレームワークとしてできあがって開発効率が上がっていくのも、昔の自分の苦労の結果で
今の自分は報われていると考えれることもできますね
暇なときはフレームワークを作れと、どこかで聞いたのですが、このためですね
今は小さいフレームワークなのであまり体感できていないかもしれないです

ちいさい努力の結果が将来を作っていく、なんだか実感できます
ありがとうございました