実装物（プログラム）スレ - 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: 大丈夫、必ず一回はやられるから
もう皆分かってるから騒ぐ人＝自演　だから大丈夫よん
マップの話題は、週末でスレが荒れるから話題変えのためですし、
早くやれってことじゃないのでマイペースにやって良いと思います(・∀・)

旧スレなんかがそういう荒れた時用になってるので愚痴りたくなったらそっちへどうぞ！
23：no.774さん：2011/10/29(土) 12:52:31 ID:bxlduSA.O: >>19
むむ・・・
責務的な意味合いでcontrollerが分かれてるのか。なんかまたsequenceがナニモノかよく分からなくなってきた。

現状sequenceが実行(update)と出力(draw_frame)を提供してて、
入力(handle_input)だけがcontrollerに行ってるように見えてた。
なんで、てっきりsequenceはデカいモデル的な何かかと・・・

だから、input_handlerがなくなるならメインループからは
sequenceのhandle_input()、update()、draw_frame()を呼んで、
controllerがある方が作りやすいなら
sequence->handle_input()の中からcontroller->handle_input()を
呼び出す形の方が綺麗には見える。

それか、描画もcontrollerと同じように
get_drawable()->draw_frame()みたいにするか、かな？

＞最良の実装

変更容易性とか拡張性とかの（検討時間も含めた）
コストとのバランスはあんまり勘が働かない・・・
技巧的に凝り出すと際限ないし。
24：携帯厨：2012/08/05(日) 00:15:49 ID:Hh/vzUy2O: お久しぶりです
とりあえずの仕様
情報を構造体にしてます
必要物及び処理流れ
・技IDと、行動者、ターゲットの構造体を渡すキュー
・キューから情報をリアルタイムで引っこ抜いて技の処理に渡すselect文
・各技の処理を記述した関数
・成功判定関数
・ダメージ処理関数

の順番でやれば一応拡張しやすいかなぁ、と
技の処理の関数を新規追加すれば良いですし

めんどくさいもの
・スリップダメージ
死亡判定が煩雑になる
・敵の蘇生
ターゲッティングの記述が面倒
・｢時間経過｣のステータス変化
ATBが溜まってる最中に変化されると判定に影響が出る
・かばうの処理
一旦全体のアビリティの処理の優先順位を決める必要あり
・耐性、オートアビリティの扱い
フラグ格納先が大量にできて管理が煩雑。戦闘中に装備切り替えて耐性変わると悲しくなってくる

あまり考えれてないので、お粗末ですが参考までに…

各種アビリティの特徴まとめやら処理なんかは時間大分かかりそうデス
というかリアルが…
25：no.774さん：2012/08/12(日) 21:39:13 ID:2LRMnO5E0: >>24
遅レスですが、GJです！

てっきり流れとか簡単な仕様と思いましたが、かなりがっつり踏み込んでいて感動です。
ここでの議論を活発化させつつ、仕様をまとめられるかもしれませんね。
最終的にはやはりまとめて、管理して頂く人が必要に思いますが。

キューを使うの納得しました。キューを使えば動的な変化も対応できるような気がします。
毎フレームのメインループ処理ですが、

＊数フレームに渡る更新が必要なものをタスクとし、
　ダメージ処理関数は成功判定を即座に行なってHP減少、死亡フラグ、ダメージのポップタスクの生成をするとして、

0.条件を満たしていれば戦闘を終了。

1.ポーズ中であれば以下の処理を全て行わない

2.各キャラクターとモンスターを同一視して順次ATBやキャラクター演出等を更新
　　2.1.ここで、コマンド入力のタイミングであれば、コマンド入力キューの発行
　　2.2.モンスターの攻撃タイミングであれば、個体ごとの条件に合わせた攻撃構造体キューの発行
　　2.3.攻撃タスクが更新状態でない場合に、スリップダメージ、状態異常に関してダメージ処理関数を実行する

3.キューを取り出し、コマンドタスク、攻撃タスクを「４」の処理に登録
　　コマンド、攻撃、それぞれ、現在登録されて、更新中の同タスクがない場合、
　　かつ無効な条件を満たしていなければ登録。

4.登録された攻撃タスクとコマンドタスクの更新
　　コマンドタスクは攻撃が決定されたなら、攻撃構造体キューを登録して、タスクを終える。
　　攻撃タスクはアニメーション等を更新して、
　　直接ダメージが入るフレーム時に、ダメージ処理関数をターゲットの参照も引数にして実行する。

5.独立した描画処理（ダメージのポップとか、背景画面のスクロール）のフレーム更新

