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.

Working on polishing command mode, it is going pretty well, there’s actually not a lot to do here, though this week has been fairly unproductive, I’m easily distracted and low on productivity – hoping that the weekend brings a change in this.

The goal/plan is to release iter 14 within two weeks – that means cleaning up command mode. I’m ready for it since I’ve been off on some tangents.

I’ve spent yesterday and today re-working transport ships. They now show the pods that they carry instead of the “invisible” cargo bay method of before. Getting the pods to attach to the ship was the easy part (though there’s a bunch of “invisible” stuff happening during the actual “attachment”). They now appear attached to the ship at the proper place, and detach somewhat visibly from the parent ship when the transport ship is at its destination. The annoying part was having to re-work a lot of the existing transport ship code that treated cargo in a very generic – just a number – way. Things got a bit more complex, because now ships have a set number of attachment points, so “cargo bays” couldn’t be as generic.

The thought that keeps popping up in my mind is how much transport ship stuff is there going to be in the game? The funny thing is that transport ships were one of the earliest types of ships in game, but players have seen the least of them since they’ve been not quite ready for a while so I’ve excluded them from releases, now they are getting closer to finished, so I’m hoping that they become a sizable part of the game – having spent a bunch of time on them.

I mostly finished up the explosion enhancements – having them push and damage objects. Created some funny “unintended consequences” while testing – such as infinite explosion loops. What would happen is – I’d have an explosion damage nearby objects – in this case an asteroid, which would spawn baby asteroids as a result, that when they’d explode would damage the parent asteroid. Infinite loop of explosions and thus a hang up of the game – have to be careful with these guys.

Then I jumped off to begining of re-doing the docking mechanism, previously docking was handled via a distance check – when a marine ship collided with an asteroid base that it was intent on capturing and if the marine frigate was within 30 units in distance of the docking area, then the marine frigate docked with it, but this method isn’t very precise. So instead of a distance check I’ve created an invisible collision object (just like the explosion area of effect invisible collision object) that waits for a ship to collide with it, this object is located at the docking tube, so this is now much easier to predict and more precise. This will lead to better docking mechanisms, potentially allowing the player to dock with bases for trade, story, capturing, and other purpouses.

After this I went back to command mode – I left it a bit because I became frustrated at the now much more complex control mechanism, but I found a better way and am very satisfied with the current state of it. Also I’ve updated some of the commands to be more intuitive – for example for the “go to or move” command – before I had the player use the A and S keys to move the go to position left/right, but now I changed this so that the mouse left/right movements do this, I think this is better and easier. Feeling pretty good about it. But now we are coming to some of the annoying polishes and more decision making. I might jump off to another area before tackling command mode again.

Here’s a new video showing off the current state of “Command mode”:

What do you think? I think its off to a good start, it is funny how these things evolve and how excited I get followed by the inevitable realization how much complexity even seemingly simple things need when I get into the guts of it. A lot of small issues have been resolved, but many still remain. I’m also hitting up against the control issue – meaning that now there’s ship mode controls, tactical controls, and now command mode controls. Each of these share some keys in common and have unique keys for unique actions, argh… I’m running out of keys – because I’m trying to keep things strictly left hand on keyboard and right hand on mouse… now this makes me wonder how left handed people will deal – well there will be keymapping don’t worry 10% of humanity But with these challenges overcome eventually I think command mode will add that something extra special – which is the lifeblood of this project, trying to draw people in, giving them options and a new twist on one of the oldest genres in gaming.

Off to explosions – I left command mode in about 1/2 polished state because I was a bit frustrated by the little issues, and wwanted to do something quick, and surprisingly this time the something quick actually turned out to be something quick. That something was getting explosions moving. When I say explosions I mean anytime a bullet or missile hits something or when an object (eg: ship) explodes. Before the little tweak (that took about 2 week day nights) hits and explosions would be still, and this would mean that if a ship is moving, and that ship gets hit, then the little hit effect would be left in the dust behind the ship, now they get their momentum from the object hit so they faithfully follow along. Its something that players might not even notice, because it just makes sense, but if it was in its old state, I think people would feel that there is something wrong.

