ゲームエンジン総合スレ★２

1 ：2011/02/01 〜 最終レス ：2012/11/02

このスレはゲームエンジンの製作・雑談・情報交換を行う為のスレです。
ゲームエンジンに関係ない話は該当スレか雑談スレでどうぞ。
総合発表＆雑談スレッド その3
http://hibari.2ch.net/test/read.cgi/gamedev/1216633635/
※前スレ
http://hibari.2ch.net/test/read.cgi/gamedev/1293381827/

2 ：

神奈川産の基地外とそれに粘着する基地外は書き込み禁止！！
ゲーム製作にスクリプトが必要かどうかの議論はよそでやれ！！

3 ：

■関連スレ
・各種ライブラリ紹介スレ2
　http://hibari.2ch.net/test/read.cgi/gamedev/1177886529/
・推薦図書/必読書のためのスレッド in ゲ製作技術5
　http://hibari.2ch.net/test/read.cgi/gamedev/1261811596/
・タスクシステム　（※タスクシステム総合スレ　実質part10）
　http://hibari.2ch.net/test/read.cgi/gamedev/1285930493/
・物理エンジン　AGEIA PhysX　（※実質的に物理エンジン総合スレ）
　http://hibari.2ch.net/test/read.cgi/gamedev/1192632076/

4 ：

■各種ゲームエンジンのスレ（順番は適当だ）
・DXライブラリ 総合スレッド その7
　http://hibari.2ch.net/test/read.cgi/gamedev/1286180687/
・Selene/Lue/Luna ライブラリ Trial-Version 3.00
　http://hibari.2ch.net/test/read.cgi/gamedev/1244947599/
・【3Dエンジン】Irrlicht初心者質問スレその4
　http://hibari.2ch.net/test/read.cgi/gamedev/1285057945/
・OGRE3D
　http://hibari.2ch.net/test/read.cgi/gamedev/1180869789/
・【UDK】Unreal Development kit ver.2【無料】
　http://hibari.2ch.net/test/read.cgi/gamedev/1269680499/
・【3Dゲームエンジン】Unity 2
　http://hibari.2ch.net/test/read.cgi/gamedev/1284742292/
・汎用ゲームエディター『Multimedia Fusion2』 7
　http://hibari.2ch.net/test/read.cgi/gamedev/1286354919/
・【2D】ゲーム作成ツールGameMaker part5【ﾏﾝｾｰ】
　http://hibari.2ch.net/test/read.cgi/gamedev/1291622881/
・【SB】Shooting Game Builder ver11【ｼｭｰﾃｨﾝｸﾞ】
　http://hibari.2ch.net/test/read.cgi/gamedev/1291426535/
・■吉里吉里／ＫＡＧ／ＴＪＳ雑談質問スレ■その22
　http://hibari.2ch.net/test/read.cgi/gamedev/1285897465/
・NScripter Ver.17.00
　http://hibari.2ch.net/test/read.cgi/gamedev/1275595048/
・【ウディタ】WOLF RPGエディター　其の22
　http://hibari.2ch.net/test/read.cgi/gamedev/1286476377/
・■　LiveMaker　スレッド5　■
　http://hibari.2ch.net/test/read.cgi/gamedev/1267224872/

5 ：

オススメのがあったら適宜付け加えてくれ

6 ：

>1
大義であった

7 ：

>>4　漏れたので追加
・XNA 質問・相談スレッド 2　　（＠ム板）
　http://hibari.2ch.net/test/read.cgi/tech/1286284415/
・DarkBASIC 使っている奴情報交換してください 2
　http://hibari.2ch.net/test/read.cgi/gamedev/1198971706/
　（C/C++で使えるDarkGDK。C#、VB.netで使えるDarkGDK.netも）
・【オープンソース】Construct【ゲーム作成ソフト】
　http://hibari.2ch.net/test/read.cgi/gamedev/1290156055/

■3Dエンジン、ゲームエンジン等のデータベース
　http://www.devmaster.net/engines/

8 ：

Wikipediaのゲームエンジンの頁。割と充実してる
http://ja.wikipedia.org/wiki/%E3%82%B2%E3%83%BC%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3
WikipediaのTemplate:美少女ゲーム系/doc/ゲームエンジン。美少女ゲーム系エンジンにカトゴライズされるAIMSェ…
http://ja.wikipedia.org/wiki/Template:%E7%BE%8E%E5%B0%91%E5%A5%B3%E3%82%B2%E3%83%BC%E3%83%A0%E7%B3%BB/doc/%E3%82%B2%E3%83%BC%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3

9 ：

gamedevwiki
http://wiki.game-develop.com/
後作ったゲームエンジン発表会Rゃらって話はどうなったんだろ。

10 ：

>>9
作る奴は作ってるし
ｽｸｼｮがあがり始める秋頃に詳細決めれば無問題
それ以前にこのスレが消滅する可能性もあるがｗ

11 ：

>>999(前スレ)
ライブラリとゲームエンジンを混同してないか？
どんなプラットフォームでも一応のことはできるライブラリ
が揃ってるもんだけど、それは問題にしてないよ。

12 ：

>>10
そうだね、またその頃になったらテンプレに加えたら良いか。

13 ：

前>>998
>うんまあそうなんだけど心情的には合ってるでしょ？
過去にお金がないから使いたいゲームエンジンが使えないという事情があったりして
例えばUnreal Engineとかを酸っぱい葡萄のように思ってたことはあったかな。心情的に

14 ：

>>12
うむ
言い出しっぺの一人として9月までにはα揚げるよ
3D版ウディタだから同人限定だけどね

15 ：

>>11
普通に開発ツールも含めたゲームエンジンの話だけど？
さっきからどんだけ狭い「ゲーム業界」を対象に話してるの？
まさかゲームエンジン∋個別のゲームシステムっていう視点で話してる？

16 ：

おまいらPCで作るんだろうけど3D関係とか基本的なのは
すでにDirectXとかあってこれ以上何が要るのって状況なのに
何作るつもりなのよ。

17 ：

>>15
ゲームエンジンがなかったらハード直叩きするしかないと思ってない？
今のハードってそれをやろうと思っても出来ない方向になってるんだけど。

18 ：

>>16
例えてみれば
やっと16色表現できるようになった程度だろ

19 ：

DirextXだったら参考書も色々あるしサンプルも豊富だし。
わざわざ独自エンジンで再構築したら不案内になるだろ。
作るとしたらそこじゃねえよな多分ｗ

20 ：

パブリッシャーが試作品（付きの企画）を募っては審査しては細かく手広く出資しては審査しては
この繰り返しで絞り込んで商品化、みたいなプロセスが主流の場合、吹けば飛ぶような新興の
デベロッパーが雲霞のごとく発生しては消滅を繰り返してるから人材の流動性が大きいんだよな
内製のエンジンだのライブラリだのツールだのノウハウだのの蓄積と継承が望めない短命豆粒ソフトハウス
だらけの（例えばアメリカのような）状況下で見栄えのするプレゼン用プロトタイプを短期間にサクサクと
作り捨てないといけない需要が旺盛となれば、それに応えてゲームエンジン市場が日本に先行して
育つのは必然かなぁ、とも思う
日本は零細でも比較的長命だし余程の底辺でもなければ内製のライブラリだのツールだのノウハウだのは
蓄積・継承されやすいから、サウンド系のミドルウェアとか一部を除けば買うまでも無いよ内製でどうにか
しちゃうよってパターンが成り立ちやすいよ。発注側からこれ使えって供与されれば使うし
シリコンスタジオのアルケミーとか

21 ：

×発注側からこれ使えって供与されれば使うし
○でも発注側からこのエンジン使えって供与されれば使うけど

22 ：

>>19
小規模な3DSTGや3Dアクションゲーを個人で作って同人で出したときはDirectX+自作だったな
今はいいものがあるのかな。UDKとかゴツいのは苦手だから自作のライブラリやツールは手放せん
前スレでも言われてたが紙芝居エロゲみたいにある種の様式美で型にはまったものなら既存の
吉里吉里とかNスクとか安定したものがあるからそれ使えばいいんだけどな

23 ：

>>20
いやー日本ほ昔からコンシューマ主流だから。
家庭用機って数年おきに新機種移行するから
一生懸命汎用的なもの作ってもすぐパアになるんだよ。
そういう土壌ではゲームエンジンみたいなのは育たんわな。
だから蓄積されるとしたら方法論とかだけど
それにしても人材が長持ちしないから失われたりするｗｗ

24 ：

レイヤーの下層、ターゲット依存部が作り直しになるのは不可避ってのは同感だよ
でも全部ASMで記述して頃に比べれば使いまわし可能な非依存部はずいぶん増えたと思うよ
型にはまったゲームばっか作ってるだけだからかもしれんがｗｗｗ
方法論についてはもちろん同意。人が辞めちゃうのも同意。。。
でも海外フォーラムでお話聞いてると日本よりももっと短周期で人が入れ替わるケースをたびたび耳にする

25 ：

あ、人が入れ替わるっていうか小さな会社がアボーンして散り散りになるってケースね
おそらく勤続年数の平均値とかとったら日本よりぐんと短いと思うよ

26 ：

なんかシンミリしてしまう話だな
お前らこれくらい熱くなれよ！
つttp://kirishima-live.jpn.org/

27 ：

>>23
スマン。なんか誤読してた。PCゲー主流時代があったアメリカとは事情が違うってのも同意。
あとあいつらほんとFPS大好きだよな。俺も好きだけどさｗｗｗｗ

28 ：

アメリカ人みたいにゲームのキャラとマップだけすげ変えて
違うゲームだぜヒャハー！ってぐらい割り切れればいいんだけどな。
日本人だとどうしても他と違うものを、他が真似できないものを
って考えちゃうから肌に合わん。

29 ：

>>28
トライエースが開発したとかいう国産エンジンもその一つ？

30 ：

洋ゲーだと古いPCで動かなくてもOKみたいなのがうらやましい。

31 ：

>アメリカ人みたいにゲームのキャラとマップだけすげ変えて
>違うゲームだぜヒャハー！ってぐらい割り切れればいいんだけどな。
駄目なゲームが山ほどあるのも事実だがそういうのは見向きもされてないけどな
ソッコーでsteamで$5とかで叩き売られても人気サッパリだったりするぞ
UE3使ってるタイトルでもキラリと光るやつは色々手を加えてる
見た目の差別化の話に限定するとBioShockは水流エフェクトのためにエンジニア雇ったり
かなり作りこんでいたしMirrors Edgeとかもライティングの処理は独自改良していた
（GIレンダラーでテクスチャにベイクしただけってわけじゃない）
既存エンジンで差別化できないから独自エンジンに手を出す、という動機が成り立ってるところは
上の例より更に要求水準が高いほんの一握りのトップランナー。資金も桁外れに潤沢なんだよ。
（例えばBioShockの続編、BioShock Infiniteは独自エンジンだが勿論BioShockが売れなければ無理だった）
>日本人だとどうしても他と違うものを、他が真似できないものを
>って考えちゃうから肌に合わん
「俺の肌に合わない、俺はフルスクラッチ（痒い表現だな）DA！！」とかの嗜好・恰好は
外販されてる既製ゲームエンジン採用可否の決定的な要素にはなってねーと思うよ
使わないケースは単純に「本当に必要ない」or「本当は使いたいけど先立つおぜぜがない」

32 ：

>>31
うーん、何か違うよなあ。
むしろ日本じゃ外部のエンジン使うほうが贅沢だと思うけどな。
なんでかっつうと和ゲーだと標準ライブラリ＋αで十分作れ
ちゃうんだよ。洋ゲーとは求めてるもの方向性が違うから
例えばFPS用のレベルエディタとかあっても余計なお世話だし
物理エンジンとかあってもそもそも無理に使う必要ないし。
それよりも使うと会社的に著作権１００％主張出来なくなるから上層部が
嫌う。使用料も移植とかリリースするたんびに払わなくちゃいけないから
いやな感じだし。だから出来るだけ自前で作ろうとする。

33 ：

日本のゲームって絵づら的にも写実的じゃない方向性だし
むしろシナリオとか萌えキャラとかに重きを置いて、システム
というよりは人手をかけてゲームを細かくコントロールして
いくことに美徳を求めるから他社製ゲームエンジンとか入れても
かえって阻害になるような感覚がある。

34 ：

>>33
まあ、ゲームエンジンを固定しまうと演出面とかでは限界が出てくるわな…。
そういう点が日本のゲーム向きではないのだろうね。

35 ：

>>34
しかしその結果がコスト増大に技術的な遅れになってるんだからしょーもないわ。

36 ：

>>35
コスト面は別にあんたが心配するこっちゃないだろｗ
そもそも採算が合わなければ自然に市場から淘汰されるだけだし、
そもそもゲームエンジンを使ってないからって、
使いまわせる部分が皆無で毎回1からコードをフルスクラッチしてるわけでもないんだし、
製作コストそんなに大きく変わんないと思うよ。
せいぜいデザイナーにやらせられるはずの仕事がプログラマに回ってくる程度の話だろう。
そんなのは単価の安い下っ端のプログラマがやればいいので、デザイナーより単価が高いわけでもあるまい。

37 ：

洋ゲーって
「ホラ、こんな素晴らしいゲームシステムを作ったぞ！さあ勝手に遊べや！」
って感じでユーザーを突き放すけど、そういうのって日本じゃウケねえ。
日本人はグルメだから美味しいものだけ集めて口元までもってって
やらないと食わない。だけどそれをやるには人手をかけて作りこみの
方向になるから金がかかると。

38 ：

エンジン安く買って、好きなだけ造り込め。以上。

39 ：

おお、スゲー伸びてる。
バン・ナムの人が監修して最近出た翻訳本の影響か。
翻訳にムラがあるが、確かにあの本イイよな。
「ちっ、また１から作り直しかｗ」ってなっちまうよｗ

40 ：

>>38
日本のゲームって微にいり細にわたって作りこまれてて一見高度
なようだけど、あれって裏を返すとイレギュラーな処理のオンパレード
ってことで中身ゴチャゴチャなんだよな。それに対してシステム化
というのは色々な切り口があるものに対して「この方向でいきましょう」
ってバッサリやっちゃうから逆に不自由になって日本人的な
作りこみができなくなる。

41 ：

エルシャダイdisってんじゃねーぞ

42 ：

続編や焼き直しゲーばっか売ってる日本人。
ゲームを面白さではなく技術で語る。
肝心のゲーム部分を作れないプログラマ主導の、プログラマに依存した体質。
職人指向と言えば聞こえがいいが、機材の限界を追求することに固執してゲームデザインが見えてない。

43 ：

ゲームエンジンは元々MOD文化から生まれたものだからな。
リソース差し替えガラっと絵ヅラ変えて新ゲームでござい
ってのが基本なのでエンジン使うほうが似たりよったりの
ゲームになりやすい（笑

44 ：

似たり寄ったりのクソゲーを作るのが外人
多種多様なクソゲーを作るのが日本人ってことか

45 ：

>>42
>肝心のゲーム部分を作れないプログラマ主導の、プログラマに依存した体質。
ゲーム部分が作れないというか、企画がゲーム部分をまともに考えられないから
プログラマが文句言いながら無難に作ってるだけだよなｗ

46 ：

お前らそんなに自己分析出来てんだったら洋ゲーに押されてんじゃねぇ

47 ：

＞＞３９
だから早くゲームエンジンアーキテクチャーのパクリエンジン創ろうず

48 ：

とっくに作ってるよ

49 ：

>>39
＞「ちっ、また１から作り直しかｗ」ってなっちまうよｗ
なるなるｗ
新しいことを知るたびにちゃぶ台返ししたくなるｗ
まぁ、作る度によくなってる実感があるから楽しいんだけどね。

50 ：

趣味で作る自分のためのRーエンジンと割り切るならそれもアリだが
もしも公開して人に使ってもらって好評を得たいと考えてるならそのループはやばいぜ
他人の評価がない自己完結型のスクラップアンドビルドの反復は効率が悪いからな

51 ：

他人の評価が望めない場合は、とにかく繰り返し実戦投入（ゲームを完成させる）
自己完結型ならバトルプルーフこそが最良の道だと思うぜ。あとYAGNIの心得も

52 ：

>>49
ちゃぶ台返したくなるってことは、それだけいろんな考え方が
あるってことだからね。そういうことに対してエンジンみたいに
固定化しちゃうと使う人と感覚がかみ合わないから
「ダッセー！こんなん要らんわ（プ」
とか言われて使われないのがオチだったりする。
だから作るとしたらよほど普遍的なものに限定されるけど
そういうのって大抵ライブラリで供給されてて、じゃあエンジン
って何よ？要らねえじゃん！ってことになってしまう。

53 ：

>>42
隣の芝生はーだなそれは
むしろ海外こそ続編や焼き直しばかりだぞ

54 ：

>>42は国内大手が海外の大手と契約して販売権とってきて
タイトル選りすぐって完全日本語化して大々的に広告をうって
国内販売してるコンシューマ機の洋ゲーしか知らないんじゃないかな
それらが洋ゲーの中のほんの一部の極上品ということも
steamとかで二束三文で売られてる金太郎飴FPSの山を眺めれば
彼らがかなーり保守的で偏食漢の客相手に手堅く商売してるとわかるはず
デベロッパ：とりあえずFPSにしとけば採用してもらいやすいかな？かな？
パブリッシャ：とりあえずFPSなら最低でもこれくらいは売れるかな？かな？
（投資家：とりあえずFPSなら最悪でも投資は回収できるかな？かな？）
彼らもリスクヘッジに余念はないよ
そんなわけでどの洋ゲームエンジンもFPSの作りやすさを前面に押し出して
そこに特化した高レベルの各種モジュールやツールを最優先に入れてくる
使おうと使うまいとそこの分の開発費や維持費はライセンス価格にばっちり
反映されるから日本では「これ高ぇえよ…」となるケースが多いのも頷ける

55 ：

>金太郎飴FPSの山を眺めれば
広告見てるだけでもゲップ出るよなｗｗ
日本はあそこまで露骨じゃないからまだマシだろう。

56 ：

金太郎飴FPSとはうまいことと言うなｗｗｗ
お前ら、ろくにプログラムも書けないド低能のくせに、
悪口だけは天才的だな

57 ：

あんまり興味無いから最近は見てないけどたしか、
�@兵隊さん、�Aスパイ、�B忍者、�C緑色の巨人、・・・etc
基本システム皆同じで一斉発売。
さあ好きなの買えや！って感じだろ。
ゲームエンジン地獄ｗｗｗ

58 ：

>>54
金太郎飴になることはむしろ利点ではあると思うけどね。
それだけ簡単にそれなりのクオリティの物が作れちゃうわけだから。
プログラマーいなくてもジャンル固定でも
十分いいものが簡単に作れるってのは大きいんじゃないかね？

59 ：

>>58
>>2

60 ：

FPSでも美少女キャラクターに変えるだけでも結構売れると思うけどなあ

61 ：

ユーザー層がそんなかぶってないんじゃね？

62 ：

>>58
娯楽の画一化は消費者を飽きさせる。
楽しませることがゲームの価値であるならば
「似たようなの一杯→飽きる→体感的な質の低下」
ということになるだろう。

63 ：

>>62
消費することだけが娯楽じゃないよ。生産するのも娯楽だよ。
生産と消費を両立している人を生産消費者（Prosumer）って呼んでるけど、
この人たちがより多く生産して消費できる仕組みとして
いずれはコンテンツの質以上にツールの質も問われる時代が来るんじゃないかな？
生産する仕組みが未発達であればコンテンツが溢れて飽きることには同意だけど。

64 ：

>>63
作る系のゲームは日本じゃあんまり流行らないよなあ。
ネットなど一部ではすげえ人気でも売り上げみるとショボいし。
作るほうもあんまりユーザーに作られると仕事なくなるから
あんまり本気出してないのかもしんないけどさｗ
・・・まあ、その方向はあんまり期待しないほうがいいよ。
漫画と同じでどんどん新しいの買ってもらわないと困る業界
なんだしさ。ユーザーもあんまり面倒臭いのは期待してないし。
相手は難易度高いだけでもブーブー言って糞ゲー呼ばわりする連中だぞ？
寝転んで口あけてれば美味しいもの口に入れてくれるような
のがいいんだよ。方向性としては。

65 ：

あんまり他社のエンジン使ったり外部の技術に依存しちゃうと
足元見られるからね。結果、技術あるところは肥え太って
無いところはますます苦しくなって格差拡大、面白くない
ことになる。

66 ：

MMDとか見ると、TPSのキャラクターだけ手軽に取り替えられると流行ると思う。
Webで見られないと無理か？　Flash PlayerみたくMMD Playerとか作れば絶対はやる。

67 ：

>>64
>>2

68 ：

>>64
最近だとMineCraftってゲームが流行ったらしいよ。
レゴみたいな画面で自由度が高いらしい。

69 ：

　ゲームエンジン切り出しって言うのは、抽象化の一環なんじゃないかな。
　むしろゲームエンジン作るっていうのは、再利用のためというよりも
デバッグ効率のためなんじゃないかと思う。
　問題となる処理を必要最低限の要素に還元して、似た者同士グループ化して、
単純明快な利用ルールで呼び出せるようにする。
　このような構造を目指さないと、デバッグが大変そうで心配になるんだが。
　生産物の規模によるだろうけど。

70 ：

>>64
流行るかどうかは提供の仕方によるかな。
従来通り、RPGツクールみたいな形で完全に投げるのはアウトだと思う。
ゲームを作ること自体をSNS化するみたいな、
コミュニケーションや遊びの目的をゲーム制作に求められるようになれば、
なんとか流行の風が吹くかもしれない。
ニコゲーはそういう狙いもあって、作品数が9000点と伸び続けてるみたいだけど。
少なくともアンチはいつでもどこでもいるから仕方ない。
ニコ動みたいにアンチをあまり意識しなくて済むシステムが必要かも。
>>66
Webは必須じゃないんじゃない？
ブラウザで見れるのは魅力的だけどね。
WebGLと通信インフラの普及の仕方で変わってくるかも。

71 ：

>>2
新参は誰が神奈川産キチガイか知らないってこともあるから
もっとはっきり書いたほうが良いと思う
・◆GRGSIBERIAの書き込み禁止
・◆GRGSIBERIAへのレス禁止
これくらいはっきりと。

72 ：

ばかばかしい。アホの口車に乗って何がしたいのか。

73 ：

>>70
ゲーム作るSNSって国内でも既にいくつかあるよ
流行ってないみたいだけど…
mixiかニコ動あたりでもそんな感じのやってた気がする

74 ：

ああよく見てなかったすまん
最初からスレ見てるのに誰が基地外かしらんかった…

75 ：

>>74
前スレ読めるなら、このコテハンの書き込み確認してみなよ。
こいつはとんでもない基地外だから。

76 ：

ブログとか読むとなかなか良い発想を持っているのだが
如何せんスキルが全然足りない

77 ：

ツクールはツクールでユーザ主導のコミュニティで発表するようになってる。
ウディタは公式サイトに発表の場がある。
SNS化が必要かどうかはさておき、遊んでもらう相手を探す場は必要。
エンジンにしても、アップローダかリンク登録の仕組みを一つ用意しておくといいかも。
ただ、人が居なくて無反応だと意味ないから難しい。

