ゲームプログラムなら俺に聞け22

1 ：11/11/17 〜 最終レス ：11/12/24

エロゲしか作ったことないけど
なんでも聞いてちょ
【前スレ】
ゲームプログラムなら俺に聞け21
http://hibari.2ch.net/test/read.cgi/tech/1316762253/
このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

2 ：

デバイスロストってWiiとかPS3でも起こるの？

3 ：

なにしてんの

4 ：

>>2
知らないけど起こるんじゃない？
コントローラー引っこ抜けたりとかよくあるだろ。

5 ：

【C/C++/Windowsアプリケーション入門関連】
猫でもわかるプログラミング
http://homepage2.nifty.com/c_lang/
WisdomSoft
http://wisdom.sakura.ne.jp/
【DirectX SDK】
ダウンロード
http://msdn.microsoft.com/ja-jp/directx/aa937788
Direct3D C/C++ リファレンス
http://msdn.microsoft.com/ja-jp/library/cc323912.aspx

6 ：

少し話はずれるけど
途中からコントローラー挿しても反応してくれないゲームは困る
ちゃんと毎フレ調べろよ

7 ：

FPSとかかなり多くの男根が描画されるやつってどう処理してんの？
当たり判定までは分かるんだけど、どうやって管理しても負荷高そうな。

8 ：

>>7
弾痕管理クラスを1つ作って一括管理

9 ：

男根管理ってどこの女王様だよ

10 ：

ぷよぷよの消える条件のアルゴリズムが分からない。
テトリスみたいに1列とかなら余裕なんだけど、
あんな風に上下左右に繋がって枝分かれして折れ曲がった状態のってどうやって検出するんだろうな。
昔ペイントソフト作ってて塗りつぶし範囲の検出方法が分からなくて頓挫したが
同じことじゃないかと思う。

11 ：

>>10
ぷよぷよのアルゴリズムはググればすぐ見つかる。

12 ：

>>10
プヨの結合を深さ優先でたどって4以上ならドーン
なんでこんな簡単な事もわからないんだろう
こんな事で悩むとか明らかに情報処理資格の一つも取れないレベルだよな
そんなんでゲーム作るとかまじやめてくれ
基礎を叩き込むまでエディタに触るの禁止しろ

13 ：

『でろ〜んでろでろ』という落ち物パズルは御存知だろうか
あれの判定はむずかしそうだ

14 ：

>>13
知らん、動画うｐ

15 ：

ぷよぷよよりパズルボブルのほうがアルゴリズム難しそうじゃないか？

16 ：

http://www.youtube.com/watch?v=PxrfWFjl17I
ニコニコにも別のプレイ動画があった
『でろーんでろでろ』の表記で検索したほうがいいようだ
基本的にぷよぷよの丸パクリなんだが、一点追加されてる要素が
『でろが消えると、消えたでろの周辺にあるでろから触手らしきものが伸びて、
触手がからみあったでろは離れた位置にあってもつながってるものとみなして連鎖の判定を行う』ってこと。

17 ：

ぷよぷよは消せるとこが道になると考えれば要は迷路探索と同じだろ
そんなもん再帰で一発、ぷよ程度のフィールドなら深さもそれほど考える必要ない

18 ：

>>16
自分で説明してる仕様をもっと詳しく説明してみな
「消えたでろの周辺」ってどこマスの事だよ
「触手らしきものが伸びて」ってどこにどう伸びるんだよ
「触手がからみあった」ってどういう事だよ
etc.
こういうパズル系は仕様を事細かに説明すれば、
それがほぼアルゴリズムの根幹を成すようになる
あとは効率の問題だ

19 ：

おおさわぎするようなことかw

20 ：

FC、SFCで最も難解なアルゴリズムで作られたゲームは何？

21 ：

>>19
大騒ぎというか、作るならしっかり考えなきゃならないことだよ
実際にCやJavaScriptなんかで作ろうとすると、
頭の中で考えてるだけじゃなかなか上手く作れないじゃん
こういうアルゴリズムで実現できる、というのを
やっぱり疑似言語や文章なんかに一度書き下してみるべきだよ

22 ：