こんな感じにすればいいのかと思いました。
もちろん処理がそのまま描画プライオリティに反映される場合は別として。

・敵の蘇生、時間経過による変化。
携帯厨さんのいうキューの手法であれば、それほど複雑ではないように思います。
死亡したターゲットもプログラム上では、死亡フラグと不可視フラグがONになっているだけで、存在している扱いにすればいいと思います。
蘇生を攻撃タスクとして、復活アニメーションを終えた後、死亡フラグを削除してしまえば、次のキューは同じモンスター扱いで処理が出来ます。

全体で管理すべきことと、個別キャラ、モンスターで管理すべきことがどうなりそうなのかが気になります。
アビリティ等については
http://www31.atwiki.jp/fftsukurou/pages/96.html
に特殊処理の洗い出しもありますので、この実現性ですかね・・・。
26：携帯厨：2012/08/13(月) 17:44:02 ID:e.ET9km20: >>25
レスどーも
死亡ターゲットに関してですが、
「蘇生行動に限り死亡フラグと不可視フラグが立っているオブジェクトを選択可能」
って処理が面倒かなぁ、と思いまして

死亡しているモンスターを存在する扱いにすると、全体攻撃とか、
「乱れうち」的な対象をランダムに選択する行動に影響が出そうな気がするんですよね
ターゲットの不可視フラグと自分の行動が蘇生か否か判断して、
ターゲットをずらす処理でも組めば良いんでしょうけど…

時間経過に関する変化ですが、私の言う
「経過ターン」ではなくて「指定秒経過」だと思ってください
各状態ごとにタイマー回して、時間経過したら
割り込み処理起こして状態を変化させてやらないといけないので、
管理が「面倒くさい」かなぁと
（ＡＴＢ溜まった回数にすると、
ヘイスト状態には解除が早まるという弊害が起きますし）
27：携帯厨：2012/08/13(月) 18:04:51 ID:e.ET9km20: これだけじゃ何なんで、キャラの構造体が持つ情報一覧でも
構造体の中に番号が書いてある構造体があるイメージで

①丸裸の時のステータス格納構造体
装備の付け替えや技によるパラメーター増減の計算に使用、
戦闘中は編集不可
②戦闘時に使用するステータス構造体
字の通り、メニュー画面で表示されるステータスもこれ、
戦闘突入時やパラメーター増減時は毎回計算する
③状態異常構造体
現在の状態異常、毒とか。
解除行動を行わない限り無くならない
④時間経過系構造体
何をもって時間経過とするかが未定だが、
有効フラグと残り時間を格納、プロテスとか
⑤属性耐性
２倍、補正なし、無効、吸収の４パターンを各種属性にセット
⑥異常耐性
必中、補正なし、無効の３パターンを各状態異常にセット
⑦属性、状態異常攻撃
各属性、各状態異常に対してセット
戦闘中に装備で切り替わるなら、現在の装備している装備の効果を
なめ回して見る必要あり
⑧装備アビリティ
オートアビリティの発動条件を見る
何個装備可能かプログラムで制御しちゃいけない気がするので、
ここはList形式にしたほうが良いかも

⑧はアビリティを一旦分類して見る必要があるけど、
情報が膨大だからなかなか纏まらない…
28：携帯厨：2012/08/20(月) 08:34:49 ID:JiDA.swoO: とりま、今ここの考えに詰まってるから知恵plz

・特殊な防御、回避アビリティの重複(庇う＋守る＋白羽取り＋カウンター的な)
重複させて良いのかどうか。重複させると各アビリティ毎の処理を成功判定式とダメージ判定式に組み込む必要あり
(エフェクト出すからどのみち組まなきゃいけないかもだけど)
個人的には装備可能は一つにしたい(そうすると各アビリティ毎にフラグを用意する必要が無くなる)

・時間経過で消える効果
解除をターン制(と言うかATB貯まった回数、素早いと効果長く)にしたい、ヘイストとかスロウ時は有効ターンを上げ下げする
変にリアルタイム化すると、ウエイトモードの考慮とか、タイマー割り込みとか非常に面倒
29：no.774さん：2012/08/20(月) 12:48:10 ID:vMCar1hIO: >>28
お疲れ様です
検討を進めていただきありがとうございます
一つ、仕様のまとめと実装方法の検討が混在して議論が難しくなっているように思います。
この辺について少し話したいのですが、今日22時にチャットに入ってもらえないでしょうか
無理そうでしたら夜改めてこちらにレスいたします