游戏编程，技术讨论 第五章 ： unit design

tensaix2j

[第三章]  Fog of war  

fog of war ， 就是 还没 explore 的地方， 就会 黑漆漆 一团，
explore 过的地方， 就 会分两种，
第一种 是 当 有 属于 你的unit 在附近， 那就会看到 清清楚楚。。
第二种是， 已经explore 过的地方，但若没有 你的unit 在 附近， 就 只看到 greyed out 的 map。。。

你们 会 用什么方法？

tensaix2j

刚刚找到这个 open src 的engine。。
但我暂时还是想亲手写。

http://www.cs.ualberta.ca/~mburo/orts/orts.html

sson

原帖由 tensaix2j 于 17-5-2008 02:33 PM 发表
可是， 若障碍不存在的话，
你是否会看到那个物件 先往diagonal 路线跑在往horizontal 或 vertical 路线跑。。。。

不太明了你的意思。
1 2 3
4 5 6
如果是使用 8 方位移动方式，从 4 移动至 3 ，
一定是 4（斜向）- 2（横向）- 3，或 4 （横向）- 5（斜向）- 3
但若使用的是自由方式则会穿过 2 ，5 间而达 3 。

看过了你的演示，虽然不知道你如何实现，不过总算达到了最基本的移动了

小章鱼没有真正做过手机游戏。


～Fog of war～
嗯，这个小章鱼也是没有实现过，只是有思考过罢了。
不过结果不太如意，感觉不怎么有效率。
你有什么构思么？


小章鱼也是不鼓励使用他人的引擎，除非你对那引擎用技术很了解，主要是如果不了解，日后要扩展你的游戏很难。

呵呵，为了你的帖，这阵子可是经常上来

tensaix2j

其实 我一直是拿starcraft 来做参考。。。我发现它的物件的movement 并不会 restricted to 0, 45, 90, 135 ..... 的角度，而是 可以是 任何 角度的移动的 例如 21度 13 度。。。。etc

在 test01 我只是 停止它的移动若它的移动会遇到collision。但他的
target xy 保持所以 一旦它的移动不会造成collision的话， 它就会继续移动。。但不会绕道。。。就是如果障碍一直不动，它就会卡在那边

不过 我刚刚 完成了 绕道的 部分。。。 但还没想怎么optimize
你看会不会 怪怪的。。。

在test02，我加了 left mouse drag and select 的功能。。
right mouse 就是移动

