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

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時にチャットに入ってもらえないでしょうか
無理そうでしたら夜改めてこちらにレスいたします
30：no.774さん：2012/08/20(月) 19:15:46 ID:JiDA.swoO: >>29
残念ながら、私はチャットには行けないです
(と言うか、夜参加できそうなのが9/1、7、13日くらいです)

色々と制約がありまして…
31：no.774さん：2012/08/20(月) 20:49:00 ID:vMCar1hIO: >>30
お疲れ様です。レスありがとうございます。
了解しました！
チャット無しで今日中にレスします。
遅くなるかもしれませんので、
明日にでもご確認ください。
よろしくお願いします。
32：no.774さん：2012/08/21(火) 07:22:56 ID:UdCQqM8g0: おはようございます。
自分も実装について語っていましたので、申し訳ないのですが、
バトルの仕様作成について気になっているところがあります。

１．携帯厨さんのアクティブタイムバトルシステムが共通の見解になっているか不明
２．携帯厨さんの実装方法から妥協点まで検討するのは早すぎないか
３．携帯厨さんが妥協点を提案した場合、誰がその決断をするのかが不明
４．実装開始までにやや時間がある

以上を踏まえた上での提案なのですが、
下記のプロセスで行なってはどうかと思います。

(一)．携帯厨さんの理想的なATB実装について見解をまとめて頂く（仕様作成）
(二)．これを叩き台に、プログラマと意見交換を行う（実装の検討）
(三)．以後、携帯厨は適宜プログラマと相談し、実装を把握して、妥協点を決め、それによる仕様への影響を修正して頂く（妥協点の決定）

あくまで提案です。

(一)の方法ですが、

(a) 携帯厨さんの理想的なATBであること
(b) ATBを全く知らない人がみてプログラムを可能な説明であること
(c) UIやエフェクトについては、携帯厨さんの理想を説明するのに必要な場合のみ、軽く触れる

に心がけて頂くと、不明なく共通の見解に出来るのではないかと思いました。

ざっくりとしたイメージですが、
・戦闘開始時どのように始まるのか（キャラの登場イメージや、ATBの初期の値等々）
・開始後、どのようにコマンドが発生するのか（ATBの増加のしかたは何よってきまるか等々）
・コマンドが発生すると何が出来るか（キャラをとばす、隊列チェンジ、コマンドの行数等々、コマンド選択中におこりうること等）
・コマンドを入力すると、どのような行動が起こるか（攻撃はいつ始まるか、ステータスへの影響、ダメージ発生のタイミングと、ダメージの数字がどのように飛び出すか等）
・各種状態変化はどのタイミングで発生し、いつ終わるか
・戦闘終了の条件
といった感じです。

基本の流れを解説した後、特殊な状況を説明するなど、方法は色々あるかと思いますが、
(b)を重視してまとめて頂けると、後に混乱なく実装の検討が出来るのでは無いかと思います。

提案は以上になります。
元が既にあるFFのATBであることと、プログラマの名無しさんがATB実装を出来るか未定であること等もありますので、
こちらまとめをして頂いても労力に見合わない可能性もあります。
また既に進めていただいてる検討に水を指してしまうというのもあります。
ですが、明確な見解となり、プログラマ名無し氏との実装の検討に用いられ、開発誰もが参照できる資料を作ることは有意義だと思います。

ご検討よろしくお願いします。
33：携帯厨：2012/08/24(金) 08:36:48 ID:UGNdKDbEO: >>32
えーと、とりあえず自分の基本的なスタンスから

①私が考えられるのはコマンド入力が完了してからダメージが反映されるまでの一連の流れ、及び技の効果をプログラム的にどう実装するかのイメージである
(表示系を考えられるだけの脳味噌が無い)
②可能な限り、プログラム処理中に管理が面倒にならないようにしたい
(モンスターデータの作成はツールでも作れば楽になると思っている)
③コマンド選択は、メニュー画面のアイテムや魔法の選択使用を拡張すれば実装できると言う甘い考えを持っている
④この方法で組めと言う指示ではなく、こうすれば楽じゃない？っていう提案のつもり
(実際に組む方がやりたい手法があったら、それで全然構わない)

船頭が多くて船が山登り始めないように、権限は最弱でいいのです
34：no.774さん：2012/08/24(金) 09:25:47 ID:tYxo2vMYO: >>33
返信ありがとうございます
今、まとまったレスがしづらいのですが、
僕の書き方が悪くて、少し誤解があるように思います。

