さぎょうよう・ばっく・ぐらうんど・ねこ♡
09/12/5(土) [気だるさがぐるぐる廻る]
気分的に面倒なのでとりあえずメモ書き
通信処理に伴うラグ、そこから出る問題にまたしてもぶち当たった為、shibaiと組んでonMove内を改造した。
１：まだテスト段階
２：onMove内をswitch文で区分け
３：接続状況、ログイン状況、初期化、メイン などを条件に処理ステップを設けた
４：考えに穴がなければディレイ処理削除可能
まぁそんだけ。
09/10/13(火) [ほっとけーき爆弾]
はぁーいちゅーもーくヽ(´∀｀)ノ
今日知った真実を１つ。
サーバ関数を呼ぶ際のディレイ処理。これはとっても地雷でした＼(^o^)／＼(^o^)／＼(^o^)／
以後、使うのをやめて他の方法を考えること( ^ω^)･･･
進もうとすると戻される作業循環に絶望した！！／(^o^)＼
09/10/6(火) [涼しさと寒さの境界]
当ページの更新はここまで。って思っていたあなた。んなわけないだろぉ～(ﾟДﾟ)
今更だけどデカイ仕様変更。
当り判定の関係上、敵HP、プレイヤHP、ボスHP、ベースHPをサーバで管理することになった！
敵関連：生成→行動選択→移動ルート選択→行動選択(loop) をサーバで管理することになった！
≡≡≡c⌒っﾟДﾟ)っ ｽﾞｻｰ
休み明けに忘れてるといけないのでめもめも。
猫
- 敵時限生成：統合テスト←今ここ（バグ有）
- 行動選択：統合テスト
- 移動ルート選択：統合テスト
- 攻撃：統合テスト
- 当り判定：統合テスト
- ボスの作り直し or 整形：仕様決め
- ワールドサーバのポート取得：作成
兎
- ランキング取得の続き
- ログイン、ログアウトの不具合修正
- 新規垢生成の検査
- ルーム２の復元
- あとシラネ
09/09/10(木) [綺麗な夕焼け]
今後のサーバ
現段階でのプログラムと、近頃話し合った仕様から鑑みるに、
今後サーバで大きな動きは無いと思われます。
あるとしたらボスサーバで執り行う処理が増える程度。
なので当ページの更新もここまでな気がする。残念！
追記
と思ったけどランキングの保存範囲によってはランキングを管理するサーバを作ってもいいかもしれなくもないかもしれなかったりするかもしれないので、要検討。
忘れていたバグ報告
同ページ09/07/29の記事中「おかわり」で書いたバグの説明を今更ながらに書いておきます。
テーマは「処理の時間差」
クライアントの処理速度は基本的にフレーム単位で処理されますね。メチャ速いです。
これに対して、サーバを介した通信処理の処理速度と言うのはメチャ遅いです。
これは、サーバにデータを送り、その返事をサーバから受信するまでを１つの処理とする場合が多い為、通信速度などの影響をもろに受けてしまうからです。
クライアントプログラムの流れの中で、通信処理というのは送受信が即一連で実行されるわけではなく、送信にしても受信にしても、相手(自分)に届くまでに時間が掛かります。
掘り下げて説明すると、送信後即受信するわけではなく、厳密にはクライアントからデータ送信後サーバにデータが届くまで、サーバから返事(データ)がクライアントに返ってくるまでに時間があります。
その時間中もクライアントは送信コマンドの次の行から処理が継続して処理され、サーバからデータが返ってきた時点でクライアントの処理に割り込むという形でデータが受信されるのです。
流れで書くと、
クライアントの処理A
↓
データを送信
↓
クライアントの処理B ←送受信の間にコレが入る可能性が高い
↓ ←----------割り込んでデータを受信
クライアントの処理C
となります。
実際にあったクライアントの例を挙げると
ソース↓↓↓
SLogin(***,***);
ｉｆ(ログイン出来たか); 0＝失敗,1＝成功
上記ソースの実行順序↓↓↓
①ログイン認証(ID,PASS)を送信
↓
②ログイン出来たか判定
↓
③サーバからログイン認証の結果を受信
説明
②の時点ではログイン認証の結果がサーバから返って来ていません。
よって、送信したID,PASSが正しくても②のログイン判定で参照する値には認証の結果ではなく、初期値の0が入っている為ログイン失敗になります。＝シーン移行もなし
ちなみに、この時間差のバグを出すと実行結果はその時の回線速度に左右される為、運がいいと正常に通り、運が悪く少しでも通信にラグが出た瞬間乙ります。＝実行結果が実行する度に変わる。
対応策としては、送信した後、その結果が返ってくるまでクライアントの処理を進まないようにする処理(ループを廻す)等をして受信まで時間を稼ぎ、受信した段階でクライアントの処理を再開させる(ループを抜ける,等)ようにするのが現段階では妥当だと思われます。
09/07/29(水) [ピザとカントリーマァム]
サーバ分割完了 ～ 今後の予定
ちょろっと問題が残ってるけどなんとか分割が安定しまうま！
という訳で、今後は基本的に各種管理サーバを構築して行きますん
過去の開発記録で言う所の「データの保管・運用をするサーバ」です。
現段階で制作をしようとしているサーバは以下の2種類 ↓↓↓
castle_server : 管理サーバ
このサーバは嘘っぱち。
下記情報は各room_serverにて管理することになりました
[保持データ]
- 城の種類
- 各城の拠点座標
- 各城の武器庫座標
- 拠点HP
[処理]
boss_server : 管理サーバ
[保持データ]
[処理]
？が付いているのは不確定要素ですん。
上記に対してや、上記以外の事でなにか必要な事がある場合ﾄﾞｼﾄﾞｼ意見募集ちゅー☆
おかわり
クライアントを預かり、サーバを分割版に切り替えた際クライアントに問題が見つかりました。
詳細は後日ここに書くか、気が向いたら用紙に書いて提出します。
時間が掛る場合が予想されるので直接聞いてもらった方がいいかもめ。
部分的な書式ミスの類ではなく、通信を含めたプログラムを組む上での考え方の問題でした。
今回の問題を理解しないままクライアントを組まれると、この先ちょろっと心配なのでちゃんと理解しておいて下さいな。
問題解決に伴い、クライアントに多少の手を加えさせてもらいました。分割版を使用する場合早めの統合をお願いします。
09/07/03(金) [空気読めない飴]
形になり始めてるのでサーバ分割の進展を書いていくよ！
けど書くのが面倒なので端折っていくy（ry
現段階で実装が確認出来ているサーバは2つ
|
サーバ名 |
種別 |
| 1 |
world_server |
インタフェースサーバ |
| 2 |
room_server |
インタフェースサーバ |
上記サーバの役割と保持情報
実装予定の話だかんね！まだメインプログラムはこの構造になってないんだからね！！
world_server
[役割]
- ログイン判定(各インタフェースサーバにアクセスする場合必ずこれを通る)
- ログアウト判定(各インタフェースサーバからログアウトする場合必ず(ry )
保持情報
room_server
[役割]
保持情報
- メンバ情報(下記参照)
- ユーザオブジェクト
- ユーザオブジェクトに対応する番号(クライアントのマップキーと同期)
最近やっていることを簡単に言うと
どのサーバに入る場合も [world_server] にある唯一のログイン処理を通る仕様にする
これによって、ユーザのログイン情報を [world_server] にだけ保持させるようにする
もちろんログアウトも [world_server] にのみ存在し、どのサーバから落ちる場合もこれを通る
現段階での問題点
- room_serverからのログアウト処理が未実装
- ここに書くのは、とてつもなく見にくいと思う → 専用ページがあると良いかもわからんね
- メインプログラムと合わせるときに壮大な処理引っ越し作業が待っている
09/06/22(月) [飴のち曇]
お仕事
現段階でのプロトタイプに対する功勲値ゼロ。／(^o^)＼
立ち回りとしては
前半は、α版(企画通れば)以降に必要とされるかもしれなくｍ(ry な処理(サーバ分割)の
構想、実験とLager関数漁りを主としたソロ活動。
後半は、ワールド段階で詰みかけてた黒兎のサポとプレイ中に必要とされる処理の実装。
はよぉ仕様書あげてんかー(゜д゜)
活動方針
基本的には、サーバプログラムしか弄らない＋考えたくないです。
代わりに安定したサーバサービスを提供していくつもりです。(善処します)
メンバー全員の「12単位 = 卒業」が掛ってたり掛ってなかったりと、地味にシビアな見返りが
待っているので、細心の注意を払いながらサーバを実装していきたいです。
これまでの足跡
プロトタイプでは使わないので、載せるのやめようかと思ったけど書くことなくなるので記載＾ｗ＾
[サーバ分割に伴うあれこれ]
≪簡単な説明≫
サーバは２種類あるんぞよ
| 種類 |
通信相手 |
| クライアントと通信を行うサーバ |
クライアント＋各サーバ |
| データの保管・運用をするサーバ |
各サーバ |
上記２種類 ↑↑↑↑↑↑
２種類のサーバは、サーバに掛る負荷を考えて複数用意する。
それに伴い、各サーバ間でデータのやり取りを行う必要が出てきたりこなかったり。
前者の場合、ゲームの規模や仕様によって「町」「フィールド」「ダンジョン」などなど、
世界の違いを区切りにしたシーン毎に、管理するサーバを用意する。
後者の場合、ゲームの仕様に沿った「アイテム」「スキル」「敵」などなど、
各ユーザが共通で扱うデータ群毎に、管理するサーバを用意する。
≪分割実装に必要なもの≫
サーバ
・area_listファイル
・各サーバ(エリア)
・データ通信用の処理
クライアント
・ログアウト処理
・connect処理の任意呼び出し
・接続先の[IP:Poot]取得処理
おねだり
toクライアント班全員
仕様を固める＋仕様書の作成をもちっと早くしてくりゃれ！
それに伴ってサーバ班との話し合いが必要だったら細かいことでも話してもらえると、
お互いの相違も少なく混乱が起こりにくくなるのでお願いしますん。
※現に先日、話し合いが足りなかった事が原因で黒兎の作った処理が１つボツになりますたんぐ
toサーバ班(黒兎)
debug.logを出すな
toメンバー全員
リーダーが泣くからウィキ使ってあげて！
自分の携わっているパートに近いことしてるメンバーと、ちゃんと話し合いをすること。
自分のパートにしか手を出さないで他のパートを完璧に無視している人が多いように思える。
手が出せない程専門家したパート分けではないことと、プロトタイプ通らないと話にならないので
他のパートで困っている人がいたら出来る限りのサポートをして恩を売っておくこと！
最終更新：2009年12月05日 01:08
