Meanwhile… while working on the AI I added the potential for AI ships to evade their attackers or switch to target them. The evade maneuver had an issue, it needed a power boost, so I added in afterburners (been meaning to add these for a long time). The result – much more fun, both in terms of seeing the AI use these in combat and in terms of using them in combat myself. Obviously afterburners have a variety of uses, close in on a target, run away from a target, boost to reach the new gravity drive speed threshold, do a 180 then engage burners to slow the ship down Lots of fun. Combat feels more tactical and engaging now that there is an added ship function.

Have been running through a lot of fighter versus fighter scenarios in a small asteroid field, and its a lot of fun, very happy about this, the AI now has about 4 potential “attack patterns” sometimes it chose them at random and sometimes it somewhat intelligently (very small decision criteria) decides the best one out of the available options. Battles are much more dynamic with this and seeing the AI use afterburners as well.

Still a lot of work to do on the new AI initiative. I want to make larger ships more interesting in combat as well, plus I have to add in “dynamic speed” settings for ships, basically having the AI intelligently speed up or slow down to reach a target, based on distance and target’s velocity.

The big news is that I greatly enhanced obstacle avoidance, something I’ve been struggling with for years now. Did I ever tell you the time about my super crappy implementations of this? no.. well.. let me tell you they were super crappy. The previous method was (when an obstacle was in a ship’s path) was to simply tell the ship to go to a position above or below (depending on if the ship was nearer to the “bottom” or “top” of the obstacle) the obstacle until it could look at the destination without any obstruction, this worked most of the time unless the destination was positioned in such a way that looking at it from the above/below was impossible, in which case the ship would fly off into space. Pretty dumb and not anywhere close to release worthy.

Needless to say path finding is a huge issue and was a huge worry, this new system takes into account what is in the ship’s path, and intelligently plots a course to avoid it – based on math – figuring out the perpendicular to a vector, then projecting that vector outwards to find a safe position. Somehow the crazy thing works, even though my math skills are embarrassing.

The other neat thing that I worked on was giving larger ships different turning and speed parameters when their AI is active. Basically the larger the ship the more it will turn to face its destination before engaging its engines, also during these turns the larger ships will turn more so than pitch up or down, this makes them more very much different from small fighters and corvettes, further distinguishing them, giving them a more epic feel.

Did an interview with True PC Gaming, you can check it out here. It was a bit harder than I thought putting my thoughts in writing. The interview also features new screen shots, showing the new art style. I’ve also added them to the media page on the main website here.

It was about a year ago that I first made the project public via this blog and the website. Its been a good year, hopefully this year will bring even more to the project.

I’ve started working on the new/enhanced AI. The primary goal is to give the AI the ability remember more than one task, as you can probably guess, the old AI could only remember one. This lead to a few problems mainly being that the AI was very inflexible, and that whatever task I gave it had to be complete in and of itself.

First up the inflexibility – say for example the player orders one of his/her ships to attack a object that is 1000 distance units away, but while the ship is flying towards that object it is attacked. Because the old AI only remembers one task at a time if the AI responded to the attacker it would forget the original order, because I want to give the player the ability of absolute command over ships in their arsenal, this meant that I had to tell the AI to ignore any attacker (the turret’s would defend the ship, but the ship itself wouldn’t respond) under these conditions (where the player directly orders a ship to perform an action, the ship would ignore everything else around it and try to do that action). But! If the AI can remember more than one thing, it can respond to things – in this example defend itself, and then afterwards continue onto the target that the player commanded it to. So giving the AI some memory is of clear benefit here.

The second issue is that the tasks had to be complete in and of themselves – this is actually an internal coding thing, so technically invisible to the player, however having each task be complete in itself means that AI tasks are prone to bugs, they are hard to save (for saving/loading), and that they are hard to add. So the new state of the AI is that it will be built up of small and reusable tasks that form larger ones.

For example this is how I stared coding what I called in code “AI Nodes”:
Idle node – set ship speed to 0
Wait node – use idle node until a timer expires
Turn to position mode – turn ship towards a specified point in space
Go to position node – use the turn to position node, and set the ship speed so that it can travel to the position
Go to object node – use the go to position node and update the position based on the go to object’s position
Follow object node – use the go to object node, when within distance of the follow object switch to the idle node.
Formation follow object node – like the follow object node, but instead of idling when near use the turn to position node to align with the followed ship, with some speed matching.

As you can see the go to position node uses the turn to position node. This very simple example shows how I can create more complex behaviors, eventually giving me the ability to set complex tasks, that are easy to arrange and create. For example: go to position abc, destroy this ship, pick up that object, and then return to position xyz. This could be useful for pirate raids, for civilian traffic, for trading ships, for scripted events, for boss battles, for cutscenes and other story elements – anything really.

The very very flight basics are in, what I’m currently working on now is the gravity drive changes for the AI and player controlled ships. All along I’ve been planning on not having the standard “warp” or “hyperspace” type mechanism in this project, instead what I call a “gravity drive” – a method of traveling at a high rate of speed, but not the boring already seen mechanics, instead ships can use the gravity drive to pull themselves (or as I like to think of it fall towards) large objects, making them choke points and giving them strategic value. These objects will be asteroid bases, large rocks, and potentially special “gravity field generating” stations and even maybe some special ships. So the player can either use standard engines to travel to a position, or can use the gravity drive to hop along from nearby large object to nearby large object until they get to their destination. So it basically calls for some basic distance comparison based mapping, which I’ve coded in tonight.

Next up more logic, the pull mechanism of the gravity drive, and better obstacle avoidance, then off to combat, and then off to intelligent node selection/addition/removal/management.

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.