実装物（プログラム）スレ - 1316517064

1：名無しさん：2011/09/20(火) 20:11:04: 旧スレ
実装物（プログラム）スレ
http://jbbs.livedoor.jp/bbs/read.cgi/game/49808/1267069936/
2：spinor：2011/10/04(火) 22:42:44 ID:pKobkEs60: とりあえず Windows でビルドできるようになった（はぁと）
MinGW がどのように DLL を扱うのか少し分かったような希ガス

ようやっと、明日から実装に戻れそう
3：spinor：2011/10/06(木) 21:50:33 ID:LQu2.vc.0: 戦闘システムの設計について、今のところ、大体の大枠が決まりつつあります

SDL/Linux→DirectX/Windowsの移行で時間をとられるので
戦闘システムの詳細決定は少し遅れそう…
4：no.774さん：2011/10/07(金) 01:54:33 ID:c4RZpmm6O: 本スレで誘導レスした者ですがすでにこちらを使ってたんですね!
失礼しました
本スレの人らも気づいてると良いんですが
5：spinor：2011/10/13(木) 22:41:59 ID:7MPxpuu.0: 今は、会話や戦闘時に使うウインドウの表示を実装しています

４人目については、どちらでもいいです
固定でも、入れ替えでも、対応できるように実装するつもりです

とりあえず、地味な裏方作業がしばらく続くと思います。。
視覚的に分かる変化あったら、その都度お知らせします
6：73：2011/10/14(金) 09:54:58 ID:IDY8L8qs0: ありがとうございます！

入れ替えに関しては、やはりややこしくなるのよりは、
ある程度簡略的な方が作りやすいんじゃないかなといった感じです。
それはプログラムというか調整が楽になると言った感じですかね？

たくさんのキャラを動かしたいという要望に関しては、イベントやゲストと言うかたちで、
実現できたらいいなと。
7：no.774さん：2011/10/20(木) 23:52:25 ID:GacpATlkO: 普段使ってるのはCとC#なんで話半分ぐらいで聞いたってください。

thisでもm_でも良いと思うんだけど、
今はもう補完機能前提なのが普通と違うかな。
だから件の変数名も長くて平気だったりとか。

＞ログとか
util.cppってあるんだし、そこにエラー出力関数だけ定義しちゃって良いんじゃない？
streamにこだわりたいならちょっとギャップある。
デバッグログとエラー表示に同じ機構を使う必然性はさほどないと思うよ。
8：no.774さん：2011/10/21(金) 00:16:02 ID:YR0XzPgIO: 携帯でクソ長文書いてたら日ぃ変わってもたが、
まぁ上らはわりと瑣末で。
ついでにちょっと今日のコミット見て思ったことを書いてみる。
思い過ごしならスルーして。

構造をきれいにする方に意識が行き過ぎて迷走しかけてるように見える。
早く動かすのは諦めて、ちゃんと設計フェイズを入れた方が良くはないか？
それは分担の面でも。
俺個人そんなに動ける技術も時間もないけど、
出来る範囲で何かしようにも今の状態だと手の出しようがない。

既存のに追いつかないと風当たりキツいのは分かるけど、
なんかちょっと心配になる。

例えば何だろ。
すごい半端なところでコミットされてるんだろうとは思うし、
設計のポリシーもイマイチ分かってないけど、
drawableやらjob_baseやら、ホントにbattleか？

まぁナニだなぁ。
ちょっとコミット止まると「またぞろ逃げた」とか
すぐに言われそうな雰囲気もなんだかなぁ・・・
9：spinor：2011/10/21(金) 19:43:41 ID:OgCtuOjI0: なんか本スレの空気悪くなってる…というか人違いされてる…OTL
全部、私の実装が根源なので申し訳ない。。

>>7-8
お世話になります

補間機能前提ですか…その通りだと思います
命名規則困った。。広く浸透した業界標準とかあれば、それに
合わせてそれでおしまいにできるんですが

ログについては、エラー表示だけでも早めに実装します

迷走している自覚あります（汗）
コミットのログで「軽微な変更」とか、普通にあり得ないし
意味のある単位でコミットできていないと思います

ただのログ保管場所ｗ余裕なしですね…

