next »

[Dori]

Thanks for your help so far.

well I have other questions for you. I'm planing to make some kind of strategy game. And now I'm thinking about how to implementation a level. The simple way is to create a grid of cells and make units be in one cell at time like chess, this is probably the way I'm starting with. But then if I want to have hight it becomes a problem, the cell is not a rectangular any more. Well I have been playing "Bang! Howdy" it is a mix of RTS and TBS and the use cells to store units. However I like to have my units in different size so one unit would be taken more then one cell and that would complicate things a lot.
How about using real position? I will be come even more complicated but will it be more real feeling of the game, not stuck in some cell?
Also is it good idea to develop levels in 3d program like blender?

What do you think, any comments?

P.S. how do the big games like Command & Conquer, and other RTS game do this?

[Marvin Fröhlich]

I think, the best way to go is to use some Terrain implementaion (cylab is working on a new, improved one) and store some 2D-meta information for each cell. Therefore you should create a logical grid on the Terrain.

Do you know the WarCraft 3 map editor? It works with a grid. But the result is a smooth looking Terrain and the units move in real coordinates.

Marvin

[Dori]

How does this terrain implementation? I am very new to game programing and 3d. I have only program desktop apps in java and c++.

[Marvin Fröhlich]

How does this terrain implementation? I am very new to game programing and 3d. I have only program desktop apps in java and c++.

I don't know. Ask cylab. Maybe write him a PM. He will be able to tell you much more than me. I myself haven't worked with a Terrain yet.

Marvin

[kukanani]

Ok, I have an idea.  I've thought this up before, but never had a chance to use it (you know how life is).  How about a grid of cells, but infinitely small movement increments?  Here's how it would work:

Every entity (human, robot, fish, whatever) stores two sets of coordinates - it's current cell's coordinates, and its real coordinates. 

The cells would be used for area-of-effect attacks (bombs, splashes) and things like that, and also to figure out locations on a mini-map, if you are planning on having one.  The cells would also be used in path-following and terrain implementation - as in this example:

Mr. Entity is somewhere in Cell (35, 46) - it dosen't matter where in it he is.  The player selects him and clicks somewhere in Cell (34, 46) - one cell to the left.  The path that Mr. Entity would take (in psuedo-code)  is:

1.  move to the center of (34, 46).
2.  update exact coodrdinates.
3.  make sure that the cell (35, 46) is not impassable.
4.  move to the center of (35, 46).
4.  update cell coordinates and exact coordinates.
5.  move to the exact location in (35, 46) where the user clicked.
6.  update exact coordinates
7.  play "Hey, dude, I got there" audio clip (not neccesary, but hey...)

Also, the cell centers could be stored in each cell individually, like if you wanted a person to stay away from a hot lava cell, just move the adjacent cell's center.

Just a thought...

[Marvin Fröhlich]

Ok, I have an idea.  I've thought this up before, but never had a chance to use it (you know how life is).  How about a grid of cells, but infinitely small movement increments?  Here's how it would work:

Every entity (human, robot, fish, whatever) stores two sets of coordinates - it's current cell's coordinates, and its real coordinates. 

The grid coordinates can easily (and cheaply) be calculated from the real coordinates. So there's no need to store them separately.

The cells would be used for area-of-effect attacks (bombs, splashes) and things like that, and also to figure out locations on a mini-map, if you are planning on having one.

I guess more important is the well know "feature" of positioning buildings on the map. If you want to build up a building in your RTS game, you will want to position it somewhere on the map. In very most games this is only possible on a discrete grid (not freely).

The cells would also be used in path-following and terrain implementation - as in this example:

Mr. Entity is somewhere in Cell (35, 46) - it dosen't matter where in it he is.  The player selects him and clicks somewhere in Cell (34, 46) - one cell to the left.  The path that Mr. Entity would take (in psuedo-code)  is:

1.  move to the center of (34, 46).
2.  update exact coodrdinates.
3.  make sure that the cell (35, 46) is not impassable.
4.  move to the center of (35, 46).
4.  update cell coordinates and exact coordinates.
5.  move to the exact location in (35, 46) where the user clicked.
6.  update exact coordinates
7.  play "Hey, dude, I got there" audio clip (not neccesary, but hey...)

Well, why not simply picking a position on the map and move the entity to this position? I don't think, here is a need for the grid. The grid is normally only used for positioning buildings and for other map-queries like "Am I allowed to move to there?" or "What kind of ground is this cell? Am I allowed to place a building there? Or a harbour?".

Marvin

[kukanani]

The grid coordinates can easily (and cheaply) be calculated from the real coordinates. So there's no need to store them separately.

Exactly. I meant to say that, but the idea's still kind of fuzzy in my head...

Well, why not simply picking a position on the map and move the entity to this position? I don't think, here is a need for the grid. The grid is normally only used for positioning buildings and for other map-queries like "Am I allowed to move to there?" or "What kind of ground is this cell? Am I allowed to place a building there? Or a harbour?".

Marvin

Right, that will work in my small example, but it's quite a bit easier to implement complex path following on a grid, isn't it?

[Dori]

I have been looking at terrain class and it looks very complicated, what about creating maps in blender as OBJModel? Is that to slow?

Edit: spelling

[Marvin Fröhlich]

I have been looking at terrain class and it looks very complicated...

Cylab is currently working on an improved and simplified new Terrain implementation.

