Galactic Sovereign Development Log

I’ve been working on putting everything together.  Fixing up placeholders like the spawning of ships being unrelated to planet position in LUA, attaching notifications to planetary invasion events, attaching sounds to planet lasers, that sort of thing.  While it’s more fun from a programming point of view to write new things, I think there’s been a fair amount of untapped potential piling up, waiting for me to connect systems already written.

So: Planets now have a defence value which ticks up.  Upon reaching a threshold, a planet destroyer + escorts are launched at the planet’s faction’s favored enemy.  I’ve significantly reduced the range on the planet killing laser and reduced the fear of gravity wells for ships with weak thrust, so planet killers should no longer hover so far outside planet defence range, and less often get pushed out of the solar system by passing planets.  I’ve also upped their thrust some.  I think I might need to start attaching different drag values to different ships- I still want the planet killers to be slow and ponderous, but it’s a pain having them be constantly flirting with getting sucked into gravity wells just to be within laser range.  Giving them more engine power but more drag would solve that problem without also messing with everything else in the game.

Planetary invasions are announced to the player on launch, as are attacks when they arrive.  There will be some sort of a filter for this eventually so the player isn’t so omniscient, but that’s a gameplay issue to sort out at a later time.

I’ve also resolved some issues with invasions targeting the wrong planet.  The difference between 1-based LUA and 0-based C++ indices still apparently gets me sometimes.

And finally, there is now a nice hum attached to the planet killer lasers, and they no longer visually penetrate the planet they’re hitting.  I think lasers are probably my next target for visual revamp.

The significant new update is the addition of dust and, in general, an efficient way to track particles floating through space.

It would be an easy problem, if I didn’t require the dust particles to react to external forces. Until now, the dust has all been stationary, and is obviously just a big dust cloud texture at various depths in the -z axis to provide some feedback on ship speed and apparent depth to the view.  But even having dust floating around randomly could be done pretty much exclusively in the shader- a bunch of 1×1 quads with varying Z-axis depths to provide differentiation to the vertex shader, and a uniform giving the current view coordinates.  Pretty much all the work would be done on the shader, which for my purposes makes it effectively free.

But wait, they’d eventually drift off the screen.  And since I’m not tracking the entire universe worth of dust, there wouldn’t be any more dust drifting in from far off the screen to replace it.  If the player just stood still for a few minutes, the screen would clear.  I could have the particles wrap around, but that might be noticeable.  So given a random value stored in the Z vertex and time stored in a uniform, I wrote a shader which would randomly move each particle in some direction for a while, then fade it out, then fade it back in near the original position floating in some other direction.  Since the fades in/outs are randomly distributed through all the particles, I think the trickery should be pretty transparent to the user, and look like a randomly moving cloud of dust.  If I wanted to, I could even assign nearby particles similar “random” values and reduce the amount similar values are split in the shader, to have them float in loose groups, to give the impression of currents.

So this is what I did for a while, and the results were acceptable.

But it’s a trickier problem if I want explosions to have an effect.  They have a permanent effect on particle position, there is no limit on how many there can be, and their timing is important.  It is unclear to me how to create a shader that can handle all of that without being able to store all the position and velocity data between frames.  I suspect that this might be possible with newer versions of OpenGL, but I’d rather not have significantly more demanding system requirements on a 2D game for the sake of nicer dust, and there’s far too much undone to start writing multiple render paths right now.

So the obvious answer is to track it all in C++, where all that information is available and remembering things between frames is not a problem.  Obviously, tracking all the dust in the world is ridiculous, so I’d have a chunk of memory I’d stake out on game load that I would recycle as old particles drop off the screen and new particles get added on.  It would have to extend a little beyond the edges of the screen, so an explosion near the edge wouldn’t reveal undisturbed dust if the view shifted in that direction, but still, pretty much just enough particles to fill the screen.

Each explosion triggers a search through all the particles to figure out who is nearby (since current position is unrelated to starting position, that can’t really be simplified).  Beyond that, it’s simple- add velocity*time to the position, and degrade velocity a bit.  I toyed with the idea of combining them into groups of 100 or so and setting an “untouched” flag on them, to skip all that computation if they haven’t been touched by an explosion, but since that would fail to save much effort when the computer was the busiest- lots of combat going on on screen- it seemed like a waste of time.  I can’t come up with a way to avoid having to think about every particle every frame.

So not only am I doing more work on the CPU than I envisioned when I started thinking about dust, but that shader I worked on is kind of redundant.  But perhaps there is a common solution.  I could dump the detailed background (the one not included in most updates due to size), and replace it with some drifty clouds, powered by the dust shader, only with much larger and many fewer particles.  It would give a kind of nebula effect, and positioned moderately far back in the Z axis, it would be plausible that it is not touched by explosions in the foreground.  And given the additional non-static visual complexity, maybe I could track many fewer particles in the foreground without losing the feeling of space not being boringly empty.

Or perhaps I’m rationalizing a use for the shader because I dislike cutting something that I spent time on.

In any case, I was careful to write all the dust code with a “density” variable, so it will be easy enough to stick a slider on that value and let the player reduce it if it ends up actually having a significant effect on performance when the game is completed.

I have finished the notification system, so important events are now announced to the player.  Currently this includes when a friendly planet launches an attack or when any planet is conquered.  While implementing the ability to save messages, I also noticed and fixed a bug which would duplicate ships if the game was saved multiple times in a row.

There is also a new feature possible to attach to projectiles- either a gravity explosion or implosion.  I think it makes the shockwave weapon feel a little bit more real.

For the next update, I am probably going to add some layers of cloudy nebula-like material to the background to make the background look less flat, and perhaps some floating particles affected by gravity.

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.

ver24

New this update is the addition of defence satellites.  Their stats are defined in their own XML file, and they’re plugged into the world through universe.xml, in the appropriate planet entry.  They fire on enemies of their home planet’s faction.

They’re currently armed with lasers- adding projectiles to something which will always be operating in a gravity well seems like asking for trouble, especially since shots which miss will probably be sucked onto the planet, where they’ll damage the planet the satellite is there to defend.  They’re currently invincible, though I will probably change that to be a very large health pool which regenerates, since having no way to to remove them from hostile planets would be frustrating, while they should also not be so fragile that the player would have to be going back and re-purchasing them regularly.

Next up, is handling the small things which I’ve been ignoring- dropping in a few more planets, adding the ability to resize the window, re-enabling weapon switching for the player, and adding in a few more planets under enemy control.

Saving functionality is complete.  All ships, projectiles, gravity walls, and of course the player have save and load functions which slot themselves into the relevant XML in the appropriate save directory, and restore themselves appropriately on load.  Which is, I suppose, a fancy way of saying “You can save and load”, but using so few words for such an important thing seems unjust.

Consistent with the theme of keeping the data in a user modifiable format, saves are straight XML.

Also sidestepped is the sound issue.  I’ve included a sort of droning space ship engine effect as a demonstration.  Next up I’ll add some sounds to the weapons.

So, with new abilities come new controls:
Shift+F1 … Shift+F5 save the game in slots 1-5, respectively
F1 … F5 loads the game.

saves

While writing the LUA “planetTick” function, I came to the conclusion that requiring modification of the C++ core to add new kinds of data to planets runs counter to the premise of user modifiability.  So I’ve added an “extra data” child to the planet XML node, which can contain arbitrary keys and values, which are made available to LUA through the getPlanetData function.  New data can be added either through editing the XML or in LUA through the setPlanetData function, and all of this will be stored on save.