drawableとかjob_baseはどうしようか迷って、結局参加者来ないから
しばらくは全部battle/に入れて、後で場所変えるか！みたいな…
10：73：2011/10/21(金) 19:49:26 ID:MRsY.TEk0: 乙です！
いやいやプログラム関係はずーーーっとあんな調子なので、お気になさらず！
以前より活発にプログラム談義が行われていることに、spinorさんに感謝したいところです。

理想を言えば、チャットでプログラム談義をがっつりしてもらえるのが良さそうですが、
なかなか皆さん時間がとれないようですね。

焦らずにご自分のペースでやっていただいて大丈夫ですよ。
煽ってる人らのことは全然気にしてないので(・∀・)
11：no.774さん：2011/10/23(日) 01:36:02 ID:qZGsNevo0: 参加してもいいけど、設計方針が見えないからなかなか入りづらいよね
多分、今参加してもインターフェースも決まってないから、余計に構造がおかしく
なりそうだし
あとソース公開場所はwikiにリンクしておいて欲しい
12：spinor：2011/10/23(日) 21:24:18 ID:5gbygP3.0: >>11
お世話になります

↓のページの先頭付近に、ソース公開場所を入れました
ttp://www31.atwiki.jp/fftsukurou/pages/121.html

バトルに関するプログラムのインターフェースは、今のところ手探り状態です
もし、興味があれば、ワールドマップやダンジョン、キャンプ画面なら、バトルとは独立して開発できます
シーケンス切り替えのインターフェースは、大きく変わらないと思いますから

担当するプログラムは、ディレクトリに入れて、名前空間で区切れば、
かなりバトルとは独立した状態で開発できますよ

どの名前空間にいれるか、未定のクラスは、一番上のディレクトリに暫定的に入れている状態ですが。。

あとは、入力処理ですね。。今のままだと、思った処理ができないと思います
その辺りは、近いうちに改善したい。。
13：no.774さん：2011/10/23(日) 22:30:54 ID:kl8nHy6oO: >>12
ちょい待ち。
先にプレイヤーキャラのデータの持ち方、参照の仕方を決めるべき。

あとcontrollerとsequenceの関係が分からない。
戦闘画面で「LR同時押しで逃げる」はどう実装されるイメージ？

少なくともこの2つがはっきりしない状態で複数人でやるのは危険だと思う。
画面だけ先行してもはっちゃけるし。
14：spinor：2011/10/24(月) 23:23:44 ID:Hkc14DqU0: >>13
今、パッチの作り方のページ案を考えています
もうちょっと待ってて

とりあえず、↓を参考にして下さい。殴り書き＆ひどい図は許して
ttp://ux.getuploader.com/fftsukurou/download/75/seqence.pdf

プレイヤーキャラのデータのインターフェースは、もうちょっと検討させて
15：no.774さん：2011/10/24(月) 23:25:17 ID:Hkc14DqU0: ダウンロードパスを設定していました…すみません（汗）
>>13 のIDです
16：no.774さん：2011/10/25(火) 22:09:09 ID:uNDO8BYYO: あ、念のため。
俺、>>13だけど>>11とは別人なので・・・
パソコン立ち上げるのが土曜だけの人間でもよけりゃ
しばらく参加してもいいけど。

>>14
拝見しました。

gitのコードと全然ちがくねぇ？www ＞ controller

よく分からんところを自分なりに解釈してみたんだけど、
下の認識であってる？

・handle_input()がキー押下による状態変化（カーソル移動、決定etc）で、
update()がその他の状態変化（アニメーションの制御etc）

・controllerが独立してるのは、Stateパターンみたいなことをしたい
（重複度無くてよく分からん）

あとsequence_manager見てて思った。
どこからでもswitch_sequence()呼べるか
update()でsequence_tを返すかしないと
画面遷移出来ないことない？
17：no.774さん：2011/10/25(火) 23:05:14 ID:Vm8g.ztg0: wikiのページに、コード実装に参加する方法を、追加しました
10月初旬に宣言したとおり、最初の５回くらいはパッチを本スレにうpして下さい

詳しくは ttp://www31.atwiki.jp/fftsukurou/pages/121.html を参照して下さい

>>16
是非、参加を検討されてみて下さい

今のコントーラは、以前SDLで実装していた時のままで、間に合わせ状態なんです
とりあえず >>14 のように、実装したいという、思いだけです（汗）

> handle_input()…
そのとおりです

