Javaで作るスタンドアローンゲーム
Javaでのゲーム開発は賛否ありますが、国外では割と盛んになってきているように思います。
裏を返せば日本語だけでは情報が得辛い状況であり、寂しく開発してる人が多いのでは・・・。
関連スレ
JAVAアプリでゲーム
http://toro.2ch.sc/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
Java自体は好きだけど、こういう排他的な方向性は気に食わん。クソが
ガラケー向けに一杯出てるだろ。
クライアントがJREインストールさせる壁があるのと
アプレットの起動時にブラウザが固まるのがうざくて
どうせ敷居が高いならスタンドアロンで作るほうがいいかなと思ったり
OpenGL2DならSlickライブラリお勧めだよ
アプレットは目的が違って来るよね（ウェブで気軽に触って欲しいみたいな）
やはりソースコードもそういう方向に行っちゃうし、何せネットにあるアプレットのソースに酷いのが多いのは有名（古いのが多いのも理由）
学び始めた子がここに嵌まっちゃってる感がみてられん
「排他的」というのは被害妄想すぎるし、Swingのそれをわかってくると面白くなってくるというもの
アプレットに限らずだが未だにJFrame使わずFrame使ってたりJApplet使わずApplet使ってるのは不勉強だと思われても仕方が無い
人気無くなったのか知らんがJavaって2004年5年あたりで時が止まってる気さえする
とかいう俺もjre1.6から離れられないわけだが
JREは自動更新したりアプレットとか開くと更新を要求されるから1.7になってる。
swingではなくawtを使うのは1.6後期までOpenGLと相性悪かったからだろうね。
swingコンポーネント使うとOpenGLの速度潰すからボタンとか自作しろって
slickフォーラムに書いてあったが、もうOpenGL捨ててswingだけでなんか作ろうと思う。
（ちなみに俺のホームページは1年間あたり500円稼ぐのがやっとw）
何かいいゲームネタをもってるやついたら、俺と組もうぜ！ m6(・∀・)ﾋﾞｼｯ!
同じJava使いとして応援してます
組むのはプログラマがかぶるかなという気もしますが
ゲームネタの雑談するのは乗り気です
今のところ、とりあえず凸画像だけで作るRTSとか、ローグとか、
そんなゲームがいいかなと思ってます。
そこで質問なんですが、ダブルにするかトリプルにするかってどうやって決めればいいのでしょうか
まだ情報量の少ないFXの調べ物でつまづくとまずいから、swingでいくことにしよう
自分はいつもデフォのダブルバッファリングしか使ってないので何とも言えないが
欠点： プレイヤー入力から画面出力までに１フレーム遅延が発生する
利点： 処理落ち時に１フレーム分余裕がある
ググったらこんな感じでした
XULRunner とは意外な組み合わせ
と思ったらいまではJavaXPCOMで呼びだせるのか
時代は進んでるなあ
XULRunnerでweb広告を貼るわけだが、
同根するネイティブ(dll, so)が100MBくらいになる。
これをwindows限定ならば20MBぐらいで済む。
どうせゲームクライアントはwindowsだから
windows以外はバッサリ切り捨てる。
追尾ミサイルが100発ぐらい飛んできてスローモーションの中避けるのは
むしろ盛り上がる。画面が止まったまま当たり判定くらったら嫌なはずだ。
エフェクトなどが重要ではないリアルタイムSLGなんかでは
画面の更新を飛ばしてでもとにかくロジックを更新せねばいかん。
前者はダブルバッファ、後者はトリプルバッファが向いてそうだが、
迷うぐらいならとりあえずダブルバッファを選んだほうが無難だと思う。
ググるとデコレーションメールの画像？ ゲームに使えるん？
八方向のキャラグラ素材作ったら大変だろ？
だから例えばマップ上では簡素なアイコンとして凸絵を表示して、
マウスで駒を選択すると右上にキャラ名と正面向いたキャラ絵を表示するんだ。
それなら前向きの絵だけ用意すればゲームが作れる。
ttp://uploda.cc/img/img50e0368219f69.png
でもやりたいんです！！僕はＨＳＰでブロック崩し（アルカノイド）
ぐらいなら作ったことあります。
今のところ、オープニングまで作ったのですが、どなたか僕に
ＨＳＰの基礎からすべてを叩き込んでくれませんか？？
お願いします。
ゲ製板でゲームを製作してるやつはまずいないしな
この板にいるのはせいぜいこの程度の初心者ちゃん↓
【Eclipse】Android ゲームApp作成【初心者】
ttp://toro.2ch.sc/test/read.cgi/gamedev/1355211405/l50
vipゲ製スレもエロ画像貼って雑談してるだけ
ゲ製板にゲームを製作している人がいなくても無問題では？
不毛だと思うことをしていないのだからむしろ喜ばしいのでは？
雑談の中ですら批判専門家や乞食くんばかりでまともなやつが出て行ったのがゲ製板だろう。
個人的には javax.sound.midi で midi を
プログラムレベルで叩けるのを知ったのが自分の最近のヒット。
音はショボ目かもしれんがデフォの gervill シンセを鳴らして遊んでる
自動作曲とか興味ある人いるかな
それならsteinbergからSDK落としてきて素直にVST開発するのがいいが、これまた同志がいない
ファミコンゲームしか作る気ないし音はNSF一択
String var = "hello";
switch(var){ case "fuck" : break; }
知らなかった…
早速，自分のコードを書き直してみよう．
lwjglみたいなの使うか、SWTとawtを上手いこと使うのがいいね
ただswingはやはり気楽で便利だ
あんまり作り方を説明してる文書ってないよな
良く知らんけど、
Swingは描画の更新をイベントディスパッチのスレッドが行わないといけないから
OpenGL の速度が生かせないのかな？
はじめから OpenGL の描画に同期したコンポーネントとして設計すれば良さ気か
Swing を移植できたらすばらしいけど、根元の動作原理を良く分かってないからムズイ
VRAMに固定されてるテクスチャじゃないからじゃねーの？
http://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248211/
swingで974FPSも出てるぞ。
でも自分で試すと58FPSくらいしか出ないんだよな
どうやるんだろう
ディスプレイのリフレッシュレート調べろ。
>eclipseで-Dsun.java2d.opengl=trueを設定するにはどうすればいいんだぜ？
ググればすぐ分かる
こんなレベルで一個一個質問してたらゲームは遠いぞｗ
スプライトシートに特化したソフトが仮完成した
マップエディタを改良していきたい
エディタ側からイベント追加、フリーハンドでの当たり判定生成ができるよう改良する予定
$ java -Dsun.java2d.opengl=true ...
java.lang.InternalError
at jogamp.opengl.awt.Java2D.invokeWithOGLSharedContextCurrent(Java2D.java:345)
at jogamp.opengl.awt.Java2D.initFBOShareContext(Java2D.java:578)
at jogamp.opengl.awt.Java2D.getShareContext(Java2D.java:472)
at javax.media.opengl.awt.GLJPanel.<clinit>(GLJPanel.java:193)
Caused by: java.lang.NullPointerException
at jogamp.opengl.awt.AWTUtil.lockToolkit(AWTUtil.java:90)
at jogamp.opengl.awt.Java2D.invokeWithOGLSharedContextCurrent(Java2D.java:336)
... 3 more
Exception in thread "main"
ぐぐたけどわからんちん
http://uploda.cc/img/img50e58004f1dfb.png
ディスプレイには同期していないので６０以上でています
エラーを出していた部分をまるまるコメントアウト：
class GLPanel extends JPanel implements ... {
...
static {
// Force eager initialization of part of the Java2D class since
// if (Java2D.isOGLPipelineActive() && Java2D.isFBOEnabled()) {
// Java2D.getShareContext(GraphicsEnvironment.
// getLocalGraphicsEnvironment().
// getDefaultScreenDevice());
// }
}
}
こんなライブラリの内部をいじってコメントアウトしてしまって大丈夫かは知りません
というか、良く見たら背景のGradientPaintが表示できてない…
-Dsun.java2d.opengl=false の場合は
http://uploda.cc/img/img50e582e27afd5.png
やっぱコメントアウトしてる部分で初期化処理してるのかなあ
http://uploda.cc/img/img50e5927fb81f4.png
グラジエントが縞模様っぽいのは仕様か…？
有名所だと、
Ardor3D / cocos2d-x / Crystal Space / DimsensioneX Multiplayer Engine / EasyWay Game Engine
Env3D / Espresso3D / Golden T Game Engine / Irrlicht Engine / Jake2 / JGame
JMonkey Engine / Joge / JOGRE Engine / Nebula Device / Spring
だと思うんだけど
ref
( http://en.wikipedia.org/wiki/List_of_game_engines )
( http://content.gpwiki.org/index.php/Game_Engines )
やっぱし2dものなら、cocos2d-xとかで、頑張って３DするならArdor３Dまたは、Irrlicht Engineとかって感じ？？
あと何かお勧めのライブラリとかある？
いい加減寝るか―
スマホで作らない限りスマホにも使える系は面倒かなと。
あとSpringてDIのあれとは別物？
最新ゲーム機の出力に近づけたいならゴージャスなもの用意すべきだし
俺は物理演算をどうするかを判断基準にしている
割とその辺の数学が好きだったり、ファミコン時代の試行錯誤が体感できるからあまりライブラリは使わない
というか個人製作でリアルさ求め始めると血迷うのが見えている
public Player(int x, int y, int id) {
}
みたいな感じで自機を用意しました
idによって違うイメージがdrawされるようにしています
これを利用して自機だけでなく敵も作りたいのですがどうやってPlayerクラスを利用するのかわかりません
Player jiki = new Player(200, 200, JIKI);
Player teki = new Player(400, 100, TEKI);
のように二つ用意し、それぞれdrawすると、後に書いたtekiしか表示されなくて困っています
Playerを配列にしてもみたのですが、drawすると後に書いた敵しか表示されなかったです
オブジェクトは二つ生成されてもswingの描画はそうはいかないということですかね
public class Player {
public Player(int x, int y, int id) {
}
public void draw(Graphics g) {
g.drawImage(idの値によってイメージ切り替える処理);
}
}
これをJPanelを継承したクラスに自機と敵と言う形で二つインスタンス化したいです
JPanelを継承したクラスのコンストラクタでインスタンス化し、paintComponentでそれぞれdrawしています
思いつくところとしては
・画像データはちゃんと読み込まれているか
・描画位置が完全に画面の範囲外になって見えていないのでは
・画像が重なって下になった画像が見えていないのでは
→ 試しに JPanel の paintComponent で直に drawImage してみる
→ Player の draw(g) で drawImage の代わりに fillRectangle とかしてみる（setColorを忘れずに）
出来と言語は関係ねーぜ。
まぁ、考えかた次第だし何を求めているかだけどな。やっぱり、C++/Cで出来るのに、Javaでは出来ない事も多い。
それして、Windowsなら、似たように（場合によっては更に簡単に、）C#でもっと高クオリティのが作れる。
Javaは色々な機器で動かせるようにはできてるけど、ゲームでresponse早くして、高画質とかを求めると
それようにその機器向けにチューンナップが必要で、その点Microsoftはガチでやってるからそこにはまだまだ勝てない。
でも、一般的なゲーム（商用含む）でも、そこまでガチなものを作る事はないけどな。
HD+でfps60出すぐらいなら、ライブラリの呼び出し方一本で大抵済むし、
そして、その位の性能だったら今のPCなら Windows/Mac/Linux どれでもJavaで十分イケル。
というか、Pythonとかのもっと軽い言語でも、ライブラリを適時呼び出して上手いことやればいいだけなので、出来るしな。
大雑把な値として経験から、JavaでWindows Gameを作るのと比較すると、
C#（XNA）との差は軽いゲームで5％強遅く、重めでキツイ処理入れ出すと20％弱ぐらい遅くなる。
さらに、C++ でガチでやるのと比べると、1/3〜1/5ぐらいしか性能でない。
・ C++/C（GPU） >> C# ≧ Java > LL系
ただし、C++はガチでやり出すとメモリ管理も含め資源の調整とかGPU向けの細かい指定とかとか、
ただでさえ、開発期間と知識が求められる上に、コンパイル時間とか半端ない・・・・・・。
実際に比べるのは不可能だけど、少なめに見ても、開発時間は30倍は堅い。
やっぱし大手のガチProjectじゃないとできないし、結局それなら、普通にMiddleWareを買ってきた方が良い。
（Programmerは楽とは限らないがwww orz）
http://uploda.cc/img/img50e9176927843.png
それよりもSWTとSwing混ぜて使えるようにしてほしい
このぐらいのゲームなら簡単に作れそうだ
ttp://clovergames.3zoku.com/game.html
なんとなくわかるんだけど設計としては評価しづらいな。
XML形式だと入らないだろうし、Serializeしてバイナリで吐いても素材分巨大化する
midiはJDKに入ってるJavaSound、MP3はこのライブラリが使いやすそう。
ttp://www.javazoom.net/mp3spi/mp3spi.html
あとは.wavが使えるものがあれば十分なはず。
＞それよりもSWTとSwing混ぜて使えるようにしてほしい
謎杉。何がしたいの？
アクションにも対応できる骨格をまともに作ろうとするとawt要素が増えてくるよね
自分でレンダリングするならbufferstragegy使わないと損だし。
そしてSWT使うならダブルバッファリングするのは当然だ
何が言いたいって、awtはゲーム開発において偉大だということ。
これは低速GUIと呼ばれるSwingと対比してではない。
今更awtとかswtを直接使う人いないんじゃないの？
壁にめり込む前に修正してやるのか、とりあえず動いてみてめり込んでいたら修正するのかどっちがいいのでしょうか
前者の場合、
(壁までの距離)<(1フレームで動ける距離)のとき、壁との距離分だけ動かす かな？
こっちのほうが何だかカッコイイ気もするけど、何か自由度が下がりそうな気がするんですよね
ただ後者は楽だけど、めり込んだ瞬間にアクション起こされた時の対策を加えないといけないですよね
・全てのオブジェクトの移動前と移動後（予定）の座標を取得する
・当たり判定
・予定通り動かす or 衝突アクション
マウスでドラッグしながら塗るようなアプリ（マップエディタとか）だと
マウスの座標現在値だけでやると早くマウスを動かしたときに
ドラッグ間の線が途切れるんだよね。そんなときにもこのやり方が役に立つ。
どういうゲームを想定してるのか分からないけど，
俺が作ってる3D STGの場合，後者でやってるよ．
…次のフレームで本当に衝突するか分からないし．
俺の場合は，衝突判定オブジェクトは球とか単純な形状のみでやってて，
例えば移動球同士の場合は，相対距離（の二乗）を
時刻tを変数とした二次方程式で表して，それを解くような感じでやってる．
なので基本的には，すり抜けはおきない．はず．（バグってなければ）
その間はそれぞれ等速直線運動をしている，という前提でね．
移動は上下左右斜めも可能でピクセル単位です
また一つ質問なんですが、プレイヤーの当たり判定をするポイントってどこにするべきなのでしょうか
自分はプレイヤーの中央に判定点を取っているのですがいつもグチャグチャになります
当たり判定を円のような面積？で取る方法はやったことがないです。２Dでも使えますか？
点ではなくて面積で当たり判定を取る方法・・・
ブロックのサイズから面積を計算して、プレイヤーと重なった面積が○○以上になれば当たったことにする みたいなことですか？
人の形をしたものにはキャラグラの80%ぐらいの大きさにあたる
四角形で判定とればいいし、巨大なヘビとか曲がるレーザーなら
小さい四角の判定を鎖のように繋げて判定にすればいい。
って、言うか
今どんな判定してんの？
まさかブロックの座標を総当りで判定？
ブロックは奇数行・列に配置させてるので単純に、if(マス目%2 != 0)みたいな感じでやってます。
自分がやってる方法はいつもこんな感じです。
public int x, y; // プレイヤーの左上の点
private static final int S = 32; // プレイヤーの縦と横のサイズ
/**
* 判定点を返す。
* @return プレイヤーの判定点の座標
*/
private Point getPoint() {
return new Point(x+S/2, y+S/2);
}
移動の際int directionに方角を代入しているので後は
・動けるか否かのbooleanを返すメソッド if(direction==RIGHT && (getPoint.y)/S%2 != 0) （右へ移動するとき、奇数行であれば動けないの意味でfalseを返すみたいな。）
・修正が必要な領域に入ったか否かのbooleanを返すメソッド
・修正するメソッド
みたいな感じに細かく定義していってます。
ただ、if(マス目%2 != 0)のように定義しちゃうと、
プレイヤー：□、 ブロック：■とする
□
↓
■ ■
のように、少し左によった状態だけど判定的にはokなとき
■□ ■
のようになって、ここで右側にいけない（右の壁まで数ピクセル進めない）のって気持ち悪いと思うのです
こういう時だけ場合分けするにしても煩雑になってきますし、そもそもの当たり判定の方法がよくないのかなと思いまして質問しました。
仕様に合わせた最適な判定は知らんが（仕様が分からないし）
普通は中心じゃなく四隅を判定する
右移動中なら右上、右下だけとかの省略はできるが
で、四隅をプレイヤーサイズじゃなく判定サイズにする
ブロックがこんな感じに敷き詰められてると思っての回答になるが
■ ■ ■
■ ■ ■
■ ■ ■
奇数行だから横に動けないとするんじゃなく
奇数行で右に移動中なら右側の判定ｘ座標も奇数目になったら
めりこんだ座標分戻すってやる
斜め移動ならブロックのどの面に先に当たったかも必要になる
ちょっと前にTDぽいの作ったなぁ
四隅を判定するのが普通なのか？物凄くソースが汚くなりそうなんだが。
普通Rectangleのintersetsみたいなのを使うんじゃないの？
やってる事自体は変らないでしょ
升目と矩形の判定を中心一点だけではやらない
当たり判定クラスを作るだけだろ。
むしろ四隅を判定しないやり方ってありえないだろ。
ゲーム独自の判別する必要があるし、
既存クラスライブラリに全部やってもらおうというのは無理だよ。
んなことわかりきってる。だが可能な限りjreに依存するべきだと思うよ。
＞むしろ四隅を判定しないやり方ってありえないだろ。
全然ありえなくない。逆になぜ四隅を判定する必要があるか書いてごらんよ
なにより二次元における閉じた図形であれば必ず重心が一点のみ存在する訳で、これほど保守性の高い性質はない。
あと、
if(playerRectangle.intersects(blockRectangle) {
Rectangle intersection = (Rectangle) playerRectangle.createIntersection(blockRectangle);
...
...
}
で重なった矩形が取れるなんつーくっそ便利なモノ使わないと損だと思うよ。
四隅にこだわってる理由がよくわからんし、一応ここJavaスレだで。
的外れ。
＞なぜ四隅を判定する必要があるか書いてごらんよ
Rectangleを使うと四隅を判定しないのか？
>>82-83の話をしてるから、そこんとこ踏まえてね。
>>91が四隅を判定しているように見えるのか？
判定してるのは交差してるか否かだろうよ。
「だけど内部処理は・・」って？どっちが的外れなんだか。
プレイヤーとブロックの四隅を判定しているように見えるけど、何か違うのかな？
実装において物理エンジンでもRectangleでも
より原始的な方法(int x,y,w,h)でも好きにすればいい話。
１から１０まで書かないとわからないようだな。
ならなおさらBのRect使えよと言いたいが、設計の段階の話なら
＞より原始的な方法(int x,y,w,h)でも好きにすればいい話。
で納得。
マップチップを敷き詰めた状態でブロックがいちいち矩形座標持ってるとも思えないし
あと上下左右４方向の移動・当たり判定が理解できるまでななめ移動は考えない方がいい
int CHARA_X, CHARA_Y; // キャラピクセル座標
int CHARA_SIZE; // キャラサイズ（ＸＹ同サイズとして）
int CHARA_MOVE; // キャラ移動量（CHARA_SIZE < CHARA_MOVEだとすり抜ける）
int CHIP_SIZE; // マップチップサイズ（ＸＹ同サイズとして）
int MAP[][]; // マップ（０：移動可 １：移動不可）
private void moveChara() {
if (direction == RIGHT) {
CHARA_X += CHARA_MOVE;
while (MAP[CHARA_Y / CHIP_SIZE][(CHARA_X + CHARA_SIZE) / CHIP_SIZE] == 1) {
CHARA_X--;
}
}
}
単純なアプリなら単純に作ったほうが工数が少なくて楽。
保守性がどうとか初心者が背伸びして粋がってるとしか思えん。
「基本図形を描画するメソッドは使うな！」的な流れも確かにあったが、今は利用できるものは利用したほうが便利でシンプルに書けることに気づいてるじゃん。
Java2D使うのは初心者には無理だと思ってるならそれはバカにしすぎだと思う。
http://www.youtube.com/watch?v=Otl24e_nuyc
例えばこういうチュートリアルみてもビギナー向けの解説としてるけど？
100〜のスレッドの続きを読む