うむ。再帰をエレガントに表現できる擬似言語か文章なら尚良いね

23 ：

うん

24 ：

SFCなんてそんな込み入ったアルゴリズム使うにはスペック足りないだろ
そういえばPCゲーってPCの性能でAIの性能は影響受けないの？

25 ：

AIをスレッドで実装して時間の許す限り計算とかなら影響するだろうな

26 ：

>>24
最初にお行儀の良いアルゴリズムを考えておいて、
その後でそれをマシンのリソースに合わせて最適化するんだよ
ところで、そんな込み入ったって、どんな込み具合を想像してるんだ？

27 ：

>>24
> そういえばPCゲーってPCの性能でAIの性能は影響受けないの？
思考時間が限られる場合や、厳密に限られてはいないがユーザーを待たせたくない場合は、
PC に限らずマシンの性能はAIの（実現したい）性能に大きく影響するだろ
囲碁や将棋なんか良い例だ

28 ：

ニンテンドー６４の最強羽生将棋は今でもそうとうレベルの高い思考するらしいね
当時は『ハード同時発売のソフトが将棋かよw』って言われてたもんだが

29 ：

将棋AIのアルゴリズなんて見当もつかねーよ
置ける場所を洗い出してその中からランダムで1箇所選んで置くとかしかできねーよ
将棋に限らずオセロとか囲碁とかチェスとか
バックギャモンならなんとかなる

30 ：

基本はα-βだ

31 ：

将棋や囲碁のAIはどんなに性能がよくなっても
心理戦がないから面白くない。

32 ：

将棋自体がエンターテイメント性にかけてオモシロクナイ

33 ：

ゲームプログラマになる前に覚えておきたい技術に変なレビューがついて
売れ行き悪くなってんな・・・
Cだけでゲームとか苦行にもほどがあるってのに
あんなレビューを真に受けてCしかできない奴が増えたら困るぞ

34 ：

本質をわかってないやつほどCで書くのがへた

35 ：

そりゃ速度をギリギリまで追い求めたらＣで完全に自分でメモリ管理とかになるんだろうけど、
現代のパソコンの性能で、そのレベルが必要な趣味グラマなんて何人いるんだ。

36 ：

タイピングゲームで複数の入力に対応させるにはどうしたら良いですか？
「ショット」
shotto
syotto
sixyotto
silyotto
shixyotto
shoxtuto
syoltuto
shixyoxtsuto
・
・
・

37 ：

