リアルタイムストラテジーの話

**名無しさん＠お腹いっぱい。** · 01/11/17 12:31

age of empireとかstarcraftみたいな
リアルタイムストラテジーの開発の話題

**名前は開発中のものです。** · 04/10/01 08:15:10

だいぶ前にこの板に経路探査の技術を議論するスレ立てたんだけど
すぐに削除されてしまってがっくりきたんだけど
このスレでも経路探査について話し合われてるね
RTSの肝はやっぱ経路探査法だね

私も最終的にはRTS作りたいと思ってるんだけど
現段階では経路探査法をいろいろ模索してる最中です
なかなか人間らしい経路探査法が見つからない

RTSの経路探査専門のスレ立てたいけどまた削除されるのかな
削除の基準とか知ってる方いらっしゃいますか？

**名前は開発中のものです。** · 04/10/01 14:26:36

>>265
普通にA*でいいんじゃねーの？
人間らしいって基準が曖昧すぎるし。

**名前は開発中のものです。** · 04/10/01 18:42:12

普通のRTSだと経路探索はA*一択だとおもう。
後はそれをどう高速化するかの問題で。
確かGame AI Programming wisdomにEmpire Earthが使ってる
アルゴリズムが詳しく書かれてたような。
スレは一定以上の書き込みがないと自然に落ちるんだった気がする。
話題の範囲が狭すぎるし立てても盛り上がらないと思うが。

**名前は開発中のものです。** · 04/10/01 19:38:24

このスレじゃだめなの？
話題あるなら、振ってみては？
盛り上がって、専用スレたてる必要が出たら、建てればいいじゃないかと。

**名前は開発中のものです。** · 04/10/01 20:50:48

ダイクストラ法かな。メモリ食うけど早いぞ

**名前は開発中のものです。** · 04/10/02 06:20:14

"A*"で検索かけても
「"A" は一般すぎる言葉のため、検索には使用されていません。」
って出てきて検索できないｗ
A＊について詳しい解説載ってるHPなど教えてください

**名前は開発中のものです。** · 04/10/02 07:16:25

http://gamdev.org/w/?%5B%5BAStarAlgorithmTutorial%5D%5D

**名前は開発中のものです。** · 04/10/02 07:24:49

>>271
ありがとうございます
早速見てみます

**名前は開発中のものです。** · 04/10/05 05:48:54

人間らしいと言うのは、視界を考慮した移動ですよね。
「見える範囲内で最短経路を移動する」
を繰り返して目的地へ移動する。
ただし、これだとすぐに行き止まるし、最初から迂回することは出来ないよね。

プレイヤーの視界をユニットの視界としているなら問題ないけど、
それなら通常のA*となんら変わりはない。

**名前は開発中のものです。** · 04/10/05 11:19:18

ストラテジーの場合、というか戦争を行う場合、
情報収集を事前に行うのが大前提で、
普通のA*的な移動を行う方がリアリティあると思う。

目的地への地図も無いまま当ても無く進軍するなんて
聞いたこと無いし、大体、目的地の方角と距離が
わかってるんだったら、そこまで行くまでの地図を持ってるだろ？

斥候の移動に関してなら同意かも。

**名前は開発中のものです。** · 04/10/06 04:56:40

>>229
グラフィックでは？
AoEなら、8方向でさらに攻撃ややられた時のアニメーションまで考えると膨大な量になる。

**名前は開発中のものです。** · 04/10/06 05:23:38

1ｹﾞｰﾑでだいたい何人くらいのグラフィッカーが関わってるんだろうか？

**名前は開発中のものです。** · 04/10/06 06:05:27

あらかじめ場合分けして数個から数十個の条件分岐で経路探査できるようなルーチンを考えてます
マップ上で障害物を認識するためにあらかじめマップに処理を加えてます

**名前は開発中のものです。** · 04/10/06 06:14:59

A*が駄目な理由が解かりませんよ。
アルゴリズムが理解出来ないのなら仕方ないけど。

**名前は開発中のものです。** · 04/10/06 07:45:46

経路選択と陣形に整列させるのがRTSで一番難しいﾌﾟﾛｸﾞﾗﾑかな？
ﾊﾞﾗﾊﾞﾗに配列されたﾕﾆｯﾄを効率よく陣形に整列させるのは難しそうだな～

**名前は開発中のものです。** · 04/10/06 07:56:36