test02
(这次不打包那个 1.3 mb 的 interpretor 了。。要的话去download test01 的package）


Fog of war
--------------
我的第一个想法是， 那些黑雾 也是 一片片的 物件。。。
你的第一个想法是什么呢？

[ 本帖最后由 tensaix2j 于 18-5-2008 01:12 PM 编辑 ]

sson

starcraft 小章鱼没玩，只是看过罢了。
具体怎么样不晓得，不过估计多数是采用混合式的。
像地面单位，估计是 8 方位移动，移动时若有障碍允许在有效范围内绕道（自由移动）
天空单位，估计就是自由移动了。
至于你说的回旋角度，因该是允许 360 度移动过渡。

多单位选择的功能不错 ，不过感觉很慢……



呵呵，小章鱼的第一个想法就是不画
因为状态估计因该就只有 3 个
1. 可视
2. 不可视（全黑）
3. 探索过，可是不在可视范围（半透明）
render 方面还好，就是如何有效的取舍和设置这 3 个状态没有一个明确的思路

tensaix2j

你是说 八方为移动 不一定是 45，90，135，。。。 度的吗？

starcraft 的空中 物体 仔细看其实 也没 overlap的。。如果 overlap的话就很奇怪了。。。 会看到一群飞机 合体 画面上只看到好像剩下一架。。


-------------------------------------------

是有点慢， 我还没想到 怎么 optimize 那个碰撞测试的地方，现在还是 O（n2）。（暂时）。。跑差不多 500 个物件时就显然很慢。。但我还有一个后路，就是可以 compile 这个 interpreted script去 bytecode 。。 document 上说 会快 10 倍。


-------------fog of war---------------------------------
的确只有三种 state for 这个 东西
看来， 那三个 状态 是 apply to 那些 tiles
然后 render 的 时候 决定  

第三个 状态 比较特别， 就是 看到 场景， 但看不到 物件。。
该怎么做好呢。。

sson

嗯，实际移动，还是 45 90 135 ，不过在视觉上（图像）做一些过渡动作，
starcraft 没有记错，也是 Tiles 的。
tile 就是一人一格，就不会有你说的 overlap 了。
就是 overlap 了，加上图像的设计（倾斜 45 度）一前一后有距离感，看起来也就很正常。


就用上面说过的 grid 就可以。
不然就做个最简单的取舍，
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
这是单位列表 Array ，有 10 个单位。

1. for(var i =0; i < list; i++){
   
2.     item = list[i]
   
3.     for(var j = i+1; j < list; j++){
   
4.         item2 = list[j]
   
5.         collision(item, item2)
   
6.     }
   
7. }

复制代码

这样就省去了很多。


～fog of war～
看不到，就不要画咯
又回到之前的取舍，看不见的自然就过滤掉了，在 render 的时候根本就不在渲染列表了。

难道你目前的 test02
在地图 scroll 到别处（看不见物件的地方），你的物件还是照样画？

tensaix2j

starcraft 的tile 应该很小。。可能小至一tile 一 pixel，
因为我在map editor 里可以摆放那些人时，移动是+- 1 pixel 的。。。


也就是说，这图里的人一个占50-80 个tiles

[ 本帖最后由 tensaix2j 于 19-5-2008 12:29 AM 编辑 ]

sson

如果是 1 pixel 就不叫 tiles 咯，貌似你对 Tiles 的理解有点错误。
Tiles 其实是一种地图管理方式
而在地图上的单位实际可以因为单位的移动、物理模拟而处在 tile 和 tile 之间（过渡动作）
你在做地图的时候是不能画半格的对吧？
Tiles 地图的好处是单位和地图的碰撞检查非常方便简单，做 A* 等也很便利，渲染也很方便。

所以游戏设计时，一般一个 tile 多是地图的基础大小（跟图像设计息息相关），
而一个基础地图的大小一般也就是游戏正常角色的大小。

tensaix2j

我对tile 的理解是：
它是 地图上 一格一格 的 grid 。 基本上是 每格 只可以装一个物件


可是 starcraft 的物件呢， 你实在看不出它的 tile 有几大。。
因为它的基础大小正是 1 pixel 。你可以任摆放在不 overlap 的地方
而 那些物件 应该不是 在 过度动作中， 因为， 你一开始游戏，他就是不动，也就是已经定位了..

那我问你， 在  过度动作中 overlap 是允许的吗？

sson

是的，Tile 和 Grid 基本上是一样，不过运用在不同的地方，所以使用方式也不太一样。
Tile 不一定是只是放一件咚咚，Tile 只是一种管理方式，
譬如一个地图使用 Tiles 管理并允许 multi layer ，那么一个 Tile 里就不只一个东西了。

如果 Tile 是 1 个 pixel （总而言之太小）就没有意义了，并且占用的记忆空间也不小。
所以之前小章鱼才会推荐你去多了解些数据结构和管理。
因为懂了这些，在设计游戏时（图像，程式）就比较容易配合，也容易设计更优化的程式。


“而 那些物件 应该不是 在 过度动作中， 因为， 你一开始游戏，他就是不动，也就是已经定位了.. ”
过渡动作中也可以“暂停”呀，这只是一种移动模拟方式，和 Tile 没有关系。
过渡动作中可以在有效的范围内重叠，毕竟游戏是倾45度方式（starcraft）。
可能这间中有点小误会，请问你对小章鱼所说的“过渡动作”的了解是？

tensaix2j

过度动作？  
我的理解是 从 tile 去 tile 的移动过程

不好意思 ，我对中文的 术语比较生疏。。。

你的意思是， 我在 map editor 里，摆放那些物件时
有些我摆在 “半格”的 是 其实 还在 过渡动作 中？
不过， 这里完全不允许 从叠的 哦。

tensaix2j

我做个实验如下



你画的出它的tile grid 吗？
它们的x y 的 delta都很小 不是 一个tile的差别哦

sson

嗯，大概是这样。

依你的图的大小， Tile 的大小大概应该是 24x24
而这单位大概就是游戏里最小的单位了吧？
这单位的宽和高大概是 20x30 吧，所以基础大小是 20x20
允许的重叠范围就是 -x:0, +x:0, -y:10, +y:0
仔细看，从上到下摆列的单位，头覆盖了脚步些许吧？
这就是倾45度的呈现方式。


再次声明 Tiles 只是用来管理地图，方便单位和地图的碰撞测试。
所以和单位的移动和位置没有关系，只要单位不处在“不可行走”的 Tile 就可以。

在这游戏中，估计如果你把单位移动到空地上（没有其它单位），该单位应该就会停在 Tile 正中，
不过也有可能开发者加入了一些允许偏差，让它看起来比较不规矩。


[ 本帖最后由 sson 于 19-5-2008 03:18 PM 编辑 ]

tensaix2j

问题是， 有些占 一个 tile，有些占两个tiles（各一半），有些占4 个tiles （各四分之一）

如果，你是说 那些 在2个1/2 ，或4个1/4 格 的是在 过度中？？
好像不是woh

tensaix2j

我还发现 就是如果不可行走 的是半个tile ，或更小的话，
另个单位 依然 会进来赛 ， 直到 没有空间 为止。。

sson

那个……
都说了， Tiles 和单位的移动和位置是没有直接的关系的。

另外说 starcraft 是用 Tiles base 也是小章鱼自个儿的推断，不一定正确。
Tiles = 24x24 也是小章鱼估计的，不过现在想起来，32x32 的可能性更高。
你捉张有画地图障碍物的图来看看（就是有 clift 什么的）。

不过是不是用 Tiles base 没有太大的关系，重要的讯息是 Tiles 只是一种地图的管理方式和移动结果的位置没有关系

tensaix2j

他一定有tile 只是很难理解 他的size， 然后如何配合 过渡动作
而且， 它的 terrain 的tile 是 isometric 的。。。

sson

嗯，游戏是采用全倾45度呈现。
那个绿色的框就是你设计地图是的最小格子吗？如果是，那她的 Tile 的大小就是那格子了，
转换成数据管理的大小，应该是 128x128（小章鱼认为会比较好算，虽然在 isometric 中应该是 64x64）

不要把数据结构和管理跟呈现方式混合来想。

如果还是不能理解，尝试把

宽除于 2 ，然后旋转 45 度。

tensaix2j

你又错了。。。
因为， building 的tile 是 90 degree (quad)的。。