ゲームにおけるデータ構造・クラス設計・パターンat GAMEDEV
ゲームにおけるデータ構造・クラス設計・パターン - 暇つぶし2ch200:名前は開発中のものです。
07/01/31 00:35:16 NKCnpIjT
クラス名・変数名に迷ったら書き込むスレ。Part9
スレリンク(tech板:113-132番)
から誘導されてきました。

・こんな構造の名前はなにがいいですか?
・タスクっぽいですねー
・擬似マルチタスクっぽいかも?
・スタック使え!
・え?スタック?
・segregated storage使え。
・boostのpool?

まあ、そんな感じで、ゲーム向けのデータ構造をどうするかって話になりました。

201:名前は開発中のものです。
07/01/31 00:44:13 YqKTmdjS
>>200
答えでてんじゃん。
ここで何が聞きたいの?

202:名前は開発中のものです。
07/01/31 00:49:48 jNUdiQRe
フラグ立ててるだけなのがなー。
削除と同時に最後尾のデータをコピーしちまえ。

203:名前は開発中のものです。
07/01/31 01:00:05 8/b3tbHY
>>200
そのアルゴリズムのどこが高速なのか本当に分からない。
フラグを立てて何に使うの?

204:名前は開発中のものです。
07/01/31 01:08:05 kxHbC4YN
いや、向うで煙たがられて誘導されたからって、
本当にこっちに来る事もないだろww

205:名前は開発中のものです。
07/01/31 01:09:38 8/b3tbHY
今適当に書いたけどフラグなんか使うよりこっちのほうがいいんじゃないか

template<typename T,int N>
class FixedAllocator
{
 union Block
 {
  T Data;
  Block* pNext;
 };
 Block* m_pGarbage;
 Block m_Pool[N];
public:
 FixedAllocator()
 {
  m_pGarbage = &m_Pool[0];
  for( int i = 0; i < N-1; i++ )
   m_Pool[i]->pNext = &m_Pool[i+1];
  m_Pool[N-1]->pNext = NULL;
 }
 T* Alloc()
 {
  Block* pRet = m_pGarbage;
  m_pGarbage = m_pGarbage->pNext;
  return &m_pGarbage->Data;
 }
 void Free( void* p )
 {
  static_cast<Block*>(p)->pNext = m_pGarbage;
  m_pGarbage = static_cast<Block*>(p);
 }
};

206:名前は開発中のものです。
07/01/31 01:10:11 94hlWcQw
>>202
フラグ管理より双方向リストでつないどくのが良いと思うけどな。

struct PoolNode
{
 struct PoolNode* pn_next;
struct PoolNode* pn_prev;
 char pn_padding[8]; //必要なら
 char pn_buf[PN_BUFSIZE];
};

static PoolNode nodes[NODENUM];

// 未使用ノードは、こっちにつなぐ
static PoolNode* free_first = &nodes[0];
// 使用中ノードは、こっちにつなぐ
static PoolNode* inuse_first = 0;

現実には、俺なら自前で書かずに STLport の node allocator にお任せして、
STLコンテナ使っちゃうか、boost::pool だけと。

207:名前は開発中のものです。
07/01/31 01:13:52 NKCnpIjT
boostみて、なんじゃこりゃーな感じだったので、

>>206とか、見るとわかりやすいですね。

配列でデータは持つんだけど、使用中ノードは、連結リスト風につないでおくっと。
未使用ノードも同じようにもつ。

これだけで、済む話かー。

208:名前は開発中のものです。
07/01/31 01:14:36 YqKTmdjS
>>205
それが segregated storage だろ。

209:名前は開発中のものです。
07/01/31 01:15:32 8/b3tbHY
>>208
そう言うのか

210:名前は開発中のものです。
07/01/31 01:17:52 kxHbC4YN
欲しいのはクラス名だけであって、
>>200が考案した以外のクラスなんて興味ないんだろw
だって、>>200より優れたクラスなんて存在しないんだからwww

つ 【ステフ18クラス】
つ 【次世代コミュクラス】
つ 【バキュンバキュンクラス】

この板ならではのクラス名を授けるから好きなの選べ

211:名前は開発中のものです。
07/01/31 01:18:10 8/b3tbHY
そう言うっていうか、boostのクラスなのか。
boost、まだ知らん機能多すぎる…orz

212:名前は開発中のものです。
07/01/31 01:22:57 94hlWcQw
boostは、知ってても使いこなせてないクラスも多いなぁ。fusionとかmplとか。

普段お世話になってるのは、stdafx.h 見るとこんな感じ。

#include <boost/array.hpp>
#include <boost/bind.hpp>
#include <boost/call_traits.hpp>
#include <boost/crc.hpp>
#include <boost/cstdint.hpp>
#include <boost/function.hpp>
#include <boost/format.hpp>
#include <boost/intrusive_ptr.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/noncopyable.hpp>
#include <boost/ref.hpp>
#include <boost/scoped_ptr.hpp>
#include <boost/scoped_array.hpp>
#include <boost/static_assert.hpp>

213:名前は開発中のものです。
07/01/31 01:24:55 NKCnpIjT
>>210
変数名つけろスレから着たけど、
いまや、クラス名だけでないです。

>>210さんが、私のデータ構造を最高!マンセー!他はクズ!>>200様に一生従います!
と言ってくださるのは、うれしいのですが、

他に、どんな効率のよい、データ構造があるかというのを知りたいのです。

Delphiには、boostねーよー。うらやましい。

214:名前は開発中のものです。
07/01/31 01:26:10 NKCnpIjT
× >>200様に一生従います!
>>200様に一生を捧げます

間違えました。

215:名前は開発中のものです。
07/01/31 01:26:40 94hlWcQw
>>213
効率はデータの使い方に依存する。で、何に使おうと思ってるの?

216:名前は開発中のものです。
07/01/31 01:46:00 94hlWcQw
もしかしたら、主要なデータ構造を一通り勉強したいってこと? それなら、
まずは(データ構造を処理するアルゴリズムとセットで)

・Cプログラマのためのアルゴリズムとデータ構造
・珠玉のプログラミング
・プログラム設計の着想
・プログラミング作法

あたりの書籍を読むのがお薦めだが。

217:名前は開発中のものです。
07/01/31 02:00:35 kxHbC4YN
>>213
いや、普通に皮肉だから、無理にレスしなくていいよ。

218:名前は開発中のものです。
07/01/31 02:31:13 sTyDsN4F
この板で数少ない有用なスレッドだな

219:名前は開発中のものです。
07/01/31 15:38:04 CxDF9OMM
>>215
パーティクルや弾幕のように、
追加、削除の頻度が高い場合に使える構造はないかと探していました。

>>216
勉強したいだけ、というわけではないのですが、
参考になります。

220:名前は開発中のものです。
07/01/31 19:22:58 WbpDldoh
弾幕だったら各機で同時に発射しうる最大数に応じた領域確保しちゃうかな。
頂点バッファは1つあれば十分だし。

221:名前は開発中のものです。
07/01/31 20:28:29 94hlWcQw
>>219
パーティクルは出現数の上限を決めて、それを超えたら適当に消すのが常套手段。
多少消えても人間は気づかんから。

メモリ管理自体は PS2 以降のハードなら大した工夫は要らなくて、pool なり STLport の
node allocator なりで十分な性能が出る。それよりベクトル演算効率化することを考えとけ。

222:名前は開発中のものです。
07/01/31 22:47:38 YNrC6zK6
>>221
おまいの賢さは分かったが数個前のレスくらい読んでやれ

223:名前は開発中のものです。
07/01/31 23:00:17 94hlWcQw
>>222
同時に発射しうる最大数を確保して超えないことを保証するのと、適当な数を
確保しておいて越えたときに消しちゃえってのは、一見似てるけど使いどころが
違う。

一般にヒット判定があれば前者、単なる見た目だけなら後者。ヒット判定がある
ものを適当に消すと致命的なバグになったり、予期せぬ挙動をすることがある
ので。

224:219
07/01/31 23:25:03 NKCnpIjT
まあ、実際、別のプロジェクトで、毎回、インスタンス生成しても、
描画の方が圧倒的に遅すぎるというプロファイル結果が出たりしたので、
そんなに神経質になる必要はないんですけどね orz
(動作環境は、PCです)

新しいプロジェクトで、
パーティクル一杯出したいから、それぐらいは、pool化したいなって思ったんです。

225:名前は開発中のものです。
07/03/21 22:27:58 /cwA8n13
>>224
シミュレータの場合、速度最優先で描画をしない状況もあるから、
それが免罪符にならない場合もあるんだよね

226:名前は開発中のものです。
07/03/23 13:48:25 vxAgs8Dc
良スレage

227:名前は開発中のものです。
07/03/26 06:10:31 mFbF2Qb2
ところで、
キャラクターの構造体は何で取ってる?
今じゃ普通にダブルでとっても問題ないよな。
むしろ、その方が微調節がしやすくって良いよね。
俺は貧乏癖がついててイントでとって微調節がやり辛くなって、
結局後で困ったりしてるんだよね。

皆は何で取ってる?

228:名前は開発中のものです。
07/03/26 06:11:56 mFbF2Qb2
あ、ゲームは普通の2dのアクションゲームとかです。

229:名前は開発中のものです。
07/03/26 08:35:24 I1HKFzJn
doubleでおk

次の話題どうぞ

230:名前は開発中のものです。
07/03/26 12:51:40 74T0tUus
単純にintのかわりにすると計算誤差で困ることも多いからちゃんと使ってくれ
具体的にはイコールで判定とかやっちゃだめだぞ

231:名前は開発中のものです。
07/03/26 18:43:03 /edWn9Q+
>>227
自分で固定小数点数作るのが楽ちんだろ
浮動小数点数の等号問題も出ないし

232:名前は開発中のものです。
07/03/26 19:09:19 I1HKFzJn
桁落ちの誤差で困ったことはないなあ。
「本当はセーフだったのに、桁落ちしたせいで等号が成立して
 敵に当たったことになって死にました」みたいな状況は
あるだろうけど、まず気づかないと思うし。

そのあたりを完璧にしたいのであれば、丸め誤差も考慮に入れて
10進固定小数点数クラスを作らなければならないだろうけど、
そこまでしたくないというのが正直なところ。

233:名前は開発中のものです。
07/03/26 19:20:52 /edWn9Q+
>>232
そんなクラス作らなくてもいいんじゃね?
16ビットシフトするだけでゲームの精度的には十分かと。

234:名前は開発中のものです。
07/03/26 21:35:29 /T0E1d66
URLリンク(shinh.skr.jp)


235:名前は開発中のものです。
07/03/26 22:10:26 xV5pAsSl
>>232
なんか勘違いしてるけど、固定小数点数にするのに10進は関係ないぞ。

236:名前は開発中のものです。
07/03/26 22:13:45 I1HKFzJn
>>235
10進って言ったのは、丸め誤差を考慮しての話なんだけど。
桁落ちとは関係ない。

237:名前は開発中のものです。
07/03/27 01:42:55 0naF3MYn
10進でも2進でも丸め誤差は出るってば。

238:その1
07/03/27 06:12:21 6cy45QrY
「キャラの座標の型に関して」

・整数か小数か -> 断然小数

・小数の表現方法
 -> 浮動小数点数 or 固定小数点数
 -> 2進表現 or 10進表現

・浮動小数点数
 ○ 基本型であるので扱いが楽
 × 演算速度が遅い
 △ 非常に近い値同士を比較したときに桁落ちが発生する
   (桁落ちが発生したところで別段問題がない場合も多々ある)
