This weekend was spent changing the way that the combat AI pursues targets. The issue was that often the AI would pursue targets forever, I’ve added some logic to prevent this – based on the new AI “postures” – they are very similar to the previous postures, except now there is a “Pursue” posture that means that the ship will pursue forever, this isn’t the default option, so most of the time ships will allow the player to flee, or won’t leave their bases to pursue enemies. I also added some triggers, and a “enemy to player” only faction – that will ignore anyone but the player’s ships, meaning that I can control the battle well. It can be awckward if you want the player to be attacked by 4 fighters, only to have a nearby base launch its fighters and intercept the attackers, sure sometimes I may want to help the player out, but when I don’t… I don’t.

Today I spent fixing the gate travel code – it was originally implemented a few months back – but never used. During the following months I’ve added features which broke the old gate travel system, but now its back in working order.

While looking at the game – I thought that I may re-factor the fundamental way that the “play areas” are setup. Right now everything is on a map (eg: multiple bases), and maps are connected via gates. But I may re-factor where only one or at most two bases are on a map, there are still gates, but adjoining sectors can be traveled to via the gravity drive. If you are confused as to what the difference between the two systems is – it is that the new method would have more potential for more “filled” play space. So for example in the old system I could have 100 asteroids, but because there are multiple bases (lets say 3) around each base would get 30 asteroids. With the new system of one base per “sector” – that base would get 100 asteroids. But let’s forget about asteroids for a moment, and consider assault platforms, or ships. Attacks would come from asteroid bases in other sectors, but the AI would only briefly live in the sector that the player is in, and nothing of other sectors would be rendered – thus letting the sector that the player is in – take more ships – in a more compact way. This would be a huge switch, but still the old system would remain, so for a more RTS battle you could have a play area like the current one, with multiple bases on one map, but for story purpouses the “less is more” sectors would come into effect.

Not sure that I’m making myself clear so I’ll stop now with this – today was fairly rough getting started coding, the weather is kind of grinding me down, still progress was made.

In the beginning of the week I re-factored the “objectives” code into “mission” code. The goal was that a “mission” could have multiple “objectives”. Objectives being test conditions for events – object destroyed, one object going near another, etc. So missions now can have multiple test conditions for success, eventually they’ll also have test conditions for failure as well.

Then I re-worked the text info for the player, lots of improvements leading into a dialog system. Basic stuff – in terms of – you’ve probably seen it before in other games. You see a portrait of a “speaker” and their dialog scrolls, and the player’s “avatar” responds. Some HUD mission info work was done, and I’m fairly happy with it.

This weekend I polished up the dialog as well as working on the first mission for the player which meant new triggers, objectives and cutscenes. Its going well, I’m almost done with the first leg of the intro, there’s even a few “hidden” missions for the player to stumble upon.

The rough goal is this – finish up the intro mission, polish, then release iteration 15. Then add in key mapping and then we enter the “beta” stage, and proceed from there.

Looking over the post above – a lot of interesting things (though whether they are interesting to anyone besides me is debatable) tend to happen, but then they drift away from my recollection so I might not end up writing about them. For example when I added a trigger for launching ships out of bases/stations. Previously the turrets (on a ship) would “pop in” right as the ship fully exited – whatever it was being launched out of. I scripted this “launch ship” trigger into a cut scene and so I thought – man – I’m showing this so early on and showing a odd turret pop in so early on, I have to fix it, and so I did. Just one of those somewhat unexpected/interesting things. Maybe its a good thing I don’t mention more things, kind of getting rambling here.

Early last week I improved the dock with and collide AIs. For the dock with – since the hangars/bases tend to have multiple launch tubes for fighter drones I enabled the use of all of them not just the first one as was the case as of the previous post’s writings. For the collide with AI I modified the “aim lead” code for projectile weapons and now have a freaky good collide with AI. Very happy about this because prior to this it was embarrasing to have the ore drone ship constantly miss colliding with the ore rock, then eventually getting lucky, it was made worse since you’d see multiple drones trying to smack into one rock, but ending up orbiting it. The other good news about the improved collide with AI is that I can use this for better “intercept AI” across the board. Since this tweak has ships leading other objects and chosing a path to intercept – where the object will be – not where the object is – which in case of moving objects – tended to mean lack of collisions/intercepts. So I can use this for combat AI, for formatino and go to AIs as well. Eager to get this implemented.

The mining process is mostly done its fairly fun to watch now that the pieces are fairly competent, it adds life to the game. Now I need to finalize dock with AI a bit, put in a error correcting system in place.