78 ：

もし売れ筋がはっきり分かってるのであれば金太郎飴上等で低コストで作りまくれば良い。
今までにない面白いものを作ることが目的ではなく、売れることが重要だから。
「ドラクエ」や「ＦＦ」という名前だけでゲームを買うユーザがいるように。
そのためのエンジンを目指すのは悪いことじゃない。

79 ：

何の話かよくわからんが、スレに投下するだけじゃだめなのか
ゲームでもツールでも、良いものは勝手に広まってくもんだよ

80 ：

難しく考えることはない。ゲームを１本つくればそれがゲームエンジン。
グラフィックや設定ファイルを生のままフォルダに入れておけ。
あとはそれらを改変するだけ。

81 ：

>>80
正論だね
サンプルゲームみたいなものかな
CrysisもCryENGINEのサンプルゲームだったし

82 ：

いいねそれ
難しく考えてた

83 ：

コンシューマでも実際その考えで１本完成すると結果論的に
ゲームエンジがあることにされてしまうのだが、エンジンあるから
予算減・想定されてない新要素追加で大手術→炎上という
お決まりのコースがあったりする。まあ余談だがｗｗ

84 ：

業務系でも、前回のプロジェクトの資産を有効活用って
なかなか出来なかったなあ。

85 ：

>>73
ニコゲーの理念とちょっと似てるかな。
制作は何人でやっても最終的に個人作業だけど、
あえてそれを集団でやろう的な。文化祭のノリ。
>>76
まあ、スキルはないかな。
ただ僕はいろんな方面から突っ込まれるぐらい中途半端なスキルはたくさん持ってるつもり。
>>77
FX Composerみたいなエディタと投稿サイトがリンクしてるのはいいよね。
作ったものをすぐに投稿できるし、欲しい物は検索すればだいたい出てくる。
投稿者個人のページがあったりするとブランドが根付いていいかも。Pixivみたいな。

86 ：

>>85
お前みたいな基地外は出てこなくていいよ
だいたいお前のブログなんかツッコミ以前に
独りよがりで自分にしかわからない書き方してある
チラシの裏みたいな糞記事ばっかりじゃん
小学生の作文以下だよ
Fラン大学以前の問題だろ

87 ：

>>85
http://blogs.yahoo.co.jp/nanashi_hippie/51851090.html
だいたいな、↑この記事にしても、もっと何がやりたいのか明確にして、
何が問題になっているのか、自分はなぜそれを解決できないのかを
きちんと説明すれば誰かが教えてくれるだろうに。
お前はC++のtemplateすらきちんと理解していないド素人レベルなんだから
まともなC++プログラマなら誰でもお前の悩む程度の問題には答えられる。
そういう答えを引き出せないのは、独りよがりのRー作文しかお前が出来てないからだ。

88 ：

>>85-87
総合発表＆雑談スレッド その3
http://hibari.2ch.net/test/read.cgi/gamedev/1216633635/
>>85には悪いが趣旨に反してなくてもレスしたら荒れるんだからトリップ外せ。

89 ：

>>88
このコテは最初から荒らすつもりでやってんだから外すわけ無いだろ
トリップを連鎖あぼーんしろ
http://www.vipss.net/haruhi/1236690020.html
http://mimizun.com/log/2ch/compose/1153020376/
http://mimizun.com/log/2ch/tubo/1135592029/

90 ：

>>89
そのスレ見たが、本当に気持ち悪いな、こいつ。
マジで吐き気がした。
いまもレスがついてほくそ笑んでやがるんだろうな。
とっとと肺に穴あけてRばいいのに。

91 ：

ID:BaySpCb4の書き込みみても吐き気がするよ。
お前、>>85のコテハンを叩く書き込みしかしてないじゃねーか。

92 ：

>>91
いいから、このスレの前スレと、>>89のスレ見てみろって。

93 ：

>>92
>>91はどう見てもアイツの自演だろ、触るな

94 ：

>>93
本当だ・・・こいつ、>>91に書き込みする直前にtweetしてやがるｗｗｗ
こいつ本当に、わかりやすいなｗｗｗ

95 ：

たしかに、いつも欠かさずセットで書き込みがあるし、
文章の構成なんかに統一性があるな。

96 ：

お前らスレタイも読めないんだったら同レベルだわ。
これ以上は雑談スレでコテハン野郎でも語ってろ

97 ：

もう呆れ果てるな。

98 ：

とりあえず神待ちしかできねーしｗｗｗｗｗ

99 ：

どうせ神待ちなんだから雑談でいいじゃん

100 ：

ゲームエンジンの雑談なら良いけどキチガイを叩くスレではない

101 ：

お前ら、Fラン、Fランって馬鹿にするけど、いくらFランでも
みんながみんな、えいいちみたいに馬鹿じゃないからな。
えいいちは、AO入試組なんだよ。筆記試験が無かったわけ。
学力が中学生並なのはそのため。
えいいちみたいな池沼が入ってくるから、
AOでも筆記試験を課すべきだといま教授会で問題になっている。

102 ：

おいでませー　おいでませー

103 ：

有志の方、一緒にフクロマンス継中を作りませんか？
全て私が独裁するので難しいコトは考えなくて構いません。　by監督
目的：実売１以上　新カナの普及　スパさんの有名人化助力　俺のヒマ潰し
期間：年内

（＾笑＾）サスペンスギャルゲー『フクロマンス』
http://namidame.2ch.net/test/read.cgi/mitemite/1251928765/

104 ：

>>103
カス野郎ギャラよこしやがれ！

105 ：

誰かTorque使ってる人いる？

106 ：

今安いよね
ソースコード付きで99ドルとか

107 ：

Garage Games こんなこと書かれてるけど経営大丈夫なんだろうか
http://www.4gamer.net/games/036/G003691/20101115020/

108 ：

急に過疎ったなw

109 ：

>>107
その記事古いよ
先月復活してiPhone版3Dエンジン切り捨て、価格大幅値下げで新規スタート
http://www.garagegames.com/community/blogs/view/20775

110 ：

フルソースなら買ってみようかな

111 ：

そうそうソース付きで安いし、それなりの歴史があるからいいんじゃないかと思って。
ソース読んで勉強もできるかもしれないし。

112 ：

iPhoneにも手を出そうとして予算不足で経営不振になっただけで、
エンジン自体はUnrealやCryEngineをも押しのけてGame Developer Magazine誌の2008年エンジン部門大賞を取ったレベルだからな
Unityなんて今更9.0cレベルのソフトシャドウを使うために1500ドルでソース無しのPro購入必須だしアホらしい

113 ：

ぼくは子どもの頃から素直で物覚えが良くて頭が悪く、まで読んだ

114 ：

Torqueはインディーズ向けと謳ってるがエンジン部分のソースコードのサイズは14MB。
けっこうデカい。ソースコード付きなのはマニュアルが不親切だからってのもある
基本的なスタンスは「ソース渡すからあとはお前ら勝手に解読して使えよ」って感じ。
で、使いやすいライセンス形態のオープンソースのエンジン（例えばIrrlichtとか）に比べると
WEB上の情報量はかなり少ない。購入するならその辺も留意のこと

115 ：

ちなみにIrrlichtのソースコードは6MB。初心者が解読してお勉強するにはこれでも
相当なボリュームだが、Torqueに比べればマニュアルの充実度は天地の差だし
付属のチュートリアルも良い。歴史が長い使ってるやつも多いWEB上の解説も豊富
日本人で使ってるやつらの解説ページもある
初心者の場合、洋モノに手を出すってだけで辛いものがあるのにそれに加えて
有料だわ情報量少ないわマニュアル糞でソースがデブのTorqueは正直やばい

116 ：

重要な情報乙！

117 ：

Torqueをけなすだけじゃフェアじゃないので褒めるところは褒めておくよ
大概の洋モノ・図体でかいゲームエンジンの例に漏れず、Torqueもスクリプト組んで
サクサクっとFPSを作りたい人に特化してる。例えばSDK付属のサンプルはFPSだけ。
C/C++で記述する部分はほとんどない。ゲームエンジン呼び出して終わり。
ミッションエディタっつーレベルエディタで作ったデータを読み込んではい動きましたー
ボットのAIや典型的なイベントは雛形スクリプトをちょちょっと改造して出来上がりー
みたいな。かなり便利。MAXやMAYA用のエクスポータとかも付いてる
FPS以外のゲームを作りたいやつはソースを解読したり改造することになるが
上記した付属マニュアルが糞とか情報が少ないってのが災いして超大変。
そこで追加パッケージを有料で買う。例えばゼルダやマリオっぽいゲームを
FPSを作る時と同様にサクサク作りたいなら$299の3D Action Adventure Kit買え
カネで解決できる奴はTorqueは悪くない
ならDarkBasicのほうがよぐねーが？って声が聞こえるが。うんそのとおりだぞ

118 ：

IrrlichtもシーンエディタがTorqueより高くなってて微妙じゃね？
サンプルつってもまともなゲームの例はTorqueより少ないしさ

119 ：

あっ、うん。。。
なんとなく>>110-111を見て、本格的なゲームエンジンのソースを読んでお勉強
という用途としてはIrrlichtのほうがまだとっつきやすいかなーと思ってさ
そういう用途で他にいいものがあったらスマネ

120 ：

IrrlichtのシーンエディタってCopperCubeだよね。
Maximal amount of scenes per documentが
Light(99ユーロ)だと10、Pro(299ユーロ)だと制限なしなんだけど、
これってどうなんだろう。

121 ：

よく知らんけどirrEditじゃあかんの？

122 ：

irrEditもCopperCubeもだけどライトマップ生成がシングルスレッド動作だから
i7とかXeon使ってても非常に遅かったりする。Hammerとか他のエディタ使って
作ったデータを引っ張ってくるほうがいいと思うお

123 ：

結局
海外のエンジン頼みかよ
レベル低すぎだな日本人はｗ

124 ：

日本の技術じゃツクールシリーズが限度だな。

125 ：

車輪の再発明なんかしても意味ないだけだろ。

126 ：

日本に技術がないのは事実だけどな
技術がないなら最初は外国のを真似て勉強するしかないだろう

127 ：

んでも判子ゲー作る需要がねぇから猿真似できてもなんにもつかえねぇよ

128 ：

>>125
新発明もできないじゃん。

129 ：

車輪だって発明当時のままじゃないしなｗ

130 ：

何も発明できないやつの言い訳「車輪の再発明」

131 ：

まあ、このスレでは車輪すら出来てないけどな。

132 ：

偉そうに言ってる連中も作れないけどな。
しかも海外製のゲームエンジンを使うことも出来ない。

133 ：

さすがに使うのはガキでもできる

134 ：

英語すら読めない低レベルばっかってことだろ

135 ：

煽ってないで勉強しろってことだ

136 ：

文句があるなら作ってから言えよ
ところで何かゲームが作りたいのだが、スーパマリオでいいか？

137 ：

>>136
趣味でやるには意外と難易度高いぞ

138 ：

>>136
せめてタクティクス・オウガにしてくれ

139 ：

>>136
会社の３Dエンジン作ったよ。

140 ：

>>139
そのエンジンの特長をご教授願います

141 ：

>>140
http://preview.canstockphoto.com/canstock4178508.png

142 ：

チープなCGでござる

143 ：

ああｗｗｗｗｗｗ
3Dのエンジンか…5時間前に見たネタを今理解した

144 ：

金太郎アメだの判子ゲーだの言うけどよ、
日本でも大概どっかで見たようなゲームしかリリースされてきてないじゃん。
中には「これ新しいな♪」ってのもあるが、
『ゼビウス』でさえ『スクランブル』のアイデアがベースになっているって話じゃないか。
斬新な要素なんて、微々たるもんだよな。

145 ：

>>144
そりゃ大枠でみるとそうなんだけど
エンジンで吸収できるほど似てるかっていうとできないんだよね
アメ公のＦＰＳはエンジンで吸収できてしまう程度（それだってかなりめちゃくちゃになると思う）
あんまりエンジンに夢を見るのもどうかと
この「○○エンジン使って開発しました！」ってのも開発ネタ的にはいいウリになるけど
使う側の苦労ってのはあんまり知らされないじゃん？
そこんとこ見えないままあんまりエンジンエンジン叫んでもね
俺もエンジン（他の会社の）使った経験あるけど
ちょっとしたことしようとするだけでカスタマイズしてもらったり
かなりエンジン提供者側の担当者とやりとりしたよそのままで使えるもんじゃないし
できることはドキュメントに書いてあるけどできないことは書いてないからねぇ

146 ：

>>145
頭が固いね

147 ：

エンジン使用不使用を問わず糞ゲーを乱発してる和ゲーの自称開発者が
エンジンなんて使えないとか言っても説得力が無さすぎるわ
洋ゲー以上に既製エンジン使いこなした作品を出してから言えよ

148 ：

■e ＜ UE3でRPGつくってみました！

149 ：

プログラムを作るという行為は決まりごとや法則を
与えていく行為にほかならない。故に多大な労力をかけ
高度にくみ上げられたプログラムは決まりごとでガチガチ
に拘束されており、色々な用途に再利用できる可能性は極めて
少ないのであった・・・

150 ：

例えば車でいうとホンダあたりがアメ車ひっぱってきて
「これから我が社の製品はこの車を改造して造る」
とか言うようなもんだろ。そして
燃費が悪い→エンジン改造
大きすぎる→ボディ・シャーシ改造
内装がダサい→内装全交換
小回りがきかない→タイヤ交換
跡形ものこらんわｗｗ

151 ：

>>150
燃費が悪いのは重すぎるだけだし、
ボディやシャーシ改造したら全取り換えだし、
小回り悪かったら4WDにすればいいし。
喩えが悪い。

152 ：

>>149
頭が固いね

153 ：

ま、このスレの過疎り具合をみれば誰も興味ないのは一目瞭然ってとこか

154 ：

>>145
商用ゲーム作るならソースコード込みのライセンス買うでしょ普通。
エンジンなんて自分でガンガン改造して使うもの。

155 ：

改造するのはいいんだけど、所詮他人が作ったコードだから
理解度がどうしても低くなる。当然いじってトラブる確率も高い。
その点エンジン供給元のメーカーは理解度が高いので
十分使いこなしたゲームを作る。売上の一極集中が顕著な
ゲーム業界で、同じ土俵かつ供給元以上のゲームが作れない
ということは即ち、売れない上に高額なライセンス料まで取られるということ。

156 ：

みんな？

157 ：

みんな進んでる？
自分元気無くなって休んでる

158 ：

俺もちょっと休憩中。
イベントの送付はできるようになった。
グラフィック付けるのがめんどくせ。
Androidが楽しくてそれどころじゃない

159 ：

Androidって楽しいの？
どんなことしてる？

160 ：

DSLに作ったゲームをソース付きで登録してきた
審査通ったらみんな買ってね

161 ：

>>159
Androidで３Dぐりぐり表示する。
とりあえずコンパイル通るところまではやってみた。
OpenGLとOpenGL ESの違いさえ吸収すれば
そのまま動きそう。

162 ：

>>160
おお、すごいね。
完成させることって大事だよね。
>>161
おお、おもしろそうだな･･･
Direct3Dしかやったことないけど、OpenGLもやってみようかな。

163 ：

OpenGL4.1ならES2.0互換でしょ？

164 ：

>>157
予定通り9月までにβ仕上げられそうだよ
3Ｄ版のウディタもどきだけどね

165 ：

>>160
おー、ソース参考にしたい
ところでDSLって何？

166 ：

>>165
ＤＬＳだったｗ

167 ：

間違い指摘するつもりじゃなかったw
gamedlsってやつかな？
新参で略語についていけない・・・

168 ：

>>167
もっといかがわしいところ
http://soft.dlsite.com/
ちなみにまだ申請R
金額も高く設定しちゃったぜ・・・

169 ：

>>168
あ、ここかw
ありがとう

170 ：

体験版プレイして、よさげだったら俺も買うよ。

171 ：

自分で言うのもなんだけど完全に初心者向けな上ゲーム自体は超つまんねー
おもしろくしようとする気もおきないほど作ること自体に時間がかかってしまいかつ面倒臭かった
会社でやるのとは違うわ

172 ：

そらまあ一人でやると大変だよな。
俺も昔簡単なゲームつくろうと思い立って
なんとなく「これくらいなら１週間ぐらいで作れるぜヒャハー！」
とか思ってたら、やってみると「ああこの素材どうしよう」とか
「あ、ここんとこツールみたいなの要るじゃん」とか
色々出てきて結局３週間ぐらいかかったのを思い出したわｗ

173 ：

>>164
じゃあ自分も９月までにβ目指す
がんばろー

174 ：

>>160です！
審査が通ってとうとう出たぞ！
http://home.dlsite.com/work/=/product_id/RJ074526.html
ゲームはオススメできないが
３Ｄゲームをチュートリアルどおりに作れるはじめての入門書になると思う
金に余裕があったら買ってみてくれ
タスクシステムも使ってない
変な組み方やグローバル変数も一切使ってない正直な組み方にしてみた
とか、２ｃｈで宣伝してみる・・・

175 ：

170だけど高いよｗ
1000円ぐらいなら義理で買おうかと思ったけど、3000円とはｗ
それに入門書なら体験版に目次のようなものも入れておいたほうがいいんじゃない？

176 ：

入門書の体験版に入門書が1ページも入ってないってどういうことなの
このスレってやっぱ基地外しか居ないじゃねーか

177 ：

>>175
やっぱ高い？ｗ
別にいくらでもいいんだけど
１０００円や２０００円だとやらない気がするんだよね
３０００円ぐれーなら折角だからやろうかな？とか無駄に狙ってみた
>>176
一応サンプル画像に入れといたけどね

178 ：

>>174
へぇ〜、こういうカタチでの出品ってあるんだな。
けっこうおもしろそうだね。

179 ：

>>178
この形の出品はきっと俺が初に違いないｗ
これからみんなこういう形の公開が増えるといいなぁ
ページ作ったものの放置してDirectXのバージョンが上がっても
誰も引き継がないってＨＰ多いしね
だったら金とってでもちゃんとサポートしろよって俺の魂の叫びでもある

180 ：

身をもって主張したのねｗ
熱いねぇ。

181 ：

>>175
>それに入門書なら体験版に目次のようなものも入れておいたほうがいいんじゃない？
おお、なるほど
ありがとう
参考にしてみる

182 ：

>>179
本当にサポートできるだけの実力あるの？ｗ
いや、疑うわけじゃ無いけどさｗ
そこまで言って金をとるからには、相当の覚悟が必要だぜ？
しかも安くない価格だしｗ

183 ：

>>182
そこはやってみないとなんとも
こっちでは動いてるけどそっちじゃ動かないって状態が一番怖いな
そんなに環境もそろってるわけじゃないんだな
まあ、動きさえすれば後はソースがあるからって感じ
難しいことしてないしね
でも数学一切わかんないって人にはどう説明したもんかなぁ・・・
入門書なんだしここ一番重要だけどなんの対策もないなｗ
実は使ってる数学関連のコードに対してはなんの図解もしてないｗ
でもこんなの書いてたらそれだけで一冊できるよね・・・
あくまで組み方だけに着目したものということでｗ

184 ：

>>183
ボーンアニメーションは解説してる？
画像見る限りテクスチャやシェーダは皆無のようだけど。
影も今時丸影って・・・真っ黒だしw

185 ：

>>184
してない
はじめは入れる予定だったんだけど
それだけであんまり巨大になっちゃうもんだから入れるの止めた

186 ：

>>174
審査とおるの早い！
高くて手が出なかったけどw
ソース目当てで買う人はいそう
売り上げとかが気になるw

187 ：

>>174
有言実行おめ！

188 ：

せめて目次ぐらい載せておきなさいよ。
これで売れたら逆に驚くわ。

189 ：

1000円なら買うわ

190 ：

>>185
ビルボードやパーティクルは？
さすがにアルファブレンディングは解説してるよね・・・？

191 ：

お前らあんまりイジメてやるなよw

192 ：

>>188
上でも指摘されたから目次は入れてみた
それと高いっていうから３００円下げてみたｗ
あーでも初っ端って多分その通り打っても動かないとか
わけわかんないとか不具合多いよな
はじめは安く売ったほうがいいのかなぁ・・・
ちなみに変更申請して反映されるまでだいたい半日〜１日って感じ？

193 ：

>>190
描画機能もほとんどしてないな
注釈レベルで入れた覚えはある
でもよくあるDirectXの入門書に大抵載ってる内容だから入れる必要ないんじゃないかなぁと

194 ：

Refｌectorで体験版のソース読んだけど、この品質のコードの解説で3000円とか流石に夢見すぎだろ…
うっかり買っちゃった人が不憫すぎる、Blogとかで公開してアフィで稼いだ方がいいんじゃないの

195 ：

プログラム系でアフィは儲からんぞ

196 ：

>>194
余計な機能一切使ってないからな
タスクシステムやグローバル変数も一切無いっしょ？
タスクシステムスレにいたタスクシステム以外でどうやって組むの？って奴等にも見てほしいぜ

197 ：

それって拡張が難しいっていうだけじゃｗ

198 ：

悦に入ってるところを申し訳ないんだけど、見せても鼻で笑われるだけだと思う
タスク云々以前のレベルで
別に煽りたいわけじゃないんだけど、
これを読んで何か得られるものがあると思って書いているならある意味すげえって思った

199 ：

>>197
うーん
その辺は「ね？こう組んだほうが追加とか楽でしょ？」って感じで
チュートリアル形式で進めてあるんだｗ
俺はこっちのが楽だと思うんだよね
無駄にまとめようとして失敗してるソースはよくみるんだけど
こうやって素直に組んだソースがいままで出たことなかったので俺がやってみた

200 ：

>>198
それは相当レベル高い人から見た意見じゃないの？
初心者なら、なんらかの参考になるんでは
ところで、これってC#からDirectXにどうやってアクセスしてるの？
XNA？

201 ：

>>198
やってみるとわかるんだけど
俺のソースをトリッキーなコード使って圧縮しようとしても大して恩恵受けないっしょ？
まあ、見た目短くはなるんだけどはじめはそれを技術だと思っちゃうんだよね
そうではなくて書かなくてはいけない処理と
書かなくていい処理をしっかりと分けられるのがちゃんとした技術だと思うんだ
なんかネットまわるとよく落ちてるソースがタスクシステムまみれだから
ちゃんと組もうよってのも俺が言いたかったこと
うーん、チュートリアルやってほしいなぁ・・・（笑）
ってもう組めるやつはタスクシステム未使用もグローバル変数未使用もあんまり興味ないかｗ
>>200
managedとかいうヤツ

202 ：

Managed DirectXかｗ
もう開発終了したライブラリを使うのはどうなんだという気がしないでもない

203 ：

まじめに売るつもりなら２ｃｈで晒すのはやめておいた方がいいと思うよ。

204 ：

>>202
そこはあんまりこだわってなかったから
C#から一番楽に3Dと音が使える方法でという感じでテキトーに決まったｗ
>>203
でもちょっとやると大体ここに行き着くからなぁｗ

205 ：

なんでタスクシステムが悪いみたいな前提になってるんだ・・・？
あれほどシンプルで分かりやすい仕組みもなかろうよ。

206 ：

