While working on switching the new game/instant action/tutorials over to reading data from xml files instead of being hard coded into the executable I needed some more info added to the save game file – now that research was being read in via xml I needed the save game file to have a link to the research file. So as usual I added it in to the save game file as plain text, predictably the game crashed on a load, my method of saving and loading is very primitive and relies on an exact sequence. The crash was caused due to me not obeying the exacting rules, usually I’d look through the code and mirror the save/load, or find some typo, but this time I decided to do away with the primitive method and switch over to the xml tags method as I’ve been doing for quite a while now.

And after two days of fairly boring coding in between spending time with relatives, I’m to the point that saving and loading work again, but are most likely very buggy. The good news is that crashing on loading should be mostly a thing of the past, however having the game crash during this stage of development isn’t always bad, it immediately told me there was a problem, and usually led me to where the problem is fairly quickly. Still this method is better, is much more flexible, easier to manage and will even lead to save games not being incompatible with every little change I make – which will be very handy during testing.

Now that the save game files are xml they are very human readable and thus editable, I’m not sure if I’ll throw in some protections against editing the save game files, all the other data files are easily editable for modding so there may not be much point, but we’ll see.

I’m itching pretty bad to add something substantial (and more creative coding wise) to the project, once the holiday season is over and I still have some days before another semester starts I’ll focus on the AI upgrades.

Progress is going to slow down a bit, Christmas is coming up which traditionally would be a big boost to me since I tend to take a lot of time off, but with Christmas this year came a guest and lots of sightseeing and activities.

So when I do have time I mostly stick to small tasks. That don’t require too much creativity/thought, but mostly visual observations on things that are obviously missing and/or need fixing.

Asteroids now spawn “baby” asteroids when hit by fire. When destroyed an asteroid may split into one or two pieces.

I’ve worked on objectives, rewards and triggers a bunch. Refining them, adding to them, that sort of thing.

Hmm… this could also be a good time to do bug fixes… maybe I’ll designate a few hours here and there to do that.

While re-vamping the start new game/start tutorial system I thought that the first “flight basics” tutorial shouldn’t include an asteroid base – to cut down on complexity and laser focus on the tutorial objectives. But a barren map wouldn’t be appropriate either, so enter asteroids. I’ve been meaning to add these since forever, but finally got the motivation to do it. There are a few different types – ones that move and ones that don’t – the movers move depending if your ship has enough mass to move them when there’s a collision.

The future of these objects yields some neat possibilities – shoot larger rocks to make smaller rocks. Particle effects around bigger ones – dust clouds, smaller rocks, hollow asteroids and quite a lot other neat potentials.

Via the battle editor duplicate button I can quickly generate some fairly “OK” fields, the battle editor automatically randomizes the rotation of the few rock models that I have so far, so that they don’t appear completely alike. Even at this very basic state of asteroid field generation they add a lot to the emptiness of space. Now to teach the AI to avoid them…

In other news, there are now 3 new ship models, 1 new station model, about 5 asteroid models, a few new turret models, new torpedo models and another station mostly done. So content wise we are heading in a good direction as well.

Did a lot of behind the scenes overhaul, got rid of a lot of noobish programming practices – using strings (eg: ship names) instead of their memory addresses to identify/compare/assign objects. The newer method is both faster (though CPUs are so fast it doesn’t really matter) but also easier to debug and error correct.

I was about to overhaul the AI, but I felt somewhat hesitant, I didn’t have the exact method in mind so I wanted to hold off a bit so I did a few battle editor changes, you can now specify targets for ships, and link stations to bases (so that a shipyard can produce ships using the base’s resources). Also you can specify backgrounds and light parameters in the generated files.

Next up I decided to tackle tutorials, they’ve been text files for a while now, but not in “xml” type format so I decided to convert them to make them easier to maintain. This will also impact objective files for all game modes – and basically overhaul how games start and load, before game starts were hard coded, after these changes they will be read from xml files meaning that they will be open for modding and easier changes.

I started working on what I call turret roles – basically a turret’s automatic behavior. Prior to these changes turrets took their parent’s (either ship or station) target, if the parent didn’t have a target, turrets took as their target the parent’s attacker if any. This was way too dumb though, the goal is for AI in this project to be somewhat self sufficient, allowing the player to focus on combat or other tasks – there are so many that a good amount of automation is needed. Besides in the game’s universe these are space ships, crewed by sentient beings and sophisticated AI – they should make somewhat logical choices

