I suspended work on the game for a while, but I’m back, and progress continues, with a substantial list of updates.
Additional player weapons are re-enabled, switch weapons using the mouse wheel. The number keys still work, but may be eliminated in the future. This means the player can no longer control their zoom level. Whether I re-include that depends at least partially on gameplay mechanics, so I’m not going to make that decision now.
I fixed a shader bug in the glow trail shader introduced/exposed by the most recent ATI driver. It was the second shader I ever wrote and really a learning experience more than anything else, so it very well may have been relying on some undefined behaviour.
The screen is resizable. Right now, it just resizes down to windowed 800×600; I’ll add in the ability to choose resolutions as soon as I write the main game menu.
The player can now claim a planet which is at zero health. Land, bring up the planet interface menu with “E”, and pick “claim planet”. Satellites will behave according to the faction of their planet’s owner, shooting at enemies and ignoring friends.
Fixed a problem with the gravity wall tool not fully restoring all information when loading a game.
Computer controlled ships no longer stack up at the same point in space. They now bounce off each other, creating a much more believable cloud of ships when a lot of them congregate.
LUA can now access the general state of the universe with “getWorldData”, which allows it to access general star and planet data and positions. I’ve also repaired the get/setPlanetData functions, which were apparently mangling data since I added the extraData ability. This was made exceptionally difficult by having a problem which lay at the interface between C++ and LUA. I have resolved to minimize the size of that interface in the future.
Computer controlled ships are now much more flexible. LUA can set three orders- go to a location, follow a ship, or follow a planet. Since targeting is independent of that, “follow a ship” can be used for both “escort a friendly ship” and “attack an enemy ship”, and the same for a planet. Right now, every five seconds, every owned planet locates an enemy planet and launches a planet-destroying laser-armed ship towards it. Since they’re all close together, the ships spawn so fast, the planets don’t bother defending, and the range of that laser is so large in comparison to the defence satellites, the planets all die fairly promptly. Obviously this is just a proof of concept, but it’s a massive step forwards in terms of actually having a game.
To better illustrate the relations between planets, I’ve added more of them. They’ll all look the same until I get some more images from the NASA archives or something similar.
Also fixed is the behaviour of smoke trails at high speeds and low frame rates. Previously the smoke trails would get ahead of the ship if the number of milliseconds between frames was higher than the time granularity of the smoke trail (currently set at 15ms), this is now fixed.
The glow trail shader wouldn’t work at all on nVidia drivers due to a variable type mistake which ATI cards apparently don’t care about. This is fixed.
I’ve added a queue to flash text to the player- proof of concept bound to the “P” key. Major events like planets being conquered or player planets coming under attack will be displayed through this system.