プログラマ専用SNS ミクプラ

前のトピックの関係のことです。
stateをスタックに積む方法を使っています。
質問は２つです。

①
操作に対する確認(セーブ、ロード、タイトルへ戻るなど)画面を使いまわそうと考えています。
それぞれの違いは
○「□□□しますか」の質問文の□の部分
○はい　を選んだ時の処理
くらいです。

この確認画面で はい を押された場合にどの処理をするかや□に何を表示するか、確認画面から戻ってきた時にどちらが選択されたかを判断する必要があります。
普通に関数を呼ぶなら引数と戻り値でいいのですがstateを変えてメインループから分岐するためこの方法はできません。
となるとどれの確認画面かのフラグと戻り値を保存するグローバル変数を作るしかないのでしょうか？
グローバル変数は出来る限り少なくしたいのでなにか良い方法があれば教えてください。

②
メニューやオプションなどをどこから呼んだかわかり戻るのが楽なようにウィンドウ表示したい部分以外でもスタックにstateを積んでいます。
そうすると、ゲーム→メニュー→オプション→キャラクター→ステータスと呼んだとしてキャラクターやステータスが透明部分なしの全画面だとゲームやメニューの描画が無駄になってしまいます。
対策として上から順に見ていって透明部分がないところまで行ったらそこから上を順に描画するというのを考えました。
しかしこれだと各stateの描画で透明部分があるかの情報の追加や毎回の描画でどこから描画開始するかの確認が必要になります。
場合によっては無駄であってもとりあえず下から全部描画していったほうが早いこともあるかもしれません。
すべて描画すればいいようにウィンドウのためのスタックと戻るstateを保存するためのスタック２つを用意する方法も考えましたが管理がめんどくさくなりそうな気がします。
どうするのがベストなのでしょう？

①
ステートを構造体にすればフラグ持たせられると思うのですが、どうでしょう？
よりオブジェクト指向的な方法を取るならステートクラスを作って継承させる手もあります。

②
無駄な処理があるからといって、それが直ちに駄目ということにはなりません。

前のトピックでもそうですが、L'zさんは実際に試さずに勝手に処理が重いと判断している部分があります。
「無駄」がパフォーマンスに影響が出た時に初めて、無駄な処理の削減を検討するべきです。

h2so5 さんが書きました:①
ステートを構造体にすればフラグ持たせられると思うのですが、どうでしょう？
よりオブジェクト指向的な方法を取るならステートクラスを作って継承させる手もあります。

構造体を使えばstateを変更したときにメンバのフラグも書き換えればできますね。ありがとうございます。

オブジェクト指向のほうも知っておきたいのですがなんとなく知っているくらいで継承は使ったことがないです。具体的な使い方としてどのようにすればいいんでしょう？

h2so5 さんが書きました:②
無駄な処理があるからといって、それが直ちに駄目ということにはなりません。

前のトピックでもそうですが、L'zさんは実際に試さずに勝手に処理が重いと判断している部分があります。
「無駄」がパフォーマンスに影響が出た時に初めて、無駄な処理の削減を検討するべきです。

現時点では簡単なものしか作ってないため影響は出ません。しかし、いつか大きな物をつくるときは影響が出るかもしれないので、大きく複雑なものを作っているときに色々と試すのではさらに複雑になるため簡単なものを作っている今 効率がよく無駄の少なくできる方法で作り大きな物を作るときに負担が少なくなるよう考えているのですがこういう考えはよくないのですか？

L'z さんが書きました:

h2so5 さんが書きました:②
無駄な処理があるからといって、それが直ちに駄目ということにはなりません。

前のトピックでもそうですが、L'zさんは実際に試さずに勝手に処理が重いと判断している部分があります。
「無駄」がパフォーマンスに影響が出た時に初めて、無駄な処理の削減を検討するべきです。

現時点では簡単なものしか作ってないため影響は出ません。しかし、いつか大きな物をつくるときは影響が出るかもしれないので、大きく複雑なものを作っているときに色々と試すのではさらに複雑になるため簡単なものを作っている今 効率がよく無駄の少なくできる方法で作り大きな物を作るときに負担が少なくなるよう考えているのですがこういう考えはよくないのですか？

