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

**名前は開発中のものです。** · 2012/12/27(木) 16:04:18.62

スレタイはアプレットとの対比的な意味と考えてください。
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

**名前は開発中のものです。** · 2013/01/16(水) 10:43:20.41

普通、2Dだと四角か円で判定とるだろ。
人の形をしたものにはキャラグラの80%ぐらいの大きさにあたる
四角形で判定とればいいし、巨大なヘビとか曲がるレーザーなら
小さい四角の判定を鎖のように繋げて判定にすればいい。

**名前は開発中のものです。** · 2013/01/16(水) 12:12:30.09

ヒット判定のすりぬけ問題は前もって交点検出しないとだめよ。

**名前は開発中のものです。** · 2013/01/17(木) 17:15:05.18

>>77
って、言うか
今どんな判定してんの？
まさかブロックの座標を総当りで判定？

**名前は開発中のものです。** · 2013/01/17(木) 18:33:38.80

スクリーンショットとか上げてよ

**名前は開発中のものです。** · 2013/01/17(木) 22:57:41.07

>>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なとき

■□ ■
のようになって、ここで右側にいけない（右の壁まで数ピクセル進めない）のって気持ち悪いと思うのです
こういう時だけ場合分けするにしても煩雑になってきますし、そもそもの当たり判定の方法がよくないのかなと思いまして質問しました。

**名前は開発中のものです。** · 2013/01/18(金) 00:06:12.20

>>82
仕様に合わせた最適な判定は知らんが（仕様が分からないし）
普通は中心じゃなく四隅を判定する
右移動中なら右上、右下だけとかの省略はできるが
で、四隅をプレイヤーサイズじゃなく判定サイズにする

ブロックがこんな感じに敷き詰められてると思っての回答になるが
■　■　■

■　■　■

■　■　■

奇数行だから横に動けないとするんじゃなく
奇数行で右に移動中なら右側の判定ｘ座標も奇数目になったら
めりこんだ座標分戻すってやる

斜め移動ならブロックのどの面に先に当たったかも必要になる

**名前は開発中のものです。** · 2013/01/18(金) 02:20:15.70

お～こんなスレあったのか
ちょっと前にTDぽいの作ったなぁ

**名前は開発中のものです。** · 2013/01/18(金) 23:19:47.41

>>83
四隅を判定するのが普通なのか？物凄くソースが汚くなりそうなんだが。
普通Rectangleのintersetsみたいなのを使うんじゃないの？

**名前は開発中のものです。** · 2013/01/18(金) 23:22:12.80

訂正：intersectsね

**名前は開発中のものです。** · 2013/01/18(金) 23:46:53.86

Ｊａｖａは知らないからそう言う便利なのがあれば使えば良いけど
やってる事自体は変らないでしょ
升目と矩形の判定を中心一点だけではやらない

**名前は開発中のものです。** · 2013/01/18(金) 23:52:51.60

>>85
当たり判定クラスを作るだけだろ。
むしろ四隅を判定しないやり方ってありえないだろ。

**名前は開発中のものです。** · 2013/01/18(金) 23:57:49.81

ゲーム（マリオ）だと踏んだとか横から当たったとか
ゲーム独自の判別する必要があるし、
既存クラスライブラリに全部やってもらおうというのは無理だよ。

**名前は開発中のものです。** · 2013/01/19(土) 00:50:01.89

＞既存クラスライブラリに全部やってもらおうというのは無理だよ。

んなことわかりきってる。だが可能な限りjreに依存するべきだと思うよ。

＞むしろ四隅を判定しないやり方ってありえないだろ。

全然ありえなくない。逆になぜ四隅を判定する必要があるか書いてごらんよ

**名前は開発中のものです。** · 2013/01/19(土) 01:39:37.12

ちなみに、中心一点というかそれを基準にするのは悪くないと思う
なにより二次元における閉じた図形であれば必ず重心が一点のみ存在する訳で、これほど保守性の高い性質はない。

あと、

