C/C++ゲーム製作総合スレッド Part3

ところで上の方でファミコンやスーファミの
ゲーム開発をするみたいなことを言ってる人がいるけど
どうやって作るつもりなのかが気になる

ファミコンは8bitプログラムで
スーファミは16bitプログラムなわけでしょ？
で、今、動かしているWindowsパソコンは32bitか64bitなわけです
当然、プログラミングはWindowsで組むわけですよね？
で、ゲームをプレイする時もWindowsでプレイするわけでしょ？

つまり、先に8bitか16bitのゲーム本体を作って
そのゲーム本体で動くゲームを開発するということですか？
すっごく大変な作業になると思う

なんだろ、凄い知識が偏ってるね。偏食はいかんなぁ。

>>622
>32bitならeax ebxとかのレジスタで32bitフルで使える。
まじですか？
それは初耳です
いつから32bitレジスタをフルで使える仕様になったのですか？

32bitの上位の16bitの領域は、
ビット番号もなければ名称もないので
そこを使うことは出来なかったはずです
ただ、上位の16bitを下に降ろしてくれば使えますが

>>628
そうですか？
だって、Windowsの上で動く16bitプログラムを実行するわけでしょ？
32bitOSの上で16bitプログラムを実行するなんて可能なのですか？

ボクが考えるに16bitのOSを先に作って、
パソコンの電源を入れた時に
Windowsを起動せずに16bitOS（ゲーム本体）を起動させて
その16bitOSの環境下でスーファミ（16bitプログラム）を起動させるなら話が分かります

ねぇ、最近の質問者ってみんな釣りなんだろ・・・？ねぇ（怯え声

intがひと昔前は-32768〜+32767だったのを知らんのだろなあ

>>630
64bitのwindowsに32bitのソフトをインストールしても動くけどあれはなんなの

>>630
ちなみにC言語ができた当初は16bitはおろか8bitのCPUしかなかったと思うんだが？

ID:gc/L8yIj = ID:pJKr/LeY ですから

>>629
なんで16bitで計算する前提なの

学校の課題レポートを手伝うのはやめたほうがいいよ

>>630
マジレスすると、CPUには仮想モードってのもあるしエミュレータと言うソフトもある。
携帯アプリ開発なんかはエミュレータを使うだろ。
そもそも普段のゲーム開発でCPUの細かいアーキテクチャを意識する必要はない。
ボードゲーム作るのにサイコロの化学的組成を意識する必要がないのと同じ。
化学的組成は知ってるけどサイコロがどこで買えるか分からない、そんな風に見えるよ。
習いたての単語を並べて悦に入りたいようだが。

それは言いすぎだろう。
単純に「形から入るタイプ」「頭でっかち」なだけでしょ。

>>627
FCやSFCのソフトを作るって意味ではなく
FC、SFCレベルのクオリティーの事

>>640
その意味で使われるFCレベルって、どっちかっていうとゲームウォッチレベルだったりするよなｗ

俺もマジレス。

>いつから32bitレジスタをフルで使える仕様になったのですか？
元からだし。じゃあなんのための32bitなのかと

>ボクが考えるに16bitのOSを先に作って、
スーファミにOSはいりません。なんのためのOSなのかと

>その16bitOSの環境下でスーファミ（16bitプログラム）を起動させるなら話が分かります
16bitってのは命令長のことで、同じ16bitでもCPUの命令セットが違えば動かない
つい10年ぐらい前にMacがIntelのCPUで動くようになったって大ニュースになったんだが
まあ高校生とか大学生なら知らなくても無理ないかな

>え？C言語が低レベル言語？高級言語じゃなかったかな？
最近のメジャーな言語20個の中では低級言語の方から数えて3番目ぐらいまでに入るわけで。

なんだろ、形から入るってか自分の知識が正しいと思い込みすぎてる感じだな。
あと内容がかなり古かったり基本的なことを知らなかったりと偏ってる。
結構勘違いが多いから、もうちょっと自分の知識を疑ってかかった方がいい。

まあ何事も興味を持つことから始まるんだから間違いは後々からでも気が付けばいい

そんな事よりどうでもいい感想を長々と垂れ流すな
blogに書け

この板は過疎で数年たってもスレを消費できないんだし
別にいんじゃね？

いくら過疎っててもうぜぇもんはうぜぇ。
あと単発IDで擁護すると却って目立つぞｗ

そういうのはカラスに任せておけばいい

単発じゃなかったorz

そういやジュウシマツ和尚とか最近みないな

LuaJITってなんなん？
Luaの亜種？

JustInTimeコンパイラ のLuaでしょ
亜種じゃないよ。

constメンバ関数かそうじゃないかだけでもオーバーロードできるけど
シングルトンのstaticメソッドでも同じようなことってできないのかなぁ
メソッド名にConstって付けるのかっこ悪いお

シングルトンのstaticメソッドの時点で「カッコとか気にしない人なんだな」
ってことくらい分かってもらえてると思うけどね

そりゃどっちかというとMonostateだよね。
愚者はその名も知らなかろうが。

スレ民くらいになるとstaticメソッドがなくてもインスタンスを取得できるらしい。めでたし

staticメソッドならインスタンスいらなくね

それだとMonostateだろｗ

スレ民様に質問なんだけど、インスタンスが単一なのがしんぐるとんで
すたてっくなめんばしかねえのがものすてーとでいいの？

monostateはnamespaceで作るのと同じだね

シングルトンの場合はインスタンスを複数にふやせるから状態管理の変数をもったりできる
monostateだと全体で1個になるだろう

インスタンスを複数に増やしても状態管理の変数もインスタンスの分だけ増やせる・・だな

てかお前ら何言ってんだ？

デザパタの事で語り合ってるんでしょ

C++でシングルトン使ってると聞いただけで、十中八九設計が腐ってると予想してる

シングルトンってわかりやすい概念だから、覚えたての子が
強引に適用するイメージがある。ラムダとかファンクタもそんなイメージがある

シングルトン使いまくってゲーム完成　＞　シングルトン使わずにゲーム未完成

今作ってるゲームだと、1つだけシングルトン使ってるなあ。
Applicationって名前のクラスで、起動時の引数とか起動してからの時間だとか、そういうのを格納してる。

>>666
あ、なんか作り方おんなじだ。シングルトンの概念はわからんがオブジェクト１つ作って格納してる

dxの初期化にシングルトン使ってるわ
ひとつの関数で初期化＆取得ができて便利

俺なんか、d3ddevice取る関数がシングルトンだぜ。どこでもdevice取れちゃう。

まずいんだろうなとは思うんだけど、当時一人ですげぇゲーム作っちゃう人が、
こういうやり方だったのを真似して未だに・・・。

俺はDeviceは常にメインフローから引き渡す形にしてるな
メッシュに関するものとその複合的なものと、シェーダに関するものと、あと外部リソースに関するものを
なるだけお互いに疎遠な関係にしたかったって思想があるから

ああ、あとリストア処理の単純化とかも。
個人的に、モジュール間の依存性について明示的でない暗黙の強い関係が生まれるのがなんかイヤだったのでそんな感じ

>>669
似たような処理をするクラス作ったけど、自分はmonostateだったなー

d3ddeviceって複数いるのか？
メインウィンドウとチャイルドウィンドウは同じd3ddevice使うんじゃなかったけ

複数必要みたいな話、誰かしてたか?

グラフィックスデバイスにアクセスするモジュールって
ゲームプログラム全体から見ればかなり限定されると思う

複数要らないからシングルトンでおkってことでおk？

>>676
それはダメな使い方の典型例じゃないのかｗ

身も蓋もない発言になるかもだけど
他人に使わせる予定のないモジュールなら、シングルトンみたいな仕組みを
わざわざ組み込む必要性って乏しいんだよね

必要になったら後付けでそういう仕組みを組み込めばいいのではないかと

えっFactoryとか普通シングルトンじゃね？非メンバ関数で実装？

>>679
何のFactoryか知らんけど、他人に使わせる予定がないという前提があるならば
意味も使い方も熟知してる自分一人がユーザーなんだから、そのインスタンスの
生成は自身のコントロール下にあるだろうし、シングルトンの仕組みをわざわざ
組み込まなくても実質的に不都合なしという判断にも十分妥当性はあるかなと

ケチつける気はないが、次のプロジェクトでも使いまわすなら、その考えはやめたほうがいいと思う。
数カ月後の次の自分は他人だぜ。

他人に使わせる気で作っておくと、非常に使い回しがいいい。
中で何やっているかコード追わなくても良い程度、或いは使用上の注意など気にせず使える程度でも。

>>681
いや、きっとそう言われると思ってたよ。その意見も同意

シングルトンの構造って基本的にはポカヨケのためにあると思ってるんだよね。
普通にnewしてインスタンスを作ろうとしたり、意図せずに一時オブジェクトを
作ってたりするとそこでビルドエラー。なんでーってなって、そこで自分のミスに
気付かされる的な

>>680
C++だったらテンプレート使って普通に汎用ファクトリ書けるよ。

>>683
なんかESPで誤読されてる気配を感じ取ったんだけど
Factoryが要らないっていう趣旨じゃないからね。一応

グローバル変数の代わりにみたいにシングルトン使うとコード書くのが楽になる
インクルードすればどこからでも参照できるし、使うときに初期化されてるかいちいちチェックしなくていい

どうせ自分しか見ないからって楽になるように書くとむしろシングルトンだらけになる

どんだけ唯一の技法みたいに信奉してるのかと不安になった。　みんなシングルトンシングルトン言い過ぎ。
C++での開発って大前提で言えば、取れるアプローチはJavaやC#でのOO表現の形に縛られたりしないから、他の考え方あってもいいんだけどな。
そこに本末転倒が無いならば。

あと楽って話だと、C++で書いてる前提で言えば例えば公開ヘッダをすっきりさせる目的でPImplイディオムとかたまに使う俺。

シングルトンってそんなに使うかなぁ。
observer的なクラス設計するときはシングルトンにするのは分かるけど。
あとは外部ファイルから読み込んだパラメータの定数代わり？

>>679
mementoなんかはfactoryパターンになるケースもあると思うけど
それがシングルトンじゃまずいでしょｗ

全く全然使いませんってこたぁ無いが、
例えばゲームプログラムなんてマルチスレッド処理随所に考えていく余地ある代物で、
それを書いてる前提で言えば基本的に相性良いものじゃないしな。むしろ慎重にならざるを得ないもの。
実装方法として良いとかダメってより、なんでもそれでおkみたいな物じゃないよな。動作の実際を考えて実装しろって感じ

スレの流れを見る限り、何でもかんでもシングルトンにしてるって人は
ほとんど居ないみたいだし、心配しなくていいんじゃない？

具体的にどこで使うか？は、結構バラバラっぽいけどｗ

むしろどこで使うのが正解なの
典型的な例ってなんかある？

>>685
そういう目的なら、適切なnamespaceの中に変数や関数を配置して
構造化プログラミングをしているほうがよほど素直だし、生成に関する
パターンであるシングルトンなんて言葉が出てくる余地はあまりなさそう

自己流と言えばみんなエラー処理ってどうしてる？
tryとか例外処理を使うかどうかっていう話じゃなくて、
プログラムがエラーに直面した場合どういう風な流し方をしてる？
メッセージだして問答無用で落すとか、復帰可能そうな場合はなるべく頑張ってみるとか

