Javaでゲーム作成 2本目

**名前は開発中のものです。** · 2005/10/27(木) 09:43:50

Javaでのゲーム作成について情報交換をするスレです。
ゲーム作成以外の話題はム板（http://pc8.2ch.net/tech/）、
他言語に関する話題は他スレでお願いします。

前スレ
JAVAでゲーム作成
http://pc8.2ch.net/test/read.cgi/gamedev/1074347252/

テンプレは>>1->>10あたりを参照

**名前は開発中のものです。** · 2006/02/05(日) 19:35:20

>>232

640x480の画面に32x32のマップをひきつめただけですでに４０ＦＰＳだったんですよね
Graphics2D。。。

やっぱりＣ＋＋の方がゲーム開発はいいのかなぁ・・・
開発効率はＪａｖａの方がはるかにいいんですけどね

何かJOGLやLWJGLに近い速度がでるゲーム用ライブラリって
ないんでしょうか

**名前は開発中のものです。** · 2006/02/05(日) 19:44:36

アルファブレンドでしきつめたらそれくらいにはなりそうだが
通常転送ならそこまで遅くなることはあるまい

使い方がおかしいかと

**名前は開発中のものです。** · 2006/02/05(日) 19:48:54

>>234

アルファブレンドで描画したときです。
正直なきたくなりました。
同様の処理でＤｉｒｅｃｔＸの場合は余裕を持たせてもＦＰＳ５００ぐらいでした。

**名前は開発中のものです。** · 2006/02/05(日) 20:03:06

デフォはDirectDrawベースだから当たり前
PureJavaベースのゲームなら少し前のコンシューマの２Dベースにしておくべき

アルファブレンドが多い場合は自前のエンジンを使ったほうがいい
Java2Dのアルファブレンドは機能が多すぎて高級すぎる
回転とかも同様

あとメモリアクセスを減らすために解像度を下げるとか
今後を考えてレンダリングエンジンはマルチコアに対応させる

現状を考えると320*240-16bppが２DでJavaでの安定動作の限界だと思うよ
それを2倍拡大して描画するのがベストか

Sunはデスクトップ部分に5.0は力を入れるといいつつ
1.4.2とほとんど変わらなかった前科があるから6にも期待薄だな

**名前は開発中のものです。** · 2006/02/05(日) 20:25:57

-serverを指定するだけ多少は速くなるし、メモリ次第かなぁ

**名前は開発中のものです。** · 2006/02/05(日) 21:05:19

serverはゲームではオススメしない
強度の最適化のために滑らかに動かない

**名前は開発中のものです。** · 2006/03/01(水) 00:33:42

BufferStrategyとpaintComponentを切り替えられるようにすれば
RPGツクールでキーボード名前入力を可能にした感じのゲームも可能なのかな。
でもそんなことしてたらMMORPGなんて作れない気もする。
-serverの件もそうだけど、なんかもどかしい

**名前は開発中のものです。** · 2006/03/01(水) 00:53:30

一応BufferStrategyはCanvasでも使える
AWTなのであまり込み入った使い方しないように

**名前は開発中のものです。** · 2006/03/01(水) 01:34:48

おお、ホントだ。BufferStrategyは埋め込み可能だったのか。
ゲーム画面上に透明チャット窓とかしようとするのも可能そうだね。
BufferStrategyならAWTとSwingの差分なんてあってないようなものだろうし。
ちょっと希望が湧いてきました。

**名前は開発中のものです。** · 2006/03/01(水) 02:35:02

5.0からAWTにZOrderが追加される。かゆいところに手が届いてら。

**名前は開発中のものです。** · 2006/03/04(土) 19:59:23

Swingでrepaintをした場合ってイベントキューで処理されるの？
Timerのタイミングできちんと描画スレッドに渡せますか？

**名前は開発中のものです。** · 2006/03/04(土) 23:22:41

何を言いたいのかわからんがSwingは普通のSUIのイベント処理だぞ