if(playerRectangle.intersects(blockRectangle) {
Rectangle intersection = (Rectangle) playerRectangle.createIntersection(blockRectangle);
...
...
}

で重なった矩形が取れるなんつーくっそ便利なモノ使わないと損だと思うよ。
四隅にこだわってる理由がよくわからんし、一応ここJavaスレだで。

**名前は開発中のものです。** · 2013/01/19(土) 01:42:43.12

＞可能な限りjreに依存するべきだと思うよ。
的外れ。

＞なぜ四隅を判定する必要があるか書いてごらんよ
Rectangleを使うと四隅を判定しないのか？

>>82-83の話をしてるから、そこんとこ踏まえてね。

**名前は開発中のものです。** · 2013/01/19(土) 01:58:37.40

>>92
>>91が四隅を判定しているように見えるのか？
判定してるのは交差してるか否かだろうよ。
「だけど内部処理は・・」って？どっちが的外れなんだか。

**名前は開発中のものです。** · 2013/01/19(土) 02:03:27.73

>>93
プレイヤーとブロックの四隅を判定しているように見えるけど、何か違うのかな？

**名前は開発中のものです。** · 2013/01/19(土) 02:17:39.53

>>83(俺じゃないけど)は設計の話をしているわけで、
実装において物理エンジンでもRectangleでも
より原始的な方法(int x,y,w,h)でも好きにすればいい話。

１から１０まで書かないとわからないようだな。

**名前は開発中のものです。** · 2013/01/19(土) 02:20:19.61

A⊂Bの意味で言ってるのね。
ならなおさらBのRect使えよと言いたいが、設計の段階の話なら
＞より原始的な方法(int x,y,w,h)でも好きにすればいい話。
で納得。

**名前は開発中のものです。** · 2013/01/19(土) 12:23:53.82

単純にこんな感じでいいんじゃないの？試してないけど
マップチップを敷き詰めた状態でブロックがいちいち矩形座標持ってるとも思えないし
あと上下左右４方向の移動・当たり判定が理解できるまでななめ移動は考えない方がいい

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--;
　　　　}
　　}
}

**名前は開発中のものです。** · 2013/01/19(土) 15:59:40.56

ブロックの大きさも一律固定だろうしな。
単純なアプリなら単純に作ったほうが工数が少なくて楽。

保守性がどうとか初心者が背伸びして粋がってるとしか思えん。

**名前は開発中のものです。** · 2013/01/19(土) 16:59:27.07

別に俺が言ってる方法は複雑じゃないと思うんだけどな～。（ソース量の面やAPI的にも）
「基本図形を描画するメソッドは使うな！」的な流れも確かにあったが、今は利用できるものは利用したほうが便利でシンプルに書けることに気づいてるじゃん。
Java2D使うのは初心者には無理だと思ってるならそれはバカにしすぎだと思う。

http://www.youtube.com/watch?v=Otl24e_nuyc
例えばこういうチュートリアルみてもビギナー向けの解説としてるけど？

**名前は開発中のものです。** · 2013/01/19(土) 17:03:50.09

awt使うのは・・・に訂正。

**名前は開発中のものです。** · 2013/01/19(土) 18:25:25.58

なんか感じの悪いスレだな

97 · 2013/01/19(土) 20:16:33.84

>>97
風呂入ってコード思い浮かべたらいきなりバグあったわ。気晴らしは大事だね

