Javaで作るスタンドアローンゲーム

1 ：名前は開発中のものです。：2012/12/27(木) 16:04:18.62 ID:rl+qGRHn.net

スレタイはアプレットとの対比的な意味と考えてください。
Javaでのゲーム開発は賛否ありますが、国外では割と盛んになってきているように思います。
裏を返せば日本語だけでは情報が得辛い状況であり、寂しく開発してる人が多いのでは・・・。

関連スレ
JAVAアプリでゲーム
http://toro.2ch.net/test/read.cgi/gamedev/1033926010/


参考になりそうなサイト
・どのイメージタイプを使うべき？
http://weblogs.java.net/blog/chet/archive/2004/08/toolkitbuffered.html
・弱点と言われる？ベクタグラフィックス関連の改善
http://docs.oracle.com/javase/1.5.0/docs/guide/2d/flags.html
・大量のソースコードを公開して下さっている国内サイト
http://aidiary.hatenablog.com/entry/20040918/1251373370
・Java 2D games tutorial
http://zetcode.com/tutorials/javagamestutorial/
・出入りが最も盛んな？フォーラム
http://www.java-gaming.org/index.php
・スプライトシートの切り方等（国内）
http://sky.geocities.jp/kmaedam/java2/java2.htm

動画
3D Game Programming tutorial
・http://www.youtube.com/watch?v=iH1xpfOBN6M

351 ：名前は開発中のものです。：2014/11/21(金) 22:58:54.97 ID:wDfQVO6/.net

一気に飛躍しすぎ
まずはチャットを作ってみては？

FWについては知らん
少なくとも有名なものは無い

352 ：名前は開発中のものです。：2014/11/22(土) 00:18:10.87 ID:1kMHRznH.net

いくつかのサンプルを参考にチャットは作成しましたが、TCP通信のストリームを用いての文字列データだけのやり取りに留まっています。
画像を含めたインスタンスをサーバクライアント間でやり取りをしようとObjectOutput（input）Streamを利用するとブロッキングが発生してしまい、
別スレッドで起動する必要が出てくる上、今のところ画像データのやり取りはできていません。
UDP通信の送受信も試しましたが、今度は文字列データすらやり取りができなくなりました。
ノンブロッキング方式となるjava.nioパッケージもいくつかサンプルに沿って作ってみましたが、こちらもうまく行くのは文字列データのみで、
インスタンスの送受信はできていない上、何回か繰り返し処理をしているうちに何故かブロッキングが発生しないはずのメソッドでブロッキングされます。

使い方がよくないのは分かるのですがコードも煩雑になり手に負えなくなってきたので、通信周りの処理はオンラインゲームでは極当たり前のものだし、
フレームワークで存在しているかもしれないと思い探したものの見つからず、何か情報がないかと質問した次第です。

少なくとも有名どころにはないというのは大変残念。
Webアプリケーションのフレームワークならいくつもあるのに、通信あたりのとりわけマルチキャストに対応している物となると情報がない。

353 ：名前は開発中のものです。：2014/11/22(土) 05:43:04.14 ID:YsbIPryz.net

自分も同じような段階なので非常に興味があります
僕の場合は通信にはプロトコルを定めて4バイト以下でやり取りしているので、オブジェクトの送受信は今ちょっと調べただけですが……

ハッキリとは分かりませんが、ObjectOutputStream自体がブロッキングするioなんじゃないでしょうか？

調べてみたところ以下の実装が綺麗な気がします
http://stackoverflow.com/questions/5862971/java-readobject-with-nio
ByteArrayOutputStreamでラップしてデータの長さを調べて、さらにByteBufferでラップして先頭に長さを埋め込んでおきます

受け取る側ではまず先頭の長さ情報（4バイト）を読み込みます
続いて長さ分確保したbufferに本体を読み込み、あとは逆順にObjectInputStreamに落とし込みます

僕も簡単なフレームワークがあったらなあとも思いますが、お互い頑張りましょう

354 ：名前は開発中のものです。：2014/11/22(土) 13:31:16.69 ID:fUGuXT+m.net

通信用スレッド作ってブロッキングでやれば簡単だと思うよ
ノンブロッキング化なんて後からやればいいじゃない

355 ：名前は開発中のものです。：2014/11/22(土) 16:49:26.43 ID:GtITkLZ+.net

TCPではなくUDPで通信するのは俺もわからんし興味はある

データを受け取った側が一々受け取り成功したことを発信側に返信していたら
遅いTCPと実質同じになってしまうとか、注意点ふぁありそうな気がするけど
この辺は言語問わず情報がなさすぎて困る

356 ：名前は開発中のものです。：2014/11/22(土) 23:47:22.91 ID:fUGuXT+m.net

UDPの主な問題点は、パケットの到着が保証されない(途中で消えることがある)、順序が保証されない(前後が入れ替わることがある)の2点
どうにかこれに対処しないといけないが、だからといってこれを完全に保証するのなら、素直にTCPを使った方がいいわけで、
UDPを使うなら、パケットが消えたり入れ替わったりすることを前提に、最初からそれを受け入れる方針で設計しないと意味が薄い
一部重要な情報だけ到着確認や再送信など手厚い保証を作り込むという選択肢もあるが、TCPと併用し情報の重要度によって送信し分けるという選択肢もある