リペイントわたしてもリペイント範囲のaddされるだけ

連続でrepaint複数渡しても1回しかリペイントされないとかよくあること

これはSwingに限ったことではない
Windowシステムは全部そう

だからTimerでrepaintわたしたからすぐに描画されるわけではない

正確なタイミングでやるならAWTイベントでのリペイントは辞めるべき
BufferStrategyを使うのが正しい
これは内部でDirectXとか使われてるイベントモデルではなく、いわゆる直書きだ

**名前は開発中のものです。** · 2006/03/05(日) 13:59:16

>>244 どうもです。
FPS管理するからrepaintのままでやります。
描画に失敗したら致命的というわけでもありませんし。

**名前は開発中のものです。** · 2006/03/05(日) 14:46:49

FPS管理って普通にみんなBufferStrategyでしてると思うぞ
なんか勘違いしてないか？

**名前は開発中のものです。** · 2006/03/05(日) 15:12:44

いやJComponentもバリバリ使いたいので。

**名前は開発中のものです。** · 2006/03/05(日) 16:46:58

Swingコンポーネントベースのゲームってめずらしいな
ダブルバッファリングをライブラリに任せるのは割ときついからな

**名前は開発中のものです。** · 2006/03/15(水) 01:15:11

保守

**名前は開発中のものです。** · 2006/03/18(土) 15:46:10

良スレですね。

6年ぶりぐらいにJava触って驚いた～。
趣味の遊びには最適ですね。

**名前は開発中のものです。** · 2006/03/18(土) 23:01:07

exewrapがJavaゲームの必須アイテムになるのかな？
ヒープサイズをjrockitと同じ物理メモリの75%とかに指定したいんだけど
exewrapにはそういう指定は出来ないんだろうか

128m版と256m版の2つ用意したほうがいいかな・・・うーむ

**名前は開発中のものです。** · 2006/03/18(土) 23:25:32

鯖アプリじゃないんだから物理メモリの割合は意味がないぞ
メモリ増えればGCにかかる時間は増えるわけで、ゲームで使用するメモリ量とかちゃんと計算してないの?
それだとGCとかでかたつかないか？

**名前は開発中のものです。** · 2006/03/19(日) 00:20:58

単位時間に対するGC率が増えるのって操作性に影響でないの？

**名前は開発中のものです。** · 2006/03/19(日) 00:26:14

100秒ごとに1秒とまるGCと1秒ごとに0.01秒とまるGCとどっちがゲーム向きかということだ

それにわりあいでやられたら世代の調整とかおわっとる
GCのアルゴリズムの種類だって調整するのは常識なんだし
アプリごとに最適な値は大きくことなる

**名前は開発中のものです。** · 2006/03/19(日) 00:34:10

Mapにキャッシュするサイズ＋演算用のサイズで考えればいいんだよね？
最適値というのは演算分のヒープサイズがどのくらいのものなの？

**名前は開発中のものです。** · 2006/03/19(日) 00:50:29

GCの頻度とか使用量とかチェックしてないの?
-verbose:gcオプションいれてごらん

もっと詳しく見たいのならプロファイラで見るのが一番だが
まずはGC部分に注力するならこれが見やすいだろうね

**名前は開発中のものです。** · 2006/03/19(日) 00:58:12

>>256
OK、チャレンジしてみます。

**名前は開発中のものです。** · 2006/03/31(金) 14:22:07

当方、子供の頃にZ80アセンブラやBASICでゲームプログラムして遊んでいました。
まぁアルゴリズムとかは結構わかります。

今頃になって、再びプログラムを趣味にしてみようと思いJavaを選択しました。
シンタックスやOOPの基本的なことは大丈夫そうです。
Eclipseインストールしてちょっと感激。

で、問題なのはすこしでもDirectDrawとかFPS管理とか、ちょっとでもシステム寄りの
部分になると全然わからないのです。
いくつかソースを読んでみますと、各人でわりと実装が違うようですね。
Java５ではどんな方法がよいのかなど、参考になるものは無いでしょうか。