while (MAP[CHARA_Y / CHIP_SIZE][(CHARA_X + CHARA_SIZE) / CHIP_SIZE] == 1) {
これだけだと右上しかチェックしてないわ。下記が修正パッチね

while (MAP[ CHARA_Y　　　　　　　　　　 / CHIP_SIZE][(CHARA_X + CHARA_SIZE) / CHIP_SIZE] == 1) ||
　　　　MAP[(CHARA_Y + CHARA_SIZE) / CHIP_SIZE][(CHARA_X + CHARA_SIZE) / CHIP_SIZE] == 1) {

>>99
キャラクタ同士の当たり判定ならわかるけどブロックとの判定でもそうなの？
俺は勝手にボンバーマンをイメージしたけど、本当に１つ１つのブロックもRect座標を持つべきなの？

**名前は開発中のものです。** · 2013/01/19(土) 21:38:54.76

＞本当に１つ１つのブロックもRect座標を持つべきなの？

ボンバーマンなら特殊形状のマップでも
1ブロックの組み合わせに過ぎないから必要ないね。

ゲームがブロック崩しで、各ブロックの大きさや形（長方形・正方形）が
異なるなら、Rectangleが望ましい可能性が高い。

**名前は開発中のものです。** · 2013/01/19(土) 22:23:26.72

必要か、必要でないかはアプリケーションの仕様が決める。
オブジェクト指向設計として何が望ましいかはまた別の話。

オブジェクト指向設計としては、定数が各コードに散らばるのは良くない。
そこんとこに拘るなら、ブロッククラスにRect持たせて、
コンストラクタでRectの幅と高さを定数値に初期化すれば
定数(final int BLOCK_SIZE)を使ってる部分を隔離できる。

**名前は開発中のものです。** · 2013/01/19(土) 22:58:15.32

そんな話だっけ？
俺は単純に>>71からの一連の質問に対して
>>85(yYWDydAV)の案は合わないなと思ってるだけだけど。

**名前は開発中のものです。** · 2013/01/20(日) 00:17:41.28

＞単純に>>71からの一連の質問に対して～
そうだよ。質問者はアプリケーションの実現方法について聞いてる。

でも>>6 = >>59 = >>85 = yYWDydAVの話が噛み合わないのは、
目的を達成すれば、ゲームの仕様を満たせばそれでいいってわけじゃない
みたいな話を押し付けてるからだと思うんだよね。

あえて質問者を無視して「１つ１つRect座標を持つべきなの？」に答えれば
>>104みたいな話にはなる。

**名前は開発中のものです。** · 2013/01/20(日) 00:20:40.09

まあオブジェクト指向設計とか一般論としてどうだろうと
質問者にとって良い回答をすべきだろうな。

**名前は開発中のものです。** · 2013/01/20(日) 02:37:11.99

>>103
誰も一つ一つにRect座標持たせるなんていってないぞい。
先読みしてぶつかる可能性があればRectangle生成するようにする。

**名前は開発中のものです。** · 2013/01/20(日) 04:42:00.77

オブジェクトのサイズが小さくて移動速度がサイズより大きいような
場合はすり抜け対策しようねって話じゃなかったのか。

**名前は開発中のものです。** · 2013/01/20(日) 08:45:04.14

>>108
＞先読みしてぶつかる可能性
俺ならここでチェックしてしまうけどな。この先読みのソースはどんなものになるか知りたいな。

>>109
最初は単なる当り判定の話だったけど、ひょっこりすり抜けの話も加わってるね

**名前は開発中のものです。** · 2013/01/21(月) 01:52:02.04

ショボゲー製作中。

ttp://kie.nu/JdF

**名前は開発中のものです。** · 2013/01/21(月) 06:54:29.41

一度だけ実行するときとかのラッチ回路？ってどうかくのがいいんでしょうか
自分はfieldにstaticなintを初期化して、メソッドをくぐれば1にするみたいな書き方をするのですが、
fieldまで遠かったり、それだけのために用意することにためらいがあります

**名前は開発中のものです。** · 2013/01/21(月) 12:30:21.04

staticイニシャライザで済むなら

**名前は開発中のものです。** · 2013/01/22(火) 13:47:00.06

やってみたが升目あるゲームならrect基準にやるのありだなと思った
むしろ全マスにrectもたせても重くはならんのと違いますかね

マス目クラスにrectを継承させる
描画は
g.fill(this)か
g.draw(this)ですむ

移動しないブロックなら
コンストラクタの引数でsetBoundsして、必要なれば描画も用意
移動するブロックなら（もちろん自キャラでも）
升目クラス描画のところでsetBoundsすれば、スレッド走ってたらレクトも動いてくれる

そしてなにより、intersectsで判定してる様子を描画すると中二病に火がつくｗｗ

**名前は開発中のものです。** · 2013/01/22(火) 14:07:40.54

あ、もちろん画像なら画像を描画。
別に何もかもrectでやらんでいいがどうせextendsする予定のものがなければ、
継承したrectのwidthとかhight使うと良いんでない？

マップ全体が一つのオブジェクト的な設計より、1マス目事に判定が違うのだから1升目ごとをオブジェクトとみたほうがいいかも

ちなみにswing使って囲碁や将棋作るときってこの考えだよね
１升目をJComponentで作って、必要な数だけgridlayoutでしきつめる
これじゃアクションならさすがに重いからawtのrect使うと。

**名前は開発中のものです。** · 2013/01/22(火) 17:48:44.90

とりあえずお前等って何か作ってんの？
目的もなくあたり判定の練習とかしてもしょうがないぜ。

**名前は開発中のものです。** · 2013/01/22(火) 19:23:35.49

やらない奴より１００倍マシ

**名前は開発中のものです。** · 2013/01/23(水) 01:15:45.88

質問なんだけど、MouseListenerやKeyListenerの処理を画面の描画の状態によって切り替えたい場合どうしてる？
例えば
private static final int TITLE = 0;
private static final int MENU = 1;
private static final int BATTLE = 2;
private int status;

private boolean getStatus() {
return status();
}

のように用意して、画面が遷移したらstatusに代入し、getStatus()の値によってswitch文で分けるとか？
もっと上手いやり方あったら教えて欲しい
ここが無駄にコードを膨らませてる気がする

**名前は開発中のものです。** · 2013/01/23(水) 01:32:11.34

>>118
とりあえずstatusはenumにするとして，
あとは俺もswitch文で分けてる．

**名前は開発中のものです。** · 2013/01/23(水) 02:31:45.51

何だやる気のないやつしかいないのか。

>>118
ひとまずint flagとswitchで分けて、あとでストラテジーパターンに変える。
いきなりストラテジーパターンでやると無駄が出る。

**名前は開発中のものです。** · 2013/02/02(土) 17:38:30.08

もうダメだわｗ

Twitterサイバーテロ事件の原因は話題のJavaの脆弱性ｗｗｗｗｗ今すぐアンインストールしろｗｗｗｗｗ
http://engawa.2ch.net/test/read.cgi/poverty/1359787786/

**名前は開発中のものです。** · 2013/02/02(土) 19:57:25.02

せやな

**名前は開発中のものです。** · 2013/02/02(土) 21:14:23.35

enumがStringだと向きとか困るな。
無名クラスで代用するのはどうよ？

abstract class Angle { int index; }
final Angle left = new Angle(0){};
final Angle right = new Angle(1){};
final Angle down = new Angle(2){};
final Angle up = new Angle(3){};

**名前は開発中のものです。** · 2013/02/02(土) 21:46:18.43

Javaは危険だからインストールすらしてない

**名前は開発中のものです。** · 2013/02/02(土) 22:56:21.12

スタンドアロンゲームなんだからローカルで全権限与えて実行だろ
ＷＥＢの脆弱性とか関係無いんじゃないか？

**名前は開発中のものです。** · 2013/02/02(土) 23:54:27.00

>>125
彼らは馬鹿だからそういうの理解出来ないんだよ

**名前は開発中のものです。** · 2013/02/03(日) 00:45:51.50

C/C++プログラマーのJavaのネガティブキャンペーンの一貫だな

**名前は開発中のものです。** · 2013/02/03(日) 01:19:45.37

>>127
全然関係ないが

**名前は開発中のものです。** · 2013/02/03(日) 10:21:42.46

指摘された脆弱性50個のうち40個以上はJavaアプレットの脆弱性。
ブラウザでアプレットの実行をオフにしておけばほとんど影響ない。
そもそもJavaアプレット自体すでに時代遅れの手段で、使っている
サイトはほとんどない。某回線速度測定サイトはアプレットらしいが。

**名前は開発中のものです。** · 2013/02/03(日) 11:15:13.91

ですがアプレットもまた元気になって欲しいですね
って、このスレッドを立てておいて言うのも申し訳ないのですが
http://www.java4k.com/
なるサイトを見つけまして、アプレットx基本APIx4k縛りなんていう面白そうなコンテストを毎年やってるみたいです
しかも中々熱い
アプレットを非難する意味で立てたスレッドじゃないということだけわかってくださいまし

**名前は開発中のものです。** · 2013/02/03(日) 12:05:01.48

JREとインストールするとアプレットが動いてしまう事、
ブラウザでアプレットの実行をオフにしても起動する脆弱性、
これが問題になったんだろうけど、普通の人にはわけわからんわな。

**名前は開発中のものです。** · 2013/02/03(日) 13:31:24.07

今回の脆弱性は最新版 update 13 で全部修正されていると考えていいの？

**名前は開発中のものです。** · 2013/02/03(日) 17:35:19.90

update 13のコントロールパネルでアプレットを動かないように指定できる。
でも一般人はそんなこと言われてもわからず、騒ぎ続ける。
C#がSilverLightを捨てたのは正解だったかもな。

**名前は開発中のものです。** · 2013/02/03(日) 23:55:32.89

そもそもアプレットの話題はすれ違い
何のために>>１が重複スレともいえるこのスレを建てたか分からなくなる

**名前は開発中のものです。** · 2013/02/09(土) 20:55:58.67

質問
自分でレンダリングする場合、敵だったり弾だったりのインスタンス化と描画の時差というか、タイミングはどうすればよいのですかね
原始的？な方法だと
10発撃てる→あらかじめ画面外に10発とも描画しておく→キー入力でsetter使って移動
みたいな感じですか。これは時差？が無いので描画メソッドもスッキリしそうです。
ですが、
まずキー入力→その結果インスタンス化→そして描画
という流れにしたい場合の描画メソッドはどのように書けばいいのですかね。
例えば、

ArrayList<Teki> tekiArray = new ArrayList<Teki>();
を用意しておき、キー入力を受けて

tekiArray.add(new Teki(...));
な設計での描画をどうするかということです。

if(tekiArray.size() != 0) {
for(int i=0; i<tekiArray.size(); i++) {
tekiArray.get(i).draw(g);
}
}
みたいなことも考えましたが、うーん・・・

**名前は開発中のものです。** · 2013/02/09(土) 22:14:33.38

質問の意味が全く分からないんだが・・・
時差って何やねん？

**名前は開発中のものです。** · 2013/02/09(土) 23:02:11.08

画面外にあるものを描画することはないだろ。
あらかじめインスタンスを弾の数だけ用意しておくのは正解。
画面の外に出た弾はフラグ立てて休ませておいて使いまわすのがよい。
休みフラグの立っている弾は当たり判定と描画をしないでreturn;。

発射時に毎回インスタンスを生成するのを避けるのは
ガベコレ持ち言語でSTG作るうえでの基本。

**名前は開発中のものです。** · 2013/02/09(土) 23:17:25.67

敵と敵の弾はどうだろうね。
ものすごい大群とかじゃなけりゃその都度new()+add()でいんじゃね？

どうせしょぼいもんだろうしな。

**名前は開発中のものです。** · 2013/02/10(日) 01:33:03.92

>>135 でいいと思うけど
その draw がどこから呼ばれるのかちょっとだけ気になったりする

**名前は開発中のものです。** · 2013/02/10(日) 04:16:31.60

>>136
時差というか、前者では実行した瞬間から描画されてますよね？（画面にみえてないだけで）
しかし後者はキー入力を受けてからなのでプログラムを実行した時点では描画されていないですよね？
つまり描画メソッドに条件式必要になるとおもうのですが。

>>139
drawはTekiクラスがもっているメソッドです。（オフスクリーンのBufferedImageに描画するため）

**名前は開発中のものです。** · 2013/02/10(日) 12:10:15.72

まずメインループがどうなってる？なんか怪しいぞ

**名前は開発中のものです。** · 2013/02/10(日) 12:54:26.23

？？？

**名前は開発中のものです。** · 2013/02/10(日) 13:24:56.51

>>135
玉のテクスチャと透明のテクスチャ作っといてまずそれを自由に
切り替えられるようになるべし。まあ画面外に出しといてもいいけど。

**名前は開発中のものです。** · 2013/02/10(日) 13:44:16.59

メインループってRunnableのrun()メソッドのことかな・・・。

@Override
public void run() {

updateKey();
updateRendering();

}
みたいにキー入力をアップデイトしてからダブルバッファリングしてます

**名前は開発中のものです。** · 2013/02/10(日) 15:27:52.05

俺は>>137の方法でやってるなぁ．自分の弾も，敵の弾も．
発射の都度にnewしたら，たくさん撃ったときにとても処理が遅くなったし．

**名前は開発中のものです。** · 2013/02/10(日) 16:08:37.65

>>145
確かに打つ瞬間が遅くなりますが、しかしその方法だとArrayList使う意味がないというか・・・
シューティングを例にあげたので、「初めから数を決めてnewしておく」が最善かと思いますが、
もしそのインスタンスの数がかなり多い場合を仮定すると、それはプログラム全体を重くしますよね？
それで移動だとかその他の処理の優先度を高くしたい場合致命的だと思うのです

**名前は開発中のものです。** · 2013/02/10(日) 16:13:08.41

シューティングで弾が多すぎる場合はむしろ処理落ちさせた方がいいんじゃない
避けれないし

**名前は開発中のものです。** · 2013/02/10(日) 16:55:26.05

昔はハードの都合で処理落ちしてたけど
それがむしろ迫力のある演出にもなっていたな。

>>146
メモリが枯渇すれば実行例外でアプリが強制終了。
たぶんオブジェクトを配列で100万超えたあたりから

あとメモリを確保する事自体は重さと全く関係ない。
新規確保＋捨てるを繰り返すと重くなる。（捨てたものを回収するから

ならば１つのシーンとかステージの間、ずっと捨てなければ良いってのは
C#やJavaでゲーム作る際のコツ。

もし初心者でなければ、オブジェクトプールを作ればいい。

**名前は開発中のものです。** · 2013/02/10(日) 17:03:17.27

あとArrayListでadd()したものをremove()していながら
速度がどうとかいってるのはおかしな話だと思う。

敵が1000いて、300番を1体remove()したら後ろ700体を詰めなおす処理が走るけど。

**名前は開発中のものです。** · 2013/02/10(日) 21:13:15.85

え！remove()したほうが重くなるんですか。

**名前は開発中のものです。** · 2013/02/10(日) 21:43:22.70

>>150
それが中でどういう処理されてるか想像してるか？

**名前は開発中のものです。** · 2013/02/11(月) 18:11:27.91

Javaを使うなら少々の処理落ちには目をつぶれ
ど～～～～しても処理落ちを許せないならJavaなんか捨ててしまえ

まあ >>135 みたいなこと質問してる時点で
前者しかあるめぇ

**名前は開発中のものです。** · 2013/02/12(火) 20:08:58.69

そんな使い方したいならLinkedList使え
これならremove()しても軽いはず

**名前は開発中のものです。** · 2013/02/19(火) 23:28:13.96

JavaFX使ってますか？

**名前は開発中のものです。** · 2013/02/20(水) 18:26:13.94

たま～に使ってるけどゲーム開発には使ってませぬ
だけど8きたら使うかも

**名前は開発中のものです。** · 2013/03/04(月) 16:50:08.02

壁とキャラの当たり判定難しい。タイルでするなら
if (map[y][x] == 1) {
return true;
} else {
return false;
}
だけど、ピクセルなどよくわからない。

**名前は開発中のものです。** · 2013/03/04(月) 17:15:36.43

>>156
ピクセル単位？と思ったが恐らくエスパーすると、矩形同士の交差判定をしたいのではと思った
物理的な接触はそうだが、でも論理レベルだとそのタイルと同じことだと思うよ
…最終的にどんな内容なのか知らないが

**名前は開発中のものです。** · 2013/03/04(月) 18:05:20.38

すみません。Rectangleのやつではなく、
■■■■■■■
■　□ ■
■■■■■■■ のピクセル単位です。
Javaでゲーム作りますが何か？のやつで、
今現在、ドラクエみたいな全方向移動をピクセル単位で動かして当たり判定を書きたいと思っています。
そこのマリオで配布されているコードを写して、左右”だけ”の当たり判定をやろうとしたのですが挙動が変になりました。（判定なしは問題無し）
左の壁の判定は大丈夫なのですが、右へ行くと途中で何も無い空間で止まってしまいます。
yも下へある一定下がるとエラーがでます。y方向には何も変更は無いはずなのですがどうなっているのでしょうか？
public void update(){
x += vx; // 当たり判定実装の時は消す
vx = 0; //　上に同じ
y += vy; //
vy = 0; //

double newX = x + vx;
Point tile = map.getTileCollision(this, newX, y);
if (tile == null){
x = newX;
} else {
if (vx > 0){
x = Map.tilesToPixels(tile.x) - WIDTH; // 右の壁にぶつかる前に止まる。なんで？
} else if (vx < 0){
x = Map.tilesToPixels(tile.x + 1); // この左の壁の判定は大丈夫。けど数値を10とかにすると変になる
}
//vx = 0;　// もともとあったけど、自分のやつじゃ動いてくれなかった。
}
vx = 0; //これで動く
}

**名前は開発中のものです。** · 2013/03/05(火) 09:33:04.36

>>158
どういう計算とか、どういう処理が必要とか、そもそも具体的にイメージ出来てるか？
つまり、そのコードの全てのタイミングで、各々どういう計算でどうなればいい、と。

例えば、そのMapクラスのスタティックメンバみたいなメソッド、それ何やってるの？
普通に書くと、単純に式書いて終わりだと思うけど、その中だとか…

何も考えずにコピペ&丸投げとかダメだよ

**名前は開発中のものです。** · 2013/03/05(火) 17:30:28.05

キャラクターが1ピクセル単位で動くとしても
マップの当たり判定はマス毎にあるよね？（1マス＝32x32ピクセルとか）
だからキャラクターサイズ（32x32）とマスのサイズ（32x32）で
判定するのをベースに、キャラクターのピクセル単位の移動を混ぜる感じになるのでは？

**名前は開発中のものです。** · 2013/03/05(火) 18:07:32.87

>>159, 160
確かに、コピペなどマズかったと思います。
そのサイトやdeveloping games in javaで図を使って説明されているので、何となくは理解しているつもりです。
なぜy方向に影響が出ているのかは分かりませんが
基本的にコードはそのままで数値を変えて学んでいるので、MAPクラスもそのサイト（javaでゲーム作りますが何か？）のマリオと同じです。
ttp://aidiary.hatenablog.com/entry/20050616/1255785698
キャラがピクセルで判定がマス毎ピクセルの混じりだから？難しいです。
タイルならまだ幾分やさしいのですが、動きがカクカクなのでピクセルにしたかったからです。

**名前は開発中のものです。** · 2013/03/05(火) 21:58:35.97

なんか勘違いしてるようだが、「タイルだからカクカク」で「ピクセルだから滑らか」ってのは君の思い込みだよ。
1マスごとの移動だってピクセルを基準に動かしているわけだが。
おそらくkeyPressedでフラグ立ててkeyReleasedでフラグ折って動かす場合とその判定をしないときの挙動をわかってない。

**名前は開発中のものです。** · 2013/03/05(火) 22:41:16.35

そうなのですか？なるほど、確かに１タイルは32X32ピクセルですね。
フラグってこれ？のことですか？keyReleased も同じみたいですが。
public void keyPressed(KeyEvent e){
int key = e.getKeyCode();

if (key == KeyEvent.VK_A){
leftPressed= true;
}
if (key == KeyEvent.VK_D){
rigtPressed= true;
}
if (key == KeyEvent.VK_W){
upPressed= true;
}
if (key == KeyEvent.VK_S){
downPressed= true;
}
}

**名前は開発中のものです。** · 2013/03/05(火) 23:01:22.81

>>163
そうそれ。

君がいう「カクカク」な状態って言うのは、そのフラグ判定してるところに直接移動メソッドを書いた場合のことっだとおもう
なぜかっていうとそのkeyPressedメソッドはupdate()されていないよね
だから「押している間動かす」ということをしたければ、キープレスでフラグtrue、キーリリースでフラグfalseにしておいて
メインループに書くupdate()メソッド内で移動処理するわけ

**名前は開発中のものです。** · 2013/03/06(水) 18:23:56.13

なるほど。
たしかに、それなら当たり判定はシンプルのままに出来そうですね。
お手本（サイトで配布されているコード）を見てもちょっと混乱してしまったので、もう一度Developing games in javaの当たり判定コードの理解を頑張りたいと思います。当たり判定って難しいです。

**名前は開発中のものです。** · 2013/03/09(土) 03:05:43.17

すごい簡単な話で
・移動判定はマス単位
・移動アニメーションはピクセル単位
にするだけじゃないのか？

**名前は開発中のものです。** · 2013/03/09(土) 03:25:33.88

いやそれだけじゃないと思う
十字キー押し続けると一回入力あってから少しディレイしてから連打？みたいな挙動になるでしょ？
ようするにこれを「カクカク」した状態と表現したのだと思うよ
だからmousePressedとmouseReleasedでフラグ判定して、メインループでtrueなら移動みたいに、押している間動くようにした状態をなめらかといっているはず

**名前は開発中のものです。** · 2013/03/09(土) 07:39:04.60

ぷよぷよ作ってるんだけど移動と回転をどう定義するといいだろうか
とりあえずやったのは

int[][] field = new int[12][6];
のようなフィールドを0に初期化して

int[][] puyo = new int[3][2];
を
for(int j=0; j<3; j++) {
for(int i=0; i<2; i++) {
if(i == 1) puyo[j][i] = 1;
}
}
のように初期化し、
010
010
で1のときに描画して、移動処理はfield[j+offsetY][i+offsetX] += puyo[j][i];
のようにした

だけどこれじゃプヨを右方向に動かしたらfieldの横幅を超えてしまうよね？だからエラーでてしまう。
C++だと同じやり方でエラーでないんだけど、もしかしてC++の場合は初期化したfieldの幅を超えたら勝手に広げてくれていたのかな？
Javaでこれをするにはどうしたらよいだろう

**名前は開発中のものです。** · 2013/03/09(土) 07:47:34.35

>>166, 167,
それもあるのですが、マス（32X32）だと一歩歩くごとに32ピクセルも移動します。
ゼルダの時空の章などはもっと歩幅が小さい（1ピクセルとか？）のでマス移動だと「カクカク」してしまいます。

**名前は開発中のものです。** · 2013/03/09(土) 09:00:20.72

>>168
offset足した値が横とか縦を越えていないかチェックしてはじけばいいのでは。

C++の場合はオーバーランしてメモリ壊してるよ。
警告なんて出ない。

**名前は開発中のものです。** · 2013/03/09(土) 11:43:02.11

>>168
上下左右に１マスずつ広げて壁の部分もフィールドの一部ということにするのが簡単かと
ちなみにあれ実はフィールドの最上部に見えないけどぷよの置ける部分が存在するから縦は13段だよ

**名前は開発中のものです。** · 2013/03/10(日) 00:01:43.20

>>170
＞offset足した値が横とか縦を越えていないかチェックしてはじけばいいのでは。

これ、自分も考えたんだけど、そのチェックに加えてpuyo配列自体の1の部分も1列横にシフトとかそういう面倒な操作いるよね・・
だから投げそうになったんだ

>>171
なるほど。だけどそれでもかなり大変なコードになりそうだ・・・。見えているゲーム領域の左上とfield[0][0]が対応しなくなるよねきっと。

やっぱC言語ちっくなpuyoをint型にするような設計はよくないのかな。
fieldの値を基準にpuyoを描画するんじゃなくて、Puyoクラスを作って独立させて描画させるべきか。
でもfieldの状態を更新するのが難しくなりそう・・・

**名前は開発中のものです。** · 2013/03/10(日) 06:42:22.32

質問。
http://aidiary.hatenablog.com/entry/20050624/1255786339で、マリオにファイヤーボールを出させたい。
(^o) ～～@　な感じ。
どうやったらマリオの場所をスクロール中の画面の場所を特定できるようになるのだろうか？
マップスクロールで大幅に横に移動するー＞現在のマリオ場所をとって来るー＞ボールにその位置を入力ー＞発射ー＞ボールは画面外。
ーーーーーーーーーーーーーーーーー
| 　　　(^o) 　　　　　　　　　～～｜@　<-　ボールは画面外
| |
ーーーーーーーーーーーーーーーーー
ボールのクラスで
public void setPos(double x, double y) { //　位置設定
this.x = x;
this.y = y;
}
MainPanelクラスで
Point posX = player.getPos()
weapon.setPos(posX.x + player.getWidth() / 2, posX.y);　// posX.x -> 現在のx座標、posX.y -> y座標

これだと、右にいくほどボールの発射場所がマリオから右に遠のいてしまう。

**名前は開発中のものです。** · 2013/03/10(日) 07:15:40.28

if(puyo.x % 32 == 0){ // マスのサイズで割った余り0 or not
check(map[x][y]);
}else{
check(map[x][y]);
check(map[x+1][y]);
}

Java以前の初心者スレ化してしまったな。
DXライブラリスレなみのレベルとはなさけない。

**名前は開発中のものです。** · 2013/03/10(日) 08:53:11.38

解決しました。
ボールのdraw()にマップスクロール時の座標を書き入れていなかったらかでした。

**名前は開発中のものです。** · 2013/03/10(日) 20:29:07.98

ボール発射時：左に向いていたら　ー＞　左へボール飛んでいく x-= 6;
右に向いていたら　ー＞　右へボール飛んでいく x+= 6;
private void keyConfiguration() {
if (leftPressed) {
player.move(LEFT);
} else if (rightPressed) {　でキーを拾って
public void move(int dir) {
if (dir == LEFT) {
vx = -SPEED;
direction = LEFT; // face to left
} else if (dir == RIGHT) {
vx = SPEED;
direction = RIGHT; // face to right　でプレイヤーの向きは分かった。
public void move() {
if (isInStorage()) {
return; // do nothing}
if (player.direction == LEFT){
x -= SPEED;}
if (player.direction == RIGHT){
x += SPEED;}
if (y < 0 || y < -(panel.scrolledHeight())) {
store();
}
コンパイルはokみたいで実行したら
Exception in thread "Thread-2" java.lang.NullPointerException
at theLastSamurai.Weapon.move(Weapon.java:51)
at theLastSamurai.MainPanel.run(MainPanel.java:80)
at java.lang.Thread.run(Thread.java:679)　何故？

**名前は開発中のものです。** · 2013/03/10(日) 21:25:31.59

初心者以前に馬鹿じゃねえの。
例外のスタックトレースも読めないとか池沼か。