Little stuff added/changed/etc –

I finally fixed the “attack pattern” that ships with primary missile weapons do, they now circle their opponents (a re-use of the “patrol object” AI) and fire missiles, instead of standing still. Giving them a bit more mobility on the battle field, and overall making the battle more interseting and dynamic. Since this is pretty cool I might re-balance some ships – for example the Intrepid frigate has missile launchers as secondary weapons, I might make these primary, or maybe I’ll just tweak the Intrepid’s AI to use this attack pattern in combat… yeah that sounds better… I’ll make this moddable too

I tweaked the way that turrets decide when to fire at their targets. The way a turret decides if it will fire depends on whether it has a good chance of hitting its target, the way this is decided by the turret is by calculating the needed rotations (in radians/degrees) the turret needs to turn to face its target. The position that the turret tries to turn to is the object position (for example an enemy ship). But because the object is much bigger than a single point in space – often turrets wouldn’t fire when they actually could hit their targets (this is especially true the larger the ship is). To fix this I added a bit of code to do a ray test (imagine drawing a straight line from the turret and seeing what the line hits) – if the ray test results in a positive hit of the targeted object, the turret will fire. This is a simple thing, but because it fits into the “oh my god its so bad” category – if it wasn’t done, that I’m happy to have finally done this. I attempted this before, but it didn’t work because my orientation of the turret math was wrong – making the ray test always fail, I fixed this math when I put in turret and command modes (specifically for the cross hair markers for turrets) so I put the math in use here as well – love it when this happens

Not sure if this fits into the “small” category (it will depend on how much I get into this feature) – but late last night and today I spent adding in a rudimentary radar system. So that we are on the same page – I’m talking about a heads up display that shows you nearby objects (right now just ships) in a semi – 360 degree view. Kind of like a mini map – but 3d. Right now it is full of bad programmer art, but the basics are in. It is another one of those – “it should be added because this is a space sim” type situations. I hope that down the line when the HUD/GUI gets a make over that this will be a very cool looking feature. I played a few instant action games with it and it is a good addition.

Goal was to have a fairly productive xmass vacation so I wanted to do a bunch of little things, here’s what happened:

Added a few ships to the game – they were of a different “faction” (the red ships you see in the video below) – because the way that factions were handled was hard coded – I re-did the way the game engine deals with them. I switched them over to be readable in via the xml files (like other objects). Meaning that they are moddable and easier to manage overall – adding new ones is adding a xml file instaed of changing the code in various spots. There was some very old code that I changed so it is a bit worrysome that I added a bunch of bugs, but so far so good.

Then I went in and added code for the “colony” platform. The colony platform boosts the crew capacity of bases – but at the cost of making that additional crew vulerable to attacks – if a colony platform is destroyed that crew dies. The goal for colony platforms is to give the the player/AI something to both defend (their own) and attack (their enemy’s). Hopefully adding a bit more strategy.

Next up I did a little bit of work on transport ships – since I added a visual “pod” when a transport ship picks up a cargo pod, I wanted transport ships to drop them when the ship was destroyed. That was pretty easy Next up I added a bit of GUI functionality for transport ships to request cargo from transfer stations (just like command ships do) and worked a bit on the transport ship AI, then dropped it after it was getting a bit complex.

Then I tweaked the way “in progress” commands appear versus commands that are being executed by the player’s ships – so when I say in progress I mean – when the player is in progress of issuing the command. So now there’s a visual difference between planning a command and seeing your ships execute them, I think its a small, but important aspect.

Today I tweaked re-did the follow AI – man o man was the previous code bad – the “following ship” would smack into the lead ship – almost every time. The re-done follow code uses the thruster command AI node (the same one that is used when you issue a thruster move command in – command mode) to maneuver to the follow point (eg: off the starboard side of the lead ship) when the following ship is close to the lead ship. The follow code is pretty good, I like the performance of the following ships in response to the lead, very happy with it. I did bit of work on the formation follow code (the difference between follow – and formation follow – is that “ordinary” follow is for non combat ships and they follow a good distance behind). It is a pretty complex issue – with a bunch of different approaches, I have to decide which one to take and then see where it leads.

Here’s a video for Iteration 14

There are a few more new features/items/etc in iteration 14 than are shown in the video, but these are the things I wanted to highlight. Also this is a first “iteration” video that features in game sound.

Hope you enjoy the changes!

I was stuck a bit this week because I wanted to re-do the formation and follow AI code – but got mired in it and decided to release iteration 14 as is – with formation/following code being extremely bad. Other than that it feels pretty solid. I’m going to create some media in the up coming days and then continue working on iteration 15. The other sticking point is that the holidays and my birthday are getting close so that’s taking some attention away from the project.

Right after the holidays is usually the most productive time of the year for the project so I’m looking forward to that winter – stay at home and code time