あ、ちなみに俺はリリースしたことがないので、
想定外の部分はassertで落すことしかしたことないです。でもassertだけじゃダメらしいので・・・

サウンドクラスとかキー入力クラスとかシングルトンにするだろ？
上位クラスにもたせるにしてもどうせスコープは広いんだからシングルトンでいいじゃん

>>692
俺が見たゲームだと
「これをコピペしてエラー報告に貼り付けてください」ってのがあった

>>693
ダメな理由は解放順序が保証されないから

>>694
動作パスの観点でスレッドセーフにしてエントリは絞るが、
必ずしもシングルトンクラスにラップするとは限らないかな
翻訳単位中に閉じ込めるとか、static修飾でextern禁止にして、コンパイル時に想定外アクセス防ぐ事は普通にある

>>694
それってデバイスアクセス用の簡易なラッパー(Adapter？)だと思うんだけど
内部でやってる事は、例えばDirectXなら、グローバルなサービスロケーターから
デバイスアクセス用の低レベルのインターフェースを取得して雑多なセットアップ
処理をして、要するにその辺のゴチャゴチャを中に全部封じ込めて、抽象化した
俺流の簡素なインターフェースでサービス提供し直すぜって役割だよね？

ここまではいいと思う

で、アプリケーションコード上のどこでそれを使うか全く決めてないから、かったりー
OODの原則とか脇に置いといて、とりあえず構造化プログラミングに便利な
グローバルなサービスとして提供しちゃおうと。世界の歯車が狂い出すの早過ぎ

単一責任の原則とか根本的な部分を放り投げます宣言として、シングルトンという
単語は出さない方がいいと思う

具体的にどこで使うか決めずにコーディングすることは結構あるけどな
自分用のライブラリ的なの作るときはだいたいそんな感じ
単一責任の原則守ったからって必ずしもメンテ楽になるとは限らんし
作るときは思い付きでガリガリ書くわ

そうそう。
私なんか、まさに
>>697の「単一責任の原則とか根本的な部分を放り投げます宣言として」シングルトン使いまくり。
この使い方としてはシングルトンが一番便利だと思う。
適度に名前空間が限定されるし、何度もアクセスするときは省略表記のためにポインタもらえるし、コンストラクタとデストラクタが使えるし。
ある用途に限定すればシングルトンじゃなくてもいいんだけど、シングルトンじゃない方がいい理由が見つからないことには、やっぱり一番便利だからこれ使っちゃうよね、という。
シングルトンに問題があるんじゃなくて、放り投げることに問題があると言うならその通りなんだろうけど。

>>698,>>699
作り捨てるつもりで勢いでガーって作るのは俺もやるよ。しょっちゅうやってるよ

鼻くそほじったり屁をこきながらの弛緩プログラミングは実に楽しいよね

そういう条件下で、例えば依存性をくどくど明示する必要はないという判断に
妥当性が生まれるのは、全容が自分の制御下(認識下)にある程度の小さな(単純な)
プログラムで、自分以外使わせる予定ないし誰の迷惑にもならないからだよね

巨大なグローバル変数フォルダを作ってそれ１つだけをシングルトーンにしておく。
よくわからない場合はとりあえずそこに押し込んでおいて、あとでまた考える。

結局のところ、結合度の重要性って開発規模によると思うんだよね
市販タイトルみたいに大規模なものは複数人で平行して開発するからコード修正の影響範囲を最小限にした方が全体的なコストを押さえる結果になるけど
2、3人のチームなら多少結合度の高いコードでも共通認識として確立されてればフレームワークとして働くし
一人なら自分の尺度で好きにすればいい

一人で開発するときはシングルトンは非常に便利です

なんかID変わっちゃったけど、俺(>>700)＝>>697ね。

結合度もそうなんだけど、ここでは結合の方法、そして結合（依存性）を
どこで明示してるか。で、ここからが個人的に謎なところなんだけど

>>698,>>699
モジュール間の依存性(依存関係)をくどくど明示する手間を惜しむような条件下なら
クラスインスタンス生成の自由がない事をくどくどクラス定義内で明示する手間も
惜しむんじゃないのかな？だって、そのクラスの意味も使い方も、関わってる
人間には重々に周知されてる事のはずだよね？モジュール間の依存性について
暗黙の了解が成立してるくらいだからね

クラス宣言の中でわざわざシングルトンクラス特有のイディオムを直接に記述したり
あるいはシングルトンホルダーのテンプレートを使ったり、要するにそうまでして
「このクラスのインスタンスはひとつですよー。勝手に作らせませんからねー」
って事をくどくど明示するのって、結構野暮ったいというか、なんか知らんけど
誰かに対して物凄い大警戒してるよね。それは3日以上前のカニチャーハン？

「やっぱこういう時は構造化プログラミングに限るよな。」
「OODの原則とか堅苦しい事はこの際は脇に置いておこう。」

こういう状態でやってるからグローバルなサービス提供が重宝されるわけで
現在のC/C++でグローバルなサービス提供をするなら>>691に行き着くのが
より素直なように思うんだよね。基本的に構造化プログラミングを指向してるから
OOPにおける生成に関するパターンの一つであるシングルトンなる単語を事更に
引っ張ってくる動機がよく分からないというか。コードが似てるというだけでは？

>>692
どこでエラーが起きたのかが表示されるので
そこを見に行く
エラー文をダブルクリックすれば、
エラー行まで飛んでくれる

そもそもオブジェクト指向とかグラフィックライブラリを作るために作られたんだろ
ボタンとかウィンドウとかクラスにして継承とか分かりやすいよな
問題はグラフィックライブラリ以外のあらゆるシステムがオブジェクト指向でやると作りやすくなると誤解したことだよな
つまりオブジェクト指向でゲームを作ると糞ゲー化するということだ

管理クラスから管理対象へthisポインタ渡したり、相互参照になるようなことを
極力回避できるように頑張ったけど難しすぎて挫けそうになったときに
シングルトンさんは優しく手を差し伸べてくれたんだ・・・

そういう状況ならひとまずはOOPなんて捨ててみたほうがいいと思うなぁ
一度、平凡な構造化プログラミングでいいから.ちゃんと機能分割してみるの
その結果として見えてくるものとしてわりとありがちなのが

管理者とかマネージャと名付けてた存在が実は単なる邪魔者でしかなかった(・ω≦) ﾃﾍﾍﾟﾛ

何とか管理クラスってよく見かけるけど、一体何をしてくれるのかよくわかんないよね。
例えば弾管理クラスとか。あーいうのってもう少し具体的な機能名を付けてもいいと思た

○○Managerって名前付けたくなったときは一度そのメンバ変数やメソッドを全て分離してみると
意外とそれら同士で関連が必要なものって少ないんだよね。そこで必要なものだけを関連付けて、
所有者もハッキリさせた上でそれらを利用するためのファサードを用意すれば、外部からは最初に
用意したかったManagerなクラスのような機能を持ってるだろうし、中身はスッキリする。
スッキリというよりはハッキリか、クラスの数は増えてゴチャゴチャだけど役割はハッキリ。

先にインターフェースから考えようとするとこの辺の分解作業でハマることが多いからほんとバランスが難しいと思う。

自分の場合、Fooクラスのインスタンスを管理するFooManagerクラスがあったら、
FooEntityを管理するFooクラスに書き換えちゃう

＞弾管理クラス

蓋を開けてみりゃ、単なる弾専用のオブジェクトプールだったり
ディスパッチャを兼ねてたりしてな。それ分割しろよって話になるわな

>>705

よく分からないけど、私がシングルトンを愛用する理由はすでに述べた。
そして、>>691で名前空間がお勧めされている理由は「素直だから」だけど、私はゲームが作りたくてプログラムしてるのであって、素直な人間になりたくてプログラムしてるわけじゃない。
シングルトンより使いやすいものがあれば、もちろんそっちを使う。

どうも、「シングルトンというものが考案されたそもそもの目的からはずれてる」から、他のを使えと言ってるように思えるんだけど。
そうとは違うの?　「シングルトンはそうやって使うために創案されたんじゃない」みたいな。
でも別に、「突撃砲は戦車の代わりとして使うために作られたわけじゃないけど、戦車の代わりとしても活躍した」よね。
あぁ、ごめん。お腹の調子悪くて変な時間帯に目が覚めちゃったから、半分寝てるんだ。

>>703
暗黙の了解があるったって間違えることも忘れることもあるから、生成方法がわかってればそこそこ安全に使えるシングルトンは落とし所として丁度いいんだよね
「全部把握してるからかんけえねえ！」ってなら確かにnamespaceのがいいかもね

>>714
横だけど、シングルトンクラスをグローバル変数として使うなら、最初からグローバル変数を使えばいいじゃん！
っていう単純な理由じゃないかな。
所詮、シングルトンがグローバル変数として使えるというのは、シングルトンの副次的な特徴でしか無いわけだし。

ま、自分も結構、グローバル変数代わりに使っちゃうことはあるんだけどもｗ

プラグラム上でひとつしかないってのが使い方とクラス定義からわかるってのも把握しやすくて楽なんだよね

まだシングルトン話してるのか
どんだけ実装技法の語彙少ないんだ

1匹の豚だからさ!

>>715
自分でも把握しきれずに使い方をうっかり間違えてインスタンスを生成しようと
してしまうほど多様なサービスがグローバルに提供されてるのか。>>699なんかも
「使いまくり」とか言ってたし、世界は広大だなぁ

気のせいかもしれないけど
「OOの定石とかカンケーねーし、俺は俺っすから、俺流ってやつっすよ」
って感じのアクの強い組み方をする我流戦士に限ってGoFのデザパタ用語を
無理やりに自分のやってる事に当てはめようとする傾向があるよね

山籠り修行で独自の理論を編み出して里に降りてきました的な組み方
してんだから、GoFのデザパタ用語なんかに日和ってないで、何かこう
新しいパターンを提唱すればいいと思うんだよね。クローバルパターンとか

タスクシステムパターンとかな

>>721
パターンなんて実装方法を一般化したもんでしょ
そんな細かい概念的な意味にこだわることはないと思うんだが
パターンはこうあるべきっていう信念でもあるの？

横だが、例えばGoF本は
「オブジェクト指向における再利用のためのデザインパターン」
だからねぇ。GoFのパターンが会話中に登場する時は、お互いに
ある程度の共通認識がないとコミュニケーションの助けにならんよ

ちなみに俺は常に同一のオブジェクトが得られるような記述を全部シングルトンって言ってるけど、これってなんか間違ってる？

↑だとちょっと語弊があるな
同じオブジェクトが得られるクラスの記述って感じか

シングルトンは構造や振る舞いについてのパターンじゃないからねぇ

間違ってるというか、それだけだと相手と会話がうまく成立するのかが
少し心配になるかな。コード中の文脈が伴わないと何とも言えん。

文脈的には、それが何故唯一のオブジェクトとして生成される
ものとして記述されるのか、という点で共通認識がないと
そうだねぇー、うんうん、って話はスムーズに進まんでしょ

例えば、ソースコード上に酷似する部分があるからといって
これすなわちGoFの○○パターンなりって話にゃならんという
話は分かるだろ？

