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

**名前は開発中のものです。** · 2006/08/10(木) 20:27:06

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

**名前は開発中のものです。** · 2007/07/18(水) 02:48:50

>>418
> ・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること

「データ」と「ゲーム上のオブジェクト」の違いがよくわかりません。
「動作を～に対して書ける」ってのもよくわかりません。
「～を引数とする関数を書くことができる」ってことでしょうか？

**名前は開発中のものです。** · 2007/07/18(水) 05:52:53

なんか奇想天外なことになってるのは
＞・データと動作を分離する事と
これのせいだと思う
誰が吹き込んだんだか知らんがまず>>413がしなきゃいけないことはこいつを殺すことだ

**名前は開発中のものです。** · 2007/07/18(水) 18:10:13

class CData : public IData<Param>, IData<Graphic>, IData<Sound> {};

こうすると、CData::valueの型は何になるの？

**413** · 2007/07/18(水) 19:28:34

>>419,>>420
>つまりテンプレートで実装する意味は無いよね
恐らく既存の構造体を利用するためにこうした筈なんですが
普通にそれらをCDataにスマポで持たせた方がいいじゃんじゃんな気もしてきました

>>421
おっしゃるとおりです
細かいところにとらわれて本質を見失うという悪い例を晒してしまいました…

>>422
>「～を引数とする関数を書くことができる」ってことでしょうか？
そうです
キャラクタの移動や描画の際は、リソースのハンドラを移動クラスや描画クラスに渡すんでなく
CDataを渡すような形で書きたいわけです

>>423
なんかキャラクタのクラスに座標構造体と移動メソッドを定義してたソースを友人に見せると
値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが
何か思い違いをしてますか…と問うまでもなく明らかにしてますね

>>424
晒したコードでは見事に多重定義のエラーになりました
実際はそれ避けたり多重定義されたIDataのvalueを内部で扱うためにboost::mplとか使って
さらに複雑な事やってるんですが>>417氏の言ってる事に繋がりますね

とりあえず苦労して作った車輪は最発明どころかガラクタですらないナニカだったというオチでした
もっかい一から作り直してみますm(＿＿)m

**名前は開発中のものです。** · 2007/07/18(水) 20:55:21

>>425
> 値を保持するクラスと操作するクラスは分けろこのスカポンタン
インターフェースと実装を分離するのは一般論としては間違いじゃないが、粒度が違う。
メンバ変数単位ではなく、意味のあるメンバ変数のセットをインターフェースにしろって
意味だと思うよ。

// 衝突判定後に、消灯判定マネージャから衝突回避のために位置をずらされる
struct IMovable {
　// 現在位置
　virtual void getPosCur(VECTOR3* p) const = 0;
　// 移動したい位置
　virtual void getPosNext(VECTOR3* p) const = 0;
　// 衝突しないようにマネージャがずらした位置
　virtual void setPos(VECTOR3 const& v) = 0;
};

class Player : public IMovable { ... };

class CollisionManager { /* こいつは IMovable だけ使用 */ };

こういう話かと。

**名前は開発中のものです。** · 2007/07/18(水) 20:55:52

>>426
s/メンバ変数のセット/メンバ関数のセット/g

**名前は開発中のものです。** · 2007/07/18(水) 23:49:47

>>425
＞値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてる
なんでそうしなくちゃいけないか理由は分からないの？
プログラムは芸術じゃないんだから外の人のどうしたこうしたで中身が変わったりしないよ？

**名前は開発中のものです。** · 2007/07/19(木) 00:19:41

> 値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが

つかこれ自体間違いだろ。

**名前は開発中のものです。** · 2007/07/19(木) 00:38:54

>>429
だよな多分

**名前は開発中のものです。** · 2007/07/19(木) 05:21:01

getterとsetter作って、アクセス管理するくらいしかやったことねえや
触らせたくないなら、関連クラスからのみアクセスとか（C++ならfriend？）

それ以上ってコストかかりすぎねえ？

**名前は開発中のものです。** · 2007/07/19(木) 11:40:10

少人数・小規模製作でアクセス制限も糞もないわな

**名前は開発中のものです。** · 2007/07/19(木) 15:01:29