俺が作ったときは、通常はTCPを使い、性能的な懸念のある一部の情報だけUDPで送るようにした
念のため、UDPがちゃんと届くか送信テストを行い(返事はTCPで貰う)、だめだったときは全部TCPで動くようにした
特定のメッセージをUDPで送るかTCPで送るかはbooleanの引数1個で簡単に変更できた

357 ：名前は開発中のものです。：2014/11/23(日) 00:38:44.67 ID:UddT0/lz.net

>>353
　提示されたソースを参照しながら色々と試しております。
　とりあえずシンプルチャットの文字列のマルチキャストはできましたが、インスタンスのやり取りはまだうまく行っていません。

　ObjectOutputStreamについては仰るとおり、ブロッキングが発生するストリームです。
　ブロッキングを回避するためにマルチスレッドにして、受信したメッセージとインスタンスをプールして一元的に処理しようとして・・・
などとやっているうちにデッドロックが発生して頭を抱えておりました。

　Webアプリケーションフレームワークでもそうであるように、通信部分はほぼ共通の処理だろうし、
C/S型MOGの実装とて大きな違いがあるとは思えないのですが、ないものですかね・・・

　一応、Jogreとか言うゲームエンジンがC/S型を想定したものらしいのですが、使い方がまるで判らず
オープンソースだからせめてどこか参考にできないかと見てみましたが私の頭では理解できませんでした。

>>354
　ゲームの根幹となるシステムはサーバ側で実装しようと考えており、その際にクライアントの通信待ちでブロックされてしまうと処理が進まなくなってしまうので、初めからノンブロッキングで行くつもりです。
　前述の通りマルチスレッド化の段階でうまく行かなくなってしまいました。

>>355
　通信方式には特にこだわっているわけではないのですが、今後内輪で一人複数キャラ起動で20〜100程の同時接続を想定しており、
そうなると今後はUDPでないとまずいのかな、などと漠然と考えておりますが、実装が楽なはずのTCPですら躓いている状態です。

358 ：名前は開発中のものです。：2014/11/23(日) 02:19:06.05 ID:Y/h3FQGO.net

ブロッキングの場合は通信相手1人ごとに受信用スレッド1個と送信用スレッド1個を作って、それに通信処理を全部まかせるのがいい
相手側に何があってもブロックするのはそこだけで済む
何か送信したいときは、その相手用の送信キューに情報を詰め込んで、送信スレッドに送信してもらう
受信の方はそのまま受信スレッド上で処理してもいいが、スレッド間の同期が心配なら、受信した情報をメインスレッドの処理キューに積んでメインスレッドに処理してもらってもいい
もちろん各キュー自身は同期しなければならないが、LinkedBlockingQueueでも使っとけば心配なかろう
欠点は通信相手が増えすぎるとスレッドが増えすぎることだが、まぁ100くらいは大丈夫じゃない？

ノンブロッキングの場合は一箇所で全ソケットの送受信の面倒を見ることになる
基本的には Selector#select を回し続け、個々のソケットがそれぞれ受信可能になっていれば受信し送信可能になっていれば送信するわけだが、
受信したいときに受信したい量が受信できるとは限らないし、送信したいときに送信したい量が送信できるとも限らないので、
ブロックさせずに1スレッドですべてを回すためには送受信共にバッファ管理が必要になる
相手に何か送信したいときは、その相手用の送信バッファにデータを詰め込んでselectのループに戻り、
ソケットが送信可能な状態になったときに送信できる量ずつ送信する(そしてまたselectのループに戻る)
受信の方も、必要な量のデータが受信バッファに溜まるまでselectのループを回しておき、
じゅうぶん溜まったら受信バッファから必要量のデータを取り出して処理する感じ？
通信相手が増えてもスレッド数を抑えられるのが利点だが、実装は面倒い

359 ：名前は開発中のものです。：2014/11/23(日) 08:51:36.48 ID:2oDwsjHs.net

Java信者がまだ生き残っていて嬉しい

360 ：348：2014/11/24(月) 01:33:12.16 ID:sj/Z1D1w.net

今日一日がんばってはみたがやはり実装できず。
シンプルチャットは動いたものの、画像を含めたバイナリデータのやり取りはできておらず、
何故か353で提示していただいたコード部分でOutOfMemoryErrorが発生する始末。
使わなくなった瞬間に明示的にnullを入れてみたりはしたものの、全く解決せずで、
相変わらず手に負えない感じがあります。

今度はブロッキングのマルチスレッドを試してみようとは思いますが、以前この方法を取った際、
キューの中に受け取ったメッセージを格納しておき、メインスレッドで順番に処理する、
というようなコードを書いてみたところ、キューへのアクセスで何故かデッドロックが発生して
動作しなくなってしまったこともあり、うまく行くようにできるか心配です。
また、なんだか最終的に数千人規模の運営にも耐えられるようなもの（MMOみたいなものか）
みたいな要望（若干語弊がありますが）もあり、スレッドの数とか心配ですが。