Here’s a brief overview of the roles:

Point Defense role – get nearest missile or torpedo that is targeting the parent – otherwise use the defense role for target selection.
Defense role – get nearest ship that is targeting the parent – otherwise use the Parent’s Target role for target selection.
Parent’s Target role – same target as the parent – otherwise (if parent doesn’t have a target) nearest target regardless if it is targeting the ship or not.
Offense role – using the turret’s priority targeting list find the nearest target.

—-
I hope what I accomplished in these roles is a fairly simple system, yet one that gives a good degree of control over the turret. Some of these roles fall back on other roles that are somewhat related – if no missiles, then look for an attacker, if no attacker, then look if parent has a target. Also the Offense role mentions a target priority list, prior to these changes only ships had a priority list of targets, now turrets have this as well. Basically some turrets may work best against some types of targets, for example a slow moving heavy turret shouldn’t try to hit fast moving fighters, instead it should try to target a frigate or bigger ship first.

These roles will be specified in the turret’s xml file, so ships can be fine tuned to their roles on the turret level. For example a corvette may have a light turret for missile defense – giving it more of an edge versus ships with missiles. Or a frigate has a heavy turret for offense making it an assault frigate. These roles can be changed in game by the player – per individual turret. If about to assault a station with torpedoes, setting a turret or two to point defense might be a wise choice.

—
Having turret roles also allows for the expansion of ship roles – for example a ship that ‘s set to defensive could have its turrets set to point defense, a ship that’s set to aggressive could have its turrets sent to offense.

So normally the past weekend would have been spent preparing the next release, instead I added a few neat features related to missiles. There is a big benefit to a longer cycle between releases, it gains an extra weekend a month of coding, weekends being when the major additions come about. Plus usually during “release weekends” I get burned out from the bug fixes and other little details that I often have to take care of, names in the installer, turning off debug options, bug testing, prepping the installer, finding that it doesn’t work, prepping it again, uploading etc.

So again I don’t think we’ll see an iteration 11 in November, or December. January is fairly fitting for iter 11 because that’s when iter 1 came out – wow almost a fully year ago.. the project certainly progressed. Hopefully, given another year it will be good enough for a commercial release

In other news, I worked a bit on the camera system, I added a camera roll when the ship rolls in first and chase views. Also I tweaked the camera movements in these modes to make the camera more dynamic, that and the addition of the roll has a pretty neat effect, giving a sort of a “wild” animal feel to controlling a fighter.

So for the first time since the project went public there won’t be a monthly update. Reason being is that although quite a lot has changed since iter 10 (take a look at the current change log here) there’s not much to show. For example the game now features pivoting turrets, “energy” missiles (something like photon torpedos from Star Trek), torpedos (slow moving destroyable missiles), multiple barreled guns (for turrets mostly), energy bullets, rocket bullets, and a new shotgun type of a gun. There’s quite a lot more changes, so why not release them to you to enjoy? Well just because the turrets can pivot… doesn’t mean that I have turret models that support pivoting (I only have 1, an awesome one, but still just one). There is a new super cool “shotgun” type gun (shoots bullets in a cone) but no ships that actually have it. So in the end Iteration 11 would look pretty much like iteration 10 – only most likely more buggy.

So I decided that iteration 11 will take some more time. Also I’m not sure if iteration 11 will come at the end of November, behind the scenes there’s a fairly big graphics overhaul going on so releasing it piecemeal would diminish the effect, plus the aforementioned aspects. This may become the norm in alpha as the focus is on polish more so than adding in features month by month. Let me know what you think and feel about this, your feedback may sway me to release updates in a more timely manner – if there is something tangible to release.

Instant action mode and the battle editor are coming along nicely. XML files are working – the game reads them to create ships/stations/asteroid bases. You can now mod in game objects now, add in new ones, etc. Go nuts! You can make a carrier whose hangar bay launches has other carriers! Oh the infinity! Will have to create some documentation on modding.

Also I overhauled the way that moving objects happened (either station placeholders or instant action objects). Pretty happy about this, been meaning to improve this, I think its pretty sold now.

Somewhat worried because I’ve modified the game in several key places and didn’t do much testing. Hopefuly not too many bugs in there. Also the XML files could have a lot of typos leading to sluggish ships (if I typed in the speed value wrong) or other issues.