I then did some more work towards the HUD and UI – I realized that my line of thinking was deeply flawed – a face lift to a bad system – leaving the project with a better looking bad system. So I opened up a 2d paint program and dabbled some, when I’m ready for more contract art I’ll have a much better idea what to ask for, since I already made a lot of mistakes a long the way.

Then came some tweaks to planets, now there can be textured planets, including an atmosphere level, fairly basic stuff, but a good begning and opens up the door for lots of experimentation – again to see what works and what doesn’t.

This weekend I did a bunch of stuff across the board working on the HUD, story sytem, triggers. I also enabled the ability for ships to carry other ships – so unlike carriers the host ship doesn’t manufacture the ship(s) it is carrying, the host picks them up then drops it off. Allowing for the use of smaller ships carrying fighter drones, or beyond.

Next up – I’m getting close to implementing a “dialog” system – so instead of the old “Objective pop up” where the game pauses, they will be a real time conversation going on that the player may actively participate in – I haven’t decided yet. At this point the first leg of the “story” aspect of the game should be fairly well under way, meaning that I can release the next iteration.

I have a rudimentary “asteroid” mining system in place. Thanks to a new asset which is a cannon mounted to a rock. The cannon shoots an asteroid, the weapon fire creates “baby” asteroids that splinter off. Then a nearby drone hangar base launches drones which pick up the rocks and ferry them back to the base. Its pretty neat! I just have to polish up the collide with and dock with AI. It works, but the dock with AI needs error correction in case the ship doesn’t get in on its first pass. This is all automated or as usual the player can hop into ship, blast the rock then hop into a drone and pick up rocks. I hope that this aspect of the game adds to the live of the world, gives something for the player to attack, guard etc. There’s going to be another way of mining asteroids, for different factions, we’ll see

I also received another new asset – a “base” station. So I worked on having it orbit a planet. Planets were originally in the very early days of the game – in fact one of the earliest pieces of code I wrote was having them rotate and orbit around a sun – this wasn’t accurate in anyway, but hey they did move. I scrapped planets when they weren’t big enough or were too big and became navigational hazards, but always wanted to bring them back. And now they are – yay! For planet rendering I modified the new sun shader code by letting diffuse and specular light impact the “planet” object.

While adding planets, I polished up the sun/light handling code – now there are different types of “suns” – invisibile ones (only emitting light), billboard ones (2d sprites) and physical ones (ones that you can collide with). Adds a good balance of tools for future use.

This past week’s focus was almost exclusively on HUD and GUI. The great news is that the GUI is completely re-done and in doing so I learned a lot about how skinning (the visual representation aspect – both in terms of visual assets and the coding/scripting that goes behind the scenes) of it all works. The HUD has been re-done as well, and it has led to more understanding and knowledge as well – always a plus – and the visuals are greatly enhanced. I’m not embarrassed by the current state – hah! – that feels good to say – very pleased with the outcome. Though I hope for an even greater quality in the months/years to come.

What’s most interesting I think is how the process worked – it was essentially on a item by item basis – for example – here’s a cross hair asset, here’s a targeting bracket. And although this isn’t a great way of doing things – it is pretty much the only option for me and this project. A better way – I believe – would have been to have 10 different mockups/demos/prototypes and then go from there. Unfortunately there aren’t resources for this. So we have to hack away as best as we can.

A problem arose today that often happens when one project aspect comes to a close – is that I have trouble switching gears, though I did do some more work towards the story – it mostly came in the form of a good (I hope) idea that was spawned by a new asset – an assault platform – a big gun mounted to an asteroid.

As an aside – I keep having thoughts of scaling back – but looking through the GUI/HUD – I keep thinking why don’t we go simpler? I’m open to the idea, but for now I’ll continue on the current path. I hope to release iter 15 in about a month – so I have to be a bit more strict with myself.

Lots of stuff happening – mainly hud and gui overhaul – so 2d art.

Working with an artist and every day the old 2d art is getting chipped away. Interesting ideas tend to lead to new code to support the new art. A total 180 from working on story/cutscenes, no biggie, making good progress nonetheless. Very excited because a 2d overhaul was a big thing on my list – and because I can’t reasonably do it alone it is one of those things that was a mystery, in terms how – how, when, etc, now very much clearer.

The weekdays went by well – I each day I addeda nother little tid bit in the forms of what I call “triggers” which are ways of communicating with the game engine – outside of the game engine. So via XML (if this sounds too fancy for you – think of them as regular text files).

Here is an example of trigger:

trigger
__triggerType attr1="ship_command"
__shipName attr1="playerRaider"
__commandType attr1="goto_position"
__position x="0" y="0" z="-200"
__reletiveObject attr1="playerRaider"
/trigger