シンプルなものを作るには、分かりやすいかもな。
「タスクシステム万能！」と言う人がいた時代があるから、嫌われてるだけだと。

207 ：

>>205-206
絶対そんなことねぇってことを伝えたい

208 ：

実行しただけでもほめてあげるべきだと思うよ。
低レベルだって言ってる人は、ビジネスチャンスだぞ。
もっといいものを安く売ってくれたら買ってあげるよ。

209 ：

確かにタスクに相当する物を
一切使ってないってのは気になるね。
まぁ買う金はないんだけど。

210 ：

オブジェクト指向言語なら、タスクシステムじゃなくてStrategyパターンを使うのが
普通じゃないのかな。

211 ：

自分もタスクシステムってしっくりこない。
それも一つの方法とは認識してるけど、各種パターンを通じてオブジェクト指向を学んだ後では、
特に重要とも思わないし、ムリに使う必要もないと感じた。
実際タスクシステムをまったく意識せずとも普通に動くゲームが作れた。
似てるところはもちろんあるだろうけど、「タスクシステム」という意識はまったくなかった。

212 ：

・・・まあオブジェクト志向がゲーム開発にあんまり向かない
ってのはあるな。ゲームって開発途中の気分で基本概念が
コロコロ変わったりするからクラスみたいなプロパティ
とメソッドの集合管理単位をむやみに作っちゃうと後々
組み換えが非常に困難になったりするという。

213 ：

>>211
最初のゲームはタスクシステムにあたるものがなかった。
しかし、ゲームがだんだん複雑化してくると、それをより簡単に管理する必要が生まれて、
タスクシステムが考案された。
つまり、タスクシステムを用いずにゲームが作れても当たり前。そちらのほうが原始的なんだよ。
現代におけるタスクシステムは、すでにオブジェクトマネージャだろ。
タスクブロックをオブジェクトという言葉に置き換えれば、何も違和感がないと思うが…
>>210
ストラテジーパターンをオブジェクトの振る舞いの設計に使うとしても、タスクシステムは単に
そのオブジェクトを登録し管理するマネージャにあたるものだから、比較するようなものではないよ。

214 ：

タスクを使うと良くも悪くも分散監理になっちゃうから
かえってゴチャゴチャになる危険性もある。

215 ：

あー・・・やっぱり始まったか。
それぞれの俺様定義で話が始まるのが「タスクシステム」のマズいところだよね。
> タスクブロックをオブジェクトという言葉に置き換えれば、何も違和感がないと思うが…
だったらはじめっから、より一般的な「オブジェクト」のほうを使えばいいのに。

216 ：

どっちにしろ>>174は詐欺レベル。
100円でも高いくらい。

217 ：

まあ内容はともかく、行動するのはいい事だな
本人にとっても他人にとっても

218 ：

>>217
それは本人が言う事じゃない。

219 ：

３０００円とかワロタ
こんなクソコード無料だろｗｗｗ

220 ：

いや、俺>>174はこっち

221 ：

>>174
買ったやつの情弱っぷりにも笑うがなｗｗｗ

222 ：

>>221
チュートリアル形式でゲームが作れる入門書はおそらく業界初！・・・がウリｗ

223 ：

行動を起こしただけでも大したものだよ
口ばっか達者な奴らばかりだからなここはｗ

224 ：

うん、行動したことを評価したい。
新しい提示方法を示したことはコード内容云々以上に大きいと思う。
これで周囲が奮起するんであれば、それこそ最大の成果だよ。
自分もがんばろうと思ったぜ。

225 ：

100歩譲って頑張った事は認めても、このコードのどこがゲームエンジンなんだよ…
ドヤ顔で書かれた解説書とやらもある意味読んでみたいけど、
中身の確認も出来ずに金を出すのは嫌過ぎる

226 ：

優秀な結果を出したなら褒めてやるが
行動起こすだけなら池沼にもできるからなｗｗｗ

227 ：

>>223
>>224
本人乙

228 ：

まともな人間ならこれを晒そうとか、あまつさえ金取ろうとか考えられないのは確定的に明らかだが流石に池沼は言いすぎ

229 ：

別に新しくもなんともないけど？ゲームの作り方を謳った情報商材と何が違うの？

230 ：

彼がここまで叩かれてる理由を一つ

231 ：

ゲームエンジンじゃない

232 ：

http://ex14.vip2ch.com/test/read.cgi/news4gep/1277294113/

233 ：

同人で既存のゲームを作るのであれば
既存のエディタやゲームエンジンで十分だろう
既存のエディタやゲームエンジンで表現できないゲームを作りたいのなら
新規に作る必要が出てくるだろうが同人のレベルを超えてしまっている

234 ：

>>174
凄いね。自分で作って売ることはいいことだと思うよ。
コミケで対面販売とかもしてみるといいかもしれない。
まあ、こっちもあまり呑気なことは言ってられないんだが……。

235 ：

よし、某掲示板でなんのゲームの解説なら買う？って聞いてきたら
C/C++でSRPGなら3000円で買うってのが多かったから今度はC/C++でSRPGを作るぜ
終わったら次に多かったjavaでAVGも作ってみるぜ（javaなんて流行ってるのか？）
ちなみにC#でアクションゲームは？って聞いたら「いらねー」って即答だったぜ・・・orz
事前調査は大事だぜ・・・orz

236 ：

C#はDirectX使いにくいから敬遠されてるだけだと思う
Managed DirectXのようにC/C++と同じ感覚でDirectX使えたら
C#で書きたい人一杯いると思うけどね
XNAはXBOXの制限を受けてDirectX9+XBOXの仕様の制限から
抜けられないし、SlimDXは公式以外のサードパーティ製は
いつ開発終了になるか不安ってのもあるし
>>235
ちなみに、ソフトバンクから出版されていたロールプレイングゲームプログラミング
という本がまさにC/C++でSRPGの本だったけれど、もう絶版だから
それほど売れてなかったと思う
ちなみに、その本が本体2600円なわけだが、3000円にこだわってると
いつまでたっても売れないと思うｗ

237 ：

Panda3D ってのもあるね。フリー

238 ：

Hero EngineというのがMMO向けのライブラリで、基本無料＋売上の30%
40万円ぐらい払えば売上の15%
サーバー付きらしい
http://www.inside-games.jp/article/2011/03/03/47689.html

239 ：

>>236
2800円にしたけどあんまり変わんないっしょ？
1500〜2000円ぐらいにするとまたなんか違ったりするのか？
あと、その本なんかタイトルがＲＰＧだからじゃね？（そんなことないかｗ）
ま、ゲーム自体作りたいってヤツ少ないのかもしれないなｗ

240 ：

ていうか同人はかなり出来のいいやつでも２千円ぐらいが相場だぞ。

241 ：

>>240
それ、ゲームの話じゃね？

242 ：

http://d-stage.com/shop/detail.php?seq=18521
このページ数、オフセ印刷でこの値段なのに
ハリボテC#アクションとPDFで3000円とかマジ…
そもそもゲームエンジンですら…

243 ：

ただの宣伝だったね

244 ：

>>242
それで何が作れるのかわかんなくね？
いくつかサンプルがほしいところ

245 ：

エンジン系の商品の惜しいところはそれで何が作れるのかわからないところだよね
俺もスキンメッシュ動くソース（俺ライブラリ（名称未定））あるから作ろうと思ったけど
それをどう表現したもんかそっから先進まないんだよね

246 ：

>>245
馬鹿なだけじゃね？

247 ：

そのサークルのゲームほとんどそれで作ってるみたいだよ
D.N.A.Softwaresってとこみたいだからググったらサイトあったし、
普通の人間ならサンプルまでたどり着けると思う

248 ：

>>246
これが難しいんだよ
１．スキンメッシュに対する解説をするのか？
２．あくまでクラスの使い方だけに絞ってゲーム自身に対しての解説だけにするのか？
でまず悩む
両方するにはコストでかいし
１だけだとついていけるヤツがかなり少なくなってしまうし、そもそも興味がもてない
２だけだと１からすべてを組み立てられなくなるわけで自然と対象者を絞ってしまうだろうし
人のライブラリをいきなり使うのってそれはそれで結構センスいるからなぁ・・・
>>247
なるほど２Ｄゲーに特化したと・・・

249 ：

>>248
間口は広く初動は速くいう意味で２で始めて、
１は要望があれば個別に対応するのがよいかと思います。

250 ：

>>248
んーだからDirectX自身もRMとかいう初心者向けモード
あったけど廃れたじゃない。あれって結局使い方簡単に
すると痒いところに手が届かなくなって、たいおう

251 ：

>>248
続きは自分のブログでやってくれる？

252 ：

>>251
そのレスはエンジンに関するものだっただろ

253 ：

（続き）対応しようとすると低レベルをいじらなくちゃいけないから
かえって面倒でほとんど使われない、余計なお世話みたいな
感じになっちゃうんだよね。

254 ：

外部のエンジンを使うということは逆に言うとそのエンジン
がないと動かないってことだから一種の欠点でもあって、
移植とかまで視野にいれるとちょっとまずい。
だから独自に俺ライブラリ作ったり俺エンジン作ったりとか
はそれなりに意義がある。それに根本的なこと知らないと何ができて
何が出来ないのかとか判断つきにくくなる部分もあるし、
再発明でもそれをやる意味はあるのよ。

255 ：

>>250,253
ＲＭは「しばらくこれで十分」って割り切ってた人は結構使ってたと思うけどな
スキニングが一般的になってからは廃棄処分になったけど
でもスキニングもちょっとしたことだからなぁ・・・
この辺いい感じでまとめたのも含めて売ってみるか
SRPGは先駆者が売れなかったっぽいから今度は3DADV（スキニングお披露目ゲームになるけど）でいいかｗ

256 ：

じゃぁオレも適当にHP作ってでSTGあたりで記事書くか。

257 ：

>>256
ＳＴＧは回避しておけ
ＳＴＧってだけで見てもらえない可能性が高い

258 ：

STGは有名なのあるしな。2Dアクションゲームとかがいいんじゃないか

259 ：

2Dアクションも対抗馬つえー…っていうかSTGとだいぶ被ってる

260 ：

>>238
利益じゃなくて売り上げなら、もうけ０なんじゃｗ　> 30%

261 ：

だからそこは基本無料なんだろ？
軌道に乗ってからは課金してくださいっていうまさにMMO商法

262 ：

取りあえずID:u5vL8x/Tはトリップ付けようぜ

263 ：

酉なくても大体わかる不思議

264 ：

じゃあ3DSTGにするというのはどうだろう

265 ：

STGはロジックが単純過ぎて参考にならない。
RTSがいい。

266 ：

STGってことだけなら複雑なことすればそれはそれでおもしろくなりそうだけど
大抵、R的な組み方してて他に応用が効かないんだよなぁ・・・
自機も弾も敵も敵弾も障害物もなにもかも共通部分が多すぎる
その組み方に酔ってしまうと他のゲームが組めなくなるほど

267 ：

全部アマチュアの個人製作
・98年に発売されたハーフライフのゴールドソースエンジンを使って
ナルトのゲーム
http://www.youtube.com/watch?v=sbG8czUg_pY&hd=1
ドラゴンボールのゲーム
http://www.youtube.com/watch?v=IZDSCUwW6ug&hd=1
・ハーフライフ2のソースエンジンで
攻殻っぽいゲーム
http://www.youtube.com/watch?v=MOh3xYPrYF8&hd=1
HL2のグラフィックを大幅に向上させる
http://www.youtube.com/watch?v=ypJGm18uxPU&hd=1
・アンリアルトーナメント3のUE3の無償版であるUDKで
巨大なボールを動かして解くパズルゲーム
http://www.youtube.com/watch?v=B2Dx_LXLfgY&hd=1
映画ターミネーターのゲーム
http://www.youtube.com/watch?v=zBSPiMYaPRY
タワーディフェンス型FPS
http://www.youtube.com/watch?v=1cp5oqRPSNQ&hd=1

268 ：

Unityの日本語サイトを見つけたがチュートリアルからとんでもねぇことになってるｗ
http://unity3d.com/japan/
http://ws.cis.sojo-u.ac.jp/~izumi/Unity_Documentation_jp/Documentation.html
チュートリアルどおりにやってるはずだけどなにやってるのかさっぱりわからないｗ
普及するまでもうちょいかかりそうな気がするな

269 ：

>>267
肝心のゲームはどこでプレイできるんだ？

270 ：

>>269
全部Moddbで無料でダウンロードできるよ

271 ：

>>268
ちゃんと「基礎」読んだか？
この程度のチュートリアルが理解出来ないならゲーム作れねえだろ…

272 ：

>>271
じゃあ、ちゃらっとゲーム作ってみせろよ
出来もしないくせにｗ

273 ：

煽りあうなｗ

274 ：

馬鹿同士で喧嘩するのはよそうぜｗｗｗ

275 ：

>>271
なんかね
ずっとわからないまま進むんだよ
用意されたもんを特定の組み込み方をするだけのサンプルだから
一番知りたい
「１から作る（俺の作りたいゲームを作る）にはどうしたらいいんかな？」
って部分がかなり据え置かれるっていうかもしかしたら
そういう用途だとあんまり恩恵ないのかもしんないｗ
チュートリアルやってから思ったけどｗ

276 ：

>>275
「細かい解説はリファレンス見てね」ってスタンスだからね。
上級者向きのチュートリアルになってる。

277 ：

>>276
ちなみにUnity使うとしたらモデリングソフトって何がいいの？

278 ：

洋ゲ＝ZBrushなイメージ

279 ：

>>270
サンキュー

280 ：

Unityは詳しくないから知らんけど
俺がよく遊んでるゲームで使われてるSourceエンジンに関しては
チュートリアル的なものはなんでもYoutubeで誰かが勝手に解説動画あげてるぜ

281 ：

>>280
じゃあ、ちゃらっとゲーム作ってみせろよ
出来もしないくせにｗ

282 ：

こういうエンジンとかライブラリ的なものってHowTo的な
解説しかしないから使い手が混乱疲弊するんだよな。
人によってやりたいこと千差万別なのに、それら全てに
いちいち回答するとか無理だもんな。だからユーザー同士で
あーでもないこうでもないと議論しあってヘトヘトになっていく。
だから本当に必要なのはどういう理念で作られてるのかとか
細かい仕様以前の原理みたいなものなんだよね。それが
わかればたぶんこういう機能あるだろうとかこれは出来る
これは出来ないとか判断できる。けどそこまで理解できる
人間なら自分で作るわなｗ

283 ：

そっかー

284 ：

簡単な入門書書いて電子書籍として売れば、金になりそうだな。

285 ：

>>282
ＭＳのマニュアル詐欺で、
　マニュアル＝分かりずらい
ってのが定説になっちゃったからな。
長ったらしい文章をだらだらと書いてあって、
間違ってはいないんだけど、Rくそ分かりにくい

286 ：

MSのマニュアルって分かりづらいのか・・・。
最近のMSDNが恐ろしく便利なのはその辺が改善された結果なのかねぇ。

287 ：

まあ翻訳にも問題が

288 ：

MSDNってほとんど機械翻訳だしその機械翻訳すらされてない（日本語版で表示すらできない）ページが多々あるからな
これなら英語でも良いから完全網羅してくれるドキュメントの方が遥かに良いわ
「MSKK仕事しろ」と言われる最たる面

289 ：

ＭＳというか、ＭＳに代表されるような、
海外から出てきた系なマニュアルね

290 ：

MSDNの英語ぐらいだったらまだわかりやすいほうだろ。
文法わかんなくても単語さえ知ってりゃ大体意味わかるし。

291 ：

>>278
それってボーンも使えるの？

292 ：

>>291
ボーンらしきものを使ってモデリングはできるけど、
アニメーションをするためのボーンそのものは使えない。

293 ：

【前スレ読んでない人用】
NG推奨◆GRGSIBERIA
>>2で言われているキチガイとは292のことです
触れないようにしましょう

294 ：

>>292
マジか
じゃあ、Unity使ってる人ってなにでモデリング（ボーンアニメーション込みで）してるの？
FBX云々ってあるけどその変換がすんなりいくソフトから見つけないといけないじゃないか？
そんでそのモデリングソフトが高額だったらUnity自体がフリーでもなんの意味もなくてショボーン

295 ：

>>294
Blenderとかあるだろ

296 ：

>>294

297 ：

>>295
Blenderかよー・・・仕方ねぇいじるか
ありがとう

298 ：

何が「仕方ねぇ」なんだ？

299 ：

ネタ投下
ttp://game.watch.impress.co.jp/docs/news/20110307_431667.html

300 ：

無料で全部、しかもモーションまでまとめてやりたいならそらBlenderしかないだろう。

301 ：

そんなことはない
統合環境っていうならBlender１択だけど
合わせて使うならボーン入れやモーション付けは他にもあるよ

302 ：

統合環境の話だよ。

303 ：

>>174
のトライは面白いと思ったけど、全然売れてない…　市場がないのか？

304 ：

内容がRだからだろ。

305 ：

価格がないように見合わないから。あと、ターゲットがはっきりしない。
大体簡単なものが作れない初心者が、簡単（といってもコードを書かなければならないレベル）な
フレームワークを買うはずがない。
こういう商品は、短くてもいいからもの凄く優れたサンプルがついていたほうが売れる。
わかりやすいことは売りにならず、俺もこんなのを作ってみたいぜ、という夢を刺激するべき。
実際に作れる難易度かどうかｊはまるで気にする必要が無くて、このすごいビジュアルを
どうやって実現しているのかの解説のほうが需要があるし、金を出すやつも多いだろう。
フリーで配るならこの限りではない。黎明期の猫ワカとかね。

306 ：

>>174だけど
まあ、このレベルのものじゃダメってことだな
必要だと思えば値段はあんまり関係ないっしょ？
仮に1000円とか2000円にしたってそんな技術書みたことないし
第一安すぎて信用できないじゃん
値段下げてもあんま買う人いない気がするね
買っても２ｃｈの義理で4〜5人ってとこ？ｗ（このスレの人間が見かねて買ってくれる的なｗ）
やっぱりゲーム自体がショボイ・つまらないってのと
C#（どうやらこの言語人気ないらしい）ってのと
書いてる俺に信用がないってのが大きな理由のような気がするね
次C/C++当たりでスキニング付のヤツ出してみたら
その次は俺もゲームエンジン使って作ってみようかな？
なんでいまとりあえずUnityをちょくちょく触ってる

307 ：

>>305
それは実際の経験則で言ってるの？
売ったと言う意味で。
僕も140Pのハルヒ本出したけど、1000円で25部ぐらいが限界だったぞ。
値段設定そのもので激しく後悔したけどね。

308 ：

>>306
応援するよ、面白いトライだから、是非がんばってみて欲しい。
俺は、自分で好きに作れるから要らないけどね。　方向性は有りかも知れない。

309 ：

>>306
え？嘘ｗ
2000円前後で良い技術書沢山あるよ
本屋行ったことないの？ｗｗｗ

310 ：

>>308
この形式で売る人がもうちょっと増えてくれたら
みんな気軽に買ってくれると思うんだけどなぁ・・・
こういうのってまわりの勢いもあると思うんだよね

311 ：

ぶっちゃけ初心者がこの値段で買うなら
松浦や赤坂の本を買った方がまだマシ
てのはさすがに侮辱しすぎか

312 ：

>>310
簡単なツールなら、ソース付き自由改変可で500円ぐらいなら出せるけど。
そんなのでいいなら、トライできるけど？

313 ：

>>311
いやー、その人たちは何冊も出してるわけだし
色々と学んだこともあるんじゃないだろか？
ゲームエフェクトマニアックスもってるけど
俺よりスキル高いのは確実だねｗ
でもその人たちがなかなかやんない
・チュートリアル形式でゲームを作る（これが今回）
・チュートリアル形式でスキニングのサンプル付き（全ソース公開）のゲームを作る
的なのはやってからゲームエンジンに手をだしたい俺
俺が独学で勉強してるとき、この２つがほしかったんだ

314 ：

>>312
それは自由にやってみてよ
できたら俺も買いたい

315 ：

>>314
暇が出来たらやってみるわ、ただ、ここには非公開な。
また〜り、そのうち出てるとおもうよ。

316 ：

ハッタリでもいいからスクショどうにかしろよ。こんなショボいの三千円じゃ買わねーだろ。見た目重要

317 ：

C++＋DX11とかならこの価格でも分かるけど
C#＋Managed DXとか滅んだ技術でこの値段って詐欺だろ

318 ：

>>316
うーん、ビジュアルで引くには女の子でも出してはじめて効果あるんじゃないかなー？ｗ
>>317
やっぱC#人気ないんだよねｗ

319 ：

C#自体は人気あるだろ

320 ：

>>319
俺の個人的な調査によるとあんまり好きな人いないよー
まずC/C++で次にjavaって感じ
もしかしたらjavaのが多いかもしんないぐらい
んでC#はそもそも知らないって人のが多い

321 ：

どんなクソ環境に居るんだよ…

322 ：

内容以前に3000円だと書籍が買える値段だから、信用のない人が書いた
電子媒体は相手にされないだろうね。

323 ：

>>321
しらねーけど
なんでもiPhoneとかjavaが人気らしいんだ

324 ：

まちがい
javaじゃなくてアンドロイド？

325 ：

プログラミングのコミュニティランキング
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
C#はC/C++やJavaに比べると下位ではあるけど、低いというほどではないね。

326 ：

一般人の話だろ？マとかじゃなくて

327 ：

C#が人気じゃなかったら何でGUI組むんだよ。
MFCやDelphiでも使うのか？

328 ：

win32apiでガリガリ組んでます･･･

329 ：

ゲームのGUIはグラフィックでいいでしょ。

330 ：

GUIは別にC#じゃなくても組めるだろｗｗそんなに不思議がることかよｗｗｗ

331 ：

ゲームのGUIは画面の奥からグルグル回転しながら出てくる
ようなやつだから通常の言語やライブラリとはほとんど関係ねえよな。
C#はあのアーキテクチャ見た瞬間に却下だろ普通。
まああれでしか作れないってんなら別だけどさ。
それどころか本職だとC++すらまともに使わない人が多い。
根本原理がコロコロ変わるゲームでクラス使うとかえって
混乱するからC++環境でCライクな書き方をするのが主流ｗ

332 ：

エンジン本体はC/C++ + DirectX
その他周辺ツールにC#
これが俺のジャスティス
来年以降にC/C++本気出す

333 ：

言語論議はどうでもいいからゲームエンジン作れよ

334 ：

>>331
＞根本原理がコロコロ変わるゲームでクラス使うとかえって
＞混乱するからC++環境でCライクな書き方をするのが主流ｗ

主流じゃねーよバカw
つかゲームでもデザパタ使用が当たり前だっつのw

335 ：

>>334
じゃあ、ちゃらっとゲーム作ってみせろよ
出来もしないくせにｗ

336 ：

ゲーム開発でデザインパターンとかダルいこと言ってたら仕事にならん。
ああいうのはIT土方などレベルの低い人達のオモチャ。

337 ：

本体もC#書く

338 ：

オブジェクト志向がまともに機能するためには設計を集中管理
するような仕組みが必要だけどゲームはクリエイティブ系で
皆自分の発想でおもいおもいにやりたがるから大抵駄目つうか
最終的には美味しそうなスパゲティが出来上がるというｗ

