ゲームにおけるデータ構造・クラス設計・パターン2

1 ：08/05/23

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく

2 ：08/05/23

■デザインパターン
必須ではないが用語として便利なのでしばしば話題に上がる
[参考サイト]
Gameつくろー！　デザインパターン習得編
http://marupeke296.com/DP_main.html
サルでもわかる 逆引きデザインパターン
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html
[参考書籍(Amazonリンク)]
オブジェクト指向における再利用のためのデザインパターン
http://amazon.co.jp/o/ASIN/4797311126/
デザインパターンとともに学ぶオブジェクト指向のこころ
http://amazon.co.jp/o/ASIN/4894716844/
>>1乙
一応デザパタ軽く。

3 ：08/05/24

3ゲトー1乙。ずっと待ってたぜ。

4 ：08/05/24

・オブジェクト指向といったら特に指定しない限りクラスベース（所謂最も一般的なオブジェクト指向）
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。
とかスレの前提としてどうだろう。

5 ：08/05/24

インスタンスってつまりは実体のこと？
Foo foo = new Foo() とすると foo がインスタンス？

6 ：08/05/24

デザインパターンとOpen-Closed Principle
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
これも

7 ：08/05/24

>>5
揚げ足取りな事はわかってるんだが一応。
fooは変数だから、fooが参照してる参照先の何か、がインスタンスじゃね？
文脈でわかるけど、ここら辺の表記も少し気をつけた方がいいかも。

8 ：08/05/24

「ゲームとはPrettyなインターフェースを備えたデータベースである」
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな

9 ：08/05/24

スクリプト指向の意味がさっぱりわからない

10 ：08/05/24

今最高峰のプログラマって、全員ＷＥＢ系じゃん？
ＷＥＢ系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな？

11 ：08/05/24

>>8
ゲームをやる側から見た場合のRPG、特にFFなんかは5辺りから
ある意味その言葉を既に体現してる気がする。

12 ：08/05/24

メリットやデメリットを言えないくせに
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな
それで、教祖様は誰がなる予定なの?

13 ：08/05/24

>>12
今出てるのってそんな話か？
俺には世間話に>>10が適当な横槍入れただけに見えるが

14 ：08/05/24

プ板から厨房誘致すればこのｽﾚは盛り上がる。間違い無いｗ

15 ：08/05/24

たてなきゃいいのに布教スレなんかたてるからこうなる

16 ：08/05/25

もう厨房が数匹住み着いたのか

17 ：08/05/25

プ板？
ム板のことか？

18 ：08/05/25

マ板じゃね？

19 ：08/05/27

これも貼っておこう
やる夫で学ぶデザインパターン
ttp://mojalog.com/cgi/mt/mt-search.cgi?tag=%E3%82%84%E3%82%8B%E5%A4%AB%E3%81%A7%E5%AD%A6%E3%81%B6%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3&blog_id=1

20 ：08/05/28

途中からゲーム関係なくね？

21 ：08/05/28

俺には全部ゲームに関係した話に見えるけど？
サンプルコードもゲームだしわかりやすくていいと思うが

22 ：08/05/28

なんか、無理矢理ゲームに例えてる感がひしひしと。

23 ：08/05/28

日本語も満足に読めないのか

24 ：08/05/28

お、2スレ目立ってたのね。
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。

25 ：08/05/28

>>22
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ！」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い

26 ：08/06/01

俺のレベルではよくわからんが
ゲーム屋からみれば変な設計なん？

27 ：08/06/01

デザインパターンを丸々入れ込むとゲームだと描画とかで
速度でないゴミになりそうな悪寒

28 ：08/06/01

関数呼び出しとか仮想関数分のオーバーヘッドってそんなに響くか？
まぁ使い過ぎが良くないってのには同意だけど

29 ：08/06/02

クラスというか、同じ関数名が増えまくるオブジェクト思考言語は、GTAGS使えないので嫌いです。継承構造とかも嫌い。
こんなんじゃ、ゲーム屋って無理？

30 ：08/06/03

>>29
マならどんな屑でもなれるし、無理じゃないよ
個人的には一緒に仕事したくないタイプだな
他社にいても移植とかサンプルとかでそういうコード渡ってきたらゲンナリする…

31 ：08/06/03

>>29
利点理解した上で必要ないと言い切る奴は性質の悪い秀才
食わず嫌いで利点なしと判断してごねてるならただの馬鹿
環境によっては使わない方がいい事もあるかもしれんけど

