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

tensaix2j

building 最小的tile 可以看到
terrain  最小的tile 也可以看到
unit 最小的tile，看不出来， 估计 （1x1)或 （2x2）

[ 本帖最后由 tensaix2j 于 19-5-2008 05:37 PM 编辑 ]

Squall_Chua

那個角度的tile應該是先rotate 45度
然后再把height給scale成一半吧

tensaix2j

我是觉得你把 单位跟 地图 的数据管理混合来想了。
基本上， starcraft 的 单位的 tile 是  1x1 或 2x2

因为 实际上玩，
若给你一个 完全空的地图， 给你摆放一个 单位

你可以 把它定位到 各个地方， (@delta of 1 - 2 pixels)
它的 building 的tile 就比较大， (@delta of 20-30 pixels)
。。。而terrain的tile是最另类的。。。

[ 本帖最后由 tensaix2j 于 19-5-2008 06:52 PM 编辑 ]

sson

原帖由 tensaix2j 于 19-5-2008 05:32 PM 发表
你又错了。。。
因为， building 的tile 是 90 degree (quad)的。。

建筑物也是一种单位，跟 tile 又没有关系……

原帖由 tensaix2j 于 19-5-2008 05:36 PM 发表
building 最小的tile 可以看到
terrain  最小的tile 也可以看到
unit 最小的tile，看不出来， 估计 （1x1)或 （2x2）

都说了，如果一个 Tile 是 1 pixel 或 2 pixel 根本没有意义……

原帖由 Squall_Chua 于 19-5-2008 05:45 PM 发表
那個角度的tile應該是先rotate 45度
然后再把height給scale成一半吧

小章鱼并不是在叫他如何建立这种 isometric view，只是要给他看一个 tile 的概念。
实际建立时也不是旋转 45 度就可以，因为这样尺度会不方便使用。

原帖由 tensaix2j 于 19-5-2008 05:50 PM 发表
我是觉得你把 单位跟 地图 的数据管理混合来想了。
基本上， starcraft 的 单位的 tile 是  1x1 或 2x2

因为 实际上玩，
若给你一个 完全空的地图， 给你摆放一个 单位

你可以 把它定位到 各个地方， (@delt ...

说你呀，却反过来说小章鱼……
都说了 Tile 是用来管理地图的，当单位要更地图做碰撞时比较方便，渲染地图时也方便……
跟单位在地图上的位置没有关系，影响单位的直接关系的是移动运算或物理模拟什么的……

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

tensaix2j

恕我看不懂你想表达什么。。

不然，用实例 来给我解释好了。。

比如你的tile 的size， 就说 20x20 好了。
现在， 你有个 物件， size 也是 20x20 , 目前站在
x: 40 y: 40 的位置。

那我问你， 你可否 让这物件 站在 x: 28 y:28 的位置呢？

先不考虑 障碍， 就个空map

tensaix2j

原帖由 sson 于 19-5-2008 09:22 PM 发表

建筑物也是一种单位，跟 tile 又没有关系……
.

我知道建筑物也是一种单位，但并非跟 tile 没关系。。

你没仔细看那张图， 它的建筑物 用另一种模式的 tile，which is 不是 isometric的。
而且 摆放 building 时 就可以明显看到 这个 building占几个tile 。。

例如，那个 command center 是 占 4x3 个 tile
而且 building 的tile 跟unit 不一样的。。

sson

如果小章鱼的解释让你觉得迷惑，真的很抱歉，
毕竟小章鱼对这项目没受过什么正规的教育，无法明确的表达。


关于你的例子，有何不可？
小章鱼想不到有什么原因不可处在这个位置。


之前也说过，小章鱼没有玩过 starcraft ，只是高中时看过朋友玩罢了，说错了还请见谅。

不过无论如何，Tiles 是一种管理方式，isometric 是一种呈现方式。

游戏中（starcraft）虽然地图是以 isometric 来呈现，
并不表示一定要真正的 isometric ，游戏中渲染的地图图像也可以是正方形的而不是菱形的。
全倾45度咱们叫它 2.5D 对吧？也就是伪 3D ，既然可以有伪 3D ，为何不能伪 2.5D ？
反正 2.5D 本来就是一种视觉技巧来欺骗玩家的视觉让其感觉 3D。

已经成熟的技术是固定的，但使用的方式依然是灵活的。
要实现同一种效果，方法太多了。

为何要执意于 “building 的tile 跟unit 不一样的”？
小章鱼有看那张图，也知道是这样，但为何单位（unit）一定要占据一个 Tile ?
1.75 Tile 一样可以，毕竟单位和地图是两码事。
游戏中的建筑物要把它对齐网格（snap to）主要是让玩家不会把空间弄得乱七八糟，而且也有善用 Tiles 的优势。
如果游戏采用上面说的“伪 2.5D”来实现地图，那么就更容易解决了。

在你自己的游戏里，你也可以让玩家高兴怎么建就怎么建呀。


小章鱼的感觉是你并未真正的了解 Tiles 的作用和用法。
再用回之前的建议，先做个 Pacman 游戏，不过现在推荐做 2 个 Pacman
第一个是鸟瞰图方式的（传统），第二个是全倾45度（像 starcraft）

tensaix2j

照你这么说，

每个 tile 里是keep 一个list 的东西 对吗？


例如
tile[1][1] = {　obj1  obj2   obj3  obj4 }
tile[0][2] = {  obj 5 }
tile[3][4]  = { obj 6  obj7 }

sson

如果你有你的绝对理由，酱业没有问题，反正 Tiles 只是一种管理。
不过小章鱼没有酱做过，理由是感觉没有什么优点，加上如此一来 pointer 会很多，管理起来不方便，
对大地图记忆消耗也大。

不要忘记 Tiles 用来管理地图罢了，并没有管理物件。
一般小章鱼是用 struct 或其它的结构

1. struct Tile {
   
2.     Moveable // 1 byte，这个用来记录该处可不可行，简单的 boolean 就可以，不过小章鱼用 1 byte，方便其它的记录。
   
3.     rIndex // 2 bytes，这个是用来记录该用什么图像，渲染时用。
   
4. }

复制代码

以上是简单的地图单位，当然还可以更复杂。

tensaix2j

只有两个人 在 讨论。。。闷啊。。

Squall_Chua

我都有在看的


看過了你的sample后
我也打算做個類似的sample來試試自己的想法
不過最近都不得空

tensaix2j

太好了。。。 大家一人写一份， 才有当年那种 感觉。。。

我可以申请 精华 吗

[ 本帖最后由 tensaix2j 于 20-5-2008 07:09 PM 编辑 ]

cristiano~7

在地圖編輯器上當你編輯地形（那個45度的格子），四個tiles會被修改，地形的格子中心正好是四個tiles的中心
比如説如下
tile0   tile1   tile2
     (0,0)   (1,0)
tile3   tile4   tile5
     (0,1)   (1,1)
tile6   tile7   tile8
修改(0,0)的地形會影響到tile0,tile1,tile3,tile4,修改(1,1)的地形會影響到tile4,tile5,tile7,tile8


Why are Locations square, rather than isometric like the tiles?
The isometric look of StarCraft is achieved in StarEdit by combining square tiles that have isometric image characteristics. For performance and technical reasons, StarCraft maintains terrain internally on a rectangular grid.

tensaix2j

那么，要update 每个 tile 的 state

是不是，

每个obj 一移动， 就要 从 current x y 算出 它现在所在的tile 的 indices 还有 obj 移动后，新x y  占住那个 tile的 indices。。。
然后， 看看有没有 差别， 有的话，

就要 把 tile（oldindexx, oldindexy) set 成 空 然后
tile（newindexx，newindexy） set 成 obj ID
for 每个 obj