339 ：

>>311
いや、松浦本はかなり良くなってるぜ
最近刊行された本ではあのヘンテコリンなタスクシステム解説をしなくなった
http://www.amazon.co.jp/dp/4797359978/
胡散臭い部分がなくなって初心者にオススメできる良本になってるんだぜ

340 ：

美しいスパゲッティを書いたら、それがデザインパターンになっていた、が正解。

341 ：

デザインパターン（およびその基本概念）ってすごく便利でありがたく使ってるんだけど、
やっぱり速度の面ではデメリットになることが多いのかな？
たしかゴッド・オブ・ウォーだったっけかが、オール生Cでプログラミングしててマジビビった。
処理速度を求めてそうなったらしい。

342 ：

Cのほうが若干高速になるというのはある。
だからパフォーマンスに直結するような部分はCで
ゴリゴリ書くしかないよな。

343 ：

なるほど･･･

344 ：

コンパイラによるぞ
VisualC++なんかだと凄くコストの高いメソッドでも使わない限り
同じ処理で最適化オンならCとほとんど変わらないかCより速くなる

345 ：

C++が遅いといえるのは、バカが作った場合だ。
優秀な奴がC++　と　C作ったら少しCが速いだけだが。
そもそもメンテ大変、作成大変なCなんかで書かん。

346 ：

バカはコンパイラが吐いた後のコードを知らない

347 ：

ついでにバカは自分を基準にしか物事を考えられない。

348 ：

ゆえにバカは救いようがない。

349 ：

http://masafumi.cocolog-nifty.com/masafumis_diary/2011/03/udk-2011-3-dire.html
http://www.udk.com/news-beta-mar2011
これで売り上げ5万ドルまでロイヤリティフリーだぜ？馬鹿げてるな…

350 ：

>>336
デザインパターンというのは、先人たちが作り上げたよく使うコードの組み方に
名前を付けたものを言う。
タスクシステムなんかもデザインパターン。
だるいとか言ってる奴は、何も知らないか使い方を間違ってるだけだ。

351 ：

家庭用ゲーム機とかだとハードが特殊な作りだから
トリッキーな実装を要求される場合がある。
たとえばまずこのデータ構造ありきで、クラス使って
違う内部表現すると著しくパフォーマンス落ちるとか。
また、ゲームは繰り返し大量のデータを処理するような
ことがありがちで、そういうところに内部隠蔽されたクラス使ってると
単純にコピーできないとかいちいちコンストラクタ呼び出される
とかで著しい劣化の原因になるという。

352 ：

＞単純にコピーできないとかいちいちコンストラクタ呼び出される
これは単にそのクラスの作成者がアホなだけでしょ・・・

353 ：

だ・か・ら、そんなことも分からないバカが作るから遅い。
>>351お前はバカか

354 ：

つかファミコンならともかく、今のゲーム機なら
C＋＋のオーバーヘッドなんて無視できるレベル。
それよかソースが巨大になるからOOPの
効率化の方がよっぽど大事。

355 ：

>>354
それが常識なのに速度とか無駄に気にしてる奴多すぎだよな
速度面で気にしなきゃいけないのはネックになりやすいディスクI/OやネットワークI/O等くらい
気にするだけ時間の無駄と言えるレベル。俺ならそんな余裕があるならさっさと実装進めるわ

356 ：

最近のハードウェアは高性能なので俺は自分の書くC++のコードの速度でも
まあおおむね満足していますね
なので高速性のためにわざわざオール生Cで書くことはあまり真似したくないかな
言語選びもまあ突き詰めるといろいろ難しいかもしれませんが

357 ：

>>352
アホではない。仕様が変わるからそうなるのだ。
なんでそんなにシビアかというとゲームはフレームレート
維持するのが重要だからちょっとしたパフォーマンス低下が
命取りになるのだよ。メモリも少ないしな。

358 ：

C++自体のオーバーヘッドというよりクラスによって余計な括りが
できてしまうから後で高速化のために処理を組み換えようと
思っても無理になってしまうのが嫌われる理由なんじゃないかな。

359 ：

>>358
それ完全な設計ミスじゃねーかｗｗ
オブジェクト指向の抽象化をよく理解できてない人はそういう自体に陥りやすい
まあとっつきにくいは事実だからそんな人は無理に使う必要ないんだけどね
趣味の範囲ならば

360 ：

>>359
設計ミスじゃないって。そもそも気分で仕様変わるものに設計も糞もない。
オブジェクト志向は完成までのコストはかえって高くつくけど
その後の保守費用が安くなるから何年も運用してるうちに
メリットがデメリット上回ってくるんだけど、ゲームは保守しなくて
バグあってもそのままとか多いからデメリットしか残らないという。

361 ：

ID:TcT++kO8
この人ダメだ、何か基本的な事を勘違いしてる・・・
しかも自分に間違いはないって完全に信じちゃってるタイプだよ。
こうなると多分何言っても無駄。技術の発展についていけない技術者って悲しい・・・

362 ：

デザパタを始めとしたオブジェクト指向設計って
うまく組めばかなりスマートになるからやりがいあるよね。

363 ：

Cによる恩恵よりC++で書いて他の事やる時間作るほうが有用じゃね
その時間をもたつく処理の高速化に回せば
同じ開発時間ではC++でやったほうが早かったってなりそう

364 ：

C++で書くとコーディング量が増えるし管理コストが増大する。
ちゃんと整備されて再利用できるコードはそうでないものの
３倍の開発コストがかかる。長いこと運用するコードでなければ
元がとれない。

365 ：

お前らもういいから新しく言語開発しろ。ここはゲームエンジンのスレだ。

366 ：

仕様変更に強い設計ってのはCだろうとC++だろうとやればできるし、やらなければできないよ。
そこんとこ、言語の特徴みたいに言われても困る。
Cでどんなプログラム書いてるのか知らないけど、オブジェクト指向っぽいことしてるようなら
C++使えばもっと簡潔に書けるかもよ。って程度の可能性はある。
でもC++を使うだけでよりよい設計に自動的に導かれるなんてことは無い。

367 ：

>>364
へ？
つかエンジンは流用するに決まってるだろ？

368 ：

>>364
↓こちらへどうぞ。
【結構迷う】C vs. C++【どっちで行こうか】
http://hibari.2ch.net/test/read.cgi/tech/1207419469/
根拠の無い言いきりじゃなくて、ちゃんと根拠も添えてな。

369 ：

Unity「C++で書いたJIT上でJavascriptとC#を動かすのが最強なんですけどね＾＾」

370 ：

>>369
PC/PS3/xbox360ではそれが標準。
コアのエンジンだけC＋＋で、ゲームの挙動はスクリプト。
うちの会社はスクリプトにPythonを選んだ。

371 ：

ゲームエンジンを使うスレで効率が悪いからC言語を使う、なんて
呆れるばかりだよね。

372 ：

>>366
>でもC++を使うだけでよりよい設計に自動的に導かれるなんてことは無い。
これは正しいが。
>仕様変更に強い設計ってのはCだろうとC++だろうとやればできるし、やらなければできないよ。
>そこんとこ、言語の特徴みたいに言われても困る。
上と下は矛盾
>Cでどんなプログラム書いてるのか知らないけど、オブジェクト指向っぽいことしてるようなら
>C++使えばもっと簡潔に書けるかもよ。って程度の可能性はある。
どんな形ですら、同じ仕様が簡素に書けるなら。それは、仕様変更に強いのだ。
矛盾したことを言うな。

373 ：

このスレは言語厨に監視されています。

374 ：

>>366は
オブジェクト指向をうまく利用できないならCもC++も大して変わらない
うまく利用できるならCより簡素にかけるかもよ
しかし、ただ適当にC++を使ってるだけで全てがうまく行くわけないんだからそれを仕様みたいに言うな
って事言ってるだけだよね。全体的な意味としてちゃんと通ってる
それが矛盾に見えちゃうとか解読力ないのかな。そもそも矛盾の意味を誤解してたりして^^;
文章の順番変えて矛盾だ！って言っちゃうくらいだからね。打ち消しの意味とか理解してないのだろう
まあ>>372が馬鹿でも俺は損しないから言語論争なら>>368のスレ行けよ
ぶっちゃけどっちでもいいんだがいちいち論争しても不毛なのに気づかない辺りが馬鹿らしい

375 ：

お前ら…

376 ：

いいぞ、もっとやれ

377 ：

>>358
意味分からん。
そう思うならクラスを使わなきゃいいだけなんじゃ…
Ｃ++は便利なＣを内包した言語ですよ？
ランタイムのサイズがどうとかいうのなら、まあ分からないでもないが。

378 ：

そもそもC++でガッカリなコードを書く人間が
Cならきっちりしたコードを書けるわけないんだがな。
C++理解し切れなかったかそもそもCでもガッカリかのどっちかでしょ、

379 ：

お前ら本当に不毛な議論wが好きだな。ゲームエンジンに関してもそうだったが。

380 ：

それが2ch

381 ：

Cでも自主規制によってC++と同様のことができるので
両者の違いは言語仕様で制御されてるか否かである。
自主規制であれば無理な仕様変更でもルールを破る
という必殺技が出せるが言語仕様で括られてると
どうしようもない。

382 ：

言語なんか適材適所でいいとは思うけれども、
ＣでＣ++の言語仕様と同じことをやろうとするとC++よりも大抵は遅いと Scott Meyers先生が仰ってるぞ…

383 ：

オブジェクト志向は継承が便利に使える状況でないと
あんまりメリット無いが、ゲームの雑多な要素をクラス化
継承とかやると組み換えが激しいのですぐカオス化する。
そういうのにはあんまり向かないわな。

384 ：

オブジェクト指向で継承ってメインじゃないだろ。
ポリモーフィズムとカプセル化の方が重要だ。

385 ：

>>383
だからんなこたぁないってさんざん言われてるじゃん…

386 ：

>>383は専門学校卒。

387 ：

だろうな。理論的な事ばかりで大事な実践的思考がまだ備わってない感じ
大方教えてもらった事が全てでそれ以上はないと勘違いしてるのだろう
訓練と実戦は違うんだぞ
それはそうと言語論争はとっととどっかいけ

388 ：

基本的に同じ処理を強引にまとめたときに
「んじゃ、このパターンだけこんなことしてくれる？」
って追加がきたときにどうやってこの変更を適用するかっていうと
if(このパターン){
　こんなこと
}
的な追加するぐらいしかないっしょ？
これがソースを汚くする
これは分岐のときにif文が見えているからまだわかりやすいほうで
生成するオブジェクトをどっかで変えている場合とか追加部のソースを追うのは困難になる
こういう変更が入りやすい部分ってのはハナからまとめないほうがいい場合もあるよね
ってことがわかってくるとオブジェクト指向も微妙〜な感じみ見えてくる

389 ：

何だろこの青臭さｗ

390 ：

>>389
そうやって馬鹿にだけはするけど実際晒させてみると
きったねぇ変更方法しかみたことないけどな
ちなみにif(このパターン)をソースの各所にいれちゃうと
上から下まで全部読んでみないと本当の処理がわからないソースになっちゃう
それと変更のたびに他の処理への影響も馬鹿でかくなる
まとめるのってどうよ？って俺は言いたい

391 ：

未熟なのを理解したほうがいいよ。自覚無いと主うけど。

392 ：

>>391
だから理論と実践なんだって
１．オブジェクトＡ〜Ｚまでまとめたソースと
２．オブジェクトＡ〜Ｚまで別々に作ってあるソースで
オブジェクトＡに対して変更が入ったら
１はＡ〜Ｚまですべての影響範囲を気にしないといけないのに対して
２はＡだけ見ればいい
ゲームプログラムに無駄に時間がかかるのは
なんでもかんでも１でやってしまう奴が多いからだと思う
これを程度が低いと斬ってしまって思考停止してしまっている
これの問題は明らかにトレードオフだ

393 ：

わかんねえかなあ。クラスによって設計概念の縛りが
強化されてしまうということが。
単なる構造化手法に比べてコーディングが済んだ後の
設計変更が困難になるんだよ。
ゲームはとくに趣味的根拠でコロコロ仕様変わるから致命的。

394 ：

＞スキンメッシュ
『ゲームエンジン・アーキテクチャ』に4ページくらいの理論解説がある。
それまで内部がブラックボックスなサンプルを使うしかなかったが、
その解説を見て、「ああなんだ、結局それしかやっていないのか」
ってところが良く分かった。理論レベルだが。
＞処理速度
見た目のインパクトで他の作品より秀でるかどうかは、最終的に処理速度に掛かっているよね。
ちょっと昔だけど、鉄拳６のラスボスを初めて見た時、老舗ゲーム屋の意地見せてると思った。
『ゲームエンジン・アーキテクチャ』でも機械語レベルの最適化について触りだけ言及されている。
並列処理パターンの要点が簡潔に解説されているのも良い。
しかし『ゲームエンジン・アーキテクチャ』は理論とか課題は豊富なんだけど、
実際の開発環境での検証手順については全く説明が無い。
またケースに応じて、どのようなゲームエンジンを構築するかって課題をほのめかすだけ。
そういう意味で、やはりこの本は「地図」ではあっても「GEMS」ではない。
この本は、ゲーム開発の経験がある人なら、すらすら読めてしまうだろう。
より詳細な参考文献の紹介も頼もしい。

395 ：

クラスはプロパティとメソッドの集合という結構大きな
単位なので組み換えが頻繁に発生する
ような環境でポンポン思いつきで作ってると逆に
不自由になってしまう。組み換えのことを考えると
大きな単位での括りはつくらず、いざとなったらバラバラ
にして再構築できるほうがいいｗ

396 ：

C++→抽象的な考えが得意な高IQ保持者などの少数派向け
C→単純が一番。凡人向け
C++使いから見れば多態性、カプセル化はうまく利用すれば利用するほど問題に柔軟に対応できるのは当然
C使いから見ればその考え自体が理解できない。何言ってんのこいつ状態
もうそれでいいじゃん。お互い理解したところで所詮自己満足にしかならないのに
随分C++使い側の肩持つ言い分になったけど実際そうだし仕方ない
ほらム板いけ、ム板

397 ：

>>396
知能の問題というより制作現場の都合が大きいよな。
海のものとも山のものともわからないような状況で
ガシガシ組みはじめるゲームと設計の労力の大半を
使う非ゲープロジェクトを同列に論じてはいけない。

398 ：

あら、不思議、言語論争から開発工程の議論にすり替わっちゃったよ！
開発工程など案件によるだろうに
まるでゲーム開発には設計は重要じゃないような言い草の暴論まで飛びでるしどうすんだよもう

399 ：

>>397
まだ言うか…いい加減邪魔だからどっか行け
>>398
やっぱ知能の問題じゃね？って言いたくなるなｗ

400 ：

>>393
OOPの概念がまったく理解できてないね。
ゲームの仕様はUpdate関数内で処理するもの。
どんなに仕様が変わっても、object.Update()という
インターフェイスに変化は無い。
コアのエンジン・ライブラリは汎用性のある部分だけを集めて
各ゲーム特有のロジックとは完全に分離するもの。
頻繁な仕様変更はエンジン部分にOOPを使わない理由にはならない。

401 ：

OOP使えない奴がいくら騒いだって、使えないから理解できるはずもない。
OOP使える奴はCも構造化も知ってる。それだけの話し。

402 ：

>>400
ゲームの処理はタイトル固有のものが多い。
そして表示など基本的で普遍的な部分はライブラリが
大抵用意されてるのであまり問題にはならないのだな。

403 ：

ゲームって自由自在にいろんなものが組み込まれてて端から
見るとすごく高度なことをやってるように感じるけど、実のところ
は統一仕様とかシステム的なものをあえて排除することによって
自由度を高めてるだけだったりするんだよな。
こういうこと言っちゃうと身も蓋もないけどさ。

404 ：

>>403
お前の開発したクソゲーはそうなんだろうよ。

405 ：

ゲーム開発でしっかり設計しないとかどこの中小ブラックだよ・・・

406 ：

どう考えても個人でクソゲーだろ

407 ：

>>405
そう思うのは現実を知らないから。
そもそもゲーム開発は設計と製造が分かれてない。
一応メインプログラマと称する人はいるけど、その人も
製造工程に組み込まれてて設計に専念してない。
ゲームプログラマに求められるのは仕様が適当でも
創造力で作り上げる能力。悪くいえば好き勝手だが
そうでなければものが出来ないｗ

408 ：

プログラミングが製造工程だとは、悲しい話だな。
http://www.google.co.jp/search?q=%22what+is+software+design%22

409 ：

>>407
いやいやいや・・・普通のゲーム会社勤めだが
設計をしてからコーディングを始めてるつーの。
仕様変更は当然プランナーからたびたびくるけど
メインプログラマーがチェックしてOK出さない限り通らないし
通ったらその部分は再設計しなおしてるわ。
根本的に仕様が適当っていうのもおかしいけどな・・・。
適当な仕様書なんてそもそもディレクターがOKださねぇ。

410 ：

その設計が>>392の１みたいになってるなら開発を余計困難にさせる
オブジェクトが８０個もできるような規模の場合
１個変更入れるたびにすべてのオブジェクトの動作確認しないとあるときバグったときに
とてもじゃないけど直しきれない
設計が共通部分を抜き出してまとめる系のことをやってるとしたら
そのゲーム開発は最悪の工数爆発を起こす

411 ：

>>409
おおー、それは珍しい。
と思ったけどよく考えたらそういう会社もあるな。
大抵エロゲメーカーとかだけど。
あんまり難しいことやらない類の製品だと一生懸命
「フローチャート」で仕様書いてくるよ。
フローチャートですよフローチャート（笑

412 ：

>>407
ソフトウェア工学を無視した意見だなｗ
大手の会社はメインプログラマが死んだら潰れるのかｗ
うちの会社ではプロジェクト毎に共通に設計されたライブラリを
使ってコーディングするが、そんな会社は珍しいのかｗ
いやー、しらなかった。勉強になったよありがとう。

413 ：

大手で思い出したけど大手からよく移植の仕事でソース
貰ってもドキュメントの類がほとんど無いのが普通で元の担当者
も説明できない。ハックして使えって言われるよ。
他人に見られるの想定してないのかプログラム自体も
ゴチャゴチャだし。正直請けたくない。

414 ：

>>411
いやエロゲーメーカーの話なんてしてねーよ。

415 ：

単体テストも知らない素人ばかりだな。

416 ：

業務アプリ等なら実際の仕事内容から推測して
かなり仕様が限定されるし無理な変更依頼があっても
理論的に説得し回避することもできる。
しかしゲームは機能的に明確な目的がなく趣味の世界で
なんでもあり、仕様の根拠が主観。ゆえに後でどう転ぶか
わからない上に主観で物言う奴は理論で説得できない。
ソフト開発においては最悪ともいえる条件だろう。

417 ：

だからこそおもしろいとも言えるし、難しいところだね･･･
それでも、ゲームエンジンを導入してシステマチックに開発する風潮を醸成した、
石田氏をはじめとしたカプコン社員は偉大だと思うなぁ。

418 ：

ゲームはプレイヤーを楽しませるために色々とユニークな
ものを作らなくちゃいけない。いわば特殊なものの集合体。
だから何よりもプログラミング上の自由度が高くなければいけない。
ゲームのシステム化が難しいのは、システムで枠組作っ
ちゃうとそれから逸脱したユニークなものが作りにくくなる
からなのであるよ。

419 ：

なるほど。
海外で金太郎飴ばりに似たようなFPSゲームがバリバリと出てくるのと、
エンジン利用をはじめとしたシステマチックな開発の隆盛には相関があるということだね。

420 ：

順調に痛いスレになってますな

421 ：

ゲームにおけるユニークさとは、アイデアであり表現であるだけで、
基本的なゲームプログラムの部品は別にユニークでもなんでもない。

422 ：

アイディアをプログラムで表現するのがゲームなので
アイディアがユニークならその表現であるプログラムも
ユニークなのです。しかもそのアイディア主観で変わる
から予想が困難。

423 ：

>>422みたいなほとんど何も知らないような奴が、上から目線で
書き込んでるのが痛々しいな。

424 ：

ゲームはその処理内容に関してこうでなくてはいけない
という根拠になるものががなにも無い。
しいて言えば企画者の想像力が根拠。人間の想像力には
限界が無いのでそこから飛び出してくる要件も無制限。
ゲーム開発者には無限の可能性や要求に応じられる
アラジンのランプの精のごとき魔法が要求されるのであったｗ

425 ：

「アイディアがユニークならプログラムもユニーク」とか後世に残すべき名言
そういったプランナーのつまらねぇRーにプログラマが関与しないためにスクリプトがあるんだっつの。

426 ：

スクリプトもプログラムの一種だということを忘れてはいけない。
臭いものを別のところに押し込んで蓋したところで何も解決しないｗ
まあ企画に問題を投げ返すためのツールだという点は同意だが。
そうやって防波堤築いていくしかないんだよ。

427 ：

どうせふざけた仕様書もってきたらその場で突き返すしな

428 ：

だいたい依頼する側が偉くて絶対権力を握ってたりするから始末におえない。
スクリプトとかで投げ返しても今度は何でもできるシステムを要求してくるし。
仕様を厳しく要求すると網羅的な仕様出してくるし敵も手強いｗｗｗ

429 ：

我が社のゲームエンジンを使えば時代のニーズに合わせて
システムを好きなようにカスタマイズできる上に、
開発中のゲームをスムーズに仕様変更するためのサポートも充実しております。
もちろん、各ハードのパフォーマンスを最大限引き出せるようエンジンをチューニングしてありますので
お客様はご自身のアイディアを実装する作業に専念することができます。

430 ：

レベルが違うと議論にならないという現実を見た気がするｗ

431 ：

頻繁に仕様が変わるというより、粘土をこねくり回してる感覚なんだろうな。
工業製品じゃなくて、芸術作品寄りの発想なんだ。
だからひらめきや思いつきを基にした試行錯誤や実験をたくさんしなくちゃならない。
で、時間一杯試行錯誤してるもんだから満足に仕様を整理して設計を見直す余裕も無い。
全体の流れを最適化する余裕も無いので、局所的な、その場しのぎのチューニングに終始する。
そこで、ゲームエンジンの出番ですよ奥さん。
めんどくさい作業は貴方の代わりにエンジンが引き受けてくれます。
開発現場からプログラマは消えて、プランナ、グラフィッカ、サウンドなどのクリエイティブな職種だけで
スマートな開発を行えるようになります。
指示に対してできない理由を並べるだけのプログラマや
当たり前のことまで細かいことを執拗に聞いてくるプログラマはもう要らない。
心の通じ合った仲間たちと一緒にフィーリングでゲームを作ろう。
さあ、みんなでゲームエンジンだ。

432 ：

プログラマが居ないとかだともうそれこそ金太郎飴にしか
なんないよな。ゲームのロジックをちゃんと組もうと思ったら
どうしてもプログラマ的な素養が必要だもの。
エンジンつっても本当に何にでも応用できそうな普遍的な
ものは低レベルのライブラリ群とかだし、そういうのはデフォルト
の開発環境に大概揃ってるから今更語るようなことでもない。
ゲームエンジンに大きなメリットがあるとすればそれは異なる
環境で同じソースが動くなどクロスプラットフォーム展開で
効率化ということはある。だがゲームは元々そんなにプログラム
の開発規模が大きくない。多くてもせいぜい十数人とかのレベル
のものに馬鹿高いライセンス料払って使うのは微妙。