プログラムのパフォーマンス云々を気にしないで必要な機能を実装できる力があれば、もちろんパフォーマンス向上のためのプログラミング方法を勉強することは価値があると思いますが、L'zさんはまだまだそのレベルに達していないように見えます。

きちんと必要な機能を実装できるレベルにならないことには、パフォーマンス最適化の議論などできないだろうということです。
情報工学を学んでいると、最適化をする前に必要な機能を全部実装し、さらにきちんと性能計測の仕組みを導入してからやりましょう、という話をよく聞きます。

beatle さんが書きました:

L'z さんが書きました:

h2so5 さんが書きました:②
無駄な処理があるからといって、それが直ちに駄目ということにはなりません。

前のトピックでもそうですが、L'zさんは実際に試さずに勝手に処理が重いと判断している部分があります。
「無駄」がパフォーマンスに影響が出た時に初めて、無駄な処理の削減を検討するべきです。

現時点では簡単なものしか作ってないため影響は出ません。しかし、いつか大きな物をつくるときは影響が出るかもしれないので、大きく複雑なものを作っているときに色々と試すのではさらに複雑になるため簡単なものを作っている今 効率がよく無駄の少なくできる方法で作り大きな物を作るときに負担が少なくなるよう考えているのですがこういう考えはよくないのですか？

プログラムのパフォーマンス云々を気にしないで必要な機能を実装できる力があれば、もちろんパフォーマンス向上のためのプログラミング方法を勉強することは価値があると思いますが、L'zさんはまだまだそのレベルに達していないように見えます。

一応①はグローバル変数を使って、②は無駄でも全部描画する方法を使って実装はできます。
前のトピックのも配列に各stateのフラグを入れる方法で実装はできました。
stateの管理部分以外すべて完成でもないのでメニュー、オプションなどのすべての描画で試してませんが部分的に試して動きはします。
しかし、無駄が多くもっといい方法がないかと思い質問しました。
今回作っているものに関しては「プログラムのパフォーマンス云々を気にしないで必要な機能を実装できる力」はあるように思えるのですがどの辺りがたりてないのでしょうか？

beatle さんが書きました:きちんと必要な機能を実装できるレベルにならないことには、パフォーマンス最適化の議論などできないだろうということです。
情報工学を学んでいると、最適化をする前に必要な機能を全部実装し、さらにきちんと性能計測の仕組みを導入してからやりましょう、という話をよく聞きます。

パフォーマンス無視で完全に作り込んでしまってから変更になると時間がもかかるし大変なので実装前に良い方法を考えてから作ったほうがいいように感じるのですが、一度作ってしまうというのも作って問題なければそれでいけばいいということからなのですか？
それでうまくいけば最適化を考えなくてすみ楽ですがうまく行かないと時間がもったいないように思います。

L'z さんが書きました:パフォーマンス無視で完全に作り込んでしまってから変更になると時間がもかかるし大変なので実装前に良い方法を考えてから作ったほうがいいように感じるのですが、一度作ってしまうというのも作って問題なければそれでいけばいいということからなのですか？
それでうまくいけば最適化を考えなくてすみ楽ですがうまく行かないと時間がもったいないように思います。

そうですね。
初心者がどれだけ考えても抜け落ちるポイントが沢山あるので、そんな事で悩んでいるよりも完成させることを考えたほうが良いって感じですね。
とりあえず、１フレームの間にその処理を何回通るかで考えたらどうでしょうか？　現状と将来においても１フレームの間に１００回も通らない分岐処理なら気にするだけ無駄です。
それよりも分かりやすいか、メンテしやすいかを気にした方が良いですね。

L'z さんが書きました:一応①はグローバル変数を使って、②は無駄でも全部描画する方法を使って実装はできます。
前のトピックのも配列に各stateのフラグを入れる方法で実装はできました。
stateの管理部分以外すべて完成でもないのでメニュー、オプションなどのすべての描画で試してませんが部分的に試して動きはします。
しかし、無駄が多くもっといい方法がないかと思い質問しました。
今回作っているものに関しては「プログラムのパフォーマンス云々を気にしないで必要な機能を実装できる力」はあるように思えるのですがどの辺りがたりてないのでしょうか？

読み返してみると確かに実装はできてますね。僕の勘違いのようです。ごめんなさい。