少人数小規模だろうが、
開発期間中に、年単位で空白があったコードを読むこともあるわけで。

そういう場合は、アクセス権は考えといて損はねーですがよ。

**名前は開発中のものです。** · 2007/07/19(木) 18:50:40

アクセス権？になってくるとまた話が変わってきちゃうんだが
そんなファイルのパーミッションみたいな機構小規模だろうが大規模だろうがつけたらあかん
というか無駄、損がないというか何の得もない

**名前は開発中のものです。** · 2007/07/19(木) 18:59:00

とりあえず理由を

**名前は開発中のものです。** · 2007/07/19(木) 19:27:00

なんでファイルのパーミッションの話になってるんだ
>>432のアクセス制限って、クラスのメンバーに対することで、
>>433のアクセス権ってのもそのことだろ？

**436** · 2007/07/19(木) 19:27:51

変な日本語になった

正しくは、
なんでファイルのパーミッションの話になってるんだ
>>433のアクセス権って、クラスのメンバーに対することで、
>>432のアクセス制限ってのもそのことだろ？

**名前は開発中のものです。** · 2007/07/19(木) 19:39:53

「使いたいものを使いたいときに即使えないのはうっとうしい」
ということではなかろうか＞ファイルシステムの例え話

個人管理のLinuxなんかだと、最初からrootでログインして使う人もいるくらいだから
それはそれで別に当人の自由だと思う。

要はアクセス権限を分ける方がトクか分けない方がトクかは
ケースバイケースで判断すればいいってことだけど

**名前は開発中のものです。** · 2007/07/19(木) 20:12:33

＞なんでファイルのパーミッションの話になってるんだ
おまえがアクセス権なんていうからじゃん

**名前は開発中のものです。** · 2007/07/20(金) 12:39:13

スレタイを百回声に出して読んでくれ

**名前は開発中のものです。** · 2007/07/20(金) 12:40:51

ついでに二人とも正座な

**名前は開発中のものです。** · 2007/07/20(金) 21:52:02

難しく考えすぎ。

他のオブジェクトにアクセスして欲しくないメンバは
クラスの中に隠蔽して、プライベートメンバにしておくのがセオリーでは。
アクセス権ってのは本来そうやってコントロールする。

外からオブジェクトにアクセスできるようにしておきながら
アクセスできないように制限する仕組みを作るってのがナンセンス。

**名前は開発中のものです。** · 2007/07/20(金) 22:07:32

「する」「しない」の二択にするという話ならその通りだが
特定の状況でのみ●●に大して××させることを許可するとかいう話なら
ソースレベルで静的に操作するのは困難

**名前は開発中のものです。** · 2007/07/20(金) 22:32:40

動的にアクセス権を与えたいなら、まずは隠蔽しておいて、
状態に応じてアクセスを許すかどうかを決めればいいのでは。

**名前は開発中のものです。** · 2007/07/20(金) 22:52:28

本当にアクセス制御の問題で困っている人が大勢いるなら、
今頃boostにそれらしいクラスが含まれていると思うけどね。

例えばnoncopyableはオブジェクトのコピーを禁止するクラス。
こんなレベルのものでも有用さが認められればboostに仲間入りできる。
http://www.kmonos.net/alang/boost/classes/noncopyable.html

でも今現在boostにアクセス権制御のクラスがないってことは、
需要がないってことでは？

まずはプライベートメンバを使ったシンプルな隠蔽によるアクセス制御で
どこまでできるのか突き詰めてみた方がいいでしょ。
今のところ自分はそれで困ったことはないけどね…。

**名前は開発中のものです。** · 2007/07/21(土) 00:49:20

ナンセンス。この一語に尽きる。

**名前は開発中のものです。** · 2007/07/21(土) 01:16:04

progress_displayがあるのにそんなこと言われても説得力無いなぁ

動的にアクセス権決めるならgetter,setterを隠蔽してfunction使ってアクセス権を与えたいクラスに
そのgetter,setterを与えてやるって方法もあるけど
functionは1個で40bytes近く食う割と重たい(？)オブジェクトだから無茶かな、無茶だな

**名前は開発中のものです。** · 2007/07/21(土) 03:00:31

動的ってことになってくるとそれは普通にインターフェイス呼び出し時の
認証の機能の話になってしまうんじゃ？RMIとかそーいった話の流れ方向での