This trigger causes the ship named “playerRaider” to be issued a command to go to a position. Because a reletive object is specified (the same ship that’s being given the command” the position is calculated in front of the reltive object. Meaning that this ship will fly forward about 200 units in space. Using these sorts of triggers I can give orders to ships, I can create ships, I can destroy ships, basically do anything I want in a scripted fashion. Meaning that I can write a story line and that they are easily moddable – though time consuming.

This weekend I wanted to add something more substancial than the little daily triggers of the days past, so I started working on a cut scene system. To do this first I re-factored a lot of old code and put in better “state” logic in the main game loop. It was a combination of flags (booleans) and states on top of states, fairly messy. I re-factored it to be much better so adding the cutscene state would be easy. On Saturday I had a rudimentary cutscene manager working – only swapping to another camera outside of the ship’s camera. And tonight I have a bits of “cutscene fragments.”

Here’s a sample of a cutscene file (again in XML/text):


sceneFragment
__reletiveObject attr1="playerRaider"
__lookAtObject attr1="playerRaider"
__cameraPosition x="50" y="50" z="-100"
__duration attr1="4"
__headingText attr1=" "
__headingText attr1="Raider class light frigate prototype test"
/sceneFragment

sceneFragment
__attachment attr1="playerRaider"
__cameraPosition x="30" y="20" z="-50"
__duration attr1="10"/
/sceneFragment


This excerpt will have the cutscene camera look at the player ship at a certain position for a certain duration, display some text and then change to another position. Combining this with triggers the game will support a healthy dose of cutscenes

I’m very excited – I was bit worried on the cutscene aspect and now it is shaping up well, but it also is becoming more and more apparent how much work it will be to create a good visual/story experience – in scripting terms.

This upcoming week I plan on adding more triggers, more cutscene code – mobile cameras, zooming in/out, fade in/out, meanwhile adding in the beginings of the storyline.

During the week I worked on a “sun shader” – basically getting rid of the old “static yellow ball” sun and putting in an animated replacement. What currently exists is leagues better, but still (hopefully) not the finished product. A huge improvement and I’m happy to say goodbye to the yellow ball.

Here is a WIP video:

Few things to tweak – add rotation, potentially add “sun glare”, add “god” rays.

In other news I started working on the story elements. It was a bit of a tough start, because I didn’t quite know where to begin, so I decided to create the starting “map” and go from there. Because of the beginings of the story as I currently see it, the player needs to be friends with the faction that attacks the player in the current game in iter 14. This meant that I had to make factions – how they relate to eachother, more complex and dynamic. So I spent the weekend coding ways that this can change in game, and ways to keep the state of the faction as it changes in the game, before this factions were static. If they were enemies or friends they always were. This took a bit of re-work, but overall the coding so far is simple as it doesn’t involve 3d math I also tweaked some game art to prepare the starting ship of the player. I think its going to have a few unique characteristics that will be pretty cool I actually didn’t even code the first “objective” – which is a sort of a mini tutorial – a go here objective – since I had to first ensure that the nearby asteroid base and defensive platforms wouldnt’ blast the player into rubble.

I had a thought while doing this – that if I change the “story” to be just a series of very rigid missions, then I could hard code a lot of these values and that would make things so simple as to not need a lot of these past few days and future days coding. Anyway it crossed my mind and I continued coding – hopefully it will end up as I envision it, or at least close enough to resemble my goals.

Here’s some screen shots of the radar WIP. Yep it needs good art badly… Click on the images to get a larger version.

Old “non translucent version”

Improved translucent version

I overcame the major hurdle to make ship radar a neat feature – transparency. The way the the radar works is by creating a seperate scene, camera and window. The camera shows the scene which is simply 2d radar “blips” – which represent the reletive positions of objects in the radar. Anyway it took a bit of doing, but I got rid of the background of this window and thus it doesn’t obscure the hud as much – yay.

I wanted to add a “cone of sight” to the radar screen – and did so in the form of a 3d pyramid shape to represent the view from the ship. But it turns out that this pyramid is a bit tricky – it obscures other objects, changes their color, etc. There are tweaks to do, but for now I’ll let it go.

I also worked a bit on marking system for objectives in the HUD and tactical modes. For example if the objective is to capture a base then a yellow arrow will appear on the HUD pointing out the base that needs to be captured.

I’m running out of things to add before I focus on working on the story and its related elements. This isn’t to say that there isn’t plenty of polish, tweaks and even features to add, but the time is getting near to start on the story elements. It is a bit of a scary thought – since this will begin to test many things.