>>275
ｸﾞﾗﾌｨｯｶｰが必要だね

**名前は開発中のものです。** · 04/10/06 09:10:33

Glest Customizable RTS
Version 1.0.1 of Glest was recently made available, a project that aims to create a free,
customizable RTS game. While the project is currently closed source, the toolset allows
nearly every aspect of the game to be altered and customized.

（Excite翻訳)
Glestのバージョン1.0.1は最近利用可能になりました、プロジェクト、それ、自由なカスタマイズ可能な
RTSゲームを作成する目的。プロジェクトが現在ある間、出所を閉じた、toolsetは、ゲームのほぼすべての
面が変更されカスタマイズされることを可能にします。

:: Glest ::
http://www.glest.org/

RTSツクール？

**名前は開発中のものです。** · 04/10/07 00:06:04

>>279
陣形はsin,cosで簡単にできる。

**名前は開発中のものです。** · 04/10/07 06:17:51

>>282
三角関数で
「与えられた陣形にフィットするように各配置それぞれに最も近いキャラクターを移動させる」
とか
「マップ上に通行不可能なオブジェクトが配置されていた場合それにそって陣形を歪める」
とか
全部計算できちゃうんですか？

**名前は開発中のものです。** · 04/10/07 06:33:58

>>283
三角関数は回転だけですよ。

**名前は開発中のものです。** · 04/10/07 08:59:41

ｺﾝﾋﾟｭｰﾀｰﾌﾟﾚｲﾔｰの賢いＡＩ作るのも難しいだろうな
ＡＩの善し悪しによってｹﾞｰﾑのおもしろさが違ってくるし
ＲＴＳ制作は敷居が高いな…

ｺﾝﾋﾟｭｰﾀｰﾌﾟﾚｲﾔｰが町作りや資源採集、戦闘したりするＡＩって
手間がかかりそうだな…

**名前は開発中のものです。** · 04/10/08 10:04:47

地形が正方形のタイルを敷き詰めて表現されてる場合
上下左右に1タイル分移動する時の距離を１とすると
斜めに1タイル分移動するときは距離√2＝1.4移動することになって
しまって斜めに移動するとかなり早く移動できてしまう矛盾を修正するにはどうしたらいいいのかな？
上下左右に１タイル移動するのに時間１かかるとすると
斜めに1タイル移動する時間を1/1.4＝0.7として表現すると
どんなプログラムになるんだろうか？

**286** · 04/10/08 10:09:22

×1/1.4＝0.7→◎1.4

**名前は開発中のものです。** · 04/10/08 16:53:57

>>286　ふと思いついた４つの方法。
・気にしない　（確か旧WARCRAFTはそうだった）
・クウォータービューにしてみる
・移動のタイミングを計るカウンタを１．４倍にしてみる
・進行方向θ、移動距離Ｒとして、 sin & cos でＸとＹの移動量を算出する

**名前は開発中のものです。** · 04/10/09 01:46:44

FreeCraftというオープンソースのWARCRAFTのクローンがあったよ

**名前は開発中のものです。** · 04/10/09 06:45:43

>>288
4番目の方法は解決になってなくない？
タイルベースだから移動量を半端な数にできないって話なんだから。一度に長距離を進めるのならともかく
その方法を使うには結局位置を実数ベースで所持して、格子上の整数に投影するなどする必要がある

ついでにもう一つ案を加えるなら
５．ヘックス型の升目を採用する

**名前は開発中のものです。** · 04/10/09 16:27:09

>>288
＞・移動のタイミングを計るカウンタを１．４倍にしてみる

ここのところをもっと詳しく説明お願いします

**288** · 04/10/09 17:54:06

>>290
タイル状に地形データを保持しているマップの上をスムースに移動できるＲＴＳだと思って
いたのだけど…違った？>>286　その時は勿論 X,Y は実数や固定小数点に。
大戦略のようにタイルごとに大きく進むとしたら、 sin , cos を使う方法はバツか。

>>291
例えば、 QueryPerformanceCounter() などで、ユニットを動かすタイミングを計っている
ときに、 10000 カウントに一回動かしているユニットを斜め移動の時だけ 14000 カウント
に一回動かす方法。　カウンタは各ユニット１個ずつ保持。
…よく考えると、あまり良い方法じゃないかな。

**名前は開発中のものです。** · 04/10/09 18:15:20

