【初心者】スレを立てる前にココで質問を【Part15】
>>939 ・こみっくめーかー
・LIVEMAKER
このあたり。他にもあるかもしれんが。
ただし、特にコミメはユーザーから結構敬遠されるからその辺注意。
941 :
名前は開発中のものです。:2007/12/28(金) 14:58:52 ID:nv4qpEWF
>940
情報サンクス!
ぶっちゃけコミックメーカーで作られたゲームはみんな同じに見える
RPGツクールみたいなもんか
ぷよぷよとかテトリスなどの落ちゲーで自動落下の速度ってPCの性能に左右され
ますよね?
この速度をなんとか同じにする方法ありませんか?
それとも微小な差なので気にする必要ないのでしょうか?
>>944 テトリス程度なら、速度はリフレッシュレートに依存します。
ウィンドウモードと仮定した場合、リフレッシュレート60Hzで遊んでいた時と比べて、
75Hzで画面を更新している環境で遊ぶと1.25倍の速さで落ちてくることになります。
適当にタイマー付けてやれば?
PCの能力やリフレッシュレートに左右されるプログラムを組んでしまえるのがある意味凄い。
948 :
名前は開発中のものです。:2007/12/28(金) 20:43:35 ID:gjvoMIsD
自機が壁に当たると終了するゲーム(平たく言えばイライラ棒)を
作ってるんですが曲線(手書き)の壁との当たり判定方法がわかりません。
今のところ壁の座標をすべて保持して自機との距離で判定しようかと
考えているんですがその方法であってますでしょうか?
もっと良い方法があれば教えてください。
直線やスプラインにするとか
昔だと障害物と自機の衝突判定用マスク作って全ピクセルで&取って0以外の場所があったら衝突ってようなやり方してなかったか
951 :
948:2007/12/28(金) 21:13:26 ID:gjvoMIsD
ご回答ありがとうございます。
>>949 手書きのコースという制約がありまして悲しいかなそれができんです。。orz
>>950 ウホッ!目からウロコ!早速それで試させもらいます。
952 :
名前は開発中のものです。:2007/12/28(金) 23:53:00 ID:NMo2lkZ4
スクリプト系の言語でゲーム向きなものって、HSP以外にでてきたの?
DXライブラリを導入したC++とか
シンプルで世界観を選ばないキャラクター素材(所謂ホコグラ)サイトを知ってる方がいらっしゃいましたら教えて下さい
FSMはぽっちゃりすぎで合わず、ツクール準拠素材はライセンス的にアウトなので…
>>952 pythonとかASとか…いくらでもあると思うけど
ギャルゲの体験版は文字のみで何バイト程度が適正でしょうか?
今年もゲーム完成せんかったなぁ・・・・
参考書のサンプル写してるだけで何一つ達成感のない気もする
移したサンプルって何か改造しないか
そりゃキャラ絵とかは自分で描いたけどさ・・・・
プラグラム的にはそのまんまだし改造してもエラーでまくるから
結局手間のかかるツクールとしてしか使えてない気がする
君望くらいでOK、とでも言えばいいのか(w
>>955 音とか絵以外でってことか?
質問の意図がよくわからん上にギャルゲといっても体験版だけで1G超えるボリュームのもあるしなぁ
>>958 自分なりに処理を追加してみるとか
コードを自分流に書き換えてみるとか
でも、エラーを何とかする方が先かもな
C++でアニメーションのサンプルソース打ってるが難解な上に退屈すぎる・・・・・
フレーム数がどうとか回転描写だとかは一回作ったらあとは使いまわしでも問題ないよね?
ジャンプしたらこのアニメーション、死んだらこのアニメーション・・・・って具合で
stgならそんなこと考えなくていいよいいよ
何故そうしなければならない?
966 :
名前は開発中のものです。:2007/12/31(月) 00:06:24 ID:nSrmQKp9
967 :
名前は開発中のものです。:2007/12/31(月) 00:07:06 ID:nSrmQKp9
>>964 いや、なめらかにキャラが動くゲームが作りたいんだよ
ジャンプとかしゃがみとかってアクションのたびにあの長ったらしいアニメーション設定をする必要があるのか
気になってるんです
しりあいにGUIのアニメーション作成ツール作ってる人はいた気がする
なんだかよくわからないけど普通は関数化して使い回せる範囲で使い回すのが一般的なわけだが
971 :
885:2007/12/31(月) 13:55:02 ID:0OrXFjz2
>>885で空の表現について尋ねた者です。
>>891 また来ました。
で、スカイボックス、スカイスフィアともに試してみたのですが、どちらも問題ありで、
結局、板ポリに視線角度に応じて空テクスチャを貼るのが一番良く見えましたw
とくに星が描かれているだけの宇宙空間では効果的でした。
スカイボックスやスカイスフィアで空を描画している
>>69のゲームやエースコンバットシリーズが
なぜあんなに自然にできているか不思議です・・・。
横スクロールアクションを作る際、画面下に地面を表示したいんだが
簡単に言えばどうすればいい?
テキストエディタで画面半分を地面にしてそこに地面判定?
ゲーム作るために勉強中。
勉強の進み具合を時々書き記してモチベーションを保ちたい。
この目的にふさわしいスレはどこ?
ホームペ-ジでも持ったら?
キャラはこんな感じでステージは~~みたいにページを足していく
最後には作品公開も出来るし
>>974 前に自分もそれを考えたのですが、
どういうワケかホームページを作りたいという気持ちがわかないのです。
自分でも何故だかわからないです・・・。
>>975 あそこは自分で作れる人達が多そうで、それに対し
自分はまだ勉強してるだけなので、どうだろうと思ってましたが、
やはりそこしかないかもしれませんね。
俺がこっそり・・・スレとかステフと一緒に・・・スレも考えたけど
これらは微妙に違うような気がしたし・・・。
レス参考になりました。どうもでした。
みんなそんなもんだぜ
漏れも作りながらの勉強だから、名前付けずに捨てカキコとSS貼ってる
本気で作る気で軌道に乗ってきた奴は単独スレ立ててるから気にすんな
>>971 >で、スカイボックス、スカイスフィアともに試してみたのですが、どちらも問題ありで
エスパーレスになるが
雲込みのテクスチャを単純にスフィアやボックスにマッピングして描画する場合
テクスチャ解像度を十分にとらないと粗さが目立ってしまうかもだ
一昔前だとテクスチャメモリ消費量を抑えたまま見栄えを良くするために
低周波成分と高周波成分に分離して、例えば
低解像度テクスチャ(大気色)とデカールテクスチャ(雲など)に分けたり
頂点カラー(大気色)+デカールテクスチャ(雲など)に分けたりして、その上で
ブレンドするのが定石だったが、最近は512MBとか1GBのビデオメモリを
積んでるみたいだから、かなりどうでもいい話かもだ
979 :
885:2008/01/01(火) 04:05:26 ID:+SN1hRt4
>>978 >低周波成分と高周波成分に分離して
なるほど。
たしかにエースコンバットはそうしてますね。
参考になりました。
ありがとうございました。。
サンプルゲームの中身みて思ったが
ひとつの画像ファイルにキャラの動き全部収まってる。
これはBMPで描いたキャラ絵を結合してひとつの画像にするソフトがあるの?
あとジャンプや攻撃モーション、それぞれひとつの画像を使ってるの?
ジャンプアニメーションならジャンプ用画像を読み込む…とか
結合したければその程度自分で作れよ。
ゲーム本体を作るのに比べたら全然大した労力じゃないんだから。
別に結合方法が知りたいわけじゃない
ゲーム作ってる人からしたらそういう手法が主なのかってのが聞きたいだけなんだがな
>これはBMPで描いたキャラ絵を結合してひとつの画像にするソフトがあるの?
これはどう読んでも手段を訊きたいようにしか取れないけどな。
ちなみに俺は全部手作業でやってる。
格闘ゲームみたいに複雑か形で膨大な量があるわけじゃないからこれで充分。
ファイルは1キャラ1枚にまとめてる。
いちいちモーションごとに画像分けてたらいろいろ大変だ。
言い方が教えてくんっぽかったのは謝る
とりあえず参考になった、サンクス
STGゲームには縦スクロールや横スクロール等といった種類がありますけど
スクロールの違いによるメリットやデメリットはどんな物がありますか?
縦スクロールは敵がプレイヤーと正面切って対峙する為、横スクロールに比べて対決している感が強く出るってな事を昔どっかで見たように思う。
・縦
縦は良くも悪くも作りやすい
背景が上から見下ろしだから背景演出が横よりやりにくい
ドット絵が後ろ向きだから数は少なくていいけど後姿作りなれてない人もいる
・横
横は空と地面という概念が必然的にできるから戦略性が出る
背景を遠景近景で表現できるからウマー
縦STG原理主義者がいるかもしれない
私見だが。
一般にモニタは横に長いので、横タイプなら幅広く使える(自機の前方が広くて見やすい)。
横タイプだと、背景が「空」「地面」に分かれるし「手前の背景」「奥の背景」にも分かれる。
その分演出に幅が出るが、当然作る労力は膨大になる。
縦タイプだと、場合によるが背景絵も使いまわしがきいて楽。
キャラ絵を描くのも縦がたぶん楽だろう。
例えば戦闘機のようなキャラを描くとして、左右に動く時に「機体が傾いたパターン」を作る場合
縦タイプなら、一つの傾きパターンを書いて左右反転させればいけるが、
横タイプなら上下パターン両方描かなくてはいけない。