Just started JMe (a few weeks now), and it’s amazing what you can achieve in a small time!
The game I’m working on to let the time flow is a free flying simulator (paraglider, hangglider, sailplane) based on the stopped project of FlightClub:http://www.danb.dircon.co.uk/hg/hg.htm.
It’s far from finished yet, but I’m already quite pleased of the result, so I want to participate in showcases
The game is :
choose you glider (or else, you'll see the AI players flying but that's no fun not to compete)
fly from one waypoint to the other, jumping from thermal to thermal, finishing the circuit in the shortest time (well, actually the end is not well… hum… hasn't been cared off… you finish, and then you fly till you want, even at night )
As now, each thermal generates a cloud… so aim at the cloud to rise in the air.
Game task is loaded from XML. On fixed terrain right now.
I used llama (thanks a lot, you rule!) infinite terrain for continuous terrain. It's a bit modified to get different texture assigned to each slides.
I use standardgame and gamestates to ease:
game test and debug
get terrain loaded before game task loads
separate sky, terrain, game task and hud
The terrain is actually real : the french ‘massif central’, dead volcanoes in center of france. Everything is at scale.
The terrain texture is lowres satellite imagery.
The glider models are homemade.
I got some difficulties with clouds… They’re not bad, but I’ll try to achieve better. Sad impostors don’t work on my hardware!
Got to find a fast hack for cloud shadows…
The framerate is limited to 30fps (so my computer isn’t on the knees when debugging)
My computer isn’t that fast (6 years old)… so… Don’t trust the fps on screenshots
Game starts in demo mode, tracking an AI.
Different cameras are available, with travelling between them.
1 : Player
2 : AI (loop through players)
3 : Far from top
4 : Far from side
5 : … don’t use it yet
6 : Pilots eyes
7 : Free the camera
In mode 1&2, Chasecamera (chasenode in fact)
In mode 3,4,5 and 7 First player cam (AWSD + mouse)
y : launches the game
left/right : turn
up : accelerate
down : brake
p : pause
+ : speed game up
- : slow game down
F1 : printscreen
m : get the mouse back
Ground speed, distance to next waypoint, distance from start
Compass with AI players (red) and waypoint (black)
Variometer, Integrated variometer on 12s, altitude, time of the day, time flying.
Yellow circles are thermal triggers, red ones waypoint sectors..
Thanks for the comments, rather cool that you like it, I'll go further :)… and release the code… when it will be clean(er)
And thanks again llama, you tool is great… a bit hard to understand the insides… I didn't go to deep. (In fact, I wish there were more comments… but I think everybody could say the same from my own code, so…).
If you want a version with wireframe trigger, I could easily provide one. No trouble… Except that it won't work on my computer. jME crashes when I toggle wireframe on terrain… Is it my hardware or your software ?
I already had the altitude map from NASA (easy to get trough theyr website and the links you provided). And I used Virtual Terrain Builder to transform Nasa .HGT SRTM files to .ASC, with the correct dimensions. Your ASC loader worked great with large files… the others crashed.
For the satellite imagery, I used http://onearth.jpl.nasa.gov/, in combination with Virtual Terrain Builder to get the picture for the exact coordinates. Then I made a short perl script to slice the resulting picture in the same way you sliced the altitude map in order to get a texture for each block. Each texture is actually a jpeg file. They needed 90
An example would be great, especially for using llamas magical terrain, I've always wanted to try it in aircarrier but been afraid I've just got one smallish terrain block, it would be great to have a lot more terrain to fly around, especially if the performance is good.
I don't know much (anything really ) about using real terrain files, but I've found with my generated height/texture maps from L3DT that blender has been very useful for placing objects. I have a plane (a grid mesh really) in blender at the right scale and with the right settings, and if I set the height and texture maps on it it then looks exactly like the terrain will in jME, but at 1/64th the scale so that the units aren't too huge. Then I can place empty nodes (or meshes) in blender where I want things on the map, and if I load those nodes into jme they are in exactly the right place on the terrain. For example in my game I can have nodes named "ring.001" etc. and they will be replaced with rings marking out a racing course in jME. Meshes could be loaded in directly as well, but it's good to use empty nodes for stuff that is repeated, so I can share meshes etc. It sounds like you are doing a similar thing in inkscape, do you need to take the coordinates across manually or do you get them from the SVG file?
If it would be useful I can put up the blend file for my terrain, the scaling would be wrong but it sounds like you've worked out exactly how the scaling works for your terrain anyway
Yes, It would be useful that you provide the blend file. Could give ideas, or examples to everybody.
In my case, the objects are placed by reading their x,z coordinates from the xml file that describe the task. It allows many different tasks (or games/level/…).
Actually, I place the racing course and the thermal triggers in inkscape and then report (by hand) their coordinates in the xml file.
Their are two possible ways in the future where I may orient my development :
[+] either a script to generate the xml file from inkscape: easy, but will lack information.
[+] either a java program to place an define the different objects on the map directly by clicking. With Java2D… or why not, jME !
Once the XML created, the game reads it, and places the objects at the x,z coordinates (+ their definition) and raises them (y) at terrain height (+ a bit).
I don't actually need well placed stuff, since the goal of free flying is to fly the higher possible the get the furthest… I won't add buildings or stuff on the ground, but improve stuff in the air.
I'd rather also improve the texture of the terrain.
Using llama terrain with all features implies that I don't create all objects at once. Since all the blocks are not loaded, objects on those blocks should not be loaded, or they'll be bound to be on 0 y coordinate. (You could of course loads all block first… but that's no good.)
That's why I start drawing the objects when they are 25 km near, and llama's terrain 30 km.
That's also why I use different gamestates for terrain and task with a pause between them when loading the game (hacks… hacks…)… For terrain to be loaded when task loads.
And I must say tutorials for gamestates are right: much better to have stuff dipsplayed on screen when you loads the game than getting a blanck screen for many seconds.
As for the example of using llam's terrain, I'll think of doing it and adding it on the wiki. Performance follows indeed. The other continuous terrain I tried never achieved the same frame rate.
But anyhow, I took one path of the multiple ways to use it, if you use generated heightmap, it would be another… but pretty close