シングルトンに関しては、使用目的までは定義に含まれてないのが共通認識じゃないかと思ってる。
今まで、いくつかの解説サイトで「しかしシングルトンは、グローバル変数のかわりとして使われることも多い」という記述をみてきた。
これはつまり、「インスタンスがひとつしかないことを保証する以外の目的で、シングルトンが使われることがある」事を認めている表現だ。
さもなければ「グローバル変数のかわりとしてこういったテクニックが用いられることもあるが、それはインスタンスをひとつに制限するために用いられているわけではないので、シングルトンとは呼べない」という主張が多いはずだろう。
だが、そういうのはみたことがない。今のところは。

デザパタ用語の乱用だろ

>>728
＞シングルトンに関しては、使用目的までは定義に含まれてないのが共通認識じゃないかと思ってる。

言いたしっぺの人達の言い分もたまには読んであげてもいいんじゃないかと

>Intent
>
>Ensure a class only has one instance,
>and provide a global point of access to it.

>Motivation
>
>It's important for some classes to have exactly one instance.
>Although there can be many printers in a system, there should be
>only one printer spooler. There should be only one file system and
>one window manager. A digital filter will have one A/D converter.
>An accounting system will be dedicated to serving one company.
>
>How do we ensure that a class has only one instance and that
>the instance is easily accessible? A global variable makes an
>object accessible, but it doesn't keep
you from instantiating
>multiple objects.
>
>A better solution is to make the class itself responsible for keeping
>track of its sole instance. The class can ensure that no other instance
>can be created (by intercepting requests to create new objects),
>and it can provide a way to access the instance.
>
>This is the Singleton pattern.

読めば読むほどにアンチパターンだよなｗ

まぁ言い出しっぺの人達の言い分は

これも“Elements of Reusable Object-Oriented Software”だよな？だよな？

だからな。改訂しても消えないんだから奴らは本気なんだぜ

再利用可能なオブジェクト指向プログラミングをするとしたら
こういうのもあるよな？これをシングルトンって名付けたぜ！
もし良かったらお前らもこのワードを活用してくれよな！HAHAHA！

実に気前のいい奴らだ

>>731

？　私は英語はあまり得意ではないけども、そこには「そういう目的で使わないときはシングルトンとは呼ばない」って書いてある?
せいぜい「インスタンスがひとつしかないことを保証するためには、こうすればいい」じゃないの?
それだと、「インスタンスがひとつしかないことが保証されているクラスは、全部シングルトンだ」という解釈は否定できないと思うけど。

シングルトンね。
phpのデータベース接続オブジェクトに、似たようなパターンを使ってるな。
あちこちで生成されると重くなるんで。

>>728
＞「しかしシングルトンは、グローバル変数のかわりとして使われることも多い」
変数のスコープの話と、インスタンス生成制限の話は、区別した方が良くないか。

どうでもいいけど一般に言うシングルトンはインスタンスが1つしかないことを保証できてないけどな

まぁおまえら
インスタンスコーヒーを飲んで落ち着けよ。

>>737
不味そうだな

インスタンス生成制限に対するこだわりがそこまであるなら
使う機能をコンストラクタなりセッターなりで注入しろよな

シーンを生成するたびにキー入力のクラスとかをいちいちSetするのが
めんどくさかったからstaticメンバにした、シングルトンでも良いんだろうけど

>>740
逆に、何故クラスにしたのか。そしてなんでその理由でめんどくさいって話になるのか不思議
自分でそうなるように設計して書いたんじゃないのか

>>741
Staticにする前提で設計したんじゃないの？

ひとりでやってると数行書く手間省くためにstaticにしてしまうことはよくあるな
コード量やインタフェースの複雑さが作業効率に直結するから

まあ規模でかくなると破綻するんだけど

お前らがシーンクラスって言うと、なんだかいつも胡散臭い存在になるよな
そのシーンさんがいなくなるほうが見通し良くなったでござるの巻に100ペリカ

そもそもどういうものをシーンと呼ぶんだろ
シーン自体が切り替わるものなのか、シーン内の状態が切り替わるものなのか、
最初から生成してMapに登録していたものを呼び出すのか
呼び出す都度にNewするものなのかとか
考えるほどに混乱する

「タスクシステム」と同じくらい曖昧だな

どこぞのサイトからコピペした知識とコードだけで書いてる人だと
妙に固定的な考え方と固定的な名前を使いたがるよな。シーンにしろタスクシステムにしろ
そんなものそもそも固定的な、教科書のある決まった方法でもなんでも無いのに
凄くその辺の認識が曖昧だと俺も思うわ

タイトルシーンとかあるでしょ
オブジェクト指向で設計されたシーンの方がわかりやすいんだけど、
そうでないものでもシーンと呼べるものは出来るし、
どういうところがわかりにくいんだろう
シーンをつないでゲームを作るフレームワーク作っておけば、
よりシーン単位でゲーム作る感じになってシーンの差し替えも用意だから複数人でどのシーンを担当とか分業もできるし楽だよね
Unityでもシーンと呼ばれるものがあって、C++で作る時のシーンの概念と同じ使われ方（シーンにオブジェクト置いて〜みたいな）だし
そろそろシーンについての統一的な概念は理解しておいた方がいいね

タイトル以外がシームレスなゲームってどっからどこまでをシーンってよべばいいんだろ
シームレスなところは全部1シーンってことでいいのかね

シーン1からシーン2に画面がフェードしながら切り替わるシーンとか作ったりしてた

日本語だと「画面」が近い、なんてのも聞くよね

どこからどこまでを1つのシーンに収めるかはそれぞれの判断
無理にシーンの粒度を細かくしようとする必要もなくて
基本的に使用するリソースががらりと変わる部分で分けるのが普通だと思う
タイトル→ステージ選択（タイトル画面でやるならこれは要らなくなる）→ゲーム→リザルト（ゲームシーン内でリザルト表示するなら要らない）
ステージ選択で選択された項目をこのゲーム用のデータクラスに保存、
ゲームシーン開始時に読み込んで選択されたステージを開始
シーンの扱い方はこんな感じ

「それぞれの判断」なら議論はまず成り立たないし
かなり厳密な質問でも無い限りアドバイスは空振りするし
全く会話に使えない言葉だな

おまえら日本語処理しなきゃいけないときとかどうしてる？
たとえば英字交じりの日本語を一文字づつ表示しなきゃいけないとするじゃん
そういうときどうする？wcharつかう？

win環境なら。wchar_t と言うか TCHAR。
勿論、その時の都合にもよるから、必ずな訳じゃないが

常にマルチバイトだな。
自作ライブラリを直さないといけないとなると面倒くさい。

>>753
同感だなぁ

脚本レベルのかなり上位の概念なので、例えば実装レベルの話で唐突に
「シーンクラスが〜」と言われてもそんなの知らんがなって話になる

ゲームのジャンルも何も分からなければ、実装にどう関わってくるのかも
見えてこないけど、そこは空気を読んで無難なところを推測、暗黙の了解を
想像で補え的な？

基本、実装レベルのお悩み相談でシーンという単語が何の前提条件も無しに
ポーンと出てくる時は、この人は猛烈なESPを要求する人だなぁとは思う

>>748
なので実装レベルのお話で何の前提条件も無しにシーンなるものに
“統一的な概念”というのを主張するのはなかなか難しいと思うよ？

例えばUnityにおけるシーンとか、LiveMakerにおけるシーンとか
あらかじめ言おうよって思うなぁ。ちなみにこの二つの例ではかなりの
食い違いがあるというのは調べれば分かると思うよ

>>755
同じく

男ならユニコード一択だろ
Winならなおさら

統一されれば絶対ワイド文字が便利なんだろうけどなあ
正直ワイド文字の動きがよくわかってないってのが本音だけど
S_JISの文字列を先頭文字から順に半角全角判定する原始的なやり方が現役

>>761
単純に Unicode16として16bit単位で収まってるだけだよ wchar_t
VC++の場合、UNICODEマクロが定義されてる場合、TCHAR は wchar_t (WCHAR) の typedef で
定義されてない時 char のtypedef

マルチバイトばかり使っててvisualstudioから警告が出てもビビる事はまずなかったが
unicode前提のコーディングが思ったより普及していて生まれて初めてほんの少しビビった

unicodeに統一したいけど使うライブラリの引数がchar*とかになっててちょっとめんどくさい

確かにそういった影響は受けるね

俺の場合はDirectXSDK付属サンプルのプロジェクトファイルが
デフォルト設定で_UNICODEでビルドするようになった辺りかな。
たぶん2007年とかその辺じゃないかな

いい機会だったのでテキスト関係はMS独自仕様の汎用テキストマッピングを
利用するように書き換えたよ

文字セットを設定なしでプログラムし続けてたけど
このスレに影響されてUnicodeに設定してみた
charをTCHARに置き換えたり、
stringをbasic_string<TCHAR>のtypedefしたものと置き換えたり、
sprintf_sなどを_stprintf_sなどに置き換えたり、
色々面倒だったが全て置き換え終わった

最初はそうやってたが、バカらしくなってきたから必要な時に適宜マルチにエンコードする方向で統一した
処理速度？今時どうってことないさｗ

バカらしくなるというのは、テキスト関連の処理が広範囲に散乱してるとか？

サロゲートペア考慮したらマルチバイトと手間変わんないしな
ただ常用外の漢字ばかりだし読めそうなのって叱るの異字体を使うかぐらいだろうけど
他のOSでのデータの受け渡しやマルチプラットフォーム環境も考慮するとUTF-8で処理だろうし

>>768
Stringクラスは自作してるでしょ？
わざわざワイドの時とマルチの時で処理の整合性が取れてるか確認するのが面倒だったからね
内部的にはワイドだけど外部APIとかがマルチでしか受け取れないときの為に
std::stringに変換するキャスト演算子を用意してんのよ

バカじゃあるまいし広範囲に煩雑にテキスト処理が散乱するような作りにしないでしょ。

>>770
目の前の目的が特に無いまま想像だけで設計してる予感がする
具体的にどんな物作る予定があって自作してるの?
それ次第では手段と目的が逆転してる話ぶりに見える

どういう事かと説明するなら、例えば自分の処理中で必要な内部表現文字列と、
外部とのI/Fに位置する処理を分けて考えてない予感がするって事
どの形式の文字は、どこで必要だから、どこが責任持つかっていう設計力の話

こういう口うるさい先輩いるけど社内でも嫌われてるわ
そんなの分かってるし偉そうに当たり前のこと言ってるのかなり恥ずかしいから自重した方がいいよ

あと俺の目的は「ライブラリを作る練習」だったから手段と目的は逆転してないよ

涙ふけよｗｗｗｗｗ

wchar使うのが悔しいから何とかchar std::stringベースの補助関数作ってるんだけど
英語圏以外のアジアの国々や右から書く文字の国とかの文字もlocale弄れば2byteで収まりきるのかね

漢字は2byteでよゆーで入るだろ、とか思ったアホな毛唐が作ったんで無理

あいつらもたいへんなんだなぁ

>>770
自作ではないけど、俺はPocoを使ってるので基本的にはUTF-8だよ。Pocoは
POCO_WIN32_UTF8で使ってるから_UNICODEも定義されてる状態かな。
内部でUTF-16に変換してMSのAPIを呼び出してるから>>770とやってることは
そんなに変わらないのかな？

MS謹製の「これからはUTF-16で統一じゃー」のやり方はマルチプラットフォーム前提の
海外のライブラリのやり方とは違うんだよね。MSとの判断の違いは歴史的な経緯の
違いなんだろかね

>>777
訂正

うちの場合、CRT用の設定で_UNICODEを定義してるからWin32用の
UNICODEも定義される。