実装方法に関してはプログラマに一任で良いと思っています。
ただ、実装の結果出来上がるものについて、理想系を明確にしてもらうことをお願いしたかったのです。
それが>>31の(一)の仕様作成の意味合いです。ここには実装の方法は含まれません。

その先のプロセスですが、携帯厨さんならばプログラマがどのような実装をするかを理解し、ときにはアシストしつつも、
プログラマが実装出来なかった場合に、(一)の仕様変更について決断と対応をしていただけるのではないかと思ったのです。

>>31の(一)の仕様とは、プログラマがどんなものを作らなくてはいけないのかをまずはっきりさせよう、ということです。

分かりにくくて本当にすみません。
また、理解していただけてた上での、返信でしたら本当にごめんなさい。
その時はまたレスします。
35：no.774さん：2012/08/24(金) 09:42:09 ID:tYxo2vMYO: 文だけでは伝わりにくいかと思いしたので、明日の朝までに簡単な資料を作らせていただきます。
それを踏まえてご検討お願いします。
36：no.774さん：2012/08/25(土) 12:51:36 ID:yMguvN5Y0: お疲れ様です。
すみません遅れました。

http://asobibox.velvet.jp/firstfantasy/data/work/BattleSpecification.pdf
とりあえず
こちらに自分の考えるバトル仕様書のイメージをざっくりと書かせてもらいました。
形式はこうでなくてもいいですし、一覧性の悪さや足りない情報も多いと思います。
ですがこのような意味合いで、この先の

・開始後、どのようにコマンドが発生するのか（ATBの増加のしかたは何よってきまるか等々）
・コマンドが発生すると何が出来るか（キャラをとばす、隊列チェンジ、コマンドの行数等々、コマンド選択中におこりうること等）
・コマンドを入力すると、どのような行動が起こるか（攻撃はいつ始まるか、ステータスへの影響、ダメージ発生のタイミングと、ダメージの数字がどのように飛び出すか等）
・各種状態変化はどのタイミングで発生し、いつ終わるか
・戦闘終了の条件

を携帯厨さんに理想的なATBとしてまとめていただきたいのです。
必要であれば、チャットあるいはメールなどで、このpdfの作成に作ったxlsxファイルをお渡しします。

こういった資料がありますと、議論もしやすく、
プログラマの手が止まること、プロジェクトで情報が混乱すること、がなくなるのではないかと思います。

なお、本当はもう少しバトルの流れに入ってからをざっくり示したかったのですが、
戦闘開始までの、UI配置と情報を書いていましたら昼になってしまいましたので、アップさせて頂きます。
UIの配置は別に担当が必要かと思いますので、現状はわりあい適当でおｋです。

ご検討よろしくお願いします
今日、自分は10時にチャットにうかがいます。
37：携帯厨@PC：2012/08/26(日) 22:50:37 ID:9CmtcLa60: >>36
お疲れ様です。ＰＤＦ確認いたしました。
画面イメージと一緒になっているので見やすいです。

当面の私の作業内容ですが
①ＡＴＢの増加の仕方（数式含む）の検討
②ＡＴＢが溜まった後の、コマンド選択から効果反映までの一連の流れの検討
③状態変化の効果適応タイミングおよび状態解除タイミングの検討
④戦闘終了タイミングの検討
でよろしいですか？

作業を始める前に認識をあわせておきたいので・・・
38：no.774さん：2012/08/27(月) 07:42:11 ID:biwQbXBo0: >>37
返信ありがとうございます！

理想は、プログラマがアクティブタイムバトルシステムの実装を開始する際、
こういった資料に必要な情報が全て網羅されていることではないかと思います。
資料を元に、どう実装するか検討出来ると思います。

もし可能でしたら、検討と同時に直接資料を作成して頂けると助かります。
図は必須では無いと思います。

検討していただくことは(日)～(水)でおｋです。

他に自分が思いつくのは
「ATBゲージが溜まっていく段階や、プレイヤーのコマンド選択中、攻撃発動中に、モンスターのATBゲージがどうなっているか。モンスターの攻撃はどうなるか」
といったところでしょうか。

検討中に、何か疑問が出たり、詰まってしまったら、スレで話し合うという手もあります。
よろしくお願いします。
39：no.774さん：2012/08/27(月) 08:30:44 ID:7cHBB6EYO: では、パッと思い付く④をば

戦闘終了関連
・イベントの負け戦闘か否かを格納しているグローバル変数が存在する(以下、イベントフラグと呼ぶ)
・敵の総数、味方の総数を格納するグローバル変数が存在する(以外、総数と呼ぶ)
・｢戦闘不能｣の定義は別途状態異常にて検討を行う