無料RPG製作ツール「ロープレジェネレーター」
直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力する
ことができます。(HSP製のソースコード付きで、スクリプトの知識があれば
自由度の非常に高いカスタマイズができます）
他にも仲間預かり機能（100人も）や、仲間の状態/状態異常を細かく設定
できたり、乗り物が作れたり、ゲーム中に画像を差し込んだり、回転や
フラッシュなどのエフェクトなんかも簡単に作れる様です。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
戦闘はデフォだとドラクエ系。
・次期バージョンのロープレジェネレーター2.00アルファ版2を公開しました。(2011/10/29)

38 ：

>>36
ショを例にとると、
sho, syo, si＋ョ の3パターンある
sの次に何が入力されたかによって、
この3つパターンで分岐すれば良い
sの次にhが入力されたらsho、
sの次にyが入力されたらsyo
sの次にiが入力されたらシを確定して、次にョの単独入力を要求する

39 ：

正規表現でおｋ

40 ：

>36
これライブラリで売ってるところがありそうなもんだけど

41 ：

>>37
HSPかよｗ
なんでわざわざ産廃使って開発しなきゃいけないの？ｗｗｗ

42 ：

正規表現ってperlとかじゃないときついだろ

43 ：

boostでいいじゃん

44 ：

>>37
そういうのは HSP じゃなく中間言語を出力しておいて、
後から HSP にも C にも Haskell にも BrainFack にも
変換できるようにしておくべきだよ

45 ：

PS Suite SDKスレってまだ無いのね

46 ：

>>42
ガチで正規表現全く使えない言語とかアセンブリぐらいじゃねえのか

47 ：

それで作るよりスマホで作るほうが確実に収益になるだろうな

48 ：

スマホでタイピングソフトとか勘弁してくれ

49 ：

今のところスマホで一番ゲーム作りやすい環境ってM$？

50 ：

勘で答えるとアンドロイド

51 ：

>>49
FlashとUnityとUnrealから出力できるiOS

52 ：

>>46 アセンブラだって、正規表現ライブラリを作ろうと思えば作れると思う

53 ：

アセンブラだと文字コードで考えなきゃか

54 ：

機械語で３Dゲーム作れますか？

55 ：

作れないこともないが、昨今のような膨大かつ高水準な処理を、全部機械語を手で書くのは非現実的。

56 ：

現実的に可能か不能かはともかく、無限の時間と労力があれば、機械語がいちばん万能だろう。

57 ：

そりゃ無限の時間があれば将棋の必勝法だってわかるわけで。

58 ：

そうか、無限の時間が手に入ればいいんだな！

59 ：

残念ながらティプラー円筒行きという銀河鉄道の切符は、松本零士がハードSFを
理解できないので存在しないがなw

60 ：

DirectXで作るときにフルスクリーンにすると何か良いことあるの？

61 ：

画面から離れてもよく見えるから目が悪くならない

62 ：

>>61
それならウィンドウ最大化でいいじゃん

63 ：

>>60
OSが描画に関してはそのアプリケーションのことしか考えなくなるから描画速度が上がる

64 ：

でも今時フルスクリーン専用ソフトなんか出したらユーザは起動してくれないと思うけどね

65 ：

戦略性高いゲームは色々と参照しながら遊ぶのがデフォだからなぁ
あと最近じゃ実況しながらプレイするスタイルも普及してきてるし
なにかとウィンドウモードのほうがいいよね

66 ：

レースゲームとかオセロ将棋囲碁とか
観戦スタンダードになればいいのにな。
配信がデフォで、中央鯖に対局情報が集められてて
好きな対局を観戦できるようなシステム。

67 ：

そういうのはゲハでやれ
ここではプログラムの話をしろ

68 ：

EnterCriticalSectionとかpthread_mutex_lockの負荷ってどのくらい？
毎フレ100回くらいやっても100fps出る？

69 ：

余裕だよ使いまくっていい

70 ：

100回とかどこかでデッドロック起きそうだな
■スレッド1
ロックA
ロックB
〜処理〜
アンロックB
アンロックA
■スレッド2
ロックB
ロックA
〜処理〜
アンロックA
アンロックB
うっかりこんな風に書いてしまうと
最初の1つ目のロックが同時に起こったときに
2つ目のロックができずに詰む

71 ：

普通ロックの順番決めておいて処理にまとめておくだろ

72 ：

最近はGPUもデュアルだったりするけど、これって描画もマルチスレッド化が可能ってこと？
バックバッファを2つ作って、それぞれ別のものを同時に描画して、
それを最後に合成して出力するとかできるってこと？
例えばレースゲームだったら普通の進行方向のグラとバックミラーに写った内容を同時進行で描画していって、
それを最後に合成して出力できるってこと？

73 ：

GPUはもともと並列処理しまくりだよ
スレッド1000個とかそういう世界

74 ：

CPUはシングルコアからマルチコアへ、そしてメニーコアへと進んでいるが
ビデオカードは高速化が進んでいてハイエンドにもなると
ビデオカード１枚でPC全体の消費電力を軽く超えてしまう
ビデオカードはビデオメモリにDDR3を使っていたが、専用のGDDR3を作り、いまではGDDR5が出ているが
ビデオメモリの帯域がボトルネックになろうとしている
そんなビデオカードでクロスファイアしたら山がくらくら燃える
お前のPCでブレーカーがやばい
電力会社の社長が自ら裸足で殴ってくるレベル

75 ：

>>71
普通は排他処理が必要な機能ごとに管理するクラスを作る。
クラスの中に使いたい変数と、クリティカルセクシャン用変数と、
その変数にアクセスするためのSetValue()やGetValue()を用意しておいて、
そのSetValue()やGetValue()の中で変数を操作するときに排他処理がはたらくようにしておく。
そうすれば間違いはない。
通常はこうやって排他のためだけにクラスを作ることはあまりなく、
機能ごとにクラス分けされてるはずだから、その中でこれをやる。
グローバル変数をボコボコ使いまくってる池沼はここで詰む。

76 ：

カプセル化の基本なのにこの時代にまだわかってない奴が居るなんてな

77 ：

>>76
いつの時代でも初心者はいるでしょ
入門書は絶対になくならないし

78 ：

いや素人はいるけど
そんな素人がゲームつくろうとしてるわけで
それに驚いたわ

79 ：

ロック可能かどうかpluggableにするもんだと思ってたが
クラスのアクセサに内包しちゃうの？

80 ：

「正解」はない
「無難」があるだけ

81 ：

>>78
一度痛い目を見るのもいい経験だと思うよ

82 ：

意気がってるやつのレスがひどいｗ

83 ：

才能に嫉妬するなよ低脳

84 ：

ブラウザででろーんでろでろみたいなの作ったぜ
http://www42.atwiki.jp/syugyou?cmd=upload&act=open&pageid=250&file=hos.html

85 ：

ふーん、で？

86 ：

>>75
マルチスレッドってよくわからないんですが、こういうことですか？
class CriticalObject
{
CRITICAL_SECTION cs;
public:
CriticalObject(){InitializeCriticalSection(&cs);}
~CriticalObject(){};
virtual void GetValue(void*p,int kind) = 0;
virtual void SetValue(void*p,int kind ) = 0;
}
class Unko : public CriticalObject
{
int smell,color,size;
public:
void GetValue(void* p,int kind)
{
EnterCriticalSection(&cs);
switch( kind )
{
case 0:*(int*)p = smell;
case 1:*(int*)p = color;
case 2:*(int*)p = size;
}
LeaveCriticalSection(&cs);
}
virtual void SetValue(...)..
};

87 ：

値を読み書きするだけならstd::atomicでいいよ
CRITICAL_SCETIONとかコストかかりすぎ

88 ：

まずはstd::atomicが実装されてからの話だな

89 ：

boost::atomic_*

90 ：

まぁWindowsのクリティカルセクションは
最初スピンロックするから結構速いんだけどね

91 ：

俺はさ
ゲームのソースコードで
switch( phase ) {
　　case 0:
　　　　シーン0();
　　　　break;
　　case 1:
　　　　シーン1();
　　　　break;
　　default:
　　　　break;
}
この部分が好きでたまらないんだけど、分かる奴はいないか･･････
こんなソースコード、タスクシステムにしたら消滅するし、
今の俺の最高のソースコードではタスクシステムすら存在しないし、
もうこんなソースコードはかけないんんだけど、それでも、妙に気に入っているんだ　この単純な条件分岐
この、たかが　0 と　1が変わっただけで、　ゲームの画面がガラっと一変する
その様子をソースコードから直に感じ取れる部分。
タスクシステムにしちゃうと、それがみえなくなってしまう
プログラミングの美学だよ

92 ：

俺は何もかも我流だったから
シーンっていう概念さえも自分でたどり着いたんだよね
そのときの発見はうれしかった
だから、やたら気に入っているんだと思う
今まで我流で色々なものを見つけてきたが、
その中でもっとも、効率的な発見はきっとこのシーンの概念だった
これにたどり着いた瞬間、人のスペック的に見て
どんな大規模ゲームでも、作るのが可能になるだろ
まぁ実際は、ただのint型でswitchやっちゃうと、無限にシーンは作れなくなって
制限はかかるが･･･結構ぜんぜん十分だし、
ここで立ち止まってもよかった
けど俺は、きっとこの発見がうれしくて、さらに先の先までいってしまった
今の俺のソースコードは本当につまらないぜ
もう、本当に、つまらない。　どこも推敲の余地がないからか、　これ以上、リファクタリングできないからか
なんかわからないけど、つまらない。　その一言だけが漏れる

93 ：

迷宮にはまったな

94 ：

今の俺のソースコードには、シーンの概念が無い。
いろんな概念を消し去ってきたが、シーンまで消えるとは･･･な
ゲーム製作になれてくれば、タスクシステムは最初から作られていて、
キャラクター表示とか、とりあえずデフォルトのがあって、関数呼ぶだけ
だから、手作業で何かやるのは、シーンを追加するって作業だけ、
シーン間の移り変わりを手作業でつなぎ合わせたりするだけ
この時点でもう、かなりソースコードはつまらなくなっている
俺は･･･そこからさらに、
その手作業でやるべきそれさえも消してしまった
ヒントは木構造と再帰
いうなれば「無」だ、　どんどんゼロに近づいていってる　つまらない　ただひたすらにつまらなくなっていくソースコード
だから俺は今一度、シーン管理のタスクシステムを捨てて、switchで分岐させるソースコードをかいてみたくなっている
変なもんだよ　効率を捨てたくなっているんだ　効率を捨て、ソースコードの見た目を重視したくなってきてる
つうか正直、木構造と再帰ばかりのソースコードって見ていて疲れるからな。ずっとやってればなれると思うが、
なんか、俺は自分の頭が今どのくらい活動しているか負荷かかっているかって、なんとなくわかるんだけど、木構造や再帰の場合
通常ループのソースコードと比べて、１０倍とかそれ以上、負担かかってるのが分かる
ハゲるぞ
別に使いこなせないことがくやしくはない。プログラミングの果てがどうなるかなど、容易に想像できる
俺が見たものを"そのまま"に　伝えると、
　　最　後　は　　1　じ　ゃ　な　い　　　　最後は　　0　　になる
1個の関数をCALLすることで、何かの処理を行うのが、お前たちの今考えている、プログラミング　だが、最終的には0になり、関数をCALLしなくてよくなる。
なぜなら、最初から結果がそこにあり、何もする必要がなくなるんだ。この世界は、渦が渦を巻いて様々な物質が存在している。プログラミングの果てにはブラックホールのようなものがあって、
その渦を、全て解いて平坦なものにしてしまうだろう。　それが、俺のみた最後のソースコードだ。　信じろとは言わない、　けど、これが事実だ。　だから、程々にしておけ。　果てには何も存在しない

95 ：

俺がそのプログラミングの中にある「ゼロの概念」を解き放った場合
1000万人が失業する　　　まじで。
世界っていうのは、全員でゆっくりと大きな石を押しながら歩んでいる
みなはその石をどこへ運べばいいのか分からず、実は結構適当に押して歩んでいる
俺は、その石を「ある場所」へ持っていけば、「こうなる」というひとつの結果を見たに過ぎない
とりあえずその場所へ、石を持っていったらどうなるか　その計算式をみた
CPUはお前たち世界全員だ。この式を俺が解き放った場合、世界は･･･ゼロへ向かう　　全力でなｗ　・・・と同じさ
自分の首を絞めているって事にさえ気づかず、世界は「それ」を求め、ゼロに向かっていき、崩壊する
与太話？　っはｗ
そうであってほしい　だろうな
だから俺は、俺と、俺のことを認めている奴には「完璧」の概念と、俺の見つけた究極的にゼロへ向かっていくソースコードを教え、
ともに使っていくだろうけど、世界はそれを使うべきじゃない
オブジェクト指向の方向でいいと思ってるよ　関数型の方向には絶対くるな
こっち側は、きてほしくない
効率は高いよ　ただ、その効率っていうのは、様々なものを削って効率を高めるって事
今１０万行のソースコードが１００行になれば、いったい何人が失業するんだ。　人が働かなくてよくなって　腑抜けになっていく
俺は、自分はたとえ１０億の金があったとしても俺は何らかの仕事をするから、俺はそれでも腑抜けにはならないが
１０億も金があったら一生仕事をしないで遊んでるだけの奴は世界には多い気がする。
だから、あんまり１人で、本来大勢が行うべき仕事を独占して終わらせてはいけない　と　俺はそう思った。
とりあえず、このゼロへ向かっていく式「ゼロの式」は、段階を持って公開していくべきもので、突然これを投下した場合、
太平洋のど真ん中に、１０００００００兆トンの核エネルギーを人類に与えるようなもので、、わかるだろ・・・人は、自滅するんよ

96 ：

なぜ、ゼロになるかを説明すると、
"再帰的"な構文は、再帰呼び出しで書きなおせることは分かるだろ
まず、ソースコードを"再帰的"な構文で、後々完成したら「あーやろうと思えばこれ全部マクロでやれるな」って感じになるようにかいていく
ようは木構造でやるんだが･･･　あまり深く考えなくていい
で、それを再帰、つまりマクロで定義しなおすと、
ソースコードは1 つまり、マクロCALLだけになる
あとは、この1を0にする方法
それは、何種類かあるんだけど、一番説明しやすいのが
不動整数にしてしまうこと。　不動整数っていうのは、二度と値の変わらない整数の概念。
一度、数字を与えられたら　もう二度と変わらない　、最初にまず256が作られたとするだろ
256　って数字を、とある箱にかかれたら、二度とそれを変えない、永遠にそこに佇ませる。
その不動整数を、どんどん生産していくと、　最初は256しかなかったとしても、　すぐに1〜255なんて作れる。
俺一人じゃ作れないけど、世界がもし動き出してしまえばそんなの一瞬だ。
そうして、不動整数を躍起になって世界が作っていって、
99999999999999999999999999999999個くらい作ったところで、
すでに最初に作られた256が、256って数字の意味を成していないことに気づき、「数字という概念」がかき消されるｗｗｗｗｗ
ヤバさわかってきただろ････
プログラミングをずっとやっていけば、その果てには、数字の概念ｲﾗﾈwwwってなるんだよ　　ENUMっていうのでその片鱗はお前ら見てきてるはずだ、デジャヴはあるはず
数字の概念がなくなるってことは、この世界でコンピュータはなくなって、次に個数がなくなって、数えるということをしなくなって
人口という概念もなくなる、つまり、、、な、もうわかるだろ、　輪廻だよ　渦を、　解き始めている　ゼロへどんどん向かっていく
プログラミングの中に存在するブラックホール。
世界は愚かで、おそらくその頃には不動整数を生産し続ける不動マクロをすでに作っちゃってるはずだから、もう誰にもとめられない
世界はそこで永久凍結を開始する　　本当に見ちゃいけない領域

97 ：

"再帰的"な構文で再帰呼び出しで書けないコードもあるんで、ぜひ頑張って考えてみれw
Cならそんな信じられないようなシロモノが書ける、キモはswitch

98 ：

>>91-96
かなりヤバいこと書いてると自覚してるから、削除でかまわない
ゼロにたどり着いた後って、実は、俺にもわからないんだ
ただ予想ではおそらく、ゼロに近しくなってきた所でブラックホールのようなものが、いきなり空間に発生して
全てを飲み込みはじめる
今、宇宙にあるとされているようなブラックホールが出現するか、あるいはそうではなく
目にはみえないっつうか、重力も発生しないブラックホールかもしれない
ただそこに何かがあって広がっていく。
そんな何かが発生するだろうとは思っている
人類が、みな俺のようであれば　あるいは生き残れるんだが･･･　とりあえず向こう1000年は触るべきでない概念
とりあえず意味は分からずともこれだけは知っておけ
プログラミングの究極は　1ではなく　0になると

99 ：

>>97
んーとね･･･
再帰呼び出し（関数）じゃない。
再帰マクロ
Ｃ？　誰がＣの話をした･･･　RubyやLispですら付いてきてない次元の話してんだぞ今
はいはい、ご立派だ
お前たちはオブジェクト指向の道を歩んでてくれ
俺自身怖い。ゼロに世界が向かい始めたらどうなるのか、確信のもてる予想が立たないんだから
そんなものを、おそらく世界で自分だけが見ちゃってる現実、
世界どころか宇宙そのものをかき消せるんじゃないかっていう
俺みたいな小さな存在に、何でこんな「式」が思いついてしまってるのかわからない
なんだろうな････

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
14: Perlについての質問箱 49箱目 (618)
15: Win32API質問箱 Build100 (720)
16: くだすれDelphi(超初心者用)その53 (966)
17: ATL/WTL Part6 (904)