32 ：08/06/03

cscopeならglobalと同じような事をC++やjavaのコードに対してもできるぜ

33 ：08/06/03

CodeWarriorとか、OOPでもばんばんタグジャンプできるから問題ないのでは？
どうしてもGTAGSがいいの？GTAGSってGNU Tags？Google Tags？

34 ：08/06/04

>>33
>GTAGSってGNU Tags？Google Tags？
ｶｴﾚw

35 ：08/06/07

>>27
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。
デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。
皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。

36 ：08/06/08

シューティング作っているんだけど
参考になるサイトでもある？

37 ：08/06/08

積み木ファイターのひととか

38 ：08/06/10

ゲーム作るときってどうやってプログラム組んでいく？
全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル

39 ：08/06/10

>>38
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。
これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ？

40 ：08/06/10

>>38
まず、誰にでも読める企画書とプレイマニュアルを作成する。
俺自身がどんなゲームを作る気なのかわかっていないことが多いから。

41 ：08/06/10

趣味で1人で作るのか、同人誌即売会狙いで数人で作るのか、会社の業務として作るのかで変わるとは思うけどな。
まあ、最後はありえねーとしてもｗ

42 ：08/06/10

>>38
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視
エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz

43 ：08/06/12

>>42
でも一番趣味でやる構築なら手ごろな手法っぽい。
ブリッジとアダプタさえあればドウトデモナルサー的な感じで。

44 ：08/06/14

まずはトップダウンでモデル作って、作りながら問題があれば
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。

45 ：08/06/14

それができないから、他に方法が無いかと模索してるんでしょうね。お察しください。

46 ：08/06/14

あのgoogleですらボトムアップだという

47 ：08/06/14

それはプロジェクト的な意味でだろ。

48 ：08/06/23

デバイスへのポインタってグローバルにしたほうが明らかに管理しやすいよな

49 ：08/06/23

>>48 は？なんで？

50 ：08/06/23

俺はどっかにまとめるなあ
グローバルとか、デバイス差の吸収とか必要になったとき困らね

51 ：08/06/23

Direct3Dのデバイスの話とまず仮定。
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との２択から、管理しやすさについて語っているのだと推測。
で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。
引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。

52 ：08/06/23

ヘッダーが重たくなるから一部のソースでデバイス関連のインクルードして、
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。

53 ：08/06/23

オレはシングルトンクラスに持たせてそこからgetter呼ぶかなあ

54 ：08/06/23

レイヤスーパータイプじゃないの
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど

55 ：08/06/23

デバイスを使うような処理は関数で囲っちゃって、
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな？

56 ：08/06/23

>>55
俺もー

57 ：08/06/23

↑でも、ビューアとかデバッグ系のプログラムは別だけどね。

58 ：08/07/02

お前らシーンの遷移ってどういう風に管理してる？
俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。

59 ：08/07/02

シーンクラスじゃなくて管理クラスの方を積むの？
俺の鳥頭じゃちょっとイメージしにくい・・・

60 ：08/07/02

シーンなぞ市販のゲームだって両手の指で足りるくらいしかないのに
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの？

61 ：08/07/02

シーンねぇ
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。

62 ：08/07/02

それで問題感じなきゃ無問題
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね

63 ：08/07/02

シーンの切替で驚いた事といえば、
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。

64 ：08/07/02

システムによっては、フィールドと町の中とではまるっきり違うやつもあるから、
そーゆーんじゃないのん？

65 ：08/07/02

まぁドラクエ的な物なら自分もフィールド、街、ダンジョンは同列に扱うかな。

66 ：08/07/02

>>58
P of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う

67 ：08/07/02

俺はステータス画面の中の項目や、更に細かい項目もシーン扱いしちゃうなー
そこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど

68 ：08/07/02

サブメニュー系は別で作ってhas関係にしてるな
シーン単一保持だと元シーン内のアニメも止める事になるし（※無論それが前提なら無問題だけど）
俺の手癖だと、シーンを同時に複数駆動できるようにするとこんがらがる。
結局多態やswitch、Cなら関数ポインタの嵐になって弄りにくくなる一方な感じ。
なんか下手なんだろな

69 ：08/07/02

>67
俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。

70 ：08/07/03

自分はCだけど、シーン毎にゲームループを作る。
フィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。

71 ：08/07/03