beatle さんが書きました:きちんと必要な機能を実装できるレベルにならないことには、パフォーマンス最適化の議論などできないだろうということです。
情報工学を学んでいると、最適化をする前に必要な機能を全部実装し、さらにきちんと性能計測の仕組みを導入してからやりましょう、という話をよく聞きます。

パフォーマンス無視で完全に作り込んでしまってから変更になると時間がもかかるし大変なので実装前に良い方法を考えてから作ったほうがいいように感じるのですが、一度作ってしまうというのも作って問題なければそれでいけばいいということからなのですか？
それでうまくいけば最適化を考えなくてすみ楽ですがうまく行かないと時間がもったいないように思います。[/quote]
はい。あなたの言うことはよく分かります。僕もそう思います。
僕は、情報工学の分野で一般的に言われていることを書いただけです。

パフォーマンス最適化はコンパイラの最適化などとも関わってきますので、
「こう書いたら速くなるだろう」
という推測は、経験を積んだプログラマでも難しい場合があります。（速くなるだろうと思って書いたコードが逆効果だったりもします）

最適化には計測が必要、という言葉は、このあたりの事情から来ているのではないかと思います。

僕の今までの経験から言うと、あるプログラムは何度か全部書きなおすと結構良い実装になります。
初めから無駄のないプログラムを書こうとしても中々進みませんが、全部作ってからまた作りなおすと大きく改善したりします。

また、最適化すると保守性に乏しいコードになりがちですので、そういう意味でも初期からの最適化は害であるということでもあります。

softyaさんの言葉に関連しますが、実行時間の8割は2割のコードで消費されるという話があります。正確に統計を取ったわけではないでしょうが、大きく間違っているわけでもありません。
効率を気にするのは、8割の実行時間を食っている2割のコードだけでいい、ということですね。

提案。

①
stateを管理するクラスを作ってインスタンスをグローバルにして、状態の参照と変更をメンバ関数で行えば現状に状態に合わせて状態を変更することが出来るようになります。
スタックに積むとか破棄するとかもメンバ関数です。

②
ベストな方法「処理落ちしないなら気にしない」。
なぜなら描くかどうか対応する以上は処理が複雑になるからです。
プログラムが複雑になる方向への仕様変更は全てにおいてプログラマがまず避けるべき事柄です。
メンテナンス性が下がる & バグの可能性が高くなる。
ろくな事になりません。

softya（ソフト屋) さんが書きました:初心者がどれだけ考えても抜け落ちるポイントが沢山あるので、そんな事で悩んでいるよりも完成させることを考えたほうが良いって感じですね。
とりあえず、１フレームの間にその処理を何回通るかで考えたらどうでしょうか？　現状と将来においても１フレームの間に１００回も通らない分岐処理なら気にするだけ無駄です。
それよりも分かりやすいか、メンテしやすいかを気にした方が良いですね。

そうですね。ゲーム制作に関してはまだまだ初心者なのでミスも多いと思います。
分かりやすさ、メンテナンスの容易さも重要だと思うので多少の無駄は気にしないようにします。

beatle さんが書きました:

L'z さんが書きました: パフォーマンス無視で完全に作り込んでしまってから変更になると時間がもかかるし大変なので実装前に良い方法を考えてから作ったほうがいいように感じるのですが、一度作ってしまうというのも作って問題なければそれでいけばいいということからなのですか？
それでうまくいけば最適化を考えなくてすみ楽ですがうまく行かないと時間がもったいないように思います。

はい。あなたの言うことはよく分かります。僕もそう思います。
僕は、情報工学の分野で一般的に言われていることを書いただけです。

パフォーマンス最適化はコンパイラの最適化などとも関わってきますので、
「こう書いたら速くなるだろう」
という推測は、経験を積んだプログラマでも難しい場合があります。（速くなるだろうと思って書いたコードが逆効果だったりもします）

最適化には計測が必要、という言葉は、このあたりの事情から来ているのではないかと思います。

コンパイラの最適化はコンパイラによって違うみたいですしそこまで考えると全然わからないです。
アセンブラを少し勉強したことがあるので関数にすると少し処理が増えるとかその程度の知識はありますがうまく最適化したコードがかけるようになるにはまだまだ遠そうですね。