で、PocoではUNICODEが定義されてるとPOCO_WIN32_UTF8が定義される

あるクラスのインスタンスをやり取りする時に
クラスの機能の一部を隠して相手に渡したい場合ってどうするのがいいのかな？

�@対象のクラスを包含して、公開したいメソッドと同名のメソッドを定義して、
　内部のインスタンスに引数などをそのまま委譲するような実装にする

�Aあらかじめ、対象になるクラスを、受け渡し用のクラス(公開機能のみ持ってる)から継承させて作っておく

�B公開したいメソッドを対象のクラスから切り離して新しいクラスを作る
　分割元のクラスも、新しく作ったクラスを包含するようなつくりに修正し
　受け渡し時にはその内部のクラス(新しいクラス)を渡す


説明が下手で申し訳ない。
�@はブツを全く別の箱に入れて渡す感じ
�Aはエロい用途を知らない女の子に電気アンマを渡す感じ
�Bはアンパンマンが顔の一部だけ相手に渡す感じ

そのメソッドを使う人には見えて、使わない人には見えないようにしたいってこと？
そうでないなら普通にprivateにするけど

性質や目的に応じて使い分けるのが良さそうだけど、じゃあどう使い分けかって基準はパッと浮かばないなあ。
例を出してくれれば個別に答えられるかもしれんけど。

>>780
その場合はfriend前提？

>>782
そのクラス内で自分自身のインスタンス作ってそのメソッド使うならfriendになるのかな？これは賛否あるか
特定のメソッドだけ使えるようにしたいなら、俺なら2かな？
仮想関数だけ定義したクラスを継承させて受けとり側はそのクラスのポインタ使わせる
ようするにjavaのinterfaceなんだけど

ぶっちゃけ好みでいいんじゃね？と思う

PImplの話じゃないの?
C++の基本的なイディオムだけど

>>784
実装そのものはPimplに限らず、って感じじゃない？

>>780-781
DXライブラリを使ってマウスの操作情報(InputState)を扱ってるんだけど
依存度を弱めるために使用側とDxLib関数の間にインターフェースクラス(MouseState)を介してます。

MouseStateは、メインループを管理しているクラスによって1ﾌﾚｰﾑに一回だけ更新(Update)された後、
ゲームのシーンクラスに渡されてシーンの更新処理が行われる。という流れにしたいんだけど、
そのまま渡すとシーン内でMouseStateを何度もUpdateできてしまう。
これはDxLibだとマウスホイールの回転数を取得した場合にかなり問題です。
（回転数取得関数は冪等ではないため、そのﾌﾚｰﾑ中での正しい入力情報が得られなくなる）

そこで、MouseStateのUpdateメソッドを隠してシーンに渡したい、ということだぜぇ。

ちなみにMouseStateのメソッドの例としては次のような感じです。
bool Update();
bool IsDown(ID id) const; // enum ID { LEFT_CLICK, RIGHT_CLICK, etc.. };
Point GetPoint() const; // struct Point { int x, y; };
int GetWheelRotation() const;

ちなみにMouseStateをconstで渡すという方法も考えたけど、constキャストで突破されてしまうというのと
将来的にキーコンフィグなど実装したい場合にconstでないメソッドも公開したいなぁと思ったので候補から外しました。

