Galactic Sovereign Development Log

I’ve been contemplating where I’m going to be taking the game, and how I’m going to justify the gameplay I want in terms of a logical plot.

I don’t think orienting the game strongly towards a traditional step by step quest driven plot would really give the gameplay the best backdrop.  Instead, at most I want to set broad objectives, and let the player achieve them as they see fit.  If that.

What I do need is a reason for the player to start somewhere fairly safe, while establishing that there is a greater threat elsewhere, preferably with greater rewards as well.  And I’ve decided the following fits the bill: The player starts deep in human territory.  The planets there have already been mostly mined out, but it’s also safe and secure.  The technology available is civilian, consumer level stuff.  But there’s a war on, and things aren’t going very well.  So further out, other factions have been able to take control while the military is elsewhere, giving the player the next step up the risk/reward ladder.  Mercenaries, pirates, better planets up for grabs and better technology available.  Closer to the warfront, things are more militarized, with military grade equipment available and more fighting to be had.  Then there’s enemy territory, which the player could participate in taking back, with the reward of harvesting alien technology.  Then there’s always the option of discovering those aliens were attacking because they needed more resources to sustain their fight against another set of more advanced aliens.  The entire scenario lends itself pretty well to a nesting set of ever more dangerous environments.

I’ve been experimenting with sound, and the results are pleasingly straightforward.  After appropriate linking and placing of files, it takes a total of six very simple lines of code to load a .wav and play it at full volume.  The code to handle sound location and such takes more, but it’s still reasonable, especially since it’s managing all the required data already for openGL.  One thing that surprised me, though, is the way sources (things which can emit sound) are handled in OpenAL: they’re as close to physical objects as it gets, having position and velocity data, so it seemed natural that I’d attach one to each ship and attach and play buffers (which contain the loaded sounds) as necessary.  Instead, each source can only play one sound at a time, so I guess ships will hold a variable number of sources, and I’ll add them and subtract them as necessary.  Their method does make sense for things like explosions and projectiles which will only ever make one sound, though.

One thing I have learned is that there is apparently no limit to the number of times I can be surprised by the test explosion that plays when the game fully loads.

Of course, the next thing I did was spend a day on freesound looking for reasonable explosion, shooting, laser, and engine sounds.  Ends up finding a good explosion is quite hard, and engine sounds are quite easy- I’m talking about that low hum you always hear on any scene in a spaceship in most science fiction shows.  Perhaps because recording explosions is inherently dangerous and difficult, while recording your washing machine and running it through a few effects is something you can do without changing out of your pajamas.

Anyway, I thought, “Well, might as well have the engine sound definable in player.xml”.
But I didn’t have a player.xml yet.  That was the last thing that still loaded from a white space-delimited text file.  So I’d have to add that.
But then I might as well have it define what equipment the player is using, instead of raw stats like “thrust” and “size”.
But then I’ll have to write equipment.xml, to define the equipment player.xml is now using.
And of course all this requires the code to load all that .xml into more useful data structures.  Special care must be taken with the equipment data, since I’ll almost certainly want all that neatly accessible by LUA at some point.

So, that’s all done now.  Also done: projectiles shot by enemies can impact the player’s ship as well as each other, and explode when applicable.  The AI is quite accurate with projectile fire- deciding how to write the motion-prediction code behind having the AI decide where to shoot was a significant decision, and the results are pleasing.  Dodging incoming fire is difficult, but not impossible.  I was thinking about adding in an acceleration term to the AI projectile aiming target path-prediction algorithm, but that might actually be a bit over the top.

I’ve rewritten the “AI”- at least, the part of it that determines, millisecond by millisecond, what direction the ship should be applying its thrust.  The problem is pretty complex.  First, I’m not realistically able to run the AI by pre-computing a path to a given destination, because over long distances, the path changes.  Planets move in their orbit, and a path that’s clear now might not be clear by the time a ship gets there.  Taking planetary motion and their gravity into account makes the problem complicated to the point where it’s more practical to use a moment-to-moment approach, instead.

So then, every ship needs to be able to look at the universe around it, and use that information to decide what direction it wants to be going in.  The following factors are important: the gravitational force being experienced, proximity to collidable objects, current velocity, engine power, distance to target location, whether all of that adds up to a likelihood of a collision in the immediate future, and what direction that collision is coming from.