静的だと外側の構造も知らん一クラスごときが誰に使われるのが良いだ悪いだ
決めるとか何いい気になってんだって話だ

>>443
＞静的に操作するのは困難
困難どうこうより、そのポリシーを決める根拠をどこにも求められないということだよ
適当に決めてしまえば後で直せなくなる
根拠がどこにもないから

**名前は開発中のものです。** · 2007/07/22(日) 02:55:07

>>443
インターフェースを多重継承して、必要な時・相手にアップキャストしたものを渡せば。

**名前は開発中のものです。** · 2007/07/22(日) 03:36:44

簡単な具体例も挙げてくださいお願いします

**名前は開発中のものです。** · 2007/07/22(日) 13:24:51

>>450
struct IFoo { virtual Vec3 getPos(); const = 0; };
struct IBar { virtual setPos(Vec3 const& pos) = 0; };
class CPlayer : IFoo, IBar { ... };

f1(IFoo&);
f2(IBar&);

CPlayer player;
f1(player); // f1には getPos() しかさせない
f2(player); // f2には setPos() でメンバ変数書き換えを許可

**名前は開発中のものです。** · 2007/07/22(日) 15:08:54

>>447
functionって40byteも食うの？
その半分くらいですみそうなんだけどな。

**名前は開発中のものです。** · 2007/07/22(日) 18:59:44

なるほど、呼び出す側にインターフェースを渡すんですね
参考になりましたありがとうございます。

**名前は開発中のものです。** · 2007/08/05(日) 01:30:04

boost::functionって便利だけどむちゃくちゃヒープが汚くなりそう

**名前は開発中のものです。** · 2007/08/05(日) 07:10:10

>>454
小さなオブジェクトが多数 new されそうって意味？　気にしなさんな。

**名前は開発中のものです。** · 2007/08/05(日) 07:37:18

まあ、それが気になって使ってない、という訳じゃないけどねえ。
アロケータ作れば何とかなるだろうし。

**名前は開発中のものです。** · 2007/08/05(日) 20:35:16

javaでTCBを使いたいんだけど、どうしてる？

**名前は開発中のものです。** · 2007/08/05(日) 20:46:45

>>457
ふつーにメンバ変数使えばいいだけでは？　Task Control Block なんてのは、アセンブリ時代の名残だから、
C++, Java あたりでは使わんでしょ。

**名前は開発中のものです。** · 2007/08/06(月) 00:04:42

ゲームのデータを独自のフォーマットとかにする場合にヘッダを用意する？

**457** · 2007/08/06(月) 00:40:04

http://ueno.cool.ne.jp/dinna/topic/task.htm
こんな感じに組みたいんだけど、javaには関数ポインタがないので、引っかかり中。

**名前は開発中のものです。** · 2007/08/06(月) 00:44:36

>>460
まじめに勉強したら？

**名前は開発中のものです。** · 2007/08/06(月) 00:45:37

というかあからさますぎて夜釣りに思えてきた

**名前は開発中のものです。** · 2007/08/06(月) 02:03:36

TCBと言えばRTOSなので
ここはeCosに実装されたwabaを紹介してやるのが筋だろうか

**名前は開発中のものです。** · 2007/08/06(月) 03:43:57

ppc arm super wabaなら・・・

**名前は開発中のものです。** · 2007/08/06(月) 07:16:51

>>460
Java だとインターフェースもしくは抽象基底クラス使う。

**457,460** · 2007/08/06(月) 22:38:48

aを規定クラスにしたb1タスク
aを規定クラスにしたb2タスク
b1、b2タスクが混在したリストを作成したい。
C/C++なんかだと、関数ポインタnextなどにタスクをつなげてゆけるところだが・・・
javaだと関数ポインタがないので、配列にしてインデックス参照にするしかないのだろうか？
インデックス参照だと、個々のタスクごとに属性を割り振って、別々に読み出すか32bit以内に押し込むかなどして値を管理し、switchで分岐
して実行する記述が必要・・・。
C++なら多重継承があるので、b1からb2にたどることもも可能だが、javaには多重継承はないし・・・。
インターフェースは同じインプリメントを保障してくれるだけど、結局タスク切り替えのロジックが必要になるし・・・。
関数ポインタに比べて、これだと積極的に使うにはオーバーヘッドが気になるのと、記述が煩雑でプログラム的にCより退化しているように感じてしまう。
（今はリスト構造にせず、配列でタスクリストを持つ方向性で考慮中・・）