433 ：

ｔｓｔ

434 ：

９月にβの人、生きてる？

435 ：

地震後しばらく見ないうちにやっぱり言語論争から開発工程の議論に変わってるのかよｗｗｗ
途中から読み飛ばしたけど

436 ：

使う道具は工程に影響を与えるしまた逆も然り。
道具使うにしても現実に則した道具を選ばないと。

437 ：

実はタスク派とアンチタスク派の戦い
両派共にフレッシュな新戦力が投入されてる

438 ：

ここもついに世代交代か…こみ上げてくるものがあるな・・・

439 ：

こーいうとき中立派ほど利口なやつはいないよな
現実問題、ケースバイケースだから「これなら間違いない！」なんて方法はないのにな

440 ：

馬鹿にはそれがわからんのです

441 ：

だからといって馬鹿が中立派を気取ったところで利口の証になるわけでもないけどなｗ
「このケースでは明らかにこっちは間違いだろ」と分かりきってる状況で中立派だから

442 ：

状況で中立派だから→状況でも中立派だから

443 ：

>>1
●関連スレ
Blenderで3Dゲーム作ろうぜ
http://hibari.2ch.net/test/read.cgi/gamedev/1175839591/l50

444 ：

ねえ

445 ：

ちょっと脱線気味だがゲームエンジンをみんなが作ってるという事なので
そのなかでもゲームエフェクトに特化したエフェクトエンジンを作成中。
エフェクトならこれ使え！っていうミドルウェア的な立ち位置を目指したい。

446 ：

>>445
おおー
ガンバレー

447 ：

>>445
そういう一点主義なのもかっけーな！
がんばれ！

448 ：

>>445
なるほど、そういう発想はなかった
がんばれ！

449 ：

>>445
http://twitter.com/#!/bm_package/status/50520475251642368

450 ：

さぁ出かけるぞって時に玄関で転ばされた気分だ

451 ：

>>174
その後どうですか？1本でも売れた？

452 ：

>>450
あ、だったらその足で
イベントタイムライン（俺命名）ウィンドウ作ってくんね？
やる気があったらでいいけどｗ
つか、俺が作って儲ける予定だったんだけど５年もやる気になんないから他の人に頼むわｗ
仕様としては
WinMain関数でnewするとツールウィンドウが出るようになって
そのツールウィンドウには
Ａ―――――――――�@−−�@―――――�A−−�A――
Ｂ―――――――――――――――�@−−�@―――――
Ｃ―――――――――――――――――――�@−−�@―
　・
　・
　・
こんな感じのタイムラインがあって
横軸フレーム数（時間軸？）、縦軸管理オブジェクト（？別にオブジェクトでなくてもよし）になってて
イベントはこのタイムライン上にビジュアル的に配置できる感じで頼む
もちろん、再生、停止、一時停止、再開等のタイムラインアプリによくある機能は考えてつけてみてくれ
（でもこのツールには必要ないっちゃないか？）
上記、ツールで作ったデータはテキストフォーマットでわかりいい感じに取得できるようにしてくれ
ゲーム中ではキー入力のOnTrg、OfTrg、On、Ofを取得できる感じでイベントを取得したい
ぶっちゃけ俺の中ではこれさえあれば>>449で出てきたような妙なミドルウェアはいらねぇ
ちなみに横と縦は思いっきり伸ばせるようにしたい（１５分のイベントとか作りたい）から
２５５フレーム限界とかセコイことしないでね（どこまでも伸ばせる仕様で）
それと１つのシーンを分割して作ってつなげたいときもあるから初期値は必ず０フレームから開始とかやめてね
分割したもんくっつけるときはオブジェクト配置してなくてもうまくやってね
こんなもんか？
まあ、やる気の人やってみてくれ（自宅だと会社パワー使えないから一ヶ月ぐらいかかりそうだけど）

453 ：

>>451
まったく売れないｗ
っていうか、いまよく考えると売れたら売れたで不安だわーｗ
誰にもテストしてもらってないしねｗ
しかも、俺Unity中だからそっち興味ねーしｗ

454 ：

>>452
いわゆるスケジューラーね。
その機能なら既に入っててプラグイン形式で拡張できるようにしてある。
肝心のパーティクルとエミッターの部分が物量プレイでまだ時間かかるなぁって感じ。

455 ：

>>454
他の機能つけるから逆に魅力なくなるって感じ
何がやりたいかってーと
このスケジューラー？タイムライン？単体で配ってくれたほうが楽でいいと思うんだよね
これ使って、エフェクトじゃなくてキャラモデルアニメーションさせてエロゲも作れるよね？
って話

456 ：

スケジューラーなんにでも使えるのにモデリングツールぐらいでしかお眼にかかれないのが残念だなぁって俺は思うんよ

457 ：

作るのが凄まじく大変だからだよ…
ゲーム側に会わせて自由に拡張できないと話にならないしね

458 ：

>>449
有料じゃね

459 ：

>>445もいいもの作ってくれるなら有料でOK

460 ：

同じようなツールで１ライセンス１００万ってのがあったな。

461 ：

>>457
そういうのはいらない
単純にイベントが設定できるだけでいい
んでそのトリガさえ取得できれば内容なんていらないっしょ？

462 ：

スケジューラはデバッガに組み込まれてこそ効果がある。
組み込みなんかはデッドラインがガチガチのガチガチに決まっており
プリエンプティブも頻繁だ

463 ：

>>453
＞まったく売れないｗ
＞っていうか、いまよく考えると売れたら売れたで不安だわーｗ

負け惜しみ乙。

464 ：

>>463
いや、負け惜しみどころか全面敗北
やっぱ、モノ売るってのは難しいわ
準備不足も含めて、もし買ってもらってもサポートできるか怪しいし
現状、自分のＰＣで動いてるのに相手のＰＣで動かないなんて事態があったら
もう手も足もでないわ

465 ：

その後のサポートや販促は売る前に考えようよ…

466 ：

つかサポート以前に内容がそもそもクソだろ。
そこ反省しろって。

467 ：

>>466
おや、買ったんですか？
買いたくないけど中身だけ気になるのでインプレよろ。

468 ：

お前は出てこなくていい。３ヶ月経ったが何かできたのか？

469 ：

>>464
例えば、同じ事を本なんかにすればそれなりに売れるだろうが。
内容も労力も半端無いほど大変だし、文書力という違う力がいる。
DLshitの場合。
・営業先がミスマッチであるため、宣伝ができなかった。
・内容と金額がミスマッチだった。
と思える。
方向性を変えるならば。WEB上での入門にして、アフィーで稼ぐ方向もある。
これも、大変であることには変わりはない…

470 ：

>>464
勝ち負け以前の問題だと思う
無名なのだから内容を売るのではなく名前を売らないと。
値段もよくばった結果の3000円（税抜）。

471 ：

>>174だけど
まあ、ここにたどり着けたようなヤツならあの内容は必要ないな
どうしても内容ちょろっとみたいならＣ＃で組んであるからReflectorで
体験版のexeを逆変換してみ
定数やリソース、ファイルの管理はなんか元には戻らないけど
だいたいのソースの内容ならそのままみれるぞちょっと読みにくいだけだ
Unityはじめたらまったく興味がなくなってしまってｗ
１０００円でもいいやって思ったけど今度はサポートとか全くできる自信ないから怖くなって
３０００円で売れないままでもいいかな？って感じｗ

472 ：

>>471
むしろこの手の販売作品の可能性について興味がある
サポートはぶっちゃけ、なしって書いておけばなしでいいと思うよ
これに関してのユーザーの反応（販売状況）をもっと教えてほしい
俺的には780円以下になったぐらいで反応がでてくると予想してるし
500円以下なら割安感がでてくると思う
逆に100円ぐらいにして、もっとかっこいい絵にすれば、内容関係なしに売れるんじゃねーか？
本末転倒だけどさ
宣伝は2ch以外でもやってる？

473 ：

ファミ通によるとダイレクトXｌもゲームエンジンらしい

474 ：

ダイレクトＸな

475 ：

>>472
明らかに初心者向けなのにサポート無しっていかんのとちゃう？ｗ

476 ：

>>468
そう言いながらもツンデレだな、お前は。
一応、DirectXでPMDとVMDを結合してXファイルにするものを書いた。
が、XNA 5.0の内容によってはMMDX利用しながら作ったほうが早いなあと。
どうでもいいけど、MMD Agentとかゆっくりボイスって不気味の谷突っ走ってるよね。
形態素拾って文脈からメロディ生成するほうがリアルな気がする。
せっかくのミク声も甲高いゆっくりボイスになってるし。

477 ：

ゆっくり(AquesTalkという意味ではなく)は良い味が醸成されちゃってるよなｗ
電気自動車が走行時にわざと音を鳴らすようにというわけではないが、
遠い未来でも、明らかに合成音声ですよって分からないと困るようなシチュエーションではそのまま使われてるかもなｗ

478 ：

ゲームエンジンﾏﾀﾞｰ

479 ：

>>475
環境依存の部分をクリアしていくだけでいいんじゃないか？
サポートという名の有料ベータテストのはじまりだ！

480 ：

とりあえずパーティクルエディター的なところまでは出来た。
テクスチャ対応がまだだけどそれが終われば爆発とかなら作れそう。

481 ：

>>477
味と言えば味だけどね。
プレイ動画できちんとした地位も確立してるし、
キャラクターとしてアリだとは思うよ。

482 ：

4月1日はまだ早いぞお前ら

483 ：

Luaを使ったLOVEってエンジン
日本語使えるようにするにはどうしたらいい？

484 ：

やっぱり2chの技術系板って、馬鹿が煽りあってるだけの糞スレしかないな。
リソースの無駄だからもう次スレ立てんなよ。
書き込みも禁止、煽りあいたいのなら余所に行けカス。

485 ：

>>484
ひょっとしてギャグで言ってるのか？

486 ：

>>174です
こっそり1500円にしましたｗ・・・が、サポートは期待しないでくださいorz

487 ：

それでもたけーよ馬鹿

488 ：

あの程度なら一週間位でつくれるしな、、、売るかどうかは別として

489 ：

今からMDXとか何の役にも立たないじゃないですか

490 ：

せめてDirectX11で作ってくれよ

491 ：

300円ぐらいまで落とせば10部ぐらいは期待できんじゃないの？
カテゴリ全体の売り上げ平均から見て、価格が高すぎると思うんだが。

492 ：

キャンペーンとして最低価格で売ってみては？
1部でも売れないと盛り上がらん

493 ：

こういう試みは応援したいが、製作者の実力がわからんからワンコイン以上は出しづらいな・・・

494 ：

体験版やったけどフリーでも落とさないレベル

495 ：

>>491
内容が神なら５千円でも買うが、
内容が糞なら100円でも買わない。
それだけの話。

496 ：

行動を起こした。それだけは確実に評価に値する。

497 ：

>>496
本人が言う事じゃない。

498 ：

アク禁状態なわけだが・・・

499 ：

かけた！
>>174だけど
やっぱ、500円ぐらいにすべき？ｗ
もう1000円以下にすれば後はタダと変わらない気もするよねｗ
後は、面倒だからフリーでもダウンロードしないレベル？
でもそれはやなんだよね
フリーのソースってその辺に転がってるけどDirectX8とかで動かすのもままならないの多いし
とりあえずよくあるＰＣレベルで一応動かせるようにする手間をかけるぐらいの責任は自分にかけておきたい
んーじゃー、500円ぐらいにしてみっかｗ
ココ何やってるの？的サポートと
俺のＰＣで動かないから動くようにしてくれ的サポートは期待しないでくれ（まあ、これは金額関係ないけど）

500 ：

だからタダでもいらねーっつの。
何一人で張り切ってんだこいつは。
ウザ杉

501 ：

ここはゲームエンジンに関するスレじゃなかったっけ？

502 ：

>>501
いいじゃん
他に話題もないし

503 ：

>502
俺は別に構わないけど。
この板、雑談スレが乱立してるからな。
言ってみただけだ

504 ：

言ってみただけって何
言い訳がキモいんだけど

505 ：

この手のものはまずみれるものができるまでがながいからなあ。
そのあとは一気に進むが。

506 ：

>504
は？
言い訳？
イミフだな

507 ：

こう言った方がよかったか？
そろそろスレチだ。
消えろカス

508 ：

他に話題もないのに
人だけおっぱらってどーすんの？ｗ

509 ：

皆オレのために喧嘩するのはやめてくれ

510 ：

>>174
とうとう500円にｗ

511 ：

ちょｗ
何か応援したくなってきたｗ

512 ：

500円でも買う気がしない
作者が人間的に信用できないからな
最初は
＞だったら金とってでもちゃんとサポートしろよって俺の魂の叫びでもある
って息巻いてたくせに
売れないとわかったら
＞こっそり1500円にしましたｗ・・・が、サポートは期待しないでくださいorz
＞俺のＰＣで動かないから動くようにしてくれ的サポートは期待しないでくれ
こんな言い訳ばかり、なんだこれ
こんな人間が作ったもの買えないよ

513 ：

＞Unityはじめたらまったく興味がなくなってしまってｗ
＞１０００円でもいいやって思ったけど今度はサポートとか全くできる自信ないから怖くなって
＞３０００円で売れないままでもいいかな？って感じｗ
こんな事を後出しで平気でいう人間を信じられるかな
もし最初に買った人がいたら失礼過ぎるでしょ
まあ、そういうの分かってたから誰も買わなかったんだろうけど
作者は自分が最初に何を言ってたか思い出してみなよ
無料で情報公開してるサイトが、DirectXのバージョンが上がっても
サポートしないのはおかしい、だったら金取ってでもサポートしろって
そこまでの事を言ってんだよ？
あんたにそんなこと言う資格ないでしょ、あんたが一番どうしようもないクズじゃん

514 ：

>>512-513
最初はそう思ってたんだけどさｗ
やっぱり、サポートする自信ないんだよねｗ（前に何発言してようが今の本音はコレ）
金とってでもってやっぱりいざ金絡むと正直まったく自信ないね
まったく売れないってのもまた成長ないしｗ
まあ、やってみるしかないんじゃない？
ってことで自分の腕の無さも含めて最終的にこんな感じ？ｗ
ってとこ
自信は全くないけどサポートしていきたいってのもまた本音（でも自信ないｗ）
そんなとこ
とりあえず、タダにする気はないぐらい（責任をもつという意味で）

515 ：

>>513
>もし最初に買った人がいたら失礼過ぎるでしょ
１人でもいたら値段動かせないな
でも０人だからってのはあった

516 ：

ああ、やっぱりモノ作るってのは厳しいな
金の絡む絡まない関係無しにさ
たとえフリーでもエンジンを作るってこういう厳しさはあるんだろうね
途中でサポート止めちゃったり、サポートするって言ってた機能を
投げちゃったら金絡む絡まない関係無しに>>512-513よりもっとキツイこと言われるだろうね
たとえフリーでもメタ糞に言われるよね
そりゃそうだよね
エンジンなんて上に乗っける形で作ってる人はみんなパァになっちゃうもんね
うーん、やっぱり根性の無さというか人間としての根っこの弱さが
こういう部分ででるな
モノつくりを舐めてる感はたしかにあるな俺

517 ：

おおこわいこわい

518 ：

>>517
ホントだよ
みんなも出してみればわかるけどｗ
色々考えるんだ
結局、自分に１人２千も３千もとるほどサポートする力がないってことに気がつくんだ

519 ：

ゲームエンジンだけでなくゲームも売ったことがないみたいだなぁ。

520 ：

>>519
ないな
会社にいるときはリーダーが「リリースするよー」って言ったらホイホイいってソースうｐしただけだし
正直、サポート窓口だって俺じゃねぇし

521 ：

サポートはごめんなさい改善努力しますでも貰ったお金はお返しできませんを言う係

522 ：

正直ホントにプログラマかよってレベル

523 ：

もうそっとしとけよ。
性格悪いぞおめーら

524 ：

もう許してやれよ

525 ：

本人が言い訳と開き直りを繰り返さなきゃとっくに忘れられてると思うがねｗ

526 ：

各種ゲームエンジンの紹介と利用について【本日のスライド】
http://www.gamebusiness.jp/article.php?id=3510
AirPlay SDKというのは初めて聞いた。

527 ：

174と言い神奈川工科と言い黙って消えりゃいいのに何度も沸いて見苦しい言い訳吐いていくから叩かれるんだよ

528 ：

>>527
え？174＝神奈川工科でしょ

529 ：

もう別の話題しようぜ。
AirPlay SDKはC++で書けて、ライセンス要件もUnity並に甘いのが長所みたい。

530 ：

>>528
別人と思われる

531 ：

>>530
根拠は？

532 ：

あいつそもそもプログラム書けねえだろｗ

533 ：

↑
30のおっさんが大学生相手に顔真っ赤にしてるｗｗｗ
情けねえｗｗｗ

534 ：

大学生にもなって中学生に図星点かれてふぁびょり出したよこの人www

535 ：

あーあ、、、
自分で言ったら終わりなのに
スルーしきれず自分から被弾してどうするよ。

536 ：

>>529
どうしてもエアギターを弾いてる姿が浮かんでしまう

537 ：

いや、暇だったからつい。暇じゃないけど。
煽ったら何人ぐらい釣れるかな、と思って。
まあ、セーフかどうかと言うとスモーク炊いたからセーフぐらいだと思う。

538 ：

触るならレス番付けてくれ。
連鎖あぼーんできない

539 ：

>>537
マジで荒れるだけだからROMってくれ。
コテハン付けんのも何の意味あんの？

540 ：

何か成果物を出したあとじゃないとコテハンにいみはないよな

541 ：

>>539
気違いだから何言っても無駄だろ
NG登録してとにかく触れないのが吉

542 ：

ゲームエンジンなんて３ヶ月で作れるよ（ｷﾘ してたアホだろ相手にするな

543 ：

>>174
|､∧
|Дﾟ）　ｼﾞｰ　　　　　Download :1 (評価数0)
⊂）

　＼　│　／　　　　 　 　
　　／￣＼　　　　　 　 　
─（ ﾟ ∀ ﾟ ）∩∧ ∧∩　
∩ ∧ ∧∩＼（ ﾟ∀ﾟ）/　
ヽ（ ﾟ∀ﾟ ）/　｜　　　/
売れた！１本売れちゃった！

544 ：

おめでとうｗ

545 ：

おめでとー
しかしニッチというか最大のパイである一般人が近づきにくいジャンル
技術系ノウハウの販売は難しそうだなぁ

546 ：

単体で楽しめるようなデモで売ればいいと思うの

547 ：

技術系ノウハウは需要がある。
問題はその技術力の低さ。
どこにでもある初心者向けのコンテンツなぞ要らん。
ゲームエンジンアーキテクチャの本をベースにエンジンの実装を解説したコンテンツとかRTSの作り方とか、そういうコンテンツなら買う。

548 ：

いまなら海外のフリーのエンジンの日本語チュートリアル的感じなもの出すだけで売れると思う
エンジン自体の作り方って誰か興味あるんだろか？

549 ：

>>548
どのエンジンのチュートリアルが売れそう？

550 ：

メジャーなのはUDKやUnityじゃないかな。
あとはTorqueにIrrlicht、Ogreぐらいかな。

551 ：

書店のゲーム開発書籍ってWindowsやAndroidやiPhoneの本しか売ってないんだから
全部に対応してるUnityの本出したらバカ売れのはずなのにね

552 ：

>>550
Torqueは死んでるのかな？
http://www.gamebusiness.jp/article.php?id=2420
2010年11月14日(日) 02:05 Text by 土本学(Manabu Tsuchimoto)
ゲームエンジン「Torque」を提供するInstantActionは、通常業務を停止し、
事業の買い手を探すと発表しました。
InstantAction(元GarageGames)は、ゲームエンジンの「Torque」を提供するほか、
エンジンを使って開発されたゲームを誰もが公開する事のできる
ゲームサイト「InstantAction.com」を運営していました。

553 ：

調べてみた
ライセンスに関してはIrrlichtがzlibライセンス、OgreがMITライセンスとかいうので楽かな？
日本語の解説が多いのがIrrlichtで
Ogreは根性が必要だなｗ
Unityが統合開発環境っぽくてちょっと魅かれるけど
900万以上売り上げたら10万円ぐらいのUnityPro買えって書いてある
（まあ、900万円も売れたら10万円ぐらいどうでもいいと思うし
900万円売れること心配しなくてもいーかｗってことでこれもおおよそフリーといっしょか？）
日本語の解説はいくらかある
udkは商用は色々金かかるのかな？
ただし、一番情報量が多い
日本語でも英語でも
って感じ？

554 ：

そういやwebマネー残ってたっけ
買えたら買ってみるか

555 ：

webマネーって海外でも通用すんの？

556 ：

>>174
|､∧
|Дﾟ）　ｼﾞｰ　　　　　Download :2 (評価数0)
⊂）

　＼　│　／　　　　 　 　
　　／￣＼　　　　　 　 　
─（ ﾟ ∀ ﾟ ）∩∧ ∧∩　
∩ ∧ ∧∩＼（ ﾟ∀ﾟ）/　
ヽ（ ﾟ∀ﾟ ）/　｜　　　/
売れた！もう１本売れちゃった！

557 ：

おめでとうｗｗｗ

558 ：

>>552
Torqueは復活してソース付き$99販売やってる。

559 ：

>>174なんてどうでもいいから、いちいち貼るなよUZEEEEEE

560 ：

>>552
死ぬどころか新社屋建ててるよ
ゲームマスコミにはきちんとその後も報道して欲しいよなぁ
http://www.garagegames.com/

561 ：

300円くらいにしたほうがもっと勢いよく売れて儲かるんじゃね？

562 ：

HTML5使用のゲームエンジンだって。
http://www.gamebusiness.jp/article.php?id=3544
ChromeでRPGサンプルを試してみたら、右にずっと移動したままになった。

563 ：

>>556
一本目を自分で買ったら馬鹿が1匹釣れたんだなｗ

564 ：

>>563
折角買ってくれた人になんてこというんだ
自作自演するぐらいなら３０００円や１５００円のときにやってるわ

565 ：

torqueも無料で使えるものがあればいいのにね。
http://game.watch.impress.co.jp/docs/news/20110307_431667.html
たしかに、他のgame engineやrendering engineのスレと比べても伸びが違う。

566 ：

お前らが常々馬鹿にするツクラーでさえ数千円でツクール買ってるのに。この値段でも無料が欲しいとかどんだけだよwww

567 ：

散々ツクールをバカにしてる奴いるけど、あれは立派なエンジンだぞ。
データ駆動、スクリプトでいろいろと弄れるし。
バカにしまくってもアレ以上の物が出てこないのが完成度の高さを物語っている。
騒いでいるツクラーはスクリプトが理解できない人種なんだろうけど。

568 ：

566が三人目になってくれるってよかったね♪

569 ：

ここにはなんちゃってプログラマしか居ないと言うことだな

570 ：

なんちゃってで何が悪い・・・！