beatle さんが書きました:僕の今までの経験から言うと、あるプログラムは何度か全部書きなおすと結構良い実装になります。
初めから無駄のないプログラムを書こうとしても中々進みませんが、全部作ってからまた作りなおすと大きく改善したりします。

また、最適化すると保守性に乏しいコードになりがちですので、そういう意味でも初期からの最適化は害であるということでもあります。

softyaさんの言葉に関連しますが、実行時間の8割は2割のコードで消費されるという話があります。正確に統計を取ったわけではないでしょうが、大きく間違っているわけでもありません。
効率を気にするのは、8割の実行時間を食っている2割のコードだけでいい、ということですね。

「初めから無駄のないプログラムを書こうとしても中々進みません」というのはすごく同感です。とりあえず動くもので書こうと割りきって書くとけっこうスムーズにかけます。
こう考えたのはたいてい複雑でなく単純なものが多いのでわかりやすいものになります。
「全部作ってからまた作りなおすと大きく改善したりします。」これも納得です。でも、とりあえず動いてるので直すのがめんどくさくなり、途中で放置になってしまったのも多々あります・・・
「実行時間の8割は2割のコードで消費される」というのは聞いたことがありませんでした。考えてみると実際に時間がすごくかかっている部分というのは一部だけの気がします。

プログラミングの上級者になれるまではとりあえず動く方法で完成させてしまい、処理落ちがひどかったり良い方法で作りなおそうと思ったりしたときだけ別の方法に変更するようにしたいと思います。

softya（ソフト屋) さんが書きました:提案。

①
stateを管理するクラスを作ってインスタンスをグローバルにして、状態の参照と変更をメンバ関数で行えば現状に状態に合わせて状態を変更することが出来るようになります。
スタックに積むとか破棄するとかもメンバ関数です。

②
ベストな方法「処理落ちしないなら気にしない」。
なぜなら描くかどうか対応する以上は処理が複雑になるからです。
プログラムが複雑になる方向への仕様変更は全てにおいてプログラマがまず避けるべき事柄です。
メンテナンス性が下がる & バグの可能性が高くなる。
ろくな事になりません。

①今回は簡単なもののつもりだったのでC++でなくCで書いていたのですがクラスにしてしまったほうが構造体やグローバル変数増やすよりはよさそうですね。

②今回はすべて描画する方法のままにします。



ふと思ったのですが、h2so5さんやsoftya（ソフト屋)さんに教えてもらったstateを構造体やクラスにする方法や前トピックでDixqさんに教えてもらった中間の値を使ってフェードを使えるようにするなど、stateが複数の値を持てるようにしたり別の機能(フェード)の役割ももつというのは一般的によくあることなのですか？
今までstateはint型で場所を表すだけというものしか見たことがなかったので、今後ゲーム作るときにstateを積極的にクラスや他の機能にも使えるようにするのか、今回のように作りたいものに必要なのでしょうがなく追加するのかどちらがいいのか気になりました。一般的なのなら今回のようなstateの使い方を普段からしようと思います。

L'z さんが書きました:ふと思ったのですが、h2so5さんやsoftya（ソフト屋)さんに教えてもらったstateを構造体やクラスにする方法や前トピックでDixqさんに教えてもらった中間の値を使ってフェードを使えるようにするなど、stateが複数の値を持てるようにしたり別の機能(フェード)の役割ももつというのは一般的によくあることなのですか？
今までstateはint型で場所を表すだけというものしか見たことがなかったので、今後ゲーム作るときにstateを積極的にクラスや他の機能にも使えるようにするのか、今回のように作りたいものに必要なのでしょうがなく追加するのかどちらがいいのか気になりました。一般的なのなら今回のようなstateの使い方を普段からしようと思います。

正解という定番はないと思いますが、私なら各処理にstateを分散します。
提案はあくまでも今までのL'zさんの方針にそって行いましたので全く違う意見ですけどね。

オプションはオプションのstateで、ゲーム状態はゲーム状態のstate、ステージ上の展開はステージの展開stateです。
各モジュール（ファイル）が各々のstateを持つことになります。これならクラスでもC言語でも変更関数やアクセス関数で外部からstateの変更が出来る設計ができます。
更に外部からアクアス出来なくてモジュール内で閉じていれば更にgoodです。