The neat thing about the little explosion tweaks, is that in doing them I prepped explosions to be more sophisticated, leading to the goal of having “area of affect” explosions – basically an explosion that damages and/or has an effect on another object. Imagine a large ship blowing up, and that explosion’s shockwave pushing smaller ships away. Or imagine a weapon that fires explosive rounds that have a similar effect. Pretty excited about this, just another neat little thing.

Wish I updated this blog as much as I thought – man I should update the blog… Anyway while working on “multi turret mode” which allows the player to control more than one turret at a time – I realized that creating a seperate “command mode” doesn’t make sense. Multi turret mode is really command mode, but with the addition of issuing orders for the ship. The camera is already zoomed out a bit, and allows for 360 view around the ship so its only natural to extend multi turret mode with other capabilities for commanding the ship.

In a way command mode is a hybrid between ship modes and tactical, you can fight like in ship mode, but you can also issue orders like in tactical mode. The goal being of creating an interesting way of controlling large ships, so instead of moving the mouse and waitnig for the large slow ship to turn, you issue a command for it to turn, then you can controll turrets and pick targets while the ship turns, its sort of a task based auto pilot. You issue a command and then are free to control the weapons. Pretty excited about it – because without it large ships would be no more than large versions of small ships, thus making them somewhat pointless to even include in the game as player controllable ships. Hoping that command mode changes this.

I ran into a few problems, I wanted for the player to be able to issue a “maneuvering thruster” order, basically tell the ship to ascend/descent thrust right/left/forwards/backwards etc, struggled a bit with the coding behind this, but about an hour ago I figured it out, the problem is related to the ever present 3dness of the project, when there is no up/down/left right you have to translate positions to simpler terms where there is up/down/left/right – reletive to the ship that has to do the maneuvers, so that it knows which thrusters to fire. Hoping that the maneuvering thruster one day will complement ramming spikes/shields/maneuvers Maneuvering thruster’s are also important in terms of AI – right now its not very bright in certain situations, but with maneuvering thrusters ships will be able to more easily – dock, go through gates, and even fly in formation.

The past few days have been very productive – usually after I realse an iteration the week after is barely any coding/development – due to burn out, but I feel good right now. This could be because instead of my usual “release during the weekend” deal I released during weekdays. Tinal testing Tuesday, creating the installer on Wednesday then created the youtube “promo vid” on Thursday, meaning that I couldn’t spend the entire two weekend days on working on the project instead I did it in sections – since development/work on this project happens after my day job. Anyway somehow I avoided burnout.

On Saturday I started working on Turret mode. Meaning manual control over turrets, from their point of view. This actually was somewhat implemented about a year ago. What happened was that there were some issues with it (for turrets that were side mounted), and I didn’t have nice turret art so I disabled it and moved on. Because a lot has changed I had to re-work the existing turret mode and rebuild the gui, that took most of Saturday. Sunday was a bit more polish to the gui and I started on “multi turret mode” meaning control over more than one turret. So the player can hop from oen turret to another, or grab more than one, then spin the camera aorund the ship and have the turrets track the player’s view and if the player choses fire on that location.

I think its pretty neat Its my hope that this will enhance the “capital ship” mode of game player, fighters are already fun to fly, but cap ships turn slow, so what their appeal hopefully will be in this turret mode.

As I was putting in multi turret mode I ran into a problem – the player ship sometimes would obscure the target – since the camera spins around the player ship – the player ship is usually in view meaning that sometimes it can be in the way of your target, so what to do? I could automatically move the camera’s psoition up and down to look over/under the ship, but should the camera move up? or down? Both are valid answers – so what I came up with is to allow the player to manually control the camera up/down movement in multi turret mode (just like the player can controll the zoom) so I think this means that multi turret mode will be more fun and active Hopefully players will feel the same way too.

Still a bit to go, hopefully I’ll be done with turret mode this upcoming weekend, if it takes me two weekends to get a neat feature in, I’ll take that time line and be very happy with it

Almost forgot – because turret mode allows the view from the turret I’ll be modifying some of the heavier turrets to have a recoil when they fire, to give a bit more to the experience.