【初心者】ｽﾚを立てる前にｺｺで質問を【Part21】

**名前は開発中のものです。** · 2010/04/02(金) 00:21:35

疑問に思うことがあれば、スレを立てずに、まずはココで質問。
スレッドを立てる前にはローカルルールを読みましょう。
http://pc11.2ch.net/gamedev/

※ >>980 を踏んだ人は次スレ立てをお願いします。
【アップローダ・避難所・Wiki】
ゲーム製作技術板公式Wiki
http://wiki.game-develop.com/

ゲーム製作技術板公式アップローダ
http://gmdev.xrea.jp/

ゲーム製作技術板予備（機能停止中？）
http://yy13.kakiko.com/gamdev/

アップローダー予備
http://gamdev.hp.infoseek.co.jp/

gamdev.orgが落ちるたびにあげてみるスレ
http://pc11.2ch.net/test/read.cgi/gamedev/1107022166/

**名前は開発中のものです。** · 2010/08/29(日) 05:41:19

パチンコの抽選部分調整するだけなんてゲーム製作とは言わない
スレは適当なサンプル準備してやる気と継続性見せてから立てろよ

**名前は開発中のものです。** · 2010/08/29(日) 05:51:30

パチンコゲームって
http://hibari.2ch.net/test/read.cgi/gamedev/1007632693/

かつてのスレッド。
これは玉の物理演算までしようとしたみたいだけど。

> 画像・サウンドが一通り入っていて
> 確率で分岐するイベントを細かく設定できるソフトを探しています。

こんなのメーカーにしか存在しないのでは？
そもそもパチンコのあれって紙芝居みたいなものだよね。
リーチがかかってから判定しているとかではなくて、最初に結果ありきでアニメが表示されるんだよね？

極論すれば、サイコロの１の目だからこのアニメ、２の目だからこのアニメみたいな。
そうするとやっぱりゲームではないような…？

**名前は開発中のものです。** · 2010/08/29(日) 05:57:37

RPGツクールVX 48
http://yuzuru.2ch.net/test/read.cgi/gameama/1275209455/806

>>614 = この人かな？

**名前は開発中のものです。** · 2010/08/29(日) 08:39:32

>>614
スレ立てしても殺す勢いで叩かれると思う
お前が浅すぎることが原因で

**名前は開発中のものです。** · 2010/08/29(日) 08:49:04

まず間違いなく欲望レベルで終わるな。

**名前は開発中のものです。** · 2010/08/29(日) 11:32:19

いまのパチってほとんどオーサリングツールで作ってるんじゃない？
Adobe Directorとか

**名前は開発中のものです。** · 2010/08/29(日) 11:33:15

>>615
約１０年前、学生時代にＲＰＧツクール４で
一応、パチンコゲームとして完成させたのですが、
（製作時間は６０時間くらいでした）
今は…恥ずかしながら、作りきる自信はないです

>>616
そこのスレは、もう誰もいないんですよね…
他に適当なスレがないか探したのですが、見つからなかったもので。
ちなみに、玉の流れは演出せずに、デジタル変動だけ作りたいと思ってます。
ニコニコ動画などに存在するオリジナルパチンコみたいな感じです。

>>618
>>619
やっぱりそうですか。
パチンコゲーム製作者の集うスレって存在しないようなので
立てるのも有りかなと思ったのですが

**名前は開発中のものです。** · 2010/08/29(日) 11:34:48

>>616 のスレ使わせてもらえよ

**名前は開発中のものです。** · 2010/08/29(日) 11:38:37

>>617
あっそうです。向こうでも書きました。

**名前は開発中のものです。** · 2010/08/30(月) 17:06:32

javaで背景をスクロールさせる場合

img.drawImage
でずらして再描画

int[] p = ((DataBufferInt)img.getRaster().getDataBuffer()).getData();
配列にしてforでドット単位でずらす。

どちらがいいでしょうか。
drawImageは意外と速度が遅く描画が誤動作してしまう場合がありました。

配列の操作は意外と速いですが力技でやはり負担が増えそうな気がします。

**名前は開発中のものです。** · 2010/08/30(月) 17:14:12

VolataileImageだっけか。そっち使えばいいんじゃなかったっけ？
もう気にせずに勝手に使われるようになってるんだっけ？

