Terrain / Level design question

I want to know the best approach to creating a game that has lets say a 64x64x10 tile level. I want to match the tile movement in such games as Bang! Howdy (http://www.youtube.com/watch?v=LYsOfRbmJzE) and final fantasy tactics (http://www.youtube.com/watch?v=SQX1fbRh6XQ)



I have been vigorously looking through all of jme stuff new and old to figure out how to do this. My initial attempts have been trying to use a Height map from TerraMonkey (calling TerrainQuad). Also have been modifying the terrain examples jme comes with. I’m just not seeing anything being as blatantly obvious that this is the correct approach. I have also wrote some code to generate an X by Y level just using the Geometry.shape.Quad but I am having a hard time figuring out how to apply height or depth to that.



If anyone has experience with this, or even tips please let me know. Thanks!

Hello!



I’ll preface this by saying I don’t have any experience with this. But the two ideas that spring to mind immediately are:


  1. Well, if you want a relatively flat play-area, you could easily get away with heightmaps/bunch of quads. I haven’t toyed with the terrain yet, so I don’t know the level of control you have.


  2. Otherwise, you could model a level in Blender/3d app of your choice, and do whatever, just ensure that you’re working with a grid of equally sized tiles. This would give you maximum control over your maps, but obviously involves some 3d modeling - though not terribly hard modeling.



    In the end, with this type of tiled system, you want to make sure that every tile x,z is the same size. Well, I guess it’s not a hard and fast rule, but it will work much, much easier that way. And intuitively react to the player more naturally that way. Once you’ve got this tile size down, you probably want to ensure that the player isn’t terribly, terribly small in comparison to the tiles themselves. Oyie, this is really hard to describe without pictures. Ultimately, the biggest concern I would have designing a tile based game would be the scale of things. If the tiles are too big, then the player has to move a country mile to get to the next tile. - Which probably means you need more subdivisions on your grid, etc etc. Gets complicated XD - In the end though, it is something you’re going to want to think about, decide on, and stick with.



    Now, I’m not totally sure where you’re having problems, so I’ll keep blabbing. As far as actually defining the way things interact with the tiles themselves is actually fairly simple. Decide whether or not you want objects and characters to stop on the corners/vertices of each tile, or the center of the tiles (or hell, I’ve seen engines that use both - but it can be sorta awkward). From here, it sorta depends on the type of game you’re making. If it’s a slower turn based strategy game like you illustrated, then you can just highlight squares to move to or use the mouse to click on the square you want to go then the player accepts this as a move and you control the movement to that location.



    Getting the square isn’t too hard either. You would just want to ray pick with the mouse, onto your terrain/model, and find out what square the player is clicking on. Then it’s just a matter of figuring out the center of the tile. - The only tricky thing I can think of, is that in a terrain esp. each ‘tile’ is going to be two triangles. If you’re using tiles as your points to move, then you’d need to have a way to figure out the center of a tile based on two triangles. I’m having a hard time thinking of a way to do that, but I bet it’s not tooooooo hard.



    Ah well, I hope some of my wandering thoughts are of some use. And if not, hey a free bump to your post for real help! :wink:



    Cheers,

    ~FlaH

what i would do is:


  1. identify all possible terrain blocks which can be found in your game (because your terrain is a bunch of blocks put together)
  2. a) create an algorithm to put these blocks together in an intelligent manner

    or

    b) create a system which will allow you to specify which block goes where through custom coding. A two dimensional array would work very well for this.
Eggsworth said:
what i would do is:

1. identify all possible terrain blocks which can be found in your game (because your terrain is a bunch of blocks put together)
2. a) create an algorithm to put these blocks together in an intelligent manner
or
b) create a system which will allow you to specify which block goes where through custom coding. A two dimensional array would work very well for this.


OK just some follow up questions

1. What techique / api would I call using JME to achieve that

2. I plan on doing this or b once I know what sort of API or code i need to make for #1.

I also sadly abandoned the TerrainMonkey. It looked so great but for turn based strategy I went with the twodimensional array approach.

I modeled some simple hex-fields in Blender with an edge size of “1”. In JME I loaded all these models and assigned every model to a certain int in an two-dimensional int-array. Then all you need to do is change the translation of every field so that they fit together.

Which then looks like this:





You can also use a shader to put squares onto a Terrain and subsequently highlight it like this:



(it could of course look alot better :slight_smile: ) If you really have to distinguish between terraintypes(blocked, hilly and flat terrain) I wouldnt try this.

I think keeping the single tiles in an array or in memory at all will always limit your games size because of memory constraints. Actually the tiles should only exist logically and all classes should compute and create the data only as needed. So for example when you have a terrain it doesnt represent the real “array” but it has some info that its lower left corner would be where tile 0/0 is. A ray collision check on the terrain would then compute the location of the “tile” that would have been clicked and tell the tank to move there. The tank also gets just the terrain and the 45/67 tile info and computes the location where to go. This way when you want to move to tile 1000000/1000000 you dont have to have a huge array in memory but only the terrain starting at 999900/999900 for example. Extend this to all areas and you have a memory efficient “endless” tile-based system. You only need to store info when theres info, so only create an object with the info on which tile it is instead of saving each tile with no info in it.



Cheers,

Normen

Thanks for the great replies, here are some of my thoughts.



@Kaizo



The first approach seems like I would be able to that very quickly but I notice I would run into a problem of height. The second approach with the shaders seems very doable. You mentioned how to distinguish between hill, or flat terrain, im sure there is a calculation based on height or you could use the alpha map.



@Normen

I agree with your approach about not focusing all tiles in memory. The levels in general I want to keep small but I think constraining myself from further expansion is not an approach I would take.



Follow up questions. If I were to take Kaizos second approach of generating which blocks are movable (highlighted) in the shader, how would I do that exactly. Also with JME Terrain I haven’t really seen a clear way to provide height like the Final Fantasy tactics game. To explain further for example your character may start at on top of building and the rest of the level sinks in. With Terrainmonkey I have really only seen the ability to do what its named, add terrain like mountains. If I wanted to add a building with height and lets say a swamp that sinks a few down on the level, what would be my approach. (Watch the final fantasy tactics, its hard for me to convey my point with words).



In the video it looks like almost like the world is a cube, split into tiles. To provide depth the tiles fill the cube on multiple levels, then each tile just has a corresponding texture. Is what I described any different than a JME terrain Height map? I’m sorry if this is a noobie question I am just trying to wrap my head around this approach as obviously this is going to be a main part of my game.



Edit: Another thing I thought of, is I guess it can be a combination of creating the level in a modeling program and highlighting tiles with a shader. That would be my last resort type of thing because it creates more work in the end to output levels.

as far as height goes, use a 3 dimensional array rather than just 2 dimensional.



this would allow you to stack blocks



for example, block[0][0][0] = dirt;

block[0][0][1] = mountain;



so you would be stacking those hexagonal shapes ontop of eachother.



in regards to your questions you directed towards me earlier, I would follow the lead of the supplied ideas and make an in-house terrain system rather than looking for an api for it. :slight_smile:



best of luck to you