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.

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