>>286
目的地が隣接8マスのみでそれぞれに同じ移動時間がかからなければならないなら
座標を計算していくのではなく移動した割合(1秒に10%移動などして)をもとに座標を計算。

地形がマスだからって移動をマス縛りにする必要はあまりない気もするけど。

**名前は開発中のものです。** · 04/10/10 00:24:57

sin.cosで良いんじゃないか？
でかい升目のRTSってあまり見かけないし

**名前は開発中のものです。** · 04/10/10 01:11:51

AoEは縦方向への移動は遅いと思ったけど。

**名前は開発中のものです。** · 04/10/10 09:15:31

2Dで高低差を表現するのは難しそうだね
坂をなめらかに表現したり
ｷｬﾗがちゃんと坂を上ってるように見せたり（平面を歩いてる時とは違って
坂の凹凸に投影される影の付け方や坂のでこぼこに合わせてｷｬﾗも上下するような細かいところ）

**名前は開発中のものです。** · 04/10/14 16:55:44

人いないね～ｗ

**名前は開発中のものです。** · 04/10/14 20:16:03

>>296
3Dでもでこぼこに影つけるのは結構面倒だよ。

RTS って技術的にかなり総合力が必要だよね。
MMORPGなんかのほうがはるかに楽な気がする･･･。

移動ルーチン、敵の思考ルーチン、大量のキャラクターの表示、
視界計算等等。

まぁ、敵の思考ルーチン以外はセオリーは知れ渡ってるけど、
とっかかりにくいことも事実だよな。

**名前は開発中のものです。** · 04/10/16 17:37:22

移動ルーチンはだいぶん形になってきた
まだ一個の障害物でテスト運行中だけどどんないびつな形でも
スマートに回避して目的地点に行くようになったな
まだ少しバグは残ってるけどバグ退治したら
複数の障害物を避けれるようにしようと思う

**名前は開発中のものです。** · 04/10/17 00:09:18

さんびｬｸﾊﾞﾝｹﾞｯﾄ

**名前は開発中のものです。** · 04/10/19 14:07:21

グラフィックの勉強しようと思って手本としてAOCを選んだわけなんだけど
AOCのMODスタジオ使ってグラフィック抜き出して見てみたんだけど
グラフィックの量がものすごい多い

色の使い方が絶妙で真似できないよ
手書きをスキャナかなんかで取り込んだのかなって思うくらい配色がうまい

**名前は開発中のものです。** · 04/10/19 15:02:10

フリーのRTSゲームないかな？
どんなもんか見てみたい

**名前は開発中のものです。** · 04/10/19 15:14:47

>>302
フリーのRTSがみたいならコレ
http://www.glest.org/eng/index.htm

RTSというものを見てみたいならage of empiresシリーズの体験版

**名前は開発中のものです。** · 04/10/19 15:20:26

>>303
３DのRTSは作るの難しそうですね
勉強のために日本人の素人が作った２DのRTSが見てみたいです

**名前は開発中のものです。** · 04/10/19 15:33:06

>>304
国産は見たことないなぁ

厳密にはRTSというジャンルに入らないだろうけど
RTS風の戦闘をするゲーム
Makuri version3.00
http://www.broba-web.jp/zzzaaa/

**名前は開発中のものです。** · 04/10/19 15:44:14

>>305
早速やってみました
敵をなるべく多くで囲んでたこ殴りにしたほうがいいみたいですね
参考になりました

**名前は開発中のものです。** · 04/10/19 17:26:21

>>301
AOCのグラフィックは、3Dでモデリングしたものを、2Dのアニメパターンに落としてつかってたと思ったけど

**名前は開発中のものです。** · 04/10/19 17:32:03

>>307
なるほどそうでしたか…
情報ありがとうございます

**名前は開発中のものです。** · 04/10/20 13:35:09

やっぱ製品とフリーでは雲泥の差があるよね
特にグラフィックとキャラのアニメーションがしょぼいと見栄えが悪いね

**名前は開発中のものです。** · 04/10/21 06:53:33

Glest はフリーにしちゃよく出来てると思うよ。
ＣＧだって、製品には及ばずともなかなか健闘してると思う。

製品でもいいけど日本製のＲＴＳってなんかあるの？

**名前は開発中のものです。** · 04/10/21 07:01:31

>>310
ハンドレットソード

**名前は開発中のものです。** · 04/10/21 19:08:24