・固定小数点数(クラス実装)
 ○ 比較による桁落ちが発生しない
 ○ 実態は整数型なので演算速度が早い
  -> × 汎用性の高い実装(シフト数の異なる固定小数点数同士でも演算を
     可能にするなど)を行うと、結局浮動小数点数以下の演算速度に
 × 固定小数点数オブジェクトの生成が頻繁であると遅くなる
   (特にオペレータ・オーバーロードに注意)
 △ 小数点以下の精度(桁数)が固定
   (ただし、精度が足りなくて困ることはまず無いと思われる)

239:その2
07/03/27 06:13:22 6cy45QrY
・2進表現
 ○ 基本型は2進表現なので扱いが楽
 × 10進表現で有限小数となるが2進表現で循環小数になるような値の場合、
   表現できない桁が切り捨てられるなどして丸め誤差が発生する

・10進表現
 ○ 循環小数に対する丸め誤差が起きない
  -> × 一般によく使われるであろう加算減算処理では問題ないが、
     除算を行うなどすると何進数であろうが丸め誤差は発生する
 XX 基本型とは程遠い別次元の演算手法が要求される
   (2進表現で循環小数となるような値を基本型で記述した時点でアウト)
 × 同じバイト数で表現できる値の範囲が2進表現より狭い

勝手にまとめっぽい形式で書いてみた。
固定小数点数に関してはクラスとして実装した場合を想定した。
個人的に、固定小数点数を素のintで表現して、その都度シフト変換を行うような手法は、
変換方法に依存した関数/クラスを大量発生させるので論外だと思う。

240:名前は開発中のものです。
07/03/27 06:39:01 AmaYqa2T
10進表現ってBCDのことだったの?
俺はてっきりintを10^nで割って使う話だと思ってた。

241:名前は開発中のものです。
07/03/27 06:42:53 6cy45QrY
色々書いたけど、結局俺は無難なdoubleを使っちまうかなあ。
試しに固定小数点数クラスを作ってみたけどあんまし早くならなかった。
っていうかコンパイラによって速度が大きく変わりそうな予感。

10進表現での計算は、誤差が出たら切腹必至の
銀行システムとかでのみ使うものだと思っている。
言語的にサポートされていれば話は別だけど。

以上長文&駄レスすまん。

242:名前は開発中のものです。
07/03/27 06:45:51 6cy45QrY
>>240
俺は流れ的にBCDのことだと思ったが…。違ってたらすまん。

243:名前は開発中のものです。
07/03/27 10:06:48 KORunXqt
昔は、固定小数点使ってたな
今は、さすがに、浮動小数だわ

問題は、環境によっては、リプレイでずれるとかその辺
(D3DXの最適化とか最適化とか最適化とか)

244:名前は開発中のものです。
07/03/27 12:34:52 WDGoOIYE
浮動小数点だと0.1ですらがあらわせないからな
表せないのに無理しているのが浮動小数点
あらわせないのなら扱わない、問題が出ないようにするのが固定小数点

0.1を10回たしたら1になるとか思ってるような人は固定小数点つかっとけと

245:名前は開発中のものです。
07/03/27 14:36:14 DOw2VNK3
アナログコントローラーとか3D処理やったこと無いのかな

246:名前は開発中のものです。
07/03/27 19:55:06 OAIOW3b5
Flashとかだと0.5ずつずらさないと隙間が空くとかあるんだよね

247:名前は開発中のものです。
07/03/27 20:06:13 6cy45QrY
微妙に関連する話題だと思うんだけど、
皆は(無限)多倍長精度整数を使ってたりする?

248:名前は開発中のものです。
07/03/28 00:55:28 3c8pkg+a
>>247
固定小数点数使ってたら、上の桁が足りなくて、
仕方なしに64ビット整数を使っちゃったことはある

249:名前は開発中のものです。
07/03/28 05:12:49 cMkZ8VMH
>>247
そういうのは学術用だと思うよ。
ゲームなら実際問題そんないらんっしょ。

250:名前は開発中のものです。
07/03/28 05:53:37 vQ7wya7A
得点計算で使われることもあると思う。
32bit符号なし整数では40億程度しか表せないし。

恐ろしい桁数の得点をガンガン加算させて、
かつ一の位までキッチリ使っちゃうような
血も涙もない鬼の方御用達です。

251:名前は開発中のものです。
07/03/28 07:59:56 cMkZ8VMH
無限多倍長精度整数って書いてるんだよな。
long longより上だと3倍長で7.9x10の28乗とかになるけど……要るか?

252:名前は開発中のものです。
07/03/28 11:11:39 xf4mLohJ
>>249
んなーこたーない。
経営シミュレーションで多倍長な変数を使うことはあるよ。
キャッシュとか資産とかの額で。
まさか、浮動小数点使うわけにはいかんし。

253:名前は開発中のものです。
07/03/28 12:08:50 hyD2GS3G
ビルゲイツの資産とか32bitに収まりきらんもんな

254:名前は開発中のものです。
07/03/28 12:54:06 HnZM11tF
そもそもビルゲイツの資産は、株価がちょっと変わるだけで
とんでもない額が変動するから、下の方の桁にあまり意味はない。

255:名前は開発中のものです。
07/03/28 15:10:12 +k+f3/yD
32bitどころじゃないだろ。

まあ、毎年訳分からん団体に1兆寄付してるおっさんだからな。

寄付してるのは妻の方だけ?

256:名前は開発中のものです。
07/03/28 16:57:57 erfbPR6U
自分の設立した財団じゃないのあれ?

257:名前は開発中のものです。
07/03/30 00:16:52 xOzIjQQy
Delphiの日付用構造体TDateTimeを馬鹿にするなよ?
日付なのに、不動小数