楽なのは
・Update()は呼ぶなとコメントに書くだけで、あとは気にしない
・Update()をprivateにしてメインループをfriendに指定
…あたりだけど、真面目に答えろよ！って怒られそうな気がする（´・ω・`）

冗談はさておき、この場合は継承（>779の2番）ってイメージではないかなー？

>>786
Update持ったinterfaceとgetも持ったinterfaceを多重継承させればそんな感じにみえなくもないと思うけど
キャストも考慮するなら継承で制限は意味ないな
正直そこまで細かく考えることないからどれがいいかわからんw

逆だわ
get持ったinterfaceとUpdateも持ったinterface
自分で言ってて思ったけど多重継承でシグネチャ被ってもいいんだっけ？

ついでに、前述のパターンと照らし合わせます。

�@
MouseStateをコンストラクタ引数とするMouseStatePeeperを作り、
MouseStateを包含してUpdate以外のメソッドを実装する（処理としては委譲するだけ）
シーンへの引数の型はMouseStatePeeperにする（コンストラクタにより暗黙の型変換が行われる）

�A
予め、Updateメソッドを持たないMouseStateDataクラスを作っておき
MouseStateはそれを継承し、Updateメソッドを新たに定義する。
シーンへの引数の型はMouseStateDataにする（アップキャストで暗黙変換される）

�B・・・を書いてる途中にレス！

>>787
ぶっちゃけ趣味だし自分かごく近しい身内しか使わないしコメントで良いよねｗ
まぁオブジェクト指向とかカプセル化の練習がしたいんですよねー

>>788
クラス図っぽく書いてみますと
[ IMouseStateData | | +Get() ] <|-(継承)-[ IMouseState | | +Update() ] <|-(実装)-[ DxLibMouseState | 省略 | 省略 ]
これならOKだと思います。

[ IMouseStateData | | +Get() ] <|-(実装)------+--[ DxLibMouseState | 省略 | 省略 ]
[ IMouseState | | +Update() +Get() ] <|-(実装)-+
こっちの場合はGet()の被りがアウトだと思います。

あ、すみません！　名前被ってもアップキャストされて使われる分には大丈夫そうですね。

実装するクラスで
親A::Get() { 省略 }
親B::Get() { return 親A::Get(); }
って実装すれば良いのかな。

オーバーライドするだけだから
C::Get()
でいいんじゃないの？

クラシカルオブジェクト指向が初学者に与えた悪影響は計り知れないなｗｗｗ

ID:N4rcp1wd の固有の実装について、本人がどうしたらいいかわからないから質問するスレになってる

前提のよくわからない仮定の話を延々言い合うスレよりはよほど建設的で有意義だな

既に完成されてるシステムを修正する場合は�@のように包含で隠すけど
設計段階で 好きにしていいよ って言われたら�Bでやる。�Aが一番ラクだけどな

よく3Dゲームで、キャラクターがまばたきするけど
あれってどういう処理なんです？
テクスチャーをずらすとかポリゴンを縮尺するとかあると思うんですがどうやるのが正しいんでしょう

好きにやれ

>>797
＞正しい

状況(前提条件)は君しか知らないんだし、君が判断するしかないんじゃね

それじゃ聞いた意味ないな

質問する意味が無いからな

唯一の正解正しい答えなんて無いもの

テクスチャーをずらしたりポリゴンの縮尺を変えたりするのが一般的だね

ひでぇスレｗ

なんでも聞けば答えてもらえると思うなよ！ゆとりがっ！！

っていうかもうちょっと条件しぼらないと答えようないだろ
ポリゴン数や場面、許容されるリソースで最適な方法は変わるんだから
考えられる全パターン並べ立てろとでもいうのか

条件絞るとお前の固有の仕様を実装するんだから好きにしろってなる

具体的にこのゲームのこの場面のこのキャラのこの表情ってどうやってんのかな
って感じで、例えばつべに動画でもうｐって話を振ってくれりゃあ
「見た目からしてこれUV(モーフだけでできそう)じゃねーの？」とか
それくらいは答えられるけど・・・

見た目で判別付きやすい部類の話だからね

でも正しいかどうかは知らんよね。学校のテストじゃあるまいし
唯一無二の厳密解が必ず用意されてる的な固定観念いくない

いや、偏差値65以下の猿は、「厳密な正解以外はアウト」でいい。
教えたことを守らなかったら鞭で打てば良い。
分からなかったらウッキーって相談に来るから適当に正解の一つを与えておく。
どうせ猿にそれ以上を生み出す想像力はない。

固定観念イクナイは、偏差値65を越えてから。

あ、はい

触らないほうがいい

（話題ふれよ誰か）

>>810
何で番号コテを俺と同じにするの？

触らないほうがいい

おまえらC++11の機能ってどの程度使ってる？
スマートポインターとラムダ式とfor eachは使ってるんだけど
資料が少なくてどの機能が合ってどこまで使えるかわからないんだ

VS2012の話？　とりあえず自分で１個ずつ使って試せばいいけど、
実際に試して結果をまとめてくれてる人の記事がいくつかあるから参考にさせてもらうと良いと思うよ
後置きテンプレートをやってみたかったけど対応してなさそう

一番使ってるのはautoかもしれん

お知恵をお借りしたく質問させていただきます

　１
４　２
　３

ジョイパッドのボタン配置変更についてなのですが、
例えば、１のボタンを２に変更したとします
その時、同じボタンが存在しているのは不自然なので
２のボタンを１のボタンに変更させるわけですが、
これを考えれば考えるほどややこしくなります

１と２だけで考えるなら簡単ですが、
例えば１を３にして、３を１に変更、
さらに１に変更した３を２に変更する、
すると２は１に変更される

プレイヤーが制作者の意図する順にボタンを変更してくれるなら
組むのは簡単ですが、どの順番でどのボタンをどのボタンに変更するのかは
その時のプレイヤーの気分次第です

　１
４　２
　３

もしかすると、４を３に変更して
３が４になり、
２を１にして、１が２になり、
「やっぱやーめた」と言って
２になった１を１に戻し、１になった２は２に戻り、
４になった３を２に変更することにして、２が４になることもある

このように片方のボタンを別のボタンにした時に、
その変更前のボタンを自動的にそのボタンに変更する
というプログラムに頭を悩まされています
お知恵をお借りできればと思い質問させていただきました

　１
４　２
　３

１．１を２にすると２を１に変更する
２．１を３にすると３を１に変更する
３．１を４にすると４を１に変更する
４．２を１にすると１を２に変更する
５．２を３にすると３を２に変更する
６．２を４にすると４を２に変更する
７．３を１にすると１を３に変更する
８．３を２にすると２を３に変更する
９．３を４にすると４を３に変更する
１０．４を１にすると１を４に変更する
１１．４を２にすると２を４に変更する
１２．４を３にすると３を４に変更する

ノーマルで考えるならこういうことになるのだが、
これは、それぞれのボタンがそれぞれのボタンの時のものです
１が２や３や４になっていたり、
２が１や３や４になっていたり、
３が１や２や４になっていたり、
４が１や２や３になっている場合もある
それらのパタンもすべて考えると、かなりたくさんの条件式になってしまうので、
もっと短く簡潔にできないかなと考えています。

ボタンは４つしかないのです
片方を別のボタンに変更したら、変更前のボタンを変更後ボタンが
元あった場所のボタンに自動的に変更させる
という仕組みを考えれば考えるほどややこしくなるぜ

もしかしたら全ボタン2にしたいかもしれないのでそのままにする！
やった！かっちょよく決まった！

変更前のボタンを一時的に記憶する。

ボタンを変更する。

変更後のボタンと重複してるのをループで探す。
(さっき変更したところはスキップ)

見つけたらそこを一時的に記憶したので上書きする。

単純にボタン番号をスワップしてるだけにしか見えないんだが
複雑になるのか?

何を悩んでるのかがわからないw

初期状態が、
ButtonMap[0]=1
ButtonMap[1]=2
ButtonMap[2]=3
ButtonMap[3]=4
で、これを入れ替えるとすると、
たとえばswap(&ButtonMap[1],&ButtonMap[3])で、2と4を入れ替えて
ButtonMap[0]=1
ButtonMap[1]=4
ButtonMap[2]=3
ButtonMap[3]=2
になるとかいう話じゃなかったりするのか?

>>821
同じ機能のボタンが２つ以上ある案は俺も考えた
それならもう完成している
だが、それだと不親切なゲームだと思うので却下したい

タイトル画面
ttp://livedoor.blogimg.jp/winpg/imgs/7/0/707953a4.png
コンフィグ画面
ttp://livedoor.blogimg.jp/winpg/imgs/d/f/df6687f0.png
ボタン設定変更画面

コンフィグ画面のすべての機能は完成していて
ボタン設定変更画面も一応は完成しているのだが
片方のボタンを変更したら、別のボタンが変わるという仕組みに苦戦

ﾌﾟｯ

ボタン設定変更画面
ttp://livedoor.blogimg.jp/winpg/imgs/7/e/7ea8fac8.png

肝心な画像がぬけていた

>>822
その案をプロミング言語に置き換えた時に
どのように組めばいいのかをよく考えてみるよ

>>824
まあそういうことなんだけど
それをプログラミング言語で組む場合は簡単には行かないんだ
上の画面で完成しているのは、画面の表示内容を変更させるまでのもので
最後に「決定」を選択することで、そのボタン配置に変更される

そんなに悩むような事かな？

キーコンフィグ処理で、一時変数でも用意してそこで設定させて
決定したらそれを実際の設定に反映させればいいだけじゃ。

グラフィックが格好いいな。見習おう。


それはさておき、キーコンフィグを楽に作成するコツは、
>822の言うように、キーコンフィグ中に実際にボタン変更をしないことに尽きると思う。

リアルタイムに更新するのは、デメリットが結構大きい。
例えば、決定やキャンセルのボタンなどが消えてしまってコンフィグ画面から抜け出せなくなったり、
「押した瞬間」「離した瞬間」「押しっぱなし」などの処理がごっちゃになって、不具合が出る可能性があったり、
そもそもプレイヤーが混乱してしまう場合とかね。

コンシューマゲームなんかでも、ゲームによっては
・方向キーはキーコン不可
・キーコンフィグ画面での決定/キャンセルは、スタート/セレクトボタン。かつこの2つはキーコン不可。
……みたいな対策を取ってたりする。


その上で、どのボタンにも割り当てられない機能があったり、
あるいは1つのボタンが複数の機能に割り当てられているのを回避したければ、
ボタンを設定する時に既に登録されていれば入れ替えるなり、エラーメッセージを出すなりすればいいと思う。

アルゴリズムはともかくとして>>827のUIちょっと分かりにくくないか
ボタンを選択してボタンを押すってちょっと混乱するし
機能を選択してボタン割り当てた方がよくね？

　　　　 ∧＿∧
ｶﾞﾗｶﾞﾗ(　　＾＾　 ） ＜これからも僕を応援して下さいね（＾＾
　　＝〔~∪￣￣〕
　　＝ □――◇ 　　　　　　　　　　　　　　　　　　　　　　Kazuki

エミュレータとかのキー設定機能を参考にしてそのまままねればええやん

>>830
なるほど、そのコメントで
何となく見えてきました

ボタン設定変更画面
ttp://livedoor.blogimg.jp/winpg/imgs/7/e/7ea8fac8.png

この設定案自体を白紙にして
右の機能一覧を上から順番に
ボタン位置を割り当てれるようにしてみよう

途中で訂正したい場合はキャンセルボタンで1つ前に戻すようにして
重複するボタンはエラー音を鳴らして設定できないようにする
ＯＫ！とりあえず、それでプログラムを組んでみよう。

ゲーム機と違ってパソコン用のジョイパッドは、
パッド番号が統一していないのでややこしい

　１
４　２
　３
こういうボタン配置のジョイパッドもあれば、
ttp://item.shopping.c.yimg.jp/i/j/dragonjapan_225

　４
２　３
　１
こういうボタン配置のジョイパッドもある
ttp://g-ecx.images-amazon.com/images/G/09/detail/review/b0026163qq.01.jpg

なのでボタン配置を変更させるものを作るなら
直接、そのボタンを押してもらって変更してもらうしかない
SFCとかプレステとかなら、ボタン配置（ＡＢＸＹ）は決まってるから
変更させるのはまだ楽なのだがね

>>833訂正
>途中で訂正したい場合はキャンセルボタンで1つ前に戻すようにして

考えてみたらボタン配置を決めてる時にキャンセルボタンで戻すことは無理ですね
そのキャンセルボタンの位置すらも設定しているのですから
なので、１〜４までの機能をすべて設定し終わってから
最後に確認するようにして、そこでキャンセルしたら設定をオールリセットして
最初っから設定し直すことにする

ところで俺のRPGではボタンが１つ余ってるんだが
なんか適当な機能のボタンってないかな？
１．メニュー表示
２．決定/話しかける
３．キャンセル
今んとこ、３つまでなのだが、
あと１つあればシマるんだがね・・・

余計なボタンは入れないほうがいいと思う。

特に新しい要素を追加したくないなら、高速会話スキップとか

>>834
プリセットを入れるなら、プレステ風とXBox風の2つは欲しいな

>>837
ありがとう
とりあえず4つ目のボタンはスペシャルボタンにしておきます

街中で押すと特別なことが出来たり
戦闘中に押すと、また特別なことが出来たり
フィールドで押すと、また特別なことが出来たりなど、
押す場面によって内容を変えるようなボタンにしてみようと思います

ドラクエ等で採用されてる、
メニュー深層からの全キャンセルが地味に便利よな。

ttp://livedoor.blogimg.jp/winpg/imgs/3/b/3ba8897c.png

とりあえず、助言のおかげで
こんな感じに作り替えることにしました
ありがとうございます

>>840
全キャンセルボタンは確かに便利でいいね。

だけど、メニュー画面を表示させた後は、
メニュー表示ボタンを使うことはないので、
「�@メニュー表示ボタン」をオールキャンセルボタンに割り当てようと思います
他のRPGとの差別化を図るため、
スペシャルボタンは、他のRPGにはないユニークな機能を割り当てようと思います。

例えば、戦闘中に連打するとダメージが少し上がったり
敵の攻撃を避け易くなったりする。
子供の頃、RPGの戦闘で無意味にボタン連打をした覚えとかないかな？
そういうのに付加価値を付けたりして
説明書には、その説明はあえて書かないでプレイヤーに探してもらう

世の中、隠し機能はだいたい隠されたまんまだぜ

そういう理不尽な隠し仕様で喜ぶのは作者だけ

>>843
ｋｗｓｋお願いします
是非是非

隠し機能を見つけ出すって事は、かなーり根性入れてプレイしなくてはいけないわけで、
それだけプレイするって事は、それだけ面白いゲームでなくてはいけないわけで、
並のゲームじゃ、そこまでやりこまれる事は絶対にないわけで。

昔のFC時代の「裏ワザ」なんかは、開発が仕込んだものは、
誰も見つけないとわざと攻略雑誌に流していたりしたからなぁｗ

雑誌の編集側もわきまえてて、
編集部に遊びに来るような常連さんの名前で出して
採用のプレゼントを回すようにしていたりして。

まぁ、そのあたりはズブズブでやってたよなぁｗ

>>846
説明書には、スペシャルボタンは「何かいいことが起こるかもよ？」
とだけ書いておくことにしよう
何が起こるのかはプレイヤーが試してみてのお楽しみです
別にそのボタンを使用しなくてもゲームはクリアできるのだから
ゲームプレイには何ら支障は出ない

ただ、それを見つけた人は
「自分だけが知ってる特別感」だったり
見つけた時の「お！？」という喜びを得ることが出来る

例えば、RPGの戦闘で敵が攻撃してくるとするじゃない？
そのタイミングでスペシャルボタンを押せば
100%回避することが出来るなど。
知っててもタイミングが合わないと回避できないという二段構えの遊び心

いや、その裏技を極めれば低レベルクリアも可能なので
三段構えの遊び心かもね

RPGツクールとかウディタとかを使うと
例えば、こういう細かいアイディアを実装することができない
出来たとしても大変な作業です。
戦闘中に敵の攻撃時のあるタイミングでスペシャルボタンを押すと回避なんてね

そやけど、プログラミング言語を使用したオリジナルゲーム開発なら
そんなに難しくはないよね？くしゅん
だってゲーム開発者は1フレーム（1/60秒）間隔で
コード書いちゃってるわけですから
自分が「ここだ」と思うタイミングのところに
「スペシャルボタンが押されていたら100%回避する」という条件式を書くだけのことです

デバッグ用機能をリリース版にも残してるだけだな。
なんかない？って言われたら教えるけど。

ツクールやウディタでさえ完成させられなかった人間は
隠し要素なんか考えるより完成させるためにそういう無駄を極力省いて
作業工程をどれだけコンパクトにまとめられるか考えたほうが良いと思うよ

>>851
わしは完成させることよりも
開発している過程そのものを楽しんでいるところがある
ぶっちゃけ完成させること自体はどうでも良かったりするわけだ
それがビジネスと趣味とのゲーム開発の違いなんだろうねだろうね
ビジネスだと、どうしても完成させる必要があるが、
趣味であれば別に完成させる必要もない
開発する過程させ楽しめればいいのだからね

あと、こんな風に複雑な処理で凄いことをするのではなく
ちょっとしたアイディアで面白いことをすることが凄い好きだし楽しい
昔のゲームって、そういうアイディア勝負みたいなところあったよね
そういうは考えることも思いつくことも好きですわ

俺らの世代はRPGの戦闘中に
隠しコマンド（→←→←ＡＢなど）を入力すると
特殊な効果音が鳴るだけで興奮するよな
自分が開発するゲームには
昔のゲームにはよくあったそういう隠し技的なものは入れたいね

最近のゲームは複雑で高度な処理ができるようになったからなのか
そういう小手先の裏技的な遊びをしなくなったのが不満です

完成させないで妄想してるだけとか中二の黒歴史ノートレベルだったのか
ならば他所でやったほうが良いんじゃね

ゲームって言うのはプレイヤーがいるからゲーム足りうるわけで
その状態に持っていくため、もって行った時によりプレイヤーの気を引くための技術が
ゲーム制作の技術なんだから

別に好きにやればいい
他人のやり方に色々言えるほどお偉い方ならそれこそ
こんなところにいなくてもいいよ

まあここは仕様じゃなくて実装を語る所だしな
端からみて?な仕様でも作るのは本人の勝手だし

なんでこの人質問してるのにずっとえらそうなの？
自分のゲームが面白いって勘違いしてるの？
自分の技術が無いのに実装は難しいんだよな〜とか難しいこと言ってるの？

>>857
Kazukiを知らない御新規さんへ

Kazukiの同人3DRPG制作【第三話】
http://toro.2ch.net/test/read.cgi/gamedev/1285169737/l50

746 名前： 名前は開発中のものです。 [sage] 投稿日： 2013/05/24(金) 18:40:16.82 ID:Ka2layLo
ブログ潰してもまだデジタルなんちゃらとかいうゴミ作品に未練ありのようだ。

C/C++ゲーム製作総合スレッド Part3
ttp://toro.2ch.net/test/read.cgi/gamedev/1357899040/817-827

ゆめにっきっぽいゲームを作るスレ 12部屋目
ttp://toro.2ch.net/test/read.cgi/gamedev/1351597862/430

今日も元気に2chで書き込み三昧

　　　　 ∧＿∧
ｶﾞﾗｶﾞﾗ(　　＾＾　 ） ＜これからも僕を応援して下さいね（＾＾
　　＝〔~∪￣￣〕
　　＝ □――◇ 　　　　　　　　　　　　　　　　　　　　　　Kazuki

>>846,>>847
へー、そうなんですか。
昔よく遊んだファミコンのゲームで、まだ世に知られていないコマンドがあるのかとｗｋｔｋしました。
確かに雑誌の裏技コーナーを見ていて「こんな複雑なコマンド入力、どうやって見つけたんだ？」ってのはよくありました。
バイナリでも解析してるのかと思ってた。

昔、ファミコンのドルアーガの党で256面までステージセレクトできる入力コマンドがあって、
「公式回答はバグだ」って話を聞いて、
どう考えても意図して練りこまれたものに違いないと思ったことがある。

＞＞ドルアーガの塔
懐かしい裏技だな。画面がフリーズしたり真っ暗なステージや変な色の敵キャラが出たりで
情報の乏しかった当時全フロアひとつひとつ調べた記憶があるわ。
今は検索ひとつでそれらの情報が見られるサイトがみつかるから便利だな。

>>848
何か良いことあるかもよ？くらいだと多分見つけてくんないと思うｗ
凄く分かりにくいところにいるNPCに語らせるくらいで良いかもしれんよ。

どこかに各種コンパイラのC++11対応表なかったっけ？

英語圏の記事だけど
C++11 compiler support shootout: Visual Studio, GCC, Clang, Intel [March 14, 2013]
http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/

アベノミクス財政支援で
景気回復！
識者の意見は？

C++でデータ通信のライブラリのようなものをつくってます。
よかったらお試しください。
http://ichishino.nobody.jp/

boostをラップしただけのライブラリに見えた

boostは使ってないですｗ
まあやってることは似たようなことですけどね

むしろ使ってくれた方が信頼性が・・・

GPLじゃないライブラリはどんどんラップされればいいのになぁ

通信系は、他人の書いたライブラリ使うとか、ないわｗ
抽象化の哲学が違うから使いにくい上に、なにしてるかわからんから怖すぎる。

自分で書くとだるいから良いと思うけど

座標Aを頂点とする円錐(方向ベクトルav,底面の半径ar)に、座標B(x,y,z)が含まれているか判断したいのですが、
数学素人なもので、STLか素で動くコードください！！！！！！

円錐は円錐(方向ベクトルav,底面の半径ar)と表しましたが、
頂点座標Aからベクトルav方向の要素と、角度の指定と距離指定があればなんでもいいです！！！！

お願いします！！！！

あ、AとBの距離を調べればいいので、円錐じゃなくてもよかったみたいです。
まとめると、座標Aからベクトルav方向の誤差角度θ内に座標Bが含まれているかどうか、です。

こんな感じ

D3DXVec3Sub( &AB, &B, &A );
D3DXVec3Normalize( &nav, &av );
fa = D3DXVec3Dot( &nav, &AB );
fc = D3DXVec3Length( &AB );
if (fa <= 0.0f) return false;
return (fa / fc) >= sqrtf(1.0f - ar * ar);
もしくは
return (fa / fc) >= cosf(θ)

>>869
俺は逆にオレオレ規格使うほうが怖いわ

ユーザーが画面上のオブジェクトをクリックしたとき、
クリックしたことがはっきりわかる画面上のエフェクトを表示したいのですが、
どんな種類のエフェクトが考えられますか？2Dのゲームです。

今は、小さな☆をいくつか放射状に飛ばそうかと思っているのですが、
何かいいアイディアがあったら教えてください。よろしくお願いします。

描画リストを作っているのですが、どっちのほうが一般的でしょうか？
・オブジェクトが、毎フレーム描画リストに登録を行う
・オブジェクトの初期化時にポインタを登録して、フラグで管理する

>>876
僕は両方使ってます

エフェクトのような大量に発生して短期間で消えるようなものをリストにいれていても無駄なので、毎フレームごとに削除フラグのついたオブジェクトを取り除いています

また、描画リストの操作を行うと却って煩雑になるような、オブジェクトが一時的消える場合などは描画フラグで管理してます

>>875
> 小さな☆をいくつか放射状に
それで問題ないと思う
押した/叩いたってのが感覚的に分かればいいので

星が散れば叩いたって事が分かるだろうし

取りかかっといて完成させられない奴は、
一生なにも完成させられない。
例え、趣味でもだ。

そんな奴は、最後まで
中途半端で終わるよ。

そうなんだすごい

>>876
そのオブジェクトのdraw()に任せるんだからどっちも自在じゃない？
強いていうなら前者で、内部にフラグを持たせておく。
描画リスト自体を描画オブジェクトとして扱えるようにしておけば
階層構造でソートもスッキリできるし

毎フレームオブジェクトの数だけVECTORに登録するのってどれぐらいコストかかるんでしょうか
任意のオブジェクトを任意の数eraseするより軽い？

テストケース思いつかないのでそこも教えていただけると助かります。

また、描画フラグを持つということは、描画リストに登録する時に判定を行うということですよね
そうすれば>>877さんの方法も利点を踏まえてできそうです

C++で、以下のような目的に有用なコンテナがあれば教えてください。
STLかboostが望ましいです。また、要素数は10〜1000くらいを想定しています。

・先入れ先出し（queue）
・先頭から昇順で舐める（取り出さない）
・末尾から降順で舐める（取り出さない）

LinkedListかな？

双方向の連結リストをqueue代わりに使う感じです？

てか、それそのまま std::queue じゃダメなの？

>>886
std::queueだと、2番目と3番目が一手間かかるかな？と思ったんですが、
実装によっては行ける場合があるみたいですね

stdすら触ったことないけど
std::listとか

自己解決です。
std::listについて調べてたときに見つかった、両端キュー（std::deque)を使うことにしました。）
listでも良かったのですが、あくまでqueueであることを強調しておきたかったので。

全く知らなかったんですが、std::queueの中身（？）としてdequeがデフォルトで使われるんですね。
ありがとうございました。

dequeはvectorのつもりで使うと遅いらしい(言いがかり)


queueを強調したいなら
typedef std::vector<XXX> myqueue;
のが幸せになれるかもね

便乗だけど便乗だけど既存のものでスレッドセーフなキューってないかな？
ロックを意識することなく同時操作が可能なだけじゃなく、
ある時点のスナップショットがとれたりするといいんだけど

vectorってstackじゃなかったっけ？

あぁごめん

・先頭から昇順で舐める（取り出さない）
・末尾から降順で舐める（取り出さない）

の部分に気を取られて基本出し入れせずに舐めるのかとおもたわ

出し入れが多いならvectorはダメね

なんか卑猥

いいなぁ、なんでも卑猥に見える、そういう童貞力。
それこそイマジネーションの礎なんだよなぁ、今にして思うと。

>>873
返答遅れて申し訳ないです

速度的に、できたらsqrt()平方根使いたくないのですが、平方根を使わないで
座標判定できませんか？

逆に２乗

あ、ありがとうございます。
それと最後に、
arというのは円錐の底面の半径でしょうか？

1-ar*arがどうやって導出されたのかわからん
ar<=1じゃないとsqrtfがエラーになりそうだけどいいの

プログラマーの求人を見ると
C言語やC++で開発している会社を全く見かけません
考えられるとすれば、以下の理由からだろうか

　１．C++は、古すぎるので今はどこも使っていない
　２．C++は難し過ぎるから、もっと優しい言語で開発している

>>900
ちょっと違う。案件はあるけど、新規に社外から人を募集する事が少ないってだけ。
そしてイントラ開発やWeb開発の求人が並ぶようなリストには基本的にあまり登場しないので、
もしもそっち系を見ていたら当然、ますます出てこない。

もうちょっと言っておくと、難しいとか易しいとか、古いとか新しいみたいな話じゃないって事。
一般の初心者みたいな人だとそういう観点しか持ってないだろうから、わからないかもしれないが、
これらはあくまで道具なので、そして道具の性質と案件内容による訳で、必要なノウハウ規模と事後の事もあるので、って事。

普通にＣ，Ｃ＋＋の技術者はあぶれてる状態
組み込みでは使われてるけど新規募集するほどの案件はない
今はJava, C#, PHPなどがよさげ
これからはビッグデータ特需でデータベースエンジニアの時代がくるでしょう

以降はマ板で

セーブデータ管理するクラスを作りたいんですけど、インベントリに入っているアイテムなどの情報ってどのようにセーブしたらいいですか？

アイテムクラスを継承してはいるんですが、アイテムの種類によって派生クラスのインスタンスを持っています。

アイテム名だけセーブして、ロード時にまたインスタンスを作れば、とか考えたのですが
文字列からクラスを指定するにはどうしたらいいのでしょうか？

if文でも片っ端から比較することは出来ると思いますが、アイテムの種類が多いのであまりしたくないです。

アイテムのID番号みたいなのはないの？

アイテム毎にクラス作ってんの？
クラスをひとつにして属性で種類とか効果持たせたら

>>906
ID番号を作ってもいいのですが、やっぱりif分の連発になってしまうような・・・

>>907
説明不足でした、インベントリなので武器や防具なども入ります。
イメージ的には初代ポケモンの、わざマシンとモンスターボールが同じインベントリにあるような感じです。

>>905

原始的だけど、私はアイテムのクラスごとにID割り当てて、

switch(id){
case 0:
Item* = new ItemA;
break;
case 1:
.
.
.
}

って感じだったよ。
100種類くらいあったけど、KIAIで入力したよ。

ワンライナーにすればたかだか１００行や

もう根本的にデータ設計に失敗してるよな。

動いてるコードなんてそんなもんだろ。

>>909
なるほど、では気合でやってみたいと思います。

>>911
どんな設計がいいのでしょうか？後学のために・・・

どういうコード書いてるかわからんからなんともいえんけど
アイテムの種類でクラス分けてるなら名前と種類のマトリクスありゃいんじゃないの
アイテムの名前の数だけクラス作ってるならしらん

>>913
とりあえずRDBを一通り学んだあと、本当にデータ設計がそれでいいのか考え直せ。
それからIDに対応したデータを探すなら配列にするかハッシュにするかだ。
片っ端からというのが既におかしい。

俺のやり方だと
種類ID（0=装備　1=わざマシン　2=ボール　みたいな）
種類の中の個別ID（ボールなら　0=モンスターボール　1=スーパーボール　みたいな）
って作って

ロード時にアイテムクラスコンテナ[種類ID]に種類IDごとにデータ(かポインタ)を全部ぶち込む
で、セーブに種類IDと個別IDをとっておけば1行でアクセスできる

って感じかなぁ

種類が多いのか、よく読んでなかったわ

>>915
種類ごとに分けたクラスを使うということだと思うのですが
(モンスターボール・スーパーボール・ハイパーボールは同一のクラスということ？)

セーブデータから取得したデータから、クラスの種類を判断する良い方法がないかなと質問しました。

セーブデータから取得できるデータというと、数値か文字列だけになると思うのですが(バイナリは知りません)
となると、>>909とちょっと似てますが
switch(TypeId){
case BALL:
Item = new CBall((int)ItemID);
break;
}
のような・・・

アイテムをクラスで分けるんじゃなくて効果をクラスわけしてアイテムのインスタンスに持たせた方がいいんじゃないの
アイテムの種類で大量にクラスが出来るってのがよくわからん
例えば武器と防具なら装備箇所、上昇するパラメータ、特殊効果等を属性で持っとけばクラス分ける必要なさそうなもんだけど

>>919

>>907にもちょっと指摘されたのですが、
ゲーム全体の武器種類総数が少ない代わりにそれぞれ異なるアクションを持ってたり判定があったりするんです。
ガンダムEXVSの格闘アニメーションみたいな・・・

例を挙げると、ソウルサクリファイスというPSVitaの魔法で戦うゲームがあるのですが、
モンハンの武器みたいにカテゴリ分けできなくて、魔法一種類一種類のモーションや攻撃判定方法自体が違うんです。

そうするとポリモーフィズムを使う前提でクラスを分けて動作を一つ一つ指定して・・・という感じです

>>920
動作を別クラスにして参照持たせたら？
動作毎にIDふっとけば取得は簡単だと思うけど

もしかして動作のパラメータをひとつひとつハードコーディングしてる？

>>921-922
そうですね、銃剣で切りつけた後流れるように打つモーションみたいなのも想定してたので
武器ごとにまとめたほうがいいかなと

武器のクラス分けはどちらにしろ、インベントリで管理する以上
少なからずクラス選別の問題があるので質問したんですけど・・・

いずれにしろ文字列からインスタンス生成しようと思ったら分岐でわけるしかないんじゃないかな
ただクラス数は減らせるんじゃないかと思ったので

超お勧めしないけどシリアライズって手段もあるな
超オススメしないけど

書くのが面倒なんじゃなくて分岐しまくりでパフォーマンスが気になるってことなら
配列にインスタンス生成する関数ポインタつめて、アイテムIDをその位置のintにしとけばO(1)で生成は出来ると思う

俺なら分岐でやるけど

>>926
行き着くところはその2択ですか、うーん・・・
考えてみます。ありがとうございました。

根本的なところに手を付けるとしたら、各アイテムの効能は
本体でなく外部スクリプトに出しちゃうのが一番スッキリするとは思う

でないと速度だけならファクトリ配列とかで何とかなっても
結局その配列生成部分がメンテ必須になっちゃうし

>>925
開発中にその部分の処理が変わってしまい、ロード出来ないとかなｗ
もちろんシリアライズのやり方にはよるんだろうけど

スクリプト化は時と場所を選ばないと
地獄を見ることになると思う

速度云々は抜きにしても、>926の方法で、
IDと生成関数（ファクトリだっけ？）のセットを登録できる仕組みも用意しておけば
基本クラス弄らずに、アイテムを追加できたりしないかな？

もちろん、どうやって登録するかという問題は残りそうだが…

ゲームの大半をスクリプトで作ってみたい

SKYRIMとか拡張性超重視して
建物・敵・クエスト・各種テーブル・AI・パラメータいろいろ
全部スクリプトなのかな

https://lh3.googleusercontent.com/-wn7exLjQ2C8/TmTIxfxlZfI/AAAAAAAAEqQ/T4pB3TSEbUY/AC6_0905%252520%2525283%252529.jpg
こういうなめらかな煙ってどのようにして表現したらいいですか？

ビルボードの煙オブジェクトを並べてみたのですが
ちょっとミサイルの量が多くなるとめちゃんこ重くなります。

ミサイル一本につき煙オブジェクトを60個に絞って、自分の移動座標に置いていくというのを繰り返してます。
今の段階でミサイルが大体200本ぐらいは飛んでも大丈夫なようにしたいです。（恐らく他にも色々エフェクトを追加していくので）

ミサイルは結構高速で飛ぶので、煙オブジェクトを少々多めにおかないとライン状に見えないので、少なくとも60から300ぐらいに増やしたいです。

ビルボード以外で一番軽い処理となるとどのようなものでしょうか？

>>935
とりあえずGPU側で処理とか？
CPU側からは計算用の係数だけ渡すとかして。

もうちょっと言うと、予めVertexBufferに3*2*自分で決めた最大表示数の煙のセル個数分の座標値とUVは固定、
あとセルの単位で自分で決めた配列番号並べてシェーダに渡しておいて、
通常は毎度必要なだけの係数をUniform変数だけセットして、シェーダで描画させるみたいな方法
アクションゲームのエフェクト処理書くときよくやる俺

>>937
プログラマブルシェーダとかいう奴ですか・・・

そもそもビルボードは頂点数が少ないので、処理をGPUにやらせても負荷軽減にはならない。
遅くなっている奴は大概、ビルボードの数だけ描画を行っているのが原因。
頂点バッファを一つにまとめて、描画回数を一回にするだけで解決する。

そうとは限らない。

描画オブジェクトを1つにまとめるということ？？
DXライブラリで入出力持ってるんだけど詰みですか？

↓この関数群しかない
http://homepage2.nifty.com/natupaji/DxLib/function/dxfunc_3d.html

とある頂点のインデックス

DrawPolygonIndexed3D
こ、これかぁ・・

プログラムの中で頂点座標指定したりUV操作したり結構難しくないですか

２Ｄにすればいいじゃない

ジオメトリーインスタンシングが最強

>>946
こんなんどこで覚えてくるの
プロ？

DirectXとかOpenGLとか追いかけてれば
自然と入ってくる知識だと思う

ネットでも稀によく取り上げられているし
Direct X SDKのサンプルにもあるしおすし

お前らはgemsとか愛読してんの？
アレ高すぎて手が出ないんだけど

今更な感じがしないでもないですが、
ゲーム開発にはC言語とC++は、どちらが適してるプログラミング言語と言えるでしょうか？

俺はこれまでC言語とC++は同じものという考え方をしていたのですが、
よくよく考えると、C言語とC++は別もののプログラミング言語であるように思えました
C++は、C言語にプロジェクト指向を取り入れた言語であることは言うまでもないですが、
オブジェクト（クラス）を使う利点は、ワープロやアプリケーション開発に向いているように思えます
つまり、同じ処理を繰り返す比率が多いからです

そしてC言語は、組み込みシステムと呼ばれるものですので
C++よりもC言語の方がゲーム開発に向いていると思える
組み込みシステムとは、ゲーム機器に組み込まれているハードウェア+ソフトのシステムのことです

何処から突っ込んだらいいの？

全く同じ実行内容のゲーム開発をするとして、
C言語だけで組まれたプログラムと
C++のオブジェクトを使って組まれたプログラムを見比べると
C++の方が遥かにややこしいプログラムのような気がします

クラスを使うためにクラス内でメンバ関数やメンバ変数を使って
publicやらprivateやらを使って定義を構築
メインプログラムからはクラスを使うために
new演算子でインスタンス作成をしてオブジェクトを作成
そして、そのクラスのメンバ変数を呼び出してプログラムを構築する
クラスを使うには、これだけたくさんの工程が必要なのです
C言語だけで組むなら、直接命令を打ち込むだけで済むじゃないですか？

ゲームというのは、コントローラーに付いている僅かなボタンしか使いません
キーボードを使って文字を入力したりもしませんし、
与えられた項目を十字キーで選択して、決定ボタンを押すだけです
そのようなシステムになぜ、C++でなきゃいけないのだろうか？

書店で見かけるゲームプログラミングの本はC言語を使ったのはよく見かけますが
C++で解説しているゲームプログラミングの本が全くないのは、そのためのような気がします。

>>952
すみません
オブジェクト指向の間違いですｗ

あと、C言語だけを使ったプログラムとは
C++を使うがオブジェクト指向の機能だけ使わないという意味です
つまり、変数の宣言や初期化をプログラムの冒頭でやらなくても済むという
C++の特徴などは使うという意味です
C言語の場合、プログラムの途中で変数を宣言して使うことは出来ませんが、
そういうのは抜きで、あくまでもオブジェクト指向の機能だけ使わないという意味です

ゲームが項目を選んで選択肢を押すだけのゲームだったらいいね

ゲームは一秒間に60回同じ処理繰り返すわけだけど、アプリケーションやワープロの方が同じ処理を繰り返す比率高いの？

ていうかそれ以前に同じ処理繰り返す比率とオブジェクト指向になんの関係があるの？

C言語にも構造体という技術もありますし、
メンバ関数を使わなくても、普通の関数を使って呼び出すことも出来ます
グローバル変数を使えばスコープ外に変数を使うことだってできますし、
グローバル変数でも解放は出来るじゃないですか

そう考えるとC++でゲーム開発をやっていた自分が無駄なように思えてしまいました
なぜ、俺はここまでオブジェクトを使うことに拘ってるのだろう？と・・・

オブジェクト指向のほうが個人的にはゲームに向いてると思うよ

ゲームは、ゲーム内のオブジェクトを動かしたりアニメーションさせたりするわけで
それには座標やら向きやら速度がオブジェクトそれぞれに必要なわけで
これらの情報をまとめて持つということに関してオブジェクト指向がプログラマにとって一番わかりやすいはず。

別にプログラマの技術力を無視した視点から見ても
助けてくれるサポートコミュニティが無数にあるフレームワークというか言語のほうがいいんじゃないか

>>956
俺が言ってるのは、クラスを１つ定義しておいて
それをたくさんのオブジェクトでクラスを複製して使うという意味です
オブジェクトの特徴ってそういうことじゃないですか

１本のゲームを作り上げるのに
クラス化にすることがそれほど必要なことなのでしょうか？
シューティングなら主人公の構造体と敵の構造体を別々に個々に用意してもいいような気がします

一度処理を書き込んでしまえば外部のループから頭スッカラカンにして呼び出すだけでいい
っていうのが楽で素晴らしいと思う

>>958
その気づきは大切なことだからいいと思うけど
まずオブジェクト指向の利点について勉強した方がいいんじゃないの？

ちなみにC++のコードはCのコードに完全に置き換えることも出来るよ
ついでにObjective-Cも

グローバル変数を使えばできる

C++なら使わなくてもできる。素晴らしいじゃないか

>>959
まあ、俺が単にオブジェクトが苦手ということもありますが、
助言ありがとうございます

DirectX学ぶにはどうしたらいいですか？
猿でもわかるようなのがいいです。

デバイスの宣言とか頂点バッファ？とか、
C++初級者でもシェーダプログラミングとかまでこれ一冊！
って感じの本無いですか？
贅沢を言えばGPUに処理投げられたり？するとか、そこら辺の基礎知識も一緒に学べるようなもので、
ゲーム開発を意識した本が良いです。

ベクトルや行列の基礎知識はあります。
予算は5000円付近で

やっぱりDirectXの前提知識が無いのでわかりやすいのがいいです。

なんか、アホな会話がされているようだが、俺もアホだから興味深い話だｗ

俺はオブジェクト指向がどうも理解できなくて、グローバル変数や構造体でゲーム作ってる
ヘボプログラマだから、クラスだのなんだのがゲーム製作に有用なんだったら
どこがどう有用なのか知りたいと常々思ってる。

けど、解説とか「だからそれがゲームにどう関係あるんだよ」みたいなのしかなくて
どうにも身につかないんだ。

ヒント：フレームワーク

あ、俺は職業ゲームプログラマーというわけではありません
ただの趣味でゲーム開発を楽しんでいるだけです
最初はC言語だけでゲーム開発をやっていたのだけど、
途中でC++というのを知って
オブジェクトに手を出してみたのですが、それが意外と難しくてつまずいて
そこで、なぜ、俺はこんなややこしいオブジェクトを使ってるんだ？ウガー！
となってるだけですｗ

オブジェクトにつまづいたことへの愚痴のようなものです

>>964
ちょっとわかりづらくなるかもしれない例えになるんだけど

C言語の構造体だと、例えば敵とキャラクターの接触が起きた時に
それぞれの構造体データに対して、
「おいお前、敵とぶつかったから一旦座標戻すからな、あとHPからダメージ分引いとくから、あとダメージ受けた時のリアクションにしとく」
という処理を施すんだけど
クラスというオブジェクト指向を持って、クラスに対して「振る舞い」を予め処理しておくと
「おいお前、この敵とぶつかったから」
という処理で終わる。

他にも色々あるけど、つまりその処理が何をしているのかわかりやすくなって、今どんな処理がされているのかわかりやすくなる
→デバッグしやすいし、多人数で作業分担しやすい、予期しないデータ改変が行われない

というメリットがある
でもオブジェクト指向が苦手なら苦手で、別にC言語で作ってもいいんじゃないかね
作れないわけではないから

日本語が変でした

これお願いします>>965

誰かC言語ではなくC++を使ったゲームプログラミングの本を執筆してくれる人いないかな？
俺が手にしているゲームプログラミングの本は、全てC言語ばかりです
それをC++のオブジェクトの置き換えるために、
C++の本を買いあさってオブジェクト指向に構築し直しているのだが、
それがうまくいかない・・・

俺が持ってるゲームプログラミングの本は、全てC言語ばかりですので
本当にお手上げ状態です
今は、オブジェクトを理解するために、ゲーム開発を一時中断して
仕方がなくJavaを学んでいるところです

>>969
ありがとうございます
言ってる意味が、分かりそうで解からないという
モヤモヤした状態ですが、
なんとなく「オブジェクトが便利」ということだけは伝わりました

もう少し大人しくオブジェクトを学んでみることにします

明確にコードがこう変わる！っていういい例があった

ttp://dixq.net/g/
ここの「メニュー画面の作り方」を読むんだ
1,2,3とC++編の違いがわかると大きい

>>973
ありがとうございます。
そのサイトでしたら、C++以外の
C言語でDXライブラリを扱う解説は一通り読みました
サンプルコードを打ち込んで実行結果を確認して
すべて上手く行ったのでC言語でのゲーム開発については自信がつきました

あとは、それを自分が開発するゲームに置き換えてプログラミングをすれば
C言語によるゲーム開発のゴールも見えていたのですが、
俺の場合、途中でC++のオブジェクトに手を出してしまったのでドツボにはまってしまった
つまり、完成するはずのゲームは完成しない

>>969
>でもオブジェクト指向が苦手なら苦手で、別にC言語で作ってもいいんじゃないかね
でも、いいです。
せっかくオブジェクトに触れたので、オブジェクトを身に着けてみせます
ありがとうございました

Cを読んでうまく行って自信がついてC++に手を出してわからなくなった
じゃあそのサイトのC++を読めばいいじゃない

>>960を見た感じだとクラスとただのデータ構造の違いがわかってないみたいだし、ポリモーフィズムに関する理解が薄いんだと思う
確かゲームつくろーにデザインパターンのゲームへの応用みたいなのあった気がするから
それ見たら少しは理解が深まるんじゃないかな

あと純粋にC++覚えたいってんじゃなかったらCでやっちまえばいいと俺も思います

>>975
メニュー画面だけ解説されてもね
どうせなら、全部C++で解説してほしい
というか、そのサイトのC++以外のC言語を使った解説は丁寧でわかりやすかったけど
C++だけ、いきなり過ぎて最初は意味がわかりませんでした

>>976
C++のオブジェクトの扱い方については、なんとなく理解しています
メインプログラムでクラスを呼び出してオブジェクトを作成する
new演算子を使うとクラスのコンストラクタを読みに行って
まずは初期化が行われる

クラス内で扱う変数は、同じクラス内のメンバ変数から扱うことになり、
メインプログラムからは、
「オブジェクト、クラス、メンバ変数（引数）」という形式で組み
ここに書いた引数は、クラス内のメンバ変数に移されて
メンバ関数内で処理で実行結果を映す

という、一連のオブジェクトの流れまでは理解できたが、
かなりややこしい

俺はC++のオブジェクトを独学で学んだ後に、
Javaのオブジェクトを独学で学んでみたのですが
Javaのオブジェクトの方が遥かに楽ですね

C++のようにhファイルでクラス宣言とかしなくていいでしょ？
メインプログラムもJavaファイルですし
クラスも同じJavaファイル
そして公開クラスはJavaファイルに１つしか組めないというルールも分かり易い

今はJavaのオブジェクトをC++のオブジェクトに置き換えて考えてみようとしたのですが、
やっぱC++のオブジェクトは面倒で、すっごくややこしいですね・・・
Javaのオブジェクトが分かりやすいのは、
Javaはすべてクラスだからです。クラスだけでプログラムを組むからです

>>977
でもオブジェクトがただの構造体と比べてどう便利なのかわかんないんでしょ？
文法や仕組みだけわかっても概念や考え方わからないと役に立たないよ
GoFのデザインパターンはオブジェクト指向のかなりメジャーなベストプラクティスだから
それが理解できればオブジェクト指向のメリットも理解できると思うよ

念のために言っておくけどベストプラクティスは「成功例」であって「正解」ではないからそこは忘れずに

>>978
JAVAはオブジェクト指向言語だけどC++はオブジェクト指向「も出来る」言語だから
いろんなプログラミングパラダイムを持つのがC++の特徴

ぶっちゃけ人によってスタイルちがうからメンドイ

>>978
？？C++でもこーゆー書き方は出来るよ？
class CMutex
{
HANDLE m_hMutex;
public:
CMutex(void){m_hMutex=CreateMutex(NULL,FALSE,NULL);}
virtual ~CMutex(void){CloseHandle(m_hMutex);}
DWORD Wait(DWORD dwMsec=INFINITE){return WaitForSingleObject(m_hMutex,dwMsec);}
void Release(void){ReleaseMutex(m_hMutex);}
};

class CEvent
{
HANDLE m_hEvent;
public:
CEvent(void){m_hEvent=CreateEvent(NULL,FALSE,FALSE,NULL);}
virtual ~CEvent(void){CloseHandle(m_hEvent);}
DWORD Wait(DWORD dwMsec=INFINITE){return WaitForSingleObject(m_hEvent,dwMsec);}
HANDLE GetHandle(){return m_hEvent;}
void Set(void){SetEvent(m_hEvent);};
void Reset(void){ResetEvent(m_hEvent);};
};

ポリモーフィズムが便利だよなあ
敵のオブジェクトをリストに突っ込んでおいて
イテレータで回しながら順に敵の処理を実行するとか
Ｃ言語だとどうやるんだろ

よし。じゃあ、新たにJava版のゲームプログラミングの解説サイトでも作ることにしよう。
開く
JET++ &#8207;@JET_JAPAN 8月3日

とにかく約2週間も暇になってしまうので、先にJava学習を始めてみることにしよう。
どうせ職業訓練で学ぶJavaはシステム系のプログラミングになると思うので、
こっちはJavaを使ったゲームプログラミングを学んでいくことにしよう。
開く
JET++ &#8207;@JET_JAPAN 8月3日

今日が8月3日ですから、約2週間も暇になる。あ、明日は日曜日で
ハローワークはやってないんだった。なので、ハローワークは来週の月曜日の
8月5日に行くことにしよう。
開く
JET++ &#8207;@JET_JAPAN 8月3日

>>979
いや、さすがにそれぐらいは解かる
構造体は変数しか扱えない
クラスは変数と関数が使える
Javaの場合は、フィールドと変数とメソッドだけど

メインプログラムでクラスを呼び出してオブジェクトを作り、
そのオブジェクトでメンバ関数に引数を渡せば
クラスの中で、別のメンバ変数なども動かして、様々な部品を作ることができる
あとは、そのオブジェクトのメンバ変数を呼び出せば答えを返すことが出来るし
メンバ関数を呼び出せば、その関数のreturnの値を呼び出すことも可能

構造体に関数を追加したのがクラスっていう認識なんだろうなあ
継承とか、ポリモーフィズム、デザインパターンあたりを
キーワードに勉強するといいと思うよ

>>981
うん。
C++のクラスでも、そうやって宣言も定義に含めることもできますが、
そういうことじゃないんですよね
C++のオブジェクトがJavaのオブジェクトよりややこしいというのは・・・

俺は最初にC++を使ったオブジェクトをプログラムを組んで学んでから
Javaに触れてみると、
いきなり「え？」と思ったよ
だって、いきなりクラスの中にプログラムを組んでいくのだし

だが、Javaを使ってみると、意外と分かり易かったです
コードの組み方がC言語と同じだったので
先にC言語を学んでおいてよかったと思いましたね

>>985
まあ最初はみんなそんなもんでしょ、実装上は間違いってわけでもないし
その理解だと設計が手続き型の延長にしかならんからメリットが見えないけど

>>985
継承あたりまでは学びました
継承は確かに便利ですね
いくらでもスーパークラスを受け継がせたサブクラスが作れますからね

俺はこの継承という技術は好きです
前にRuby1.9のプログラムを学んだことがあったのですが、
あれは継承の連続でしたね
無数にあるクラスを一つ一つ辿っていくと
全てのクラスが１つのスーパークラスの上（下？）で、動いているのを知った時は
面白い技術だなと思いましたね

ポリモーフィズム、デザインパターンは、まだ知りません

あ、俺が見たRuby1.9のプログラムは、
RPGツクールVX Aceに入ってた
Rubyスクリプトプログラムのことです

>>988
ならポリモーフィズム学んでからまた考えればいいんじゃない
それでもCでいいと思うならそれはそれでいいと思うけど

ぶっちゃけオブジェクト指向の大きな利点は再利用性とかメンテナンス性だから
一人でやっててメリット見えないってのはありえるし

個人的にはソースを見るのが一番解りやすいな
クラスの扱いは別にC++に限らないから他言語でもいい

市販ゲームではDOOM3とかソース公開しているから見てみるといいかもね

>>965
DirectX は初心者スレがどっかにあったと思うから探してみるといいと思う
そこで質問したほうがいい答えを得れると思うよ

あと, 本だけじゃなくてネットで初心者サイトを探してみるとか
実際に DirectX で簡単なプログラム組んでみるとか
読みにくいけど, MSDN の DirectX のページを読んでみるのもおすすめ

誰か次スレ頼む

立てといた
http://toro.2ch.net/test/read.cgi/gamedev/1376262450/

ポリモーフィズムで自機と敵機を一緒にして管理してるんですけど
プレイヤーが見るUIを描画する際にどこに処理を置いたほうがいいですか？

自機をインスタンス化する時に、UIクラスなどを作っておいてそこに登録させるのか
もしくは予め自機敵機のスーパークラスにUIを描画する機能を作っておいて、
描画するときには、線形探索じゃないですけどループ回して、自機だったら描画、敵機だったら描画しない、という判断をするのか

どっちのほうがわかりやすいですか？

プレイヤーが見るUIってなんじゃらほい

前者でいいんじゃない
特定のサブクラスしか使わないメソッドを親に持たせるとクラスのスコープが曖昧になるし

ちなみにUIってのはHUDの事でいいんかな

Win8だとUSBがドライバまともにインストールできんの、直ったんかね

もう少し人に伝わる文章を書く努力をしろ

埋め

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。