> controller…
Stateパターンに重複度という概念あったかな…GoF本さらっと見たけど分かんないOTL
GoF本で言うと、sequenceがStateに、battle_sequenceがConcreteStateAに
camp_sequenceがConcreteStateBに、それぞれ対応するつもりだったんです

その上で、各シーケンスに対応するコントローラを保持させて、
キー入力処理を独自に実装できるようにして、各シーケンス間の疎結合を実現したいと思ったんです

> あと…
どこからでもswitch_sequence()を呼べるようにするつもりです

base_system::instance()->get_sequence_manager()->switch_sequence();
だと長いので、静的メンバにするか、instance()メンバ関数を検討しようと思います
18：no.774さん：2011/10/26(水) 21:58:57 ID:8sGsSm1cO: >>17
＞重複度
あ、いや、Stateパターンの概念ではなくて、
単にsequence1個に対してcontrollerが幾つ存在するのかな、
っていうクラス図上の表記の話。

＞controller
sequenceが入れ替わる方は分かるんだけど、同じように
ある1つのsequenceのサブクラスが状態によって幾つかのcontrollerを
切り替えながら動くのかな、と考えた。

そうではなくて、sequenceとcontrollerが常に1:1なら
sequenceのメンバ関数にhandle_input()があれば良くない？
どのみちsequenceとcontrollerは密接で使い回しも出来ないし、
クラスが増えて複雑になるだけで、メリットが無いように思えるよ。

元々はinput_handlerがcontrollerだけを意識すれば良いように
sequenceから分離させたんだと思うんだけど、
controllerがhandle_input()しかpublicなメンバを持ってないなら
それ自体が大層に見えるんだよねぇ。

どうだろ？
「でもやっぱcontrollerクラスは要るだろ」てことなら
それはそれで良いと思う。
19：spinor：2011/10/27(木) 22:24:21 ID:pT/IrE5Y0: >>18

重複度の件、私が大いに勘違いしておりました。申し訳ない…OTL
例をあげると、battle_sequenceはただ一つbattle_controllerを持たせる意図でした

シーケンスに、１つの入力処理関数をもつコントローラを複数持たせることは
どうも効率が悪そうで、考えていません。常に１：１です

base_system::enter_main_loop()からinput_handlerを外しました
その上で、更にシーケンスとコントローラを分割するか否か、ですね

時間が無くて実装できていないんですが、battle_controllerのフィールドに
メンバ関数へのポインタを持たせ、コマンド選択やアイテム選択などに対応する
異なる入力処理用のメンバ関数を複数実装しようと考えています

その上で、そのフィールドのアクセサを使って、入力処理関数をスイッチさせようかなと。。

あと、ＬＲボタンを押し続けたフレーム数の記録とか、エンカウントまでの歩数とかも
フィールドを使ってアクセスしようかと考えていたので、自然にそれらをカプセル化して
コントローラクラスを作ることになったんです

わざわざ、入力処理クラスを作る必要があるのか？という疑問を持つ理由はよく分かります
手続き型プログラミングとは作法が違うし、別のファイルにフローが飛んで面倒臭いもの分かります

要は、別のクラスに分割することのメリット、デメリットのバランスを見極める
必要があるかと。。
20：no.774さん：2011/10/27(木) 22:30:23 ID:pT/IrE5Y0: 連投すみません。ちとコーヒーブレイクをば

私にとって↓の辺りの影響が強いのだと思います
ttp://d.hatena.ne.jp/asakichy/20090124/1232793592

今日の日記も、興味深いものだと思います
ttp://d.hatena.ne.jp/asakichy/

最良の実装って、どんなものなんでしょうねえ。。
21：spinor＠かいはつしつ ◆5MOMRPyUPY：2011/10/29(土) 10:54:33 ID:2kRVFiUg0: 本スレに騙りが…OTL
後々のことを考えて、かいはつしつ用のトリップ付けます

luaずっと放っていたけど、そろそろ考えないといけないのか…
22：73：2011/10/29(土) 10:58:43 ID:PSzmAZOo0: 大丈夫、必ず一回はやられるから
もう皆分かってるから騒ぐ人＝自演　だから大丈夫よん
マップの話題は、週末でスレが荒れるから話題変えのためですし、
早くやれってことじゃないのでマイペースにやって良いと思います(・∀・)

旧スレなんかがそういう荒れた時用になってるので愚痴りたくなったらそっちへどうぞ！