571 ：

ゲームエンジンもミドルウェアよりからFlashのような統合環境。
そしてツクル系の専用ツールまではばひろいからな。
個人的にはミドルウェアよりのあまり統合されてない統合環境がいいなあ。
統合されすぎてると一部自前とかが妙にやりにくかったり、
環境用のスクリプトで書き直さなきゃいけなかったりするしなあ。

572 ：

Flashがゲームエンジンって発想は初めて。

573 ：

Flashがゲームエンジンじゃなくて、
Flashもゲームエンジンもミドルウェアってことだろ

574 ：

CE3の無料開発キットが夏に出るってよ
CrytekのCEOであるYerli氏によれば、この開発キットは完全版であり
C++言語、Shaderコード、Crysis 2のサンプルコード、スクリプトのサンプル、
改善されたFlowGraphなど多数の機能を実装している。
また、キットを使用し作られた素晴らしいゲームなら開発のサポートもしていきたいと語っています。
だとさ。これでおまえらも無料なのに最新エンジンを用いて
ハイクオリティなげーム作りができるようになったな。

575 ：

すでにいくつかゲームエンジンは無料化になったが使いこなしている人が少ない件

576 ：

結局素晴らしいゲームエンジンがあっても、それに必要なコンテンツが作れないから
諦めている人が多数と思われる
結局最後に勝つのは絵を書ける奴、音楽作れる奴。

577 ：

>>575
3Dモデラーなどの周辺ツールが弱いせいもあるんだろうね
海外ツールをカードで買うのは抵抗あるしな
それに分野ごとに専門でやってる人ばかりでトータルでゲーム作りたいって人は少ない気がする

578 ：

Unity：大幅機能制限版のインディーズ向けを無料にして客引き
UDK：C++使えないバージョンを無料にして客引き
業界最重最先端のCryEngineが無制限無償化するとはたまげたなぁ

579 ：

こんなもんを無料配布されたら言い訳出来なくなるじゃないか

580 ：

http://www.crymod.com/
これのことか。AutodeskのＣＧソフトが必須そうだな。

581 ：

>>578
無制限無償化なんて書いてあるっけ？
あくまで無料版（機能制限がどんだけか知らないけど）を出すよって話じゃねーの？

582 ：

>>581
完全版だよ
UnityやUDKみたいに頒布が無償じゃない代わりに

583 ：

CryEngineって重いイメージがあるけどどうなのかなあ
日本のユーザーは古いPCのオンボでPCゲーやろうとするから。

584 ：

crysis2自体はGTX460程度でも十分動くから敷居は高くない
ただいくらなんでも今時のPCゲー遊ぶのに古いPCのオンボじゃムリがある
古いPCのオンボだと、軽さを売りに広く客を集めてるチョンゲを遊ぶのもキツイのでは？

585 ：

>>582
頒布が無償じゃないってどういうこと？

586 ：

>>585
つttp://www.4gamer.net/games/032/G003263/20110425026/
下の方に書いてある

587 ：

販売するには〜
って書いてあるから非営利目的ならライセンスいらないとも思えるけどどうなんだろ

588 ：

そりゃ要らないでしょ

589 ：

それだとUDKだって商用利用はライセンスいるような。
間違ってたらごめん。

590 ：

>>589
UDKは売上5万ドルまで無許諾でおｋ。それ以上は年99ドル＋ロイヤリティか2500ドル買い切りの選択制
UnityはFree版もPro版もロイヤリティフリーの買い切りライセンス
CryEngineも教育機関向けのフルバージョン無償ライセンスが既にある

591 ：

もしかしてCryEngine3で本格的な超エロいエロゲ作ったら
国内外でバカ売れするんじゃね？

592 ：

3DCGつったってアニメーションもあるぞ。
絵書けても今度は演劇かダンス出来ないと駄目って言うね。
結局はRPGツクールが最強だった説。

593 ：

教育機関向けって関係ない人間にとっては正直止めて欲しいわ
それにそう言うのって販売とか駄目なんでしょ？

594 ：

海外は大学生が起業することも珍しくないし
学生のうちに囲い込んでおこうという"囲い込み戦略"なんだろうか

595 ：

>>592
けいおん
http://www.youtube.com/watch?v=gHFehuGspNA
小倉優子
http://www.nicovideo.jp/watch/sm5531202
この調子でやればいいんじゃねの

596 ：

まだ神奈川をNGに入れてない奴いるのか…

597 ：

>>578
開発ツールだけ無償でばらまいて、完成した製品からはロイヤリティを採る普通のビジネスモデルなんじゃ？

598 ：

>>590
ttp://udn.epicgames.com/Three/DevelopmentKitFAQJP.html
ここ見る限りだと
「販売するときは$99払ってね。もし売上$50000超えたらロイヤリティも払ってね。」
ってことだと思うんだけど。。。

599 ：

http://www.4gamer.net/games/032/G003263/20110428001/

600 ：

ｳﾜｧｧ-----｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡-----ﾝ!!!!

601 ：

どうしたの
泣かないで

602 ：

ホームページとブログどこがいいの？

603 ：

ヤフー

604 ：

ありがとう
でもヤフーやだ。ごめん

605 ：

seleneスレどこいった？

606 ：

seleneの開発者が消息不明になったので終了。

607 ：

マジ！？

608 ：

悲しいね

609 ：

消息不明になったのか。
ブログ復活してるみたいだけど。

610 ：

復活してたな

611 ：

ついでにスレも復活させて・・・

612 ：

自分で立てればいーじゃないのさ

613 ：

トライアングルのメッシュをトライアングル・ストリップ化するコードない？
ライセンスが緩くてそのまま自分のコードに取り込める奴
自分で作るのだるい...

614 ：

D3DXのMesh関数で変換が手っ取り早い。
どうせランタイムで変換なんてしないんだし。

615 ：

すまないLinuxでOpenGLなんだ。
やりたいのはメタセコイアのエクスポーターで
メッシュをトライアングルストリップ化して出力して
Linuxで読み込んでOpeｎGLで表示することなんだ。
さらに将来的にはAndroidで表示したい。

616 ：

Androidならunityで今日にでも表示できる

617 ：

>>616
そんなことは聞いてない

618 ：

>>615
そうじゃなくて
ターゲット環境でアプリ実行時にやる必要のない＝事前計算させておけるものなんだから
メタセコ使ってるならWindows上で最適化処理したっていいじゃないって言われてるんだよ

619 ：

>>618
そんなことは１００も承知。
DirectXに依存したトライアングル・ストリッパーではなく
他のライブラリに依存しないポータブルなソースが欲しい

620 ：

じゃぁNvStrip使うか自分で作れよ。
大して難しい処理じゃないだろ。

621 ：

>>619
ググって数秒でソースコード付き解説がヒットするんだが。。。そういうのじゃ不満ってことだろ？
お気に召すものがネット上で見つけられないならさっさと自作したほうが早いんじゃないか

622 ：

TriStripper使うことにしたからもういいです。
ありがとうございました。何の役にも立たないクソスレだな

623 ：

Tootleの出力のほうが遥かにマシだが、まぁどうしても組み込みたい厨にはお似合いか

624 ：

お前がそう思うんならそうなんだろ

625 ：

正直Stripなんて何年も使ってないから今さらどうでもいいというか･･･

626 ：

最近の流れは、ツンデレから、ツンケンみたいな感じなのか
おじさんは付いてくのが大変だよ。

627 ：

単に素でアホなだけだと思うｗ

628 ：

俺には汚物にしかみえない。

629 ：

tuedaさん？

630 ：

OpenGL試したけど単独じゃ音声どころかJpeg PNGも読み込めないのか

631 ：

DirectXのほうがイイ。

632 ：

よろしい、ならばLinuxにDirectXを移植してください

633 ：

Linux使ってるなら無いものは自分で作れだろｗｗｗ

634 ：

Linuxだったらpng読込はlibpngとかあるでしょ（jpgもライブラリあると思うけど）

635 ：

クソみたいなライブラリだけどなlibpng

636 ：

自作すりゃいいじゃん。
リーダーなら１日もかからんだろ。

637 ：

ddsでいいじゃん、、、
圧縮したけりゃzlibつかえばいいんだし

638 ：

そこでdevilですよ

639 ：

>>637
確かにddsのレイアウトならARGB情報をバイト配列で抜き出してOpenGLにロードできる筈だよね

640 ：

さみしい

641 ：

どした

642 ：

さみしくなんかないよ

643 ：

友達いなくて
ありがとう元気でたよ
がんばる

644 ：

お前がRば椅子が１つ空く。R。

645 ：

Unityスレで紹介されてたshiva3D
http://www.stonetrip.com/
C++を使えるのとライセンスがゆるいのが良さそう。

646 ：

>>645
繋がらん！

647 ：

>>それって、Airじゃなかった？＿

648 ：

寂しいならbotでも作ってみろ。
俺もたまに会話してる

649 ：

AI作る

650 ：

ところで九月までに自作エンジン完成させるなどと豪語していた連中どこいった？

651 ：

ここにいるよ

652 ：

あと三ヶ月なんだし。β版くらいにはなったのか？

653 ：

全然なってないよ。9月にβだよ

654 ：

ビシャモンガが既にあるけどそれはまぁそれとしてエフェクトエディタはぽちぽち作ってるよ。

655 ：

Irrlichtを拡張するとかツールを作るとか、そういう方向で行った方が
現実的だと思うけどなあ。

656 ：

ここに現実などないから心配すんな

657 ：

Androidのゲームエンジンとか凄い需要があると思うけどなあ
誰か作らない？　スーパマリオが簡単に作れるレベルでいい。

658 ：

え？そんなの作っても公開しないよ？
自分で使うし。
儲からなくなったら出してもいいけど。

659 ：

公開しても誰も使えないと思う

660 ：

ぐだぐだ言ってないで俺様の為に九月までに使えるエンジン作れよ奴隷共

661 ：

MAC用のバイナリを用意しているのに
いざMACで起動したら「Fuckintosh」ってエラー出して即落ちるようにしたら
さすがに苦情来た大学時代

662 ：

寄付してよー

663 ：

>>657
javaやれよ

664 ：

あ

665 ：

フォローして
ttps://twitter.com/#!/usr5

666 ：

このｽﾚの初期に偉そうにしったかしていた人々は今はどこへ

667 ：

偉そうにしったかしていた人々はいったい

668 ：

偉そうにしったかしていた人々はR

669 ：

もうみんなunityやってるよ

670 ：

今遺伝的アルゴリズム使って敵キャラ作ってんだけど今はステータスとか決めるのにデフォなの？

671 ：

どうだろうね、目的で使い分けること多いんでない？
GA、PSOも使うしファジィも使うし

672 ：

流行っていそうな単語を会話に混ぜるのがここの流儀w

673 ：

>>672
GAもPSOにGemsに載ってるだろ
「流行っていそう」じゃなくて既に「流行ってる」もしくは「流行った」単語だ

674 ：

流行っていそうというか最適化の部分だから昔からある話
むしろ設計者のパラメータ設定や評価基準で性能が決まるから
目的に沿った最適化手法で実装しやすければそれを用いるのがベターって言いたかった

675 ：

定期知ったか乙

676 ：

掲示板なんて個々の実力やスキルレベルは見えなから御託の並べた方が勝ち。

677 ：

知ってた。

678 ：

僕の考えたすごいゲームエンジンは完成したのか？おまえら

679 ：

既存のゲームエンジンの仕様すら理解していませんでした！
って認識でだいたいあってるんじゃないかな？
大人しくなったのはみんなにボコボコ叩かれて
既存のエンジンちょっとは見てみる気になって個人でこれ以上のもん作るの不可能じゃね？
って気がついたんじゃん？（笑）

680 ：

実力のある奴がこんなスレに顔を出さないだろｗ

681 ：

>>578
頭悪すぎワロタ
CryEngine3のSDKもUDKと同じようにソースまでアクセスできない制限はあるに決まってるだろ
Crysis2用のSDK触れば分かるけどCryEngine2のときからグラフィック強化しただけで実質マイナーチェンジしただけ
FPS以外のゲームはかなり作りにくい(FPSだけにしか使えない機能ばかり)、UDKに比べてAI制御も古すぎ
アニメーションや物理関連は独自すぎて制限も多くクロス機能も無いに近い

682 ：

くそスレ浮上しまーす

683 ：

ゲームエンジンの話でグラフィックの綺麗さを語る人がいるけど、
あれってテクスチャの品質(実写から取り込んだ)とかモデルが精細に作ってあるかとは違うんですか？

684 ：

GPUが無限に高性能であればそうだろうがな。

685 ：

>>683
俺はシェーダー、映り込み、影などに注目する。

686 ：

>>683
なんかシェフにむかって素材が全てでお前の能力は関係ないと言わんばかりだな

687 ：

？

688 ：

テクスチャ１枚やポリゴン１枚だけしか使わないわけでもないだろ。
大量のテクスチャ／メッシュを、プログラム内でメモリ効率的に管理して、
意のままにオーバーヘッド最小で描画時に適用できるプログラムを組むことが初歩。

689 ：

ノベルゲームエンジンについて参考になりそうなソースコードを探してるんですが
KIRIKIRIみたいなオープンソースエンジンがあれば教えて下さい

690 ：

吉里吉里だとなにか問題があるの？

691 ：

同じ機能でもいろんな実装方法を参考にしたいなあと思った
他意はありません。

692 ：

>>689
ぐぐった？

693 ：

http://www.dotup.org/uploda/www.dotup.org1916786.png
lol

694 ：

そろそろ９月だな、お前ら口だけじゃなかったことを証明して見せてくれよ？

695 ：

やめてゲーム作ろうとして作ってないけど、待ってる人いるの？
いたら再開しようかな

696 ：

少しだけできたわ。
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up62190.zip
htmlをブラウザにドラッグしてみてくれ。

697 ：

ライブラリィを作っているけど9月までにまとめるのは無理だった。
γ版・ドキュメント無しなくらいの状況。

698 ：

おい、なんでLuminousのスレが立ってないんだ？

699 ：

>>698
お前が立てるのを待ってるからだよ。

700 ：

まだ全然未完成だからじゃないのかｗ

701 ：

3Dゲームエンジンのどれがどうとか、特徴みたいなのがまとめられてるページみたいなのってある？
何を使えばいいのかわからない
つか教えてくれ

702 ：

http://en.wikipedia.org/wiki/List_of_game_engines

703 ：

>>701
>>4
>>7

704 ：

9月中にエフェクトエンジンだすわ

705 ：

今風の３Dゲームと同じ見栄えを出すのに必要な技術と参考書を教えてください。
教えてくれたら実装してフリーで公開してもいいです。

706 ：

>>705
GPU Pro

707 ：

よく考えたらWinRTベースのゲームってすべてDirectX11になるのか

708 ：

それ以前に、winRTって、7やVISTAでも利用できるようになるのだろうか？

709 ：

WinRTはMetro絡むし無理っしょー
でもDirect2DあたりのマイナーチェンジはVistaまで
バックポートしてくれてもイイと思うんだがよー

710 ：

winRTとmetroは直接関係ないんじゃね？
winRTって、要するにちゃんとクラス構造になってる、言ってみればwindowsAPIの新バージョンでしょ？
だから、winRT用のDLLをVISTAや7に持っていけば使えるような気もするんだけどなー。

711 ：

SSAOのチュートリアルないですか？
Wikipediaを見ましたが断片的な情報ばっかりで。。。
きちんと全部解説した資料を教えてください。
英語でもいいです

712 ：

>>711
ttp://d.hatena.ne.jp/shuichi_h/20100318/1268924159
自分はここを参考に実装したよー。
ttp://developer.download.nvidia.com/presentations/2008/GDC/GDC08_Ambient_Occlusion.pdf
細かな理論はこれとかかな。

713 ：

>>712の資料、いまいちわからん。
9枚目のVは視線ベクトル、Nは物体表面の法線ベクトルだと思うのだけど、
r_left,h_left,r_right,h_rightは何を意味してるのでしょうか？
デプスバッファからこれらを得ようとしてると思ったんだけどちがう？
10枚目のH(Θi)は、h_iのことでいいのかな？

714 ：

テキストにルビをふれるゲームエンジンには
どんなものがありますか？

715 ：

吉里吉里

716 ：

構造(こうぞう)　　じゃダメなのか?

717 ：

Unity見ていて思ったんだけど時代はdeffered shadingなのか？

718 ：

「シーングラフだけ」なライブラリってないですか？
OpenSceneGraphが名前に反して全部入りでとにかく大きすぎる。
シーンとレンダリングだけやってくれればいいです。下はOpenGLで。
シェーダー周りの抽象化とレンダリング方式がしりたいです。

719 ：

DeltaEngineのβ版がそろそろリリースされるころだ
本当に開発が進んでいるのか不安で待ち遠しかったが楽しみだ
とりあえず触ってみないかな

720 ：

>>713
＞r_left,h_left,r_right,h_rightは何を意味してるのでしょうか？
r_はP点からの半径距離で、h_はP点の接平面からの距離だね。
＞デプスバッファからこれらを得ようとしてると思ったんだけどちがう？
それであってる。
ただ、「in the normal direction」とあるように、
法線の向いている側に限定することに注意だね。
＞10枚目のH(Θi)は、h_iのことでいいのかな？
その通り。
この資料、数式の記号説明が不十分だったり、
統一的に表記されていなかったりで少し読みにくいね･･･

721 ：

Torque3D本体の値段が100$だったのが99$になってるのは
リソースを切り離して小売にしたから？
買ってみようかな

722 ：

シェーダーで質問があります。
例えばバーテックス・シェーダーでライティングやスキニングを共通部分としてエンジンが提供し、
マテリアルの係数を計算するところだけデザイナーさんが自由に取り替えられるようにしたいのですが、
どうすればいいでしょうか？
エンジン側提供のシェーダーに続いてデザイナー作成のシェーダーが走ればいいのですが...

723 ：

それをここで聞くのかｗ

724 ：

え、まさにここですよね？？？

725 ：

どうすればいいでしょうか、って言われてもな・・・こちらこそどうしましょうというか。
とりあえず要求通りに作って使わせて感想聞いて修正してまた使わせて〜の繰り返しでひとつ

726 ：

そういう意味ではない。
シェーダーのmain()はエンジンが書くのかデザイナーが書くのか？
エンジン側がmain()を提供しエンジンの定めた書式でデザイナーが関数を書いてリンクするのが妥当に思えるけど...
みんなどうしてるのかと。

727 ：

したいようにしろよｗ

728 ：

何とかシェーダーをエンジンとは独立して汎用性のある形で再利用できないかなと

729 ：

無理じゃない？
頂点のフォーマットまで変わるでしょ？
これを外部に出すとプログラムは一体何をしてるの？ってほど外側の人間からはなんのうまみもないライブラリになる

730 ：

>>726
それは個々の状況に因るからなんとも。例えば
記述させられる側にどこまで要求していいのか
ターゲット上での最適化はどこまで要求されるのか
最後にどこの誰がケツを拭く羽目になるのか
Rひり出した犯人と擦り合わせできる状況がその時あるのか
個人的には画を作る側がシェーダー言語を書くという状況にはなくて
アーチストなオペレーターの皆さんがグチャグチャと組み上げるものは
ツリーやグラフ構造状のブツ。既製ツールの仕様の下での画作りの結果が
ターゲット上で素直に反映されることを要求されるという感じ。
中間フォーマット経由でターゲット上で走るレンダラ依存の構成に変換。
ターゲット上の簡易エディタでアーチストなヂレクションするやつが
グチャグチャ調整してドヤエーナイカとご満悦。

731 ：

エーナイカ→エーヤナイカ
人が沢山絡むと色々ややこしくなってけったいなものをこさえるハメになるから全然嬉しくないな
気晴らしに夏の即売会でゲーム配ってみたんだがなかなか疲れたけど楽しかった
趣味ってのは他人に配慮なんかしないでガリガリ書きまくっても平気だから爽快感が違うな

732 ：

天才あらわる
どんなゲーム配布したんですか？

733 ：

どう見ても馬鹿の典型だろ・・・

734 ：

まともな日本語が書けない人は頭悪いってばっちゃが言ってた

735 ：

>>732
プレイヤーは劉備で、張飛を性奴隷としてRするゲームです。
３Dで表現されたリアルな張飛のRをタッチパネルで責めます。

736 ：

まぁ俺なんだが、R-18まではあってるよ・・・

737 ：

おにゃのこも自分で描いたの？

738 ：

キャラクターをいきなりフレームバッファーに描かずに
いったん別に確保したテクスチャーに描画したあと
板ポリとして描く技法を考えついたんだけどどうだろう？
メリット無いかな？

739 ：

Not required technique is not useful.
必要性の欠如した技術はまず浸透しない
The `Video Texture' has been implemented by requirement want to render the in-game TV.
VideoTextureはゲーム内TVを実現したい必要性に駆られて実装された。
>>738 is too stupid.
>>738バカ杉

740 ：

なんか変なのが湧いてきましたね...

741 ：

作ってる作ってる詐欺とうそ乙なスレでお前は何を言ってるんだ（AA略
もう１０月だなw

742 ：

浸透させるために技術開発してるわけじゃないんだOK？

743 ：

それより最新のテクノロジーを詰め込んだオープンソースのレンダリングエンジンを作らないか？

744 ：

無料でという意味ならありえんわ
最新の技術を収集蓄積するコストは誰が払ってくれるんだ？

745 ：

ヒント：
ID:DbR5pb/wの言う最新のテクノロジーというのはせいぜい>>738程度のもの

746 ：

ｗｗｗｗｗｗｗｗｗｗｗｗ
ワロタ
Ｖｉｄｅｏテクスチャなんて最新でもなんでもない件
大昔からあるし、コードも公開してるところあるじゃないｗ

747 ：

そんなにたいしたコストはかからないだろ。
今は書籍も出てるしNVIDIAのHPとかにも情報はたくさんある
それらを読んでちゃちゃっと実装すればいいだけの話

748 ：

じゃあ本読んで出直して来い
ほれ Game_Design_eBooks_Pack.4621536.TPB.torrent

749 ：

>>747
書籍も無料で手に入れるんですねわかります。
ごちゃごちゃ言うならまずお前が何か作ってうｐれよ。
ちゃちゃっとやってくれｗｗｗｗｗｗｗｗｗｗ

750 ：

ID:DbR5pb/wには>>740みたいな台詞は似合わないと思うよ。鏡を見てほしい

751 ：

能力も意欲もある人間の人間の足を引っ張る>>749>>750みたいなカスがいなくなるといいなあ

752 ：

痛いな

753 ：

>>751
他人をカス呼ばわりするカスよりはまし

754 ：

>>737
同僚にテストプレイさせたらご褒美シーンに到達するやクリーチャーをしげしげと眺めてね
憐憫の眼差しで俺を見るや「とりあえずこの仮データ差し替えようか・・・」ってつぶやいたよ
仮じゃないんだけどって言いかけたけど素直にお言葉に甘えさせてもらったよ

755 ：

良い同僚をお持ちでうらやましいw

756 ：

havokも10ドル以下なら商用無料なのかすげえな

757 ：

でもWindows dll onlyだから使いづらい

758 ：

例によって最初の妄想乙だけだったな。
このまま冬眠か。

759 ：

BISHAMONってどうなんだ？
エフェクトエンジンは他にないみたいだが。

760 ：

他にないとかどんだけ情弱なんだよ
上見りゃいくらでもあるよ。
ゲームエンジンに組み込んでるものもあるし。
あんなに安価ではないがな。

761 ：

BISHAMON以上なんてまず払えないだろ。
それともBISHAMONが良心的すぎるのかな、、、

762 ：

BISHAMON以上が払えないならまずPC買えないだろjk…
冗談は置いといて学生じゃなく社会人でBISHAMONが高いと思う感覚じゃ一生フリーソフトでゲーム作ることになると思うぞ

763 ：

ツールとSDKが別売りでSDKの方が高いっつーのがなぁ

764 ：

変わったライセンス形態だな
メインはエンジン側か
エフェクト編集は使いやすいの？
他からコンバータで持ってくるからｲﾗﾈ みたいにできるのかな

765 ：

SDKは1個あれば足りるけど、ツールはデザイナーの人数分買えってことだろう。

766 ：

エンジンと編集ツールそれぞれで金を取りたいってのはまあわかる
そうなら、それぞれ名前を変えて別製品にするところだろ、と
謎は解けた

767 ：

そろそろツールのお披露目しようかと思う。

768 ：

悪い、少しだけ宣伝
http://www.vector.co.jp/soft/other/wince/se493776.html

769 ：

>>768
宣伝するなら特徴とか他のツールと比べた優位点とかちゃんと宣伝していってよｗ

770 ：

カシオペアってなんだ？

771 ：

オロチって個人販売もしてほしい
会社に問い合わせたら法人のみですって冷たくされた

772 ：

冷たくするのはヒドいね･･･

773 ：

べ、べつにあんたなんかとライセンス契約したくないんだからねっ！法人じゃなきゃダメなんだからっ！！
こうですか？

774 ：

>>771
マッチロックが頑張ってるだけでシリコンスタジオは消極的
BISHAMONがバカ売れすればOROCHIも出るかも知れんが…

775 ：

BISHAMONは値段が結構するわりにはエフェクトエディタとしてはいまいちなんだよな

776 ：

もっと英語を勉強するべきなんだろうなあ。
会話は日本人相手でも少ないから、読み書きだけ勉強するか。

777 ：

ワイが聞いた情報によると、もうじき中国はバブルがはじけて昔の貧乏な中国に戻るらしいで
もう経済は破綻してて、取り戻すのは無理なんだそうや

その世界ではごっつい有名な政府関係者筋から聞いた確かな情報やで
まあお前ら頭の良い連中には、今さらなくらいのネタやな、
お前らからすればもう常識的なくらいの知識やろ？

778 ：

そろそろ１年経つのか早いな。
ぼくの考えた凄いゲームエンジンは結局一個も登場しなかったな

779 ：

BISHAMONみたいに一つのことだけ特化したライブラリでも、作るのに手間がかかるだろうからなあ。
まあ、次スレからはゲームエンジン全般のスレッドにすればいいんじゃないか。
このあたりとかテンプレに入れよう。
http://devmaster.net/devdb/engines

780 ：

effekseerなんてのもあるんだな

781 ：

ランタイムが組み込みやすくていいね。

782 ：

そろそろ公開したいがここはレベル高すぎて叩かれそうでなぁ、、、

783 ：

お前にとって２ｃｈで公開する意味って何？
１０年前ならまだしも今なら他にいくらでも方法あるじゃない。
ここが良いなら止めないけど。

784 ：

>>783
単純にゲーム製作に興味があって、なおかついろいろな意見を聞ける場所を他に知らないというか・・・。
自分でHP作って公開したところで宣伝が必要ですし全てを賄うゲームエンジンではなく、
BISHAMONっぽいエフェクトエディタを目指して作っていたものなので・・・。
ツールにしろエンジンにしろまずは多数の人に触ってもらってダメだしをしてもらわないと
使いにくい独りよがりなものになってしまうんですよねぇ・・・。

785 ：

おー使ってみたい

786 ：

>>784
それこそfacebookやtwitterで公開すればいいのに
2chで公開したソフトは一生2chから逃れられなくなる

787 ：

facebookは実名プレイなのが・・・
公開方法より宣伝と試用数がそれなりに行きそうな方法を考えよう・・・。

788 ：

それ悩みどころだよね。
HP作って、そこを2chで宣伝してみてはどうかね？
関心を持たれなかったら、そっぽ向かれて、それまでのことで終わるし、
意見があればスレで建設的な意見も出るだろう。

789 ：

まあ地道に続ければどうとでもなるよ。
商品として売れるぐらいになるまで頑張れ。

790 ：

>>787
別にみんな実名だからいいんじゃね？＞Facebook
Twitterでも実名の人いるし、実名だと叩く連中がいるのは2chだけだよｗ

791 ：

>>790
実名自体はどうでもいいんだ・・・
会社バレを避けたい。

792 ：

>>791
Freenet上で配布とか。

793 ：

Facebookで実名っぽい名前使えば良いんじゃない？
もしくはわざと誤変換したまま気がつかないとか。
俺は非常に特殊な名前だから、一文字誤変換させた名前で一般名に変えてる。
熊飼→熊谷ってな風に。

794 ：

検索エンジンGoogleで
インターネットテレビ 朝鮮総連 少頭劣一族 電気 人質
又は
インターネットテレビ 朝鮮総連 少頭劣一族 電気 波動砲
又は
インターネットテレビ 朝鮮総連 少頭劣一族 自民党 カニバ（又は命令）
を検索せよ。

795 ：

>>788の案で公開してみるわ。
チュートリアルとサンプル作成が間に合ったら土日に出すぜ。

796 ：

>>795
おい、土曜日だぞ

797 ：

俺たちの土日はまだ始まったばかりだ！

798 ：

>>796
サンプルとチュートリアルまだだけど他のスレで出しちゃったし出すわ。
ttp://amayuri.dojin.com/download/rainlily_beta_0100.zip

799 ：

>>798
なかなか良さげな感じがする
こういうパーティクルエディタって少し前から流行ってきてるよね

800 ：

イイねぇ。

801 ：

>798
すごくいいよ。
こういうの欲しがってる人
結構いるんじゃないかな？
俺は別エンジン買っちまったって同じようなＦＸツールも買ってしまったけど。
これがフリーで公開されるんならありだと思う。
エフェクトって作るの手間だしね。

802 ：

>>798
ちょ、あと1か月速く公開してよ
これがあったらBISHAMON買ってねえよ…

803 ：

>>802
すまん、１ヶ月前の公開は流石にムリだｗ
まだ機能的にも足りてないし操作マニュアルすらない状態だしなぁ。
でもBISHAMON持ってるならものすんごいエフェクト作れるじゃん！

804 ：

Seleneの中の人だよね？

805 ：

冬コミまであとｘｘ日！！

806 ：

VitaのSDKか個人でも手に入るらしいぞ
オープンソースのゲームエンジン作ろうぜ

807 ：

>>806
今は実績ないとsdkテスターに選ばれない
春には一般公開したいらしいけど

808 ：

>>806
あとクローズドベータだから、オープンソースのエンジンは今作っても公開したらアウトじゃないかな

809 ：

Unity本を読んだんだが、これぐらいなら自分で作れそうじゃないか？
難しいことは何もやってない。誰かLinux用でびしっと１本頼むわ

810 ：

Linux用にも色々あるが？

811 ：

pss sdkのテスター選考緩くなったみたい。
週末はTwitterで国内外の色々な人から当選報告が出てた。
まだvitaでは動かないらしいです。
自分も休み明けからさわりはじめてみます。

812 ：

英語わからなくても使える物理エンジンってあったら教えて

813 ：

ソースコードが読めるんなら、全部オッケーじゃないのかｗ
それ以前にソースコートって大抵英語のような…

814 ：

>811
あれ俺のところにはまだ当選メール来てないけど
困るなあちゃんと配送してくれないと(´；ω；`)

815 ：

>>814
フォーラムでは2Dスプライトを簡単に扱いたいみたいな話があちこちであがってるので、ほぼまともにGL触ったことないと思われる人ま選ばれてると思う。だから審査は厳しくないはず。気長に待てばよろし。
無理矢理このスレに絡めると、2Dゲームエンジンは需要あり

816 ：

訂正
>人ま
人まで

817 ：

OpenGLを素で扱うということは、ゲームエンジンよりもライブラリに近い感じなのかな。
Unityが使えるという噂もあったけど、そんなこともなかったようだ。

818 ：

OpenGLを素で使うといことは三角形や線を塗りつぶして行く感覚だよ。

819 ：

>>817
ちょこっとだけラップされてる。
既存コードから流用しにくくなった気もするが、新規コードを起こす分には平気。外部の既存エンジンに頼るつもりの人は南無。
あとプログラマブルシェーダが使えるには使えるんだが、そっちかよ！って突っ込むと思う。

820 ：

俺達でUnityを丸パクリしたゲームエンジンをC#で作らないか！！
PSS用にどうよ？

821 ：

>>817
Wikipediaに書いてあったが何とかライセンスを結ぶとUnity for VITAが使えるらしいぞ。スクエニが使っているらしい
でもそれはPSSとは何の関係もない話。あくまでUnityのVita用バイナリ
PSSで使おうと思ったら全部C#で書かれたフリーのゲームエンジンが必要
.Net/XNA/WindowsようはいくつかあるけどPSSで動くように移植するのは手間か？
どうせなら俺達で１から作らないか！　Unityみたいなの！！

822 ：

>>820
sdk内に3D物理関係の機能が無い。
こんなんマネージコードで実装して実用レベルになるんだろうか。

823 ：

ならないんじゃね、と思うがよくわからん
NVIDIAも絡んでるみたいだし、そのうちPhysiXが使えるようになると期待
PSSがこの先生きのこるには

824 ：

至れり尽くせりにするとアマチュアとの差がなくなるからパフォーマンスが出ないように

825 ：

クタたんちーーーっす
まともなシステムを提供できないハード屋の言い訳だったよな結局

826 ：

シェーダーで使うパラメーターって
直接Uniform変数としてセットするか
一回シーングラフの要素にしてからUniform変数にセットするのか
どちらでしょうか。具体的には
(1)SetUniform("DiffuseColor", 0xff7c7c7c)みたいな形か
Materil.DiffuseColorみたいなクラスをシーングラフに作って
(2)BindUniform(Material, "DiffuseColor");
みたいな形でしょうか

827 ：

>>826
何の話か全くわからん。

828 ：

わかりにくくてすみません
ある描画ライブラリの仕様が(1)のSetUniform()形式です
シーングラフのオブジェクトのパラメーターを自分でGet()してSet()してね毎ターン、
というスタンスなのですが、どうもこれが気に入らない。
エンジンの人間ではなくゲーム本体を作っている人間が
毎フレームシェーダーに送る定数をGet()してSet()しなければならないのがまずおかしい。
シーンの描画は最終的には
Graphics3D.Render (scene);
のように１行で描画できるべきで、シーンの構築が不完全と言わざるを得ない。

829 ：

具体的には、
1) シーンのノードは自由に継承してユーザー独自のノードを作れる
2) そのパラメーターの名前は自由に決められる
3) そのパラメーターをシェーダーに送るように設定できる(bind)
4) それらのパラメーターをシーン全体で一発更新できる(refresh)
という仕様に変更しようと思うのですが、元の仕様とは大分変えないと実装できなくて
世の中の人間はもしかして元の仕様のほうがいいのか、私の考えが間違えているのかとか
いろいろ悩んでます。
やっぱりシーンの構築が終わったらRender(scene)一発で描画できたほうがいいですよね？

830 ：

過疎スレですが質問させて下さい
シャドーマップを作る時のZレンダリングのパスでは
設定されているシェーダーではなく共通のシャドーマップ生成シェーダーを使うと思うのですが、
これは例えばMeshオブジェクトには複数のシェーダーをセットしてパスによって切り替えるのでしょうか
それとも設定されたシェーダーは無視して強制的にこのシェーダーを使って描画しろみたいな仕組みがあるのでしょうか

831 ：

SDL1.3っていつ出す予定なんだろ

832 ：

SFMLに移った方が良いかもね

833 ：

SDL1.3からライセンス変わるのか

834 ：

>>832でSFMLってのを初めて知った。

835 ：

そんな事より>>830を誰か頼む
一応今の予定では強制シェーダー描画モードを搭載する予定だ

836 ：

関連スレのタスクシステム総合スレが死んだな...
http://logsoku.com/thread/toro.2ch.net/gamedev/1285930493/

837 ：

ここも過疎スレ
誰かゲームエンジン作れよう

838 ：

タスクシステムが逝ったか・・・。
まあ、ゲーム製作スレ四天王の中でも最弱な面汚しだからな！

839 ：

残ってる四天王教えてくれ

840 ：

最強
　　　＿＿(^^)　＜ペイピッポォ
　　／＿＿　＼　
　　|　|　　 |　　|
　 （＿）　（＿＿）

841 ：

エターナル４天王
・ゲームエンジン総合
・タスクシステム総合
・Unity総合
・ゲーム制作メンバー募集

842 ：

>>837
エンジンなら腐るほどあるだろうに
UnityみたいなエンジンならUnityで十分
既成概念を超えるアイデアがない限り無駄

843 ：

夢がないね

844 ：

先の無い夢に人生を賭ける馬鹿は死ぬ

845 ：

いろいろググって廃れたフォーラム覗いたときに
トピックの返信が一桁、二桁だらけなのを見ると悲しくなるな
やっぱりある程度のユーザー数がないとモチベが切れちゃうんだろうね

846 ：

エンジンよりフレームワーク書いたほうがいい
実装は既存のエンジンで

847 ：

グダグダ言うよりまず物を作れとあれほど言ってるのに・・・

848 ：

Ogre3DとIrrlichtとOpenScenGraphを調べたんだけど、どれも酷いね
有名なライブラリだから期待してたんだけど使い物にならない
Ogre3Dはシェーダー周りが独特で見るも無残なできだし、
Irrlichtはまだましだが目が潰れるぐらい汚らしい
この２つは論外。OpenSceneGraphはかろうじて合格
それでも固定シェーダー時代の名残なのかシェーダー時代のエンジンとしては使えないだろう
結論は俺が作ったほうがまし

849 ：

早く作ってオープンソースで公開してね^^

850 ：

よーし、パパゲームエンジン作っちゃうぞー
C#, .Net, OpenGL環境（だけどPSMとかに移植可）
シーングラフ、アニメーション、シェーダー、スケレタルアニメーション、コリジョン検出など
今日からここが俺の日記帳だ！

851 ：

やったー！

852 ：

シーングラフは「ノード ー コンポーネント」モデルとする
造語だけどUnityみたいな形といえばわかりやすい
３D空間上の１点が１ノードで、そこに色々な機能を持ったコンポーネントをアタッチして使うのが基本
Predicateで指定した条件が一致するノードを探すFind, FindAllと
指定のコンポーネント型を探すFind<TComp>, FindAll<TComp>がある
子ノードをたどってActionを実行するTakeもある
あとはSendMessage()で関数名（string)を指定してコンポーネントの関数を呼び出せる
ざっくりとガワだけ書くとこんな感じ
http://dl.dropbox.com/u/32901747/DDD/DDD-20120628.chm
（セキュリティ警告を外さないと見られないかも）

853 ：

DDDのクラスは単一のObjectクラスを継承する（標準のObject）とは別
このObjectクラスにはUniqueID, UserID, UserObject等を含むがおもしくも何ともない話なので省略
Objectクラスの一番重要なのはアニメーション機能。
DDDではAnimationTrackを１基本アニメーション単位とする
このアニメーションを任意のプロパティ（Setter必要）にセットすると準備完了
Animate()関数の呼び出しで値が書き換わる
これはノードのアルファ値を書き換えている例
node.AddAnimationTrack (anim, () => node.Alpha);
第２引数が珍しい形だが、これがC#で最も簡単にプロパティを指定する方法
型はExpression<Func<T>>だが特に気にする必要はない

854 ：

アニメーションは「値型でSetter/Getterを持ったプロパティ」なら何でもセットできるようにする
この辺はC#の機能をフルに使っている
クラス的にはKeyframeSequence<T>とAnimationTrackが存在し、
複数のAnimationTrackをAnimationClipが管理する（再生速度などはこのクラス）
歩くとか走るはこのClipが相当する
Clipを差し替える時は特に仕組みを用意してないが（全てのTrackを手動で切り離すことになる）
この辺は考慮中。あるいは
node.AddAnimationTrack()ではなくnode.AddAnimationClip()でクリップ単位でアニメーションをセットしたほうがいいのかもしれない。

855 ：

MathパッケージにはVector2,3,4, Matrix3x3, 4x4, Quaternionが含まれる
すべてC#の構造体を使って実装される
これらの構造体はプロパティとしてアニメーションを付加されたりUniform変数としてシェーダーにエクスポートされる
特徴は次の２つ
(1) 構造体は不変量とする
　どうしようかずいぶん迷ったがこれらの構造体は不変量、つまりnewした後は一切変更できない事にした。
　不便そうだが直感に反してそうでもない。いちいち計算のたびに新しい構造体を作るがコストは安い。
(2) 必ずプロパティ（ComponentCount)と添え字演算子([])を実装する。これはエクスポートする時に必要となる
Vector2,3,4は１つにまとめてもいいが、今回はタイプセーフを優先して別クラス
座標系はOpenGLと同じ右手系でV=MVの形.
　

856 ：

>>853
node.AddAniamationTrack()ではなくnode.AddAnimationClip()に変更
クリップ単位でセットすることにした。理由はその方が簡単
開発マシンをSSDにしてたら一日消えたんだぜ。まじ呪うMicrosoft

857 ：

Uniform変数の実装について。
今現在よくある実装はSahderProgramやVertexBufferみたいなクラスに
いきなり値をSetUniform("Alpha", 1.0f)みたいに突っ込むがこれは良くない習慣だと思っている
(1) この関数を呼んだ時に値がセットされるので毎フレームOnDraw()の中で呼ぶ必要がある
(2) 毎回呼ぶので依存関係がわかりにくい。
DDDでは「データ構造と操作の分離」を基本思想としているので、以下のように実装しようと思う
ShaderArrayクラス。使用するUniform変数の情報を保存するコンテナクラス
AddUniform(name, object, property)でどのオブジェクトのどのプロパティをどの変数でエクスポートするかセットする
この段階ではまだ値はセットされず、後のRender()関数内部でこの情報に従って値がセットされる（データ構造と操作の分離）
※　型とサイズ(vec2,3,4)はシェーダーをコンパイルした時に判定するのでここでは必要ない
※　Uniform変数の配列は当面なし。どう実装すべきか良いアイディアがない

858 ：

ShaderProgramについて
シェーダーはShaderProgram１つで全て賄う（FragShader, VertShaderはなし）
クラス名を可能な限り少なくするのがDDDの思想
DDDはHWに依存しないのでコンパイルとリンクはRender()まで行われない（というかできない）
定義されたAttribute変数とUniform変数を列挙する列挙しがある。型はIEnumerable<ShaderVariable>.
ShaderVariableは>>857と>>858の両方で使用する
これもやはり「クラス数を可能な限り少なくする」ため
シェーダーで定義された変数名と型を調べてそれが>>857でセットした一覧にあればそのオブジェクトとプロパティから値を拾ってきてエクスポートする事になる

859 ：

シェーダーにエクスポート出来る変数はIExportableインターフェースとして明確化した
ComponentCountとValueTypeを返す添字演算子を持つ
よく考えるとIExportableはIAnimatableでもあるわけだが・・・

860 ：

ある意味もっとお世話になるMesh周りはこうしようと思う
Mesh
　VertexBuffer
　IndexBuffer(s)
　Appearance(s)
　　　ShaderProgram
　　　UniformArray(s)
　　　Texture(s)
　　　Material
　　　PolygonMode,BlendMode,PointSpriteMode
(s)が付いているのは複数。IndexBufferとAppearanceが複数なのはサブメッシュ。
見え方は「Appearance」が担当する。
Appearanceは１つのShaderProgramとそこで使用するUniform変数のセット。あとTextureとMaterial。
Materialはユーザーがシェーダーに渡すパラメーターをセットしたObjectを置いておくためのプレースホルダー。Materialクラスは完全に空でユーザーが継承して使用する。
>>857の理由によりUniform変数には直接値をセットしない事に注意。
かならず値を取ってくる元になるObjectのプロパティがなければならない。
あとのPolygonMode, BlendMode, PointSpriteModeはシェーダーから触れないOpenGLの機能を変更するためのつまらないクラス
ポイントスプライトとは独立したノードではなくMeshクラスを使用する。

861 ：

VertexBufferとIndexBuffer
バーテックス・バッファーはAttribute変数として送られる頂点ごとのデータのバッファー(x,y,z, 法線, テクスチャー座標など)
インデックス・バッファーはglDrawElement()で使うインデックス。
この辺のデータ構造はライブラリによって異なるが、どの方式が有利とかは多分無い
DDDではMeshの下にVertexBufferx1とIndexBufferxnを持つ
生の頂点データはVertexArray<T>クラスが保存する
これはそのままglBufferData()でGPUに送り込める形そのもの
操作は非ジェネリックな同名のVertexArrayを通して行う
IndexBufferは本当にintの配列をどかんと持っているだけ
やはりそのままglBufferData()でGPUに転送する

862 ：

描画できるプリミティブについて
トライアングル、ライン、ポイントスプライトの「リスト」形式のみ「ストリップ」には対応しない
これは現在のGPUではリスト形式を使ったほうが高速で、あえてストリップ形式を使う理由がないため
シンプルである事を価値とするので複数の手段は提供したくない
インデックスを指定する時にリスト形式だと冗長なのでストリップ形式でも指定できるようにしようかとも考えたが
上記の理由でバッサリ削除
この辺は異論も出そうだが実際に作っている人の裁量の範囲ないということで

863 ：

あれ
インデックスは32bit限定？
ushort版はなし？？

864 ：

これってこの部分を実装しましたという報告なのか、これからやりますなのか

865 ：

>>862
intあればいいと思ったけど対称性悪いからIndexBuffer<T>にしといた
今の所ジェネリックなのはVertexArray<T>とIndexBuffer<T>とKeyframeSequence<T>
全部同名の非ジェネリック版ばあって操作はそちらから行う

866 ：

>>864
今の所ガワ(API)だけ実装してある。中身はすっからかん
必要なフィールドとかは置いてあるので実装はそんなに苦労しないはず
それでも月単位で必要だけど

867 ：

テクスチャーまわり
Image2DとTexture2D, TextureCube。あと基底クラスのTexture.
画像のロードは.NetのSystem.Drawingにやってもらう。
データの入力形式としては.NetのBitmapかbyte[].
フォーマットはLuminance, Alpha, LuminanceAlpha, RGB, RGB.
パック形式のRGB565, RGB5551はとりあえず対応しない。S3とかも対応しない
リピートはClampとRepeat.　テクスチャー関数というかDecal, Modulteなどはシェーダー内部の話なのでここでは出てこない
あとテクスチャークラスに直接画像をロードするライブラリもあるけど今回は１クッション（Image2D）を置く

868 ：