システムデザインに拘ると、抽象化についてこれないメンバーいるからなぁ・・
ゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。
外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。

72 ：08/07/03

>>71
それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。
日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。

73 ：08/07/03

むしろ日本の問題は、会社の枠で情報が閉ざされがちで、
結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。

74 ：08/07/03

閉ざしたくて閉ざしているわけでもないと思うんだけどね。
情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。

75 ：08/07/03

それは違うな、設計能力を持つ人間が極めて少数しか世界に存在していない
守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう
実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる
設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない
他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない
道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか

76 ：08/07/03

>>75
きもい、長い

77 ：08/07/03

>>75
> 守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
> または公開することもできるだろう
もちろん社内で議論はしてるだろう。仕事してるんだから。
それと公開するかどうかは別の話だ。
ここでの話は、企業として技術情報を公開することについてじゃないの？
少なくとも>>72はそういう話でしょう。
それとも>>75は単に多くの日本の開発者を無能扱いしたいだけ？

78 ：08/07/03

アメリカと日本じゃ、プログラマの流動性も違う品。
業界内で名を売って自分の値段を上げて転職するのが王道の国と、
あくまで内部で実績積み上げてくのが主流の国では、プログラマが
社外で情報発信するモチベーションが違う。

79 ：08/07/03

外国人すげぇ日本人だめ、みたいなステロタイプの意見が多いな
日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ
＞外人はゲームに限らず抽象化は得意
国産虹コンテンツの破壊力を目の当たりにしてそれはないよ
＞まああっちは人が多いから下のレベルが高いんだろうけど
PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下（兵隊）の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね

80 ：08/07/03

＞アマチュア間で情報をやり取りする開発者のフォーラムとか
＞あってアマチュアも結構あれこれ知ってるからなあ
MODとか好きだから今でも国籍隠してチョコチョコ見たり書き込んだりしてるが
日本のアマチュアを劣等とするほど明瞭な差異は感じない
嗜好の差異は凄まじいが素養・素質はどっこいだよ
「CoD4作りたいですどうすればいいですか」「HL2買ってHammerでもいじってろ」「サーセンｗｗ」
みたいなやり取りは沢山ある。日本で言えば「FF作りたいです」「ツクールやってろ」「おっおっお（＃^ω^）」と等価。
ただ英語圏vs日本語圏では裾野・人口が圧倒的に違うのでキチガイの数では英語圏に軍配があがる。
それと英語圏＝3Dキチガイの巣窟。日本語圏＝虹キチガイの巣窟。なのでアマチュアが渇望する知識
アマチュアが尊崇するアマチュア作家はだいぶ違う。単純に比較はできない

81 ：08/07/03

ゲーム開発に限った話じゃないけど、長引く不況のせいで日本人は
技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。

82 ：08/07/03

>>81
不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。
情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。

83 ：08/07/03

ノウハウ流出に厳しいってほんとかよ。
Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
海外では古い商用ゲームのソース公開したりする人達が沢山いる
けど、日本でそういうことやった会社はあんま聞いたことないし
プログラミングの本でも、８０年代は日本人が書いた本でも面白い本は
沢山あったのに、ここ１０年ぐらいの名著は外人が書いた本の
翻訳本ばっかりの現状考えるとにわかに信じられん。

84 ：08/07/03

単なる欧米コンプレックスだろ

85 ：08/07/03

>>83
> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。
Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。
実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。
もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。

86 ：08/07/03

Google の論文は、個人的には就職者ホイホイのような気がしてる。
SIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよｗ

87 ：08/07/03

論文の質・量で言うとMicrosoft Researchのほうがすごくない？

88 ：08/07/04

専門知識を蓄えてしまうと、ますます話の合う人間がいなくなりそうな予感。

89 ：08/07/04

>>84
ソフトウェアに携わる人間で米コンプレックスを感じない人は
無能あるいは情報弱者だろう
欧州はそれほどとも思わないけどアメリカリードしすぎ

90 ：08/07/04

>>89
海外はすごいよ。
開発するにしてもニッチな物になればなるほど日本側で
解説してるのが少ない。
結局は翻訳サイトで翻訳しながら自力で学習してる。

91 ：08/07/04

それ、英語の普及範囲を評価してるだけだろ
日本人の英会話力の低さは別問題だよもう

92 ：08/07/04

米コンプレックスとは世界の「知」が集まる「場」「国家」に対するコンプレックス
こういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」
一個人は素直により良い「場」の恩恵を享受することができるわけで
情報交換にしたって英語圏MODコミュやゲームデベロッパーのコミュを
覗き見ることに何の拘束も受けないよ。このネットの時代にあって
国家の枠組みや物理的距離は、知的欲求や情報交換を阻害する
主要因では既になくなってるよ。特にアマチュアにとってはこんな恵まれた状況は
90年代半ば以前はなかったわけで、この期に及んで、より良い「場」に距離を感じ
コンプレックスをおぼえるならその正体は言語コンプレックスなんだよ
言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ

93 ：08/07/04

>>91
かぶったス

94 ：08/07/04

ところで休暇中に発見した格安で愉快な英語おしゃべり上達法
ネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ

95 ：08/07/04

米国の現場における労働集約型闘争が生み出した兵隊の質の低下は
既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234
「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数のテクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる

96 ：08/07/04

くねくねハニィのコラムによると、
日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
ってことらしいぞ。
むしろ海外の方が技術的には閉鎖的なんじゃないか？知らんけど。
少なくとも俺はよそのメーカーを手伝う機会が多いから日本が閉鎖的とは思わんな。

97 ：08/07/04

切羽詰って偽装請負みたいなことやっちゃってたりするよな

98 ：08/07/04

>>96
＞日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
＞海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
＞ってことらしいぞ。
これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。

99 ：08/07/04

>>80
以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ（同人）市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/
○　絵（とくに３Ｄ）がきれい。
○　音楽も一般受けする質の高いものが標準。
○　ゲーム中以外のシーン（デモ、オプション設定）が作りこまれている。
パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。
日本のフリーとかシェアは、ゲームとして楽しいのが少ない上、パーツも陳腐なデザインが多い（よくできたものもあるが）。
グローバルな金儲けには関心なく、村市場（コミックマーケット）で満足してしまっている奴が多いんだろうな。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

ゲームエンジン総合スレ★２ (825)
◆◆SRCについて語ろう◆◆(ﾟДﾟ) (436)
ウルファールのウディタ講座 (348)
むしろjavascriptでゲーム作ろうぜ (649)
結局オレらパクリって言われるんだよ (199)
サウンドクリエイター撲滅スレ (102)
--log9.info------------------
予備校に通わないで東京５美大いけますか (809)
美大のレベルって… (981)
なぜ武蔵野美術大学は凋落傾向にあるのか (450)
名古屋芸術大学vol.18 (268)
東京工芸大学ｐａｒｔ34【芸術学部】 (280)
都立片倉高校造形美術コーススレ【5】 (382)
町田デザイン専門学校 (218)
桑沢ﾃﾞｻﾞｲﾝ研究所・ﾃﾞｻﾞｲﾝ専攻科 (526)
ムサビの基礎デってなにをやるんですか？ (689)
▼△▼悟った奴だけが書き込めるスレ▲▽▲ (174)
＄＄　大阪芸術大学　££ (564)
将来不安な奴！！ (184)
ムサビ相談 (118)
マジで本当に死にたい (323)
迷ってた無名美術大学にはいって悩んでいます (317)
【夜間】多摩美術大学造形表現学部part9【上野毛】 (264)
--log55.com------------------
【野球】大阪桐蔭監督「まさか甲子園で試合とは…正直びっくり [砂漠のマスカレード★]
【ラサール石井】アンジャ渡部に言及「彼が女性の敵かどうか真相はまだわからないが、もっと大きな女性の敵と闘っている人もいる」 [鉄チーズ烏★]
【芸能】渡部建のオンラインサロンが閲覧不可に　名店紹介やオフ会「とっておきの店、こっそり教えます」 [砂漠のマスカレード★]
【将棋】藤井聡太七段、王座戦予選で敗れ今期初黒星 [数の子★]
【芸能】氷川きよしが西川貴教との2ショットを公開し話題 「眩し過ぎます」 [しゃぶれよ★]
【芸能】渡部建、芸能活動自粛を発表「妻にも説明し、謝罪しました」★２ [ひかり★]
【映画】キアヌ・リーヴス、『マトリックス4』ネオ再演の決め手は脚本だった [自治郎★]
【音楽】ビリー・アイリッシュやT・ザ・クリエイターらが批判した音楽ジャンル「アーバン」、使用を禁止する動き #Republic Records [湛然★]