tensaix2j

更新 test03

用了 tile 来做物件取舍， 果然快了很多。
另加， implement 了 一个 很crude 的 fog of war 。。。

Test03

Squall_Chua

果然有快很多了
path finding上面感覺有比之前的好了
你用什么方法來implement?
那個fog of war有點爛
你應該define每一個object都有個visible radius
醬子就會比較好了
而不是要走到那個tile才visible
醬會看到它走進fog里面

tensaix2j

其实test03里没有path finding。跟test01 一样的.只是换了 coll det的物件取舍的方法。

test02 的问题是，一个物件，当它的 target x y 被占据后， 它一直
会想办法想去那个地点，所以会看到这么多物件好象无法安顿下来那样a

fog of war
－－－－－
这个可以，
不过 我的情况还是会很 rectangular，因为地tile 是四方的..。。我在想看如何弄 那些fog ＂圆＂一点，

[ 本帖最后由 tensaix2j 于 23-5-2008 08:46 AM 编辑 ]

tensaix2j

［第四章］ terrain design

地行上。 基本上我想要有四种。。

第一种， 就是 低地。。
第二种， 就是 高地

一个物件 在 低地的 tile， 戈壁是 高地的tile ，基本上
不允许它 直接 跨过去。。而是 要 go through
第三种tile 就是 ramp ，斜玻。。。 就是 联接高跟低的tile

第四种，是 物件 完全不可以在里面行走的


你们会怎么做。

tensaix2j

其实， 我没把 src compile 成bytecode， 你门可以从那个kit package 里 unwrap 出来 。。

Squall_Chua

我有想過這個問題了
我想到的解決方法是如果它要到的位子被其他object占據的話
它會找個離那個位子最近的地方停下來
還有它在行走時如果碰上前面的object的話
我看得出你的implementation是等前面那個object走開先
不過我覺得應該還可以加入繞道的mechanism
因為要是它前面的那個object是不動的話
它會走不過去的

圓的fog of war
我想到的方法是用一個fog map
就是一開始是全黑的蓋在你原有的map上面
然后如果你的object走過的地方都以你的object為中心
在fog map畫個transparent的圓形
圓形的邊緣可以將alpha value慢慢調整

你可以試試看
這個是我剛想出來的