PATHEngine
http://www.pathengine.com/

経路探索のエンジンらしい。デモのミニゲーむずい。

**名前は開発中のものです。** · 04/10/21 20:47:14

>>312
二面の途中でやめたんだけど先に進むともっと複雑な地形が出てくるのかな？
二面までの地形は単純すぎてエンジンのすごさを実感できないな…

**名前は開発中のものです。** · 04/10/22 00:51:29

まぁ１００歩ぐらい譲ってA*による経路検索は出来たとしよう。しかし、ユニットで経路がふさがれた時の挙動や
建築や伐採で地形が変形した時のA*ツリーの再構築方法等はかなりどうしていいかわかんない。

WarCraftとかDOSの時代に動いてたRTSはまさにオーパーツだな。どうなってんだ？

**名前は開発中のものです。** · 04/10/22 00:59:57

>>312 ２面で敵に殺された。経路探索について知りたいのに！

**名前は開発中のものです。** · 04/10/22 01:10:07

地形の変化への対応は再探索が普通なんじゃないのか？

**名前は開発中のものです。** · 04/10/22 01:14:10

>>314
(1) マップから特長点を認識して特長点だけのマップを作っておく。
(2) 特長点のマップを使ってA*で経路探索して結果だけNGの道も含めて保存しておく
（この経路行けるかなと思ったけどダメだった）も含めて多めに保存。

(3) 地形が変更されたら、特長点マップも変更されるかも。
(4) 特長点マップが変更されて、その変更が(2)の結果にかかってたら、そこから計算やり直し。

でどうだろう？データ量多すぎかな。

**名前は開発中のものです。** · 04/10/22 04:19:53

>>314
昔は検索しやすいようなデータ形式でそれに見栄えをあわせる、
ってことをしてたわけだけど、今は見栄えがまずありきで、
それだと検索のしやすさなんか無視だからね。

本当はＰＣが賢かったり登場するユニット数が多いほうが
面白いゲームが出来るような気がするけど、流れ的には
見栄え重視だよね。

**名前は開発中のものです。** · 04/10/22 15:15:32

>>312
この程度の経路探査なら
A*使わないでできてるけど

**名前は開発中のものです。** · 04/10/23 23:40:28

移動ルーチンは８割がたできあがったけど他のプログラムやグラフィック、音楽などがまだ一つも完成してない

**名前は開発中のものです。** · 04/10/23 23:53:15

しかしなんでこんな汎用アルゴリズムにGoogleで検索しづらい名前つけるんだろね

**名前は開発中のものです。** · 04/10/24 00:53:20

A*が考案されたのは1968年だぞ…無茶言うなよ。
ただ検索しにくいってのには同意。

**名前は開発中のものです。** · 04/10/24 11:27:34

それではこれからこのスレは一時A*の新しい名前を考えるスレということでよろしいでしょうか？

**名前は開発中のものです。** · 04/10/24 12:18:53

*から連想されて
Aが付くとなりゃ決まってる！

　　　　　　　　　　　　　　　　　　　　　　　　　　ｱﾅﾙ

**名前は開発中のものです。** · 04/10/24 12:46:29

A*ってどうやって検索すればいいの？
Aを含んでると検索してくれないんだけど…

A*関連のHPを片っ端から紹介してください

**名前は開発中のものです。** · 04/10/24 12:51:47

pathfinding "a star"

**名前は開発中のものです。** · 04/10/24 12:57:44

A*の日本語HPってないのかな…

**名前は開発中のものです。** · 04/10/24 13:40:23

>>325
http://www.google.co.jp/intl/ja/help.html

**名前は開発中のものです。** · 04/10/24 13:46:38

>>327
http://gamdev.org/w/?%5B%5BAStarAlgorithmTutorial%5D%5D
http://plus.naver.co.jp/browse/db_detail.php?dir_id=107&docid=27003
http://mikilab.doshisha.ac.jp/dia/research/report/2004/0716/004/report20040716004.html
http://kyu.pobox.ne.jp/softcomputing/ai/ai3.html

**名前は開発中のものです。** · 04/10/24 23:37:01

PATHEngine 作者インタビュー

ttp://ai-depot.com/Interview/PathEngine.html

**名前は開発中のものです。** · 04/10/25 01:29:36