**名前は開発中のものです。** · 2006/03/32(土) 00:20:26

>>258
そういう人かなりいるよね
ゲームは問題なく作れるけどウインドウアプリになるとmainからはじまらないので
わけがわからない、と

Javaは一応mainから常に始まるしまだ楽なほう
>>1-11あたりはまずよんでみた？

**名前は開発中のものです。** · 2006/03/32(土) 01:27:44

3/32 記念ﾊﾟﾋﾟｺ

**名前は開発中のものです。** · 2006/04/04(火) 13:36:48

eclipseってそんなに良いか？【エクリプス】
http://pc8.2ch.net/test/read.cgi/tech/1099300344/274-
> 280 名前：デフォルトの名無しさん[sage] 投稿日：2006/04/04(火) 09:53:59
> >>276
> ほんとかよ。
> 2Dゲームの背景にタイルを敷き詰める処理を作ってみたが明らかに遅いぞ。
> これと言って変な処理は入れてないが、5fps出ない。
>
透過pngをImageIO.read()で読み込んで
Graphics.drawImage(Image, int, int, ImageObserver)で表示すると確かに重くなるが
上の奴はこれと同じ状況なのだろうか？

**名前は開発中のものです。** · 2006/04/04(火) 13:41:10

アルファブレンドだと重いけどただの色抜きなら重くはないよ
5.0ではBufferedImageのままなにもしなくてもそれなりにきくようになってるし
5fpsってありえんね

そもそもソフトウェア描画でもVGAで30fpsはでそうだが

**名前は開発中のものです。** · 2006/04/06(木) 12:59:32

iアプリを作ろうと思って勉強してるんですが、画像表示で躓いています。

サンプルではちゃんと表示されるんですが、画像を自作のものと入れ替えるとIO.connectionexception
ってのがでるんです。サンプルと同じGIFでサイズも同じにしてあるんですが。自作画像の方に問題が
あるんでしょうか。

**名前は開発中のものです。** · 2006/04/06(木) 14:20:33

>>263
動かないのが実機かPC上かを明記してもらえるとありがたい
サンプルがどんな処理を行うアプリケーションなのかも関係してくる
情報が少なすぎるのでエスパー回答してみるが、

・ファイルが壊れている
終端コードが無かったり、BMPなのに拡張子だけGIFにしたとか
試しにネット上に転がってる別のGIFファイルでテストしてみては？

・ファイル名の指定が間違っている
サンプルと同じファイル名にしてテストしてみては？
大文字小文字、全角半角の違いがないか気をつけて

・容量がオーバーしている
同じサイズというのはピクセル数のことだと思いますが、
バイト数が上限を超えていないか確認してください。

**名前は開発中のものです。** · 2006/04/06(木) 17:15:27

適当に書いてすいません。エラーがでるのはDoja3.5のPC上で、ビルドした後実行すると出ます。
サンプルは簡単なもので、画面にタイトルを表示するだけのものです。十枚ある画像を取り込んで
そのうちの一つを画面に表示するものです。

ファイルが壊れている＞壊れているかは私に判断できないんですが、自作の画像はwindowsのペイ
ントで書いて、0という名前で（サンプルで表示されるのが0.gif）形式をGIFにしています。

容量がオーバー＞サンプルは色付きですが、自作のものは白と黒のみなのでサイズは小さいです。

いろいろ試してみたんですが、サイズの違う画像の時に一回エラーがでずにちゃんと表示されて、
その画像の大きさをいろいろ変えたんてみても上手く表示されました。やはり元の画像が悪いので
しょうか

**名前は開発中のものです。** · 2006/04/06(木) 17:20:56

あともう一つ。一回エラーが出た後、画像をもとのサンプルの画像にしても、やはり
エラーが出たままなんです。

**263** · 2006/04/08(土) 17:16:17

ソースも画像も変えてないのに何回かやったら表示されるようになりました。
お騒がせしました。264さんありがとうございます。

**名前は開発中のものです。** · 2006/04/08(土) 21:22:15

何回かやったらってありえね
ビルドしてないとか

**名前は開発中のものです。** · 2006/04/09(日) 20:57:47

俺の場合、PCを再起動してみたら正常に動いたってことはたまにある。
メモリが不足してたのかな？

**263** · 2006/04/09(日) 23:11:53

原因はわからないです。さんぷるの画像の内、一枚だけ入れ替えたらうまくいったんで、
一枚ずつ入れ替えていったらエラーがでなくなりました。言われてみれば一回電源切った
あとかも

**名前は開発中のものです。** · 2006/04/10(月) 02:20:42

>>270
わかんないならもうレスしなくていいよ

**名前は開発中のものです。** · 2006/04/15(土) 01:23:46

そのくらいのサンプル段階ならソース晒してもいいでしょう
アップローダにアップしては？
http://gamdev.org/up/upload.php
短いソースならこのスレに書き込んでもいいだろうし。

**名前は開発中のものです。** · 2006/04/15(土) 10:51:05

この板寂しいからレスしてくれよ・・・
書き込みがあるとわくわくする

**名前は開発中のものです。** · 2006/04/15(土) 11:44:35

最近アプレットは流行らないよな。
このスレはJavaアプリのこと？アプレットのこと？
サーバ側の話？J2MEのこと？　なんでもあり？

それよりなにより、漏れは女とJavaTea飲みたい。

**名前は開発中のものです。** · 2006/04/15(土) 16:50:42

MEは実装依存度が高すぎるからそちらのスレで
基本はJavaアプリだろうね

アプレットは社内用リッチクライアント用途ではかなりいいけど
アプリと違って起動時のパラメータとかチューニングが限界がある

アプリによってメモリやGC等の設定は細かくかえるのが普通だから
ゲーム用ではさほど・・
フルスクリーンとかファイルアクセスとか限界もあるしね

手軽に配布ということでフラッシュ程度でいいのならフラッシュで作ればいいし
JavaでやりたいのならWebStartにしたほうがまし

JRE同梱してアプリにしたほうがいいよ

**名前は開発中のものです。** · 2006/04/15(土) 18:40:50

某スレに幾つかアプレットの２Ｄゲームが上がってるけど、
速度的には全然遜色ないな。
アプレットでも結構作れる事は作れるけど、開発環境などその他諸々の点で
フラッシュの方が断然上。
アプレットでゲームを作るメリットは何もないよ。

**名前は開発中のものです。** · 2006/04/15(土) 18:57:48

無料でまともなFlash開発環境があればいいんだけどな

**名前は開発中のものです。** · 2006/04/15(土) 19:10:16

ActionScript経由でFlashの機能は全部表現できるんだよね？
だったらActionScript3.0がパブリッシュ（コンパイルの意）出来る環境があれば
あとはAPIリファレンスを手に入れるだけで何とかなりそう

**名前は開発中のものです。** · 2006/04/15(土) 21:04:45

>>276
配布を考えればの間違いでは?
開発環境はアプレットのほうがどこをどう考えても上

アクションスクリプトきっついよ

**名前は開発中のものです。** · 2006/04/15(土) 22:36:11

>>276
ASの開発しづらさを知ってて言ってるのか？
マジキツイっての、アプレットと作り比べてみろよ。

**名前は開発中のものです。** · 2006/04/21(金) 18:53:51

Java使えればゲーム以外にも仕事で役立ちそう
Flashは覚えても応用範囲が狭そう

**名前は開発中のものです。** · 2006/04/26(水) 22:50:39

>>281
俺はC→AS→Javaだったよ
ASだけは遊びで覚えたんだけど、OO開発の基礎は自然と身についた
MovieClipの仕様がいいんだろうな

**名前は開発中のものです。** · 2006/04/29(土) 05:29:13

みなさんゲーム作ったんですか？
ここじゃ晒さないんですか？

**名前は開発中のものです。** · 2006/05/01(月) 20:40:07

フリーのは、ふりーむ！とベクターで公開してる。
有料のはDLsite.com等で販売中。

**名前は開発中のものです。** · 2006/05/07(日) 00:14:23

知っている方がいらっしゃったら教えてほしいことがあります。

以前j2re1.4.1_02でフルスクリーンとウィンドウモードを切り替えるものを作ったのですが
1.5.0_06では解像度の変更が正しくうごかないという事に当たりました。

手順は
１）フルスクリーンにする
GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
device = ge.getDefaultScreenDevice();
DisplayMode　fullscreen = new DisplayMode(640, 480, 32, DisplayMode.REFRESH_RATE_UNKNOWN);
device.setFullScreenWindow(fullscreen);

２）排他を解除しウィンドウモードにする

GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
device = ge.getDefaultScreenDevice();
device.setFullScreenWindow(null);

この後で１）を行った場合、1.4.1_02ではフルスクリーンで解像度が変わったのですが
1.5.0_06ではフルスクリーンにはなるが解像度が変わらないということになりました。

何かご存知の方がいらっしゃったらお願いします。

**285** · 2006/05/07(日) 00:27:33

書き忘れていました。
１）では決まったフレームをフルスクリーン指定してます。

device.setFullScreenWindow(frame);

**名前は開発中のものです。** · 2006/05/07(日) 02:17:45

元々フルスクリーンと行き来するとリークが発生するから起動時に選択させるほうがいい

ところで意味が分かりにくいのだが
１＞２＞１ってこと？

**285** · 2006/05/07(日) 02:57:40

>287

>元々フルスクリーンと行き来するとリークが発生するから起動時に選択させるほうがいい

ありがとうございます、その方向で考えてみます。

＞１＞２＞１ってこと？

そうです。

**名前は開発中のものです。** · 2006/05/07(日) 11:37:59

いまやってみたけど画面ちゃんと切り替わったよ

**285** · 2006/05/07(日) 14:11:36

>289

j2re1.4.1_02では、繰り返し切り替えたときにちゃんと解像度も一緒に変わったのですが
1.5.0_06ではフルスクリーンにはなりましたが、二度目以降のフルスクリーン切り替えで
解像度が変わりませんでした。（一回目はちゃんと解像度が変わるようです。）

もしうまく切り替わったのでしたらソース、上げていただけませんでしょうか？

**名前は開発中のものです。** · 2006/05/07(日) 14:15:43

こんなかんじ

GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice device = ge.getDefaultScreenDevice();
GraphicsConfiguration gc = device.getDefaultConfiguration();
DisplayMode mode = new DisplayMode(640, 480, 32, DisplayMode.REFRESH_RATE_UNKNOWN);

JFrame frame = new JFrame(gc);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
device.setFullScreenWindow(frame);
device.setDisplayMode(mode);

Thread.sleep(1000);

device.setFullScreenWindow(null);

Thread.sleep(1000);

device.setFullScreenWindow(frame);
device.setDisplayMode(mode);

**名前は開発中のものです。** · 2006/05/07(日) 14:17:41

注意事項としてウインドウモードとフルスクリーンモードで
色深度が違う場合テクスチャキャッシュとか全部作り直してね

異なる色深度で転送を行うとすごく遅くなる

**285** · 2006/05/07(日) 14:20:50

ソース、ありがとうございます。
確認してみます。

**285** · 2006/05/07(日) 15:30:17

>292
先ほどのソースありがとうございました。
フレームの非表示をフルスクリーンとウィンドウ毎にきりかえりため
毎度フレームをdisposeし、再作成していたが原因でした。
ところで、上記ソースのやり方でフルスクリーンのときにだけ
frame.setUndecorated(true);
を有効にしたいとおもい、いくつか試しているのですがうまくいっていません。
作成していたソースを載せておきますので、再度も一度だけご指摘いただけますでしょか？

**285** · 2006/05/07(日) 15:33:08

以下がソースです。

GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice device = ge.getDefaultScreenDevice();
GraphicsConfiguration gc = device.getDefaultConfiguration();
DisplayMode mode = new DisplayMode(800, 600, 32, DisplayMode.REFRESH_RATE_UNKNOWN);

JFrame frame = new JFrame(gc);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

System.out.println("初期表示");

frame.setSize(800, 600);

frame.setResizable(false);
frame.setLocationRelativeTo(null);//中央配置
frame.setVisible(true);

Thread.sleep(10000);
System.out.println("フルスクリーンへ");
//frame.setUndecorated(true);//フレームの非表示
device.setFullScreenWindow(frame);
device.setDisplayMode(mode);

Thread.sleep(10000);
System.out.println("ウィンドウモードへ");
device.setFullScreenWindow(null);

**名前は開発中のものです。** · 2006/05/07(日) 16:01:17

＞このフレームの装飾の有効化と無効化を切り替えます。
＞フレームが表示されていない時にだけ呼び出すことができます。

マニュアルどおりだと思うんだが

タイトルバーの表示、非表示はフレームが表示されているときは駄目
一度非表示にする必要があるよ

**名前は開発中のものです。** · 2006/05/07(日) 16:03:32

GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice device = ge.getDefaultScreenDevice();
GraphicsConfiguration gc = device.getDefaultConfiguration();
DisplayMode mode = new DisplayMode(640, 480, 32, DisplayMode.REFRESH_RATE_UNKNOWN);

JFrame frame = new JFrame(gc);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setUndecorated(true);
device.setFullScreenWindow(frame);
device.setDisplayMode(mode);

for(int i=0; i<10 ;i++){
Thread.sleep(1000/2);

//ウインドウモード
frame.setVisible(false);
frame.dispose();
frame.setUndecorated(false);
device.setFullScreenWindow(null);
frame.setVisible(true);

Thread.sleep(1000/2);

//フルスクリーンモード
frame.setVisible(false);
frame.dispose();
frame.setUndecorated(true);
device.setFullScreenWindow(frame);
}

**名前は開発中のものです。** · 2006/05/07(日) 16:06:27

あ、最後フルスクリーンモードで終わってるんでALT+F4な

**285** · 2006/05/07(日) 17:03:17

丁寧な反応、本当にありがとうございます。
setVisible(false); の後でdisposeが必要なのですね、
わからずに数ヶ月引っかかっていました。
297でいただいたサンプルなのですが、最後のフルスクリーンの状態で
解像度が640, 480ではなく元に戻っていませんでしょうか？
これを何とかできないかなと
//フルスクリーンモード
frame.setVisible(false);
frame.dispose();
frame.setUndecorated(true);
device.setFullScreenWindow(frame);
device.setDisplayMode(mode);
としてみたのですが、今度はウィンドウモードの解像度が戻らなくなってしまいました。
これが一番最初の質問と同じ状態のようです。

**名前は開発中のものです。** · 2006/05/07(日) 17:32:54

ウインドウモードのタイミングが指定がおかしかった

//ウインドウモード
device.setFullScreenWindow(null);
frame.setVisible(false);
frame.dispose();
frame.setUndecorated(false);
// device.setFullScreenWindow(null);
frame.setVisible(true);

としてごらん

**285** · 2006/05/07(日) 18:08:49

ありがとうございます。
切り替え動くようになりました。
動くようになったので調子に乗って切り替え100回とか試してみたら
java.lang.OutOfMemoryError
がでてきました。最初におっしゃってたように、あまり頻繁に切り替えるもんじゃないって事なんですね。

**名前は開発中のものです。** · 2006/05/09(火) 15:25:13

