I'm not sure I'll ever stop being surprised by how things that appear to be really simple and have not so simple intricacies within.
I made a game for the LowRezJam where you are restricted to only ever displaying 64 x 64 pixels. I settled on making a game where those pixels are for a sensor on a space telescope and the player acts as the onboard computer, searching for exoplanets. There's no doubt that I was geeking out on my space game. I made an intro scene which goes through the basic stages of a rocket launch. I have the first stage simply fall into the ocean, but during this jam, SpaceX landed their first stage on a barge in the ocean. Figures, my rocket was immediately outdated.
The first pass of my game was that the player would need to stabilise the spacecraft before it could start analysing the stars that it could see. It would then find exoplanets based on how far away the stars were. It was my first time using Unity's Lens Flare. They don't look amazing usually, but with the pixelated script I had running on the camera, they looked surprisingly stylised. They could have their fade speed adjusted which worked nicely for an "exposure" effect, where the stars further away would take longer to appear.
I created it so that there were different types of stares, dwarfs, ordinary (like our sun), giants, pulsars and black holes. Each had a different probability of having a planet orbiting it. Each star also had a different likelihood to spawn. And then there are 3 different types of planets that can spawn, rock, ice and gas; and each of those have different properties (size and distance from star). The orbits of the planets are randomised so that the normal to their plane of rotation was random, as you'd expect. This create the real problem of the fact that some stars have planets orbiting them but they don't eclipse their sun so are harder to spot. I was happy with all of this, but feedback I got was rightly that there was almost nothing for the player to do. They could just move the camera to a new spot and then leave it to find planets itself. Not much gameplay. While I was happy for it to not be very filled with gameplay - just something to geek out with - I did want the players to try to hunt for the eclipses.
Initially too, there was no visible indication of the found planets. So I created a simple target image that I'd use in Unity's UI to show up when a planet was found by the automatic analyser. A simple task that was absolutely not as simple as I had expected. Unity's UI doesn't simply move around using it's position... it has a confusing maze of transforms. Great for using the GUI in the editor to set up UI. Not so great when you want to do things in code. I tried lots of attributes that didn't behave as expected. The most obvious one was the "position" but... wow... no. Maybe local position? Negative. Perhaps the offset min/max? Nope. Eventually I got it: anchor min/max. Setting both of those to the same position essentially allowed me to move them where I wanted in viewport space. Later in development, I also came across an issue with scaling. The game has a screen at the start that lets you change the scale of the screen (either 64x64, 128x128, 512x512 and even 32x32). I'd been testing in the largest scale because that's naturally the easiest to work with. However when I tried the smaller screen, the targets were still the same size - and so relatively huge! While in playmode, I tried changing a setting and viola, it was the correct size relative to the screen! So I exited playmode and made the same change. Then I started the game again and... nothing, the targets were being scaled too small to be seen. I reverted to the original setting and pressed play. Huge again. Once more while in play I changed the setting and they scaled exactly as I wanted them to... So my fix? I keep the setting that makes them too big in smaller screen sizes, and then in script I change the setting. And that works. Fuck if I know how or why.
So now I could have the target pop up when a planet was found. Unfortunately, I thought the stars looked really good, and very quickly loads of targets filled the screen, and looked shit. My quick fix was to add a button to toggle whether the UI showed the found planets.
There was still the issue however of lack of playability. I decided that instead of just showing the player all the planets, it could throw in some fake ones and the player must determine which were real. This helped slightly but there were still issues. For example, a player might see a star very obviously get blocked, but will have to wait until the computer highlights it before they can claim it. Additionally the randomisation of the planets made it really difficult to find lots of planets. I needed a further overhaul.
Eventually I made it so that there was no automation. In retrospect, this is an obvious thing to do, but I guess I was just wanting to make a cool gadget instead of a game. But as I went along I definitely wanted more input from the player. So instead, the player highlights a star by putting the mouse pointer over it and they can then select it if they think that there is a exoplanet there. Find 10 and they win, mess up 5 times and they lose (so that they don't just go on a clicking spree). I also overhauled the planets. To my upset, I removed all the orbiting crap. I originally tried to increase the likelihood of an eclipse by increasing the sizes of the planets and slowing them down and putting them closer to their stars and... it was just getting absurd. So instead, they now move backwards and forwards along a straight line that points towards the camera. This way I could guarantee eclipses while still controlling their length (by adjusting the midpoint of their movement). This worked perfectly and made it much more playable, as now I could be sure players would be able to hunt for the planets without the risk of too many being out of view.
I did however have a weird bug where a target would appear over apparently nothing. Sometimes a star is really far away and so it's light takes a while, but sometimes nothing would ever appear. There are black holes in the game but they're incredibly rare and I aligned my scene view camera with the game camera and there was nothing there (I have Gizmos to help show me stars and planets).
What the fuck was my camera locking onto? And then I realised. I turned the scene camera around 180° and sure enough, there was a planet that lined up from the target through the camera. The way I do my targets is to make an array of them (enough for every star) and then make them transparent. They then are locked to their equivalent star and move was the camera rotates. They then appear when the mouse hovers over them. As I should have expected, things behind me when converted into view space will fall back on screen. I fixed this by simply disabling the target so that it's hit-box wasn't being picked up if the star's behind the camera. I later refined this to only enable if the star comes into view.
After tracking down a few bugs, I was able to finish up the game. It's not a huge game - it's a game jam game - but I'm really pleased with how it's turned out. And while I was originally a little sad to drop authenticity for playability, I can see it was the right move.

Holy shit it's been a while since I've updated my blog.
What the fuck have I been doing since March 2014?
Well I guess the TL;DR of it is I was more active in both my space and games aspects of my professional life.
I graduated from my masters course with a distinction and decided to stay on at my job working on satellite software because not only does it pay much better than making games, but I can actually afford to do both using that wage.
I can't overstate what a fortunate and privileged position I have found myself in.
I fucking love my job, I have a comfortable living and I have 100% freedom of expression in the games I create without having to worry about whether it'll make enough money for the game after.
Not only do I earn enough to get by, but with appropriate budgeting, I can afford to attend various conventions dotted about the globe to help expand my knowledge and understanding of games.

As well as procedural generation, I need to implement some form of post processing effect. This is of course the same case as the coursework requirements from my third year. Post processing however was definitely the weaker of the skills that I picked up from that project. I'd had high hopes of implementing high dynamic range lighting but I struggled to get my head around the pipeline which meant I was left with barely any time to implement a decent effect and thus settled on a hacked bloom effect. It was OK but not managing to implement it has snagged at me ever since.
Now I'm required to do the same task, as with the procedural generation, it will be a good measure of how my knowledge has improved over the course of 2 years.

It's so difficult, especially in graphics programming, to not get distracted by something shiny.
I've now moved onto properly testing the 3 tiered matrix system in place for the podracer engines. First they're moved along with the pod. I chose the pod to be the parent because it's easier to have that as the fixed position and move the parts about to make it look cooler. The second tier is the positioning and rotation of the engines relative to the pod. I've got it so that the podracer can take input for how to turn the engines which rotates them around their forward (local z axis). The final tier is the individual podracer parts which are moved when the engine/pod is generated and should stay in place. To test these, I have the pod flying forward (slowly so I can properly observe it) and then have one of the engines rotate, I then make one of the individual pieces rotate. Seeing this work is what made me notice something shiney

So with my terrain being in a good place, namely it's procedurally displaced and I can collide with it (albeit simply), I wanted to move onto my racer. 
And I'm glad I did.
I hadn't realised quite what a task the podracer is going to be. I obviously knew the project as a whole is a large undertaking, but I didn't think about how much I wanted to put into the racer itself.
The first issue I came across was how exactly I was going to create these podracing engines from multiple model modules. The answer of course, was instancing.

Another first for me: procedural terrain collision.
As awesome as my procedural planet was last year, collision with it was limited to spherical collision based on it's radius. To actually collide with the planet, I would need to cast a ray to the centre of the planet, then evaluate the generation function at the point along that ray the radius units from the centre. Totally doable, but I just didn't have the time and there's an endless list of features I wanted to add to that application: There's literally the entire universe worth of things I could add and then some.

So the last blog update has barely dipped it's toe into the ocean that is the internet and I've got more to talk about.
After getting my noise to render correctly, I was ready for the big task of creating the terrain manager to make the patches.
I am currently really poor at estimating how long something will take me. Those tasks that I'm convinced shouldn't take long seem to take much longer and task that I fear will take too long barely take any time at all... Fortunately that's working in my favour at the current moment in time.
Implementation of my terrain manager wasn't plain sailing however.

So I've got normals added to the vertices. As I went to write this, I was preparing the following pictures:

What the show is the apparent discrepancy between the detail of the terrain and the normals generated. The first patch consisted of 64 x 64 quads and the normals are close to what I want, although it is obvious it's low quality. The following two images show a 512 x 512 patch and a 1024 x 1024 patch respectively and the lighting that those patches generate. While they are much smoother, the normals appear to be fading as it gains more detail. This was really confusing me, I could intensify the lighting in the shader, as I have done in the fourth and final image, but as the image shows, this can effect the parts that should be lighter too.

While working on another project I had a epiphany regarding my graphics terrain.
The terrain model correctly maps out the diamond pattern to the specified density of quads (split into triangles). As I was rendering using an index buffer, I could actually render lower levels of detail. It would require having multiple index buffers and so come at a more considerable memory cost, but would require negligible additional computation at run time but instead would make the quadtree based LOD system run even more smoothly as I could simply set the level of detail to render a terrain patch much easier and still use static terrain vertices.
I had an idea in my head about how I could do it, it would be maybe a ten minute job to add in the functionality for multiple index buffers.

It's a little disheartening to be spending my time trying to recreate something I did in 3rd year.
I need to create a terrain class for my framework and so went about creating it. However, as with rewriting my framework, I wanted to make improvements to the terrain.
In 3rd year I made the diamond layout (as can be seen in my blog post relating to my 3rd year graphics programming development). I do enjoy being able to avoid if statements where possible, but given time is, as ever, constrained I decided to just go for the more readable if statement to generate the diamond pattern. This time around however, not only do you specify the width and height of the terrain, but you can specify the triangle density of both the width and height. Additionally, the terrain calculate the correct UV coordinates.