どっちかといえばA*のアルゴリズムよりもノードの動的な構成方法の方が謎領域だな。
２Dコリジョン上で複数ユニットを動かすなんて10人いたら10人とも同じもの作りそうなんだが
何故か全然情報ないんだよね…。

国産のMMOでもまともに経路検索してるの無いし。海外のはちゃんとMobが障害物に挟まらずに
追ってきたりするのに。

**名前は開発中のものです。** · 04/10/25 10:52:22

>>307
3Dでモデリングしたものを、2Dのアニメパターンに落とすツールかソフトないでしょうかね…

**名前は開発中のものです。** · 04/10/25 10:56:55

AOCのグラフィックをMOD　PACK　STUDIOで見ると同じキャラでもパターンのサイズがいろいろ違うね
普通は32×32ドットとかパターンサイズを統一してると思うんだけどな

**名前は開発中のものです。** · 04/10/25 13:49:53

>>302
EmpireTohuっての見つけたぞ
http://i-saint.abz.jp/pg/

SDL+OpenGL+Luaつー環境もなかなかアツイ

**名前は開発中のものです。** · 04/10/25 14:42:21

>>334
まだ開発途中だけどAOMみたいで形はできあがってる感じだね
３Dだしﾐｻｲﾙの弾道や爆発ｼｰﾝもかっこいい
参考になりました

**名前は開発中のものです。** · 04/10/26 00:38:26

>>331
日本のゲームプログラマの質の低さを物語っていますね。

**名前は開発中のものです。** · 04/10/26 00:42:40

AoEはグラフィッカーが50人ぐらいでは？

**名前は開発中のものです。** · 04/10/26 00:43:46

>>337
それは多すぎだよｗ

**名前は開発中のものです。** · 04/10/26 03:27:23

GoogleにA*で検索できないぞｺﾞﾙｧって言えば案外対応してくれそうな気もする。
理系集団だし。

**名前は開発中のものです。** · 04/10/26 05:31:04

50人って多すぎかな？
FF10は100人で作ったらしいけど、そのうちグラフィッカーは
50人以上いるでしょ？

**名前は開発中のものです。** · 04/10/26 05:37:39

　8bit時代のロートルぷろぐらまだす。

　なんか漏れ的に懐かしい話題のスレのようなので、
俺が大昔に書いた経路選択処理を書くっす。

a.マップ（スクエアマップで斜め移動は1.4倍コスト）と同じサイズの整数2次元配列を用意し、「未到達」値で初期化
　（以後の処理は全てこの配列を対象とする）
b.移動目標とするべき地点に、その重みに応じた「重要度」数値をプロット（小さいほうが重要箇所）
c.配列全てをスキャンし、「重要度」がプロットされている地点の
　隣接スクエアに「元の地点の重要度＋スクエア間移動コスト」を重要度としてプロットする。
　（既に重要度がプロットされている場合は、新しい値が小さくなるときだけプロットする）
d.移動させたいユニットのスクエアが「未到達」でなくなるまでcを繰り返す
e.ユニットは値の「重要度」値の小さいほうに移動する

　ってやって、目標設定も一緒にやってた。
データ処理量の問題とかありそうだけど、ま、何かの参考になれば・・・・

＃思考ルーチンスレにも似たこと書いたけど、
＃こっちのが具体的に書いたので重複許して。

**名前は開発中のものです。** · 04/10/26 11:19:48

>>341
目標地点を基点にしてA*で探索すれば配列全てをスキャンしなくてもすむと思うんだけど、気のせい？

**名前は開発中のものです。** · 04/10/26 14:01:17

>>342
　まぁ、基本的にはそう。
　最終的には(A*は知らなかったけど)もう少しましな実装にしたいなぁ、とは思ってた。

　だけど、
a.思考ルーチンも兼ねてて、「複数の目標のうち、どれを選択するべきか」ってのも
その処理でやらせてた（今考えるとさもしい発想かも・・・）
b.コード側のメモリ制限が厳しかったので、メモリ食いそうなコードを書きたくなかった
c.配列を1枚プロットすれば、他のユニットにも使いまわせたので、
　合計処理時間は意外とかからなかった

　ので、そのまま実用にしちゃった:p

　マップサイズが小さかった（確か80x50）から
全スキャンでどうにかなった、といえばそうかもしれない。

**名前は開発中のものです。** · 04/10/29 02:13:59

>>334
それ全然経路検索してねーやん。ユニット重なりも怪しい。