**457,460** · 2007/08/06(月) 22:41:30

だれか経験豊かなjavaプログラマた通りかかったりしないかなぁ。

**名前は開発中のものです。** · 2007/08/07(火) 00:03:46

Vectorじゃだめなのか

**名前は開発中のものです。** · 2007/08/07(火) 00:17:53

やはり釣りだったか

**名前は開発中のものです。** · 2007/08/07(火) 00:42:53

HSPでOOPをやろうとするのと同じくらい馬鹿げてるな

**名前は開発中のものです。** · 2007/08/07(火) 01:25:29

>>466
ぐちゃぐちゃ言ってないで書いてみろ。あんまりにも考察がめちゃくちゃで
どこから突っ込んでいいのかわからん。ソース晒してみれば突っ込みも入れやすい。

**名前は開発中のものです。** · 2007/08/07(火) 01:55:24

>>466
日本語でおｋ

**名前は開発中のものです。** · 2007/08/07(火) 03:33:11

>>466
参照使え馬鹿

**名前は開発中のものです。** · 2007/08/07(火) 03:37:03

なんでみんな冷たいんだｗｗｗ

**名前は開発中のものです。** · 2007/08/07(火) 06:44:09

>>468
LinkedList の方が。

**457,460,468** · 2007/08/07(火) 07:55:20

void (*func) ();
これのjavaでの代用法が知りたい。

**457,460,468** · 2007/08/07(火) 08:07:53

LinkedList ....
Thanks! >> 475

**名前は開発中のものです。** · 2007/08/07(火) 08:09:00

>>476
java.lang.Runnable func;

**名前は開発中のものです。** · 2007/08/07(火) 08:24:51

>>466
aを要素にとるコンテナを宣言して
それにb1インスタンスだのb2インスタンスだのを加え、
コンテナを走査して処理メソッドを順に呼び出せばいいだけの話。

データ構造だとかクラス設計だとかいうレベルじゃない。
単にプログラミング言語の勉強が足りていないだけ。
それにお前は多重継承を激しく誤解している。出直して来い。

**名前は開発中のものです。** · 2007/08/07(火) 10:39:17

なんかタスクってGoToやってるような雰囲気があるな

**名前は開発中のものです。** · 2007/08/07(火) 10:48:42

>>476
>>460では関数ポインタ使ってなくね？

**名前は開発中のものです。** · 2007/08/07(火) 14:27:28

まぁvtableは関数ポインタみたいなもんだけどな。

**名前は開発中のものです。** · 2007/08/07(火) 14:28:52

>>478
Swingでやってハマるとかｗ
関数ポインタに直感的に一番近いのはjdk7までお預けだな。

javascriptならそのまま
(function(num){ print(num);})(100); //-> 100
だが。

**名前は開発中のものです。** · 2007/08/07(火) 15:06:05

>>483
日本語でおけ

**名前は開発中のものです。** · 2007/08/07(火) 19:51:36

自分が話理解出来てないだけなのに日本語でｒｙとか言ってる奴増えたよね。

**名前は開発中のものです。** · 2007/08/07(火) 20:52:36

>>485
>Swingでやってハマるとか

理解できないのはこの部分だ

**名前は開発中のものです。** · 2007/08/07(火) 23:28:41

Swingがスレッドセーフではないって話かな。

もしそうなら >478 が言いたいのはRunnableのインターフェースだけを
借りることだろうから話が飛躍してるな。

**名前は開発中のものです。** · 2007/08/07(火) 23:51:16

>>476
だから抽象基底クラスかインターフェース使えと。下のサンプルコードは C++ だが、Java でも
ほとんど変わらん。

#include <boost/foreach.hpp>
#include <boost/ptr_container/ptr_list.hpp>

struct ITask {
　　virtual ~ITask() {}
　　virtual void exec() = 0;
　　virtual void draw() const = 0;
};