As I was play testing the soon to be released iteration 14 – the game crashed, frequently. The logs told me that it was a file access issue – what was happening was that sound files were locked when in use (creation/playing) and when the game engine tried to use them for another sound it would result in a crash.

I tried a few things, did some experiments, almost gave up on releasing iteration 14 without some sound bugs, but eventually prevailed and learned a few things about the project’s sound engine (which is an open source Ogre wrapper (a piece of code that creates a framework between two systems) for OpenAL. At one point I thought I might have to give up on this wrapper and try another sound engine – in this case FMOD was a potential. One issue is that FMOD is a licensed product (OpenAL and the wrapper is free), another is that it would cost some time to convert. Luckily I don’t have to think about this for now, but who knows what the future will bring.

So anyway, lots of bug fixes, tweaks, and play testing. I also did a one line of code addition that really helps out turret and command mode, feel very good about it now, hoping to potentially recruit some testers before releasting iteration 14 during the upcoming week.

This weekend’s progress feels less substancial then the last’s – but I think objectively it has been a very good weekend. There was a lot of xml (the data files) editing to tweak the sound paramaters and other settings. It is a bit overwhelming. I also did a lot of play testing and fixed a lot of crash issues. At one point I would play for about a minute, crash, fix the crash, then repeat the process. This happened about 4 times. Small stuff like switching from one view to another – after issuing a command in “command mode.” While coding I don’t switch views since I want to see the action complete, but during regular game play this (unforseen combinations of actions) happens often.

This highlights the importance of a regular release cycle – which forces me to play test and polish. If I left all the small issues to be fixed at the end of the project, I think it would be a huge mistake – I’d be buried under a pile of bugs. As it is it takes about 2-3 days of bug testing to get a fairly reasonable state out of the game. And although I think I mention this often – it feels good to fix these bugs, giving me more confidence in the project.

There is however a seemingly ominous crash bug, I’m re-using a few of the same sound files in different instances and it looks like sometimes a file isn’t being released before it is asked to be re-used by the file system causing a crash (file not available error), this is somewhat roaming of a bug appearing in different spots. The solution might be not to re-use sound files for hits and explosions – since these tend to happen quite often. We’ll see.

During the play testing I again realize that there is a bit of a play gap during which the player is waiting on resources. Recently I’ve been playing the THQ bundle and those games don’t tend to have any downtime, so it strikes me a bit in my project. I have to rememmber that my game is a bit different and more niche, players might not mind some moments of peace to consider strategy.

Hoping to release iteration 14 during the coming week. This morning I finished up some sound system change overs, using new sound files with the new game engine sound enhancements. Then I started some light play testing and bug/issue fixing. I’m going to do a lot of save/load testing as well since that caused a bunch of problems in iteration 13.

After iteration 14 I will focus on adding the story, so lots of story support coding and hopefully the start of the story will follow. The goal is to create a few hour sof game play that demonstrates the game fairly well and then push towards a Stream Greenlight campaign, and maybe even a Kickstarter – with the goal of getting funds towards re-doing the gui and hud.

This was a very good weekend in game development terms, I made up for the low productive week. Saturday I worked on polishing the transition between ship mode and tactical mode – I re-wrote the transition so that the previous hud, mouse and camera settings are preserved. Before this info was tossed away as it wasn’t needed since there was only one hud and switching back to cockpit made the most sense after exiting tactical mode, but now with command mode I wanted to add this polish in.

While I was working on the transition I also added some command mode commands – they are very basic but I think very useful – the first one is to “rotate to neutral” meaning that the ship will pitch and roll itself to be aligned with an imaginary “up” plane. I say imaginary because in space there is no “up” or “down.” The other command I added is an – cancel current command. Easy stuff, but again I hope very handy.

Having mostly did the transition polish and command mode polish I wanted to add some sounds that recently were designed for the project. I started with the afterburner sounds and wanted to consolidate sound creation and paramater specification via creating an xml readable in sound paramater file. Then I worked on re-working “main engine” sounds – although players never heard them, they were in game, but disabled because there would be stutters and other glitches. The sounds were tied to visual particle effects, and not every ship had a particle effect for every “maneuvering thruster.” The sounds also triggered badly and started and stopped in awckward ways. I re-wrote them and even polished up some engine particle effects glitches (overfirings on very minor thrust corrections) that have been lingering ever since I added in engine particle effects. Very happy with this.

I then moved on to weapon sounds – which are a bit more complex. Some guns will cycle sounds in a random sequence, some guns will repeat the same sound, but need to re-create it, some sounds loop and have a tail sound when the firing stops. This leads for the creation of a sound handler object that will handle this in a unified way (eg: for both fire sounds, engine sounds, and explosion sounds). Making sound maintenance easier and cleaner due to having it all in one place in code.

Other than that the weekend was good non-game development wise. We (the wife and I) went out for breakfast on Saturday, saw a movie on Sunday and took a walk around the neighborhood with the sun shining.