そう言えばフロントミッション：オルタの経路検索も酷かったよね。和製RTSの恥部って感じ。

**名前は開発中のものです。** · 04/10/30 06:18:16

米軍は衛星や航空部隊が、味方と敵の位置と移動方向を把握して、
司令部が計算し、現場の戦車に移動方向や弾を撃つ方向を指示する。
測量から、１秒もかからないで、イラクの戦車に命中。

でも歩兵の場合は、おおまかな指示が歩兵のディスプレイに伝えられる
だけで、あとは歩兵同士のP2P通信で、現場で判断して行動してください。

**名前は開発中のものです。** · 04/10/31 18:17:41

音声P2P通信って奴だな

**名前は開発中のものです。** · 04/10/31 20:51:10

移動ルーチン思ったよりバグが多かった
バグフィックスにだいぶかかりそうだ･･･

**名前は開発中のものです。** · 04/11/04 16:55:51

人いねーｗ

まじでRTSの話で盛り上がりたい

**名前は開発中のものです。** · 04/11/04 21:15:38

話題なさすぎだな

**名前は開発中のものです。** · 04/11/07 08:58:53

LANで存在しているホストを調べるにはどうしたらいいんですか？

**名前は開発中のものです。** · 04/11/09 21:14:03

どなたか、AOE開発元のアンサンブルスタジオがHPに載せてた経路選択についてのレポートの
ある場所教えてください

**名前は開発中のものです。** · 04/11/10 23:04:35

やっぱRTS作るなら戦略的に面白くなるように高低差のあるマップじゃないとな…
AOEのように高低差をなめらかに作るのむずかしそうだな
directX８で高低差のあるマップの作り方書いてるサイトないかな？

**名前は開発中のものです。** · 04/11/11 19:04:07

HightMapじゃだめかな

**名前は開発中のものです。** · 04/11/11 19:04:46

HeightMapでした失礼
googleに「もしかして」って指摘されたOTL

**名前は開発中のものです。** · 04/11/11 19:19:14

>>353
HeightMapってなんですか？
検索したけどあまり詳しくかいてなかったので

**名前は開発中のものです。** · 04/11/11 19:37:35

Terrain rendering の方が検索しやすいかも
http://www.google.co.jp/search?hl=ja&c2coff=1&q=Terrain+rendering+&lr=

**名前は開発中のものです。** · 04/11/11 19:38:41

>>356
英語苦手なんですｗ

**名前は開発中のものです。** · 04/11/11 19:40:28

>>356
おすすめのHPとか教えてください

**名前は開発中のものです。** · 04/11/11 19:43:26

苦手なだけなら頑張ればいいじゃん

**名前は開発中のものです。** · 04/11/11 19:45:23

AOEの地形の変化にも柔軟に対応した経路選択ってどうしてるんだろうな…
１ﾌﾚｰﾑごとに経路選択用の地形ﾃﾞｰﾀを更新してたら重くなるしな

**名前は開発中のものです。** · 04/11/11 23:55:46

>>355
2次元配列で高さを管理する方法。

**名前は開発中のものです。** · 04/11/12 00:50:24

>>360
地形が変化したときだけ、経路探索用データを更新すればいいんじゃない？

**名前は開発中のものです。** · 04/11/12 04:57:53

>>361
もっと詳しく説明おねがいします
>>362
あちこちで森を切ったりしてるから頻繁に更新しないといけないかも
私が使ってる経路探査用地形ﾃﾞｰﾀを一ﾌﾚｰﾑごとに更新したら超ｽﾛｰになったので
そこらへんどうしてるのかなと思いまして

**名前は開発中のものです。** · 04/11/12 05:37:46

>>363
説明しよう！
heightmapとはxy方向に等分に分割したマップである
頂点は周りの8方向の頂点と合計4つの四角形を構成し頂点を共有するので
メッシュを別個に置いていく方法と比べて滑らかにできる
もちろん分割数が少ないとカクカクになり、分割数が多いととても滑らかになる
ちなみにDirectXSDKサンプルにも収録されている
自然な地形の作り方はgame programming gemsなど

**名前は開発中のものです。** · 04/11/12 06:06:05

>>363
別に１フレームごとに更新することは無いんじゃない？
ちょっとずつ更新して、２秒に一回更新することにしたら？
コストが100分の１以下になるよね？

AoEって高さの概念って攻撃力ぐらいじゃなかったっけか？