class TaskManager {
public:
　　void exec() { BOOST_FOREACH(ITask& task, m_tasks) task.exec(); }
　　void draw() const { BOOST_FOREACH(ITask const& task, m_tasks) task.draw(); }
private:
　　boost::ptr_list<ITask> m_tasks;
};

**名前は開発中のものです。** · 2007/08/08(水) 00:01:44

>>488
優しいな

**名前は開発中のものです。** · 2007/08/08(水) 07:33:12

たったこれだけのことなのに
さも凄まじいシステムであるかのように
タスクシステムと言う人の気がしれない

**名前は開発中のものです。** · 2007/08/08(水) 07:48:40

>>490
歴史を勉強しましょう

**488** · 2007/08/08(水) 07:51:26

>>490
同意。

アセンブリ言語でハードコーディングしていた時代に初めて見たら「やるな」と思うが、
今時だとふつー過ぎて何も言うことがないよね。UNIX V6 のころのデバドラも、既に
こんな作りだし。

自分でコード書くのもいいけど、もっとコード読もうよ、と思う。

**名前は開発中のものです。** · 2007/08/08(水) 07:53:43

今とは比較にならない制限の厳しさの中で
TCBを弄り回してた時代のことを知らないんだろね

**名前は開発中のものです。** · 2007/08/08(水) 08:21:56

そういう話題は以下のスレでやってくれ

タスクシステム総合スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1173708588/

**457,460,466,476** · 2007/08/09(木) 01:21:26

できた。
抽象基底クラスは知っていたが、
仕様上、基底クラスから上位のクラスをたどる必要があったので、
関数ポインタ云々といっていたのだが・・
キャストすればよいだけだった。
javaにはポインタの概念がないから、
javaのクラスは当然キャストできない、というような誤解があったので。

**名前は開発中のものです。** · 2007/08/09(木) 01:24:51

>>495
それなんか設計がおかしくないか？
みんなの意見無視ってところか

**名前は開発中のものです。** · 2007/08/09(木) 02:27:45

＞仕様上、基底クラスから上位のクラスをたどる必要があったので、
そんな仕様にするのが悪い。
第一、抽象基底クラスを知っているのならば
そんなところで困ったりしない。

**名前は開発中のものです。** · 2007/08/09(木) 02:50:07

初心者には冷たいもんだな

**名前は開発中のものです。** · 2007/08/09(木) 03:14:21

というか言語仕様勉強しろ

**名前は開発中のものです。** · 2007/08/09(木) 04:12:56

キャストってw
ポリモフィズムをカケラも理解しとらんじゃないか

**名前は開発中のものです。** · 2007/08/09(木) 04:46:19

自分から質問してきたくせに
まともな意見すら無視するような勉強不足君は
鮮やかに放置して、次の話題ドゾー

**名前は開発中のものです。** · 2007/08/09(木) 05:27:24

まともな意見を無視するのと勉強不足なのは関係ないと思うぞｗ
質問者はどちらの属性も持ってるけど

**457,460,466,476,495** · 2007/08/10(金) 20:04:16

失礼。

>>488
解決のヒントになりました。
ただboostライブラリはjavaにはないような気がします。

>>468
Vectorの案内が最初の解決のヒントになりました。

**名前は開発中のものです。** · 2007/08/11(土) 20:49:07

>>503
さんざん情報貰ったんだから、せめてソース晒して恩返ししてみないか？

**名前は開発中のものです。** · 2007/08/17(金) 01:53:51

JavaSEでVectorつかってそーだな・・・

**名前は開発中のものです。** · 2007/08/21(火) 16:35:31

質問すまそん。DXライブラリ＆VC++でゲーム製作してます。

例えばRPGで、キャラデータ・アイテムデータ・フラグおよび
ゲーム内システムデータ（ゲーム世界での日付とか）は、
それぞれグローバルなデータクラスにしてるんですが、
もうちっとスマートな設計の仕方はないでしょうか？

ほぼ全てのインスタンスから参照するデータ（例えばフラグとか）って、
いちいち参照やポインターで格納させるよりか、データクラスとしてグローバルに
展開してメソッド経由でアクセスさせたほうがいいような気がするど素人なんですが、
こんな俺はオブジェクト指向として根本的に間違ってますね？