258:名前は開発中のものです。
07/03/30 01:10:16 /yTpVVer
不動ならいいや('ー`)

259:名前は開発中のものです。
07/03/30 03:52:48 HXn7HlKm
MSのAccessも日付はdoubleでもってたような・・・

260:名前は開発中のものです。
07/04/01 02:13:01 aK7v4JwN
いいシーン管理方法が思いつかない…。
「シーンはスタックに積む」って話をよく聞くけど、
積みっぱなしでメモリは大丈夫なのかとか、
タイトルシーンやメニューシーンはその都度生成した方が
再初期化の手間いらずで楽なんじゃないかとか、
ロードの際にスタックの中身をいちいち
再現しなきゃいけないんじゃないかとか、色々疑問が残る。

261:名前は開発中のものです。
07/04/01 13:27:10 vpNPV10r
>>260
何が「いい」かは作るプログラムによって違うからな。
疑問に思うんならやってみろとしか言えない。

262:名前は開発中のものです。
07/04/01 14:21:19 XdYqPGRk
なるほどそういうときにシリアライズを使うのか

263:名前は開発中のものです。
07/04/01 15:15:13 Sn7iJUNq
>>260
Gemsの5巻にスタックを使ったシーン管理が載っている。

試してみたら、なかなか使い易かったよ。

264:名前は開発中のものです。
07/04/01 15:35:35 gVILklLW
>>262
javaのシリアライズの話ならそういう時の為のものじゃないぞ



265:名前は開発中のものです。
07/04/01 20:39:12 4uyw/V8k
>>260
作ってるゲームによるでしょ。

シーン切り替えの度にブラックアウト & ロード処理が入るふつーの RPG だと、
シーンは必要な都度 new して作る(ただしテクスチャ・モデル等のリソース類は
事前に割り当て決めておく)、状態遷移はプログラム側でベタに行う…で十分に
管理できる程度だった。

266:名前は開発中のものです。
07/04/05 20:02:57 53u6wZm0
>>263
Gemsうp!!
って、無理だw

ソースコードだけでも配ってないのか・・・

267:名前は開発中のものです。
07/04/06 02:24:49 jVhSsUiB
【警告】
日本はカルト教団に支配されてしまいます。
選挙に行きましょう。

268:名前は開発中のものです。
07/04/06 16:07:18 +BNVME6N
スタックベースのシーン管理に参考になるページはないですか?

269:名前は開発中のものです。
07/04/07 09:34:17 ok5ggep+
どっかのやねうの昔のサイトに解説がなかったか。

270:名前は開発中のものです。
07/04/07 12:47:03 lstp6MTf
YaneSDK.Netのソース読め

271:名前は開発中のものです。
07/04/08 01:31:41 TWCxMGaJ
本人がいらっしゃるようなので一言申し上げますが
yaneSDK3rdの更新してください><
2ndからトランジエントビルトを移植しようとしたんですが正直無理です><

272:名前は開発中のものです。
07/04/08 01:42:46 Svf9QlZ3
無理とか言ってたらなんも成長しないがな。
つか本人が来たとか本気で思ってるのか。

273:名前は開発中のものです。
07/04/08 02:50:06 l6t1YJuf
皮肉にマジレスしてどーする

274:名前は開発中のものです。
07/04/08 13:14:13 8g6onocj
そういや、やねうらおの会社の社員が、やねうらおを訴えた件はどうなったんだろうな。

275:名前は開発中のものです。
07/04/09 03:25:15 /ygJ9fwS
騙された馬鹿が、ギャーギャー文句言ってただけ

276:名前は開発中のものです。
07/04/09 03:38:12 TJO4g1v+
いい加減スレ違い。

277:名前は開発中のものです。
07/04/09 13:14:13 /ygJ9fwS
スタックベースのシーン管理について質問

つくってみたけど、いまいち利点がわからん・・・
何が便利なんだろう・・・


278:名前は開発中のものです。
07/04/09 15:13:20 bk7kEELW
スタックみたいな古臭いのじゃなくて
デザインパターンでオブジェクト指向的にスッキリと出来ないものなんだろうか

279:名前は開発中のものです。
07/04/09 16:14:10 3UDAKRrm
シーンをオブジェクトと見なしてスタックに積むんだから、
十分オブジェクト指向じゃないかと思うんだけど、そういうことではない?

280:名前は開発中のものです。
07/04/09 18:50:04 CrOX57BA
>>277
利点かー。
末端のシーンがどこに戻るか把握しなくていいから、シーンを柔軟に組めるとか、シーンを再利用しやすいとか。
ごめん、思いつきで書いた。

281:名前は開発中のものです。
07/04/09 20:46:27 d0StE6D+
>>279
うん。
それ自体が定型になるなら、スタックベースのシーン管理というのも
ゲームにおけるデザインパターンといっても過言ではないと思う。

282:277
07/04/09 20:49:46 d0StE6D+
とりあえず、googleして、定番とおもわれる

・呼び出し(Call)
・移動(GoTo)
・呼び出し側に戻る(Return)

をシーン管理オブジェクトに、実装して、シーンを状態遷移してみたりしたんだけど、

これって、シーンを遷移するときって、前のシーンは開放しちゃっていいのか?
開放しちゃうと、
しなかったらしなかったで、リソース圧迫するし

クソー、Game Programing Gems 5がほしいZE

283:277
07/04/09 20:54:13 d0StE6D+
> 開放しちゃうと、
開放しちゃうと、呼び出し(Call)の意味あんのかな?と思うし

284:名前は開発中のものです。
07/04/09 23:33:21 HDs+xqt8
ところでシーン間の関係はだれが持つの?

シーンクラス?シーン管理クラスとか他のクラス?

分岐のあるゲームだとこれ重要。
次に進めるべきシーンを決める奴が持てばいいのか・・・?

シーン遷移管理とシーン関係管理+フラグ管理に分けるとか?

>シーンを遷移するときって、前のシーンは開放しちゃっていいのか?

javaだとこれ厄介なんだよね。何しようが使ってなかったら勝手に拾われるから。
一応クリーンアップなりシャットダウンなり処理して放置かな。

こういうときにファイナライザ使うもんじゃないしね。

285:名前は開発中のものです。
07/04/10 00:13:19 NhbAQuFj
>>277
シーンは最初に全部確保して
最後に全部解放してるよ。

シーンスタックそのものが「アクティブなシーン」のスタックであって、
今アクティブじゃないシーンは別のリストに保管してる。
でスタックに積まれてるものは一通り処理する。

こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか
裏画面でデモ(通常ゲーム処理)回しながら上にウィンドウ表示とか
出来ますよ って趣旨だったと思う >Gems5

ただ、ウィンドウ関係以外には特に利点は無さそう。

286:名前は開発中のものです。
07/04/10 01:08:35 wXzQkwkx
マルチスレッドを実現する手段の一種ということ?

287:名前は開発中のものです。
07/04/10 01:12:58 vYIHoF6r
>>285
>でスタックに積まれてるものは一通り処理する。
これ、厳密にはスタックって呼べなくね?
LIFO≠スタック

288:名前は開発中のものです。
07/04/10 01:16:37 EIMh3HFt
なんだ、シーンの遷移がスタック的なのかと思ってた。

289:285
07/04/10 01:26:00 NhbAQuFj
>>287
上にシーンを積んだときにサスペンド処理(シーンクラスのメソッド)を呼ぶようにして
サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる
とかそんな処理になっていたと思うから 一応一番上に積まれているのが
現在のシーンってことになる。
立ち読みだから細かいことは忘れたw

スタック全体をなめるんだからスタックとは言わないと俺も思う。

290:277
07/04/10 01:59:26 9N2vtVIw
わかった。
かなり勘違いしていた・・・。

>>288
俺もそう思ってたww



291:名前は開発中のものです。
07/04/10 09:19:06 xnqcZNCE
これ読んで、久々にパックマン作りたくなったな~。
アクションゲームは、作ってないけど、デザインパターンを、正しく使うと、プログラムがスッキリするし、大好き。
デザインパターンって、しらない人多いのかな?

292:名前は開発中のものです。
07/04/10 09:47:11 9N2vtVIw
Large-Scale Stack-Based State Machines
James Boer
Game Programming Gems 5, 2005.



293:名前は開発中のものです。
07/04/11 01:26:38 hEaakUMM
>>291
> デザインパターンって、しらない人多いのかな?
んなわきゃない

294:名前は開発中のものです。
07/04/11 05:40:08 6fD2+qm/
スタックベースのシーン管理、結局、状態遷移をスタックベースに作ってしまったw

これで、

 タイトル画面→(呼び出し)→ゲーム処理→(戻る)→タイトル画面

とか、
 タイトル画面→(呼び出し)→リプレイのメニュー→(呼び出し)→ゲーム処理→(戻る)→
 リプレイメニュー→(戻る)→タイトル画面
とかできるようになったw

スタックベースといったらやっぱりこっちだろw

295:名前は開発中のものです。
07/04/11 05:56:16 M15Cgj6f
スタック的に自然な状態遷移しかしないのであれば役に立つだろうけど、
そうではない大部分のゲームにとっては役立たず以外の何物でもないと思う。


296:名前は開発中のものです。
07/04/11 07:47:20 J6IpVt/X
スタックというデータ構造を状態遷移を表現するために利用するからには
・次のシーンに移る=push操作
・1つ前のシーンに戻る=pop操作
という対応関係が常に成り立っていて、この操作のみで完結すべきなんだが、
これだけの操作でOKなゲームがどれだけあるかっていうと、ぶっちゃけほとんどない。
スタックにこだわるあまり、データ構造を破壊したり
オブジェクトの役割を破壊したりするような例が後を絶たないのだが、
>>279>>281のようなやり取りが行われている現状では仕方がないか。

297:名前は開発中のものです。
07/04/12 03:38:40 AG1SAh/k
実質が状態遷移ならstateパターンでいいやんって事ですか?

298:名前は開発中のものです。
07/04/12 04:43:05 0Ip1HTkJ
>>297
Stateパターンとか全く関係ないよ。
シーンの遷移をうまく表現するためのデータ構造に関する話。

どこまで理解しているかわからないから基礎から説明する。
Stackというデータ構造は、
・オブジェクトを1つStackに積むpush操作
・最後にStackに入れたオブジェクトを1つ取り出して捨てるpop操作
・最後にStackに入れたオブジェクトを参照するtop操作
を持つ。ここで、
・push操作=次のシーンに移る
・pop操作=1つ前のシーンに戻る
・top操作=現在のシーンを取得する
と対応付けると、これはシーン管理に使えそうだぞってことになる。
これが、今話題に上がっているStackベースのシーン管理。

これをStateパターンにしたところで、Stackの中に入るオブジェクトが
シーンオブジェクトから状態オブジェクトに変わるだけで、
シーン遷移のための操作やベースとなるデータ構造は変化しないってのはわかる?

299:名前は開発中のものです。
07/04/12 05:16:23 0Ip1HTkJ
(続き)
で、何故Stackベースのシーン管理に関して
>>295>>296(俺)のような批判が出るかって言うと、
>>298で挙げた3つの操作だけでうまく管理できるような
状態遷移になっているゲームが少ないから。

例えば、Stackの状態が
タイトル <- メニュー <- ゲーム処理 <-
だとして、ゲームオーバーシーンに移りたいとする。そうするとpush操作で
タイトル <- メニュー <- ゲーム処理 <- ゲームオーバー <-
となるが、次にタイトルシーンに移りたくなったときに、
これに対応する操作がない。あくまで与えられている操作は、
次のシーンに移るか、1つ前のシーンに戻るかだけだから。

"ゲームオーバーシーンから戻るときだけは
topがタイトルシーンになるまでpopする"というような特例を
不都合が生じる度に設けると、Stackベースにした意味がなくなる。
これが>>296で言った『データ構造の破壊』に相当する。

"Chain of Responsibilityパターンを使ってシーンオブジェクト間で
データをリレーしていけば実現できるよ"って意見をどこかで
見たことがあるのだが、そもそもシーンオブジェクトには
状態遷移を正しく行う責任はないので、オブジェクトの動作的に不自然。
これが>>296で言った『オブジェクトの役割の破壊』に相当する。

ここまで神経使うかよって思うのが普通だとは思うけど、
せっかくのデータ構造スレなので色々グダグダと言ってみた。
よさげなデータ構造があれば是非ともそれを利用したいし。

300:名前は開発中のものです。
07/04/12 07:27:37 KA8mV/7R
Stackのシーン管理を、必要なところだけ使うようにすればいいんじゃないの。
セーブ画面とか、オプション画面とか。

301:名前は開発中のものです。
07/04/12 11:44:45 dOVFJA3U
>>185-
ちょっと参考になるよ

302:名前は開発中のものです。
07/04/12 18:19:58 sR+tFe8j
色々考えて、俺はスタック的な遷移も結構いいんじゃないかと思えてきた。

スタックだと、シーンの遷移の責任は全て親に任せることができる。
キャンペーンモードなのか、単独のマップを遊ぶだけのモードなのかは、自分は
知る必要もなく、遷移する理由(勝利、敗北、キャンセル…etc)だけを伝えれば
次にどのシーンになるかは親が決めてくれる。

各シーンが自分で次のシーンを選んでダイレクトに遷移していくよりは、
親に一任した方がすっきりするね。

スタックそのものでなくても、スタック的な遷移ができることは便利だと思う。

303:名前は開発中のものです。
07/04/12 20:03:01 +rjgMuLJ
うむ、完全にpush/popに収める必要はないよな。

304:名前は開発中のものです。
07/04/12 20:15:13 BUTEbHo0
素直に多方向リンクリストでやれよ。

305:名前は開発中のものです。
07/04/12 20:25:07 +rjgMuLJ
それは実装・データ構造の話じゃん。

306:名前は開発中のものです。
07/04/12 21:46:48 V5BuRGqQ
>>302
遷移する理由を伝えることによるシーン遷移ってのはいいね。
が、これは別にスタックに限った恩恵ではない
(っていうのは>>302もわかってると思うけど)。
>>304の言う多方向リストでも可能(っていうか本来はこっち)だし、
イテレータが指すシーンを現在のシーンとする双方向リストでも可能。

多方向リストで工夫して実装すれば、
リソースを食うシーンに移ったときに
前のシーンをいくつか解放するといった処理が行えるし、
シーンを激しく前後するような操作をしても
オーバーヘッドがかからないのでいいかも。
もっとも、ゲーム起動時にリソースを全部先読みしても
全く問題ないようなゲームだったら、
積みっぱなしのスタックで全く問題ないし、
これが一番簡単だと思うけど。

307:名前は開発中のものです。
07/04/12 22:34:50 Yo7l8Dzb
"多方向リンクリスト"に該当するページが見つかりませんでした。

308:名前は開発中のものです。
07/04/13 01:17:14 FDWvNnME
双方向リンクリストじゃない?

309:名前は開発中のものです。
07/04/13 01:37:40 maKmelpg
色んな方向につながってるってことは…
vectorじゃねぇの?

310:名前は開発中のものです。
07/04/13 02:13:59 ye+8qT/8
遷移元シーン番号と遷移事由コードで
テーブルから遷移先シーン番号(またはシーンオブジェクトの参照)を
引くだけというのはだめだろうか

311:名前は開発中のものです。
07/04/13 04:18:27 VGgK68eb
ヒント:C言語などの関数

312:名前は開発中のものです。
07/04/13 04:47:41 sVc4IdNT
>>311
エレガントじゃない気がする

313:名前は開発中のものです。
07/04/14 05:39:36 0P7qLuwH
状態の保存方法なんて画面にあわせて stack なり queue なり
vector なり list なり、適当に作ったツリー構造なりを使えばいいよ。

コンテナ実装するのも一苦労だったアセンブラやCで組む時代じゃないんだから、
全体でどれに統一するか悩む必要なんて無いでしょ。

314:名前は開発中のものです。
07/04/15 10:34:45 PbHNo8Qe
ログ

315:名前は開発中のものです。
07/04/15 14:31:59 GX7kX5Cm
参照カウント付きスマートベクトルポインタ使ってシーンの遅延生成や破壊を自動管理したり
夢が広がりまくりんぐ

316:名前は開発中のものです。
07/04/19 13:16:55 WPH1WRyj
シーン間の遷移(例えばクロスフェード)とかどうやってる?

317:名前は開発中のものです。
07/04/19 13:42:33 1tbYRD5H
俺はシーン別に切り分けてバッファを持っている。

318:名前は開発中のものです。
07/04/19 22:50:53 ofjIK8wt
自分は、Viewで処理してて、Modelでのシーン自体は完全に移行済みにしとく。

あくまで、表示(演出)は表示(演出)ときりわけやったほうがいいと思うし、
また、切り分けとくと変更も楽だし、テスト時とか演出要らん場合はさっさと飛ばせるし。


319:名前は開発中のものです。
07/04/20 18:21:55 NDgAfFd0
やべ。意味が分からん^^
ちょっと確認させて欲しい。

class IScene {
  virtual void update(ISceneContext& ctx);
  virtual void draw(ISceneContext& ctx);
};
class SceneStack {
  void push(IScene *scene);
  void pop();
  void call(IScene *scene);
  void update(ISceneContext& ctx) { /*登録されたシーンの更新*/ }
  void draw(ISceneContext& ctx) { /*登録されたシーンの描画*/ }
};

自分の理解では、こんなのがシーン処理の実装なんだけど、
まずこの解釈はあってる?
当然、シーン変更時はscenestack.call(new_scene)とかやるわけね。

>>317
シーン別にバッファを持ってるってことは、
シーン遷移時の処理はSceneクラスで遷移を行うか、
他の遷移専用クラスがあるってことですか?

>>318
↑の例でいうと、ISceneまたはSceneStackのdraw内のみで
遷移処理を実行するということですか?


全然分かってないかもです。
理解が足りなくて申し訳ない。

320:316
07/04/20 18:22:39 NDgAfFd0
>>319も316です^^

321:名前は開発中のものです。
07/04/20 23:58:50 jHP7m8qh
やねうら臭がする

322:名前は開発中のものです。
07/04/21 04:53:19 upqCn/9t
>>319
俺もおおよそそんな感じ

323:名前は開発中のものです。
07/04/21 09:13:46 jPfR3hGz
沖縄県の方へ(命に関わる注意事項です)

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度(※)ですが、一度「一国二制度 沖縄 三千万」等で検索をお願いします。
この際、民主党のHPで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
 簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
 (つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。)
 さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
 3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
 そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

324:317
07/04/23 17:44:03 jyQ0IgwD
>>318とほぼ同じと思うけど
シーンに関してスタックは使ってないので、並列処理しているとき
それぞれのシーンが自分用の裏画面などを持ってないと都合が悪い

表示(演出)は別クラスにして任意シーンの裏画面を複数使って料理する
ぶっちゃけ、カメラを切り替えている感じ

325:名前は開発中のものです。
07/04/24 20:58:04 LmvfBEf6
>>324
なーる。表示用クラスが裏画面(テクスチャだよね?)
を複数使って演出してるわけね。
ありがとう^^

326:名前は開発中のものです。
07/04/30 13:33:52 rkXlhSNv
RPGでマップとかイベントはゲームスタート時に全部ファイルから読み込んでメモリに置いておくほうが普通でしょうか?
それともマップに入ったときにファイルからロードするほうがいいでしょうか?

327:名前は開発中のものです。
07/04/30 13:38:16 Omqviadr
普通なら、使いもしないデータを主記憶に展開しておくのは無駄としか思えないが・・・

328:名前は開発中のものです。
07/04/30 14:13:55 +32zYLn2
環境とか開発の容易性とかいろいろ考えた上で全部入れるのはべつにかまわん
重いのは画像や音声だったりするわけでそれがないので別に大丈夫かと

規模によっちゃそれすらもまるごといれてもかまわんけどな
1MBもあればFF4がまるごとはいるわけで


329:名前は開発中のものです。
07/04/30 14:36:40 rkXlhSNv
動的に読み込むってなかなか難しくて・・・
FF4で1MBなら自分の程度なら全部読み込んでも大丈夫かも。


330:名前は開発中のものです。
07/04/30 16:15:04 1Z2FVuUn
シームレスは少し難易度高いが、区画ごとに区切っていいなら難しくないんじゃ?
あっちこっちでグローバル変数使うような原人は知らん。

331:名前は開発中のものです。
07/04/30 17:45:14 QczQVIdr
最初は難しいことに手を出すよりも、楽なほうでやったほうがいいよ。
後からだんだん発展させていけばいいと思う。
ぐちゃぐちゃになったらリファクタリングで。

332:名前は開発中のものです。
07/05/01 07:32:01 n4UjW/KJ
クラスが多くなってぐちゃぐちゃになってきたorz
RPGって結構複雑ですぐ混乱してくる。
そろそろUMLとか勉強しないときついなと思ってきた。

333:名前は開発中のものです。
07/05/01 10:50:48 TWHDSCbL
UMLは構成を抽象化して理解するためのものであって
おぬしの想像しているものとは用途が違うぞ


334:名前は開発中のものです。
07/05/01 11:11:50 RvA2WJ3F
システムの規模が肥大して、クラスを整理するのが大変になってきたら
UMLなり何なり書いて一からやり直してもいいんじゃねぇの

335:名前は開発中のものです。
07/05/01 11:14:53 TWHDSCbL
リファクタリングとデザインパターンおぼえておけばおけ
アクセサとしてpublicなメソッド用意してるだけだとあとでみなおすとききついから
フレームワークつくればよろしい

336:名前は開発中のものです。
07/05/01 14:19:12 QizfdMH2
有名そうなライブラリをぱくるとかで

337:名前は開発中のものです。
07/05/02 23:12:09 n6prPmTN
UMLからソースのスケルトンを自動生成する奴とか使って手抜きしたい
一応ヘッダから関数の定義のスケルトンや、標準関数やライブラリの関数のusing宣言を
自動化する程度のツールは自作して使ってるけど

338:名前は開発中のものです。
07/05/02 23:15:54 waD0m0t1
今までいきなりコーディング始めてたんだけど大規模なゲーム作り始めて設計の重要性を痛感したorz
ただUML書いててもちっとも楽しくない。

339:名前は開発中のものです。
07/05/02 23:53:12 HOIFQT1u
>>338
おやこんな所に俺がいるじゃないか

早く新人研修のJava教本を読む作業に戻るんだ・・・

340:名前は開発中のものです。
07/05/03 03:33:21 aROKnpN+
俺はUML書いてるだけで楽しいけどなあ

341:名前は開発中のものです。
07/05/03 04:46:21 PxIyx3hy
同意
コードに落とす方がかったるい

342:名前は開発中のものです。
07/05/03 07:22:23 mjAAEilH
すげー、良く分かるw
コード打ってる時も、デバックしてる時はめんどい加減で止めたくなる。

343:名前は開発中のものです。
07/05/03 10:26:46 ykGFiN+W
俺は未だに、コーディングするときは脳内麻薬出まくり。

分かりきった定型的なコードを書いてるときは退屈で死にそうだけど。

344:名前は開発中のものです。
07/05/03 17:19:41 GHCrYaAw
人それぞれだなー
自分はキーボードかたかた叩いてちょっとずつ作っていく瞬間が楽しい

でも設計できないと先がなさそうorz
がんばってUML勉強しよう。


345:名前は開発中のものです。
07/05/03 17:36:22 mjAAEilH
>>344
UMLはそういうものじゃないぞ。基本的にあれは知らなくても十分だし。
(あくまでも、設計の書き方・設計のための言語みたいなもん。
 個人か固定少人数でやるなら、適当でもなんとかなるし。)

設計を と思ってるなら、普通にオブジェクト指向系の本がいい。
自分が買って読んだ本で、お勧めは
 憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門
まぁ、あと定番ながら
 オブジェクト指向プログラミング入門 
 デザインパターンとともに学ぶオブジェクト指向のこころ
立ち読みで数ページしかみてないけど、入門の方はC++ 以外の言語(Object-C、Java、Delphi?)まで含めた本。

どれもこれも、値段も高いし・ページ数もやたらとあるしで
趣味でゲームを作るだけならちょっとオーバーワークっぽくも思えるけど、
Programmerとしての教養に読んでみては?


346:名前は開発中のものです。
07/05/03 18:20:36 q0fI33vb
憂鬱本は読んでみたけれど全くオススメできない。
ゲームプログラマなら、遅くともインベーダゲームを例とした説明のところで
頓珍漢なことを言っているのに気づくべき。

347:名前は開発中のものです。
07/05/03 18:36:59 l4cqkKLa
JAVAでもいいなら「オブジェクト脳のつくり方」がお勧めだぞ。
UMLの超簡単解説もあるし。
例題が業務システムなのがアレだが、
本質的な部分はC++も同じだから大丈夫かと。

348:名前は開発中のものです。
07/05/03 19:06:09 aROKnpN+
アレコレ言ってもしょうがないんでとりあえずUMLに触れてみて
どうやってコレを使ったら自分の助けになるのか
自分なりに理解するのが大切だと思いますよ

349:名前は開発中のものです。
07/05/03 21:21:39 ykGFiN+W
>>344
書籍で理論や共通知識を学ぶのも良いけど、ある程度コーディングできるように
なったら、「ホンモノ」のコードを読んでみるのも良い勉強になるよ。

個人的には UNIX V6 のソースコード読んで勉強したクチなんだが、いまどきの
人に薦められるかというと、ちょっと違う気がする。今だと Java, C++ あたりで
良い教材無いかねぇ…

350:名前は開発中のものです。
07/05/03 21:26:04 t/pC1jsI
UMLといってもクラス図くらいしか描かねぇ

351:名前は開発中のものです。
07/05/03 21:47:30 aROKnpN+
色んな図あるけど業務でやらない限りは
クラス図、アクティビティ図、シーケンス図あたりが限度かねぇ

352:名前は開発中のものです。
07/05/03 21:53:36 ifdqR3nP
業務でもそれプラスユースケースくらい

353:名前は開発中のものです。
07/05/03 22:57:52 ykGFiN+W
>>351
俺はアクティビティ図を抜いて、代わりにステートチャート図が追加って感じ。

354:名前は開発中のものです。
07/05/04 13:14:26 ljy2orUl
> 憂鬱なプログラマのためのオブジェクト指向開発講座

これ、全然おもしろくなかた。
わかりにくい。
オブジェクト指向分かってる後によんだのに、わかりにくかった。

「プログラマのための 憂鬱なオブジェクト指向開発講座」に直すべき。


355:名前は開発中のものです。
07/05/04 14:10:22 TiDrCtuu
そんな>>354のオススメ図書は?

いや、あおりでなしに、その本読んだけど分からなくて、今も分からないままなもんで。教えてくらさい orz

356:名前は開発中のものです。
07/05/04 21:08:31 +e+/DrXO
シームレスってどうやんの?
例えば2DのRPGマップをスクロールさせる様なばやいとか

357:名前は開発中のものです。
07/05/04 21:14:04 osoiCnRq
>>356
普通にやれば言いと思うが・・・
どんな状況を言ってるんだ?



358:名前は開発中のものです。
07/05/04 21:44:45 7VEgWe3m
>>356
マップをエリアに分割して、自分が今いるエリアの周囲をメモリに読み込んでおく。
移動して自分がいるエリアが変わったら、不要になったエリアの情報を破棄して
必要なエリアの情報を非同期読み込み。

これだけだが、何か疑問が?

359:356
07/05/04 23:07:32 +e+/DrXO
わかったありがとちん。
作ってみるよ。

360:名前は開発中のものです。
07/05/05 00:05:52 WcHz0Tx6
>>355
あー、俺は、Delphiを使っているうちに覚えてしまったたちでね・・・。
当時は、標準添付ライブラリのVCL使ったり、ソースとか読んだりして、オブジェクト指向を学んだな。

今なら、.NETのライブラリ使ったり、コンポーネント作って、覚えるようなもんだろうか。

習うより、慣れろって感じでスマソ。


あえて言うなら、実践的なオブジェクト指向ということで、
デザインパターンの言及しているwebページとか、本とかかな?
直接関係ないが、開発技法になっちゃうが、XP(エクストリームプログラミング)関連とかも、
OOP前提が多くて、実践的でためになる。
リファクタリング、ユニットテストなど。

あと、Javaでかかれた本とかページとかは、オブジェクト指向前提で参考になるよ。


361:名前は開発中のものです。
07/05/05 01:04:52 EPC7H7SP
なんとなくだが、>>360は見栄を張ってる気がする。
“ためになる” “参考になる”とか言いつつも具体的な書籍やHPも挙げないし、
言ってる事も理解へ向けてと言うよりも言葉で煙に巻く感じで(・A・)イクナイ!!

自分なら>>355には、  オブジェクト指向プログラミング入門  を推す。
内容にがやや教科書的/板書的過ぎるから普通の読み方じゃなく
章単位の読み方とか多少英語論文的な読み方が求められるけどページ数に合った力がつくと思う。

あと、ここでなんか批判されまくってるが、「憂鬱な」はそんな悪い本じゃないと思うぞ。
まぁちらほら賛成できない部分や論理的におかしい部分は見受けるが、それでもなかなかの良書。
もう一度、読み直してみるのもいいと思うが。

362:名前は開発中のものです。
07/05/05 02:25:29 WcHz0Tx6
アホか。見栄はりに2chに来てねーよ。
煙に巻くつもりなら、レスしなけりゃいい。

具体的なページを上げられないのは、当時のをブックマークしてないから。
第一、コード書いて、読んで、実地で学んだと言っているのに・・・。

ただ、「デザインパターン」とか「エクストリームプログラミング」とかキーワード上げてるんだからさ・・・
まあ、ググレカスと言いたいところなのだが・・・


■デザインパターン
サルでもわかる 逆引きデザインパターン 第1章 はじめてのデザインパターン はじめに
URLリンク(www.nulab.co.jp)

Amazon.co.jp: オブジェクト指向における再利用のためのデザインパターン: 本: エリック ガンマ,ラルフ ジョンソン,リチャード ヘルム,ジョン ブリシディース,Erich Gamma,Ralph Johnson,Richard Helm,John Vlissides,本位田 真一,吉田 和樹
URLリンク(amazon.co.jp)
流行になった本だが、実例少なく今となっては読みにくい。CDの中身がまとまっていてよい。

Amazon.co.jp: デザインパターンとともに学ぶオブジェクト指向のこころ: 本: アラン・シャロウェイ,ジェームズ・R・トロット,村上 雅章
URLリンク(amazon.co.jp)

Amazon.co.jp: 増補改訂版Java言語で学ぶデザインパターン入門: 本: 結城 浩
URLリンク(amazon.co.jp)



363:名前は開発中のものです。
07/05/05 02:26:17 WcHz0Tx6

■リファクタリング
オブジェクト指向は直接関係ないけど、おすすめだから読んどけ。

Amazon.co.jp: リファクタリング―プログラムの体質改善テクニック: 本: マーチン ファウラー,Martin Fowler,児玉 公信,平澤 章,友野 晶夫,梅沢 真史
URLリンク(amazon.co.jp)
プロでこれ読んでない奴いたら、殴っていい

Amazon.co.jp: Java言語で学ぶリファクタリング入門: 本: 結城 浩
URLリンク(amazon.co.jp)

ちなみに、コメントないのは、俺が読んでないものなので注意(わかりやすそうなのを上げといた)


長いURL書き込めなくて苦労したぜ・・・

364:名前は開発中のものです。
07/05/05 02:33:04 WcHz0Tx6
あとは、OOPしてる読んでおきたいソース。

一応ゲーム制作技術板だから、ゲーム系のソースでも上げとこうか。

ABA Games
URLリンク(www.asahi-net.or.jp)

Titanion
URLリンク(www.asahi-net.or.jp)

とりあえず、ふつーに、OOPしとるんで読んで参考になること請け合い。
規模はでかくないが、ABA氏の一通り完成されたゲームばかりなので勧めやすい
あと、D言語やJavaばかりだから読みやすいよ。


365:名前は開発中のものです。
07/05/05 04:41:51 nOa25t75
初心者ならオブジェクト指向狂詩曲がいい。
内容はたいしたことは無いが、OOPの作法みたいなものがわかる。
軽く読めるのでおすすめ。

ところでダックタイピング系の書物でおすすめない?

366:名前は開発中のものです。
07/05/05 09:36:59 WcHz0Tx6
>>365
ダックタイピングって、Rubyとか、Pythonのアレですか?
C++とかで実装する方法とかってことですか?

そんな局所的な本なんてでてんのかなー。



367:名前は開発中のものです。
07/05/05 12:08:35 +5LnnL0c
ェネリックプログラミング系の書物がそれにあたるような気が

368:名前は開発中のものです。
07/05/23 19:36:40 yFXY+8Zs
たまにネタふり。

2Dゲームなどで使われる
オーダーリングテーブル(Ordering Table)は、すでに常識でしょうか。
たぶんローカル用語でしょうけど、大体用語がないので、これですませています。

おれは、弾幕ゲーム作ってるんだ!
いちいち、物体ごとに、Zソートしてたら遅くなる!そんな時に使用します。

z値ごとに、ArrayListをもって、バケットソート(バケツソート)するような感じです。
z値が広い場合は、z値を狭めるか(0~100くらいの定数にしてもいい)、
z値を割って使用します。

図では、こんな感じ。

z値
0 →□→□
1
2 →□
3 →□→□ →□→□
4 →□→□

□は物体。

369:名前は開発中のものです。
07/05/23 19:39:22 yFXY+8Zs
>大体用語
代替用語

370:名前は開発中のものです。
07/05/23 20:10:55 yFXY+8Zs
>>368
登録するのを物体ではなく、メソッドポインタなどにすれば、より汎用性が高まると思います。

371:名前は開発中のものです。
07/05/23 20:13:35 tJZKFF0H
久々に凄いネタ振りを見た

372:名前は開発中のものです。
07/05/23 20:46:34 sQffGK0m
人いたんだこのスレ

373:名前は開発中のものです。
07/05/23 21:17:01 h3A9cPXz
ぶっちゃけZソートで重いって8bitCPUかと

374:名前は開発中のものです。
07/05/23 21:37:02 5lNumVZr
最近知って、自慢したくて仕方なかったのでしょうw

使いどころ違うしw

375:名前は開発中のものです。
07/05/24 00:12:03 sQQ2EGyG
>>368
> 物体ごとに、Zソートしてたら遅くなる!
今ならZバッファ使えばいいじゃん。PlayStation じゃないんだし。

376:名前は開発中のものです。
07/05/24 00:19:50 4PByfCCv
>>375
画像処理のことなのか?
まぁ、半透明使うならZソートしといたほうがいいけど

>>368はハッシュとかツリーとか勉強するといいかも

377:名前は開発中のものです。
07/05/24 14:14:16 MN3OTeQA
>>375
3Dのシーンならそれでいいんですけど、
2D主体で、アルファ付きテクスチャ描画が標準、
アルファブレンドを使うのが当たり前、加算合成などが多めになると、
Zバッファが使えなくないですか?

俺、もしかしたら、基本的なところで、ミスってる?('A`)

>>373
毎フレーム、オブジェクトを数千個ソートするのもそんなには重くはないですけどね。

>>374
実は、昔から(DirectDrawの時代)から使ってるんですが、
使いどころ間違ってるのあk-----マジ教えてくれ

>>376
そうです。半透明が多めなんです。

Hashとかツリーは普通に使います。OTの実装もHashと同じですし

378:名前は開発中のものです。
07/05/24 15:21:37 4PByfCCv
hashとかわかってるならなんでそんなことをココに書き込むのだと小一時間問い詰めたい

379:名前は開発中のものです。
07/05/24 15:43:03 a3uG9+mx
・2D主体かつαブレンドを多用
・z値が整数で適当な範囲に収まる場合
ならその方法がいいのかもね
でもゲームによってやり方を変えるのが一番賢いだろうね

380:名前は開発中のものです。
07/05/24 16:17:32 aFaY4/D0
>378
最初にネタふりって書いてあるやん

381:名前は開発中のものです。
07/05/24 16:34:16 uojugi7P
っていうか、2Dのスプライトの場合はZオーダーなんてそう頻繁に
入れ替わるものではないから、前フレームのソート結果を上手く利用すれば、
もっと軽くできると思う。

382:名前は開発中のものです。
07/05/24 16:58:41 FtXKITOW
このスレの90%はネタを振る人間とそれにケチをつける人間でできています

383:名前は開発中のものです。
07/05/24 20:02:03 K0O2WDIn
>>382
残りの10%は?

384:名前は開発中のものです。
07/05/24 20:07:39 KUhBCX3E
ROM

385:名前は開発中のものです。
07/06/04 17:52:58 wXEt1jZx
ROMはいくらいても0%だろう

386:名前は開発中のものです。
07/06/12 16:35:34 KXWIMOSu
同人の俺は気にするほどのゲーム作らないからなー。
後から基数ソートやらに書き換えるつもりでSTLのsortでZソートしたけど
どこにも問題ないのでそのままリリースしたよ。めっちゃ富豪的

387:名前は開発中のものです。
07/06/12 20:19:56 mHZMnLTI
>>386
PS2 でも、そんなもんでした。STLport にお任せ。

388:名前は開発中のものです。
07/06/18 14:54:09 oOcxT9uX
コールバックってどういうときに使うんですか?
タスクシステム(というかハンドラオブジェクト)を使う時の場合において適当な例を教えてください

389:名前は開発中のものです。
07/06/18 15:00:56 2wNoPL2v
コールバックする時。

タスクシステムに限らず、メモリの解放を行ってもらうときとか、
進展情報を表示する時によく使うなあ。

とくに前者の場合は、他の開発環境で作ったDLL内でメモリを解放したいときとか。

390:名前は開発中のものです。
07/06/18 16:26:41 1gQkyo9F
>>388
オブザーバーパターンは便利だよ。
たとえば敵を倒したときにそいつのはいた弾をすべて消すとか、誘導弾のつけなおしとか
なれてくるとほとんどこれだけでイベントベースでコードが出来上がる。


391:名前は開発中のものです。
07/06/18 20:21:44 nIlBSYV8
タイミングが判明する場所と、そのとき行いたい処理との間の結合を
疎にしたいとき使います。
ほとんどこれだけでとか関係なし。必要なところへ必要なだけ使うべし。

392:名前は開発中のものです。
07/06/19 02:59:21 cFac+yZB
>>388
C時代のコードを利用するとき。
C++使えるんならほとんどのコールバックが仮想関数で見た目上は消せるだろう。

つまり仮想関数をCで使いたいときにコールバックが出てくる。

393:名前は開発中のものです。
07/06/19 05:07:59 AmvqVn7S
>>392
あとは、スクリプト言語との連携とか。

394:名前は開発中のものです。
07/06/22 08:30:52 njuyTnq1
Xboxのアレは禁断のボゴソートを使ったとしか思えない

395:名前は開発中のものです。
07/06/22 15:30:47 G4eFb+Vh
>>395
Xboxのアレって何ですか?

396:名前は開発中のものです。
07/06/22 17:18:36 vqNTOWGn
カルドセプトサーガの事じゃないの?

397:名前は開発中のものです。
07/06/22 20:36:17 OntiNUWq
そのタイトル名でググってみたが、これは酷いなw
サイコロが奇数と偶数が交互に出るとかw

398:名前は開発中のものです。
07/06/22 22:02:44 qN22ntrp
>>394
ボゴソートって知らなかった。
URLリンク(ja.wikipedia.org)

これはひどいあるごりずむ

399:名前は開発中のものです。
07/06/22 22:21:08 VTeo1nmT
>>398
これ逆にコーディングの手間がかかるだろw

400:名前は開発中のものです。
07/06/22 22:22:42 +XVLd04M
>ボゴソートは、ソートのアルゴリズムの一つ。
>平均的な計算時間はO(n×n!)で、非常に効率の悪いアルゴリズムとして知られている。
>安定ソートではない。

最後の一行のオチで吹いたw

401:名前は開発中のものです。
07/06/22 22:28:33 0YS4QSdj
ここでボゴソートを使ったゲームを考えるのがゲームプログラマの努・・・ごめん無理

402:名前は開発中のものです。
07/06/23 00:06:58 WPiear32
ボゴソートワロタw

403:名前は開発中のものです。
07/06/24 05:25:19 zQnoyhbz
ワラタ
ソートつーか、バラバラに並び変えるアルゴリズムかとw

404:名前は開発中のものです。
07/06/24 11:16:29 1MtSzEPe
>>400
安定ソートの意味知ってるのかよ('ω`)

405:名前は開発中のものです。
07/06/24 11:33:03 NLW3QANP
>>404
安定ソートの意味知ってるのかよ('ω`)

406:名前は開発中のものです。
07/06/24 11:35:30 rfvCjIOU
>>404-405
知らないよ!(゚Д゚)

407:名前は開発中のものです。
07/06/24 11:54:44 nOj+/xcZ
>>404-405
知らないよ!(゚Д゚)


408:名前は開発中のものです。
07/06/25 03:07:29 qVqBESx6
えーっと、同じ順位のアイテム同士はソート前の順番を保つ、であってる?

409:名前は開発中のものです。
07/06/25 09:30:06 mc9m8oVn
あってる。
この記事のオチはInfinite monkey theoremだよ。ググレ、笑うから。

410:名前は開発中のものです。
07/06/25 10:06:14 U5o2CqSM
セットで RFC2795 もどーぞ。
URLリンク(www.ietf.org)

411:名前は開発中のものです。
07/06/25 20:59:14 NaYhg1aV
>>394-410
スレ違い

412:名前は開発中のものです。
07/06/25 21:35:29 933SMbqm
>>411
既存のゲームにおけるパターンの一端って事で

413:名前は開発中のものです。
07/07/17 22:54:23 Mh0Ht4Or
このスレ生きてますか?
基本的?なデータの扱いについて意見を聞きたいです

データに対応する操作クラス以外から値を書き換えることを禁止するためにこういうクラスを考えました
template <typename T> class IData {
public:
  friend class Mutator<T>;
  typedef T element_type;
  typedef boost::shared_ptr< element_type > value_type;
protected:
  value_type value;
};

template <typename T> class IMutator : public IData<T> {
  typedef IData<T> data_type;
protected:
  void assign(data_type& target) { value = target.value; }
  void swap(data_type& target) { boost::swap(value, target.value); }
};
使う際はこいつを継承して
class CData : public IData<int> {};
class CMutator : public IMutator<int> {};
のようにすれば
CMutatorはIMutatorのassignやswapを使ってCDataのvalueの指すデータを生成から破壊まで自由に扱えるわけです

でもこのようにするとCDataの持つ情報が増えた時に
class CData : public IData<Param>, IData<Graphic>, IData<Sound>のように
継承しまくりになることとか、shared_ptrの機能によるコストが気になったりします

そこでもっと一般的なやり方を知りたいんですが何か良い方法ありませんかね?

414:名前は開発中のものです。
07/07/17 23:05:36 oI0Vf9iA
template <typename T> class IData {
public:
 boost::shared_ptr<T> value;  //!< 漏れ以外勝手に書き換えんなよ!
};

415:名前は開発中のものです。
07/07/17 23:19:26 Mh0Ht4Or
いくら防衛策を巡らせても書く人の意思でいくらでも変えられるから
そんな事考えるのは無駄だよってことですか
言われてみればそういう気もしますが…(´・ω・`)

416:名前は開発中のものです。
07/07/17 23:29:43 9lPCzUGd
多重継承にパフォーマンス(速度・容量の両面で)上の弊害は無いが
役割が酷似した基底(インターフェース)同士を多重継承って嫌過ぎだろ。常考。
衝突避けるためにインターフェース設計の段階でお互い調整しなくちゃいかんし
衝突上等ならキャストだらけの汚ねぇコードになる。俺ならコンポジットにする






417:名前は開発中のものです。
07/07/17 23:32:47 ecw8MgBR
いまいち要求が飲みこめんけど、委譲とかプロキシパターンとか
アダプタパターンとか、ありもののパターンで十分間に合いそうな希ガス。

経験上、複雑な仕組みはロクなことがない。
Keep it simple stupidですよ。

苦労して得られる利益が少なくて割が合わないパターンでは?

418:名前は開発中のものです。
07/07/18 00:07:21 xDBgIMCC
どうも
よく考えたらIDataはインターフェースじゃないっすね…
全く異なる型を同士でコンポジットにしてアクセスも上手く制限できる事って出来るんでしょうか

要求としては
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事
です

操作されるデータの実体へのポインタを持つIDataと、それを扱うインターフェースIMutatorに分けたのは一番目のため
多重継承したCData経由でデータを扱うのは2番目を実現するため
データの実体へのポインタであるIDataのvalueメンバをprotectedにし
Mutatorをフレンドにしたのは三番目の為

以上によってゲーム内でのオブジェクトの振舞いは全てIMutator派生クラスのCDataに対しての操作として
書くことが出来て、リソースの確保等のシステム的な動作は外部に一任できる

という意図があったんですが、そんなに複雑ですかいね?

419:名前は開発中のものです。
07/07/18 00:28:49 JHo6PQLB
・データと動作を分離する事と
・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること
・書き込み専用のクラス以外からのアクセスを制限する事

つまりテンプレートで実装する意味はないよね?

420:名前は開発中のものです。
07/07/18 00:37:53 9FpPIZ4u
>>419
ないね

421:名前は開発中のものです。
07/07/18 00:57:12 IHWjkDA2
> ・書き込み専用のクラス以外からのアクセスを制限する事

IMutatorを継承すればどんなクラス以外からでもアクセスできる以上、
制限できてるとは言いがたい。

「IMutatorの継承を無闇にするな」と、文書で説明する?
ならば、414でいいでしょ。

422:名前は開発中のものです。
07/07/18 02:48:50 vN51PGaN
>>418
> ・動作をデータに対してではなくゲーム上のオブジェクトに対して書けること

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

423:名前は開発中のものです。
07/07/18 05:52:53 1k3Xg7ZP
なんか奇想天外なことになってるのは
>・データと動作を分離する事と
これのせいだと思う
誰が吹き込んだんだか知らんがまず>>413がしなきゃいけないことはこいつを殺すことだ

424:名前は開発中のものです。
07/07/18 18:10:13 sTmzL7Mk
class CData : public IData<Param>, IData<Graphic>, IData<Sound> {};

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

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

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

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

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

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

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

426:名前は開発中のものです。
07/07/18 20:55:21 ux1Fssbs
>>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 だけ使用 */ };

こういう話かと。

427:名前は開発中のものです。
07/07/18 20:55:52 ux1Fssbs
>>426
s/メンバ変数のセット/メンバ関数のセット/g

428:名前は開発中のものです。
07/07/18 23:49:47 1k3Xg7ZP
>>425
>値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてる
なんでそうしなくちゃいけないか理由は分からないの?
プログラムは芸術じゃないんだから外の人のどうしたこうしたで中身が変わったりしないよ?

429:名前は開発中のものです。
07/07/19 00:19:41 RaZNmmmq
> 値を保持するクラスと操作するクラスは分けろこのスカポンタンとか言われたのでそうするようにしてるんですが

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

430:名前は開発中のものです。
07/07/19 00:38:54 PDuVn1ka
>>429
だよな多分

431:名前は開発中のものです。
07/07/19 05:21:01 5YEt12VO
getterとsetter作って、アクセス管理するくらいしかやったことねえや
触らせたくないなら、関連クラスからのみアクセスとか(C++ならfriend?)

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

432:名前は開発中のものです。
07/07/19 11:40:10 LxxDZCLh
少人数・小規模製作でアクセス制限も糞もないわな

433:名前は開発中のものです。
07/07/19 15:01:29 3ArgKadV
少人数小規模だろうが、
開発期間中に、年単位で空白があったコードを読むこともあるわけで。

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

434:名前は開発中のものです。
07/07/19 18:50:40 TacCeKvZ
アクセス権?になってくるとまた話が変わってきちゃうんだが
そんなファイルのパーミッションみたいな機構小規模だろうが大規模だろうがつけたらあかん
というか無駄、損がないというか何の得もない

435:名前は開発中のものです。
07/07/19 18:59:00 ajveBJeZ
とりあえず理由を

436:名前は開発中のものです。
07/07/19 19:27:00 3ArgKadV
なんでファイルのパーミッションの話になってるんだ
>>432のアクセス制限って、クラスのメンバーに対することで、
>>433のアクセス権ってのもそのことだろ?

437:436
07/07/19 19:27:51 3ArgKadV
変な日本語になった

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

438:名前は開発中のものです。
07/07/19 19:39:53 /RFbeqQb
「使いたいものを使いたいときに即使えないのはうっとうしい」
ということではなかろうか>ファイルシステムの例え話

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


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

439:名前は開発中のものです。
07/07/19 20:12:33 TacCeKvZ
>なんでファイルのパーミッションの話になってるんだ
おまえがアクセス権なんていうからじゃん

440:名前は開発中のものです。
07/07/20 12:39:13 vUDuhb3O
スレタイを百回声に出して読んでくれ

441:名前は開発中のものです。
07/07/20 12:40:51 vUDuhb3O
ついでに二人とも正座な

442:名前は開発中のものです。
07/07/20 21:52:02 +3gqdIHH
難しく考えすぎ。

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

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



443:名前は開発中のものです。
07/07/20 22:07:32 lyxTTGt6
「する」「しない」の二択にするという話ならその通りだが
特定の状況でのみ●●に大して××させることを許可するとかいう話なら
ソースレベルで静的に操作するのは困難

444:名前は開発中のものです。
07/07/20 22:32:40 +3gqdIHH
動的にアクセス権を与えたいなら、まずは隠蔽しておいて、
状態に応じてアクセスを許すかどうかを決めればいいのでは。

445:名前は開発中のものです。
07/07/20 22:52:28 +3gqdIHH
本当にアクセス制御の問題で困っている人が大勢いるなら、
今頃boostにそれらしいクラスが含まれていると思うけどね。

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

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

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

446:名前は開発中のものです。
07/07/21 00:49:20 DMrsrXyJ
ナンセンス。この一語に尽きる。

447:名前は開発中のものです。
07/07/21 01:16:04 oWQ5iQEX
progress_displayがあるのにそんなこと言われても説得力無いなぁ

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

448:名前は開発中のものです。
07/07/21 03:00:31 DMrsrXyJ
動的ってことになってくるとそれは普通にインターフェイス呼び出し時の
認証の機能の話になってしまうんじゃ?RMIとかそーいった話の流れ方向での

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

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



449:名前は開発中のものです。
07/07/22 02:55:07 /VC165Eo
>>443
インターフェースを多重継承して、必要な時・相手にアップキャストしたものを渡せば。

450:名前は開発中のものです。
07/07/22 03:36:44 jrExVTdK
簡単な具体例も挙げてくださいお願いします

451:名前は開発中のものです。
07/07/22 13:24:51 /VC165Eo
>>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() でメンバ変数書き換えを許可

452:名前は開発中のものです。
07/07/22 15:08:54 PSHVXCKb
>>447
functionって40byteも食うの?
その半分くらいですみそうなんだけどな。

453:名前は開発中のものです。
07/07/22 18:59:44 jrExVTdK
なるほど、呼び出す側にインターフェースを渡すんですね
参考になりましたありがとうございます。

454:名前は開発中のものです。
07/08/05 01:30:04 CiKwXSKt
boost::functionって便利だけどむちゃくちゃヒープが汚くなりそう

455:名前は開発中のものです。
07/08/05 07:10:10 4IAfjfpf
>>454
小さなオブジェクトが多数 new されそうって意味? 気にしなさんな。

456:名前は開発中のものです。
07/08/05 07:37:18 CiKwXSKt
まあ、それが気になって使ってない、という訳じゃないけどねえ。
アロケータ作れば何とかなるだろうし。

457:名前は開発中のものです。
07/08/05 20:35:16 ki20ixME
javaでTCBを使いたいんだけど、どうしてる?

458:名前は開発中のものです。
07/08/05 20:46:45 4IAfjfpf
>>457
ふつーにメンバ変数使えばいいだけでは? Task Control Block なんてのは、アセンブリ時代の名残だから、
C++, Java あたりでは使わんでしょ。

459:名前は開発中のものです。
07/08/06 00:04:42 Mz0XA0lP
ゲームのデータを独自のフォーマットとかにする場合にヘッダを用意する?

460:457
07/08/06 00:40:04 wjb80OI1
URLリンク(ueno.cool.ne.jp)
こんな感じに組みたいんだけど、javaには関数ポインタがないので、引っかかり中。


461:名前は開発中のものです。
07/08/06 00:44:36 N/EWx1nS
>>460
まじめに勉強したら?

462:名前は開発中のものです。
07/08/06 00:45:37 N/EWx1nS
というかあからさますぎて夜釣りに思えてきた

463:名前は開発中のものです。
07/08/06 02:03:36 dDj8AjaH
TCBと言えばRTOSなので
ここはeCosに実装されたwabaを紹介してやるのが筋だろうか

464:名前は開発中のものです。
07/08/06 03:43:57 r8MqGT/t
ppc arm super wabaなら・・・

465:名前は開発中のものです。
07/08/06 07:16:51 R+5scQVe
>>460
Java だとインターフェースもしくは抽象基底クラス使う。

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

467:457,460
07/08/06 22:41:30 dCjdYchV
だれか経験豊かなjavaプログラマた通りかかったりしないかなぁ。


468:名前は開発中のものです。
07/08/07 00:03:46 ziyaQFb3
Vectorじゃだめなのか

469:名前は開発中のものです。
07/08/07 00:17:53 2nrPyfF8
やはり釣りだったか

470:名前は開発中のものです。
07/08/07 00:42:53 lyE3j1c/
HSPでOOPをやろうとするのと同じくらい馬鹿げてるな

471:名前は開発中のものです。
07/08/07 01:25:29 /sDbVbxZ
>>466
ぐちゃぐちゃ言ってないで書いてみろ。あんまりにも考察がめちゃくちゃで
どこから突っ込んでいいのかわからん。ソース晒してみれば突っ込みも入れやすい。

472:名前は開発中のものです。
07/08/07 01:55:24 sukzLC0P
>>466
日本語でおk

473:名前は開発中のものです。
07/08/07 03:33:11 jZSDWWPE
>>466
参照使え馬鹿

474:名前は開発中のものです。
07/08/07 03:37:03 Qoe4Y4zA
なんでみんな冷たいんだwww

475:名前は開発中のものです。
07/08/07 06:44:09 vUw1LN3Q
>>468
LinkedList の方が。

476:457,460,468
07/08/07 07:55:20 8/4fXdca
void (*func) ();
これのjavaでの代用法が知りたい。


477:457,460,468
07/08/07 08:07:53 8/4fXdca
LinkedList ....
Thanks! >> 475

478:名前は開発中のものです。
07/08/07 08:09:00 /sDbVbxZ
>>476
java.lang.Runnable func;

479:名前は開発中のものです。
07/08/07 08:24:51 88OVU+XC
>>466
aを要素にとるコンテナを宣言して
それにb1インスタンスだのb2インスタンスだのを加え、
コンテナを走査して処理メソッドを順に呼び出せばいいだけの話。

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

480:名前は開発中のものです。
07/08/07 10:39:17 98Sz9x7X
なんかタスクってGoToやってるような雰囲気があるな

481:名前は開発中のものです。
07/08/07 10:48:42 TDGAxW6A
>>476
>>460では関数ポインタ使ってなくね?

482:名前は開発中のものです。
07/08/07 14:27:28 lyE3j1c/
まぁvtableは関数ポインタみたいなもんだけどな。

483:名前は開発中のものです。
07/08/07 14:28:52 gmxLaOKz
>>478
Swingでやってハマるとかw
関数ポインタに直感的に一番近いのはjdk7までお預けだな。

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

484:名前は開発中のものです。
07/08/07 15:06:05 2nrPyfF8
>>483
日本語でおけ

485:名前は開発中のものです。
07/08/07 19:51:36 LOGzBd/R
自分が話理解出来てないだけなのに日本語でryとか言ってる奴増えたよね。

486:名前は開発中のものです。
07/08/07 20:52:36 2nrPyfF8
>>485
>Swingでやってハマるとか

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

487:名前は開発中のものです。
07/08/07 23:28:41 rZkCIKw7
Swingがスレッドセーフではないって話かな。

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

488:名前は開発中のものです。
07/08/07 23:51:16 vUw1LN3Q
>>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;
};

489:名前は開発中のものです。
07/08/08 00:01:44 2nrPyfF8
>>488
優しいな

490:名前は開発中のものです。
07/08/08 07:33:12 71C/M+UG
たったこれだけのことなのに
さも凄まじいシステムであるかのように
タスクシステムと言う人の気がしれない

491:名前は開発中のものです。
07/08/08 07:48:40 4PM0J5aw
>>490
歴史を勉強しましょう

492:488
07/08/08 07:51:26 obrNCieZ
>>490
同意。

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

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

493:名前は開発中のものです。
07/08/08 07:53:43 HMa+110c
今とは比較にならない制限の厳しさの中で
TCBを弄り回してた時代のことを知らないんだろね


494:名前は開発中のものです。
07/08/08 08:21:56 XmcrCIW0
そういう話題は以下のスレでやってくれ

タスクシステム総合スレ
スレリンク(gamedev板)

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

496:名前は開発中のものです。
07/08/09 01:24:51 Tm6LW0Jp
>>495
それなんか設計がおかしくないか?
みんなの意見無視ってところか

497:名前は開発中のものです。
07/08/09 02:27:45 RcnrWFRi
>仕様上、基底クラスから上位のクラスをたどる必要があったので、
そんな仕様にするのが悪い。
第一、抽象基底クラスを知っているのならば
そんなところで困ったりしない。

498:名前は開発中のものです。
07/08/09 02:50:07 yVPi3RJq
初心者には冷たいもんだな

499:名前は開発中のものです。
07/08/09 03:14:21 v8CPCZuZ
というか言語仕様勉強しろ

500:名前は開発中のものです。
07/08/09 04:12:56 k08h5JG9
キャストってw
ポリモフィズムをカケラも理解しとらんじゃないか

501:名前は開発中のものです。
07/08/09 04:46:19 BskRNsfr
自分から質問してきたくせに
まともな意見すら無視するような勉強不足君は
鮮やかに放置して、次の話題ドゾー

502:名前は開発中のものです。
07/08/09 05:27:24 nQyaGvDb
まともな意見を無視するのと勉強不足なのは関係ないと思うぞw
質問者はどちらの属性も持ってるけど

503:457,460,466,476,495
07/08/10 20:04:16 aK9bbQO3
失礼。

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

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


504:名前は開発中のものです。
07/08/11 20:49:07 AcYB8hIq
>>503
さんざん情報貰ったんだから、せめてソース晒して恩返ししてみないか?

505:名前は開発中のものです。
07/08/17 01:53:51 7sSY46ad
JavaSEでVectorつかってそーだな・・・

506:名前は開発中のものです。
07/08/21 16:35:31 /oULNmRu
質問すまそん。DXライブラリ&VC++でゲーム製作してます。

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

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


507:名前は開発中のものです。
07/08/21 18:54:06 /OCncB5N
ちゃんと管理できるなら問題ない

508:名前は開発中のものです。
07/08/21 19:55:25 LQCVNOKZ
>>506
>>507に同意
オブジェクト指向をしたいのか、ゲームを作りたいのか。
書き方に明確な規則やルールがあれば、それだけでいいと思うけどね。

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

1.ゲームシステム=ゲームの中の宇宙を作る(ゲームシステム=プログラム本体)
2.宇宙の中に惑星を一個作る。(ゲーム世界(日付等含む))
3.ゲームの世界の中に、登場人物やアイテムを作る。(キャラクターデータ、アイテムデータ)
4、登場人物とアイテムは、状態を所有している。(フラグ)

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

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

509:名前は開発中のものです。
07/08/22 02:49:01 xHfctKqh
>>505
標準ライブラリが互換性のために未だに使いまくってるんだが・・・。
んで使い勝手悪いからいい加減JCFに移行しろと叩かれてるじゃないか。

510:名前は開発中のものです。
07/08/22 10:20:41 lSyOGrel
Universe.MilkyWay.SolarSystem.Planets.Earth.Enabled = false;


511:名前は開発中のものです。
07/08/22 21:45:27 HTZJHbeS
>>508
> 単純に現実に沿って状態を作る(これがRPG向きか?と言われると、そうではないけど)
単一システムで作るのは、結構つらいなぁ。

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

512:名前は開発中のものです。
07/08/22 21:58:56 9DW3Phyd
>>506が心配してるようなのって構造化手法の方の話で
オブジェクト指向とはあんまり関係ない気がする
オブジェクト指向言語は結局構造化手法の流れを汲んでるから関係あるっちゃあるんだけど
「オブジェクト指向的」に批判されることはないと思うんよ

513:名前は開発中のものです。
07/08/22 22:26:25 9DW3Phyd
>>508はこの方針でゲーム作ってなんかあったらここへ相談しにきてね

514:名前は開発中のものです。
07/08/23 00:15:28 mSgl7P3T
>>60が参考になるんじゃね

515:名前は開発中のものです。
07/08/24 15:43:24 C1/M3//R
>>513
>>510みたいなことは流石にやってないけど、マップが複数面あって
自由にキャラクターを選べるのを作ってるから、今のやり方で全く問題なかったりするぜ!

516:名前は開発中のものです。
07/09/01 13:35:04 +CS1vDDV
>>510おれもそんな感じだww

517:名前は開発中のものです。
07/09/01 15:26:53 AAlSvZp8
>>516
お前って奴は…

518:名前は開発中のものです。
07/09/01 18:53:13 pEzsrlB5
チラウラだが .NETの自動生成コードとか見ると
クラス名がネームスペース入りのフルネームで書かれてて
>>510と比べてもあまり遜色ないくらい長ったらしい記述になってる

519:名前は開発中のものです。
07/09/03 18:50:24 pkJ0HJ1y
>>510はどこまでが名前空間でどこからがコレクションなんだろ

520:名前は開発中のものです。
07/09/03 18:56:19 l4kjvmoQ
Universe.、までが宇宙空間

521:名前は開発中のものです。
07/09/03 20:58:24 nm3JiNC1
Planetsまでじゃないのか

522:名前は開発中のものです。
07/09/03 21:43:06 l4kjvmoQ
C#とかだと区切り記号が全部ピリオドだから分かりにくいよなあ

523:名前は開発中のものです。
07/09/03 22:51:36 4m5q0iOi
俺ならPlanetsは入らないな。
Universe.MilkyWay.SolarSystem.Earth

しかし、こんな話題しかないものか。

524:名前は開発中のものです。
07/09/03 23:01:33 nm3JiNC1
いいんじゃない、超光速星間航行を多用するスペースオペラ的ゲームのデータ構造。

525:名前は開発中のものです。
07/09/04 00:01:23 aU+sltFh
>>522
そんなこと言いだしたらjavaのエンクロージング型の完全修飾名は恐ろしいことになる。

526:名前は開発中のものです。
07/09/04 00:51:30 SZHcTWC/
外から内部クラスをアクセスすることはほとんどないんじゃね?

527:名前は開発中のものです。
07/09/04 01:36:58 aBG3sZkW
>>522
Delphiはわかりにくいと申すか

528:名前は開発中のものです。
07/09/04 01:47:09 h5r4WGWI
まあDelphiもC#も、同じヘルスバーグ氏設計の言語だからな
俺は氏の思想は好きだが

529:名前は開発中のものです。
07/09/04 09:17:06 /fq60VcD
どっちもIDEで使うための言語だからそんなに問題にならないでしょ

530:名前は開発中のものです。
07/09/04 14:17:11 A5VD8Kop
C#はCLRで使うための言語だろ。
VSがIDEなだけで。

531:名前は開発中のものです。
07/09/04 17:20:53 /fq60VcD
独立して使えるように体裁は整えてあるし確かにそうなんだけど
#regionとかpartialとかIDE向けの機能があるのは確か

URLリンク(www.atmarkit.co.jp)
>Q.C# 3.0では、型推論によって読むのが難しいコードになってしまうのではないか?
>A.Visual StudioのIDEを強化すればおk

さすがにスレ違いだなすまん

532:名前は開発中のものです。
07/09/04 18:32:28 1MQtcsKR
まあ、確かに動的な型変換と型推論は型の決め方が違うから読み辛い。
というかC#は既存言語の枯れたパラダイム
てんこもりにしただけのくせに信者が騒ぎだすんだろうなぁw

533:名前は開発中のものです。
07/09/05 22:29:15 wushZy2l
アンチうぜぇ

534:名前は開発中のものです。
07/09/06 00:13:48 XDEo8NLL
信者うぜー

535:名前は開発中のものです。
07/09/06 01:04:58 ojjbKURb
突然何の脈絡もなく言語叩きをしだす馬鹿は放置して次の話題ドゾー

536:名前は開発中のものです。
07/09/07 00:33:06 B51b23c5
JAVAとかC#とかってキャストないよね

タスクシステムのワーク領域のキャストってどうやるのかな

537:名前は開発中のものです。
07/09/07 00:44:42 GaWvLQQX
>536
今どきそんなC時代の古典的「タスクシステム」に無理矢理合わせようとしないのが正解。

538:名前は開発中のものです。
07/09/07 00:54:28 qKvVhzB0
>>536
だからインターフェース継承しろと。どうせメモリ管理は GC 入ってるんだし。

539:名前は開発中のものです。
07/09/07 09:56:16 +KS6LJ+F
キャスト自体はあるだろと

まぁC++でもそんなコードかいてたら殴り倒すけど

540:名前は開発中のものです。
07/09/07 10:04:18 puv664XK
>>539

シューティングゲーム プログラミング
松浦 健一郎 (著)

この本ではC++でワーク領域のキャストしてたけど、殴るの?


541:名前は開発中のものです。
07/09/07 10:07:03 ODKwq4Ib
ワーク領域のキャスト(笑)

542:名前は開発中のものです。
07/09/07 11:36:49 +KS6LJ+F
それ悪い見本だろ

543:名前は開発中のものです。
07/09/07 12:02:42 xHXwrHzM
>>542
普通に使ってたよ
本を書いてる人を殴れる程、出来るプログラマーなの?あなたは


544:名前は開発中のものです。
07/09/07 12:51:19 6U+LdAPY
松浦 健一郎 (著)、じゃなくて
松浦 健一郎 (笑)の間違いだろ。


545:名前は開発中のものです。
07/09/07 13:28:52 43uHszUC
MAKKENは殴ってよい

546:名前は開発中のものです。
07/09/07 13:54:05 NUmtK/nu
>>540の本って継承知らない程度の初心者向けの本ってところか?
継承使わずにやるやり方にページ割くくらいならさわり程度でも継承教えたほうがためになりそうだが・・・

547:名前は開発中のものです。
07/09/07 16:11:07 g09BD/TG
>>543
>>542が出来るプログラマーかどうかはわからんが、
基本的に日本だと本を出す奴ってのは3流だから
とりあえず本出してる人すごいって認識は改めたほうがいい。

548:名前は開発中のものです。
07/09/07 16:48:36 HXEpQNDZ
3流は本すら出せんだろ

549:名前は開発中のものです。
07/09/07 16:51:44 wO5yXJcP
>>547
三行目に同意
俺も高校まではそういうステレオタイプを持ってた

550:名前は開発中のものです。
07/09/07 17:54:50 VwzOSVjv
じゃあ「俺よりは凄い」で。

551:名前は開発中のものです。
07/09/07 20:37:04 B51b23c5
ここは自称凄い人がたくさんいるスレですね


552:名前は開発中のものです。
07/09/08 00:42:34 hAtUkBFn
>>546
一応継承は使ってるみたいだよ
new deleteのオーバロードも使ってるし

だから単に継承を使ったやり方をしらないだけじゃね

553:名前は開発中のものです。
07/09/08 02:39:33 RITYgY6W
最近のライターがコード書けんのは確かだな。

554:名前は開発中のものです。
07/09/08 07:47:53 bNPXbGtI
はいはいスレ違い

555:名前は開発中のものです。
07/09/13 22:14:56 1Bt3Jrj9
"Those Who Can't Do, Teach"という言葉があってだな。

シューティングの本?
同人シュー作者の俺がそのうち書いてボコボコにしてやんよ

           ∧_∧
        つ≡つ);:)ω・).,,';
   _| ̄ ̄||≡つ=つ  )
 /旦|―||// /|   \
 | ̄ ̄ ̄ ̄ ̄| ̄| . |∪ ̄\_)
 |_____|三|/

556:名前は開発中のものです。
07/09/13 22:42:21 sAjH+7xy
>>553
正直、本を書いてもあまり儲からないんだよな……。前に技術書書いたことがあるんだが
印税8%で初版3000部とかだったから、時間単価考えたらコード書いてた方が遥かにマシ
だった。

もう少し幅広く売れる本とか、時間かけずに書けるとか、その後の仕事受注につながる類の
ヤツなら良いんだが。

557:名前は開発中のものです。
07/09/13 22:44:13 p9GEmztQ
何系の本なの?ゲーム系?ハード系?
それとも普通の言語系?

558:名前は開発中のものです。
07/09/13 23:27:43 sAjH+7xy
>>557
ネットワーク系。だいぶ前だけど、当時は翻訳やら執筆やらイロイロやってた。
今じゃすっかりコンサル稼業で、趣味でしかコードかけない人生だけどな……。

559:名前は開発中のものです。
07/09/14 00:00:01 qAC7e6UH
技術書って印税8%も来るのか。

560:名前は開発中のものです。
07/09/14 01:56:40 kBeEhHlB
>>559
でも 1 冊 2,000 円 x 8% x 3000 冊だと 48 万だぜ。駆け出しのプログラマだった頃は
実質 1.5 ヶ月かけても割に合ったけど、もうダメだ。金以外に何か目的がないと
やってられんよ。

561:名前は開発中のものです。
07/09/14 04:58:49 CTgFkt8N
やねうらおさんですか?

562:名前は開発中のものです。
07/09/15 18:37:54 odGWNMQb
けっこう、計算するとシビアな値段だな・・・
人生掛けてまでやることじゃない
クソ本あろうとしったことか!

あ、俺?俺は、情報商材にして、単価上げて(゚Д゚)ウマー

563:名前は開発中のものです。
07/09/15 20:05:14 5hbSwr+P
自分の備蓄禄だと思えば良いじゃない。

何ページで執筆に何カ月かけたか知らんが、
コード書けない人間なら数こなせば良い金になるな。
eclipse本なんてコード書かなくても良いしソフトの新版出る度に改定するから副業にはちょうど良いじゃないか。
デザインパターン本なんて同じ内容なのに言語ごとにあるぞ。

コード書いて食ってる人間に本なんて書いてる暇があるかは知らんが・・・。

564:名前は開発中のものです。
07/09/15 20:15:34 zE0h51TJ
日本の場合、コード書いても食えない人間ばかりだろ。
だから低レベルな本しか出てない。
そんな本ばかりだから若い人が育たない。
で、その若い人がコードで食えないから、さらに劣化した本を書くというスパイラル。

565:名前は開発中のものです。
07/09/15 20:27:26 lBqIBG3l
と、コードを書けもしない人間が申しております

566:名前は開発中のものです。
07/09/15 21:30:05 kmdFdmdy
>>564
> 日本の場合、コード書いても食えない人間ばかりだろ。
というか、単価の高いプログラミング仕事がほとんどない。

大手ゲームメーカーでリードプログラマやるより、中小の基幹システム改修
案件の SE やってた方が全然収入がいいという。技術的にもプロジェクト運営の
面でも、ゲーム屋の方が大変なんだが。

567:名前は開発中のものです。
07/09/16 03:07:48 YcEkQAYx
しょせん日本のマは末端の土方

568:名前は開発中のものです。
07/09/16 07:52:57 hBA8iHMq
プログラマなんて、IT土方だからな

569:名前は開発中のものです。
07/09/16 09:22:16 bdw4UY6n
>>568
GoogleとかMSだと給料高いけどな。現地ではなく日本採用でも。

570:名前は開発中のものです。
07/09/16 09:44:24 hBA8iHMq
>>569
プログラムだけできるだけじゃ、入れないところじゃねーか


571:名前は開発中のものです。
07/09/16 11:01:46 5DEnzRu4
>>569
M$はともかくgoogleは給料安いんでないの?福利厚生はともかく給料は。

572:名前は開発中のものです。
07/09/16 12:12:44 bdw4UY6n
>>571
Google は給与水準公開してないから情報限られるけど、俺が中の人から
聞いた話だと十分高いと思った。

それより株式公開前にストックオプション貰ってた連中は、上場と同時に
億万長者の仲間入りしちゃってるから、それと比べると給与はどうでも
良いっつー話らしいが。

573:名前は開発中のものです。
07/09/16 19:28:45 OIlosS2z
絶望した。上場したてのGoogle株を買って、任天堂に乗り換えれば
たった3年で20倍になってる事実に絶望した。
絶対うまいこと乗れたギーク系投機家がどこかにいるはず。

574:名前は開発中のものです。
07/09/16 20:24:04 JalQ3AgQ
お前ら良いなgoogleが上場とか、俺の頃はまだyahooすらなかった。
CEREN vs NCSAのhttpd戦争終結後くらいか・・・。


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch