This is our first game, a cockpit flight game that is more of an arcade than a sim. It is similar to the ancient games like the classic Wings or the very good Strike Commander. The story and the atmosphere are important elements of the game, so a lot of focus is placed on that too.
There are many details on the official web site, those who are interested can visit:
An early, demo version is provided for download on the web site. For the moment it allows playing only one skirmish mission.
Most of the game core is written in Python, with few performance-critical parts rewritten in C++ (roughly 95% Python, 5% C++). Nevertheless, performance is still sluggish, and it is not clear to us how to improve it further. By the way, forum user nikolm is the core programmer, and he will be happy to hear any advice
The game is open source, and it would be nice if you could recommend some other good places to announce the game.
Well, I definitely struggled with terrain and shadow casting.
The problem with terrains is that they are typically 320 km on a side, and should have some geographical realism and surface variety. So each terrain has an elevation map from SRTM, manually extracted water mask to construct flat water surfaces, and possibly a number of other masks, like for cities. Then there are altitude-dependent color and normal maps for these different geo layers. The high-altitude color map is from ESDI/GLCF. But this is all rather inflexible, and variety is lacking. Especially in low-altitude flight. Would be great to do something about it. Btw, looking at your terrain demos, they are breathtaking!
For shadows, so far I could only wrap my head around basic shadow mapping. So all those artefacts, like jagged edges, are present. To have so-so good resolution in the shadow map (from sun), only an area of about 100 m around objects in camera focus is shaded. And a special shadow scene is maintained, using simplified models. Improvements here would be nice too.
Hey stef, your game looks pretty cool. You could post an announcement on the Free Gamer forum. It’s a site dedicated to open source games. freegamer.blogspot.com
Couldn’t run the binary on my ancient 32 bit win xp. I’ve started it from the source (had to move some files, the main.py imports from the src dir, but mai.py is in that dir, had to change USE_COMPILED to False to start the scrip).
When I tried to start the skirmish I waited some 15 minutes then got this info in the console and a python crash
INFO: Starting game.
INFO: Starting skirmish mission: genk:incoming
INFO: Switching to zone: zero
INFO: Constructing terrain.
Out of memory allocating 100663300 bytes
AL lib: (EE) alc_cleanup: 1 device not closed
Hi wezu, yep, binaries are 64-bit. We had to go for 64-bit for the reason you experienced, memory is guzzled up pretty fast when starting. Mostly on model and texture caching, and terrain and cloud generation. From the output, it appears it goes out of memory somewhere in terrain generation. Had it managed to start, on subsequent starts everything would have been read from cache, and then it would use less memory and start much faster. One possibility to provide enough memory on first start, is to insert “return” statement at start of cache_bodies function in missiontools.py. Then maybe it will crash only after the terrain has been generated and cached, so on a second start everything may pass.
The slowest machine we tried is an AMD A8 (from late 2011), with integrated GPU. There it takes 6 minutes for first start, and 30 seconds for second start. RAM use on second start is a bit below one gigabyte. But in-game performance on this machine is bad.
The long first-start time is caused by all generation still being in Python. It is on the TODO list to rewrite this in C++. Then it may also be easier on memory, with careful manual data allocation/deallocation.
If USE_COMPILED is set to False, 100% Python code is used. This will result in less details in some effects (e.g. no smoke shading), and slowdowns at places.
Edit: About moving the files, it should work with files where they are if you run the limload.bat file from the util dir.
According to recommendations from wezu and SkrX, I have now made a profile on IndieDB and posted a topic on FreeGameDev forum. Now waiting for both to clear moderation
Getting into the either of two skirmishes should be much faster now, as terrain creation is redone in C++ which speeded up whole operation over 25 times! Heck, even system memory usage is halved
Nice.
Common trick to prevent cloud billboards clipping when passing through the camera:
Fade out the cloud billboard as it gets very close to the camera. I’m pretty sure this trick was used in Just Cause where you can do sky diving.
Optionally have a white frame in aspect2d and when you fade out the cloud billboard, fade in the white frame at the same time so it will take its place.
The above tricks sometimes helps with the billboard intersecting with the player/plane geometry as well, but depending on the camera distance from the plane and/or if there are other planes besides yours, you will still notice the billboards interesting with those. No idea how to solve this issue myself. Anyone?
I was looking to nail that sense of flying and freedom. The less a game hold the player to the hand, the better, in my opinion. Flying is agile in every way I could think of (jet, cockpit, pilot’s head, etc), so that it could flow well with (intense) action-like mission structure, that I imagined.