**名前は開発中のものです。** · 2007/08/21(火) 18:54:06

ちゃんと管理できるなら問題ない

**名前は開発中のものです。** · 2007/08/21(火) 19:55:25

>>506
>>507に同意
オブジェクト指向をしたいのか、ゲームを作りたいのか。
書き方に明確な規則やルールがあれば、それだけでいいと思うけどね。

でも自分が「オブジェクト指向的」に組むなら、その辺の情報はグローバルにはしないと思う。
必ずシステム内で生成する。何故なら、ゲームシステム≠ゲームの世界と考えてるから。

１．ゲームシステム＝ゲームの中の宇宙を作る（ゲームシステム＝プログラム本体）
２．宇宙の中に惑星を一個作る。（ゲーム世界（日付等含む））
３．ゲームの世界の中に、登場人物やアイテムを作る。（キャラクターデータ、アイテムデータ）
４、登場人物とアイテムは、状態を所有している。（フラグ）

単純に現実に沿って状態を作る（これがRPG向きか？と言われると、そうではないけど）
データは必ず1→2→3→4の順にアクセスする。面倒くさいけど、一応これにも利点がある。
・ゲーム内での登場人物の役割を切り替えやすい。
・同時に複数キャラが操られても破綻しにくい。（マルチプレイさせやすい）
・同様に、ゲーム世界以下の要素は増やすのが比較的容易。

まとめて言えば、人や物、物事の取り扱いを現実と同じようにできるってことね。
最初に戻ると、規則があるなら君の好きで良いんじゃないってことで。

**名前は開発中のものです。** · 2007/08/22(水) 02:49:01

>>505
標準ライブラリが互換性のために未だに使いまくってるんだが・・・。
んで使い勝手悪いからいい加減JCFに移行しろと叩かれてるじゃないか。

**名前は開発中のものです。** · 2007/08/22(水) 10:20:41

Universe.MilkyWay.SolarSystem.Planets.Earth.Enabled = false;

**名前は開発中のものです。** · 2007/08/22(水) 21:45:27

>>508
> 単純に現実に沿って状態を作る（これがRPG向きか？と言われると、そうではないけど）
単一システムで作るのは、結構つらいなぁ。

俺だと RPG はフィールド＆シナリオ、戦闘、デモシーンでシステム完全に切り離して
作っちゃうけど。どーしてもフィールドからシームレスに戦闘に入りたいと言われたら
考えるが、工数は開発もデバッグも倍かさむよって感じ。

**名前は開発中のものです。** · 2007/08/22(水) 21:58:56

>>506が心配してるようなのって構造化手法の方の話で
オブジェクト指向とはあんまり関係ない気がする
オブジェクト指向言語は結局構造化手法の流れを汲んでるから関係あるっちゃあるんだけど
「オブジェクト指向的」に批判されることはないと思うんよ

**名前は開発中のものです。** · 2007/08/22(水) 22:26:25

>>508はこの方針でゲーム作ってなんかあったらここへ相談しにきてね

**名前は開発中のものです。** · 2007/08/23(木) 00:15:28

>>60が参考になるんじゃね

**名前は開発中のものです。** · 2007/08/24(金) 15:43:24

>>513
>>510みたいなことは流石にやってないけど、マップが複数面あって
自由にキャラクターを選べるのを作ってるから、今のやり方で全く問題なかったりするぜ！

**名前は開発中のものです。** · 2007/09/01(土) 13:35:04

>>510おれもそんな感じだww

**名前は開発中のものです。** · 2007/09/01(土) 15:26:53

>>516
お前って奴は…

**名前は開発中のものです。** · 2007/09/01(土) 18:53:13

チラウラだが .NETの自動生成コードとか見ると
クラス名がネームスペース入りのフルネームで書かれてて
>>510と比べてもあまり遜色ないくらい長ったらしい記述になってる

**名前は開発中のものです。** · 2007/09/03(月) 18:50:24

>>510はどこまでが名前空間でどこからがコレクションなんだろ

**名前は開発中のものです。** · 2007/09/03(月) 18:56:19

Universe.、までが宇宙空間

**名前は開発中のものです。** · 2007/09/03(月) 20:58:24

Planetsまでじゃないのか