Hi, I have been looking at jME for a while and finally decided to try to write something using it.
I am trying to create a game board with 3d tiles(blocks) similar to tactical rpg type games like Final Fantasy Tactics and Tactics Ogre. I originally wanted to do this to create a hex board, but this seems simpler for now.
I was able to create a board using the Box object and shared meshes with a sky box using the textures that come with jME. I have a few questions about how I implemented stuff,and how should I implement stuff.
- Is using the Box object the right way to do this? Right now I have a layers of the board randomly generated. The first layer is solid (20x20 all blocks filled) and the 2nd layer just has some blocks randomly placed (roughly 1/4 of the bottom layer). I created 4 boxes, one for each type of texture I want: dirt, water, wall, and grass. Each block of those types uses a sharedMesh. This makes my system crawl to about 9fps. I figured out how to enable back face culling and that put me up to about 16 fps. There may be some error in the way I did this that is causing it to be so slow. I just wanted to make sure there wasnt a better way to do this. I saw some other topic on generating terrain and then laying a grid over it, but that makes it much hard for me to implement things like height advantage and movment for the game ( as well as picking). The other thing is all sides are being textured, even sides that are not visible, is this a big hit on performance? I thought about having some code that optimized the board when it is created, removing textured for invisible sides and removing blocks that are completely covered by other blocks.
- Picking. How would I do something like placing a "glow" or outline on a tile when the mouse is over it. I found example code to do the mouse picking, im just not sure about how to add a visual effect. This would also be for when a unit is selected to hightlight the tiles withing attack and movement range.
- Units. I have model loading working, but how do it place a model "on top" of a tile. Do I need to put a bounding box on each tile (Box) that I used to build the board? boxes are a constant size, so could I just use a local translation + the extent of the box?
- Textures: is there an easy way to add things like roads, bridges and stuff to a texture? For example a bridge tile in this game would be a water texture with a bridge image layered on top, but it would actic like a "ground" tile.
I am new to game dev and 3d so these questions might seem really trivial, but if anyone can explain or point me to some docs I woudl appreciated it.
Thanks for the reply. 2-4 makes sense and gives me more ideas of how to implement those.
I am still a unsure of the game board design.
Here is a SS of what I would eventually like the terrian to look like : http://www.rpgamer.com/games/ff/fft/screens/fft_15.jpg
I am a bit more familiar with jME after playing around yesterday, and I think quads are the only way to go to do this now.
Here is what I am thinking for the design:
The tiles are represented by quads. The board will be represented by a grid (2d array) of tiles. Each tile in the grid has a normal, translation, and texture.
The normal determines the which way it faces, the tiles will either be flat and face up (0, 1, 0) or be sloped at a 45 degree angle facing (0.5, 0.5, 0), (-0.5, 0.5, 0), (0, 0.5, 0.5), (0, 0.5, -0.5). Each of these tiles will also have quads(triangles for the sloping tiles) to fill in any exposed sides, ff there are any.
The translation determines how the grid is layed out in the screen.
Textures for the "side" quads might be different from the tile its associated with(like in the screen shot), but I can deal with that later, for now they can share the same texture.
The sloped tiles are used for transitioning between elevations, but they arent needed, the transition may be a 90 degree drop.
A) does that board design make any sense?
B)What is the best way to represent this in the scene graph? I am assuming that each "tile" and its associated "sides" belong to a node, then the board has its own node with the tile nodes as children. so it would be like rootNode->boardNode->tileNode(s)->Quads. Does this provide any benefit over just attaching all the quads to a boardNode?
C)SharedMeshes: what is the best use of sharedMeshes in this case, should every quad share a base quad, then texture and translate/rotate, or should there be x number of base quads with textures(like dirtQuad, waterQuad, …) and then create sharedMeshes based on which texture then translate/rotate.
D)coordinate reference systems:
Quads by default lay in the x-y plane. I am rotating them to lay in the x-z plane so that elevation is the y axis. Is is typical to have the y axis as "up" and "down" in a game world? It doesnt really matter to me how the world is oriented but I would like to stick to what is standard for games.
I'll keep digging throught the test code, but sometimes its hard to know what to look for.
Here is a screenshot of what I cam up with so far.
The board is randomly generated right now, and the textures for the md2 are .pcx, so I just gave them the tiles texture for now.
I still dont have the transition tiles implemented.
I am having problems placing the models. I must be overlooking something simple, I know the height of the tile, so I need to translate the model to the tiles centre x,z and and the y to the tiles y + some value based on the model. The problem is i dont know where the centre of the model is, or the height of the model, and I didnt see any way to get it. In the SS I am using the boundingvolume (its a boundingsphere)to position it, but this is not very good. I am offsetting the y by the distance from the boundingvolume centre to the edge.
I also built another board that used TerrainBlock instead, it looks much nicer, but I am only able to get picking to work with a boundingbox currently, and that does not work well with terrain that does not fit the box exactly.
With that I was trying to get the picking results in order of nearest first, then do triangle picking on it, if no triangle pick results, then try the next bounding pick result.
Is that the standard way to pick terrainblocks? or is it easier to just pick the traingle, the find out which block it belongs to?
As far as knowing where on your model the origin is, that has to do more with your modeler than the 3d engine. Wherever the model was created around the modeler program's origin is where it will sit in jME. You should open up all the models and adjust them so that they match some general policy, like making sure the origin is centered between the soles of the feet of all characters when they're standing. Then wherever you place the model in jME will dictate the point between their feet, which should be the center of one of your box tops.