ソース見直してたらstaticでいいのにインスタンス生成してる部分が結構あった
インスタンス生成よりstaticの方が軽い、速いかな？

**名前は開発中のものです。** · 2006/05/09(火) 16:50:48

Java的にはstaticはできるだけ使わないほうがいいらしいけど

**名前は開発中のものです。** · 2006/05/09(火) 17:54:55

オブジェクトはプールしないで積極的に生成破棄してくれ
世代別GCとの相性を考えるとこれ

**名前は開発中のものです。** · 2006/05/09(火) 22:27:04

>>303
実装するにあたって、static変数が必要なデザインパターンもあったんじゃね。

**名前は開発中のものです。** · 2006/05/09(火) 23:23:28

>>303
そういう覚え方はよくないよ。勉強しなおしたほうがいい。

**名前は開発中のものです。** · 2006/05/16(火) 11:01:52

ドラクエってさ、コマンド選ぶと前のコマンドがバックに表示されたまま
次のコマンドが出るじゃん　それでキャンセルで現在のウィンドウが消えて
前のコマンドに参照が戻るよね
あれってそれぞれにバッファ用意してやるしかないかな？
たとえば道具→使う→誰に　なら
道具を表示するバッファ
道具、使うを表示するバッファ
道具、使う、誰にを表示するバッファ
みたいに

**名前は開発中のものです。** · 2006/05/16(火) 11:35:56

ファミコン時代にバッファがあったと思うか?
ひたすら上書き

ウインドウが消えたらアクティブになったウインドウの描画

それだけだよ

**名前は開発中のものです。** · 2006/05/16(火) 11:37:03

一応レイヤーという考え方もありだが、いまだとそっちのほうが楽だろ
それぞれウインドウ内のみの描画管理
画面全体の描画でそれらを適切に呼び出す

**名前は開発中のものです。** · 2006/05/20(土) 04:48:56

>>308-309
遅くなったけどサンクス
なんとなく分かってきた

キャラやアイテムのリスト作るのが面倒臭いな・・・
存在してるキャラ、所持してるアイテムを調べてリストにして
多ければウィンドウをスクロールさせなきゃならぬ
面倒だけどがんばるか・・

**名前は開発中のものです。** · 2006/05/20(土) 09:04:00

面倒か？
わからなければ先にUMLでもなんでもいいけど処理の手順を書いたほうがいい

**名前は開発中のものです。** · 2006/05/21(日) 05:45:05

処理を考えるのが一番面倒だ
きちんと順序立ててやってみるよ・・

**名前は開発中のものです。** · 2006/05/22(月) 04:54:34

俺はデータモデルの設計が一番面倒だなぁ。
変更や拡張に強く、ネットワーク越しの同期の取りやすいデータモデルをとか考え出すとはまり込む。

**507** · 2006/05/22(月) 19:16:41

Javaを最近勉強しはじました。
とりあえず簡単なゲームを作りたいと思っているのですがどれ位勉強すればいいですか？

**名前は開発中のものです。** · 2006/05/22(月) 19:27:29

ゲーム作りで勉強すれば
そういう本最近多いし

**名前は開発中のものです。** · 2006/05/23(火) 14:28:37

if else で100近く分岐しそう・・
激重かな

**名前は開発中のものです。** · 2006/05/23(火) 15:24:24

>>316
どういう風に分岐させたいんだ？

**名前は開発中のものです。** · 2006/05/23(火) 15:30:17

１００こくらいのifでおもくなるって10MHz切ってるマシンの人かな

**名前は開発中のものです。** · 2006/05/23(火) 22:43:16

>>317
たとえばさ、魔法クラスがあって、そのメソッドに魔法No.をわたして
そのメソッド内で渡されたNo.によってswitchで分岐させるとか

話がswitchになっちゃったけどswitchは数しかつかえないんだよね、たしか
それ以外で識別したいならif elseしかないと思って

