Hi, I have been developing an isometric game for some years now as a hobby in Delphi but recently taught myself Java in order to convert it. So far I am extremely impressed with Java and have picked it up without any problems. I was making some progress converting when I finally started coming across a lot of the limitations of the 2D aspects of the game (which I previously just skipped over) and decided to convert to 3D. JME seems really amazing having looked at the demos and played with some of the sample code from starter.pdf.
I have never done 3D programming before and only played a little with milkshape and gmax. So, hopefully a few questions I have can be answered by more experienced people:
- The game is vaguely similar to Civilization (identical in a graphics sense and infact currently uses most of the graphics from freeciv) so I was wondering if its a big task to create a kind of tile based game in 3D that closely mimics what is currently being done in isometirc 2.5D?
- I was good at geometry at school but thats a while ago now and what I have retained I could write on the back of a postage stamp XD. Is the maths I will need extremely difficult? Apart from vectors which I noticed reading these boards, what other areas should I brush-up on?
- I have looked at the terrain demos but these seem to be dealing with terrain for first person type games so am I correct in assuming this stuff will not be of much use to me?
- I would like various models (e.g tanks) that the player will really only see from above or from a slightly tilted viewpoint and only be able to zoom in a little (so the tank is say 40 pixels long max.). It would be nice to have effects of the guns firing and explosions, but a huge amount of detail is not necessary right now. It is a god-game after all like Civ. The same would go for other -not so detailed- details like cities, rivers, forests, mountains etc. but the game is at a larger scale than Civ (e.g a city takes up 4-20 tiles) Can anyone give some general pointers as to what I should be focusing on to make a start?
Any other pointers or sample code I should be looking at would be very helpful (I have fetched the cvs of jme).
Thanks,
Chad.
Just to add a note (like my post needs more!) with my current thinking:
I was thinking of just having a series of squares with textures on them all laid out side by side but that would get tricky in many places like going from land to sea and keeping the coast from looking too ‘square’ or uniform or repeating (as it is currently in isometric). I guess I would still have to make hundreds of transition textures just like the transition tiles in 2D tiles (e.g. swamp to grassland, desert to plains etc).
I was also very impressed with bumpmapping which I thought could be good for things like forests, hills and mountains. Anyway I’m not sure if this is what bumpmapping is intended for. Also I am wondering if rendering 400 tiles on screen at the same time all with bumpmaps would bog the engine down. My other concern is that for terrain transistions and mountains its nice to have a dramatic change in colour and texture from say rich green grassland to grey rock to white snow caps. This is what struck me about the terrain demos and lots of other demos I have seen with such (heightfield?) terrain generation is that there is never any real dramatic change in colour to clearly indicate if you are looking at a marsh or a swamp etc etc. And this is important for the user who has to make lots of instant strategic decisions based on the terrain he/she is looking at.
I am also thinking there will still need to be an overlay system of some sort much like that used in 2D, like placing a road over a hill or a farm on a plain.
It would be nice to have cities with individual buildings (even though the scale would be incorrect) so that units could move in amongst them and effects (like explosions) would be reflected by them. Ruined buildings would also be nice which is what I have now which serves as a quick visual indicator as to how far gone a city is.
Anyway, I wont labour the point any more and will carry on reading starter.pdf while I wait for comments.
Cheers, Chad.
Hello builderchad and welcome 
i can not answer all your questions, because i’m not a 3D expert but here is my thought :
1/ making content in a game is always a big task. However with 3D you can make some simple form which become impressive because there are in 3D. If you keep graphism simple it’s not more work than 2D, if you want good 3d graphism well… it will take time.
2/ i’m currently making a game for my hobby with jme with my old math memories 
and i have not encounter big problem so far. The most complex part is made by lwjgl and jme, the rest depends on your design and the function you want to create. There’s lot’s of good 3D math tutorial on the web too.
3/ i’m not sure but i think the terrain demos can help you a lot. If you separate logic tile (in the game) and graphic representation i think it’s possible to use terrain stuff
hope that helps.
Adenthar.
Thanks Adenthar, I will definately look for some of the maths tutorials. As far as graphics detail is concerned I think it would spoil the game if some graphics were well done and others were not which is what worries me a bit. I am an expert at making isometric tiles now - especially buildings - so I dont see a problem with making good textures for cities, its just the geometry I would need for things like tanks, soldiers, ships, cavalry etc.
Another question that has been on my mind is how much opengl specific stuff do I need to know?
Anyway lots of ground to cover…thanks for your reply.
Chad.
1) The game is vaguely similar to Civilization (identical in a graphics sense and infact currently uses most of the graphics from freeciv) so I was wondering if its a big task to create a kind of tile based game in 3D that closely mimics what is currently being done in isometirc 2.5D?
3D is not necessarily harder than 2D. The math tends to be a little more complicated, but that's all. The real trick mostly comes down to what assets you have. It tends to come down to your art/artists. Do you have 2D art assets or 3D?
But technically, there is nothing wrong with using 3D for iso-games. Look at Warcraft 3, Empire Earth, Myth, etc.
2) I was good at geometry at school but thats a while ago now and what I have retained I could write on the back of a postage stamp Laughing. Is the maths I will need extremely difficult? Apart from vectors which I noticed reading these boards, what other areas should I brush-up on?
jME tries to hide a lot of that for your (matrix transformations, quaternion rotations, etc). So you shouldn't need to bring out your diff eq book. However, it's always nice to know what the underlying system is doing, allowing you to make better use of it.
3) I have looked at the terrain demos but these seem to be dealing with terrain for first person type games so am I correct in assuming this stuff will not be of much use to me?
Depends on what you want to do. It was only presented in a First Person view, because almost all the demos are presented that way. There is nothing wrong with pointing the camera at the terrain from a high altitude.
4) I would like various models (e.g tanks) that the player will really only see from above or from a slightly tilted viewpoint and only be able to zoom in a little (so the tank is say 40 pixels long max.). It would be nice to have effects of the guns firing and explosions, but a huge amount of detail is not necessary right now. It is a god-game after all like Civ. The same would go for other -not so detailed- details like cities, rivers, forests, mountains etc. but the game is at a larger scale than Civ (e.g a city takes up 4-20 tiles) Can anyone give some general pointers as to what I should be focusing on to make a start?
Most professionals create highly detailed models (hundreds of thousands of triangles). Then work down to a low detailed model to reach the level of detail they need, and performance they want. Starting at the high level in your model program gives you the fidelity you need to get to any level of detail you desire for your game. Sounds like you only need low level models (a few hundred triangles).
I was thinking of just having a series of squares with textures on them all laid out side by side but that would get tricky in many places like going from land to sea and keeping the coast from looking too 'square' or uniform or repeating (as it is currently in isometric). I guess I would still have to make hundreds of transition textures just like the transition tiles in 2D tiles (e.g. swamp to grassland, desert to plains etc).
If you go for a tile based game, creation of these tiles is not going to be very different at all from creation of a 2D tile game.
An aside: you can get great speed on tiles if you add them to the scenegraph in a quadtree kind of way. i.e. each tile is a node. 4 touching tiles are attached to a parent, 4 touching parents are attached to another parent and so on until your have a node that contains the entire map.
I was also very impressed with bumpmapping which I thought could be good for things like forests, hills and mountains. Anyway I'm not sure if this is what bumpmapping is intended for.
Bump mapping is perfectly suited for this (basically, anything to add "texture" to a scene without adding triangles).
Also I am wondering if rendering 400 tiles on screen at the same time all with bumpmaps would bog the engine down.
Depends on the machine. 400 tiles (if they are quads) is 800 triangles (2 tris / quad). That's a very small tri count, and something like my home machine (1 1/2 years old) would run this at over 1000 FPS. Adding Bump Mapping will slow things down a bit, but it will still run in the hundreds of FPS. Bump mapping support is currently only in the Shader code, so it will require a modern card.
None shader bump mapping is in the future.
My other concern is that for terrain transistions and mountains its nice to have a dramatic change in colour and texture from say rich green grassland to grey rock to white snow caps. This is what struck me about the terrain demos and lots of other demos I have seen with such (heightfield?) terrain generation is that there is never any real dramatic change in colour to clearly indicate if you are looking at a marsh or a swamp etc etc. And this is important for the user who has to make lots of instant strategic decisions based on the terrain he/she is looking at.
This based on the texture applied to the terrain, you have complete control of such things. You can apply a texture that has a "harsh" transition if that's what you need.
I am also thinking there will still need to be an overlay system of some sort much like that used in 2D, like placing a road over a hill or a farm on a plain.
This would probably be accomplished through the use of decal textures, which isn't currently directly supported in jME.
Thanks for the detailed reply Mojomonk, it has definately given me a lot to think about and look into.
3D is not necessarily harder than 2D. The math tends to be a little more complicated, but that's all. The real trick mostly comes down to what assets you have. It tends to come down to your art/artists. Do you have 2D art assets or 3D?
All my stuff is in 2D isometric so pretty much none of it is compatible with 3D. My brother has been helping me create many of the tiles like the transistion tiles. We are up to about 350 now. At a wild guess about 40 hours each invested. But! We are both very excited about moving to 3D and he will give me help with that. The amount of freedom and flexibility we will gain from 3D far outwieghs our investment to date. Plus we have already compromised on a lot of things and still coming up against limitations with the isometric approach. The 3D will free us and allow us to revisit all those things that were shelved.
Depends on what you want to do. It was only presented in a First Person view, because almost all the demos are presented that way. There is nothing wrong with pointing the camera at the terrain from a high altitude.
Well I am glad to hear it, its daunting to think I would have to start from scratch and my 'tile' approach is already showing cracks - most notably the transitions from one terrain type to another being blocky and ugly.
I realise a lot will change and I would still like to preserve some sort of 'blocking' - behind the scenes - to break up the terrain into logical blocks because I have done so much with the AI and some of it is working quite well like influence maps.
Most professionals create highly detailed models (hundreds of thousands of triangles). Then work down to a low detailed model to reach the level of detail they need, and performance they want. Starting at the high level in your model program gives you the fidelity you need to get to any level of detail you desire for your game. Sounds like you only need low level models (a few hundred triangles).
Well I am hoping I will be able to get hold of some models as open source and rework them in a 3D package. For a long time though I will be happy to use big coloured squares to represent units ;) until some of the more important things are working (particularily the terrain).
An aside: you can get great speed on tiles if you add them to the scenegraph in a quadtree kind of way. i.e. each tile is a node. 4 touching tiles are attached to a parent, 4 touching parents are attached to another parent and so on until your have a node that contains the entire map.
I will definately look into this to try understand what you mean by it. I have never come across scene graphs before but it seems a very clever way of doing things.
his would probably be accomplished through the use of decal textures, which isn't currently directly supported in jME.
I have looked into decal textures and yes it does seem to be an ideal solution. Is support for decals planned for the future?
I wonder if there are any other suitable alternatives to decals for the time being? And would decals be something I could do by accessing the lwjgl layer?
Cheers and thanks for all the help. I am hoping to make some headway into the terrain demos this week and start experimenting so I can start asking more specific questions.