遅いとか思ったこと無いぞ。

**名前は開発中のものです。** · 2010/08/30(月) 17:25:26

なるほどVolatileImageは高速のようですね。
drawImageは作ったものを貧弱なポケットPCで動かすと画面がめちゃくちゃになってしまうことがありました。
2画面やオブジェクトとの重ねあわせで有利なものがいいのですが。
引き続き経験談お待ちしています。

**名前は開発中のものです。** · 2010/08/30(月) 17:51:02

>貧弱なポケットPC
こんな条件後から出すなよなー。
そこが前提になると、ぜんぜんわからん。

**名前は開発中のものです。** · 2010/08/30(月) 17:54:17

前提という訳ではありません。一例です。
drawImage画面崩れの現象はデスクトップでも起こりました。
もちろん最終的にはデスクトップで動けばいいです。

**名前は開発中のものです。** · 2010/08/30(月) 18:15:00

正しく作ったものが、画面崩れたとかはない。
画面が崩れるのはほとんどの場合環境依存か
自分のプログラムのせい。

**名前は開発中のものです。** · 2010/08/30(月) 18:27:54

ちょっとずれますがjavaではタイミングの問題で動作が違うというのはあるようにおもいます。
前例のポケットPCのものはデスクトップで完全に動きます。
デスクトップでずれたというのは別のものでdrawImageのやつだったのですが
スクロールだけ配列操作に書き換えるとその（ちょっとした）崩れは直りました。

**名前は開発中のものです。** · 2010/08/30(月) 19:20:32

描画のタイミングは制御できるんだが。
まさかダブルバッファリングとか意識せずにやってんの？

**名前は開発中のものです。** · 2010/08/30(月) 19:22:11

ダブルバッファリングやってます。

**名前は開発中のものです。** · 2010/08/30(月) 19:29:41

>デスクトップでずれたというのは別のものでdrawImageのやつだったのですが
>スクロールだけ配列操作に書き換えるとその（ちょっとした）崩れは直りました。
ダブルバッファリングやってるなら、ずれようがないでしょ？？？

オフスクリーンの背景画像の上にスプライトを描画して、
最終的にオンスクリーンに描画するのに、なんでスクロール画像が別物扱いなの？

**名前は開発中のものです。** · 2010/08/30(月) 19:38:50

実際に表示がおかしかったとしか言いようがないです。
バッファリング画像の元データのサイズを2倍に指定したらまともに表示できた
なんて現象の1例もありました。

**名前は開発中のものです。** · 2010/08/30(月) 20:00:49

ダブルバッファリングしてるつもりで、全然してなかったとか。ｗ

**名前は開発中のものです。** · 2010/08/30(月) 20:15:00

なぞな現象だな。

とりあえずデスクトップでおかしな現象はプラットフォーム上には無いし、
俺が作った奴は640*480でスプライト500個ぐらいは何ともなく表示できた。
いま手元に無いけどFPSも60を下回ることは無かったと思う。

**名前は開発中のものです。** · 2010/08/30(月) 20:19:20

ソースあｐれや

**名前は開発中のものです。** · 2010/08/30(月) 20:20:48

かなり複雑な中の一部なのでうｐは無理です。

**名前は開発中のものです。** · 2010/08/30(月) 20:45:42

その言い方だとアルゴリズムの問題じゃないのかなー
計算量が無駄に多いとかさ
変なコード書くと明らか重くなるよ

**名前は開発中のものです。** · 2010/08/30(月) 20:53:57

やっぱり、どう考えてもおかしい。

・オフスクリーンに描画完了
・オンスクリーンに転写

この間に画像が壊れるってなに？

いま気づいたけど、一番最初の書き込み>>624　
>javaで背景をスクロールさせる場合
>
>img.drawImage
>でずらして再描画
すまんが、どんな処理してるのか想像できなくなった。
まさか巨大な背景画像からきりだしてるの？

**名前は開発中のものです。** · 2010/08/30(月) 21:00:46

＞この間に画像が壊れるってなに？
自分も不思議でなりません。

バッファ画像にブロック単位で描いてます。
スクロールする時はdrawImageでそれをずらして描画。
そのバッファ画像をオンスクリーンに転写－ここでオブジェクトや他の画像と合成しています。

