1 :
デフォルトの名無しさん :
2013/04/21(日) 15:41:16.06
モルピグ
tes
ここって
>>1 以外にテンプレないの?
28スレ目ともなればあっても良さそうだが
テンプレも作られないような存在価値皆無のスレです ごめんなさい
モルピグ厨の巣窟
7 :
デフォルトの名無しさん :2013/04/24(水) 21:29:35.73
mainのループの呼び名は メインループでいいですか?
別にmainに無くてもいいけど
>>7 C++とかは知らんけど、iOSとかのObjective-Cはイベントループと呼ぶ
まあメインループとか描画ループとか呼んでたな。
DirectXSDKって2006年だか2008年だかのが最新!? はっきり覚えてないけど、この間SDKを最新版にしようと思って探したらそれくらい古いのしか見つからなかった
DirectXもXNAもオワコン
質問です。 モルピクの通信データの圧縮ってどうすればいいのでしょうか? 現在、プレイヤーの数が増えてきたため、プロバイダの帯域制限に引っかかりそうでヒヤヒヤしています。 アップデートして無駄なところは極力減らした(後に拡張することがあってもいいように用意していたヘッダを8バイトから4バイトに減らすなど)のですが、 そろそろ限界です。 プロバイダは変えるつもりですが、まだどこにするかも決まっていないので、変えるまでに3か月くらいはかかると思います。 それまで何とか乗り切りたいのです。
またモルピグさんかw そんな一般性ゼロの単語誰もわかんねーよ。
17 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/04/27(土) 19:09:17.98
>>15 どういうプロトコルかにもよるけど
1バイト単位で調べて同じ値が連続してたらまとめるとか
そういうのしかないしんじゃない
モルピグって用語使ってると特定されて嫌がらせ受けると思う
既に動いているのにそんな抽象的な質問しても 的はずれな回答にしかならん
流行ってたころならともかく、ソーシャル全盛の今の時代に そこそのMMO運用してるならとっくに特定されてもおかしくないはず というわけで実際はモルピグ名乗るのもおこがましいほどのカスか脳内の話だろう
23 :
15 :2013/04/27(土) 23:40:00.37
>>18 ありがとうございます。
それでどの程度圧縮できるか分かりませんがやってみます。
>>19 無駄な部分はかなり修正したのでほとんどないはずですが・・・もう少し調べてみます。
ゲームの強いセーブデータを配布したりできないように暗号化したいんだがいい方法ない?
>>24 他のPCで使えないようにしてしまう。例えばPC固有のデータを確認するとか
NICのMACアドレスあたりを埋め込んでおくのが手軽かな 今時NIC無しのパソコンなんか無いだろうし
イーサ設定なんかいくらでも偽装できる
配布する側はともかく、そんなのを落としてくる人がいちいち偽装するかな
それを言ったら セーブデータを落としてくるほど価値があるクリア特典のあるゲームor金が絡むMMO→偽装に対しても頑健である必要がある それ以外→別にセーブデータ出回ってもいいし。自分の労力に見合う苦労させたいっていう開発側のオナニーじゃない? コスパ的にも楽してストーリーだけ楽しみたいってユーザーのプレイスタイルを縛り付ける意味はないと思う
>26-28 MACアドレスって調べてみたけどこれでいいわ NICのMACアドレスを埋め込んであるかどうかすら知らなかったら MACアドレス偽装もしようがないだろ そこまで調べあげて偽装するような奴には破られてもいいわ
セーブデータがロードできないバグに悩まされる未来が見える・・・
お手軽な方法としては否定するわけじゃないけど o 正規ユーザーに「個人用途においても他のPCにセーブデータの移行はできない」と明記する必要がある o PCの修理で基盤交換するとロードできなくなる o MAC検証を回避するexeパッチが出回った時点でカジュアルユーザーにも無力になる …ぐらいは想定した上で導入しなよ
>>30 そこまで調べあげて偽装するような奴は、破った後に、
誰でも簡単に破れて簡単に改造できるスクリプトやツールをばらまくよ
こんなスレで聞くくらいだし、フリーソフトでちょっとズルをやりにくくするくらいの意味合いじゃないのかな? 改造ツールがバラまかれる規模ならもうちょっと別の対策を考えた方がいいかもね
>>33 >>15 のような奴もこんなスレで訊いている現状、
求めている質については回答者の方からは何とも言えんので、
一応そういうことも想定できるよと、可能性を述べました
今回はそこまで求めてなくても、「なるほど、そういうこともあるのか」と
頭の片隅にでも入れておいてくれたら、それでいいよ
36 :
35 :2013/04/28(日) 12:33:01.63
MACを埋め込むんじゃなくて、MACをキーに暗号化すれば検証回避とかは出来ないんじゃね?
いや、だからさ
早く乳揺れ見せて
何言ってんだお前
41 :
デフォルトの名無しさん :2013/04/29(月) 03:32:01.91
なんか作ろうぜ
最近のパソコンなら家電量販店に売ってるやつでもシェーダが使えると思ってていいの? 訳:ここ2年以内に発売されたパソコン(デスクトップ・ノートを含むが、タブレット・ネットブックを除く)であれば、 家電量販店で販売されているものの80%以上でシェーダ5.0を利用可能ですか?
>>42 IvyBridge SM5.0 (2012/04〜)
SandyBridge SM4.1
CPUがSandyBridgeでビデオカード積んでないPCがどれくらいの割合か分からん。
44 :
デフォルトの名無しさん :2013/04/30(火) 21:36:44.45
Win32APIのみで3Dゲームのライブラリって作れる?
DirectX を使わないとかいう訳のわからない主張でない限り、Yes
わけわからなくないよ底辺の俺でさえDIBで3Dレンダリングをスクラッチから組んだことあるし
それは3Dゲームではない別の何か
>>44 テクスチャ無しでよければ、
頂点色有りのトライアングルが描画できる関数があったはずだからそれ使えば?
たしか、GDI+か何かの関数だったと思う。
頂点色によるグラデーション付き塗りつぶしも、 3D空間で真面目にやるならパースペクティブコレクトが必要なんだがね
まったくだな 3Dもそうだけどライブラリに頼り切ってアルゴリズムの書けない連中だらけになった
51 :
44 :2013/05/01(水) 22:30:41.78
DirectXを使わないと現実的じゃないってことでOK?
53 :
デフォルトの名無しさん :2013/05/04(土) 00:21:57.88
お前らはゴールデンウィーク中にどんなゲーム作る?
ゲームじゃないが水の物理シミュ
SPH法難しい
みんなそれなりに充実しているようだね 俺もなんかしないとなぁ
エリアレベルでの半透明のリアルタイムレンダリングってどうやるの? RPGの戦闘でコマンドを選ぶところで、 「魔法」を選んだら、次は魔法の種類を選んで、最後に対象の敵を選ぶ 古典的な入力方法。 但し、「魔法」コマンドを選んで次の魔法一覧が出ても、 「魔法」コマンドを含むエリアが消えずに半透明グラデーションで残したい。 攻撃 ファイア 魔法 サンダー アイス ↑これが、「魔法」コマンドを選んだ後の魔法の種類を選択するときの状態。 「攻撃」「魔法」と書かれてるエリアは消えずに、 そのエリアは文字も含めて右から左へ半透明でフェードアウトした状態で描画したい。 そこからサンダーとか適当に魔法を選んだら今度は、 ファイア 盗賊A サンダー 盗賊B アイス ↑みたいに対象の敵を選択できる状態になるけど、 このときも「ファイア」「サンダー」「アイス」を含むエリアは完全には消えずに 右から左にフェードアウトした状態にしたい。 しかも各選択時にはパッと変わるのではなくて、スライドするように変えたい。
環境はWindows7でDirectXは9で開発してる。 つーか説明が分かりにくいから画像にするわ。
1.シェーダを書きます 終了
>>57 リアルタイムでオフスクリーンに文字をレンダリングして、
それをテクスチャにしてビルボードをバックバッファにレンダリング。
その際に頂点カラーとしてアルファ値を設定し、アルファブレンディングを有効化しておく。
シェーダーがまともに使える以前は、たとえばこんな風にして実現していた。
62 :
uy@右翼 :2013/05/05(日) 11:01:37.53
最近世界情勢の事調べてんだけどさあ そこから推察すると日本のITが全体的に失墜し始めた理由は 韓国と台湾と中国にそれぞれ日本の技術と市場を売ったからだな 韓国にはソフトウェア技術 台湾には基盤技術 中国にはその両方ってところか 売った理由は戦後賠償 日本経済が伸びすぎたから米国から待ったをかけられて 「市場」そのものを売るといいか明け渡すように要求されたものと思われる 日本の技術はたしかに最高峰なんだけど、中小が、だから通りで虚業化してるんだ そしてアニメ関係がかろうじて生き残った 理由は簡単 日本人以外には出来ないから 真似が出来ない。神風と同じだね 日本は、日本以外でも出来る産業はいくらでも奪われるような立ち位置なんよ 中韓からの撤退につきこれから東南アジアにもおそらく「市場」そのものを売りにいく だからさ、他国に真似されない産業を作っていかないと生きていけない イプシロンロケットや10式戦車くらいになると 技術を奪われるにしてもイギリスとアメリカ相手くらいでそっちでも極秘扱いになるはずだからまだいいとしても 発展途上国に対し金だけじゃなくいろんなものを売ることを要求される日本は ありきたりな産業で生きてる中小企業は政治家の指先ひとつでどんどん生存厳しくなっていく これが俺様の推察した、日本のIT不況の根幹にあるものだ
読んでないけど遠目にもスレチとわかるのでやめてください
>>60-61 ありがとう。
シェーダってそんなに便利なものなのか。
ちょい勉強してみる。
キャラの回転移動伸縮の指定は絶対指定と相対指定どっちでやってる? 絶対指定だと回転移動伸縮指定の指定順序を記憶しないと 回転だけリセットとか難しいよね(例:回転して移動して正面を向かせる) かといって相対指定だと蓄積誤差とかが気になる みんなどんなやりかたしてる?
蓄積誤差は気にせずにやってる
じゃあなんも考えずに変換行列にどんどんかけちゃって行けばいいかな
気になるとか、そういう感情はとりあえず脇に置いておいて(まぁ時には直感も大事だが)、 どのようなシーンで、どの程度の誤差が蓄積して、どのような問題が起きたか、 という視点で考えたほうがいいと思う。 実際に問題が起きるのなら、その誤差を減らす方法か、シーンを変えることを考える必要がある。 問題が起きない程度の誤差なら、誤差が蓄積している事だけ覚えておいて、あとは無視できる。 趣味でゲームを作る場合、作る前に悩んでも仕方がないし、意味がない。 これから起こるかもしれないことに対して対策を考えても、 その対策が有功か検討するのに結局作ってみなければならないのだから、 それなら作ってみて問題が起きてから、それに対する対策を考える方が建設的だ。
>>68 ライブラリの設計なので後で変更するのがきついんすわ
最終的にはテストコード書いて検証する必要あるけど
とっかかりとして、普通どっちでやってるのかなと
>>69 そんなのキャラの動かし方やシーンによって変わるよ。
3Dのフィールド上に立っているキャラをプレーヤーのコントロールで歩かせる場合は、
相対値で十分だし、その方が自然だ(基準値をどこかに設けるほうが不自然)。
たとえば 5秒前進した後で5秒後退し、画面上の見た目で最初と数ドットずれていたとして、
プレーヤーはそれに対して怒ったりはしないし、気づかない人が大半だ。
(そのズレがゲーム性に関わるのなら問題だが。例えば横スクロールアクションとか)
でも、キャラを中心に一定の半径をもってエネルギー流が回転するシーンの場合、
回転するごとに誤差のせいでその半径がどんどん広がっていったらおかしい。
こちらは、基準値となる座標や角度を設けて、相対的ではなく絶対的な回転角度から計算すべき。
だから、ライブラリなら両方使えるようにしておくのがいい。
一方でもう一方を実現するなんて不自然なことをプログラマにさせたくないのなら、ね。
両方かーめんどうだな 回転移動伸縮回転移動伸縮…したあとで移動だけ絶対指定した場合 現在の変換行列に移動を打ち消す行列かけてから新しい移動行列かけるわけだよな 相対指定の履歴を全部で保存しておいて逆順に逆行列掛けてくのがいい?
>>71 すまんが、言いたいことがよく分からん。
相対指定も絶対指定も指定するために必要なものは変わらんと思うが。
今回施す変換行列と、変換の基準となる行列、この2つを指定すればいい。
相対指定なら、基準となる行列とは前回まで積み重ねた結果の変換行列のこと、
絶対指定なら、基準となる行列とはなにか適当な変換行列のこと(キャラの中心とか、ワールド座標系とか)。
> 回転移動伸縮回転移動伸縮…したあとで移動だけ絶対指定した場合
そのような要望をするのは、そのライブラリを使うプログラマ側だよな。
なにを絶対指定の基準とするかはそのプログラマにしか分からん。
であれば、基準となる変換行列はプログラマ側に指定させるしかない。
> 現在の変換行列に移動を打ち消す行列かけてから新しい移動行列かけるわけだよな
それは絶対指定にならないのでは? 打ち消す行列をかけた時点で誤差が蓄積する。
> 相対指定の履歴を全部で保存しておいて逆順に逆行列掛けてくのがいい?
絶対指定(を以後続けること)において、記憶させておかなければならないことは、
今までの変換の履歴ではなくて、基準となる変換行列の方だと思うが。
並進変換(平行移動)だけ絶対指定して、回転変換などは相対指定したいのなら、
並進変換の基準となる変換行列だけプログラマに保存してもらえばいい。
逆に相対指定の場合は、基準となる変換行列は今までの変換の積み重ねだが、これはライブラリ側で把握可能だ。
今までの積み重ね全てではなく、前回の最終計算結果だけ保存しておけばいい。
インターフェースとしては、基準となる変換行列を null 値で指定されたら、
相対指定されたとみなして、最終計算結果を基準となる変換行列として計算すればいい。
そうすれば、相対指定と絶対指定でインターフェースを分ける必要がなくなる。
>>72 認識が食い違ってる
基準となる変換行列は常に単位行列で
・平行移動絶対指定⇒回転・拡縮状況はそのままにキャラを"変換行列が単位行列のときの位置"に平行移動しそこから絶対指定された量平行移動させる必要がある
・回転絶対指定⇒平行移動・拡縮状況はそのままにキャラを"変換行列が単位行列のときの姿勢"に回転しそこから絶対指定された量回転させる必要がある
・拡縮絶対指定⇒平行移動・回転状況はそのままにキャラを"変換行列が単位行列のときの大きさ"に拡縮しそこから絶対指定された量拡縮させる必要がある
それとプログラマ側には行列演算を意識させたくないので
glTranslateみたいなIFだけ用意してる
>>72 追記
[移動|回転|拡縮]相対指定を繰り返したあと[移動|回転|拡縮]絶対指定することもある
絶対指定って座標じゃないんだ
>>73 なんとなく意味がわかってきた。
それなら、スケーリング変換行列と回転変換行列と並進変換行列、
それぞれを保存するバッファを用意すればいい。
Msb : スケーリング変換行列を保存するバッファ
Mrb : 回転変換行列を保存するバッファ
Mtb : 並進変換行列を保存するバッファ
今回施すそれぞれの変換を次のものとする。
Ms : 今回施すスケーリング変換行列
Mr : 今回施す回転変換行列
Mt : 今回施す並進変換行列
全ての変換で「相対指定」するのなら、新しいベクトル V' を
ベースとなるベクトル V から次のように計算する。
Msb = Ms * Msb
Mrb = Mr * Mrb
Mtb = Mt * Mtb
V' = Msb * Mrb * Mtb * V
もし、回転換のみ「絶対指定」するのなら次のように計算する。
Msb = Ms * Msb
Mrb = Mr
Mtb = Mt * Mtb
V' = Msb * Mrb * Mtb * V
つまり、相対指定するなら、バッファに新たな行列をかけて計算を積み重ねる。
絶対指定するなら、バッファに新たな行列を代入する。
(これが、変換を打ち消す行列をかけることと同義だ)
77 :
76 :2013/05/08(水) 12:54:12.60
>>73 すまん、
>>76 の掛け算の順が逆だった。
スケーリング変換行列からかけないと結果が無茶苦茶になるな。
正しくは、
全ての変換で「相対指定」するのなら、新しいベクトル V' を
ベースとなるベクトル V から次のように計算する。
Msb = Ms * Msb
Mrb = Mr * Mrb
Mtb = Mt * Mtb
V' = Mtb * Mrb * Msb * V
もし、回転換のみ「絶対指定」するのなら次のように計算する。
Msb = Ms * Msb
Mrb = Mr
Mtb = Mt * Mtb
V' = Mtb * Mrb * Msb * V
いきなりライブラリ作ろうとするからだろ 「この程度の蓄積誤差なら問題ないな」とか 「このくらいになってくるとヤバいな」とか もうちょっとノウハウを蓄積させてからのがいいって
参考までに俺がゲーム用ライブラリを作るときの手順は、 1.まずその分野のゲームを作る 2.将来ライブラリ化する予定の部分は別ファイルにして#includeするだけで使えるようにして作っていく 3.マジックナンバーを削ってマジックナンバーだった部分は初期化などで設定できるようにする 4.それをincludeするだけで使えるか確認するために同じ分野の別ゲーを作る 5.前回では見えなかった特定のゲーム依存の部分を汎用できるようにブラッシュアップ 6.ライブラリ化 7.その頃にはその分野のゲームを作るのに飽きている 素人でもこの手順でやれば作れる もちろんプロは設計から入るからこんな手順踏まないけど
プロはしっかり設計してしっかりテストして 思いつきの仕様変更にしっかり振り回されて 大人の都合でプラットフォーム変更されてしっかり泣く
>>77 ありがとう。
そんな感じで書きはじめてみた。
DirectXのZバッファが思い通りに効いてくれません。 以下のようにA〜Eのテクスチャをスプライト->Drawで描画しています。 A 0.8f B 0.4f C 0.4f D 0.2f E 0.1f 基本的にZバッファは効いてくれているのですが、ところどころ問題が起きます。 〇Bを描画するとCが最全面にきます。 〇Cをコメントアウトすると、Eが描画されなくなります。 〇CにAより深い値を設定してもAの背面にはならず、Dの背面にはなります。 AutoDepthStencilFormatはD16と、D24S8の両方で試しましたが同じでした。 Draw直前で引数に与える位置座標(D3DXVECTOR3)のz成分は上記のままだったので問題ありませんでした。 毎フレーム描画前のデバイス->Clearには2番目の引数でZバッファをクリアする旨、クリアは1.0fまでする旨書いてあります。 DirectXは9使ってます、OSは7、言語はC/C++です。
さらに不可解な現象が発生しました。 問題の切り分けをさらに細かくしようとして変数を宣言していたところ、 DとEの間でD3DXVECTOR3 test;と宣言するとDとEが描画されない事案が発生。 Dより前に宣言しても同様でした。 描画自体は別のクラスに投げていて、そのクラスにはそのtestは渡していません。 宣言するだけでEが描画されなくなります。 グローバルにtest変数があるわけでもなく、testを他の絶対に使用していない名前に変えても同様の現象になります。 これも上記の不具合に関係ありそうです。 ■D、Eが問題なく描画される場合 D3DXVECTOR3 test;//グローバル・ローカルに関わらずプログラム中で1回も使ってない名前 Draw_DE(); BOOL Draw_DE(){ D描画 E描画 return TRUE; } ■D、Eが描画されなくなる場合 Draw_DE(){ D3DXVECTOR3 test;//グローバル・ローカルに関わらずプログラム中で1回も使ってない名前 D描画 E描画 return TRUE; )
解決しました・・・が、ってか、え??????
解決後の検証結果、スプライト->Draw()に渡しているRECTやD3DXVECTOR3変数が、スプライト->End()、もしくは、デバイス->EndScene()以前に破棄されると
>>82-82 の問題が発生するようです。
スプライト->Draw()に渡していたそれらの変数がローカル変数で、スプライト->End()、デバイス->EndScene()の前に破棄されていたため発生した問題のようです。
■問題が発生する場合
デバイス->Clear(引数省略);
デバイス->BeginScene();
スプライト->Begin();
Draw_Test();
スプライト->End();
デバイス->EndScene();
デバイス->Present(引数省略);
BOOL Draw_Test(){
D3DXVECTOR3 pos , cen;
RECT rc;
(変数に値を設定)
スプライト->Draw( テクスチャ , &rc , &cen , &pos , 0xFFFFFFFF );
return TRUE;
}
■問題が発生しない場合
D3DXVECTOR3 pos , cen;
RECT rc;
デバイス->Clear(引数省略);
デバイス->BeginScene();
スプライト->Begin();
(変数に値を設定)
スプライト->Draw( テクスチャ , &rc , &cen , &pos , 0xFFFFFFFF );
スプライト->End();
デバイス->EndScene();
デバイス->Present(引数省略);
■問題が発生しない場合2 D3DXVECTOR3 pos , cen; RECT rc; デバイス->Clear(引数省略); デバイス->BeginScene(); スプライト->Begin(); Draw_Test( &rc , &pos , &cen ); スプライト->End(); デバイス->EndScene(); デバイス->Present(引数省略); BOOL Draw_Test( RECT *rc , D3DXVECTOR3 *pos , D3DXVECTOR3 *cen ){ (変数に値を設定) スプライト->Draw( テクスチャ , rc , cen , pos , 0xFFFFFFFF ); return TRUE; } この2通りの問題が発生しない場合から考えて、最初に述べた結論で間違いなさそうです。 というか、こんな縛りがあるなんて驚きです。 これってプログラムでは普通なんですかね。 ※(引数省略)・・・問題の本質に関係ないため、この投稿で省略したという意味です。
ブレークポイントをあちこちに仕込んだり変数の中身を表示したりとかなり手こずりました。 解決したもののかなり運に近かったような気がします。 rcもposも使い回してるので内容も変わりまくってるはずで、 その変数がスプライト->Draw()する瞬間以外にも参照されているということになりますよね。 不可解です。 なにはともあれ、解決して良かったです。 これもみなさんに回答や助言を頂いたお蔭です。 みなさんのお力添えがなければもっと悩んでいたと思います。 やっと眠りにつくことができます。 おやすみなさい。
どういたしまして
検証はしないが もし本当なら有り得ない欠陥
89 :
デフォルトの名無しさん :2013/05/09(木) 22:56:15.34
誰か検証してよ
ゲーム作るならjavaとcのどっちがいいんだ?
きちんとデバッグできてDirectXとか使いたいならC お手軽に作ってデバッグもCより楽にやりたいならJava
適当にサイコロ振ってどっちか選んで、とりあえず全力で完成させてみろよ。 本当はどっちが作り易かったのか考えるのはその後でいい。
javaにする とんくす
お手軽だとは思うが 丸投げで聞いてくるレベルでは情報が少なすぎてツライかも
>>79 そのまとめたライブラリは
クラスにまとめてる?
それかextrunを使って分かりやすくグローバルにしてる?
「描画ループって何ですか?」というレベルでは何を使っても ゲームは完成しない。
描画ループって、どういうループ構造の事を指してるんだ? メインループとか、Windowsアプリのメッセージループとかなら、 while (...) { ... } という構造でループしてるなってすぐ分かるが。 描画ループは、描画処理の部分だけでひとつの輪っかを成しているのか? ってことは、メインループとかとは別スレッドか・・・
>>97 当たり前だろ
このご時世シングルスレッドで作るゲームって数当てゲームくらい
Now loadingの画面でアニメーションさせられるのは HDDからの読み込みとアニメーションが別スレッドで動いてるからですか?
>>98 そういうことなら、描画ループを知らないレベルでもゲームは完成させられるはず。
なぜなら、以前まではそのレベルで、数当てゲーム以上のクオリティのゲームを完成させていたから。
何を使ってもゲームは完成しない根拠をもう少し詳しく説明してほしい。
はい
どうでもよさ過ぎて鼻水でた
RestoreHanamizuToNoseOf(102);
ゲームの技術じゃなくて今のスマホの流行ってどうなってんの? 例えば3Dとかはスマホでは完全に定着してるのですか?
>>104 3Dどころか、プログラマブルシェーディングも完全に定着しています。
スマホ内部の組み込みプログラミングのレベルでは3Dでも 普通に使われてるけどAndroidのアプリはJavaだから無理。
107 :
デフォルトの名無しさん :2013/05/12(日) 19:13:33.78
でスマホのゲームってほとんどが無料じゃん?どうやって稼いでるの? 作り損?
そういうのはゲーム会社に就職できたらわかるかるから がんばって就職してね。その気がないなら気にしたって しょうがないでしょ。ビジネスモデルは自分で調べる。
>>106 内部組み込みとか意味不明。
AndroidはC++でプログラムは作れるんだが、
ndkも知らないのに知ったかするな。
jniは組み込みじゃないからな。
ついでにいうとJava単独でもシェーダぐらい呼び出せる。
>>107 趣味か、広告で稼いでるか
ガチャなどで一部の人から搾取して稼いでる
ビジネスはスレチ
C++のアクションゲームで プレイヤーや敵キャラのクラスは いろんなステージで使うからstaticにしてるのだけど どんどんstaticが増えてきて困ってる 本来はどうやってまとめるものなの?
面の状態を記憶する領域をシングルトンとして提供するか持ち回すかして プレイヤー情報や敵キャラの情報は全部その中に持ったり都度生成したりする
>>112 ステージってことは面クリ型?
俺が作るとしたらって考えたんだけど敵の何をstaticにするのかよく分からない
ステージクラスの中に敵クラスのポインタを宣言しといて、
ステージがロードされるたびに、前のステージの敵クラスは全解放して、また新しいステージの敵の数だけ敵クラス用メモリ確保→敵データ読み込みとかどうよ
プレイヤーのクラスはグローバルにしとく
どうなってほしいの?
118 :
116 :2013/05/15(水) 21:09:26.28
>>117 ブロックの反発を使って不自然な動きをしないようにしたいです
>>116 お前のプログラムだと、なんで滑るようにブロックを登ってしまうんだ?
何が原因なんだ?
不自然じゃない動きってどういう動き?
121 :
116 :2013/05/15(水) 23:46:26.21
ジャンプしてブロックの斜め上にぶつかった場合 ブロックの上部にプレイヤーの座標がくるとめり込まないようにY軸がマイナスされる それで不自然に浮いたような動きになる 当然、ifの順番を変えてもどこかの角が不自然な動きになってしまう
122 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/05/15(水) 23:58:45.81
縦方向のめり込みより先に横方向のめり込みを考慮する
123 :
デフォルトの名無しさん :2013/05/16(木) 00:54:23.03
>>122 そうすると
ブロックの下からジャンプして頭ぶつけたときに横に滑る
124 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/05/16(木) 01:07:06.69
ぶつかるブロックとマリオの位置関係を定義
125 :
デフォルトの名無しさん :2013/05/16(木) 01:39:05.71
126 :
デフォルトの名無しさん :2013/05/16(木) 01:40:07.40
>>124 実際、マリオとかロックマンってどうなっているんだ?
127 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/05/16(木) 01:44:09.85
>>125 マリオとブロックの相対位置と、マリオの速度に応じて、「マリオがブロックと接する面」を定義し、
接する面より向こう側に移動できないようにする
小さい頃ブロック崩し作ったなあ 手抜き実装: 現在の縦座標はブロック外→縦にぶつかったので縦ベクトルを反転 (elseで判定を繋がない) 現在の横座標はブロック外→横にぶつかったので横ベクトルを反転 (縦も横もブロック外なら角にぶつかったので両方とも反転) 反射先がブロックかどうか見ていないので 例えばブロック密集地に高速で突っ込むと高確率でバグる
130 :
デフォルトの名無しさん :2013/05/16(木) 08:54:34.90
131 :
デフォルトの名無しさん :2013/05/16(木) 12:41:11.34
>>127 どういうこと?
説明したサイトなどない?
何だ、片山はWin32APIスレ潰したら今度はここをターゲットにしたのか
市販のRPGの多くがマップと戦闘を分けてるのは そのゲームの演出的な意味なの? それともメモリ容量の関係? プログラムの生産性や分割しやすさとかそういったもの?
そこまでわかってて何を聞きたいのか
いや、どれか分からないから聞いてるんだけど
いちばんの理由はドラクエ以来のテンプレとして プレイヤー・開発者ともに受け入れられたからだと思うけどw
138 :
デフォルトの名無しさん :2013/05/16(木) 19:41:04.35
>>132 わかんねーよぉぉぉぉぉぉぉぉぉぉぉ
くそがぁぁぁぁぁぁぁぁぁぁぁ
マリオ程度なら適当にゲーム開発講座サイト探したら載ってそうだけどな
141 :
138 :2013/05/16(木) 22:23:27.61
>>139 うるせぇぇぇぇぇぇぇ
雑魚だから質問してんだよぉぉぉぉぉぉぉぉぉぉ
教えてくれよぉ(´;ω;`)
142 :
片山博文MZパンク ◆0lBZNi.Q7evd :2013/05/16(木) 22:39:01.74
マリオの右にいくつかブロックがあるとしよう。マリオの頭から足までの範囲のすぐ右にブロックがあったら、そのブロックの左端より右に歩いて行けない。 この時、マリオはそのブロックに「接している」と言うことができる。 マリオが落下しているとき、マリオの左端から右端の範囲のすぐ下にブロックがあったら、そのブロックに着地してそれより下に落下しない。この場合も下のブロックに「接している」と言える。
143 :
デフォルトの名無しさん :2013/05/16(木) 22:45:23.66
>>142 うむ
それでブロックにめり込んだ分だけ
反発してブロック手前まで戻すのが今のプログラムだろ
そこからどうするにょ?
真面目に答えて欲しいのなら、真面目に質問して欲しいにょ
145 :
デフォルトの名無しさん :2013/05/16(木) 22:59:34.17
>>144 ごめんなさい
それをどう変えれば良いの?
>>145 どの辺に対して、どの方向から接して(めり込んで)いるのかを考慮する
横方向から接しているのに、縦方向から接しているのと同じ対処をしてもダメ
バグっていても伝わらなくてもしらん無責任な書き込み マリオの移動処理{ キー入力を読む; //略 マリオの速度を暫定的に更新; //略 重力も考慮してしまう マリオの左右処理; //後述 マリオの上下処理; //後述} マリオの左右処理{ if(いまのマリオの位置に横速度を足すとブロックに当たる){ マリオの横座標をブロックと接する位置に; マリオの横速度を0に; }else{ マリオの横座標に横速度を加える;}} マリオの上下処理{ if(いまのマリオの位置に縦速度を足すとブロックに当たる){ if(縦速度が下向き){ マリオの縦座標をブロックに接する位置に; マリオの縦速度を0に; }else{ switch(突き上げたブロックの種類が){ case:ただの石なら 音を出す; マリオの縦速度を反転; case:破壊可能ブロックなら 音を出す; ブロックの破壊処理; マリオの縦速度を超低速上昇に設定; case:……} マリオの縦座標に縦速度を加える;}}}
「マリオが・・・」を軸に考え始めると、マリオに係る処理が膨大になって そのうち破たんすると思うよ もっと、マリオも全体の一部的なを考えをしないと
マリオもブロックもひとつとみて、コントローラー(クラス)にやらせるのがいいのかね
150 :
デフォルトの名無しさん :2013/05/18(土) 13:20:54.32
>>145 いっそマリオを長方形に見立てて、四隅の角の座標を取る
例えばマリオ右上の座標が、右側にあるブロックの左下座標より上、なおかつ左にあったら横からの衝突処理
同ブロック左下よりも右、なおかつ下にあったら下からの衝突処理
同右、なおかつ上にあってめり込み状態だったら、ブロック左下とマリオ右上の座標差x,yのうち小さいほうを優先して処理
みたいなのしか思い浮かばん……
マリオ作りたいって言ってるけど、 それ以前にブロックも段差もない平坦な2Dアクションは作れたわけ?
>>151 質問者は、キャラがブロックの角にぶつかるとキャラがそのブロックを滑るように登る、と言っている。
この問題の解決と、ブロックも段差もない平坦な2Dアクションが作れるかどうかと、どう関係するんだ?
ブロックも段差もない平坦な2Dアクションが作れることは、この問題の解決の必要条件なのか?
そもそも「ブロックも段差もない平坦な2Dアクション」とは何を指している?
地面の上をただジャンプするだけのものをプログラムできるかどうかと質問者に尋ねているのか?
だいたい一度にどの程度の数のオブジェクトをどう管理したら重くなるかとか そういうのは経験積むしかないよね?
>>152 関係するし必要条件だと私は思うのですが
どう考えたら関係ないと思えるんでしょうか?
>>155 質問者が抱えている問題は下記の2つ。
これらが意図したようにプログラムされていないために問題が現れている。
・当たったかどうかをどのように判定しているか
・当たっていた(めり込んでいた)場合、どのように解消するか
これらはなにもアクションゲームに特有の問題ではい。
シューティングでもRPGでもパズルでも、いろいろなゲームで根幹の問題だ。
初心者が「地面の上をただジャンプするだけのもの」を作る場合、
キャラが画面の縦軸座標のある値よりも下には行かないようにプログラムする。
このようなキャラと地面との当たり判定とその解消方法は、
ジャンプした時のキャラとブロックとのそれらとは根本的に異なる。
(経験と知識を積めば、一般化して、地面に対しても同じ処理で解決しようとするだろうが、
それはブロックとの当たりについて知識や経験を得た後だ)
方法が異なるので、「地面の上をただジャンプするだけのもの」を作ることで得た知識や経験は、
質問者が今現在抱えている問題を解決しない。
よって、「地面の上をただジャンプするだけのもの」が作れるかどうかを問うことに大した意味はない。
それと、そもそも質問者はジャンプなどをすることはプログラムできているはずだ。
ジャンプしてブロックに当たった時の処理で問題が起きているのだから。
ジャンプするからには、普通は地面が用意されていると思う。
「地面の上をただジャンプするだけのもの」は既にプログラムできていると思わないか?
そこまでダラダラ長々書く必要があるのか
>>157 この長さが必要だったかどうかは、私にはわからん。
もっと短くても
>>155 が私の考え方がどういうものか理解してくれたのなら(納得はしないだろうが)、
この長さは不必要だったかもしれん。
もしかしたら、
>>155 が理解するにはこの長さが適切だったかもしれん。
私は
>>155 の返答から、やや丁寧に書いた方が良いだろうと判断した。
本当にこの長さが必要だったかどうかは
>>156 に聞いてくれ。
>>158 自分に聞いてどうするよ・・・orz
本当にこの長さが必要だったかどうかは
>>155 に聞いてくれ。
はい。
>>156 >方法が異なるので、「地面の上をただジャンプするだけのもの」を作ることで得た知識や経験は、
>質問者が今現在抱えている問題を解決しない。
本当にそうでしょうか?
>「地面の上をただジャンプするだけのもの」は既にプログラムできていると思わないか?
思わないです。
>>161 > 本当にそうでしょうか?
本当にそうです。
それでは解決しません。
解決すると言うのなら、それをはっきりと質問者
>>116 に言うべきです。
「地面の上をただジャンプするだけのもの」を作る時に**という処理を使うが、
それを〜〜のように改良すれば今回の問題は解決する、など。
> 思わないです。
矛盾しています。
あなたは
>>151 で作れたかどうかを訊いている。
プログラムできていないと思っているのなら、
>>151 の質問は無駄です。
質問者にわかりきった無駄な逆質問をするより、上記のようなアドバイスを
はっきりと示した方が質問者にとって良いこととは思いませんか。
>>162 >本当にそうです。
>それでは解決しません。
必要条件と必要十分条件を取り違えていませんか?
それ「だけ」では解決しないのは私も分かっています。
>矛盾しています。
何が矛盾なのですか?
必要条件である「ブロックも段差もない平坦な2Dアクション作れる」
を満たしているかどうかを確認するのは絶対に無駄なのでしょうか?
無駄
長いわ
ば、ばかな 何ひとつとして有用な情報がないw
妄想プログラマが多いからな
>>163 「地面の上をただジャンプするだけのもの」を作れなくても、
たとえばシューティングゲームで当たり判定の処理をプログラムしたことがあれば十分。
シューティングゲームを作ったことなくても、他のものでもいい。
ゲームでなくても、GUIのツールを作る過程で本質的に同様の処理をする場合もある。
よって、
>>116 を解決するのに「地面の上をただジャンプするだけのものが作れる」は
必ずしも必要ではない。
>を満たしているかどうかを確認するのは絶対に無駄なのでしょうか?
あなたは「地面の上をただジャンプするだけのもの」は既にプログラムできているとは思わないと
>>161 で言っている。
まだプログラムできていないと思っているのなら、確認の必要はない。
これは既にプログラムできているという前提で、
さっさと「地面の上をただジャンプするだけのもの」を作ることで
問題がどう解決するのかを提示すべき。
既にプログラムできているかどうかあなたの中で判断できないのなら、確認には意味がある。
粘着しとんなあ
俺は既に
>>146 で自分なりのアドバイスをしている。
その周辺の他の人のアドバイスと合わせれば、解決の糸口が見えて来るのではないかと思っている。
しかし、
>>151 が「地面の上をただジャンプするだけのもの」を作れることが
解決に繋がると考えているのなら、それをもっと詳細に説明してあげた方が良いと俺は思うぞ。
俺は、質問者は既に「地面の上をただジャンプするだけのもの」はプログラムできていると思っている。
それが解決に繋がるのなら、質問者はぜひ知りたいと思っているのではないかな。
>>169 そう思われるのは心外なので、
>>151 に対するレスはもうしない。
何でもいいけど、当たり判定のプログラムのどこでそんなに困るのか。 そもそもマリオでブロックの角に当たったら滑って登るって普通だったろ。
自力で出来ないなら市販の物理エンジン使えよ バカには無理なんだから金でもつかわんとなんも出来んぞ
>>170 質問者の
>>116 がただサイトからコピペしただけで
「ブロックも段差もない平坦な2Dアクション」の部分すら理解してない
という可能性を
>>151 は示唆してるというだけなんじゃないの?
当たり判定くらいから算数の力が必要になってくる 学校のテストで点をとるためだけに勉強してた奴はこの辺りで引っかかりはじめる 3D行くと三角関数使うようになるし 数学苦手な奴にはもう無理
>キャラが画面の縦軸座標のある値よりも下には行かないようにプログラムする これがもし本当にできるのであれば キャラが画面の縦軸座標のある値よりも上には行かないようにプログラムすれば天井ができ キャラが画面の横軸座標のある値よりも右には行かないようにプログラムすれば壁ができ キャラが画面のある座標には行かないようにプログラムすればブロックできるじゃんやったな
>>175 一度は実際に検証してみてからレスした方がいいと思う
>>176 いや、だからそういうところから質問者が自分で試してみろってことだよ
何で下は上手く行くのに上がダメなのか考えればいつか自ずと答えが出るだろ
それが理解するってことだろ、答えだけ知ろうとするなよ
って俺は思うんですけど厳しいですかねwwwww
>>177 > 質問者が自分で試してみろ
いや、そういう考えなら、俺も同感だ。
別に笑うことでもない。
でも、そういう事を「最初に」はっきりと質問者に向かって言わないと、
遠回しな言い方では伝わらないよ。
ただ、それは回答者の方も一度は検証してからレスした方が良いというのと別問題だとは思う。
つーかムキになって反論すんなよ いくら考えて上等な反論並べたところで 誰も認めやしねーよ。うざいガキと思われるだけ。
>>178 つまり貴方様は既に検証済みということですよね?
参考にそのプログラムを見せていただけませんか?
>>116 はもうこのスレを覗きに来てない気がするんだよな…
いや、いいけどさ過疎だし
>>181 入社して研修を受けてた頃からさんざんやってるから、いろんなことを検証してきた。
俺のアドバイス
>>146 の「接する方向を考慮すること」もすぐにやらされるから検証済み。
君だってアクションゲームを作ったことがあるのなら、同じ事を一度はやってるはずだ。
それに例えば「アクションゲーム 当たり判定 ブロック」などでググれば、
俺(や、その周辺の人)のアドバイスの実例や、もっと詳細な解説はいくらでも見つかる。
あらためて俺が自分のプログラムを公開する必要性がない(面倒だし)。
俺のプログラムでなければ参考にならない、なんてことはないだろう。
それに、これくらいのキーワードは誰にでもすぐに思いつくはずだ。
君だって思いついただろう(この程度も思いつかないなんて言うなよ)。
なのに何故ググろうとしない?
>>175 のように、「これより右には行けない」、「これより下にはいけない」、
「これより右にはいけない」、「これより左にはいけない」と処理することで
ひとつのブロックを表現しようとすることも研修中にやっている。
そして、これではうまく処理できないこと経験している。
キャラの移動速度の関係でブロックにめり込んでしまった(しまう)場合、
そのキャラをどこに移動させればいいのか判断できないからだ。
ブロックの上側に強制的に移動させればいいのか?
それとも左側に強制的に移動させればいいのか?
結局、接する方向を考慮する必要がある。
「これより下にはいけない」これひとつだけなら問題ない、上側に移動させればいい。
>>175 は「できる」と言っているが、俺は研修中できなかった。
まぁ
>>175 も「できた」とは言っていないが。
また同じ粘着か 実りないしよそでやれよ
>>183 要約すると
「昔に検証したことだから今は手元にソースない」
ってことですね分かりました
>>183 >入社して研修を受けて
入社を始点に物事語ってる時点でお前様の程度が知れる
お前様を採用して会社も(お前を育てるのに)さぞ苦労したろうな
>>185 そう。
現時点で示せるコードは何一つ手元にないし、これから
>>181 のために書くのも面倒だ。
学びたいのなら、ネット上にもっと良いコード片や資料はいくらである。
そちらを参考にしてくれ。
>>186 研修云々を話してしまったのは俺のミスだ。
このスレにはどうでもいい関係ないことだった、申し訳ない。
忘れてくれ。
どうでもいい関係ないことに拘って延々と粘着するスレだろ 何言ってんの
初心者相手に自己顕示欲を満たすためにその当たり判定を実現したものを作ろうかと思ったけど当たり判定だけのためにアプリ作るのもだるい
ここはひどいインターネッツですね
>>186 全然関係ないけど、人を育てるのはどの会社、どの分野でもそうとう大変だよ
今ちょうど俺が新入社員相手に四苦八苦してるところ
ゲーム全く関係なくて、エクステリア関係の小さな問屋だけど
新人がうまく育たない会社は大抵先輩の指導がカスなんだよな
(´;ω;`)ウゥゥ ごめんなさい、がんばる
中途ならともかく新卒で即戦力とかいう求人結構きくしな・・・
そんなんもれなくブラックじゃん つか学生上がったばかりで即戦力の実力あるなら起業するし
だよな、俺とか
すげーなお前 正直うらやましい
企業は嘘じゃないけど、泣きそうなくらいセルフブラックです 見栄張ってごめんなさい
オブジェクト指向での設計で疑問に思ったんですけど、 ゲームって、オブジェクトAがオブジェクトBを参照する必要が出てくる事がよくありますよね。 これを単純に、親への参照を持つ事によって解決しようとすると循環参照となり、 インターフェイスが多くなりがちだし、良い設計とは言えません。 何かうまい方法はないのでしょうか? class Manager{ public: vector<Object> getObjects() { return objects_; } private: vector<Object> objects_; } class Object{ void hoge(){ vector<Objects> objects = pManager_->getObjects(); ... } private: Manager* pManager_; }
オブジェクト間のコミュニケーションプロトコルをシッカリと作り込む
そこでFacadeっすよ
あ、いや、Mediatorだったかも(適当)
>>201-202 FacadeというよりMediatorになる気がしますね。
Mediatorは、メソッドをたくさん持った何でも屋みたいになるのが嫌なんですけど、この場合はこれがベストなんですかね。
>>200 もMediatorみたいな事になるのかな。
204 :
202 :2013/05/31(金) 09:23:11.41
>>203 たしかにMediatorは肥大するな
>>200 はMediatorっていうよりプロトコルオブジェクトな気がする
なぜ参照するのかを考えて、そこに必要なデータを別のクラスに持たせて引数で扱うとかか
なんにせよ間に緩衝材となるクラスが無いと不便ね
ゲームではテクスチャやサウンド等のリソースは使い回すのが普通だ。 例えば同じモンスターが複数出てくる場合、テクスチャも同じなわけだからモンスターの数だけテクスチャをロードするのはリソースの無駄だ。 サウンドに関しても同様。 しかし、俺は今回そういったモンスターなど動きのあるものも必要なパラメーター以外を使い回すという仕組みを思いつき、実装した。 どういうことかというと、例えば2Dゲームで同じ姿形のモンスターがそれぞれ任意のタイミングでAという動作をする場合、 モンスターごとにAの動きの定義を持たず、Aという単一の定義に対してフレームなどの状態を渡して描画するという仕組みだ。
なるほど波動拳というわけか
説明が難しいな。 例えばモンスターに必要な情報は以下の通りだとする。 テクスチャ、サウンド、フレームや状態ごとの描画やサウンド再生定義、基本値(最大HPなど)、個々の値(現在HP、フレーム、状態) 室町時代には仕組み自体が確立されていなかったから、モンスターごとにこの全情報を持っていた。 しかし明治に入ると西洋の画期的な仕組みが取り入れられ、テクスチャやサウンドは同一のものなら使い回すようになった。 しかし今回俺は、フレームや状態ごとの描画やサウンド再生定義をも使い回すような仕組みを編み出したわけだ。 今はさらにその先の基本値まで使い回す仕組みを編み出そうとしている。 もしこれが完成すれば変化する値以外を完全に抽象化できるから大きなリソースの節約になる。
何という事だそれはまさに真空波動拳ではないか素晴らしい
なんという既視感
マトリックスに改編が加えられたか Translateかな
>>207 へんに口語を使わず、真面目に論文に起こしてくれ
そうすれば馬鹿な俺でも何を言ってるのか、何が画期的なのか理解できると思う
DIだろ(超適当)
アクションゲーム作ってるけど キャラクタデータクラスの中に出てくるキャラごとの基本パラメーターとして レベルごとのステータス 状態(立ち、必殺攻撃、よろけ)ごとのモーションのパラメーターのセット (何秒硬直するか、どの攻撃判定を出すか、使うテクスチャ、当たり判定のサイズ、移動スピードなど) 攻撃判定のパラメーターのセット (ダメージ基本値、ステータス補正の大きさ、当たり判定のサイズ、移動スピード、ガード可能か、消滅までの時間、消費MPなど) などを格納 キャラクタクラスには 使うキャラクタデータクラスの番号 今のHP、MP 今の座標 今の状態 今の状態になってからの経過時間 などを格納 キャラクタデータクラスはマップ変更で出てくるキャラクタが変わらない限り変更ないから固定値 キャラクタクラスはキャラクタごとに座標とかの変更されるパラメーターを入れる こんなの基本とまでは言わないけど Androidみたいハード性能が低いもので作ってたら 自然にたどり着くレベル
データを正規化しただけだろ これだから素人は困る 最低限基本情報はクリアしてから言語始めろよ
全部詰め込む人がいることも事実
これがオブジェクト指向か。
そうです。
オブジェクト指向って出来てない人多いよね オブジェクト指向言語なのに
OOPは言語関係ない概念だろ
>>219 オブジェクト指向設計を念頭においた仕様を備えた言語を使っているのに
と言い換えれば伝わりますか
それでも関係ないよ javaで手続き指向を書けるしCでオブジェクト指向を書ける 言語のサポートは書くのが楽かどうかというだけで オブジェクト指向的な考え方が出来るかとか使うかは別の問題だ 概念と実装手段の切り分けが出来てないよ
>>218 「せっかくの」 オブジェクト指向言語なのに
と言えば良かったと思うよ
オブジェクト指向は空気を記述するのに向いていないからね。
偽oopが幅利かせてるような糞な世の中 ってSmalltalk使いがゆってた
226 :
デフォルトの名無しさん :2013/06/15(土) 00:21:06.90
単一継承神話が崩れ去った今、旧教の原理主義者達は何がおっしゃりたいんでしょうか 動的型宣言もいまいち冴えてませんねえ
smalltalk=ユダヤ教 C++=キリスト教 java=イスラム教
その並びならユダヤ教はSimulaだろう
うしろ!うしろ!
>単一継承神話が崩れ去った今 なにこれ?
典型的な藁人形論法さ
先日、DirectXの描画でZバッファがおかしいと質問して皆さんに助けていただいた者です。 あのとき、Begin〜end間で描画のために別の関数を呼び出した場合、 pSprite->Draw()に渡すアドレスの変数がローカルだと上手く描画されないと書きましたが、 今回はその状態でないにも関わらず描画されないという不可解な現象が発生しました。 今回は簡単な描画テストのため、Begin〜End間に自作関数を含んでいませんでした。 timebuf = timeGetTime(); Draw(); BOOL Draw() { D3DXVECTOR3 pos, center; RECT rc; クリア〜Begin〜End〜Present return TRUE; } これだとクリア時の塗りつぶしは指定した色が反映されるのですが、テクスチャが全く描画されないのです。 ちなみにtimebuf = timeGetTime();をコメントアウトすると描画されるのです。 何度も確認しましたがこの一行でテクスチャが描画されたりされなかったりするのです。 結果的に、Draw()関数内の全ての変数にstaticを付けることで解決しましたが、どうにも不可解です。 ただそれでも何とか希望通りの動作をするようになったのは皆さんの惜しみ無いお力添えのお蔭です。 ありがとうございました。
キーリピートについて質問です 例えばキーリピート間隔2フレームの場合、 カーソルの右キーと左キーが1(mod 2)フレーム差で押されたとき 1フレーム毎に左右のキーが押されたものと等価になるので カーソルキーに連動して動かすキャラが振動してしまいます 通常キーリピートを実装する際はどんなやりかたでこの問題を解決しているのでしょうか ちょっと重いですが排他関係にあるキーが同時推しされている場合、キーリピートでキーのアップダウンイベントを 発行するのを抑制するくらいしか思いつきませんでした
素人だがなんとなく 1.解決せず仕様としてしまう →←___→←→←→…… 2.最後に押されたキーのみキーリピートの対象にする →←___←←←…… 3.キーの状態が一箇所でも変化したらキーリピート状態をすべてのキーに対してクリアする →(←+→)___(←+→)(←+→)(←+→)…… のうち好きなのを採用すればいいんじゃないかと思ったが もしかしたらそれじゃまずいのかもしれんな
>>234 普通WindowsやLinuxなどでは
>>235 の2番の仕様だよ。
他の OS や環境は知らんが。
あるキーXが押され、リピート開始までの時間に他のキーが押されたら、
そのXのリピート開始をキャンセルする。
リピート開始できるキーは一度にひとつだけ。
もし俺が作るなら、タスクシステムにして、あるキーXが押されたら、
リピートタスクをそのキーXのキーコードで初期化して再生する。
そのキーXが離されたり、他のキーが押されたら、再生中のリピートタスクを破棄する。
>>234 1フレームで2入力受け入れてるくせに
なんで結果の処理は2つ同時にやらねーんだよ?
プラマイ0でキャラ移動処理やらないのがスジだろ
破棄するのか初期化するのかどっちだよ 一度にひとつだけならタスクにする必要無い気がするけど 俺ならキャラを動かすところでキーダウンで調べて排他にして その上でキーリピートで動かすみたいな処理にするな。楽だから。
排他とか処理は無駄 キャラ移動処理する前に 今回の入力の累積取って それから移動処理させれば済む話 たまたま正反対のキー操作の例だけど 他に弾発射だの独立したキーリピートが複数あっても 粛々とやればよいだけ 排他とかいじってると、独立系キーとかの区分けがシッチャカメッチャカになるぞ
>>234 俺が画面内のキャラを操作する場合、
アップイベントがあればフラグ立てて、ダウンイベントがあればフラグを下ろす。
フラグが立っている間は決められたインターバルごとにその行為を実行する。
>>238 > 一度にひとつだけならタスクにする必要無い気がするけど
すまん、言葉が足りなかった。
他の処理もタスクでやってるのなら、リピートの処理も、という意味。
俺の場合は、アニメーションやサウンドなどほとんどのものをタスクで処理してる。
質問者もすでにタスクシステムを構築しているのなら、リピートもそれに組み込んだ方が楽だ。
242 :
234 :2013/06/21(金) 00:34:32.08
俺の実装ではクラスのメンバにキーリピートを制御するクラスインスタンスを持たせて、
そいつにキャラクラスに飛んでくるキーアップとダウンのイベントリスナーを登録させることで
決められたリピート間隔でアップダウンイベントをキャラに投げさせることで
擬似的にキーボードが連打されている状況を作り出すことで実現しています。
>>235-236 2番だと移動しながらの弾丸フルバーストができぬのです
>>238 , ...All
自キャラを出来るだけ単純化したいため
ゲーム自体に関係のない作りこみ部分のフラグ・変数等は極力減らしたいのです
そのため処理キーリピート処理はカプセル化したいというのが動機でして
ライブラリ部分で苦労しておいて実際のゲーム作りは楽したい
>>237 タイミングによってフレーム毎に
[↑D][↑U↓D][↑U↓D]… // U=Up, D=Down
というイベントが飛んでくることになるので、
1フレームに注目した場合↑↓一方のキーが押されているということになるので
エスパーしないと無理ということに
こういう処理をどうしてるのかわかるような
小さなソースコードないでしょうか・・
弾丸フルバースト?
例えば 十字キーで1つ ABCDボタンで1つ のみ連射が有効じゃダメなの? ボタンのグループを作ってそのなかで一つのみ有効とか
キーリピートってキーダウンとかキーアップと一緒に計算しておくもんじゃないのかな というかキャラの移動がリピート処理って珍しいと思う。弾丸ってことはシューティングなのかな?
キーリピートのリピート開始トリガーがたったの2フレームって あり得ないんだけど。押しっぱなしでリピートトリガーにするなら 少なくとも10〜20フレームぐらいは取らないとだめでしょ。 20フレームウェイトしたって0.3秒だから現実的だと思うけど。
>>246 質問者は「例えば」と言っているのだが。
開始時刻をずらして並進する2つのキーリピートによる問題を
わかりやすく説明しただけだと思う。
単純にめりこんだ分押し戻せばいいのになんで登るんだ
249 :
248 :2013/06/23(日) 16:22:40.01
ウホ 長いことリロードしてなかった。ごめんなさい
ちょっと懐かしい話題でワロタ
ワロタ
シーンの分け方が分からなくなってきたし、シーンに何かを被せるときはどうするの? それに関連して、リソースをどの段階で読み込めばいいか分からなくなってきた。 具体的には2DRPGでメニュー出したときにマップが透けて見えてるような状態。 マップを描画しなきゃならないからメニューもマップで管理するの? メニューで使うアイコンとかのリソースってメニューを表示するたびに読み込むの? それともゲーム開始時に全部読み込むんですか?
とりあえず今はマップクラスにメニューを操作するコードをゴリゴリ書いてるんだけど、何か違う気がしてきた。 違う気がしてきたけど他に良い案も思い浮かばない。
>>252 シーンを複数表示できるようにして(呼び出した順で描画)
マップシーンでメニューシーンを呼び出すといい感じになると思う
スタックで積む感じ。ほいでメニューの終了時にポップする感じ。
リソースは読み込みに時間がかからなくて、メモリに余裕があるなら
ゲーム開始時でいいんじゃないかな
素人だけど ファミコン時代はともかくPS時代以降の重ねあわせ処理は 基本ハードウェアに丸投げするものじゃないのだろうかと想像 マップはマップ用のレイヤーだけ、メニューはメニュー用のレイヤーだけいじる ハードウェアにはリソースそのものや 消去・移動回転・エフェクト・リソース交代などの指示をぶん投げると なんとなく一番手前から5枚くらいのレイヤーは、致命的なメッセージ用、 一般的なエラーメッセージ用、デバッグ時エラーが起きそうな警告メッセージ用、 デバッグ時メッセージ用、デバッグ時変数リソース等監視用としてとっておきたい感じ
>>255 > ハードウェアにはリソースそのものや
> 消去・移動回転・エフェクト・リソース交代などの指示をぶん投げると
そのようなハードウェアの機能はありません。
というか出来ること出来ないことが渾然としてるな
258 :
デフォルトの名無しさん :2013/06/29(土) 14:18:24.77 ID:NdLj9NH6!
矢印の方向にキャラは動くのですが、二つのキー(↑→)を同時に押してる間、斜めに移動させたいです。 んでもって、どちらか一方を離したら残っている矢印の方向へ移動する。 現在:ゲームボーイのドラゴンクエストみたいな動き。 欲しい動き:斜め動きが出来るニンジャ。 void keyPressed(KeyEvent e) {migi = true;....}を同じクラスにある void keySet(){if(migi){player.move(MIGI)}elseif(..)....}に送ってる。 今のプレイヤーの動きはこんな風にしています。 public void move(int dir) { if (dir == HIDARI) { vx = -SPEED; } else if (dir == MIGI) { vx = SPEED; } } public void stop() { vx = 0; } public void update() { x += vx; y += vy; }
>>258 問題の本質は、キーボードの複数のキーの同時押しを検出すること、と解釈して良いでしょうか。
質問文には書かれていないので私の勝手な推測ですが、Windows 上で C# を使っているものとします。
この問題の解決ですが、私の知る限りでは2つの方法があります。
そもそも、少なくとも Windows の API には、
キーボードの複数のキーの同時押しを検出する仕組みそのものはありません。
なので解決するには、そのような仕組みを持った Windows の API 以外の方法を使うか、
Windows の API やその仕組みを組み合わせて擬似的に検出を実現するしかないです。
前者は、たとえば DirectX を使う方法があります。
(他の方法もあるかもしれませんが、私は知りません)
「C# DirectX キーボード 同時押し」 などでググってみてください。
後者の方法は「C# ゲーム キーボード 同時押し」などでググってみてください。
ただし、後者の方法は非常に面倒で、仕組みもスマートとは言いがたい感があります。
個人的には、前者の方法を奨めます。
260 :
デフォルトの名無しさん :2013/06/29(土) 15:36:36.29 ID:NdLj9NH6!
>>259 ありがとうございます。
言語はjavaなのですが DirectXに付いて調べたいと思います。
言語を問わず、 if ( 右 + 上 ){右上へ斜めに移動する処理} else if ( 右 + 下 ){右下へ斜めに移動する処理} else if ( 左 + 下 ){左下へ斜めに移動する処理} else if ( 左 + 上 ){左上へ斜めに移動する処理} else if ( 右 ){右へ移動する処理} else if ( 上 ){上へ移動する処理} else if ( 左 ){左へ移動する処理} else if ( 下 ){下へ移動する処理}
else ifを連ねるのは馬鹿のやること。 判定ロジックを工夫すべし。
263 :
デフォルトの名無しさん :2013/06/29(土) 17:24:53.44
これはひどい・・・
オセロゲームを実装したクラスの駒を置く処理で今は 「駒を置けるか判定→駒を置く→置いた影響を反映するサブルーチンを呼ぶ」 の3ステップでひとつの駒設置メソッドとしてるんだが これをひとつひとつのメソッドに分けてゲームを利用するクラス(ようはビュー)が適切にこの順番で呼ぶようにしたほうが良いのかな?
>>261 else ifでやるならせめて左中右で1pass、上中下で1passの2passにしたいなあ
>264 それは、何がしたいか、によります。 その3つの処理を不可分のものとしたいのなら、分けずに現状のままにすべきです。 たとえば、このままでも処理が十分シンプルで、コードを見て全体の処理が容易に把握できる、など。 逆に、コードが長く複雑で、ぱっと見で処理が把握できない状況であり、 もっと分かりやすくしたいのなら分けるべきです。 他にも、ゲームの仕組みを実現しやすくするために分けた方が良いケームもあります。 たとえば、コマを置く時にプレーヤーはカーソルを動かすと思いますが、 その際に駒が置けるところにカーソルがあればカーソルが光り、 置けないところではグレー色に表示されるようにしたい場合、 「駒を置けるか判定」の処理は分けた方が良いです。 分けなければ、同じ処理のコードを複数の場所に書くはめになるからです。 置いた影響を反映するサブルーチンも同様です。 この処理の部分が洗練されていれば、たとえばAIの思考ルーチンからも呼び出せます。 何がしたいのかを明確に示していただければ、どう分けるべきか、分けるべきでないか、 もう少し具体的なアドバイスができるかもしれません。
267 :
258 :2013/06/29(土) 19:34:18.40 ID:NdLj9NH6!
一応?斜めに動くのですが、何かしら動きに違和感がある。 ずっと→を押していて、その→を押したまま↑を押しても斜め上へは動いてくれない。 最初から↑と→を同時に押さなければ斜め右上へは行ってはくれぬ。 if (keystate == (UP + RIGHT)){ player.move(TOPRIGHT);} public int keystate; public void keyPressed(KeyEvent e){ int key = e.getKeyCode(); if (key == KeyEvent.VK_A){ keystate |= RIGHT; // →の保持のため? leftPressed = true; }
>>267 押されたキー情報を取得する方法でやってると、キーバッファに
残っているリピートキーも拾ってくるからそうなる。
× 押されたキーの情報を取得する
○ キーマトリックス情報を取得する
こうすればOK。キーマトリックスを読むのは何か方法があったと
思ったけどちょっと思い出せない。
269 :
258 :2013/06/29(土) 20:38:39.37 ID:NdLj9NH6!
>>268 なるほど。思った以上に難しいな。
アドバイスありがとうございます。
しかし、キーマトリックスに付いての情報少ないな〜。工学系統なら沢山あるのに。
アプリケーションからキーバッファをクリアできるといいんだけどね。 これもちょっと方法がわからないんで。
>>266 ビューとロジックをしっかり分けたい
ビューはロジックをよく知らなくても良い
ロジックはビューのことはなるべく知らなくて良い
というのが良く分割されたビューとロジックだと思うんだ
三つのメソッドに分解するのはいいとして
それを外のクラスからバラバラに呼び出せるのは間違いではないか、と思うんだ
置けるかどうかメソッドはイミュータブルだし、有ればビューにとってもAIにも便利だから公開してもいいと思う
でも駒を設置メソッドと影響を反映メソッドはバラバラにして公開すべきではないと思う
なぜなら分割して公開した場合、ビューはロジックを詳しく知っていて適切な順番でメソッドを呼び出さなければならなくなる
ロジックはビューが正しい順番でメソッドを呼び出してくれるかに依存するようになる(正しくない手順に対処しなければならなくなる)
結果として両者の依存度が高くなる
だからロジック担当クラスとしては
三つのメソッドをひとまとめにしてひとつのコマンドとして公開するべきじゃないかと思う
このコマンドがいつビューやAIに呼び出されるかはわからないが
呼び出された時に有効なら処理をして、連鎖的に発生する処理をして、その際に変更が有ればnotifyする
呼び出された時に無効なら何もしないし変更がないからnotifyもしない
ダメかな?三つに分けて呼び出す側が責任を持って適切に呼び出すべきだと人から言われて悩んでるんだ
272 :
デフォルトの名無しさん :2013/06/30(日) 09:49:55.20
プロトコルとブラウザに分ける
273 :
258 :2013/06/30(日) 09:56:45.69 ID:oHBz3JbV!
Killer Game Programming P.308, Ch12 に複数のキー入力の項目があったのでちょっと勉強してみます。 一応、ウェブ上にもあったのでuri貼りましょうか? もし興味がある人がいれば。
274 :
266 :2013/06/30(日) 11:12:50.70
>271 あなたの目的の本質はこれですね。 > ビューはロジックをよく知らなくても良い > ロジックはビューのことはなるべく知らなくて良い このような仕組みを作ることである、と。 そして、現在の状況を要約すると、こういうことですね。 ・この3つの処理は必ずこの順で処理しなければならない ・駒を置けるか判定する処理は、これ単体で処理することに「も」価値がある であれば、ロジックは2つのコマンドを公開すべきでしょう。 (ロジックの内部で3つの処理を分けるかどうかは、また別の話) 1. この3つの処理をひとかたまりとして順に処理するコマンド 2. 駒を置けるかどうか可否を知るコマンド ただし、このような方針にすることにもデメリットはあります。 ロジックに対して何かまた新しいことがやりたくなった場合、 ロジックはまたそれ専用の新しいコマンドを作って公開しなければなりません。 逆にロジックが上記のようないくつかの処理をかためず、プリミティブなコマンドを公開していたら、 汎用性が高まり、ロジックを利用する側は既に公開されているコマンドを組み合わせるだけで済みます。 こちらのデメリットはあなたが考えるとおりです。 要は設計スタイルの違いで、好みの問題です。 > 三つに分けて呼び出す側が責任を持って適切に呼び出すべきだと人から言われて そう言った人の理由は何なのでしょうか。 私はあなたの状況がわからないので、その人の言い分の方があなたに合っているのかもしれませんよ。
275 :
266 :2013/06/30(日) 11:17:21.26
>>274 > 私はあなたの状況がわからないので、
私はあなたの状況を詳しく把握しているわけではないので。
その人があなたの設計やコードを見ているのなら、私(たち)よりも詳しく把握していて、
その上でのアドバイスでしょうし。
>>274 その人から聞いた理由は
「駒を設置メソッド」はあくまで駒を設置するためのメソッドだから設置可能か調べたり影響を反映させるのはおかしいので別のメソッドに分けるべき
後から見た人がこのメソッドを見て設置以外の処理をしているとは普通考えないので不親切
という事らしいです
277 :
266 :2013/06/30(日) 11:48:29.57
>>276 そういうことなら、話がごっちゃになってますね。
その人はあくまで、ひとつのメソッドの役割はひとつに絞るべき、と言っているのです。
それを他のクラスに公開するかどうかは、話が全然違います。
ひとつのメソッドの役割はひとつに絞るべきというその人の意見は私も賛成です。
そして、バラバラにして(外部に)公開すべきではないというあなたの意見にも賛成です。
これは排他的なことではないので。
私なら、3つの処理をそれぞれメソッドに分けてクラスのプライベートメソッドにします。
そして、
>>274 で言ったように2つのコマンドを公開します。
なんか超絶面白いの作ってくれ
ゲームは相互参照が多いって誰かが言ってたけど、マジでそう思う。 ゲーム開発のためのツール作ってると相互参照なんてほとんどないのに 本体作ってると相互参照ありまくり。
どこのことかよくわからんが 一画面に情報をつめ込みたいとか プレイヤーのボタン操作を一回でも減らしたいとか そういうワガママの行き着く先ってことかな
それはツールとは言わないんじゃないかな どちらかと言うとバッチ処理の類だと思うね ツールこそ相互参照が超絶多いでしょ 例えば3Dモデラー自作とか考えてみなよ? 座標、重複頂点か、法線、頂点カラー、ポリゴン形成、マテリアル 軽く列挙しただけで、これらの単独情報が相互参照しまくりでしょ
283 :
258 :2013/07/07(日) 08:35:56.53 ID:1ENr07X8!
方向弾についての質問です。 例えば、右キーを押したときに車から乗客が右へ飛んでいくようにしたい。 右キーが押されたらrightpressedをオンにして if(rightpressed){car.throw(RIGHT);} に引数を渡して乗客の移動をしているのですが、 これだと右に乗客を飛ばして車が左に移動すると、右へ飛ばされた客が車の移動と合わせて左に戻ってきてしまう。 複数の客を将来扱うと仮定して、どうすればいいでしょうか?
>>283 客が車から放たれた瞬間に、客を独立したオブジェクトとして生成し、扱う
アクターとか知らないんだろうな
悪魔より悪魔らしい探偵さんでしょ
288 :
デフォルトの名無しさん :2013/07/07(日) 16:48:30.32 ID:1ENr07X8!
>>284 方法探してみます。
ありがとうございます。
アクターもカールヒューイットが言った意味からだいぶ勝手に拡張された気がするな
てか書き込みにIDが付いてるのってなんだ?
呪いさ
292 :
デフォルトの名無しさん :2013/07/07(日) 18:56:42.71
末尾に ! がついてるのが見えないか? 俺も眼鏡かけないと見えないが
2Dのゼルダみたいなゲーム作ってます 壁に当たったら壁の接戦方向にずりずり動かしたいのですが どのようなアルゴリズムで実装したらいいのでしょうか Collide()関数とDistance()関数はあります。 法線は今のところ取れません(が何とかなるかもしれない)。
ずり動かす処理に関しては ゲームプログラマになる前に覚えておきたい技術 って本に詳しく載ってたはず 角がややこしいって話らしい
>>294 ちょっと失礼。
その本のサンプルがエラーで使えないのですが、何がいけないと思いますか?
空のウィンドウでinclude、lib86の設定はしてます。
・環境
Windows7
Visual Studio2012
DirectX11
>>295 エラーの内容を書かないとか馬鹿にしてるの?
>>295 こういう奴は一生ゲームを作れない
君見込みないよ
ボケで噛んじゃうって恥ずかしいよな
ミニマップってどうやって表示してるんでしょうか 自分は青点で敵は赤点みたいなやつです 1回目と2回目で描画の方法を変える方法がわかりません
じゃあお前はキャラや背景、スコアなどをどうやって描画しているのかと訊き返したい
キャラはSprite.OnDraw()で描画しています 1回目のSprite.OnDraw()はキャラを表示して、 2回目のSprite.OnDraw()はレーダーに赤点を表示したいのですが どうやって1回目と2回目の処理を変更したらいいのかわかりません
データベースむずすぎわろた グリーバカにしてすいませんでした
>>304 よくわからないけど、
例えばキャラクターを管理するクラスを
class CHARA{
/*中略*/
int MainDraw();//キャラクターグラフィック描画用
int RaderDraw();//レーダー上の描画用
/*中略*/
}
にして、描画するときにそれぞれ呼び出したらいいんじゃないの
>>304 全く別のキャラ2体を描画するときはどうしてる?
>>306 描画はOnDraw()と決まっているので変更は無理です。
キャラが
Sprite1.OnDraw() <-- キャラ表示用
Sprite2.OnDraw() <-- レーダー表示用
の2つを持っていて1回目はキャラ用のスプライト、2回目はレーダー用のスプライトを描画すれば・・・?
しかし1回目と2回目でどちらのスプライトを描画すべきか切り替えスイッチはどうすれば???
わからん
OnDraw以外は追加できないのか?基本的な仕組みを変更せずにどうやって2回描画するんだか if( flag ) Sprite1.OnDraw(); else Sprite2.OnDraw(); flag =!flag; どうしても無理なら毎回フラグで切り替えるしか無いんじゃね
どう考えても不可能なのでOnDraw()に引数を追加してN回目みたいな変数を渡すことにするわ 1回目は普通にゲーム画面を書いて 2回目は小さく右上にレーダー画面をレーダー用スプライトで まだ作ってないけどこれがベストなはず
どんなライブラリ使って、どんな設計で、どんなプログラムを書いているのかも分からないのに、 それでも質問者とまともに会話しているお前らが正直すごすぎると思った。 しかも、ちゃんと解決されているのには脱帽だ。
下手な抽象化のせいで自分の首を絞める良い例ですな
OnDraw()以外にできないのはライブラリやAPIの都合なんだろうか? だとしてももっとスマートな解決法ありそうだけど 抽象化の層をひとつ増やすとか
規約とかで縛られてるだけじゃね?引数追加とかできるわけだし 名前を縛られてるだけなら、OnDraw(void)とOnDraw(int)の2種類用意するのはどうだろうか
試しに実装してみたら意外と難しいです
http://www.fastpic.jp/images.php?file=5771022390.png 第1にカメラは2つ用意して切り替えないと無理
あとOnDraw()の中でpass == 0,1で切り替えるは激しくダサイ
(この程度のプログラムなら問題ないがゲームレベルになったときに発狂すると思う)
ゲーム作るときに複数回レンダリングパスをまわすのは普通だと思うのですが、
これの抽象化方法がよくわかりません。
あるいはOnDraw1(), OnDraw2(), OnDraw3()....とエントリーポイントを複数用意すべなのか?
わけわからんです
継承とかよくわからん第三者なので、適当に class CHARA{ public: get_locate(); /*コンストラクタでCHARA_MAIN_WINDOWの変数とCHARA_RADER_WINDOWの変数を作成*/ /*デストラクタも同様*/ /*略*/ } class CHARA_MAIN_WINDOW : public CHARA{ CHARA chara; int OnDraw(chara.get_locate());//キャラクターグラフィック描画用 /*略*/ } class CHARA_RADER_WINDOW : public CHARA{ CHARA chara; int OnDraw(chara.get_locate());//レーダー上の描画用 /*略*/ } と書き捨てて、きちんと勉強している人々にタコ殴りされる前に逃げる。とうっ
ライブラリに頼るな。所詮は最終的に2DのサーフェスorViewにピクセルとしてレンダリングされるだけ。 自前でやれれば問題ないんだと。って言っちゃうと身も蓋もないかw
キャラクタから座標もらってマップクラスがマップを描画すればよい。
319 :
デフォルトの名無しさん :2013/08/02(金) 18:57:30.95
ライブラリに頼って何が悪いんだYO!!!
悪いなんて言ってないだろ。 頼るなと言ってるだけだと思うぞ。
ライブラリの性質とそれが提供する機能の実現方法を知っていて利用するのが理想だな
322 :
デフォルトの名無しさん :2013/08/06(火) 09:46:32.71
PC用のゲームを作る場合 縦横の画面の大きさはどれくらいが良い? 出来るだけ大きくて、様々なサイズのディスプレイにも表示できるサイズがいい
とりあえず800x600くらいにしてみたら
縦長か横長かをまず決めねば
325 :
デフォルトの名無しさん :2013/08/06(火) 13:45:28.15
客層を考えねば
>>322 解像度のことを言ってるのか、ウィンドウサイズのことを言ってるのか
解像度ならWin32APIで取得できる
DirectXを使うなら対応してる解像度を取得する関数がある
ウィンドウの大きさなら好きに作って最大化しろ
設定の仕方じゃなくてデザインの話だろ
デザインの話ならここよりゲ製板じゃね ム板はフルネームの「プログラム技術@2ch掲示板」の通り 技術的な話が専門だからなあ
Windowサイズは640x400に決まってるだろjk
331 :
デフォルトの名無しさん :2013/08/06(火) 20:03:37.52
なつかしす
縦が32で割り切れないとことかかわいい
32で割り切れるとなんかいいことあるんだっけ?
334 :
デフォルトの名無しさん :2013/08/07(水) 11:21:20.93
NTSC の垂直解像度が 525(有効480) なわけで 32 というより 480 に由来しないのが変なんだよ PC9801ではモニタを壊すリスクと引き替えの 禁断技で 30行計画つーのがあってだな・・・
テレビモニタを流用してた時代ならともかく、それは基本的にない。 PC-98GSとかあったけどさ。
336 :
デフォルトの名無しさん :2013/08/07(水) 12:08:23.69
テレビをモニタとして使っていた頃には 320x200 だったね それで 8x8 の文字を 40x25 または 40x20 で表示してた
CONSOLE 0,25,0,1
338 :
デフォルトの名無しさん :2013/08/07(水) 19:04:53.14
1920x1080で
>>333 RPGとか作るときに32x32のマップチップがぴったり敷き詰められないんだよあれ
340 :
デフォルトの名無しさん :2013/08/07(水) 20:23:36.05
2↑↑nになっていない数は、美しくないんだよ
今時直接画面と1対1で設計せんだろ? 作りたいように作ってあとは画面に合わせて拡大縮小だろ
昔はハードウェア側も8x8とか16x16とか32x32みたいな単位で表示を扱ってたから そういう単位に合わせるのはそれなりに意味があったと思うが 今はその単位からズラしても良くね?って思う
2DRPG作ってるけど未だにマップチップが32*32の呪縛から逃れられない
640×400の昔話だったのでは?
メモリ漁る時も見やすいからな
C++でDirect3D11ゲーム作ってるんですが フレームレート制御で描画ウェイト入れるときSleep(0);って有効なんでしょうか? それとも別にもっと良い方法が?
「有効」とは?
早すぎるレンダリングにウェイトを入れるという目的について十分な効果があるかという意味です。 あるいはそのほかの方法があれば、それと比べてSleep(0);のデメリットは何かあるのでしょうか。 ウェイトを入れるということは、そのスレッドの処理を休止して他に溜まってる処理をCPUにさせるんですよね。 Sleep(1);としたときには、1ms以上経過後に処理が再開する(1msに満たなければ何度でもそのスレッドの処理をスキップする)みたいですが、 0を渡した場合は「一度だけ処理をスキップする」ということであってますよね?
>>349 ありがとうございます、それです。WIN32APIです
違いましたか。
プログラムをもう一度よく見てみようと思います。
失礼いたしました。
351 :
デフォルトの名無しさん :2013/08/15(木) 15:32:04.23
引数は 1ms 単位だが、タイムスライスは 31.2ms (サーバー系では 187.2ms)で、いずれにせよ 1ms の精度はないというだけ
>>350 一応念の為に言っておきますが、MSDN によると、
0 を指定した場合の挙動に関する記述は次の3点に要約されると思います。
1. 等優先順位で準備完了している他のスレッドに制御が渡る。
2. そのようなスレッドがなければ即座に制御を返す。
3. 現在のスレッドの残りのタイムスライスは放棄される。
この3はおそらく1の補足説明だと思われます。
「一度だけ処理をスキップする」の 「一度」 や 「処理」 の意味が曖昧ですが、
これは、0 を指定しても他のスレッドに制御が渡るケース、
即座に制御が返されるケース、どちらにも当てはまらないと思いました。
なので、0を渡した場合の挙動を思い違いされているようです、ということです。
>>351 それはDirectXプログラミング的には何も問題ないのでしょうか?
>>352 3の意味で「一度だけ〜」といったつもりでした。
2のごとき結果は殆ど有り得ないだろうという私の早計により言及しませんでした。
言葉が足らず申し訳ないです。関数の挙動を見る限りでは、Sleep(1);を呼び出すと、
1msの間、現在のスレッドがスケジューリングされない、つまり1ms以上レンダリング ループが
休止するのですが、かわりにSleep(0);を呼び出すことで、より敏感な描画ウェイトを
実装できるのではないかと思って質問させて頂いた次第です。
それとも、SwitchToThread 関数など、他の方法をとる方がよりよいのでしょうか。
>>354 Sleep(0) とやった時にいつ他のスレッドから戻ってくるかは、日本語の MSDN には言及がないな。
他のスレッド(全てではない)がなければすぐに戻ってくるとは書いてあるが。
だから、一度だけ処理をスキップするかどうかは残念ながら「未定義」だ。
きめ細かく、より正確に時間の制御をしたかったら Sleep 関数に頼らずに、
そのゲームループの中で空ループを回すなどした方がいいと思う。
ところで、早すぎるレンダリングにウェイトを入れるというのは、
例えば動的 fps にするくらいなら 30 fps に固定したいとか、そんな理由?
356 :
デフォルトの名無しさん :2013/08/15(木) 18:31:35.93
dormant に入るかどうか「未定義」はおかしいだろ
基本的にQueryPerformanceCounterをチラ見しながらループぶん回すだけやがな タスクマネージャでCPU占有してんのを糞ユーザーに馬鹿にされるのが嫌だってだけなら MMCSS指定してSleep(1)を挟んどけばとりあえずおk 動作環境のFPSがVSyncに左右されて良いのならPresentの同期待ちを利用するのが一番素直ではある
>>355 確かに、そのように考えてみると書いてないですね……。 思い違いでした。 ありがとうございました。
特に動的/静的 fps 制御ということは考えてはいませんでしたが
最低限 CPU負荷を軽減 (Sleep 関数などのことです) した上で出来る限りの柔軟性を求めたかったので
実質、動的 fps と言うべきかもしれません。 規定値としては 60 fps に設定しています。
Sleep 関数を呼ぶか呼ばないかも動的にトグルできるようにしてみようと思います。
>>358 MMCSS ですか!
当初 timeBeginPeriod 関数を呼ぶべきかも考えたのですが、そのようなAPIがあるのは知りませんでした。
本当に助かりました。ありがとうございます。
フレームレートみたいな周期性のものをSleepで調整しようという 考え方そのものが間違ってる。
誰もsleepで調整する話してないだろ
普通、シグナル使わない?
v-sync?
何で「垂直同期」って名前なの? 何が垂直なの?
電子ビームが下から上に移動するタイミングだから垂直
そこはググレカスと言ってあげるのが親切というもの
水平同期はないのですか
ありますよ ゲームで気にする必要はないと思うけど
水平同期=DQ3の旅の扉のエフェクト
>>369 ファミコンのラスタースクロールは、結果的に水平同期信号と同期しているというだけで、
水平同期信号を直接拾っているわけではないんじゃなかったっけ。
たしか、0番スプライトをレンダリングする際に特殊なフラグが立つ機能と、
グラフィックテーブルのどの位置から画面にレンダリングするかを決めるスクロールレジスタの値を、
垂直帰線期間以外でも自由に変えられるという機能を使う方法がある。
この番スプライトを画面左端に置いてフラグをポーリングすることで、
果的に水平同期信号と同期できる。
間違ってたらごめん。
371 :
デフォルトの名無しさん :2013/08/18(日) 14:15:15.96
ゲームエンジンに詳しい人に質問です。大雑把に 自キャラ --> 自タンク --> 砲弾 --> 敵タンク(破壊) = 自キャラ「一機撃破!」 という流れがあった時に、敵タンクから自キャラを探すにはどうするのがベストでしょうか 1. 発射元のオブジェクトの参照をバケツリレーする 2. シーン全体からオブジェクトを検索できるようにする 3. ゲーム全体で使える汎用イベントシステムを実装する いろいろ考えると3のイベントシステムを実装するのがベストかと思うのですが、 グロバールのイベントマネージャーみたいなのがあって、 単に敵タンクが「俺壊れたっす」を登録して、自キャラ「俺壊したっすか」クエリーを飛ばせばいいか、 あるいはもっと何かいい実装方法がありますか。 参考になりそうな書籍を教えてください
砲弾に誰の砲弾かっていうデータ持たせて それで撃墜カウント計算すれば済む話
ダサい設計だな
374 :
371 :2013/08/18(日) 14:59:26.42
>>372 それは1ですね。そうやってバケツリレー方式でオブジェクトの参照を渡していくのは、
ゲームの設計で賢い選択ではありません。
せめてIDか識別用文字列を付加して2または3のどちらかでオブジェクトの参照を取得できるように実装する必要があります。
おそらく3のイベントシステムを実装すべきですが、そのベストプラクティスを教えて欲しいです
ルーティングしてイベントをブロードキャストするだけ
なにがバケツリレーなんだよ めんどくせー中間処理入れる必要ゼロだ
>>371 はまちがいなくまともなプログラムが作れない
378 :
371 :2013/08/18(日) 16:02:28.06
>>375 そんな単純な話では無いです
市販ゲームレベルでイベントが起きるたびに全オブジェクトの virtual OnGameEvent() を呼び出すのは無謀。
僕の考えた最強のイベントシステムは、
- イベントの識別は文字列(名前)
- 優先度
- イベントはキューイングして保存、順番に発行
- 興味のあるイベントを事前に登録型
- ピアキャストとブロードキャスト
- Update()フェーズの次にHandleEvent()フェーズを実装
こんなのでいいと思うが、どうだろうか。
俺の考えた最強のシステムを山ほどつなぎあわせた挙句に グローバルなシステムに丸投げってキチガイシステムよく見るよな
文字列使う時点でセンスない
381 :
371 :2013/08/18(日) 16:08:56.61
>>376 ある程度の規模のゲームになった場合、オブジェクトの参照(ポインター)を使ってメソッドを呼び出すのは
「結合が強すぎる」事に気がつくと思います。
通常はゲームオブジェクトはIDか文字列で識別し、ゲームオブジェクト間のやりとりは
イベントシステム(メッセージパッシングとも言う)で処理していくのが欧米の一流のゲーム会社のやり方です(たぶん)
>そうやってバケツリレー方式でオブジェクトの参照を渡していくのは、 ゲームの設計で賢い選択ではありません。 こいつキチガイだろ。 そうだと思うなら1書いたときにそう書いとけよ。 お前の思い込みなんかしらねーよw
結合を強くする(一概にそうではないのに)変わりに なんでも管理するグローバルシステム。 頭悪すぎる。 欧米の一流のゲーム会社のやり方ですw
たかが撃破処理すんのに なんで破壊された敵タンク視点で処理すんだよ? この時点でパーだろ 何がどう欧米の一流なんだよ
イベントの種類毎にガチガチのイベントルーティング処理をわざわざ実装した上で さらに全体検索も作るなんて狂気の沙汰 そんな事するなら最初からFacadeにして上から垂れ流し+受け取りのがマシ
そもそもイベント処理(コールバック処理)が万能だと思っているのがセンスない。 イベント・メッセージ処理はデバッグするときに 実行時のキューの状態も監視しないといけなくなる。 どこにでもそういう実装していくと実装にもデバッグにもコストがかかりすぎるようになる。
イベントIDを文字列にした時点で テンプレートなしで、型クラスを自前で作ることが確定 男らしいと言えば男らしい・・か?
欧米の一流のゲーム会社のやり方ですw
389 :
371 :2013/08/18(日) 18:05:26.00
>>384 敵タンクの破壊処理を敵タンクが行わないプログラマーがいたら2流以下
HP=0になって壊れたかどうか判定できるのは敵タンクだけですよ
そして敵タンクを破壊したらキャラが「一機撃破!」としゃべって欲しいのですよ
この時どうやってキャラ オブジェクトに情報を渡すか?
メソッド呼び出し(1)(2)は結合が強すぎてゲーム開発では使用しない
ゲーム内イベントで処理するのが一般的らしいのですが、実装する価値はあるのか、
あったとしてどのように実装すればいいのか。
一緒に僕の考えた最強のイベントシステムを考えたい。
390 :
デフォルトの名無しさん :2013/08/18(日) 18:16:32.62
能書きは良いからサンプルコードを
>>389 >敵タンクの破壊処理を敵タンクが行わないプログラマーがいたら2流以下
破壊メソッドをタンクに置いたところで
それ呼び出すのはdeleteするクラスだろ
392 :
デフォルトの名無しさん :2013/08/18(日) 18:26:21.80
え? ええ??
質問者の口調、状況提示の仕方や順番、思いと違ったレスをされた時の返し方、 いろいろ勉強になるレスだと思った。 俺も今後気をつけないとな
破壊イベントに関わるオブジェクトはダメージオブジェクトと敵機オブジェクト 破壊処理を敵機が持つとしてハンドラの呼び出し引数に渡すのは原因となるダメージオブジェクトと破壊された敵機オブジェクト。 移譲された側はダメージオブジェクトのダメージソースと必要なら敵機オブジェクトの情報を用いてメッセージを表示。 わざわざグローバルなイベント処理機構を実装する利点が見えない。
キャラクラスをシングルトンにしてどの敵からでもキャラを見えるようにすればいい
やりたいことが決まってて他人の言うことなんか聞く気ないのに、なんでここに書き込んでるのかわからないw
俺様が最強だとファビョりたいのだろう
398 :
デフォルトの名無しさん :2013/08/18(日) 19:42:23.67
んー、わかんない
>敵タンクの破壊処理を敵タンクが行わないプログラマーがいたら2流以下 お前の思い込み。 >メソッド呼び出し(1)(2)は結合が強すぎてゲーム開発では使用しない お前の思い込み。 >ゲーム内イベントで処理するのが一般的らしいのですが、実装する価値はあるのか、 お前の思い込み。 最初からこの3つを前提とできるような質問の仕方をするべきだったねw お前の思い込みに付き合う人はまだこのスレにいないみたいよ。 ここまで書かれる奴はばかだなぁと思うわ。
400 :
デフォルトの名無しさん :2013/08/18(日) 19:55:28.06
やられ方に合わせてちゅどーんをうまく定義するのが味のある映像の作り方だべ 誘爆を実装するなら接近キャラへの攻撃イベントだね、再帰のレベルに気をつけながら
401 :
371 :2013/08/18(日) 20:10:38.88
>>396 俺より頭のいいやつが無料でレクチャーしてくれるかもしれないからに決まってるだろw
問題点は理解した。敵タンクか破壊された時に、
(1) 爆発エフェクトを出してタンク オブジェクトを消す --> 敵タンクの役目
(2) 「一機撃破!」と叫ぶ、スコアを+100する --> 他のオブジェクトの役目
(イベントシステムを使わない)参照とメソッド呼び出しで(2)を実装する場合、
本来なら「敵のオブジェクトが行う事」を「敵タンクオブジェクトが実行」することだ。
これが最大の問題点。敵機撃破した時に何をしたいかは他のゲームオブジェクトのみが知っていればよく
敵タンクが関与すべきことではない。
敵タンクはイベント「敵機撃破」のみをブロードキャストすればいい。
(たぶんキューイングは必要)
しゃべったり得点を記録したりは他のオブジェクトが勝手にやること。
ここまでわかればあとはどう実装するかだ。
来週までの宿題な。
ここまで馬脚現しちゃってもう煽るだけか。 バカはかわいそうだな。
403 :
デフォルトの名無しさん :2013/08/18(日) 20:14:51.80
敵味方ともに、見ている現実は1つってことだな
これ「オブジェクト指向幻想」ってやつだよね。 無知って怖いな。
何のための砲弾なんだか・・・・ 砲弾抜きで、なんで爆破されたか? どっから飛んできたのかサーチして 方向一致してるタンクを見つけて「お前が撃破した!」って狼煙を上げるシステム作りたいのか? アホだろ
406 :
デフォルトの名無しさん :2013/08/18(日) 20:30:18.66
幻想は必要だよ 実行されるべき最適シーケンスは1つ おまえそれを全て書いて回っているのか いや本当にやってるなら恐れ入るが
イベントシステムは全オブジェクトが見えるわけですね。 ばかは怖いな。
408 :
デフォルトの名無しさん :2013/08/18(日) 20:48:21.92
うん、怖いな
409 :
デフォルトの名無しさん :2013/08/18(日) 21:08:57.23
ねえサンプルは?
コード出したら突っ込まれるから出しません
>>401 って、成りすましではなくご本人様? 衝撃なんだが・・・
ゲームプログラミングするときに堅牢な設計は害悪だわな 素人のアホがよくやること
まあ堅牢になってるならまだマシだが ただただスパゲティこねる奴の多いこと
>>401 敵タンクがブロードキャストする撃破イベントには誰に撃破されたかの情報ものせるん?
そのためには結局誰に撃たれたかを把握しないといけないわけだが
で、砲弾データ使うのを拒否してるわけだ 砲弾オブジェクトがあるにも関わらずだ ならどうする? ポコペンポコペン誰が突いたか? を100%の精度で当てるシステムを考えなきゃならん
玉にタンクのハンドル持たせる 衝突検知したら敵タンクに玉のハンドルとか火力とか渡す 敵タンク死んだら死亡原因オブジェクトを生成して玉のハンドルとかを渡す 死亡イベントに自分のハンドルと死亡原因オブジェクトを持たせてブロードキャスト これが正道
ブロードキャスト=なんでもあり
汎用的なやり方ってのはないような 何でもできるように作ろうとしてハマるタイプ?
420 :
デフォルトの名無しさん :2013/08/19(月) 07:41:26.67
やられたタンクってのは、きっと誰に何をやられたのかすらわからないうちに一瞬で吹っ飛ぶんだろうな
だからそれをゲームでやるなら 傍観者である審判システムがやる
自己満足のために?
テスト
かわいそう
423だって精一杯生きてるんだよ
428 :
デフォルトの名無しさん :2013/08/20(火) 00:39:00.10
自演がひどいなこれ
自演というかわざわざ数分あけて連レスする奇妙な奴はよく見かける
430 :
デフォルトの名無しさん :2013/08/20(火) 10:32:00.25
windowsのOpenGLで 絵を出せるようになったので、効果音鳴らそうと思います。 そこで色々調べたらOpenSLと言うのがmp3にも対応していて良さそうなのですがライブラリーが見つけられません。 どなたかインストール方法を教えていただけないでしょうか? よろしくお願いします。
OpenALじゃなくて?
432 :
デフォルトの名無しさん :2013/08/21(水) 18:03:47.82
OpenALはwavしか再生できなかったので、 別のを探していたらOpenSLを知りました。 jp.khronos.org よろしくお願いします。
DXライブラリでおk
今のマシンならmp3で効果音を再生しても平気なのかのう
435 :
デフォルトの名無しさん :2013/08/21(水) 22:23:14.10
組み込み向けのOpenSL ESならあるがOpenSLは無い
OpenBLなら神BLゲーが作れます
blBindLatexHurry
439 :
デフォルトの名無しさん :2013/08/22(木) 17:23:22.04
PrepairRawSync
mp3はライセンス絡みでやばいのでは?
Ogg Vorbisで良くね あるいはFLAC mp3とかメリットなくね? 効果音はデコード後のをメモリに置いてもいいかもしれない でもそこまでしなくても良くね?
メモリに置いとくくらいなら最初からwavでいいんじゃ… 配布サイズの問題とかかな
タイミング良かったわ。 初のAndroidアプリをそろそろリリース寸前まで来たんだけど、MP3使ってた。ライセンス問題なんて知らんかったよ。 ここの書き込み見て気になって調べて詳細を知った。OGGにしとこう。 THANX!
最近出たOggOpusとか言う奴はどうなん? Vorbisより低ビットレートでの性能が高いらしいが、ロイヤリティフリーなだけで特許技術を使っていないわけではないとか さっきOgg総合スレを見て知った ロイヤリティもパテントもフリーなのはVorbis FLACもそうかな? 効果音も配布サイズを最小にするため圧縮はしておきたい
自前でデコードするんじゃなくて、OSやハード側でサポートがあればmp3使ってても平気じゃね?
まさかmp3が再生できないAndroidマシンとかないだろうし
>>444 Opusなんてのが増えたんだ、軽くググったらメモリが減るかわりに計算負荷が増えるとか何とか
もし自分でmp3デコーダーを用意してきたのならそれにライセンス料がかかる恐れはある
OSとかブラウザのデコーダーを使う場合は確かにその心配ないね
ただmp3を配布するのにもライセンス料がかかるって話・・・だけれども
swfの中にmp3入れるのは配布ではないとmp3Licensingから回答があったとしているブログはあった
て事はAndroidのapkも問題無し?apkはzip形式だけどapkを取り出すのはちと手間がかかる
生でmp3をうpしないといけないHTML5ゲームではアウトか
https://www.scirra.com/blog/65/even-more-about-audio-licenses-on-the-web MP3ってOggVorbisより音質悪いと思うけどなぜ使う?素材がMP3しか無くて、再エンコードして劣化させたくないから?
デコードが軽いからとかじゃね?
安心・無難というのは武器
450 :
371 :2013/08/26(月) 17:16:03.60
いつの間にか規制が。
>>385 イベントシステム(メッセージ通信)とシーンから全ノードを名前で検索できる仕組みを実装してみたんだけど、すごくきれいに書けた。
受け取り側は MailBox (宛名)を作って、送信側は SendMessage (宛名、void*)で送るだけ。
こんなにシンプルで汎用的に作れるのに狂気の沙汰とかまったく同意できない。
ノードも文字列で判定するようにしたので不要な参照をシーンにばらまくこともなくなって超堅牢になった。
何でこんな簡単な事に反対する人間が出てくるのかさっぱりわからん。
ノードだろうとイベントだろうと文字列で持つに限る。
451 :
371 :2013/08/26(月) 17:17:56.95
toro.open2ch.net/test/read.cgi/tech/1377472860 じゃなくて toro.open2ch.net/test/read.cgi/tech/1377472860/ だな。。。バグ報告しといた。
>>450 それじゃまさに特定クラスに登録して垂れ流す処理じゃん。
しかも結局砲弾ID使ってるし。
ListenerとHandlerも知らん
メッセージパッシングっぽいな
ごった煮リストwww ゲームが複雑になるほどスパゲッティー一直線
457 :
デフォルトの名無しさん :2013/08/28(水) 08:48:50.33
ゲームにデータベースを埋め込んでキャラクターのHPとかをすべて データベースから取得するという実装はありですか?
MMORPGなどはDB使ってるが。
普通のゲームでお願いします
キャラデータそのものがデータベースの1枚のカードと同じもの
エスパーして
>>457 の戦闘力を分析した上での結論
無理
>>457 というかまともな商用ゲームは必ずデータベースを使います
データベースって言ってもいろいろあるよね…
・業務で使うDBMS(Oracleなど) ・sqlite ・その他自作エンジン エスパーすると、何も考えずDBMSをイメージしている可能性が高い したがって無理
RDBとかいうクソみたいなアンチパターンは捨てされ これからの時代はNoSQLだ
DBMSって本質的にはスループット、トランザクションへの対策だよな。 そこんとこに負担がないならDBMSでやる意味って、ないよな。 決まったフォーマットのデータを山ほどinsertしたり、 いろんなクエリを張っていろんな結果を返すようなことしまくったり。 ゲームで普通そんなことする?
ゲームならODBMSがいい感じだったねえ
469 :
デフォルトの名無しさん :2013/08/28(水) 12:58:15.31
>>457 ありだよ。
というか普通によくあるやり方です。
470 :
457 :2013/08/28(水) 13:06:28.01
ツクールなんて知らないです SRPGを作るのにユニットの攻撃力とか防御力をどう管理したらいいかと考えていて データベースで操作できたら便利だなと思ったわけで
データベースってのは、倉庫みたいなもんでしょ ゲーム内部でのパラメータ等の管理もデータベース経由ですべてやるのかしら
応答速度を重視しなければDBでやるのが楽
処理ごとのスクリプトがDBにぶら下がる構成にできると楽しい
>>470 sqliteのゲーム応用例はいっぱい出てくる
これからデータサイエンティストの時代が来るというのに
データサイエンティストって本当に科学者なの?
オブジェクト指向が基本のゲームプログラムとリレーショナルデータベースの相性は最悪
データセントリックな作りのゲームだと、 もしかしたらリレーショナルデータベースとの相性は それほど悪くないかも知れん シムシティとか
mdbにしとけ
通信環境ならともかくスタンドアロンでDB使うメリットってなに?
データを保存でき、格納形式やメモリサイズを構わなくていい。
じゃあコンシューマーではメリットなし?
ゲーム作る人間とデータ入力する人間を完全に分けられるのが一番のメリットだろ
dbとか関係ないやんそれ
>>481 DB使うかどうかにかかわらず、今時は全て分業じゃないのか?
リソースを持ちかたを考えなくて良くなるから楽 シングルトンとかモノステートと同じデメリット抱えるけどまあ何とかなるっしょ
考えなくて済むとかないわ dbmsは考えなくちゃならん事めちゃ多い ゲーム程度の規模なら自作したほうが頭使わずに済むよ
sqlite最強伝説
普通のオフラインゲームじゃ使い所が分からん ゲームエンジンみたいな規模になればsqliteとかのメリットが出てくるのかなぁ
データ照会にどれだけ時間がかかるか分からんもの使いたくねえわ ドヤ顔でsqlite持ち上げてるアホは10fps程度のカクカクゲー作ってんの?
頻繁に使われるデータとそうでないものは分けろ。 メインメモリとページメモリのように。
結論 ODBMSがベスト
メインメモリとページ"メモリ"ってどういう分け方?
マルチ・プラットフォーム向け、2D用のオープン・ソースのゲームエンジン、Cocos2d-xでは iOSは、IMA4。Androidは、Vorbisが品質面で推奨されますが、 MP3だと、同じデータを使える ところで、プログラム板に、Cocos2d-xのスレッドが見当たらないが
データ照会の時間気にしてるやつって毎フレームアクセスするつもりなのかよ
なんのためにデータベース使うの?
今月はこのスレが活況で喜ばしい レベルも高い
>>488 sqliteって非商用で最速の部類よ?
自分で管理オブジェクト作って掘ってるより、
インメモリのsqliteのがよっぽど速いと思うが。
>>498 いつまでそんな意味のないレスをし続けるつもりだ?
この先一生か?
501 :
デフォルトの名無しさん :2013/08/29(木) 18:17:31.81
ム板では「バカ」の定義は非常に単純
502 :
デフォルトの名無しさん :2013/08/29(木) 18:29:23.46
よくいる優秀なプログラマ。 ・自分は専門家でとても出来ると思いこんでいる。 ・知識も豊富でプログラムに詳しいと思いこんでいる。
503 :
デフォルトの名無しさん :2013/08/29(木) 18:35:53.29
その結果 試しも考えもしないで 「無理」「常識では考えられない」「馬鹿?」と 狭い知識で全力で言い訳や否定を行う。。 そしてプログラムより論破するのに生き甲斐を感じ始める・・・ 最近こんなPGおおすぎね?
504 :
デフォルトの名無しさん :2013/08/29(木) 18:43:36.15
思い込みかどうかはともかく、今んとこ食えている 自分の知識が広いだなんて、たわけ過ぎたことは生涯一度たりとも思ったことがない いつも否定から始めるコミュ障はPGに限らずまんべんなくいる つーか、スレチ マ板だろこれ
一つわかる事は「ここにはバカしかいない」だな
sqlite云々以前にそもそもRDB必要なのかって話じゃね
CVSやXMLとパーサだけで十分な処理しかしないなら態々事大主義になってもねと
>>457 の言うDBがどんな意図で使ったのか分からないとどうにも
>>506 正解
散々リレーショナルはゲープロではゴミ扱いって流れのあとでsqliteは非商用では最速なんだぜ〜ドヤドヤ
なんて言われても失笑するしかないだろう
オブジェクト弄りたいにしても、RDBMSよかシリアライズしてXMLなりで管理した方が 普通ゲームで使う用途だと楽じゃない?なんか話が無限ループしてるけど
考えが古すぎて笑っちゃう。 今時ゲームでdbにblob埋め込み取り出しなんて普通にやってるのに。
510 :
デフォルトの名無しさん :2013/08/29(木) 19:03:37.80
2chは8bitな人多いからねしょうがない。 でも可変数値を扱いたいといっているのにcsv,xmlとか・・・8bit以前の問題か。
やってるだけだけどな みんな間違いに薄々気が付いてるんだが 悪しき習慣として間違いを繰り返してしまう
お前らなんでそう脳までデジタルなの 別に絶対使うor使わないじゃなくて用途みて決めれば良いじゃない
なぜ私をスルーするのか? ゲームに最適なデータベースはODBMSです
>>514 確かにRDBより手軽。速度がどうかは知らないけど。
おっせえwwww for(int i; i = getDBIntValue("i"), i < 10; putDBIntValue("i", i + 1)) { }
HPを取り出したいと一言に言っても最大HPみたいなほぼ固定値を取得したいのか
現在HPをリアルタイムにDBから取得したいのか、まぁ
>>457 に出てきて貰わないと収拾が付かないな
えすぱーすると前者な気がするんだけど
518 :
デフォルトの名無しさん :2013/08/29(木) 19:22:34.52
>>514 漠然としすぎだからだよ。
ゲームに向いているのはオブジェクト思考言語ですとなんらかわらない。
だから答えようがない。
というか常識だし今更反応するのもな
>>510 多分彼はSRPGってつまりFEだのオウガバトルだの見たいな一面完結のシムを想定してるんでしょ
だと普通の表ベース管理でもそう問題無い気がするけど拙い?
コテコテのDoTA作りたいですとか言うなら話は別だけど
521 :
デフォルトの名無しさん :2013/08/29(木) 19:36:54.97
>>516 凄い遅いなテラワロタw
ところでこれ言語なによ?w
もうお前らで『ぼくらのかんがえたさいきょうのでーたべーす』作れよ zlibライセンスあたりで 良さげだったら使ってやってもいいぞ
>>520 そいつも大概RDB狂信してるだけだろ
二人で他所で煽りあってれば良いのに
524 :
デフォルトの名無しさん :2013/08/29(木) 19:43:43.36
>>522 いいね
まずはsqlをコンパイルしてアセンブラ化すればさいきょうだろ
規制解除されたからってそんな競ってレスしなくとも
盛り上がってるけど中身がないね 先週のイベントシステムの方が面白かった
dbファイルとバージョン管理システムとの相性が悪いみたいな話をどっかで聞いたような
なるほど 定義部は DML でいいとして データ側は もっと親和性のいいフォーマットがないかな?
MPバーが3本あるのですが、それを統一的に操作するにはどうすればいいですか? 例えば指定したMPから1を引きたいときにswitch分で enum MP{A,B,C} MP mp; int mpA,mpB,mpC; if(mp==MP.A) mpA-=1; if(mp==MP.B) mpB-=1; if(mp==MP.C) mpC-=1; と今はしているのですが、switch文にするにしろ、今後計算式が増えるときの根本的な解決にはなっていないような気がします。 もっとenumと(enumでなくても良い形式があればいいのですが)キーと値を密接に関わらせる方法はないでしょうか。 値本体は別で管理したいので、mapやDictionaryで持つのも違うかなと思っているのですが…… 値をポインタにして、キーをenumにすると一応解決するような気もするのですが相当気持ち悪い気がするのでそうするか迷っています。
何を聞きたいのかよくわからんがキャラクターごとにインスタンスを作れ そもそも外からenumを使って変更したいMPを選択している時点で何かがオカシイ 魔法を使ったらMPが減るとかなら自分の管理するMPは1つだろ
>>529 enumにMAXでも追加して普通に配列にしろw
int mp[ MP.MAX ];
mp[ MP.A ] -= 1;
switchやらifなんか使わねーからw
てかmpってなに?
int配列の変数名
MPが何かよくわからんがキャラクターの持ち物なら
>>530 そうじゃなくても 何かのクラスの持ち物にすればいい
int の配列は気持ち悪いけど オブジェクトの配列ならオッケー
と言ってるだけの気がする
そのレベルなら 言語仕様やコンパイラ挙動やメモリマップとかまったく関係なしに、 個人のご自由に気に入る方法で、とかしか言えないだろw
ポインタ渡しするようにすればよくね void minus1(int* mp) { *mp -= 1; } /* 使用例 */ minus1(&mpA); minus1(&mpB); minus1(&mpC);
プレゼンテーションと物理演算以外は全部.NETで十分だな プラプラめんどくさすぎ
538 :
デフォルトの名無しさん :2013/09/03(火) 20:30:58.68
ゲームはアイディア 何語で考えるかではない
そして出来上がる水中を歩くようなゲーム
540 :
デフォルトの名無しさん :2013/09/03(火) 21:11:12.00
それと馬車馬のように視野の狭いゲームと やたらうるせえだけで無味乾燥な作業ゲー
言語が壁になっちゃうならC#でいいんじゃないの 低レベルすぎるけど
手入れベル ジリリリリリリ… 「ヤバい、サツが来た!」 「隠せ、急いで隠せ!!」
ニートが親への言い訳でゲーム作るとか言い出したけどプログラムで挫折してこのスレを荒しにくる
>>540 人間をよーく観察してみろ。そしてスマホをいじっている自分を省みろ。
人間とは視野が狭く盲目で仕事やスポーツ、レベル上げなど同じ作業をバカみたいに繰り返す傾向があること。
ではその上の次元に存在する、生産者であり創造者たるプログラマは何をすべきか自明であろう。
他に聞くところもなさそうなんでちょっとお邪魔する お前らのところの仕様書って何で書かれている? 俺のところプログラマーのやつだけでなくプランナー>デザイナーの指示書も含め 全部Excelファイルでズラーっと大量にあるんだが、これ普通なのけ?
一般的
>>545 わかりました。もっと大きな画面のモニタに買い換えます。
エクセル以外を見たことがない
なぜWordで書かないのか
551 :
デフォルトの名無しさん :2013/09/04(水) 22:49:45.56
WARNING!! A STINK BOMB EXCEL FOSSIL - 549 IS APPROACHING FAST.
>>550 他の職種は知らんがゲームだと、仕様書というのは
ゲームを構成するありとあらゆる部品の製作状況を管理するためのものだ。
例えばゲームに登場する全ての魔法の名前、効果、消費魔力、エフェクトなどを表す魔法テーブル。
全てのBGMの名前、再生時間、容量(MB)などを表すBGMテーブル。
などなど・・・
テーブルを管理するのに Word を駆使しようと考える奴がいたらどう思う?
また、仕様書とは言うが、製作過程において今現在、各部品がどこまで作られたか、
という情報もたいていは書き込まれる。
例えば、BGMを外注するとして、それが完成して納品されたのか、発注前なのか、
発注済みなのか、リテイク何番目なのか、ということが仕様書に書かれることになる。
このような情報は製作過程においてどんどん書き換えられていく。
その際に、部品は全体で何%くらい完成しているのか、
どのカテゴリの部品がどれくらい遅れているのか、といった進捗状況が一目でわかると良い。
Excel などの表計算ソフトだと、そのような事をスクリプトで実現するのが簡単だ。
なんか[仕様]という括りから離れ過ぎたこと書いてね
エクセルとかパワポとか
>>552 進捗管理じゃないのかそれ
専用のソフトウェア使ったほうがいい
レポート出せるし
>>550 Wordは紙で出力するという絶対条件が無ければクソやで
エクセルって図書きやすいか?
ソーシャルゲームのアニメーションって何のソフトで作っているんでしょうか?
アニメーション作成ソフトじゃね、知らんけど
ソシャゲのキャラアニメーションと言えばさ、Maya2014 LT は使えるんかね
他人のExcelを編集する時が地獄だな 何も考えてないバカ(日本人サラリーマンの9割に相当)が作るExcel文書はロジックとレイアウトが完全に融合したスパゲティ構造だから編集のしにくさが異常
コピペした内容が勝手に変換されるとか 不規則なセル結合とか そういうのを除けば十分使える
>>555 専用ソフトの導入コストがバカにならないだろ。
Excelなら誰でも持ってるからどこで誰が開こうが見られるし、最低限の機能はある。
1個のファイルで全部完結させられるってことを考えるとExcelは合理的だよ。
これ以上にオールインワンなツールはないと思う。
>>563 tracやredmineのようなWEBサービス型のやつを使えよ。
どうでもいい
もっとプログラムの話ししようぜ
excel最強伝説とmayaのmel万能奇譚とC++無敵神話は似てる気がする
569 :
デフォルトの名無しさん :2013/09/06(金) 12:26:17.27
excelってゲームも作れるんだぜ! その下に仕様書つければ生産性高い。
よし、ExcelもExcelで作ろう
Issue管理と仕様書をごっちゃにするワルい子はいねがァ
実装データのテーブルってExcelで管理するものなの? 適当にツール作って取り出すようにしてるんだけど普通じゃない?
なんで普通にこだわる?
574 :
デフォルトの名無しさん :2013/09/06(金) 12:46:44.15
>>572 エクセル使うのも普通だし、自作ツール使うのも普通だよ。
異常のパターンってあるのかなw
575 :
デフォルトの名無しさん :2013/09/06(金) 12:49:21.98
汎用性あったほうがいいからだよ ソフトウェアの開発は普通が一番だろう
576 :
デフォルトの名無しさん :2013/09/06(金) 12:50:45.11
>>574 パワポで仕様書・データ管理とか?
見栄えは一番良くなるはずだし。
データを製品に埋め込む時はどうするん? まさか更新の都度コピペ?
579 :
デフォルトの名無しさん :2013/09/06(金) 13:00:04.45
プログラムでバッチ処理させればいいだろw
たとえ開発環境がLinuxだろうとExcelで管理するのがプロ
>>579 それならAccessとかのがまだ楽なんじゃないかなと。
582 :
デフォルトの名無しさん :2013/09/06(金) 13:21:17.91
プログラマーからみればどれも一緒って事だよw バイナリーが作れれば良いだけだしね。
ま、動いてればいいか・・。
エクセルの捜査官を継承しつつ あまり複雑でないXMLなりCSVなり吐いてくれればよい
585 :
デフォルトの名無しさん :2013/09/06(金) 14:20:08.24
捜査官のエクセルってキンタマの話かと思った
------------------------------------ ここからレベルの低い書き込みは禁止 ------------------------------------
推奨レベルLv15〜20
588 :
デフォルトの名無しさん :2013/09/06(金) 16:46:20.12
なら1つ質問です 物理シミュレーションのための RigidBody の3文字程度の略語に悩んでいるのですが、何が良いでしょうか
その質問はLV89だから駄目だな・・・ 悪いが別をあたってくれ。
Rgdぐらいでええんちゃうの(適当)
>>588 3文字程度なら2文字でもいいよな
RB でいいんじゃね
むしろ省略するなといいたい
Open-sshの設定わかんね
やっと水の流体シミュレーションできた 日本語の資料少なすぎ 実装してる奴ほとんどいないの?
595 :
デフォルトの名無しさん :2013/09/14(土) 02:51:21.52
>>594 おめでと!
ついでに質問
androidのJNIで以下のフラグを付けてexecをsjisで動かしたいのに変換できませんエラーがでる。
windowsのexecがSJISなのでアンドロイドも同じにしたいです。
誰かヘルプ!
LOCAL_CPPFLAGS := --input-charset=utf-8 --exec-charset=cp932
sjisは捨てなはれ sjisにない文字が普及してきてる
sjisがというかwindowsがもう
誰かやっててもおかしくないのに 日本語資料がネットに全然ないものとか 一体どうなってんのって思う 少子化で日本人の数減ればどんどん厳しくなるよな
いやいやプログラム関係はたいてい元々英語だし いやならひまわりでも使えばいい罠
物理エンジンまわりで日本人の姿がまったく見えない 非常に憂慮してるけどね俺は
君がやればいいのに
似非ナショナリストは他人を踏み台にするだけ
603 :
デフォルトの名無しさん :2013/09/14(土) 12:57:33.70
>>598 ゲーム制作者のための物理シミュレーション 剛体編
お勧め。
日本も本は沢山あるよ。
ネットで検索する前に必ずその分野の本を2冊ぐらい買って読んでから嵌ったらネットで調べる流れが良い。
調べる単語や流れが分かっているので効率が違う。
ネットで検索に引っかからない。 日本は終わってるっていう考えは開発者としてヤバいよw
やってるのはいるだろうけど、表に出ないだけじゃねえの
剛体の物理シミュレーションなんて現実の一般式になってる公式ぶちこむだけじゃん 光関係と軽量化をレンダラ含めて解説してくれる日本語が必要
物理シミュレーションは計算式に難しさがあるんじゃなく 多体の相互作用の扱い方と衝突の扱いに難しさがある
せやで 点で衝突するとか線で衝突するとか面で衝突するとかパターンが多すぎて 出来合いの使いたくなるわ
そういえばC++のboostも、いかにジェネリックといえどもジオメトリの衝突は 線分でやってるから完全な円に対する判定が無いんだよな
むしろ出来合いの使わない理由って何かあるの?
汎用品はできることが多そうだけど、反面、制約が多いからじゃね
>>610 欲しい機能が溺愛のに無いとか。
たとえば、粉体(水が多少染みた海岸の砂など)をシミュレートしたい、
岩や鉱物、結晶などが割れたり砕けたりするのをシミュレートしたい、など。
有料ライブラリにあっても、訳あってフリーのしか使えなければ、自作するしか無いし。
いやあるけど
>>613 ちょっと紛らわしいからアンカーつけてくれ
ニーズに合わんことはあるな。 パーティクル的なエフェクト用途で、プリミティブは球とプレーンだけありゃいいんだけど、生成・削除・更新をとにかく大量にこなせるヤツが欲しい、みたいな。 計算・シミュレーション系の汎用ライブラリは、ニッチな条件が絡んで結局自作せざるを得ない場合も多い。
水中のスポンジとかニーズありまくる
どこにあるのかさっぱりわからん
鬱蒼と茂る背が低い植物に対して、 手でかき分けたり、足で踏んだり、風でなびいたりする、 そういう計算を効率良くこなす物理演算も欲しい。 正確性を多少犠牲にしていいから、 動き方でオォッと思えるようなグラを作る方向で。 もちろん、そういう植物を大量にランダムに生やす生成システムも込み。 となると、自作するしか無いか。 生成システムだけならありそうだけど。
完成した頃には俺なんでこんなの作りたかったんだろうと鬱になりそうだけどな
で、完成した頃に出来合いのでもっといい感じのを見つけちゃうんだよな。
趣味なら勉強になるけど、仕事でそれやるとたまらんな
>>618 フリーではまだないんじゃないかな
CAPCOMがMTフレームワーク2.0と称した自慢のフレームワークを使ってるけど、
そのフレームワークにそういう機能(?)がある
そうやって大企業が自慢気に出してくるくらいだからかなり難しいんじゃないの
物理挙動って開発者の自己満足の世界だからな・・・
ぶっちゃけユーザーはあんまりそういうの望んでないんだけどな リアル指向より面白いもの作ることに力注げと
ユーザの操作によってインタラクティブにモノが動くと面白いと俺は思うけどなー
リアリティのある世界観から単純なゲームシステムを作り出せば面白くなる
ユーザーにとっちゃそれっぽく快適に動けばいいからな。 それに物理挙動で「面白い」と思えるのは一瞬だけだし、その暇があるなら絵でも描いてた方が……
そんなのより正確に「足が地面に接地」してる方が重要だし難しい
リアルタイムのボーン操作か。 斜面だと片足めり込んで片足浮くからな。
ユーザーが求める物理世界ってのはホウキにまたがって空を飛べるとかそんなもんだ
箒にまたがって急上昇した途端股から真っ二つに裂けてゲームオーバーになる物理世界も一部からは望まれそうだ
それは呪いのかかった箒です
だから仕込刀はやめておけと言ったんだ
>>624 >>627 それはそうなんだけど・・・
例えば「ワンダと巨像」で巨像に生えている毛のフサフサ感がけっこうリアルなんだが、
あれテクスチャを貼るだけでもゲームコントロールの面白さは全く目減りしないと思うんだ。
でもやっぱりあの毛のリアリティがあった方が、そこに捕まっている感がでて、
自分がその世界にいるという感じを強く受ける。
それがゲームプレイの楽しさというかワクワク感というか、そういうのに繋がつていると思うんだ。
コントロールの楽しさだけではない、プレイ全体の楽しさね。
他にも「ゼノブレイド」も同じで、やっぱり自分がそこにいる感を出して
プレイの楽しさを上げていると思うんだよ。
あのフィールド、オブジェクトがなくのっぺりしたテクスチャだけだったら、がっかりでしょ?
確かにそれでもコントロールの楽しさは変わらないけどね。
635 :
634 :2013/09/16(月) 11:49:59.97
すまん、後半のゼノブレイドの話は物理演算とは関係なかったな。
ワンダのふさふさも物理と関係ないだろw
637 :
634 :2013/09/16(月) 12:37:38.02
そうでした。 長々とごめんなさい、恥ずかしいのでこのレスは忘れてください。
>>634 ゼノブレは、のっぺりして見えないようにしてるだけで
実態のポリゴン数かなり抑えてると聞いたぞ
まぁそういうディティール表現はプログラマの技術的に可能だっとしても、レベルデータの作業量的な問題が立ちふさがるからな。
その上
>>624 ,627なわけで。
そういうの見てカッケーと思っても、小規模開発じゃ夢でおわりんぐ。
FF開発チーム「それでもリアル追求します!」 ユーザー「お、おう」
ワンダの毛は映像的表現以上に掴まれる場所のガイドラインとして機能してたけど、単なる草地じゃ費用対効果悪いんだよな。
>>641 > 単なる草地じゃ費用対効果悪いんだよな。
風でなびくのとは微妙に違うようにモゾモゾと草木が動けば、そこに敵が潜んでいるとか。
そのモゾモゾは多分黒ベタで表現できる そして○○アイテムを使えばマーカーが見えるよ! というお約束により プレイ進行とともに空気化される
そういえば、格闘物アニメとかでたまにある、 煙幕とか舞った砂塵に敵が隠れて、影やゆらぎを捉えて「そこかっ!」ってやるやつ、 ああいうゲームってなくね? リアルタイムでボリュームレンダリングできるようになったら出るかな。 QTEではなく、ちゃんとプレーヤーの操作でね。 もちろん「そこかっ!」はゲームキャラの用意されたボイスではなくプレーヤーの心の声。
心の声を読み取って音声を再生するわけか それはまだ当分先じゃねえかな
動画系の人はゲームとは違うやり方してんじゃね
>>644 それだけならフォグとビルボードだけでも十分な雰囲気は簡単に出せんじゃない?
戦場のヴァルキュリアの煙幕はそんな感じだった気がする。ゲーム的にはそんな意味なかったけど。
CoDMW2もそんなステージなかったっけ。砂嵐の中、敵に囲まれた街から脱出するみたいなステージ。
似たようなので当時オォって思ったのは、スプリンターセルだったかで、障子越しに敵の影が映るみたいな表現があったな。
サーチライトやフラッシュライトみたいな指向性のある光や自分の影が濃い霧や煙幕に当たったり、投影されたりみたいな表現をしようとするなら、リアルタイムでボリュームレンダリング的な事考えないといけないだろうけど。
いや、フォグとビルボードだけだと、アニメみたいな煙が渦巻いているような表現はむずくないか。 なんかこう、何層もの円筒の中心軸から外を見たような感じになってしまわないかと。 まぁ俺はやったこと無いから、意外に簡単にできるかも知れんが。
煙をかき分けながら登場は1ランク上の表現で実装する価値はあると思う ボリュームレンダリングがもう少し実用的な手法があればな
ゲームをそこまでリアルにして何求めてるの? 夢語るのは良いけど現実味増したゲームをプレイした子供や脳が子供の大人にどんな影響がでるかとかは考えないの?
>>650 そういうのはあまり考えないな。
子供にプレイさせるかどうかは、大人がその子供をどう躾けるかの問題だし、
脳が子供の大人がどうなるかは、周りの大人がその馬鹿をどう躾けるかの問題だから、
このスレとは完全に関係ない。
スレチな議論は他所でやってほしい。
652 :
デフォルトの名無しさん :2013/09/16(月) 21:28:10.58
リアリズムは飾り やっていて面白いかどうかがゲームの全てであり 飾りが似合うかどうかはそのうえに成り立つことでしかない
その飾りによってゲームは楽しくもつまらなくもなり得るよ。 飾りもゲームの大事な一部で、何が上位か下位か、というものではないと思う。 プレーヤーの感じ方に直結するよ。
androidアプリで、良くあるような2D脱出ゲームを作りたいと思っています。 無料で手に入れられるものだけで開発するには、何で作るのがおすすめでしょうか。 Flash、Unity、cocos2d、HTML5+Javascriptフレームワークなど 色々あり、どれに手をつけて勉強すべきかまじめに悩んでます。 私の経験としては、Javaで簡単なWebアプリの開発をしたことがあるレベルです。
>>654 Unity でいいよ
どうやって作るのかは、まずは自分で精一杯調べろよ
>>651 だとしたらリアル追求は3Dグラフィック系のスレか数学物理あたりでやったほうが良いのでは?
>>654 FlashかUnityだなぁ。少なくともHTML5+JSはない。
手をつけなきゃいけないこと多すぎて、2D脱出ゲー作りって本来の目的見失いそう。
まぁこういうのはどれに手をつけるかまじめに悩むより、どうやって目的のゲーム作るのかをまじめに悩んだ方がいいぜホントに。
みんな使ってるから〜とか、影響を受けたゲームが使ってたから〜で選んでいいのよ。
ライブラリとかフレームワークなんて、自分で暫く使ってみないと解らないことの方が多いしな。
>>646 だろうね。
ゲームで60fps出そうと思ったら1/60秒以内に1コマ描画し終えなければならないけど、
アニメや動画は60fpsだとしても1コマの描画に10秒とかかけてもいいわけだしね。
>>656 以前(と言っても随分前)3Dグラフィック系のスレで質問したら、
ゲームプログラムやそのテクはゲーム系のスレで訊いてくれと言われた
数学物理はどうか知らんが
ロッコちゃんて何の技術使って作ってるの
プログラム技術はあるのかもしれないけど 設計センスのある人はまだまだ、少ないみたいだね
いきなりどしたw
ゲームの設計ってそれほどアクロバティックな設計になるか? ある程度パターン化されると思うが……
馬鹿だね、下回りのことをいってるんだよ
665 :
デフォルトの名無しさん :2013/09/17(火) 11:41:41.10
アッー!
レンダリングの話なのか 衝突判定の話なのか マップ作成とかレベルエディタの話なのか
>>659 そこまでのリアルとなるとゲームやグラフィックスと言うより
物理シミュレーションの世界じゃねえかなあ
物理数学もある程度絡むだろうね、それだけでは終わらないだろうけど
>>667 まぁ、目的はシミュレーションじゃないからなぁ。
フレームレートを落とさず、画面に映る範囲のものが綺麗に見えるならどんな嘘でもつく、
というのがゲームグラフィックスの世界。
669 :
654 :2013/09/18(水) 00:10:52.95
>>655 >>657 ありがとうございます。Unityで一旦手をつけてみます。
SceneにCubeとかのGameObjectを置いて適当にさわってみてますが
わからなすぎるので、調べながら少しずつ勉強してみます。
>>669 本を買ったら「無料で手に入れられるものだけで開発する」ことにはならないのか?
俺は一冊Unity入門書(何でもいい)を買ってチュートリアルをこなすことを強く勧めるが
どこもかしこもunityだな
デファクトが1つに定まってリソースがそこに集まるなら それに越したことはない
AndroidSDKはなんかいまいち。 他の方法に比べて良い箇所がまったく無い。
元々AndroidってAndroidっていうベンチャー企業が作ってたのを googleがM&Aして自分のものにしてできたものだそうだから googleの優秀なエンジニアはあんまり開発に関わってないから 糞なんじゃないのかなあ
>>673 他の「方法」ってどういうこと?
どのような目的のもとでの話なのか、
例えばどういう方法があるのか、
もう少し詳しく説明してくれないか。
パズドラ大流行だな システム的にはそんなに難しくないだろう 宣伝の力かな CMはどこが作ってんだろ
パズドラはもう下降線だよ
678 :
デフォルトの名無しさん :2013/09/19(木) 04:53:40.75
「下降線」という指摘を、なにも引っさげずに言う者こそ、敗色を濃厚にしている戦犯だ なにも引っさげないことを悪とは言わない、なにか引っさげるのは幸運と才能の77であって宝石のようなものだから 臥薪嘗胆のような無駄な努力はいらんが、引っさげるまでは黙っていろ 駄作公害という用語を提唱する 人、とくに若者が何を考えることができるかを制限してしまう全てだ
コピペ?
下降線じゃなくて、頭打ちなんじゃね
681 :
デフォルトの名無しさん :2013/09/19(木) 05:22:07.35
オリジナルだ! 失礼な
なんか日本語不自由だね
アイちゃんは3行以上の文章を読めない
かわいい女の子モンスターを増やせばあと3年はいける
負け犬が何言ってもね
基本的には職人芸から科学技術への移行ができなかったのが衰退の原因だと思う
海外はもうかなり科学技術に移行してるよね。 CEDECでゲームコンサルという職を聞いてびっくりしたわ。
せめて社内ライブラリ化されればいいんだけどな
ん、ライブラリ化って何の話?
実は社内ライブラリと簡単に言うが 経営陣のちゃんとした方針とかが無いと企業として失敗する 社内ライブラリの作成、維持、更新のコストは莫大になるが直接の利益は出さない それでも、その社内ライブラリで作成するコンテンツの売り上げを見据えて許容するのか それとも安価な社外のミドルウェアやライブラリを使って(当然コア技術が無くなるが) 確立された技術レベルや作成スピードで利益を上げるのか そう言うのを考えないと コア技術が社外のミドルウェアやライブラリに依存してるのに そのあたりをゴニョゴニョしないと何も出来ない現場とかの企業は 上の思惑が正確に伝わらず、文句ばっかいって何も作れない現場になってるとか
ゲーム業界が先細り → 腕のいい奴が来なくなる ところまで見てれば社内ライブラリとか小さい会社が持ってても爆発するだけだと思う
ライブラリというかフレームワークだな 納期や品質をコントロールするために作るんだから フレームワークの規模は自然と事業の規模に沿う
社内のライブラリやフレームワークは それらを作ってメンテ&それらでタイトル作って、 そのタイトルの作業もって言うスーパー人材がいないかぎり、 どの会社もアップアップでライブラリやフレームワークに割く金がない で結局分散して、糞なライブラリやフレームワークで糞なタイトルが出来て 糞なキャッシュフローに陥って、糞な会社になっていくと言うwww
みんな大好きな完全版・第二形態・第三形態や マルチ展開は当然受け入れるっていう前提だよな
結局他力本願
697 :
デフォルトの名無しさん :2013/09/21(土) 18:26:07.96
ユーザが釣れるなら萌にも傾くだろ 釣れないならそうしないが
ゲーム作るうえで技術が問題になるのは 今も昔もグラフィックまわりだけ それ以外の要素はぶっちゃけ文系的要素
ばかは気楽でいいねw
ゲームなんて売れればなんでもいいしな
702 :
デフォルトの名無しさん :2013/09/21(土) 22:41:07.00
この業界の言論て、童貞とヤリチンだよね、まるで ナオンが釣られなければシコッてんだと、バカかwww
703 :
デフォルトの名無しさん :2013/09/21(土) 22:43:30.52
そりゃゲームは創作で創作はオナニーですから 科学技術的物理ゲームとか勘弁しちくり
ゲームが創作だっていう風潮が抜けない限り日本のゲーム業界に未来はないな。
創作でゃってるのは世界広しと言えども日本だけなんだから、 日本はこのままこの路線を進化発展させてほしいな
進化がないから今大問題なんだろ。
だから、このままこの路線を「進化発展」させてほしい 意地でも「進化発展」させてほしい
ネトゲも日本で作るより海外の持ってきたほうが安いし日本が発展するのは無理
日本人に不可能は無い
って根性論が通用せずにアメリカに戦争で敗けたがな……
今みたいに根性で作ってる限り負けるのは必然
>>707 だから今の路線ではこれ以上進化発展しようがないから頭打ちになってるんだよ。
さらに進化発展するにはゲームを論理的に突き詰める分析が必要不可欠。
意地でも進化発展するには結果的に路線を変える以外に方法がない。
世界を10次元で捉えることから始めないとな
それを11次元行列でぶん回すのか……
>>710 >>709 は精神論じゃないよ。精神論言い出す日本人はバカだ。
だいたいあの戦争は物理的に勝てる代物じゃない。
トランプや花札作ってた任天堂を世界を股にかける大企業にのし上げたファミコンのように
ブレイクスルーを日本人なら創り出せる
勝てる戦争をバカが精神論でぶっ潰したのが先の大戦
おあバカばっか
>>716 そうなのか?
普通に勝てない戦争だから(当時の知識人もだいたいそういう認識だったが)決して
始めるべきではなかったのに、なのにバカ(軍人的体育会系)が日蓮主義の八紘一宇
の精神論だとかで暴走して果てには日米開戦まで突っ走ったのが先の大戦だろ?
「勝てる戦争」とはいくらなんでも言えないと思うね。
ファミコンのロンチタイトルにピンボールってあるけど、 あれの当たり判定ってどうやってんの? 斜めや円形の壁と綺麗に当たって、 ちゃんと違和感ない方向へ反射して跳ね返ってるように見えるんだけど。 円と直線の交点を割り出すとか、真面目にやってんのかな。 あと、毎フレーム全ての壁と当たり判定処理してるのか、 それとももうこの時代から画面をグリッドに分けて、 玉がある付近の壁とだけ当たり判定処理することもやってたのか。 あれ、ロンチにしては地味に結構すごいことやってるなぁ、って思って。
あ、ロンチじゃないか まぁその辺は細かいこと無しで
>>715 それは法整備()やら人権()が尊ばれる前の時代だから出来たんだよ
それに株主に配慮せなあかん。マネーゲーム連中に夢への投資なんて真っ先に切られる
自由が奪われて機械的な生産しか出来なくなった日本に何が出来るんだ
利益優先で無難な開発しかできないんじゃ実験から生まれる大成功なんてありえない
iphone新機種にあわせてケースやら何やらで小銭稼ぎ それが日本の最新ビジネスです
プログラム関係ないボクの考えたゲーム論がやりたいならゲ製でやれよw
724 :
うゆ :2013/09/23(月) 15:50:48.93
ゲ ー ム P G ご と き が 戦 争 を 語 る な ゴ ミ ク ズ 大 東 亜 を 語 る な ら 、 知 識 つ け て 喋 れ や ク ズ 何 も か も が 的 外 れ 。
突然何だ、どうかしたのか?
ここ、北朝鮮じゃないよな。
727 :
デフォルトの名無しさん :2013/09/23(月) 16:10:26.87
どこの誤爆か、なんとなく察しがつく
ゲームで使われるアルゴリズムって、そこらの組込み機器よか複雑じゃねーの? 先にゲームで稼いでおいて、軍事用途へスピンオンすりゃいいんだよ
オウムがテロを起こした年代に、ドローンがあったらと思うと、ぞっとするよね!
複雑なアルゴリズムが日本から理論的に公開されることは皆無
アルゴリズムはシンプルであればあるほど素晴らしい
いやシンプルなアルゴリズムすらないからw
なにいってんの? おまえら
>>728 精密機器をはじめとする組み込み系だと信頼性が重視されるから
ゲームみたいに入り組んだ処理は逆に敬遠したい感じです
組み込みの場合はむしろ物理現象によるハードの外的影響が複雑だったり
なんだかんだ言ってゲームはユーザーがリセットしてくれるのを あてにしまくってるから
>>719 自分はゲーム系物理シミュレーションの勉強経験は皆無なので、数学の知識からの
ただの思い付きだけど、衝突判定のあるドットすべてに接線の法線ベクトルの向き
が既定値として登録されていて、ボールの衝突イベントが発生したとき、衝突した
ドットの法線ベクトルと、ボールの直前の運動方向のベクトルを比較すれば、角度
が算出できるので、あとは通常の物理で反発係数による軌道計算すればいいんじゃ
ないかな?
737 :
デフォルトの名無しさん :2013/09/24(火) 02:04:13.72
>>734 ハードほど入り組んだ処理を、
今のゲームプログラムでやっているのか? (疑問形。すごいウイザードを知っているので)
おまえゲームのパッドが空気嫁とか、そういう発想ないの?
物理現象(ヒヒヒヒヒ)をうまくドーパミンやエンドルフィンにつなぐのは
おまえらの存在意義だろうが
もう赤土と化した、かつて肥沃な腐葉土のあったところにしがみついてないで、
人を楽しませるという、ある意味医学とでも言うべき仕事に、おまえやる気あるか?
脳内物質の過剰分泌が見られますので 症状が続くようならば医師の診断を受けて下さい
このスレには基本的に頭おかしいやつしかいないよ
では全員医師の診断を受けてください
ゲームプログラムの技術なんて稚拙であるというとを認めたくない人が多いね
日本語で頼む
ゲームプログラムは汎用技術
俺はスーパープログラマー
ヨーカ堂勤務とか
頭いい奴がゲームプログラマーなんてするわけないだろ。
と、頭の悪い奴がほざいてます
749 :
デフォルトの名無しさん :2013/09/24(火) 21:18:27.08
>>747 真逆じゃアホ
そのゲーム界の神になるっちゅーことじゃ
おまえのほうが頭がええと思うなら今すぐやれ
カジノの大ボスになれるぞ!!
ぶっちゃけ今時ハード依存のプログラムなんて専門技術もいいとこだから、それ以外の仕事ができるかというとそうでもないのよね ライブラリ使わない仕事だからそこら辺も疎くなるし、そういう一つの仕事しか出来ない奴が威張ると典型的老害プログラマになっていく
日本語でおk
752 :
デフォルトの名無しさん :2013/09/24(火) 22:29:59.45
ぶっちゃけ野郎とはうまが合わないらしく一度もいっしょに仕事をしたことがない。 どれほど有能なのか無能なのか知りたい。
>>748 だって俺はゲームプログラマーだからなw
頭良い奴は誰がやっても同じ単純作業の仕事はやらんわ。
バカだったから気付かんかったわw
結構良い大学出たけど、30才でいまだゲームプログラマーやってるとか終わってるわ俺ww
ゲームは趣味で作って小遣い稼ぎが一番いい。
確かに頭悪いレスだ
>>754 きみは典型的なゲームプログラマーだねw
数文字のレスでわかるw凄く単純。
キミみたいかタイプは扱い易そうで嫌いじゃないぜ。
このスレって定期的に妙なのが湧くよな。
ゲームプログラミングのスレなんだからゲームプログラミングの話をしろ。
>>755 マ板でやれ。
自称ゲームプログラマーがマ板に行ける訳ないだろw
マ板なんか見たら、ホント底辺の職業なんだなと実感してしまい鬱になるだろw まあ板違いのお詫びに特別に何でも答えてあげるよ。 ほらプロの技術を聞くチャンスだぜ。
>>758 ■モルピグのタイムラグを抑える仕組みのうち最新のものを教えてください。
■モルピグによっては不正防止のため通貨にまでユニークIDを振っているそうですが、
現実の硬貨や紙幣と違って最小の\1単位まで自由に分けられる通貨をどうやって管理しているのでしょうか?
まさか\1単位でIDを割り振っているのでしょうか?
■なぜモルピグは平面座標で判定しているものが多いのでしょうか?
空間座標での判定は難しいのでしょうか?
>>758 ゲームで使える綺麗で速いスキニング方法教えてくれ
ダブルクォータニオンはいまいちだった
>>758 TPSの照準と弾道について教えてくれ。
普通のトカレフで何かを狙って撃ったとき、自分の視点から弾が出るわけじゃなくて銃から出るのにちゃんと当たるのは何でかね。
視点→照準、と平行にトカレフから弾を出せば弾道は視点とトカレフの距離の差そのままずれるから当たらないよね。
トカレフ→照準が合わさってるオブジェクト、にするとオブジェクトが避けたりして当たらなかった場合、オブジェクトより後ろで弾道と視点→照準の距離はどんどんずれるよね。
トカレフ―照準―視点の角度だけ誤差があるわけだから。
この辺りはどうやって調整しているんだ?
>>762 ピストルは平行でも照準誤差なんて1センチやそこらじゃねーか
TPSなんて1メートルくらいざらにある
>>758 ストリーミング再生を使って、ギャップのないループサウンド再生する方法は?
ストリーミングなのにループとはいったい
理想をひとつ想像すると、曲の最後まで行ったときに、先頭を読み出しておいてほしい。 今は単に、ストリーミング再生特有の、再生直後のディレイと、 最後まで行って先頭に戻った時に再びあるディレイがあって、ギャップ発生。
>>759 モルピグって初めてきいたわ、MMOのか2ch語か。
しかしなぜ問題形式wまあ試したくなる気持ちも分からんではないけどw
答える気は無くなるな。
>>760 ダブルクォータニオンを使う必要無くない?
モーションデータを再生してねじれ現象が起きるならデータの問題だ、データを修正してもらいなさいw
>>761 視点からの着弾位置を計算して、次に銃口から着弾位置にヒットレイを飛ばせばok!
>>764 なんか問題風だなw
768 :
760 :2013/09/25(水) 19:46:39.47
>>767 モデラーさんがmikotoのスフィリカルデフォームみたいの使いたいってずっと煩いんすよ
もちっと詳しく頼んますよー
>>768 モーションは何で作ってるんだろうか?
そのソフト上で再生して潰れるモーションなら潰れて正解だよ。
ソフト上でモーションを再生して潰れないデータを作って貰えばok。
俺も興味あるんで、そんな当たり前の事より、もちっと技術的な話をしてくれよw
無理言うな
長くなるのはめんどいなw
うわぁ・・・
774 :
デフォルトの名無しさん :2013/09/25(水) 20:48:59.86
>>762 拳銃に照準もクソもねえって
5m か、せいぜい 10m までの距離で重力は無視でき
先制攻撃なら片手撃ち、両手で構えるのは威嚇、
そして標的のほとんどが敵兵ではない特殊用途
>>769 自前のツール(自称売れるレベル)なんで、補間アルゴリズムなら変え放題なんすよ
もちろん次の奴からですけど
ほんじゃ、プロでも未だにリアルタイムのスキニングは線形ブレンドってことですかい?
776 :
デフォルトの名無しさん :2013/09/25(水) 20:56:36.64
拳銃にももちろん照準がある。 射撃場では基本的に照準を使わなければ当たらない。 適当に撃ってあたる距離なら石をぶつけても倒せると思う。 そんな感じ。 照準は凸と凹を合わせた時の形というかバランスで狙う。 距離でこの形を変えるので何度も練習する。 そんな感じ。
>>766 横からだが、2曲を交互に流せば解決するんじゃないか?
778 :
デフォルトの名無しさん :2013/09/25(水) 21:17:53.18
>>776 石ぶつけてもって、実際、拳銃はナイフなみの兵器やん
至近距離用で、先に抜いた者が圧倒的に優勢なわけで
シーンが射撃場の場合は全く性格を異にする
その理由が「敵が無抵抗」という点でもナイフと酷似
射撃場での成績は、ナイフなら彫刻の出来ってとこか
>>766 ていうかmp3はその性質上、データそのものにギャップが入ってるだろ常考
>>775 ダブルクォータニオンから スフィリカルデフォームから補完
お前は話し変わりすぎw揚げ足取りたいだけだろw?
まあ2chだしまともに聞いてくるプログラマーなんているわけないなww
>>780 ええっ、全部スキニング(頂点ブレンディング)の話じゃないすか
ほ、本当にプロっすか・・・?
782 :
デフォルトの名無しさん :2013/09/25(水) 21:41:28.08
照準を合わせる目についても知っておいたほうがいいと思う。 射撃場ではたいてい前に出られないようにテーブルでフェンスにしてあると思う。 そのテーブルに肘をつけて、まず両目で照準を合わせてみる。 その状態で固定したまま片目をつぶる。 次に、閉じる目を逆にする。 ここで、両目で見たときと同じ位置に照準があったままになっているほうの目が、 照準を合わせる目。 これは人によって違う。 自分がどちらの目で見ているか必ず覚えておく。
783 :
デフォルトの名無しさん :2013/09/25(水) 21:47:02.42
狙撃にはライフルだってば
>>780 これが別の話に聞こえるんじゃ、プロって言っても携帯電話ゲーっぽいなw
>>784 スフィリカルデフォームってのが知らんかったわw
フリーソフトが勝手につけた名前なんて普通知らんわww
>>781 普通スキニングでダブルクォータニオンなんてつかわねーよww
処理が無駄すぎるんだよ。
スフィリカルデフォームってのもフリーソフト独自の言葉だww
普通は頂点に重みをつけて処理だ。
独学もいいけど基本をもう少し知ったほうが良いだろ。
知ったかは良くないよww
>>785 いやホント、揚げ足取る気は一切無いんで、教えて下さいよ
プロでも未だに線形ブレンディングのままなんでしょうかね?
最近ジオメトリシェーダいじりだして、感動したところなんですが、
ポリ数増えて綺麗になるほど、破綻も気になっちゃいまして
破綻に関しては、モデラーの力量が大きいのも重々承知なんですが、
今時のプログラマ的には、それもどうよっていうですね
>>787 昔から球面線形とエルミート曲線が基本かな。
線形は処理が足りないときに使うぐらいだね。
エルミート曲線はマトリックスを使用して計算ができるから軽い。
バグったデータに合わせてプログラムを変えていくのもありだとは思うよ。
趣味レベルならありかな。
>>788 う、それはモーション部分の姿勢情報の補間方法っすよね
できれば頂点ブレンディングの補間方法を知りたくて・・・
俺の質問の仕方が悪くて誤解を与えてしまい、丁寧なレス貰ったのに大変申し訳無いっす・・・
ありがとうございます
あまり粘ってもしょうがないのでこの辺で失礼します
未だに線形ブレンディングっぽいなと分かっただけでも収穫でした
うーん線形というのだろうか・・・ 頂点の重みってわかる? 多分ダブルクォータニオンを使用してる時点でわからんと思うけど。 まあ昔からかわらんね。 変わったのはシェイダーで処理するようになったぐらいか。
頂点ブレンドに昔からエルミート曲線? 試しに一般的な重み付き頂点ブレンドの方法言ってみ?一行でかけるだろ。
>>791 それはモーション補間ね
揚げ足取らせてやったんだよw空気嫁ww
いちいち面倒な奴だな。
ググればいくらでも出ること書いてほしいのか?w
ほんとプログラマーはつつくの好きだねw
>>789 ・・・心底同情するわ。とんだ自称プロだな。
俺の知っている限りで悪いけど、未だに頂点ブレンドは線形だと思う。重みの和の平均を取る奴ね。
スフィリカルブレンド等の弱点をである膨らみを是正する方法はあるから、調べてみるといいよ。
ただし影響を与えるボーン数は制限されたけど。2つまでだったかな。
>>793 とりあえず嘘書くなよ。
ここはレベル低いね・・・
>>793 実は途中から諦めてましたが、そのうち識者が参加してくれるかなと
もしかしたらその方法のサイトみたことあるかも知れないっす
もう一度調べてみます、丁寧なレスありがとうございました
確かそれ、レジスタ数が足りなくて断念した記憶があるのですが、
最近SM4.0にターゲットを変えたお陰で、色々楽しめそうっす
プロっていうのは識者とイコールじゃないから多少はね
797 :
デフォルトの名無しさん :2013/09/26(木) 00:31:40.04
プロを自称するならUbuntu程度は使えないとね。
hudでのデバッグ用文字列表示がデバッグモードで糞重いんだけど なんかいい方法ないかな
799 :
デフォルトの名無しさん :2013/09/26(木) 17:03:16.77
マウスをクリックしたら呼ばれる OnMouseClicked (int x, int y) みたいな関数があった時に 自分がスプライトとしてこの関数はマウスカーソルが自分の枠内にいた時だけ呼ばれますか、 それとも画面全体でクリックしたら常に呼ばれますか
作った人に聞いてください
〜〜みたいな関数が<どこに>あるかで決まる
作ったのは私です OnMouseClicked(intx int y)はコンポーネントにあります 自分の枠内にカーソルがある時だけ呼ばれるためには「形状」が定義されている必要があってめんどくさい それならいっそ画面全部で共通で全コンポーネントで OnMouseClicked(int x, int y)が呼ばれるようにしたら? どっちがいいでしょうか
>>802 OnMouseClickedの中がif文だらけになって分量が増えるのを厭わないというのであれば、好きにすればいいんじゃね。
javaだとそれ用にglass paneが用意されてたりする。
既に自分の中で考えが固まっていてそれに沿わないことを言っても聞かない気がするw
そんなつまらないところで悩むのはオブジェクト指向じゃないからなのが垣間見れる。
>>802 自国にはプログラマ向け掲示板ないんですか?
WinMainのメッセージループ 16.6ミリ秒ごとに描くんだけど 画面と同期するの方法?
例えばDirectXならプレゼンテーションパラメータ辺りに同期オプションあるんじゃなかったか
この怪しい日本語は機械翻訳なのか
>>808 あるね
デフォだと勝手に同期とってた気が
811 :
デフォルトの名無しさん :2013/09/28(土) 21:37:29.65
まあいいじゃん 我が国の消費者にとって良いモノを作る人は国籍がどこでも 仕事とられる日本人こそ甘いんだから
812 :
デフォルトの名無しさん :2013/09/28(土) 21:50:04.89
技術や品質は一度も負けたことがないんだけど、見積もりでは簡単に負けるね。 単価が10倍違うからこればかりはどうしようもない。
813 :
デフォルトの名無しさん :2013/09/28(土) 21:56:13.35
歩留まりで圧勝したとして、 次の商談にそれは反映されているのかね カップラーメンに線量計あててビクーリする人が少なすぎる 我が国の国民性・・・ # 線量計もってなくても乾燥肉の味わかんね?
どこの誤爆だ
815 :
デフォルトの名無しさん :2013/09/28(土) 22:28:07.14
ということにしたいんならいいけどさ たとえば飛行機海苔とPGってどう違うのか疑問でね 特にクレカだのクルマだのさあ、おめーらも金とってんだろ?
>技術や品質は一度も負けたことがないんだけど、 どこの国の人ですか?
817 :
デフォルトの名無しさん :2013/09/28(土) 23:43:31.32
父がドイツ人なので外見はそう見えませんが、生粋の日本人だと思っています。
俺生粋の日本人だけど日本は領土問題の存在を認めるべきだと思う。
819 :
デフォルトの名無しさん :2013/09/29(日) 02:11:39.55
相手国の国旗を燃やす輩はブタ以下 領土問題は、汚物を消毒してから議論すべき問題だ
全てが明るみになればどうという事は無い問題なのだが
821 :
デフォルトの名無しさん :2013/09/29(日) 02:54:47.53
バカは死ななきゃ直らない 隠蔽体質は国家破綻しなきゃ直らない # もうスレチだから他いこうぜ この問題についてでもいいんだが技術的に話そうぜ #include <locale>
while(true){};
while(FALSE)
>>823 do{ 〜 }while(0); はたまーにやる
>>824 最後のセミコロンで無意味になっていないか?
バカが勝手にマクロの話だと思い込んだ説
doの構文をわかってない説
むしろ
>>822 のセミコロンは特殊な裏技か何かなのか
>最後のセミコロンで無意味になっていないか? これの意味が分からないw よくあるマクロだと最後に;つけるとムダになるからつけないとかいう話はもちろんあるが、 無意味になるとは意味が分からない
if _assert(x); else ... 無駄になるとかいう話じゃないべ
for(〜); { 〜 } ならたまにやって泣く
例えばゲームで、カードやモンスターが100種類あるときに、 怪物クラス、1つだけで実装するのか、 怪物クラスから、アメーバ、竜、ゾンビなど、 10-20くらいに分類して、子クラスを派生させるのか、 100全部、派生クラスを作るのか 皆さんは、いくつぐらい、派生クラスを作りますか?
????
824 名前: デフォルトの名無しさん [sage] 投稿日: 2013/09/30(月) 00:48:12.24
>>823 do{ 〜 }while(0); はたまーにやる
826 名前: ◆QZaw55cn4c [sage] 投稿日: 2013/09/30(月) 06:17:05.95
>>824 最後のセミコロンで無意味になっていないか?
カードならクラスに怪物の種類持たせるくらいでわざわざ継承しなくていいんじゃね
>>833 開きブレースをforの行末に置くか、インデントしたら?
俺は関数の頭以外のブレースは左に付けないな
>>834 怪物クラス1つだけで実装する
全部のクラスで派生していたら継承ツリーが爆発するから普通やらない
>>834 継承して全部別クラスにする。
インスタンスを作る側のソースが明示的になるし、後々の変更箇所も個々の怪物内で完結するからツリーが爆発しようとそっちの方が結果的にきれい。
840 :
838 :2013/10/01(火) 09:25:11.97
>>839 話にならないぐらい全くもって愚か
こんなのが日本のゲーム作ってるのか・・・
そりゃ欧米に負けるわw
怪物クラスが一個で、あとのバリエーションは単にパラメータか、 アクセッサで処理したらええんとちがう?
インスタンス?
インガスンガスン
>>837 行末より見た目は分かりやすいんだよな
インデントはなんのことか分からん
スクリプトってやつで書くらしい
>>832 ?
do whileは文でつよ?文は式の一部にはなれないんでつよ??
if (exp) _assert(x); else ...
848 :
834 :2013/10/02(水) 03:11:52.17
怪物クラス、1つだけで実装する人は、クラスに怪物IDを持って、 その値で、if、switchなどで分岐しますよね その分岐が膨大な数に、なりませんか? IDが、1-10はアメーバ、11-20は竜、21-30はゾンビなど、 系列ごとに決めて、またその中で、個別の怪物で分岐する? 複雑そうです それと、怪物クラスの数やデータが変わっても、 再コンパイルせずに、設定ファイルから、怪物クラスを読み込むには、 Luaを使いますか?それともXML?
IDで分岐だと外から数値を流し込みやすい
>>848 どういうゲームを想定してるか分からんからなんとも言えないな
そもそも固有の処理が必要なの?RPGなんかだと攻撃力なんかのパラメーターがかわるだけで
ほとんどの処理が共通の気がするけど。分岐する必要がないくらいに
あと普通はIDとは別に種別を持たせてそっちで判別することになると思うけど
書こうとおもったことはほぼ
>>850 がかいてくれていた。
あと、どうしても種類に個別な処理をさせたいなら、
手続きをコマンドオブジェクトとかdelegateとか使って単にパラメータ化して扱えばいい。
もちろん、そういう小規模な扱いで十分なのならだけど。
852 :
838 :2013/10/02(水) 09:39:45.84
通常は
>>850 だな。例えば敵によって思考ルーチンが違う場合は
外から注入する方式で。
ただ多少規模が大きくなるけど一番良いのは「ゲームオブジェクト - コンポーネントモデル」。
怪物の種類に応じてAIコンポーネントを作ってそれをゲームオブジェクトにアタッチできるようにしておくこと。
これだとどんな機能でも再コンパイルなしで機能を追加できる
一部の言語で(クラスではなく)インスタンスにメソッドを
ゲームを作るのにオブジェクト指向は向いてないです
それはオブジェクト指向かどうかでなくただのスクリプト利用の話に見えるが
関数型のモナドみたいに オブジェクト指向にもコレだ!と言える抜け道が必要なのだ
ゲームみたいなオブジェクトの塊こそオブジェクト指向向きだと思うが
いや、ゲームはオブジェクトをまたぐ処理が多すぎるからオブジェクト指向向きではないでしょ。 向いてるのはシーン遷移くらいだね。
んー、そういう事じゃないなあ 上で出ているように問題は"ゲームオブジェクト"と"C++のオブジェクト(クラス)"が1:1に対応しない事。 継承ツリーによる問題の細分化が不可能なこと うっかりすると継承が10段あってクラスが100個あるような巨大ツリーを作って地獄を見るけど、それは非常に間違えている 基底クラスの変更が全体に影響し変更コストは非常に高い 上で言ったゲームオブジェクト-コンポーネントモデルなら ゲーム全体でクラスの継承は2-3段もあれば十分作れて変更も容易
継承10段はオブジェクト指向よりも実装者のおつむの問題じゃね ろくに書けないから文句言っているだけに見える というかゲームオブジェクトコンポーネントモデルって何だ アスペクト指向のことか?
というか、
>>834 =
>>848 がオブジェクト指向が丸きりわからないで、
適当に用語を口走っている可能性が……
分岐を縦長(深く狭く)にするか横長(浅く広く)にするかというイメージで オブジェクト指向を捉えているのなら、それって全然オブジェクト指向じゃなくて ただの手続指向じゃないかと。
>>852 の発言「外から流し込む」からしても、オブジェクトを一種のサブルーチン(手続きの固まり)という前提で捉えていて、
そのサブルーチンにAIをパラメーターとして与えるというイメージで語っているんじゃまいか。
862 :
834 :2013/10/03(木) 02:02:07.56
ゲームのフレームワークを作るのは、 自分でツクールを作るのと、同じような気がしてきました それと、怪物、カード、アイテムの整理などに、 SQLiteなどのDBを使いますか?
ゲーム製作にooは必ずしも必要ではない これが解答
864 :
デフォルトの名無しさん :2013/10/03(木) 02:43:56.17
2chで質問してる暇があったら、さっさと自分でフレームワーク作って盛大に失敗して学べよ
と2chで野次を飛ばす暇のある
>>864 が申しておりました
>>861 スマン、834と838を間違えてたわ。
867 :
デフォルトの名無しさん :2013/10/03(木) 04:40:02.36
失敗したからっていい方法が分かるわけじゃない
>>844 例えばGNUのインデントスタイルみたいな感じ、まあ見た目は悪いがw
>>862 ゲームの仕様次第だけど、ネトゲ以外は普通DBを使わない
怪物やアイテムの種類数がゲーム中に増減したりしないから
>>868 うっかりセミコロンが紛れてるのが問題なので、GNUのインデントスタイルにしても
解決しないような
セミコロンが目立つようになるわけじゃないし
>>862 構造体の配列はそれは実際にカード型データベースだ。
配列で不都合ならリンクリストでも set でも map でも unordered_map でも必要なものを使えばいい。
sqlite とかはデータベースではあるけど DBMS と言わないと話が混乱する。
データベースを持たないゲームはかなり少ないし、DBMS を使用するゲームもかなり少ない。
ゲーム内ではなく開発時のデータ作成の話なら、Excel でも LAMP でもテキストファイルでも好きなのを使えばいい。
ゲームオブジェクト-コンポーネントモデルで話が通じないのはそのレベルなんだろうな
たかがゲームプログラミング されどゲームプログラミング
>>871 実態はともかく、構造体の配列を指して「DB」って言う人はいないから
混乱はしないだろ
ツクールやらウディタだってDBを積んでるだろ
877 :
834 :2013/10/04(金) 04:06:38.74
>>857 一般的に、大規模なシステムは、継承の階層を深くせず、
is-a(継承)よりも、have-a(実装、委譲、部品化)で設計します
その2者間で、どのようなクラス階層を構築すべきか、迷います
例えば、自分のアイデアと、オブジェクト指向が一致しないのです
ドラゴンゾンビが、竜クラスとゾンビクラスのどちらに属するのか?
両方のクラスを継承するのは、複雑すぎてムリ
ならば、竜とゾンビをインターフェースにして、両者を実装する?
もちろん、AI(戦略)をパラメーターで渡すなら、
単体攻撃、3:様子をみている、13:かみつく、28:踏みつぶす、721:毒
全体攻撃、414:泡、426:ブレス、821:毒
(3、13+721、28) (414+821、426+821)
どれが、竜クラスの攻撃か、ゾンビクラスの攻撃か、わからなくなってくる
あまり厳密に、継承を考えないほうが良さそうです。複雑すぎる
>>877 それは別次元のものを同次元に並べて考えている段階で無理がでる。
竜とか人型(ヒューマノイド)で分けるのがクラス。
だからドラゴンゾンビはあくまでも竜族。
ゾンビをクラス(種族)として捉えるのはオブジェクト指向じゃない。
ゾンビ(アンデッド)はあくまでも一種のステータス(状態)。
ステータスはhas-aの対象でしょ。
既出のようにどちらかというとコントラクトの一種で、アスペクト指向の次元に属する話題だね。
>>877 そのドラゴンゾンビというのは、あくまで人間が分かりやすいように決めた単なる「名前」でしょ?
名が体を表しているかどうかは、名付け親のセンスであって、本質ではない。
そのドラゴンゾンビと名付けられたモノが、実際にどのようなどのような能力を持ち、
どのような行動をし、どのように生息しているか。
そういう仕様を事細かに洗い出して決定するのが先決。
そして全てのキャラに対してそのような仕様を決める。
(後で追加するにしても、とりあえず今の時点で出ている全キャラについて決める)
それから、実装方法について考える。
それらの仕様は分類すると竜のものなのかゾンビなのか、他のものなのか。
分類したものはクラスの継承で表すのか、それともコンポーネントのアタッチなのか。
>>877 はどうも仕様を考える前に、クラスの有り様を考え、
それに合わせて仕様を考えようとしているように見えてならない。
ベストはこうやって抽象シーンノードに機能ごとに分化したコンポーネントを足していく。 // シーンノードの作成 var dragon = new Node("DragonZombie"); // コンポーネントの追加 dragon.Attach (new DragonBehavior()); // 動作 dragon.Attach (new Sprite()); // 表示 dragon.Attach (new Collision()); // 衝突判定 dragon.Attach (以下略); // パラメーター調整 var cmp = dragon.GetComponent<DragonBehavior>(); cmp.IsDead = true; ただこういうフレームワークから全部自作すると大変なので、 何かのゲームエンジンを使った方が良いと思う 上のコードは俺エンジンで書くとこうなるという例
おれの考えた最強のゲームプログラム
>>877 >竜とゾンビをインターフェースにして、両者を実装
ありえんwww
モンスターのクラスは共通 AIだけ差し替えるでFA
>>883 でおk。変数名や与えるパラメータで表現すべきことを、
クラス名で表現しようとしてカチカチウンコの継承ツリーを背負うことになる。
初代スレの
>>1 見てるか?
お前が軽い気持ちで立てたスレも今ではこうやって議論が行われるスレになってるんだぞ
>>871 じゃないけど構造体の配列をDBって言うことあるわw
MOSTERDATABASE g_monsDB[64];
とか構造体名や変数名に入れることもあるw
CSVファイルもDBって言うことあるw
>>882 モンスターの王様とウザさ最高峰のゾンビじゃね
888 :
834 :2013/10/05(土) 08:40:19.96
漏れのアイデアでは、竜にはブレス、ゾンビには毒攻撃の特徴があり、 ドラゴンゾンビは、両者の特徴を持っています ただ、そのアイデアがオブジェクト指向で表しにくい A+B=ABなら単純ですが、進化してABCになっている (または、特徴が減ることもある) あまり継承を考えず、ゆるやかな分類だけにしておきます ところで、キャラの魔法ダメージの計算式で、 デフォルトが100%で、ダメージ、小<100<大 0以下マイナスで、逆に魔法を吸収すると、考えていますが、 画面には、魔法防御力で表示したほうが分かりやすい デフォルトが100%で、防御力0以上のみ、小<100<大で、 ダメージは逆に、大<100<小となるが、 魔法吸収を表現できません。どうすべきか ちなみに、D&Dの影響で、ウィザードリィは、 AC(アーマークラス)のデフォルトが10で、 ACが小さいほど(マイナスもある)、防御力が高い これは、アメリカ人にはおなじみだが、 ドラクエからRPGを始めた、日本人にはわかりにくい
>>888 > A+B=ABなら単純ですが、進化してABCになっている
そういう時に使うのがコンポーネントの考え方だと思う
それなら基底クラスAttackBaseを作ってvirtual Attack () を宣言 派生クラスBlessAttack、PoisonAttackを作って仮想関数の実装だな モンスタークラスは自分の攻撃手段をインスタンス化して持っておけばOK ただこれが(十分だとは思うが)ベストかと言われるとそうでもない 例えば攻撃には武器が必要で攻撃力によって威力が変わるとき 現在装備している本体が持つウェポン情報にAttackBaseからアクセスする必要がある。 この参照は本質的に必要かと言われると必要ではなく、ない方がベスト また攻撃だけでなく同様の仕組みを他にも適応すると すぐにクラスが爆発して参照が入り乱れる 規模が小さいときはそれで良いけど大きいときはコンポーネントモデルの方がいい
何を言ってるのか分からない ■ゲームに登場するすべての攻撃のタイプ、IDで管理 0・・・ブレス 1・・・毒 2・・・以下略 ■攻撃クラス class ACTIONCLASS{ int ダメージの計算処理(); int エフェクトアニメーションのクラス(); etc }; ■モンスタークラス class MONSTERCLASS{ char *モンスター名; int *acttype; int actnum; int グラフィックID; etc }; これでactunmに2入れてacttypeに領域確保して、 攻撃のタイプIDを入れればいいんでないの acttype[0]=0; acttype[1]=1;
毒属性のブレスとかどうするん? 毒状態にする攻撃とか範囲攻撃とか攻撃時のアニメような特徴を それぞれスキルオブジェクトに追加していくのが得策
>>891 ActionClassの配列を(MonsterClassの下にではなく)別途一カ所にまとめて保存しておくメリットがない
あとActionClassから呼び出し元の情報にアクセスしたい事は普通にある
>>888 > ただ、そのアイデアがオブジェクト指向で表しにくい
それを表現するのが目的ならガンガンクラスを作ればいいし、竜やゾンビの振る舞いや、毒の効果を委譲かなんかで実装して合成クラスを作ればいい。
そういうルールのゲームを作るのが目的なら、それを表現できるフレームワークを作るべき。そのフレームワークを作るにはオブジェクト指向は向いているだろう。
だいたい、そういうのをハードコーディングすると、少し変更してまたテストプレイ、というサイクルを回すのに毎回リビルドが必要になってだるい。
クロス開発の時にはリビルド&再実行の時間が長くなりがちだから、スマホとかコンシューマだと特にだるい。
で、外部データファイルに記述するようにして、ボタン一発でリロードしてやり直せるようにする。
今出てる程度の話だと、
struct Attack {
const char * name;
int damage;
enum TargetType target; // 単体/グループ/全体/etc...
struct AdditionalEffect { enum Effect effect; float rate; };//特殊効果と発動率
std::vector< AdditionalEffect > additionalEffects;
};
struct Monster {
const char * name;
unsigned int hp;
struct AttackPattern { Attack attack; float rate; }
std::vector<AttackPattern> attackPatterns;
};
くらいで十分ではないだろうか。
毒ブレスでも十分に表現できる。
攻撃対象選択とか特殊効果なんかは id じゃなくて委譲の方がすっきりするだろうけど、外部データはこんな感じだろう。
でもまあ、どうせ後で色々仕様変更していくと、きれいに表現できない例外が出てくるんだけどね。
あっちゃ、nbsp が・・・
nandokuka breath splash
ここの人達は一本のゲーム作るのにどのくらい時間かけてる?
五 年 ドンッ!
ゲームオブジェクトを削除するときって、こういう仕様は有益? Destroy(gameObject, 10); で、10フレームあとに削除。その間はシーンにそのまま有効なまま存在。 この10フレームの間は無効化した方がいいのだろうか 例えばこの間は更新処理と描画処理はストップするとか・・・
>>899 それが有益なタイプのゲームもある。
ボーナスアイテム(フルーツとか旗とか)が画面に出て、数秒後に消えるとか、
なにかトリガー(それに敵が接触したとか)があってから数秒後に消えるとか、
そういう仕様だと Destroy(gameObject, 10) という仕組みも理にかなっている。
これはゲームオブジェクトのライフタイムの話だから、
更新処理はどうするか描画処理はどうするかという話とは切り離して考えるのが普通。
更新してもいいし、続けて描画してもいいし、しなくてもいいし。
今時フレーム単位ってまだ主流なの? 時間単位じゃないの?
個人レベルで可変フレームレートにする意味って結構薄いんだよね。
本当に可変フレームレートにするとデバッグで死ぬ
可変フレームレートのゲームってどういうメリットがあるの?
可変にする必要はないけど、スキップはできるようにした方がいいかもしれない
906 :
899 :2013/10/07(月) 08:51:39.24
それは質問の意図と違う オブジェクトのライフタイムはDestroy()の仕様とは無関係 安全にオブジェクトを削除するためには猶予期間を置いた方がいいのかどうかが質問の意図 そしてその猶予期間のオブジェクトはどうあるべきか 完全に有効なままシーンに置いておくのか、一部機能を制限して見えないようにしておくのか・・・ どういう仕様がいいのだろうか
あんたが考えていることは、 そんな重要なテーマではない。 自分がしたいようにすればいいだけ。 問題はいつも、生存期間をこっちが完全に把握し、 見通しよく運用できているかどうかだけ。
フレームレートの話題は ■描画のフレームレート ■処理のフレームレート ■両方のフレームレート のどれかを明記してください
909 :
900 :2013/10/07(月) 12:34:14.09
>>906 完全に取り違えてたな、すまなかった。
ただ、できることなら
「安全にオブジェクトを削除するためには猶予期間を置いた方がいいのかどうか」
これを初めに言って欲しかった。
なんとなく俺がバカみたいだ。
>>906 確実性を求めるなら、猶予期間ナシで削除できる仕組みにすべき
どうせ個人だしテキトーでいいよとか、開発終盤でもうどうしようもないよってのなら
遅らせてごまかすのもアリ
911 :
899 :2013/10/07(月) 13:05:20.52
>>909 ごめん
確かにミサイルとか10秒後に自爆は普通にあり得る
もともと即座にオブジェクトを消すといろいろ不都合があったので
1フレーム遅らせて削除する仕組みを作ろうとしたら、何も1フレームに限定する必要なくね、
その期間中のオブジェクトは通常通り有効なオブジェクトのまま保存するか、
シーンから取り除いて別に保存しておくべきか、あるいはetcと考えて質問した見ました
取りあえず実装してみたけど変更は用意なので、
Destroy (gameObject, time);
にしてtime時間後にフレームの最後で削除、その期間中は普通に有効のままにしよう
ありがとうございました
912 :
899 :2013/10/07(月) 13:11:21.44
にしても保管所として作ったのが GraveYard(墓場)クラスでメソッドが Bury(埋葬する)は名前変えないとな・・・ まだ生きてるし
>>906 907の回答で十分だとは思うが、例えば即座に削除できない場合の
例としては、描画エンジンが必要とするからというのが挙げられるだろう。
この場合、例えばスマートポインタを使うことで、所有権の管理ができる。
元々の所有者がまずあり、描画エンジンに描画を依頼する。
この時、双方が所有権を共有する。
描画エンジンは、描画に必要無くなれば所有権を放棄する。
全ての所有者が放棄した時に、実際に破棄される。
元々の所有者が放棄したが、描画エンジンが必要としている場合、
描画エンジンがそのオブジェクトを必要としなくなった時点で全ての
所有権者がいなくなり、破棄される。
他にも色々な実装例があるけど、ともかく、不要になったら消していいけど、
必要なうちは消しちゃダメ、って時に、要不要をちゃんと判断しないといけない。
10 フレームがどういう根拠でその数字が出てきたのか分からない。
根拠がないならダメ。
その上で、899 にあるように、削除予約の状態にあるオブジェクトは
生きているけど更新と描画を行わないというのはよくある実装。
使っているか分からないが数フレーム後に削除すれば良いやとかそんないい加減なことをする理由が分からん 参照カウントすれば確実なのに
生きてる死んでるであるとか、 墓場クラス埋葬メソッドとか、 そういう、有機的な発想を設計にもちこむよりは、 従来の、リストに追加、削除といったシンプルないつもの方法で表現したほうが単にスッキリ。
>>912 遊戯王カードゲームやると
墓地はリソースで、どんどん墓地に落としたほうが有利だとか思うようになるぜw
917 :
デフォルトの名無しさん :2013/10/07(月) 18:56:33.42
>>914 参照カウントなどという負け犬思考の実装は不可
誰が誰を参照しているかはプログラマーがきちんと管理すればいい話
>>917 おまえマルチスレッドで作ったことないだろ
>>917 お前よりも負け犬の方が遥かに役立つ
お前は負け犬以下だよ
>>917 それは言い切るとは漢。気持ちいいね。
>>918 C++, Java, C#で色々なものをマルチスレッドで作った来たけど、
マルチスレッドの場合最大の関心事は同期。結局はそれだけ。
参照カウントに手が伸びちゃうようなときって、多分参照の管理が入り組んでるんだろうな。
ウンコしといて消臭剤ぶっかけるが如し。
ゲームプログラムとは直接の関係はないですが、ちょうど参照カウントの話が持ち上がっており、 せっかくの機会なので質問させてください。 参照カウントを使わず、どう参照しているかをプログラマが把握しておく方針の場合、 実際にちゃんと問題なく意図通りに参照されいているかというのはどうテストしてるのでしょうか?
お前ら断片化とか考えないの?
組み込みでもない限り気にするだけ無駄 また宗教戦争でも始めるつもりか?
参照カウントを使える所で無理に使わないようにして訳分からんコードにしたいのなら もう勝手にしやがれ
たまにこう知識水準が10年前ぐらいになるな、このスレ
■禁止事項■ 以下の話題は宗教戦争になるので自粛してください タスクシステム フレームレート マルチスレッド 参照カウント
具体性のないへたれ
929 :
デフォルトの名無しさん :2013/10/07(月) 23:04:27.34
宗教戦争じゃなくて議論ができないだけじゃん
>>922 実際使う量の倍以上メモリがあるなら気にしなくてもどうにかなる
カツカツの場合、確保や解放のタイミングが限られてくるから断片化はやはり気にしなくておk
タスクシステムとか議論以前のゴミじゃん
日本古来のタスクシステムはいらなかったがいまはジョブマネージャーのことだったことにしている
自分で制御すれば断片化を防ぎつつ参照カウントを付けられるだろw
自分で管理できるなら参照カウントなんていらない
ナマポ欲しいです><
バーカバーカ
タスクシステムってなに?
テーレーレーレレレ テーレーレーレレレ テーレーレーレーレレー ガチャン ピロリッ ブーッブーッブーッ
もっかい聞くぞ? で、スマポ使わないのが漢なわけ?
ガラケー使いです><
ガラスマ使いです><
unityはタクスシステム?
944 :
うらま☆ :2013/10/10(木) 23:22:38.10
うわぁ...
全体的にスマポ使えるならそっちの方がいいんだろうけど、 ナマポもやっぱ必要だしとか混ぜると途端に面倒になるからもうナマポでいいじゃんってなる
C/C++ならいいんだけどJavaとかJavaScriptとかあっち系の言語でゲーム作るのって難しくね? マウスがクリックされたら動作するやつとか、 C系ならゲームループの中でマウスクリックを検出してそのフレームに反映させられるけど、 Java系だとマウスクリックされた瞬間にフレームとか関係なくいきなり関数が発動するだろ。
コールバックの中で処理はしたくないな .Netだけど一度キーバッファーに全部格納して 後で自分の好きなように使ってる
二次元配列で表したマップで、Excelのようにセルの結合を適宜行いたいのですが、どうすれば上手く実装できますか? 方向キーで移動できるようにしたいのですが……
>>946 何この話?
フラグ使えばいいだけの話じゃないのか?
951 :
デフォルトの名無しさん :2013/10/11(金) 19:13:16.80
そんな馬鹿なw
enq, deqを念のため排他にしたオブジェクトを使えばいいんだよ。 fromeventdispatchthread.enqueue(e)
ゲームループなのかイベントドリブンなのかの話じゃね
実際にはフラグよりキューがいいな ダブルバッファにしておけば排他制御もシステムだけでよくなる
ループ管理よりイベントドリブンが優位な実装ってゲームじゃ難しいだろ アニメーション効果のあまりないオセロやマインスイーパータイプしか思い付かん
イベントドリブンが優位、っていう発言が謎を呼ぶ。 そこには単に、イベントディスパッチスレッドと、 ゲームループが走ってるスレッドが対等な関係であるだけなのに。
イベントドリブンを何かと勘違いしてね
ばかばっか
ばっかばか
960 :
ゲームプログラムなら俺に聞け29 :2013/10/12(土) 00:46:17.88
980を越えると途端にdat落ちしやすくなるんじゃなかったっけ 970あたりで立てておいた方が安全じゃね?
>>962 そうなんだ。
じゃ970にして、テンプレも「
>>970 が立てること。」にしておくということで、どう?
>>948 俺ならHTMLのテーブルに倣うかな。
テーブルのセルの結合に使われるcolspanやrowspan。
二次元配列の各セルにそういうフラグを持たせて、処理や描画のときに参照する。
struct MAP{
int tip;
int colspan,rowspan;
};
MAP mymap[100][100];
描画のときとかはforで回してると思うけど、例えばcolspanが4なら4セル分の大きさのセルを描いて、後の3セルをスキップ。
rowspanがちょっと面倒だけど縦方向のスキップを数えるフラグ立てながらやれば何とかいけるだろ。
for内でフラグ立てながらやるのが面倒なら構造体の中のcolspanとrowspanをそれぞれ1がデフォルトってことにして、
0ならスキップというルールにしてもいい。
これなら結合時に値をセットしておける。
>>948 のやりたい事は2行目の「方向キーで移動できるようにしたいのですが…… 」で、
それと1行目のセルの結合(はあ?)がまったく関係していないところが凄い
セルの結合とか何言ってるんだと思う
話は完全に変わるが、セルの結合、っていうのって、 プログラマや技術屋からは出てこない発想だよなw まぁ、人は正規化のみに生きるにあらずなんだろうけど。
?
??
土壇場になってくだらない仕様変更を言い出す
>>961-964 に対する裁判員裁判を開廷します
ついてはすみやかに
>>950 は次スレを建て、障害を取り除いて下さい
LaTeXなら \multicolumnとか、HTMLならcolspan, rowspanとかあるし セル結合ってのは表なら普通にある発想では
ゲームでは絶対に出てこない発想だがな
人造人間と結合してパーフェクトセルになるという話
>>965 ありがとうございます。
なんとか上手いこと実装できそうです。
>>975 実装しない方が良い。間違えた方向に努力するのは時間の無駄
タイルマップで例えば2x2のタイルがあったら、それは4つに分割して描画するのが基本
>>975 結合せずにグループ化で対応できないかね?
セルの結合なんて糞 二次元配列こそがうつくしす
スプレッドシートって単純な配列でやってるわけじゃないだろあれ
俺なら基本はセルの二次元配列にするなぁ。 スパース行列みたいにしたり、リストにしたりするより結局シンプルだと思う。 エクセルとかも行と列に限界決めてたはず。
見た目だけ結合して内部的には結合させなければいいだろ □□□□ □□□□ こういうテーブルがあって、 真ん中の2*2を結合させる場合、 □□■□ □■■□ こうやって左上のセルに2*2だという情報を持たせて、 それ以外の3セルに使用不可フラグを立てればいいだろ キーボードの右を押してフォーカスをこの結合セルから右のセルに移動させる場合は、 1つ右のセルのフラグを調べ、使用不可ならもう1つ右のセルのフラグを調べ・・・と繰り返して 使用可能なセルにたどり着いたらフォーカスをそこへ設定 下段の一番右のセルからキーボードの左を押した場合は、 使用可能なセルが見つかるまで左へ一つずつ検索し、 見つかったらそのセルのサイズを調べる、 それが1*1なら一つ前へ戻って今度は上に向かって検索 あとは分かるな?
> 内部的には結合させなければいいだろ いやw さすがに内部自体を結合させるようなアホ(あるいはそれでやりきる天才)は居ないだろうw
二次元配列キモい。 データ本体を格納する一次元配列と、その各行の先頭アドレスを格納するアドレスの一次元配列で構築すべきである。 そのほうがサイズを可変にできて良い。
テクスチャ全否定
>>965 >>982 の実装方法が現実的でスマートなんだろうけど、本当に内部的に結合する方法ってあるもんなんかね。
あればシムシティみたいなゲーム作る時楽になりそうだが。
頭悪いの?
一つになりたいのか
セルを座標と大きさを持つオブジェクトとして定義したらいけそう ただ948のような場合はメリットがないと思う
一般的に、セル自体が座標を持つのは地獄見ると思うw 配列の中身にインデックス持たせて後々整合性のケアに悶絶したやつ多し。
セルの結合の話になってるけど、
>>948 がマップがどうのと言ってるところを見ると、セルのグループ化のほうがいいような気がするんだ。
別に座標は単一のセルのままでよくて、座標の移動処理だけの問題かと。 セル化したやつはグループID付けて、キー入力処理は上下左右のベクトルに従って、 同一グループではないところまで進めるみたいな。カーソルとかを結合したセルのサイズに合わせるのも一緒。
>>991 もともとこの話はナナメ読みだけど、
俺も結合の表現は、結合グループの管理をメインにするな。
元がセルの二次元配列で、あとはそうやって、表現上のゴニョゴニョは管理。
そもそも標準サイズ以外のサイズを導入した時点で負けている 何をやりたかったのかはよく知らないが恐らく無駄な努力を頑張ってる
>>955 でもなんというか、フラグ使うにしろキューにしろ、
マウスゲーのオペレーション部分(イベント発生部分)を言語の標準ライブラリで
拾えるってだけでもそこそこ優位と言えなくもないかもしれない?
JavaならSWT・SWING・FXあたりがあるけど、SWINGとFXの中間が欲しいよね
SWINGより精錬された仕様が欲しいけど、FXは静的なデザインに最適化されすぎているというか
>>986 シムシティみたいなゲームの場合は結合するとかしないとかそういうレベルで考えないほうが良いと思われる。
3x3の建物が建つ場合でも、結合ではなく3x3のグループを作ってグループIDを割り振り、
そのIDと建物オブジェクトのIDを関連付けする。
いちいちグループIDって必要?
シムシティタイプのやつを作るんなら俺グリッドを用意しないな。 衝突検出用のツリーみたいなもんに座標とリファレンス管理さす。 そうやってぶつからないかぎり、x, y, w, hを自分で持っとく。 で、ゲーム無いとしては団地リスト、工業リスト、商業リストの三本などをもっとく。 ゲーム内では基本的にそのリストだけ見てる。 新たに割り当てる時だけ衝突検出に頼る。 とおもったけど衝突検出も単に平坦に、そこにあるかないかだけなんで、 フラグの二次元配列で十分だな。
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。