総数の増加は下記のタイミングとする。
①魔法、アイテムで戦闘不能から復帰したとき
②増援が来たとき

総数の減少は下記のタイミングとする
①｢敵｣が逃走したとき
②戦闘不能になったとき
総数の増減は関数化し、ロックを行って複数動作しないようにする

戦闘終了は下記のタイミングとする
①｢総数｣が0になったとき
②時間制限タイマーが指定時間経過したとき

(リーダーを倒した時を含めるなら、敵にリーダーフラグを格納する必要あり)
40：携帯厨：2012/09/09(日) 20:29:34 ID:eqHuIZiIO: とりあえずATBの暫定案
数式なんかは全く考えてないです･･･
実現可能かも危うかったりする…

条件
①ATBバーの溜まる値(以下、上限値)は素早さによって決まる
②ATBバーの初期値は装備の重さで決まる
③初期値、上限値はATBバーに表さない
④ATBバーのプログラム内部での溜まる｢速さ｣は変わらない
(ヘイスト等の素早さUPは上限値の変化で反映させる)
⑤画面上のATBバーの｢長さ｣を変えない事により、｢ATBの溜まる速さの違い｣を演出する
⑥ATBが貯まったら、敵と味方で異なるコマンド選択処理を行う
41：携帯厨：2012/09/09(日) 21:05:41 ID:eqHuIZiIO: コマンド選択処理周り
魔法、アイテム選択関連は別途考える必要あり

条件
①ATBバーが貯まったら呼ばれる
②コマンド選択、防御、隊列チェンジ、スキップが可能
③コマンド選択中、アニメーション再生中にATBバーを進めるかは、別途考える
(とりあえず、設定ファイルを読み込んで選択可能にしておく)

処理
①ループ突入
②コマンド選択関数を呼び出す
③コマンド選択関数からTRUEが帰ってきたらループを抜ける

コマンド選択関数
①キャンセルを押したらFALSEを返す
②コマンドが選択されたらキューに書き込んでTRUEを返す
42：no.774さん：2012/09/09(日) 21:17:50 ID:eqHuIZiIO: 検討が必要な事

①アイテム、魔法等、別ウィンドウを表示する処理
②選択中に死んだ時
43：nanashi：2012/09/11(火) 08:07:12 ID:yKTFDJz60: 検討ありがとうございます！！

仕様書の段階では内部処理に関してあまり頭を悩まさないで頂けたらと思います。
青写真の方に重点を置いて頂きたく思います。

ルールについて、不明点として、
ATBバーがどのような速度で溜まるのか。
敵のATBバーの速度や開始時の進行度は何によって決まるのか。
コマンド選択の内容は何を参照して決まり、最大幾つあるのか。
防御とは、いつまで、どのようにステータスを変化させるのか。またステータス以外に何か変化があるのか。
隊列チェンジの効果はどこに現れるのか。
アクティブとウェイトがあるのでしたら、それぞれはどのタイミングで違うのか。

この辺についても触れていただけたらと思います。
こちら最終的にテキストファイルか何かにまとめていただけるでしょうか？
お手数多くてすみません。
44：携帯厨：2012/10/08(月) 23:23:04 ID:DJwaWha2O: 連休なのに休み無しとかナンテコッタイ

全く進められてない事を一応報告しときます

帰宅してからパソコン開く気力が無いのデス
45：no.774さん：2012/10/09(火) 12:35:12 ID:tRJhiplQO: >>44
ご報告ありがとうございます！
無理して急ぐ必要はないと思います
！
企画の性質上、忙しい時期は互いにフォローをいれ合うことが非常に大事だと思いますので、
何か頼みたいことがあるときには、気軽に本スレやこちらに投げてみたりしてもいいと思います。
46：spinor＠かいはつしつ ◆5MOMRPyUPY：2012/10/22(月) 21:58:04 ID:Hrrd6yTE0: ttp://www.kotaroh.jp/ff_battle/
虎さんが残したソースをコンパイルできるように、いじってる

とりあえず、いじったもの↓
ActionList.cpp、AtbGauge.cpp、CharacterObject.cpp、CSVString.cpp、Cursor.cpp、Drawable.cpp、DxExtend.cpp、Field.cpp、Flag.cpp、SysUtil.cpp
ActionList.hpp、AtbGauge.hpp、CharacterObject.hpp、CSVString.hpp、Cursor.hpp、Drawable.hpp、DxExtend.hpp、Field.hpp、Flag.hpp、SysUtil.hpp
BattleConst.hpp、DataConst.hpp、SystemConst.hpp

ちょっとずつ、見ていこうかな。。