OpenSangokushi commit ML
sango****@lists*****
2011年 2月 28日 (月) 22:34:43 JST
Google Mobile/Open Romance of the Three Kingdoms"GoogleAndroid"
ForkRevision: 500
http://sourceforge.jp/projects/sangokushi/svn/view?view=rev&revision=500
Author: hryksbt
Date: 2011-02-28 22:34:42 +0900 (Mon, 28 Feb 2011)
Log Message:
-----------
移動と攻撃の仕様について確認
Added Paths:
-----------
trunk/IRC_ChatLog/20110227_Skype.txt
Added: trunk/IRC_ChatLog/20110227_Skype.txt
===================================================================
--- trunk/IRC_ChatLog/20110227_Skype.txt (rev 0)
+++ trunk/IRC_ChatLog/20110227_Skype.txt 2011-02-28 13:34:42 UTC (rev 500)
@@ -0,0 +1,400 @@
+[2011/02/27 23:16:48] 裕之: こんばんはー＾＾
+[2011/02/27 23:17:19] narunaru: こんばんわー^^おひさしぶりですー
+[2011/02/27 23:17:37] 裕之: おひさです－
+[2011/02/27 23:17:50] *** 裕之がcommands.ppt,...を送信しました ***
+[2011/02/27 23:18:04] 裕之: まだつめ切れてないですけど、
+[2011/02/27 23:18:24] 裕之: doiさんとこんな感じのを作ってます
+[2011/02/27 23:18:57] narunaru: お、そうなんですねー。中身見てみますー^^結局通信はどうなったんですか？
+[2011/02/27 23:19:22] 裕之: doiさん方式がいい気がします
+[2011/02/27 23:19:44] narunaru: では、ポーリングですね^^
+[2011/02/27 23:20:09] 裕之: udpはない方がよさそうですね
+[2011/02/27 23:20:32] narunaru: そうなんですねー。ちなみになぜですか？
+[2011/02/27 23:21:19] narunaru: 固定IPじゃないからですか？
+[2011/02/27 23:22:33] 裕之: どちらかというと、位置情報を伝えるようなUDPの使い方が、返ってパフォーマンスに響くのかと思いました。
+[2011/02/27 23:23:05] 裕之: なので、ソケットを使用するにしても、TCPで、移動先を教えて、
+[2011/02/27 23:23:21] 裕之: 移動事態の処理はクライアントで行うか、
+[2011/02/27 23:23:47] 裕之: サーバがHttpで待ち受けして、全て処理をサーバで行うか
+[2011/02/27 23:23:55] 裕之: このどちらかかと思うんですけど、
+[2011/02/27 23:24:11] 裕之: 開発効率を考えれば後者ではないかな、と思います
+[2011/02/27 23:24:15] 裕之: 違いますかね？？？
+[2011/02/27 23:26:49] narunaru: TCPでいくのは全然良いと思うのですが、判断理由がよく分からなかったので、そこを教えて頂きたいです。なぜUDPで位置情報を伝えるような使い方のほうがパフォーマンスが悪くなるのでしょうか？
+[2011/02/27 23:27:07] 裕之: 通信頻度ですね
+[2011/02/27 23:27:08] narunaru: この辺りのイメージがつかめませんでした。
+[2011/02/27 23:27:34] narunaru: 頻度？
+[2011/02/27 23:27:37] 裕之: パケットが落ちてもいいような使い方をする場合、
+[2011/02/27 23:27:45] 裕之: つまりUDPですけど、
+[2011/02/27 23:27:48] narunaru: はい
+[2011/02/27 23:28:17] 裕之: この場合は、パケットが落ちてもいい分、沢山通信を送信するそうです
+[2011/02/27 23:28:25] 裕之: サーバはそれでいいですけど、
+[2011/02/27 23:28:45] 裕之: それを受けるクライアントは、つまりずーーーっと通信を受け続けてることになるので、
+[2011/02/27 23:28:58] 裕之: それがパフォーマンスに影響するのではないかと思いました。
+[2011/02/27 23:29:33] narunaru: なるほど、確かに一理ありますね。ですが、別な考え方も出来ます。あくまで一例なので参考程度に聞いて下さい。
+[2011/02/27 23:29:39] 裕之: ぜひぜひ
+[2011/02/27 23:33:34] *** 裕之がcommands.ppt,...を送信しました ***
+[2011/02/27 23:33:49] 裕之: 最終ページに1行追加しました。
+[2011/02/27 23:34:08] narunaru: まず、前提として色々な計算処理をサーバで行う場合のケースで話をします。サーバ側で計算等を行う場合、クライアント⇒サーバへは確実に情報を届けなくてはならないため、信頼性を加味してTCPで通信したほうが良いと思います。そしてサーバ⇒クライアントの通信がUDPで、たとえ、パケットが上手く伝わらなくも矛盾が発生するのは一クライアント端末のみです。しかも計算処理はサーバ側で行われているため、サーバ内での矛盾は発生しなくなります。そして次のUDP通知が届いた際にはきちんと結果が反映されるので、あまり問題は無いきがします。いわゆるユーザはらぐったとしか感じないのではないかと思います。
+[2011/02/27 23:34:59] 裕之: TCPの再送機構に任せた方がいいと言うのはどうでしょうか？
+[2011/02/27 23:35:56] 裕之: それと、
+[2011/02/27 23:36:10] narunaru: ユーザ数が増えるとTCPは再送機構などがある分、一つのクライアントにデータを通信する処理が非常に重くなると懸念されます。これはユーザ数が増えた場合に致命的になると私は考えてました。
+[2011/02/27 23:37:19] 裕之: 通信が途切れたとき、
+[2011/02/27 23:38:09] 裕之: サーバのHttpソケットのみの構成の場合、クライアントの方が、通信の制御を行っているはずなので、
+[2011/02/27 23:38:47] 裕之: MobileIPのような仕組みも不要になり、校正がシンプルで開発が早い
+[2011/02/27 23:39:04] 裕之: 私が考えたのはこんなところです
+[2011/02/27 23:39:29] narunaru: あ、HTTPプロトコルを使用する前提なんですね。それなら了解です。そもそもUDPは使えないと思うので。
+[2011/02/27 23:40:18] 裕之: Androidでは、Httpとソケットの両方がサポートされてて、HttpClientの標準ライブラリが使えるんですよね
+[2011/02/27 23:40:55] narunaru: はい、今の三国志はHTTPXXXXっていうクラスを使ってますねー
+[2011/02/27 23:41:04] 裕之: そです さすが
+[2011/02/27 23:42:23] narunaru: では通信はTCPでHTTPプロトコルということでおおむね決定ですね
+[2011/02/27 23:42:43] 裕之: あとは、ポーリング間隔で、多人数になったときの処理の重さを調整でしょうか
+[2011/02/27 23:42:52] 裕之: doiさん案なんですけど、
+[2011/02/27 23:43:05] 裕之: たとえば移動中に敵に遭遇した場合、
+[2011/02/27 23:43:16] 裕之: どちらかの攻撃があったとして、
+[2011/02/27 23:43:33] 裕之: そのダメージ数の結果はすぐには出さずに、
+[2011/02/27 23:44:40] 裕之: ぼこぼこと煙を立てたりなんかした後に、ダメージ（＝攻撃による兵力の現象）の結果表示をするとか
+[2011/02/27 23:45:08] 裕之: それからこれは私の考えですが、
+[2011/02/27 23:45:40] 裕之: 人数が多くてどうしようもなくなったときに、通信方式を一新する
+[2011/02/27 23:46:01] 裕之: それまでは、開発の軽量な方式でまずはスタートするのがいいのかなと思いました
+[2011/02/27 23:48:00] narunaru: 煙の案は良いと思います。ただ一つ疑問があって、すぐに結果を反映しない場合に、結果を反映させるタイミングはいつになるのでしょうか
+[2011/02/27 23:48:32] 裕之: いつがいいでしょうかねえ
+[2011/02/27 23:48:51] 裕之: まず、サーバから情報をゲットして、
+[2011/02/27 23:49:13] 裕之: ん
+[2011/02/27 23:49:15] 裕之: 違うか
+[2011/02/27 23:49:36] narunaru: はい、サーバから攻撃された情報をゲットしないと、まず煙がだせません。
+[2011/02/27 23:49:58] narunaru: そこから、どのタイミングで結果を反映させるのかが、疑問です。
+[2011/02/27 23:50:18] 裕之: ポーリングなので、
+[2011/02/27 23:50:32] 裕之: そのとき得た瞬間の情報を反映させることになりますよね
+[2011/02/27 23:51:24] 裕之: なので、クライアントで結果を表示してる頃には、サーバ上の情報はもっと更新されてる
+[2011/02/27 23:51:53] narunaru: はい
+[2011/02/27 23:52:13] 裕之: ちと、doiさんと話してた内容を見てますのでおまちをー
+[2011/02/27 23:52:20] narunaru: 了解ですー
+[2011/02/27 23:53:54] 裕之: お待たせです
+[2011/02/27 23:54:53] 裕之: 攻撃を仕掛けた側が、すぐに結果表示することは出来ないので、その間を煙でごまかすという作戦ですね
+[2011/02/27 23:55:27] 裕之: ぼこぼこの煙の間に、攻撃対象が攻撃の射程範囲外に移動してしまっていた場合は、
+[2011/02/27 23:55:34] 裕之: 攻撃失敗となります
+[2011/02/27 23:57:06] narunaru: あー、もしかして攻撃する際のサーバへ送るHTTPリクエストの応答に結果はのせない方針ですか？つまり、結果は全てポーリングしているソケットで受信するということでしょうか？
+[2011/02/27 23:57:37] 裕之: そうゆうイメージだと思いますよ
+[2011/02/27 23:57:45] narunaru: 了解です。
+[2011/02/27 23:58:31] 裕之: 結果の受信と、自分の行動の送信も全てサーバのHttpソケットに対して、クライアントから問い合わせる形ですね
+[0:00:15] narunaru: 自分の行動の送信を問い合わせるという考え方が良くわからなかったです。
+[0:00:46] 裕之: あ、普通にHｔｔｐで送信することです
+[0:02:21] narunaru: あ、了解です。まだ決まってないのかもしれませんが、一応確認です。クライアント側のHTTP用のソケットはポーリングでデータを受信するものと、自分の行動の送信用のHTTP用のソケットの2種類をもつイメージであってますか？
+[0:02:57] narunaru: それとも一種類で両方やるのでしょうか？
+[0:03:30] 裕之: どちらかというとdoiさんのアイデアなので、多分と言うところまでしか言えないのですが、2種類持つほうだと思います
+[0:04:19] narunaru: 了解ですー
+[0:07:14] narunaru: マスの概念なくなったんですか？
+[0:07:24] 裕之: そのほうがいいのかなと
+[0:08:05] 裕之: マス目があるほうが、当たり判定が難しそう、と言うことだそうです
+[0:08:37] narunaru: うーん、どうなんでしょう。マスが無い場合、どこを当たり判定にするのか自分は不明です。
+[0:09:13] 裕之: 移動の直線と直線がクロスするところが当たりになるんでしょうね
+[0:10:14] narunaru: プレイヤーとプレイヤーの当たり判定ですか？それって無いんじゃなかったでしたっけ？
+[0:10:29] 裕之: 無い？？？
+[0:10:41] 裕之: あーーー
+[0:10:45] 裕之: そうか
+[0:10:45] narunaru: はい、プレイヤー同士が交差する場合、すり抜けるとおもってましたが。。。
+[0:11:45] 裕之: 将来的には実装する設計はしておきたい、と言うところです
+[0:12:48] narunaru: 了解です。でもマスが無い場合のほうが難しい気もしますけど。。。どっちなんでしょうねー。
+[0:13:04] 裕之: narunaruさんはアルゴリズムマニアですよね
+[0:13:36] 裕之: 2つの点が時間をかけて直線を描くときに、
+[0:14:04] 裕之: 点同士がある一定の距離以下になった場合、辺りとする
+[0:14:11] 裕之: 当たりとする
+[0:14:31] 裕之: おそらくこんなプログラムになるんじゃないかと思いますけど、
+[0:14:45] 裕之: マスがあるとどうなんでしょう
+[0:15:18] 裕之: X1Y1から、X3Y7に移動すると決めたときに、
+[0:15:23] narunaru: マスで考えた場合に、難しいのは多分横に3縦に1とか
+[0:15:28] 裕之: どのマスを通るのか
+[0:15:28] 裕之: そうですよね
+[0:15:35] 裕之: 多分同じ事を
+[0:17:15] narunaru: はい、同じことを考えてるんだと思います。これは一応自分の中ではある程度せりできていて、斜めに移動する際にきれいにセルに入らない場合は一番パーセンテージの多いマスに居ることにして、そこから当たり判定をするのがいいのかと思ってました。
+[0:17:36] 裕之: それでも全然いいと思います
+[0:18:22] 裕之: どちらが作りやすいかと言うところと、どちらが処理が軽いか、ですよね
+[0:19:16] 裕之: それと、どちらが見た目がかっこいいか
+[0:19:29] narunaru: そうですねー。作りやすいのはマスに置き換えたほうがやりやすい気がします。マスの概念をなくしても結局は1ドット単位のマスなので。
+[0:19:42] narunaru: あー、見た目はマスが細かいほうがかっこいいかもしれないですねー
+[0:19:53] narunaru: いわゆるマスなしに見えるほうが
+[0:20:23] 裕之: ドットの概念にはなってしまいますかねー
+[0:20:37] 裕之: 作り方次第なのかなと思ってたんですけど
+[0:21:18] narunaru: 当たり判定という計算をする上では、結局は自分がどこにいて、どことあたったかは、マスになると思います。
+[0:21:29] 裕之: そうですかー
+[0:22:42] narunaru: はい、現実世界でもGPSとかはマスというか緯度、経度みたいな情報であらわしていると思います。
+[0:23:02] 裕之: 2つの点が描く直線通しの最小公倍数みたいなやり方ではいかんですかねえ
+[0:23:47] 裕之: 若干言ってることが意味がわからないかもですが＾＾；
+[0:24:25] narunaru: 言いたいことは直線の角度に時間をかけて何秒後にあたるのか計算して出すっていう方法でしょうか？
+[0:24:55] 裕之: そうですね
+[0:25:18] narunaru: それもXがどこ、Yがどこていうのが決まってないと、角度が出ないと思います。
+[0:25:38] narunaru: 結局はマスなんじゃないかと思います。
+[0:25:44] 裕之: なるほど
+[0:26:05] 裕之: doiさんのアイデアを聞いてみたいですね
+[0:26:18] 裕之: 細かいマスになるんでしょうかねえ
+[0:26:36] 裕之: もしくは何か別の面白そうなアイデアがあるかもです
+[0:27:09] narunaru: そうですねー。じぶんはマスしか考えてなかったので、他の人は別なアプローチを思いついているのかもしれませんね。
+[0:27:37] 裕之: マスの大きさが1x1なら点になりますけど
+[0:28:45] 裕之: プレイヤーのマップチップが48x48だとして、
+[0:29:31] 裕之: 必ずしもプレイヤーのチップと、計算上のマスのサイズは一致しないと言うことかもしれませんね
+[0:30:19] 裕之: そうであれば、
+[0:30:41] 裕之: 48x48よりも細かく計算した方がよりリアルですねー
+[0:30:58] narunaru: そうですねー。ただそれだとめんどくさいだけのような気がします^^;結局はプレイヤー用のマスとマップ用のマスを両方持たないといけないので。
+[0:31:36] 裕之: でもその方がかっこいいですよ
+[0:32:05] 裕之: マスの概念は無い方がいい←気になりますねー
+[0:32:14] narunaru: 確かにそうですが、それならプレイヤー同士の当たり判定だけではなく、攻撃する際もそうしたほうがいい気がします。
+[0:33:11] 裕之: もちろんですね
+[0:33:29] 裕之: マップ上の見た目も、滑らかに
+[0:33:48] 裕之: ぬるぬると、マップ上を移動して欲しいものです
+[0:34:09] 裕之: 攻撃も微妙な角度から
+[0:34:15] 裕之: 角度も距離も
+[0:35:01] narunaru: はい、多分リーダが求めてるあたり判定は格闘ゲームとかシューティングゲームレベルの細かい当たり判定ってことですよね？
+[0:35:10] 裕之: まああ
+[0:35:27] 裕之: そこまでこまかーくはなくてもいいと思いますけどね
+[0:37:11] 裕之: たとえば48のプレイヤーのチップに対して、マップは16とか
+[0:37:35] 裕之: それだけでも、だいぶ違いそうな気がします
+[0:37:41] 裕之: 24でも
+[0:37:59] 裕之: 全然余裕なら8とか4とか
+[0:39:00] narunaru: ん？すいません、話がよく分からなくなりました^^;余裕なら8とか4っていうのはなんでしょうか？
+[0:39:24] 裕之: 判定の単位と言いますか
+[0:39:52] 裕之: また、移動における座標の制度
+[0:39:54] 裕之: 精度
+[0:40:11] 裕之: わかります？？
+[0:40:14] narunaru: 大きいほうが細かいであってます？
+[0:40:32] 裕之: ちいさいほうが細かい
+[0:40:33] 裕之: です
+[0:40:42] 裕之: 48がプレイヤーで、
+[0:41:02] 裕之: 計算処理上は
+[0:41:17] 裕之: 例えば先ほどの16ッで言うならば
+[0:41:44] 裕之: 16x16が9個、48x48の中にいる
+[0:42:03] 裕之: 絵で描きましょうか
+[0:42:27] narunaru: はい、よく分からなかったのでお願いします^^;
+[0:45:51] *** 裕之がああああ.xls,...を送信しました ***
+[0:47:13] 裕之: Excle上の1マスは16x16だと思ってください
+[0:47:56] 裕之: 縦横3つずつなので、48x48になりますよね
+[0:48:14] 裕之: で、隣の座標と言うのは、16であって
+[0:48:19] 裕之: 48ではない
+[0:48:54] 裕之: 余計わからなくなりましたかね＾＾；
+[0:48:55] narunaru: 黄色は何を表しているのでしょうか？
+[0:49:11] 裕之: 黄色がプレイヤーです
+[0:49:29] narunaru: エクセルの大きい四角がマスですか？
+[0:49:45] 裕之: 赤の矢印に沿って時間が経過していきます
+[0:49:50] narunaru: はい
+[0:50:14] 裕之: Excleのセル1つが16x16です
+[0:50:31] narunaru: ↑ドットということですよね？
+[0:50:35] 裕之: さっき説明してた16です
+[0:50:41] 裕之: ドットかピクセルか
+[0:50:47] narunaru: はい、了解です。
+[0:51:02] 裕之: なので数値が細かいと精度も細かくなる
+[0:51:41] narunaru: 了解です。逆に考えてました。自分は分母のことをいってるのかと思ってたんですが、分子だったんですね。
+[0:51:54] 裕之: です
+[0:53:46] narunaru: 上記だと辺り判定はやはり難しくないですかね？結局は左上、右上、右下、左下のどの辺とあたったか判定しなくてはいけない気がするんですが。
+[0:55:12] narunaru: ↑前提としてプレイヤーの大きさを含めて考えた場合ですが
+[0:55:41] 裕之: 難しいですかね
+[0:56:24] narunaru: はい、難しい気がします。なので話を最初に戻すと簡単にするためにマスを無くすって言う方法に対する結論にはならないきがします。
+[0:56:25] 裕之: プレーヤーの中心の座標で考えるというのであれば、
+[0:56:32] 裕之: 同じなのかなと思いました
+[0:57:14] narunaru: 点と四角形では違いますよー
+[0:57:26] 裕之: プレイヤーの見た目上は48x48ですけど、
+[0:57:51] 裕之: 辺り判定の計算上は真ん中の16x16で
+[0:58:06] 裕之: これなら、いけませんかねー？
+[0:58:50] narunaru: それならいけますが、それって見た目当たってるけど、全然当たらないってことになりますが、それでもOKってことでしょうか？
+[0:59:42] 裕之: そこまでアクションなゲームでも無いのかなと思ってます
+[1:00:08] narunaru: 話を元に戻してしますようですが、それならマス目でいいのではないでしょうか？
+[1:00:43] 裕之: なので、doiさんがどのようなアイデアで、そのように仰っていたか、これがポイントですね
+[1:01:05] narunaru: そうですねー
+[1:02:04] 裕之: マス目でいくにしても、今私が提示したような案が取り入れられると、多少はリアルになるのかなと
+[1:02:22] 裕之: 思うところであります
+[1:03:01] narunaru: はい、リアルにはなると思います。ただ実装を簡単にするためっていうのが理由だったので、最初の理由にはなっていないと思いました。
+[1:03:29] 裕之: あくまでもバランスの話なので、
+[1:04:01] 裕之: それがどーんと膨らむような要素であれば、今の実装からは除外しないといけないと思いますけど
+[1:04:19] 裕之: たいしたこと無いものであれば
+[1:04:31] 裕之: 盛り込みたいですね
+[1:05:21] narunaru: そうですねー、リアルさを追求したほうがゲームバランスが良くなるなら、実装が難しくなっても盛り込むっていうのは賛成です
+[1:05:56] 裕之: 実装が簡単で、リアルさを表現できるものは今の段階で盛り込むです
+[1:06:27] 裕之: むずいのは後回しー＾＾
+[1:06:55] narunaru: では簡単に盛り込む方法をどいさんが検討してくれていることに期待しましょう
+[1:07:07] 裕之: そして段々と趣味の世界に…
+[1:07:20] 裕之: ですね
+[1:07:41] narunaru: はい、自分には簡単に盛り込む方法が思いつかないので^^;
+[1:07:57] 裕之: ちなみにこれとは逆の話で、
+[1:08:08] 裕之: 本流の設計開発とは別に、
+[1:08:29] 裕之: こうゆう細かい機能の開発を進めることも出来るので、
+[1:08:59] 裕之: それはそれで
+[1:09:36] 裕之: 動いてくれると、早いペースで完成度を上げていくことができますね
+[1:10:20] 裕之: なぜなら、今のところ、上位設計は3人で、という事になりましたですが、メンバーは50人くらいですからね
+[1:11:11] 裕之: 47人が浮いてる状態なので
+[1:12:17] 裕之: 本流の増員と、細かいところの開発は本流の進みを見て検討したいところです
+[1:13:50] narunaru: すいません、結論が読み取れませんでした^^;;47人も開発に参加させれたらいいなっていう話でしょうか？
+[1:14:38] 裕之: みなさん一度は開発に参加したいと思って、集まって頂いてますからね
+[1:15:26] 裕之: 何もしないで知らぬうちに進んでいってしまうよりは、何かお願いできないことが無いかを考えてます
+[1:16:12] narunaru: お、いいことですね^^是非皆さんにも何らかの意見や機能開発に参加していただきたいですねー
+[1:17:11] 裕之: いずれは、一人歩きするようにしたいですね
+[1:18:03] narunaru: 一人歩きってどうやったら出来るんでしょうね。よく考えてみると難しいですよね。
+[1:18:33] 裕之: 開発に興味を持ってもらうことが最初に必要だと思います
+[1:18:58] 裕之: それと、コミットされているコードが理解しやすいこともそうですけど、
+[1:20:03] 裕之: こうゆう機能があったらもっと面白いのに！とおもっている開発者がいて、コードをコミットしてもらう。というのを延々と繰り返していけば
+[1:20:21] 裕之: 一人歩きしていると言えると思います
+[1:23:09] narunaru: うーん、そうですねー確かにそれは一人歩きですね。なんとなく自分の中で納得できました^^
+[1:23:37] 裕之: まま、今すぐの話ではありませんから＾＾
+[1:24:03] narunaru: はい、将来的にはそうなるといいですね^^
+[1:24:53] 裕之: もちろん、何でもかんでも、組み込むわけには行かないでしょうから、
+[1:25:24] 裕之: そのときは、然るべきメンバーで、こんなコードが送られてきたんだけどどうしましょ、的な検討をして、
+[1:25:58] 裕之: 本流にコミットするかどうかを決めたりすすと思うんですけど、これも今の話しで無いのでまたそのときが来たら、宜しくお願いします
+[1:28:46] narunaru: はい、自分も上記のような現象の場合、入れるか入れないのかを判断してしまうと勝手に機能が盛り込まれている(一人歩き)という状態では無いのかと考えていたのですが、仕様を入れるかどうか判断するのは必ずしもひろゆきさんでは無いので、ひろゆきさんから見たら一人歩きしてるように見えるのかなと自分で自分を納得させました^^;
+[1:30:05] narunaru: すいません、単純に一人歩きの定義で悩んでいただけです^^;忘れてください^^;
+[1:30:31] 裕之: ま、そのときが来たらの話ですからね＾＾
+[1:30:37] narunaru: そうですねー
+[1:30:53] 裕之: ではじかんもじかんですからそろそろZZしましょうかー
+[1:31:04] narunaru: はい、おやすみなさいー
+[1:31:11] 裕之: お疲れ様でしたー
+[1:31:19] 裕之: おやすみなさいー ((ninja))
+[1:31:32] narunaru: どいさんから良い当たり判定の方法聞けたら教えてくださいー
+[1:31:36] narunaru: ではおやすみなさいー
+[1:31:42] 裕之: 教えてくださいーー
+[1:41:32] doi: こんばんは。遅かったですね。
+[1:42:10] 裕之: お、
+[1:42:14] 裕之: こんばんは！
+[1:42:25] 裕之: 今布団にもぐってたトコでした＾＾；
+[1:42:45] doi: ログ見てないですが、辺り判定が問題でした？
+[1:42:52] 裕之: そうですね
+[1:43:25] 裕之: マス目の概念をなくして考えるのは、実際どうやるんだろう、というところで
+[1:43:40] 裕之: どうやるんでしょうねーって色々話してたトコです
+[1:43:53] doi: マス目が嫌だった理由は粒度の問題です。
+[1:44:32] doi: narunaruさんがちょっと触れていたように重複領域が大きいマス目にっていうのもありだと思うんですが、カクカクした移動になったり、
+[1:44:45] doi: しばらく動かなくなったりするのかなと思っています。
+[1:45:25] doi: 仮にサーバ側では連続的な座標系で把握していたとしても、表示が離散的だと、
+[1:45:49] doi: ユーザからみた場合に同じ状況でも内部状態が違うというのは混乱を招くのではないかというのがその理由でうｓ。
+[1:46:04] 裕之: ということは、プレイヤーの見た目上よりも、計算処理上は、もっと細かい粒度のマス目があるということですね？
+[1:46:17] doi: そうですね。
+[1:46:34] 裕之: スッキリです
+[1:46:36] 裕之: あとは、
+[1:47:14] 裕之: サーバと通信する際は、自分の行動の送信と、他のプレイヤーの行動の受信は、
+[1:47:38] 裕之: 日とるの通信で行うのか、分けるのか、
+[1:47:49] 裕之: この辺りも、narunaruさんが気にしてました
+[1:47:59] 裕之: 日とる⇒一つ
+[1:49:14] doi: その辺は全体像が決まってからとは思っていますが、
+[1:49:24] doi: 僕の中でイメージしているものとしては、
+[1:50:42] doi: コマンドを送信するだけの単発のリクエストと、状況を通知する継続的なコネクションとをもつことを想定していました。
+[1:51:08] doi: コマンドの方は、座標（x,y)に移動というものを、ユーザが指定した時点で発行します。
+[1:52:02] doi: その上で、継続的なコネクションから、定期的に状況を取得していて、自分は今は(a,b)にいるとか、Ｘtoiu
+[1:52:15] doi: というユーザは(c,d)にいるという情報を受け取ります。
+[1:52:28] 裕之: 状況を通知する、と言うのは、状況を受け取る、つまり、クライアントからサーバに状況を取りにいくという意味ですよね？
+[1:53:07] doi: 継続的なコネクションを張ってしまえば、どちらでも一緒だと思っています。
+[1:53:41] doi: PULL型の方が端末がビジーで一回だけ、処理をはしょるとかできていいかなとは思ってますが。
+[1:53:54] 裕之: おー、そうなると、Httpだとしても、ちょっとしたテクニックを使うんですよね？
+[1:54:07] doi: ＨＴＴＰは考えてませんでした。
+[1:54:16] 裕之: おー
+[1:54:49] doi: そして、欲を言えば、位置だけでなく、何をしようとしているかも取得して、それはクライアントでもう少し細かい時間で表示を変更して、定期的な通知でずれた分を補正とうい感じにできたら
+[1:54:54] doi: いいかなという風に考えています。
+[1:55:47] 裕之: なるほど。そうなると、クラサバの両方でソケットを持つことになりますか？
+[1:56:32] doi: ソケットとは、サーバソケットを指していますか？
+[1:57:11] 裕之: Http以外の通信となると、Androidでは他にサポートされるものが無いと思ってましたので
+[1:57:40] doi: と言いますと？
+[1:58:04] 裕之: 要するに、データを受け取るには、その仕組みを自作するしかないのかなと思ってました
+[1:58:12] 裕之: クライアントで、です
+[1:58:33] doi: HTTPライブラリはあるけど、他のプロトコルのライブラリはないということですか？
+[1:58:41] 裕之: そうです
+[1:58:52] 裕之: そんなことを本で読んだ気がします
+[1:59:43] doi: どういう言い方をすればいいか分かりませんが、
+[1:59:58] 裕之: Androidでは、Httpとソケットによる通信がサポートされてます的な。
+[2:00:04] doi: ServerSocketクラスは使いませんが、Socketクラスは使いますってことで回答になっています？
+[2:00:23] doi: もちろん、HTTPに乗っけてもいいですが。
+[2:00:40] 裕之: ServerSocketとSocketの違いは良くわかってないです
+[2:00:58] doi: 待ち受けソケットか、そうでないかという感じでしょうか。
+[2:01:41] 裕之: 一度コネクションを張れば、クライアント側はSocketクラスでOKと言うことでいいでしょうか？
+[2:02:49] 裕之: 一番初めはサーバのServerSocketに対してコネクションを張りにいくという意味です
+[2:03:33] doi: サーバ側のサーバソケットに対してコネクションを張るために、Javaの実装ではSocketクラスを使います。
+[2:03:39] doi: という感じでしょうか。
+[2:03:58] 裕之: たぶんOKだと思います
+[2:04:04] doi: 概念と実装との言葉が入り混じってて紛らわしいですが。
+[2:04:29] doi: 僕がカタカナで書いているのは概念の方だと思ってください。
+[2:04:53] 裕之: [2:03] doi:
+
+<<< Javaの実装ではSocketクラスこれはクライアント側ですね？
+[2:05:00] doi: です。
+[2:05:11] 裕之: OKです
+[2:06:45] 裕之: それと、私がアレンジしたdoiさんの資料ですが、いかがでしょうか？
+[2:07:02] doi: きちんと書いて頂きありがとうございます。
+[2:07:26] 裕之: 攻撃にせよ、移動にせよ、予め共通して迎撃と回避を選択した上で
+[2:08:05] 裕之: 攻撃ないしは移動を行うといった形で、さらに操作がシンプルになるのではないかと思ってます
+[2:08:24] doi: その方が分かりやすいと思います。
+[2:08:45] 裕之: あ、攻撃の場合は、迎撃も回避も無くて、攻撃のみですね
+[2:09:06] 裕之: でも、目標の敵に近づく前に、他の敵と接触する可能性もあるので、
+[2:09:11] doi: ただ、迎撃は本当にいいのかってのは気になったりしてました。
+[2:09:18] 裕之: その場合を考慮して、迎撃と回避
+[2:09:20] 裕之: を
+[2:09:34] doi: １対１ならいいんですが、
+[2:09:34] 裕之: 迎撃はまずいでしょうか。
+[2:09:53] doi: 囲まれたりしたときに、
+[2:10:25] doi: ある敵に対して、迎撃を実行中に、別から攻撃されそうになって、迎撃をしてとかとなると、何もできなくなるかなと。
+[2:10:52] 裕之: その状態になってから回避に切り替えるとか
+[2:10:57] 裕之: 遅いですかねえ
+[2:11:13] doi: それはそれで、ありだとは思うんですけどね。
+[2:11:19] 裕之: だれか助けに来てくれるかもしれないし
+[2:11:26] doi: 囲まれて、右往左往しているわけですから。
+[2:11:45] 裕之: ほかの味方の狙っていた敵が、自分を囲んでるかもしれないし
+[2:12:29] doi: 単に僕はコマンド自体が切り替わるコマンドの仕様にはしていなかっただけなので、あるコマンドは特定の状況下で違うコマンドに切り替わるというのはありだと思います。
+[2:13:01] 裕之: 戦況を見て的確な判断を下すのが、指揮官の役割ですからねｗ
+[2:13:16] doi: 自動的にコマンドを切り替える方がいいのか、
+[2:13:29] doi: 状況をみてユーザにコマンドを切り替えさせるのがいいのか、
+[2:13:38] 裕之: そこまでは自動化しなくてもいんじゃないですかねえ
+[2:13:42] doi: それは考える余地がありそうですね。
+[2:14:18] 裕之: 自動化すると、囮作戦とか出来なくなりそうです
+[2:14:34] 裕之: 適当に突っ込んで、誘い出して、退却するみたいな
+[2:15:22] 裕之: そして戻る（つまり移動先変更）した先には、見方が大勢いるという作戦を出来る当にしたいじゃないですかｗ
+[2:15:56] 裕之: 出来る当⇒出来る様
+[2:16:04] doi: そうですねぇ。
+[2:16:17] 裕之: ちなみに、迎撃のときは、
+[2:16:41] doi: そいうことをやるなら、敵ユニットも見えないで、斥候とかで確認できるとかにしないとバレバレな気がしますけども。
+[2:16:47] 裕之: 敵が引けば、また目的地に向かって移動を再開すると思ってマスが、
+[2:16:59] 裕之: これはdoiさんも同じ考えですか？
+[2:17:13] doi: あ、僕は迎撃って概念じゃないんです。
+[2:17:19] doi: あくまで、突撃なのでｗ
+[2:17:32] 裕之: 突っ込むんですねえｗ
+[2:17:49] doi: 犠牲を払って確率的でも最短経路をとる移動、確実な経路をとる移動
+[2:17:50] 裕之: 相手がつぶれるまでですか＾＾；
+[2:17:54] doi: その2種類で考えてました。
+[2:18:20] 裕之: 兵が多少へってすり抜けるわけですね
+[2:18:26] doi: どちらかというと、確率的に相手の陣を突き抜けるイメージでした。
+[2:19:12] doi: 趙雲の単騎駆けのイメージですｗ
+[2:20:09] 裕之: そうゆう意味では、私の考える回避は、突撃に近いかもですね
+[2:20:26] 裕之: 攻撃を受けながら、進路を目指しますから
+[2:20:47] doi: で、僕が迂回と表現したのは攻撃範囲という意味ではないです。
+[2:20:56] 裕之: これに対して迎撃は売られたけんかは買いますよモードです
+[2:21:04] doi: 相手ユニットにも大きさを持たせていいのかなと思ってたので。
+[2:21:28] 裕之: これはなかなかまた検討どころですね
+[2:21:36] 裕之: 大きい＝兵力が多いので
+[2:21:42] doi: 将来的に陣形なんかも考えるとそういうこともあるかなと。
+[2:21:49] doi: 突破されやすいけど、大きいとか。
+[2:21:59] doi: 突破されにくいけど、小さいとか。
+[2:22:09] doi: 攻撃力強いけど、打たれ弱いとか。
+[2:22:12] 裕之: つまり、プレイヤー通しに力の差がある時点でのスタートでしょうかね
+[2:23:00] 裕之: 大きさと兵力がイコールでなければ、あまり問題に葉ならなそうです
+[2:24:06] doi: http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Hachijin.svg
+[2:24:25] doi: 図は決して同じ兵力ではないですが。
+[2:25:06] doi: 長蛇の陣形を敵が敷いていれば、迂回は簡単とか。
+[2:25:39] doi: 自分が鏑矢の陣形だと、突撃の確立が上がるとか、そいういうのをイメージしていました。
+[2:26:02] 裕之: 大きさというよりは形ですね
+[2:26:49] doi: ここまでこだわる方がいいのか分かりませんが。
+[2:27:11] doi: それに、もちろん兵力によっても大きさは変わるべきでしょうしね。
+[2:27:41] 裕之: 一つのプレイヤーで陣を形成するのか、複数のプレイヤー通しで陣を形成するのか
+[2:27:58] 裕之: 後者の方は新しいですよね
+[2:28:28] 裕之: 話し合って、雁行で行こうぜみたいにｗ
+[2:28:48] 裕之: そうなると
+[2:29:05] doi: 一人で複数の小隊を持つっていう考え方もありますよ。
+[2:29:16] doi: という風に話していると発散して、方向が定まらないのでなんですが。
+[2:29:34] 裕之: ですねｗ
+[2:32:42] doi: ともあれ、この辺の動きは他の人の話しも聞きたいですね。
+[2:32:59] 裕之: では一旦、いまの資料の状態でコミットしてみましょうか
+[2:33:37] doi: ん～。どうなんでしょう。あくまで案に過ぎないという気もしつつ、そうしないと、すすまないような気もしつつなのですが。
+[2:34:06] 裕之: まず進めておきたいですね
+[2:34:48] 裕之: 私のイメージも案に過ぎないと思ってましたけど、
+[2:35:16] 裕之: 具体化できてきてますし、
+[2:35:22] 裕之: tpつ劇ですよ
+[2:35:27] 裕之: 突撃
+[2:35:28] doi: その辺りはおまかしてしまっていいです？
+[2:35:47] 裕之: それはもうもちろんです＾＾
+[2:35:59] doi: 資料も細かく作って頂きましたし。
+[2:36:26] 裕之: 次のステップについてまた考えましょう
+[2:37:56] 裕之: 今日はこの辺でｚｚｚさせて頂きますね
+[2:38:05] doi: はい。
+[2:38:16] doi: 呼びとめてしまいすみません。
+[2:38:17] 裕之: お疲れ様でした！
+[2:38:21] 裕之: いえいえ
+[2:38:23] doi: お疲れ様でした。
+[2:38:26] doi: おやすみなさい。
+[2:38:34] 裕之: おやすみなさいー
\ No newline at end of file