softya（ソフト屋) さんが書きました: 正解という定番はないと思いますが、私なら各処理にstateを分散します。
提案はあくまでも今までのL'zさんの方針にそって行いましたので全く違う意見ですけどね。

やっぱり作るものに応じて変えるべきですよね。

softya（ソフト屋) さんが書きました: オプションはオプションのstateで、ゲーム状態はゲーム状態のstate、ステージ上の展開はステージの展開stateです。
各モジュール（ファイル）が各々のstateを持つことになります。これならクラスでもC言語でも変更関数やアクセス関数で外部からstateの変更が出来る設計ができます。
更に外部からアクアス出来なくてモジュール内で閉じていれば更にgoodです。

この方法だと今ゲーム状態なのかオプションなのかを表す大きな単位でのstateも必要になりませんか？

L'z さんが書きました:この方法だと今ゲーム状態なのかオプションなのかを表す大きな単位でのstateも必要になりませんか？

オプション・モジュールにポーズ中か問い合わせることで各処理が各々ポーズ状態に移行します。

softya（ソフト屋) さんが書きました: オプション・モジュールにポーズ中か問い合わせることで各処理が各々ポーズ状態に移行します。

各モジュールのstateにpauseというのを用意してpause状態だとそのモジュールは処理を行わない。
メインループではすべてのモジュールを順に実行するということですか？

L'z さんが書きました:各モジュールのstateにpauseというのを用意してpause状態だとそのモジュールは処理を行わない。

各モジュールでたぶんstateを変更はしません。そうするとstateを戻したりややこしくなる可能性があります。
必要な所でoptionモジュールにpause中か問い合わせて専用の処理をするだろうなと思います。

L'z さんが書きました:メインループではすべてのモジュールを順に実行するということですか？

メインループでは、大きなstate分岐はあるのでは？タイトルと本編とエンディングは別だと思いますけど。

ところでこれは一般論ではなく私なりの組み方という事ですので誤解なきように。

softya（ソフト屋) さんが書きました: 各モジュールでたぶんstateを変更はしません。そうするとstateを戻したりややこしくなる可能性があります。
必要な所でoptionモジュールにpause中か問い合わせて専用の処理をするだろうなと思います。

pauseというstateを作ってそれを確認するのではなく毎回直接問い合わせるんですね。

softya（ソフト屋) さんが書きました: メインループでは、大きなstate分岐はあるのでは？タイトルと本編とエンディングは別だと思いますけど。

softya（ソフト屋) さんが書きました:

L'z さんが書きました: この方法だと今ゲーム状態なのかオプションなのかを表す大きな単位でのstateも必要になりませんか？

オプション・モジュールにポーズ中か問い合わせることで各処理が各々ポーズ状態に移行します。

このときの大きな単位のstateというのとは別ですか？
タイトル、本編、エンディングの３つにstate分岐し、その中でゲーム、オプションなどをモジュールに問い合わせる方法ということでしょうか？

softya（ソフト屋) さんが書きました:ところでこれは一般論ではなく私なりの組み方という事ですので誤解なきように。

はい、わかってます。
softya（ソフト屋)さんはプログラミングはとても詳しいと思うので十分参考になると思うので１つの方法として理解しておきたいと思います。

L'z さんが書きました:このときの大きな単位のstateというのとは別ですか？
タイトル、本編、エンディングの３つにstate分岐し、その中でゲーム、オプションなどをモジュールに問い合わせる方法ということでしょうか？

グループというかレイヤ(階層)分けして考えてみます。
シューティングを例にとると各レイヤとstateとして
(1)全体的な状態：　タイトル、オープニング、ゲーム本編、エンディング、ゲームオーバー
(2)オプション状態：　タイトルオプション、ゲーム本編オプション
(3)ゲーム本編のステージ状態： ステージ1,2,3・・・FINAL
(4)ゲームステージ内の状態：ステージ前半、中ボス、ステージ後半、ボス
などと言った考えが出来ると思います。
つまり、4つのstateで制御できますね。

階層としてはオプションは特殊なのでstateレイヤとしては一番深くて３レイヤでしょうか。
各レイヤのstateは各レイヤを制御するモジュールが各々管理します。