あと、変数は少ないけどメソッドがたくさんあるクラスのインスタンスを
100個くらいつくるとメモリがやばかったりするかな？

**名前は開発中のものです。** · 2006/05/23(火) 22:51:29

class Magic
{

**320はミス** · 2006/05/23(火) 22:57:01

abstract class Magic{
public abstract void perform();
}
みたいにして、個別の魔法はこれを継承するようにするとJavaらしくなるよね
実際にゲームを完成させる気ならこんなことしないだろうけど

メソッドはたくさんあっても問題なし

**名前は開発中のものです。** · 2006/05/23(火) 23:14:15

デザインパターン立ち読みでもいいからおぼえとくといいぞ

制御とデータをわけるという考え方は
Cとか構造化言語までのものだ

**名前は開発中のものです。** · 2006/05/23(火) 23:18:59

>>321
いや、ゲームでも普通はそういうプログラムを書く

それと識別させたいのならenumを使え
switchもつかえるし

**名前は開発中のものです。** · 2006/05/23(火) 23:34:50

レスサンクス
おかげで設計ができてきた
enumすか・・あまり馴染みがないから学ぶよ

ところで>>321の4,5行目が素でわからない
ｱﾌｫですまぬ
教えてもらっていい？

**名前は開発中のものです。** · 2006/05/24(水) 00:05:11

ポリモーフィズムとかStateパターンとか
そのへんしらべてみるとわかるよ

**名前は開発中のものです。** · 2006/05/24(水) 00:29:52

おｋ、ゲーム作りながら勉強する
いろいろサンクス

**名前は開発中のものです。** · 2006/05/27(土) 11:28:27

VectorにStringとInteger入れて、取り出すときに
Integerの要素をStringでキャスト、変換したり
Stringの要素をIntegerでキャスト、変換したら
エラー出るかな　面倒くさいんでInteger、Stringで統一してるんだが

勉強すればわかることだけどもしよければレスちょうだい

**名前は開発中のものです。** · 2006/05/27(土) 11:38:38

それぞれIntegerとStringが対応してるんなら
class （名前）
{
public String getString();
public Integer getInteger();
}
みたいなクラスを作る

対応してないんだったら、String用のVectorとInteger用のVectorを別にする

**名前は開発中のものです。** · 2006/05/27(土) 11:49:40

キャストはかならずクラスの関連性がないと無理
かならず数字を含む文字列ということであれば格納前に返還すればいいだけの話だが
この情報だけではどうしたいのかがわからない

あとゲームということは多少パフォーマンス気にすることも多いのだろうから
Swing部分使わないのならVectorよりはArrayListで

シングルスレッドならパフォーマンスはまずかわらんけどな

**名前は開発中のものです。** · 2006/05/27(土) 13:09:54

即&わざわざレス感謝
ArrayListの方がパフォーマンスいいのか・・・
大分Vector使ってコード組んじゃったから、今度からはそうしよう
RPGだからスレッドはマップのキャラ動かすのとアニメーションくらいしか使わないと思う

Vectorの指定された要素がIntegerかStringかで
変換、キャストしたのちifで分岐させて処理を分けたいと思ったんだけど
やっぱり元々のVectorを別にした方がわかりやすかった　対応してないし

話変わるけど、コマンドの実装が面倒だ・・
移動コマンド、アイテムコマンド、魔法コマンド、使用対象コマンド・・
それぞれにクラス作ってそのクラスのキーイベント処理メソッドを
現在のコマンドモードによって呼び分けなきゃならん
いい方法ないかな

**名前は開発中のものです。** · 2006/05/27(土) 13:39:56

よくわからんがキーイベントにゴリゴリ書いてるのか?
それならフレームワークの設計自体からやりなおしたほうがいいぞ

**名前は開発中のものです。** · 2006/05/27(土) 13:57:59

ゴリゴリ書いてる・・
とりあえず組んでみようとは思ったがマジで勉強が足りんらしい
チラ裏ｽﾏｿでした