**名前は開発中のものです。** · 2010/08/30(月) 21:06:36

>そのバッファ画像をオンスクリーンに転写－ここでオブジェクトや他の画像と合成しています。
ダブルバッファリングになっていない件について・・・。

**名前は開発中のものです。** · 2010/08/30(月) 21:10:13

書き方悪かったです。
合成した後転写‥でした。
だいぶ前のプログラムを今掘り起こしたもんで。

**名前は開発中のものです。** · 2010/08/31(火) 04:02:43

速さが問題だと思ってるのなら、最低限描画時間の計測くらいはやってんだろうな？
それもやらずに配列は速いとか適当ぶっこいてるだろお前

**名前は開発中のものです。** · 2010/08/31(火) 13:08:59

>>643
もっとも基本的なところだから、プログラム見なくても関係なくわかってないとまずいわけだが。
結構大きい物作った割に、言っていることが初心者のようだから、
みんなに突っ込まれてるってわかってる？
少なくともFPSを計測してから、スピードが出ませんって言うべきだな。

**名前は開発中のものです。** · 2010/08/31(火) 19:36:32

崩れるってどう崩れるの？
まさかとは思うがティアリングのことだったりしないよな

**名前は開発中のものです。** · 2010/08/31(火) 19:38:55

メモリ破壊で画像データが入ってる領域を壊してるんだろ

**名前は開発中のものです。** · 2010/08/31(火) 20:15:21

>>646
俺もそれを疑っているんだがｗ

**名前は開発中のものです。** · 2010/08/31(火) 21:18:20

Ｄxライブラリでフライトシュミレーションを作りたいのですが、飛行機を旋回させた時にカメラが真後ろに付けたいのですが、座標の求め方が分からなくて四苦八苦しています。イメージとしてはこんなかんじです。
http://img.5pb.org/s/10mai496251.png

**名前は開発中のものです。** · 2010/08/31(火) 21:28:16

飛行機の角度から円周上の座標を求めるってことでいいのかな？
こことかどうだろう。
http://homepage1.nifty.com/kodayan/java2/data04/apt427.html

**名前は開発中のものです。** · 2010/08/31(火) 21:32:49

普通に
モデルのローカル座標上のカメラの姿勢を定義して
モデルのワールド行列で姿勢を変換すればいいだけじゃ？

**名前は開発中のものです。** · 2010/08/31(火) 21:35:39

DxライブラリのTPSカメラ
例えばここ
http://homepage2.nifty.com/natupaji/DxLib/program/dxprogram_3DAction.html
// カメラの初期化処理
void Camera_Initialize( void )

**名前は開発中のものです。** · 2010/08/31(火) 21:54:43

>>650
探してくれてありがとう。ＸＹＺも一回だけ動かすだけならそれでも大丈夫だと思う。
>>651
行列の概念が私にはありませんでした。申し訳ない。明日休みなので勉強します。
>>652
シフト押しながら十字キーでカメラ回転する所の処理を良く見てみます。
皆本当にありがとう。勉強するよ。

**名前は開発中のものです。** · 2010/08/31(火) 22:45:55

>>641
せめて崩れた状態のスクリーンショットでもないと、どんな現象が起きているのかわかりません

例えばオフスクリーンをタイマ系スレッドで、オンスクリーンへの転写がイベントスレッドで
行われているとかないですか？

**名前は開発中のものです。** · 2010/09/01(水) 20:47:20

2次元でカメラの位置を求めるなら
飛行機の座標を中心とした円があって
半径の長さＲと飛行機の角度θがあれば十分でしょ

Ｒ × Sinθが垂直座標
Ｒ × Cosθが水平座標を表す

半径Ｒは飛行機とカメラの距離
角度θは十字キー入力したら0～359の数でループするように設定
角度を整数(int)にすればカクカク、実数にすれば滑らかになるだろう
半径の長さＲを短くすればズームイン、長くすればズームアウトになる
リアル感を出したければカメラが遅れてついてくるようにすればいい

3次元に拡張しても同じこと
円を二つにして、角度θを水平用と垂直用の二つに分けるだけでいい