テクスチャーについて１つ注意点がある
通常CPU側にはTexture2Dクラスがあって、シェーダー側からアクセスする時は「テクスチャーユニット番号」を使用する
何番のユニットにロードされたかはTexuture2Dクラスの知る所ではなく、そのプロパティとしてテクスチャー番号を取得できない
（１つのTexuture2Dが別のユニットにセットされる事はあり得る）
従ってこれはAppearanceクラスの仕事（プロパティ）になる。
が、これは明らかにおかしくて本来はTexuture2Dクラスをシェーダー側のテクスチャー変数何とかにバインドするのが自然である
（ただしそれは上記の理由により不可能）
ではどうするか？
Texture2Dは同じ番号のユニットにロードされなければならないという制限を科す。
この制限のもとでTexture2D.TexturUnitでユニット番号が取れるようにすれば、
シェーダー側にユニット番号を自然な形でエクスポートする事ができる

869 ：

svnかgitを使って公開して欲しいなぁ

870 ：

>>869
してる。けどまだ見る価値はない

871 ：

BoundingVolume(BV)
BVは球かボックスで、カリング、ピッキング、LODで使われる。
コリジョン検出は別の専用のCollisionVolumeを用意する
たぶん珍しい形だと思うけどBVは独立したクラスにせずNodeの単なるパラメーターとする
BVはユーザー定義のBVと、シーンをフリーズ（後述）した際に自動で作られるBV階層のBVに分かれる

872 ：

BVを使ったピッキングその１
var nodes = from n in world
　　　　　　　let ri = n.Intersect (ray)
　　　　　　　where ri.Hit
　　　　　　　orderby ri.Distance
　　　　　　　select new {Node=n, Intersection=ri};
var nearest = nodes.FirstOrDefault();
説明の必要がないぐらいソースを見れば何をやっているか明確、しかも汎用的でピッキング以外もOK
（自分で作る理由の１つがこれ）
欠点は全ノードに対して交差判定をとるので遅い事
LINQ構文はデータベースをモデルにしているので全件検索になってしまう

873 ：

BVを使ったピッキングその2
float minDistance = Float.Max;
Node nearest = null;
world.Take ( n => {
　　　var ri = n.Intersect2 (ray);
　　　if (ri.Hit) {
　　　　　if (ri.Distance < minDistance) {
　　　　　　　nearest = n;
　　　　　　　minDistance = ri.Distance;
　　　　　}
　　　　　return true;
　　　}
　　　return false;
　｝)
前回のLINQ構文を使ったピッキングと異なりBV階層を利用してルートから交差判定を行いヒットしなければアーリーリタイア(return false)を行う
TakeはFunction<Node, bool>を引数にとり戻り値がtrueの限り再帰的に呼び出しを行うメソッド
BV階層を利用するのでシーンをフリーズしないと使えないけど速い

874 ：

シーンをトラバースしてある処理行うメソッドはいくつか用意する予定（詳細は決めてない）
IEnumerable<Node> Search (Predicate<Node> func)
　＝＞　指定の述語(Predicate)に一致するノードを列挙する
void Take (Action<Node> func)
　＝＞　全ノードに対してActionを実行する
void Take (Func<Node, bool> func)
　＝＞　全ノードに対してtrueを返す限りFuncを実行する
これらのジェネリックデリゲートを使った構文はシーンのトラバース以外にも使用する予定
処理結果を受け取りたいはクロージャーが使える（ラムダ式からラムダ式を呼び出す関数のローカル変数にアクセスできる）ので
ほとんど全ての処理が記述できる

875 ：

シーンのフリーズとOnUpdate()
昨日までうっかり勘違いしていたがシーンのノードのOnUpdate()の呼び出しは
シーンを上からトラバースするのではなくPriorityの順。
従ってOnUpdate()は再帰関数ではなく単発の普通の関数
コンポーネントの呼び出しは入れた順
順不同で呼び出されるのでモデルtoワールド行列とかキャッシュするためにもシーンのフリーズが必要
どのみちコリジョン(k-DOP)のワールド座標でパラメーターのキャッシュにも必要
フリーズしたら変更を伴う操作は一切受け付けなくなる

876 ：

ライト
固定時代のライトは独立したノードだったが、シェーダー時代ではライトは単なるUniform変数の１つに過ぎない
さらにDeffered Shadingにおいてはライトはメッシュと同様にGPUに頂点データを送って
（計算済みのBGufferからパラメーターを拾ってきて）レンダリングするだけの存在である
従ってDDDにおいてLightは本当に単なるMeshの別名である
using Light = Mesh;
マテリアルは専用のLightMaterialが用意されていてシェーダーにエクスポートするColorやAttenuationはここで定義されている。

877 ：

アニメーションイベントの設定
アニメーションクリップの指定の時刻を再生した時に任意のコールバック関数を呼び出すことが出来る
コールバック関数はdelegate void AnimationEventHandler(Node node, object args)型で
clip.AddEvent(time, name, handler, args)で登録する。追加情報としてobject型の引数を１つだけ指定できて使い方は任意
ハンドラーの第１引数はクリップではなくクリップがセットされたNode
（利便性を考えてこうなっているが深い階層でセットされるとNodeまでたどるのが大変なのでこの仕様は変更する可能性がある）
１つのクリップが複数のターゲットにセットされていた場合、コールバック関数は複数回呼ばれる。
コールバック関数の呼ばれるタイミングはゲームエンジンによって異なるが、
Animate(time)の中で値を変更しイベントを発火させると１つの処理単位としては内容が大きすぎる（と思う）
「シンプルであること」が価値と考えるDDDではこれを分割してRaise(start, end)とする。
Raise()は時刻(start,end]までに起こりうるイベントを全て呼び出す関数
通常start=time-Δt, end=timeで前フレームから現在のフレームまでに起こるイベントを発火させる

878 ：

SkinnedMeshの実装
スケレタルアニメーション用にボーンを仕込んだメッシュの実装
このクラスのやるべき事は実は多くない。ボーン行列の計算とGPUへの転送だけである
ボーンはただのNodeで表し特別なクラスは作らない。
SetBones(Node[])したタイミングでボーン行列（＝バインドポーズの逆行列）を計算し
プロパティIEnumerable<Matrix4x4> BoneMatricesで取得する
ボーンインデックスはこのNode[]のインデックスそのもの。
このプロパティは配列型で定義されたUniform変数に送られる
インデックスとウェイトはAttribute変数として頂点単位で送られる
ボーンの変形は「トランスフォームステージ」でユーザーがシェーダーの中で行い結果は一回書き戻す予定
OpenGLのTransofrm Feedback Buffer機能を使う予定だが、まだ詳細を詰め切れていない

879 ：

配列型のプロパティ
BoneMatricesプロパティは意外とこれが熟考が必要で、
(1) 配列型
　IEnumerable<T>のプロパティを配列型とみなす
(2) アニメーション可能
　アニメーショントラックは同名のトラックをクリップにAddTracks()で一括登録する
　アニメーション対象がIEnumerable<T>を実装したプロパティの場合は同名のトラックが連続して存在するものと期待して長さ分適応する
(2) GPUにエクスポート可能
　シェーダーが配列型のUniform変数を要求している時はそのまま列挙してセットすればOK。
でいけるはず。基本的には配列型のプロパティは例外。
多分ここにしか出てこないはず・・・

880 ：

１つ迷っているのがトランスフォームシェーダーをどうやって供給すればいいかという事
今考えているのはレンダリング時に強制的にシェーダーを切り替えて実行する案
トランスフォームシェーダーは全メッシュで共通なのでこれで十分だと思われる
シルエットで描画したいとか一時的にシェーダー（というかアピアランス）を切り替えて描画するのは理にかなっていると思う
この辺実はあまり調査して無くて他のゲームエンジンがどうやってるのかよく知らね

881 ：

MorphMesh
モーフィングは特に難しい処理はない。ベースのVertexBufferと同じ型のVertexBuuferをウェイトをかけて足すだけ
すべてCPU処理。ApplyMorphing()でベースのVertexBufferは上書きされるがデータ自体は置いておく必要がある（nullでは駄目）

882 ：

CollisonVolume
物理エンジンが組み込まれているわけではないので勝手に動いてぶつかり合うわけではない
設定したコリジョン領域同士がオーバーラップしたら指定のコールバック関数（OnCollision)が呼ばれる
CollisionVolume(CV)はコンポーネントの１種でNodeにアタッチするとコリジョン物体として振る舞うようになる
CVはk-DOP(k=26)を使う。k=26はAABB(6)にコーナカット(8)、エッジカット(12)を足したもの(6+8+12=26)
メリットは比較が速い（なにせ最大でも単なるfloatの大小比較２６回だ）。デメリットは座標変換（とても重い）。
比較の座標系は常にグローバル座標を使う。必ずしも全てのケースでベストではないが気にしない
シーンをフリーズしたタイミングで（グローバル座標に変換した）CV階層をボトムアップで作成しキャッシュする
シーンをフリーズするのはこの為という意味が強い。
コンポーネントの方のCVはユーザー定義のローカルCVで、ノードの方のCVはの自動生成のグローバルなCV
オーバーラップしていればvirtual OnCollision(Collision )が呼ばれる。引数はコリジョンの発生した位置、法線、ノード
タイミングは後述のPhysics3D.Collide (world).

883 ：

Physics3D
２つある(.Net環境で定義されていない）プラットフォーム依存クラスの１つ。もう１つはGraphics3D
コリジョンの判定はPhysics3D.Collide(world)で行う。
これがWolrd.Collide()でないのは「シーンはポータブル」という思想を反映している
シーンにプラットフォーム依存の関数が入り込んではいけない
一応Physics3Dは物理エンジンを使用する為の接続口として考えているが、
この辺はまったく調べてないので実はわからん。
当面コリジョン衝突の判定だけ

884 ：

BoundingVolume
あとバウンディンブボリューム(BV)も同様にして実装される
やはりコンポーネントの一種。BoxとSphere(and/or)が設定できる
BVはカリング、交差判定（ピッキング）、LODで使用される
コリジョンボリューム（CV)とは何の関係もない
このあたりのボリュームは可視化できるようにして欲しいなあ
という要望は当然あると思うが現状で特に考えてない。

885 ：

LODSelector（コンポーネント）
LODは複数の子ノードを持ったノードにアタッチされたLODSelectorが行う
親ノードにアタッチされたBoundingVolume(BV)がLODの基準になる大きさ
AddCandidate(node, resolution)で子ノードとそれを何ピクセルぐらいで表示したいかを決める
例えばノードに(1)メッシュ(2)ビルボード(3)空ノードを100,10,0ピクセルで登録して
World.Select()を呼ぶとスクリーンに投影されたBVのピクセル数に一番近い子ノードのみを有効にする（残りは無効）
詳細レベルの切り替えはフリッカーを起こさないようにヒステリシスを設定できる。
例えば上記の例だとhys=0.1を指定すると10〜10.9、100〜?が遷移領域になる
ブレンドファクターを使って２つの子ノードを合成すべきかとも考えたが、
使わないだろうと判断して見送った。いきなり切り替わる

886 ：

ノードの継承をObject3D - Attachable - Nodeに再編成
今ひとつゴチャゴチャしていたので３階層に再編成した。
[1] Object3D
　空間上の１点をあらわし座標変換を担当する抽象クラス。TRSMを保存
　
[2] Attachable
　1.にコンポーネントをアタッチできるようにした物。ノード単体処理もここ
[3] Node
　2.に親子階層をつけシーングラフを構成できるようにしたもの。再帰的な処理はここ
これですっきり。

887 ：

Graphics3D
デバイスクラス。.Net環境の外の部分
Targetプロパティ：xN RenderToTextureのターゲット最大４枚
〜Enabledプロパティ：機能の有効無効の制御
Selectionプロパティ：delegateでWorldからノードを取り出すLINQ構文の受け取りを想定
RenderPassイベント：delegateでレンダリングパスを記述する
Render()関数：RenderPassで指定したパスを実行する
最大の特徴は「不透明物体のみ取り出してzでソートしてカメラに近い方から描画」という処理を
後でエンジンの外からラムダ式を使って記述し（Selectionプロパティ）、RenderPassイベントに追加して
Render()関数でまとめて実行する事
従来型の記述よりだいぶすっきりと書けてると思う（たぶん）

888 ：

Mesh再考
どう考えてもこのままだとSkinnedMeshが実装できそうにないので再考した
(1) Mesh ：静的メッシュ
(2) TransformMesh ：TransformFeedbackシェーダーを含むメッシュ
(3) SkinnedMesh ：その中でもボーンによる変形を行うトランスフォームメッシュ
(4) MorphMesh ：CPUで変形するモーフ
スキンの変形にTranformFeedback(TFB)が必要で
将来的にSoftBodyとかパーティクルも実装可能な汎用クラスを考えてTranformMeshクラスを分離独立

889 ：

OpenGLリソースの保管
（.Netの範囲外である）描画コードは完全にシーンから分離する
そのためObjectとOpenGLリソース(int)の対応付けが必要になる
最初の案だとキャッシュとしてDictionary<Object, int>を考えていたが、
これだといったんキャッシュに入るとObjectの参照を保持し続けるのでシーン側で用済みになっても
ガーべっじコレクターが永遠に走らない
その都度リリースしてもらうかイベント登録とか考えたがどうもうまくない
そこで考えたのがObjectへの参照はWeakReferenceにしてディクショナリーのキーを
ObjectではなくObjectのハッシュコードに変える案
struct CacheLine {
　WeakReference ref;
　int resource;
}
Dictionary<int, CacheLine>
弱い参照は残っていてもGCには関係ないので消える。
後は定期的にGraphics3D.GC()を読んでもらえればキャッシュを捜査して
消えた弱い参照を消してOpenGLリソースを開放すれば完璧

890 ：

ひと通りAPIは決めたので月末までお休み
Doxygenでコメント埋めて抜けてるAPIを精査する
別段面白い作業ではないので一人でひっそりと。

891 ：

簡単に埋めてみた
http://dl.dropbox.com/u/32901747/DDD/DokiDokiDynamo-2012731.chm
APIだけ見てもわけわからんと思うが・・・チュートリアルが必要だがそのうち何とかしよう。
一応ページ差し込みができるのは確認した（けどXMLで書かないといけないから書きにくい）
しかし時間かかるねえ・・・
エラー条件等も含めてがっつり書いておきたかったんだけどなかなかどうして進まない

892 ：

実装するべ。コードより先にドキュメントを完成させておきたかったけど
これ以上細部を詰める必要はほとんどない（今の仕様でまず問題ないと考えている）
全部実装するのは年内一杯ぐらいかかると思うけど
とりあえず今月はシーングラフ周りから。というわけでまた月末までお休み

893 ：

irrlicht1.8aに追加でこんだけ実装した、エンジンの根本はもう実装終わりそう、やっとゲーム本体を組みに行けそう
win,osx互換、radeon,gf,intel互換、D3D,GL互換、SM2.0無印範囲で動作確認済み
・既存のHWSを改造して頂点色反映とか細々機能追加
・ソフトパーティクル
・FXAAを使えるように移植
・フォーラムに出てるXMLベースのシェーダ色々セットをD3DとGLで見た目が互換になるように改造、バグは潰し改良諸々
・自由度低い代わりに少し軽いブルーム
・A8対応(irrlichtはなぜかA8対応する気が無い？)
・A8テクスチャフォントと文章ノード
　文字個々に、4頂点色個々設定可、フチも4頂点色個々設定可、フチも込みで裏から見ても大丈夫
　文字の見た目重心で回転、拡大縮小、UVで上下左右反転、タブ位置揃え、タブサイズ可変
　描画がそこそこ速い頂点配列モードと自由度が高い代わりに遅い文字個々ノードモードでこれら装飾が完全互換
　頂点配列モード→ノードモードへはいつでも切り替え可
　書体切り替え可、字間行間設定可
　文字の初期配置と以降の変更は固定機能のほかにスクリプトでも可
　(固定機能の 右詰,ジャスティファイ,ルビ がまだ未実装)
・この文章ノード専用のメッセージアニメータ
　メッセージ表示速度やA濃度の変化距離(言い表し難い)をfloatで変更可な改行やタブサイズ対応の時間ベースアニメータ、フレーム数に依存しない
・celtストリーミング再生、oggページに分割しないで簡素に扱うためのダンパーも作った
・フルカラーもパレットも自然画もアニメ絵もPNG以上の圧縮率で、パレット画像の場合はPNGよりも展開が2倍↑速い独自コーデック、画像以外にもリソースのRAMキャッシュ用として使用、フルカラーは圧縮率を犠牲にすれば展開はもっと速くなる
・格ゲーでよくあるタイムストップ演出のためシーンマネージャ毎にタイムストップ可能にし違和感のないストップ解除も可能にした
・某エンジンで実装されてるエフェクトをパクる許可をもらったので盛り込んだ(推測で真似して実装しようとして挫折、数学苦手だ)
細々とした改造は他にも色々あるけど忘れた

894 ：

がんばれー

895 ：

http://www.twin-tail.jp/
↑どこ行ったん？

896 ：

>>893
お疲れ様です
気長にまったり頑張ってください

897 ：

>>895
あ、そこ世話になったのに消えちゃったのか。

898 ：

◆qSKP3eYtY6のひとブログやってる？
ブログ色々めぐってたら偶然それっぽいの見つけた。tu*daさん？

899 ：

ログ読んでたらなぜか既にDDD6のひとの名前がでてるｗ
それに叩かれてるけどログにある神奈川工科大のひとって
Unity for MMDのひとじゃないだろうか。
単なる名無しさんよりは名前出してる人のほうが成果だすのかも。
でも名無しでも>>893さんみたいに頑張ってるひといるし僕もがんばってみよ。

900 ：

今実装してるけど進まんねー
まあのんびりいこう
来月には三角形ぐらい出したい

901 ：

>>900
つくってるのは趣味？
Unity使わないの？

902 ：

米GarageGamesがゲームエンジン「Torque 3D」をオープンソースに
http://sourceforge.jp/magazine/12/09/11/2039230
http://www.garagegames.com/

903 ：

ほーMITライセンスなんだ
思い切ったね

904 ：

Torqueは結構迷走してるけど、会社自体は大丈夫なのかな。
でもMITライセンスは大歓迎だ。

905 ：

とーきゅーって読むのかな

906 ：

トルク

907 ：

もう開発しないよ宣言な可能性

908 ：

>>907
そうだよ？
「UnityとかUDKとかVisionとかNeoAxisとか出てPCでもスマホでも新規客取れない状況だわ。
ならもういっそTorque使ってゲームを作った方が会社としてマシだわ。
これまで支えて来てくれた既存ユーザーと業界のために現行版のソースとバイナリはそのまま公開するわ」
っていう趣旨

909 ：

骨組み部分は動くようになったぞ
コア部分(Unityで言えばGUIでポコポコ作る部分)
http://codepad.org/n2bhJENS
スクリプト部分(Unityで言えばユーザー定義のBehaviorスクリプト)
http://codepad.org/FJbjRKs1
動いているところ
http://v.youku.com/v_show/id_XNDU1Mjc1MTE2.html

ここまではこれ以上ないぐらいシンプルに実装できていると思う
来月はアニメーションとスキニング

910 ：

>>909
すげぇ
OpenGL3以降ベースのゲームエンジンって少ないから頑張って欲しい

911 ：

中華か…

912 ：

がんばってくれ。
いいものであるなら金払ってもいいから。

913 ：

〜無双、なんて(ry

914 ：

一人称カメラの動きを細かく設定できるエンジンって何があるか知らない？

915 ：

俺のエンジン(未公開)

916 ：

>>912
お前にとって良いものとは何なんだ？
箇条書きで答えよ！

917 ：

本見ながらjavaでのAndroidゲーム作成勉強してるんですが、java自体が全部理解できてなくて一苦労。
皆さんはjavaをどうやって学びましたか？

918 ：

2chで聞かずに自分でググって学びましたよ

919 ：

>>917
ゲーム作って学びました。

920 ：

javaじゃなくてC#使ってるけど、言語自体って結局慣れだから、
わからないとこは飛ばしていって次進んで、わかんないとこにぶち当たったら
またわかんなかったとこに戻るみたいにするのがいいと思う。
知識って本を何週も回し読みしたら、その分力つくと思うし。

921 ：

オープンソース読むのもいいんじゃないかな？
ゲームエンジンも既に公開されてるのがあるから、
それを自分好みに改造しながらスキルつけるってのがいいのではなかろうか。

922 ：

みなさん、ありがとうございます！
分からないところは前に戻って復習しながら進めます。
ちょっと焦ってしまいました(･･;)

923 ：

>>922 androidは詳しくないけど、ああいうのってvisual studioとかjava版のVSみたいなので
GUIアプリ作った経験があったほうがいいから、とりあえずCUIで文字列のみのをやったほうがいいかもね。
言語でつまってるならなおさら。
オブジェクト指向の話は知っといたほうがいいけど、言語のすべてをアプリ開発で使うわけじゃないし、
(map,vectorとか、知ってたほうがいいけど）気が向いたらアプリの本やってもいいと思う。言語と交互で。
読んでてわからないことがあったら、メモでもして必ず調べる。クラスとかメソッドならネットに説明あるから

924 ：

>>798
生きてたら再うpしてくれ
最新バーでも嬉しい

925 ：

>>924
どっかに残ってなかったかな･･･。
最新版は色々変わりすぎ＋変えている途中だから危険。

926 ：

>>925
変わりまくってて良いから欲しいっす…

927 ：

生存確認がてらスキンアニメーション
・http://codepad.org/ylcEHDlR
・http://v.youku.com/v_show/id_XNDY5ODkwMjk2.html
スキンアニメーションは基本的に２パスを想定していて
１パス目がTransformFeedbackを使った変形で、２パス目が変形後の頂点を(普通に)描画する。
用語はすべてJason GregoryのGame Engine Architectureにあわせてある。
ボーンのローカル座標からモデル座標に変換する方が「ポーズ行列」で静止姿勢が「バインドポーズ」。
従って「逆バインドポーズ行列」と「カレントポーズ行列」をかけたものが「スキニング行列」。
これらの行列はGetInvBindPoseMatrix(), GetCurrentPoseMatrix(), GetSkinningMatrix()で取得できる。
この辺の実装はいろいろパターンがあってどう実装してもいいけど、
世界で一番美しく書けたと思う。いやまじで。
関係ないけどどうも世の中のJason Gregory以外のスキニングの説明とコードが気に入らなくてなんだかなあと思う。
Jason Gregoryの本を読めば一発でわかる事をなぜあんなに分かりにくく書くのか・・・
ネーミングは多少気に入らない。TransformFeedbackBufferはいくら何でも長すぎる！
TransformVertexBuffer(←変形前)も微妙におかしい。この辺の名前は改善の余地がある。

928 ：

次は遅延レンダリング。fp32のオフラインレンダリングはできるようになったのであと少し。
できればHDRの後処理も入れたいので(その方が綺麗だ!)歩みは遅いけどがんばろう。
ガンダムオンラインのCβやってる場合じゃない罠
面白かったからいいけど。

929 ：2012/11/02

相変わらずすげー。
ところでイチャモンつけるようで申し訳ないんだけど
それシリアライズを考慮してるの？
アピアランスでラムダ使ってるからそのへん難しいのでは。