..., what about creating maps in blender as OBJModel? Is that to slow?

Yes, that would be too slow (in general). Well, I don't know, if Blender supports some kind of Terrain, that we could efficiently load into Xith. But in general, there needs to be some kind of clustering to improve Frustum culling and LOD, Which cannot be easily retrieved from the OBJ model. Well, maybe the OBJ model could be separated into several OBJ-Groups, that represent the clusters. And the Terrain implementation would have to be notified of how to handle these subgroups as Terrain clusters.

Marvin

[Mathias 'cylab' Henze]

The best way would be to use a heightmap for terrain and drop in models at specific grid-locations that automatically get positioned at terrain height level. I am afraid we are a good margin away from that right now, so the Terrain implementation would not suite your needs.

What about the terrain Amos uses in his game?

On another note, I would suggest to start with a 2D-Terrain first (meaning a flat plane in xith) and implement the game logic on this level, since a 3D Terrain would introduce a whole new area of problems like terrain walking, terrain collistions/intersections etc.

If you have a game ready in a "flat" world, it would be much simpler to "upgrade" it to the - then hopefully ready - new Terrain implementation.

[Dori]

Why would it be slower? many tutorials about FPS use models to create maps.

http://www.quake3bits.com/htm/tutorials/blender_modelling_maps.htm
http://www.quake3bits.com/htm/tutorials/blender_video_tutorial_terrain.htm
http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Making_Landscapes_with_heightmaps
http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=13274

I would think that these FPS maps with Doom3 engine would need to have all the optimization in the book and if blender modules would be too slow for a simple home made game then it would be way to slow for these engines?

[Marvin Fröhlich]

Why would it be slower? many tutorials about FPS use models to create maps.

I don't say, it would be slower per se. But it would be slower in Xith, because we don't have a builtin support for Terrain handling of OBJ models. Of course this can be implemented.

You should first start with the flat Terrain, as Cylab suggested. When he's ready with the new Terrain implementation, you could discuss with him about a OBJModel -> Terrain transfer code. It shouldn't be very hard. It's just a OBJGroups -> Terrain patch conversion, if I guess right. But just let Cylab fist finish hist Terrain work.

Marvin

['n ddrylliog]

@¢ylab :
My terrain implementation permits Texture, and is loaded from an XML file.
It's fine for a game which needs a heightmap. But I'd like a cleaner implementation which would support Bezier patches (as Marvin said)

@Marvin :
Yeah this conversion would be rather easy. But using some JOODE code, it would be even easier since they already have some Ray/Trimesh collision code... So basically you say when you load your OBJ Terrain which "granularity" you want for your terrain and the model is tested for a grid of points (each time a Ray is created and tested against the Trimesh, then the highest point of intersection is reported as the height of the Terrain at this point). With this approach, you would have both stunning graphics (with fine textures) and optimized terrain (height is interpolated with Bezier patches from sampled height points). Adding a JOODE collider class for Terrain would be *really great* since it would allow physic objects to go perfectly on a Xith3D Terrain with minimal hassle!

Alternately the OBJ Model could be used as a TriMesh in JOODE..

[Tom Rubaj]

 As I understand, the main problem with real positions here would be the need to check how distant the units are from each other and what units are present in some defined area. That is easily done if you have a grid - you just iterate over several grids in the vicinity - but it's nowhere near that simple with real positions.

 If the terrain is 2D (positions of the units are de facto 2D and only the graphics is 3D) you can still use some version of a B-Tree index to index the gameObjects in such a way that they would be easily and quickly accesible even with real positions.

 The way I'd do it is I'd create a recurrent tree structure of gameObjects:

class gameObjectsTree {
 GameObject gameObject;
 List<GameObject> children;
}

class GameObject {
 public x;
 public y;
}

The trick here is to create this structure in a way that will make it possible to easily define and access all the gameObjects within a defined rectangular.

To do this, one would have to construct the tree in such a a way:



(the colored areas mean "all the objects in this are are the offspring of the object in the top-left corner").

That's basically the simplified, home-made version of a 3D b-tree. It takes a bit of coding to do it right and make sure the whole index is updated in the right way and all the objects are in the right place in the tree structure and added in the right order to the children's List, but once that's done you get the most efficient way of managing multiple objects in a real-position 2D environment I've come up with to date.
 All you do is iterate over the branches of the tree until you find the branch, the children of that can be in the rectangle you are interested in and test them until you come to the object whose "offspring area" is outside and beyond that rectangle.
 That gives you about the lowest number of iterations possible. As far as I can tell, anyway : P

 As for defining the altitude: I've been using the NearestPickListener with a ray facing down to determine the altitude, that combined with wrapping all gameObjects in something containing [Vector4f velocity] that I could alter if I found the need for the object to start "falling" or "climbing".
 But I'm quite certain that if you use some implementation of a Terrain specifically, you can come up with a way better way to do that : ]

[Marvin Fröhlich]

As far as I know a B-tree is used for "external" data. But the whole game data could be kept in memory (as far as we are not writing a WOW-sized game. Further a B-tree is for one-dimensional data. The most efficient was (that I know of) is a QuadTree for 2-dimensional data and an QcTree for three-dimensional data. Of course both need to be balanced to guarantee O(log n) times.

For most Terrains a QuadTree would be sufficient. But for general levels an OcTree must be used. And an OcTree is not less efficient in a 2-dim world.

Marvin