行列変換はこういうのをまとめてやってるんだけど
大学数学わからんとホント辛いね

**名前は開発中のものです。** · 2010/09/01(水) 20:54:36

>>655 ほんとうにそれで正しく動作しますか？

**名前は開発中のものです。** · 2010/09/01(水) 21:08:11

座標だけで計算するとカメラの上方向が計算に入ってないがら
宙返りした時にグルンってカメラがひっくり返っちゃって思った通りの動きにならないと思うぞ
行列でやるのが一番楽

**名前は開発中のものです。** · 2010/09/02(木) 05:27:40

.cpp1つと.h2つ、ヘッダファイルの再読み込み防止(#ifndef～#endif)のせいで、後から読み込むヘッダファイルに共通の構造体渡せないんだけど、おまいらこういう対処ってどうやってる？

1.cpp…2.hと3.hを読み込む
2.h　…#include "3.h"を書いてはいるけど読み込まない
3.h　…1と2で使う構造体が入ってる

**名前は開発中のものです。** · 2010/09/02(木) 07:41:31

>>658
1.cppにインクルードするのは2.hだけでいいのでは？

**名前は開発中のものです。** · 2010/09/02(木) 07:47:30

> 2.h　…#include "3.h"を書いてはいるけど読み込まない
これが嘘だな。
普通に書けば読み込むのでここに書かれていないバグがある。
ソース張れ。

**名前は開発中のものです。** · 2010/09/02(木) 14:46:30

>>641の奴はもういいんかな。
自分のソース見て今更ミスに気づいて必死で書き直してるとか。
正しい姿だが。

**名前は開発中のものです。** · 2010/09/03(金) 13:47:02

人に質問するため現状を文章にまとめようとしているうちに
思考回路が切り替わり解決してしまうことはたまにあるな

**名前は開発中のものです。** · 2010/09/03(金) 14:40:22

おれはたまにじゃなくよくあるｗ

**名前は開発中のものです。** · 2010/09/04(土) 12:13:26

それで質問しっぱなしで逃げる奴はうざいな。
質問したのだから、自己解決したぐらい書けと。

**名前は開発中のものです。** · 2010/09/04(土) 14:29:54

>>657
宙返りというか反転したら
飛行機の表裏が逆になるってことでしょ
それを表すには3つの向き(横回転、縦回転、ロール回転)が必要だな

**名前は開発中のものです。** · 2010/09/04(土) 15:48:58

適当な事言うな

**名前は開発中のものです。** · 2010/09/04(土) 16:34:09

飛行機を
一般的なオイラー角で制御すると、ジンバルロックで制御不能になる。
色々な方法で回避手段をとる。

**名前は開発中のものです。** · 2010/09/04(土) 17:40:49

　すみません、何か初心者の基本書となる本はないでしょうか？
お薦めがあったらよろしくお願いします。

**名前は開発中のものです。** · 2010/09/04(土) 17:52:20

>>668
どのようなゲームを作りますか？
２Ｄと３Ｄはちがう、アクションとトランプゲームは違う。　
分野を絞りなさい。

ゲーム製作は凄く広い分野をカバーする。

**名前は開発中のものです。** · 2010/09/04(土) 18:03:08

ロベール

**名前は開発中のものです。** · 2010/09/04(土) 18:51:40

>>669 >>670
どうもありがとうございます。

**名前は開発中のものです。** · 2010/09/05(日) 00:27:53

ゲーム画面（ウインドウ）のサイズってどのくらいにしてますか？
今時はみんなフルHDモニターですかね

**名前は開発中のものです。** · 2010/09/05(日) 00:51:02

んなことない
ターゲットとする画面サイズが大きくなればフィルレートも増大して処理落ちを招いたりする
だれもが最新のPCで遊んでくれるわけではないので
数世代前のビデオカードやノートPCを目線に入れてサイズを決める
今時でもデフォルトはSVGAか大きくてXGAくらいじゃない？
当然高解像度低解像度にも対応できるようサイズ変更は可能なようには作るとして

**名前は開発中のものです。** · 2010/09/05(日) 01:44:48

今ならウィンドウにしても良いんじゃないかな？前から表示ＶＲＡＭに転送しても
問題なく処理してたでしょ。

**名前は開発中のものです。** · 2010/09/05(日) 11:18:36

ネットブックとかあるしやっぱり800x600ぐらいが無難ですかね。
というか、解像度よりはワイドモニターでフルスクリーンにすると、6:4のゲームが横に伸びるのが
皆さんどうやっているのかな～と思いまして。

**名前は開発中のものです。** · 2010/09/05(日) 11:42:21

あれ勝手になる

**名前は開発中のものです。** · 2010/09/05(日) 19:55:07

フォントや画像のサイズが実画面でどのくらいの大きさになるかは
先に計算しておきなよ
大画面を前提に作ると、小さな画面で全く遊べなくなってしまうから

>>672のような勘違いはありがちだけど
例えば一人暮らしの学生が持ってる画面は大きくて20インチ程度だろうし
15インチ画面だって現役なわけで
そういう人を相手にゲームを売ってることを忘れないでほしい

**名前は開発中のものです。** · 2010/09/06(月) 00:05:52

俺主にウィンドウモード使ってて小さい画面嫌だから1024×768で作ってるんだが公開するには大きすぎるだろうか？

**名前は開発中のものです。** · 2010/09/06(月) 02:52:06

>>678
1024 x 768 にしたという事は、
最低でも 1280 x 1024 の解像度を要求しているのと同じかと。

ウィンドウ表示すれば外枠やメニューの分の余白がいるし、
解像度ぎりぎりのサイズでウィンドウ表示する人はまずいないので。

それがどういう結果を招くか次第だと思うよ。
FPS なんかをやる層向けのゲームなら高解像度でも問題無いだろうし。

http://ax2.itgear.jp/sample/report?d=new7&m=dispitem
↑
ゲームという訳ではないけれど、解像度の分布はどこでもこんな感じ。
1024 x 768 という環境が意外と多いことが分かると思う。

**名前は開発中のものです。** · 2010/09/06(月) 03:05:12

㌧
ということはあの大きさでは大き過ぎると言うことか
800×600だと俺のモニタだとちと小さく感じられるんだよなあ

**名前は開発中のものです。** · 2010/09/06(月) 12:14:14

むしろ迷うのはワイド型のウィンドウだよなｗ

**名前は開発中のものです。** · 2010/09/06(月) 22:00:43

全ての解像度に対応すればおｋ

**名前は開発中のものです。** · 2010/09/06(月) 23:58:29

その手間が嫌だから聞いたのであって出来るのであれば最初からそうしてる

**名前は開発中のものです。** · 2010/09/07(火) 00:53:00

>>683
画面のモードを３つくらい搭載してやるのが親切と言うもの

**名前は開発中のものです。** · 2010/09/07(火) 00:57:36

小さすぎる分はユーザー側でディスプレイの解像度を下げれば問題ない。そうまでしてでも遊びたいと思うゲームを作れば問題ない

**名前は開発中のものです。** · 2010/09/07(火) 10:34:44

1024 x 768で全画面に対応すればいいんじゃね
複数画面モード用意するよりかは楽だと思うけど

**名前は開発中のものです。** · 2010/09/07(火) 11:34:59

１００ｘ１００のウィンドウ固定のゲーム作ればいいんじゃねｗｗ

**名前は開発中のものです。** · 2010/09/07(火) 12:14:58

Windows 95 以降で最もウィンドウサイズの小さかったゲームって何だろう？
タスクバー常駐とかは除いて。

プチたねとかも 390 x 280 位で小さいけど、もっと小さいのがありそう。

**名前は開発中のものです。** · 2010/09/07(火) 15:22:03

>>686
それなら楽だ
てか実際に既に対応できてるし
なんだそれで良かったのか㌧

**名前は開発中のものです。** · 2010/09/07(火) 16:44:31

>>688
切り替えモード×2になるけれどRPGツクール2000＆2003は
基本320×240の画面だぜ

**名前は開発中のものです。** · 2010/09/07(火) 17:56:25

>>690
ウィンドウ表示させるとそれなりの大きさになるけど、
なるほど、内部的にはそうなんだね。

そう考えると、低解像度でも結構ゲーム制作はできるのかもね。

ツクール2000だとSFCくらいに見えるもんなぁ。

**名前は開発中のものです。** · 2010/09/07(火) 18:15:06

ファミコンのゲームとか今やっても面白いやついっぱいあるだろ。
解像度とか問題じゃない。

FlashゲームサイトとかもほとんどVGAだぞ。

**名前は開発中のものです。** · 2010/09/07(火) 22:44:33

そら解像度違ってもゲーム性には影響ないでしょうよ
俺が問題にするのはグラの質じゃなくてウィンドウの大きさ
小さいウィンドウでプレイするのは嫌なんだ
出来ることなら最大の大きさ（全画面じゃなく）でやりたい位だが
諸々の手間を考慮してあれ位がベストかなと

**名前は開発中のものです。** · 2010/09/08(水) 16:23:37

>>693
それもゲームの内容によるんだわ
STGは広すぎると全体が把握しにくくてなり、小さいと弾の隙間を抜けるのがやりにくい
そして最適な大きさは敵のルーチンや弾数でかなり違うし、プレイヤーによっても
使ってるモニターによっても全く変わる
だからキミの感じるベストの大きさなんて自分の感覚自分の環境の話でしかないことを
よくキモに命じておいた方が良い

**名前は開発中のものです。** · 2010/09/08(水) 16:32:00

>>694 最後の2行が無ければ評価した

**名前は開発中のものです。** · 2010/09/08(水) 16:44:52

だから自分の環境でのベストの大きさっていう意味でいったつもりだったのだが
あとＳＴＧで広すぎるって関係なくね
市販とか家庭用とかって全画面が普通だし

**名前は開発中のものです。** · 2010/09/08(水) 19:57:04

家庭用はTVからかなり離れてやるからな、広すぎるのはかなりスコアに影響する
自機の周りに集中して避けてると遠いところの打ち洩らしが多くなりやすい

**名前は開発中のものです。** · 2010/09/08(水) 23:23:25

そういうのは自分で基準を作らないといけない
解像度が大きくても、枠をつければゲームフィールドは小さくできる
人間が標準的に思考できる視野は何センチ平方までで、それは想定した視聴距離、画面サイズではどうなる
ということを考える

昔はいちいちそんなの考えなかったんだよ。320×240や640×480ごときでは適当なサイズで素材描いても面白くなった
高解像度の時代になると、素材が小さいと見えない、わからない
素材が大きいと処理が指数関数的に重くなる、というジレンマを抱えるハメになった
ゲームの世界では、大は小を兼ねないし、小は大を兼ねない

**名前は開発中のものです。** · 2010/09/08(水) 23:51:46

解像度とは別で、2Dゲーのキャラクタをどんな大きさで書くかって問題もあったよ
古い話になるけど、SFCの悪魔城1作目はキャラを大きく書く分視界が狭く、
しかもムチを8方向に振れるためにほとんど画面全体をカバーできてしまい、
サブウェポンの価値が激減してた

**名前は開発中のものです。** · 2010/09/09(木) 22:36:52

>>649
姿勢を表す3軸の単位ベクトル(dx,dy,dz)を持たせておいて、
これらのベクトルで任意軸回転をすればよいかと思います。

// 初期化
dx = D3DXVECTOR3( 1,0,0 );
dy = D3DXVECTOR3( 0,1,0 );
dz = D3DXVECTOR3( 0,0,1 );

float r; //回転させる角度
D3DXQUATERNION q;
D3DXMATRIX m;
D3DXVECTOR3 v;

// Y軸回転の場合
D3DXQuaternionRotationAxis( &q, &dy, r ); //ｸｫｰﾀﾆｱﾝを生成する
D3DXMatrixRotationQuaternion( &m, &q ); //ｸｫｰﾀﾆｱﾝを回転行列に変換

// 他の2軸を回転・正規化する
D3DXVec3TransformCoord( &v, &dx, &m );
D3DXVec3Normalize( &dx, &v );

D3DXVec3TransformCoord( &v, &dz, &m );
D3DXVec3Normalize( &dz, &v );

**名前は開発中のものです。** · 2010/09/10(金) 14:25:08

>>699
そういう話ってたくさんあると思うけど、実際にプレイしないと分からないよなあ。

**名前は開発中のものです。** · 2010/09/10(金) 21:38:29

実際にプレーしてから云々も大事だけど
なるべく設計段階で潰しておかないと地獄を見るよ

例えばエクセルで正方形のセルを作って、１つ20×20ピクセルと仮定して並べる
800×600なら横40セル、縦30セル作る
そこに文字やイラストを入れるとゲーム画面が作れるので、プログラム書かなくてもシミュレートできる
キャラがでかすぎてマズイ、とかはこれですぐ分かるし
マップ作りやステージエディットもこれで良い

3Dゲームはどうするか？
レゴブロックや紙粘土、紙細工などで手作りする。人形遊びの要領でキャラクターを作って動かしてみる
カメラをシミュレートしたければ、携帯電話のカメラに映して眺めれば良い
3Dの素材とポリゴンを作る労力に比べれば、遥かに少ない手間で色々試せる

こうやって色々なゲーム案を作って、一番良さそうなデザインを作っていく
思いつきでプログラムを作ってしまうと労力がかかりすぎるし、仕様変更が難しくなるので
先に計画をきちんと練ってから始めると良い

**名前は開発中のものです。** · 2010/09/10(金) 22:26:49

メッシュの衝突検出をボールなどの図形の集合として検出したいのですが、
この手法について書いてある本やサイトはありますか？

**名前は開発中のものです。** · 2010/09/10(金) 22:30:42

>>703
3Dの球と球の衝突検出の方法がわからないのですか？

**名前は開発中のものです。** · 2010/09/10(金) 22:51:26

球と球はわかるのですが、
メッシュデータの形状の通りに球をボクセル化？する
方法がわかりませんです。

**名前は開発中のものです。** · 2010/09/11(土) 11:14:08

物理ライブラリのBulletのメリットとデメリットを教えて下さい。

**名前は開発中のものです。** · 2010/09/11(土) 16:03:35

開発元に聞きなさい

**名前は開発中のものです。** · 2010/09/12(日) 06:46:26

そこそこのボリュームのゲームが完成したんですが、
普通は完成したゲームってどうやって公開するのが良いんでしょうか？
自分が思いつくのは個人サイトで公開するかコンテストか何かに応募するぐらいでしょうか。
ちなみに内容は２Ｄアクションで開発環境はＣ＋＋です。

（「良い」って言う意味は、見てもらえる人数や、その後の発展性とか、金とか、総合的な感じです）

**名前は開発中のものです。** · 2010/09/12(日) 09:18:23

モノによる
洞窟物語みたいな凄いのなら自サイトだけで公開しても人気になるし、
人気ゲーをパクっただけみたいな大したことないゲームならどんな画策してもその後の発展性なんかない
当たり前だが、コンテストに出しても入賞しなきゃ金にならんだろ
取らぬ狸の皮算用をしても仕方ないわ

**名前は開発中のものです。** · 2010/09/12(日) 12:34:07

まぁただ公開するだけじゃどうにも人は来ないわな
フリーゲームでも宣伝とかしないと

**名前は開発中のものです。** · 2010/09/12(日) 13:31:12

今時フリーでゲーム公開したぐらいじゃ誰もくいつかんよなー
よっぽど面白いならいざしらず、話題の一つも無ければ公開しても消えるのみだ

**名前は開発中のものです。** · 2010/09/12(日) 13:35:42

今が一番フリーのゲーム熱いと思うが、
動画でプレイをアップしたり勝手にもりあがってくれる

**名前は開発中のものです。** · 2010/09/12(日) 13:42:14

そうやって宣伝とか（自演も多いだろうし）やって地道にプロモしなきゃなんだよね

**名前は開発中のものです。** · 2010/09/12(日) 14:00:29

熱いもクソも、フリゲ乞食が盛り上がっても変なクレーマー集団みたいなのが形成されるだけで良いことなんもないぜ
例えば機能を追加した豪華版をDL販売しようとしただけで発狂してアンチになるようなどうしようもない乞食層
そんなやつらに「是非プレイしてもらいたい」と思うほど極端に卑屈な人間でない限り、フリゲ公開はストレス溜まるだけ
大きな意味では将来の何かにつながるってこともない
同人で小遣い稼ぎが「将来」として価値があるなら、同人活動の宣伝にフリゲは使えるが、費用対効果が見合ってないｗ