(2)のオプションだけは各モジュールがオプションモジュールにpause中か問い合わせると言った感じでしょうか。
(1)全体的な状態の制御もゲームオーバーやらエンディングへの移行には(4)レイヤのモジュールに問い合わせる必要が出てきます。

softya（ソフト屋) さんが書きました:グループというかレイヤ(階層)分けして考えてみます。
シューティングを例にとると各レイヤとstateとして
(1)全体的な状態：　タイトル、オープニング、ゲーム本編、エンディング、ゲームオーバー
(2)オプション状態：　タイトルオプション、ゲーム本編オプション
(3)ゲーム本編のステージ状態： ステージ1,2,3・・・FINAL
(4)ゲームステージ内の状態：ステージ前半、中ボス、ステージ後半、ボス
などと言った考えが出来ると思います。
つまり、4つのstateで制御できますね。

階層としてはオプションは特殊なのでstateレイヤとしては一番深くて３レイヤでしょうか。
各レイヤのstateは各レイヤを制御するモジュールが各々管理します。

(2)のオプションだけは各モジュールがオプションモジュールにpause中か問い合わせると言った感じでしょうか。
(1)全体的な状態の制御もゲームオーバーやらエンディングへの移行には(4)レイヤのモジュールに問い合わせる必要が出てきます。

階層化するとわかりやすくなりますね。理解できました。
いつも最後まで丁寧に回答していただきありがとうございます。

解決したようですが、せっかくなので書いておきます。

YAGNIという言葉があります。
作っている途中でこうすればもっと良くなると思うアイデアのほとんどは役に立たないか、最終的にもっと優れたアイデアで上書きされるので無駄だというのはずいぶんむかしからの常識であるようです。

完成したものに対してこうすればもっと良くなるというのは結果がどうなるかはともかく確実に得るものがあります。
ただし、なんとなく無駄だと思う、とかではなく、パフォーマンスとか保守性とか具体的な目標が無いと意味を持ちません。
実質的に改善しなくてもリファクタリングを行いプログラムの構造を解析することで良い設計をする力が付くはずです。


現在のステートだけを保持する方法は、サンプルプログラムや単純な遷移しか行わないアプリ(パズルゲームとか)でしか見たことがありません。
わたしが作る場合は、最低でも現在のステートと次に遷移するステートを持つようにします。

前のスレでスタック形式を提案したのはわたしですけど、これは要するに最上位のものがアクティブであると考えることができます。
ウィンドウズのウィンドウのシステムを単純化したものと思ってもらえれば良いです。入れ替えはできませんけど。

ステート管理モジュールに対しては、『遷移先を指定して進む』、『戻る』、『遷移先に切り替える』というイベントを設定するメソッドを用意して、各モジュールは『遷移先があるかどうか』だけで処理を継続するかどうかを判断します。
各モジュールが遷移するときに演出を行う場合は、遷移演出を行うタスクを登録してそれをカウントします。
ステート管理モジュールは遷移演出を行うタスクが存在するあいだは『遷移先がある』状態を維持したまま遷移を保留します。#Dixqさんの言う0.5の状態？
遷移先の設定が検出されたとき各モジュールが自発的に遷移に向けて動く仕組みです。
各モジュールはステート管理モジュールの共通インターフェースを通じて動くので他のモジュールに依存しません。

おおむかしDOSでウィンドウシステム作ったときのやり方を応用しているのですが、アクティブではなくなった背景でアニメしたい場合は、タスクにアクティブでなくても動くという属性を設定すれば良いですし、全画面を覆ってしまって後ろが見えなくなるときは、排他制御を行い後ろのタスクを静止状態とすることで無駄な描画を省くこともできます。

(追記)
Zオーダーを管理するモジュールは設計に悩むかもしれませんが実装はけっこう簡単です。
応用範囲は広いので作っておくと便利です。

ISLe さんが書きました: 現在のステートだけを保持する方法は、サンプルプログラムや単純な遷移しか行わないアプリ(パズルゲームとか)でしか見たことがありません。
わたしが作る場合は、最低でも現在のステートと次に遷移するステートを持つようにします。

大きなプログラムになってくると複数のstateをもつものが普通なのですね。



ステート管理モジュールやウィンドウシステムの話は難しいですね。
必要になった時にまた質問するかもしれませんがよろしくおねがいします。


回答ありがとうございました。