My current solution uses a sort of priority system- the first priority is how imminent a collision is if the ship maintains its current velocity.  The more imminent that collision, the higher percentage of total engine output is reserved for avoiding it.  Second priority is gravity- every ship needs to strike a balance between not overreacting to weak gravity wells and not allowing itself deep enough into stronger ones that it is beyond the point of no return.  So a certain amount of thrust is reserved for counteracting gravity, depending on velocity towards or away from the source of the well and the total force, taken as a percentage of total engine thrust.  The final priority is getting closer to the target, without overshooting it.  Again, current velocity is taken into account, and whatever engine power is left over is devoted to getting to the target position without more velocity than can be burned off on arrival.

It’s a fair amount of math, and there are a several constants that need to be tuned.  Make one number too high, and ships will be over-cautious about gravity wells, and the player will be relatively safe near a large planet’s surface.  Make another number too low, and ships with strong engines might overestimate their stopping power, and collide with heavy planets if they have too much distance to get up a high speed.

Overall, I’m pleased with how it’s turned out.  Having a general solution for getting from A to B without making obviously bad decisions is a big step for a game like this.

I’ve been thinking about possible ways of interacting with or building an economy in the game.  In most games, a trading post is just one town, or one merchant in a town, or one space station.  So then it makes sense that one merchant has some limited inventory, and they can run out, and if they don’t have much left, they raise the prices.  In my game, however, it’s an entire planet.  Does it really make sense for the player to be able to, for instance, buy enough iron ore that it significantly affects the cost of iron ore for the ENTIRE PLANET?  Or buy so much that the planet runs out?  It seems kind of ridiculous.

I’d be in good company, though- popular science fiction has a somewhat poor track record for imagining entire planets.  How often is there a “jungle world” or “ice planet”, with a single planet-wide biome?  Or worse yet, a “city planet”.  Clearly, these are just ideas we’ve already become comfortable with from our own world- jungles, glaciers, cities- with the word “planet” stuck on the end.  Saying something like, “Oh, this planet imports coal and water and exports uranium and food” seems like a gross oversimplification.  Even modeling a planet as having a single political alignment seems silly.  Yet in a game with hundreds of planets, keeping track of much more data than that would quickly drown the player in swamps of spreadsheets.  I don’t want the game to focus too much on planet management.  There must be a reward for exploration, but not a penalty for not wanting to be an accountant.

So, maybe the player shouldn’t trade with his own ship at all.  Buy equipment, sure, but don’t start loading grain into your hold.  Combat ships are for combat.  But maybe you can hire merchant ships, instead.  Set up a trade route for them- they go to the asteroid belt to buy some ore, sell it to a refinery for metal, sell that at an industrial planet for mining equipment, and sell that back at the asteroids for more ore, for instance.  So there’s the option of becoming involved in economics if you want, but without having to sacrifice your own ability to do things besides sailing back and forth between distant planets.  Flying long, repetitive trade routes is the opposite of fun.

Especially since what I definitely want to do is create a feeling of space being big.  Big empty spaces, high velocity differences, not just what’s basically an airplane simulator with the sky painted black.  So you wouldn’t even want to be a merchant, because those ships are big and accelerate slowly.  They spend a long time just going through empty space.

There will definitely be equipment to buy, though, and either new ships, or some way to majorly upgrade the one you start with.  I want the player to experience that feeling you get in a pirate game where you finally get to a first rate ship of the line- you’ve finally made it, your ship is visually much more massive than your earlier ships, and you have more weaponry than most forts.  You’re slow, but your weapons let you reach out to whatever needs touching.

I’ve taken a break from the UI, so the news for today is I’ve stopped using:
stardata.txt
planetdata.txt
wormholes.txt
and replaced them all with a single universe.xml.  XML, if you’re not familiar with it, is a way of representing arbitrary data in a tree, where each nested relationship is represented by putting the child “inside” the parent’s node.  There are other features like validation schema, which I won’t be using.
It makes a lot more sense now from the data’s point of view- you used to have to give the ID number of which star each planet orbits when declaring the planet in planet.txt, now you just have the planet be a child of that star’s node, and it is visually pretty obvious what is going on.  The same goes for which galaxy/world each star is in.  It’s also now impossible to have a planet orbit a non-existent star, or a star in a non-existent galaxy.
I used rapidxml to make it happen without having to write my own xml parsing tools, so I was able to make the switch in a day, which is better than I really expected.