1 May 2014

Post Mortem: Dissertation

So, I'm pretty much done with my dissertation now.

Simultaneous Localisation and Mapping utilising Consumer Depth Camera Technology

What an absolute arse it's been. Lack of foresight and understanding on my part led to a lot of trouble, particularly in getting it working well enough to be considered real-time.

But, hey ho. It's done now and while the end result is certainly not as good as I was originally hoping, I've still gained a huge amount from this ludicrous undertaking.
Here's a quick rundown of what I've learned, in no particular order:
  • Proper research and literature-derived design is KEY. If you neglect that, you're going to pay for it later on when you really can't afford to.
  • Robotics is a bloody hard field to get anything working in.
  • Agile development can work, but only if you fully embrace its principles in not only your management but also your development.
  • Iterative Closest Point is deceptively simple in theory, but very difficult in practice.
  • Covariance matrices are really cool.
  • Point clouds are cool.
  • Depth sensors are cool.
  • Modular testing is cool.
  • Hofstadter's Law applies to program run-times too.
  • Existing implementations are your friends.
  • Maths libraries are your friends.
  • Git Flow is your friend.
  • CARVER matrices are your friends.
  • If your project has severe risks that threaten its completion or suitability. RETHINK YOUR PROJECT. IT'S NOT WORTH IT.
  • Having a set of sticky notes with tasks above your computer really helps. You can see what there is left to do, and when you're done with a task you get the satisfaction of removing the note and throwing it in the bin.
So, yeah. As you can probably tell, it didn't so as well as I'd hoped, but it still went ok. Hopefully I've somewhat made up for the huge flaws in my project by identifying them and picking them apart in the evaluation.

I'm definitely glad to have this behind me so I can move onto projects new. My creativity has been stagnating as I've been stuck to this one project for so long. Hopefully next year with the stuff I've learned I can draw up a vastly superior plan and strike a much better balance between my uni and personal projects that will allow me to stay sane.

As a parting gift, have perhaps my favourite image from the project's testing:

17 Apr 2014


So, I was a bit bored and decided to write a simple little program to help memorise Hiragana, one of the japanese scripts (kinda like the roman alphabet, but with over twice as many characters).

Here's how it works:

The program presents you with a random Hiragana character (or pair of characters, for the diagraphs) and you have to enter the corresponding Romaji in the textbox. Then, you click the Check button and it'll tell you if you're right or not. In this case, I managed to remember the character for 'yo'.
If you have no idea what a character is, or can't quite remember, click the Don't Know button and it'll give you the correct Romaji. Remember, admitting you don't know is better than being wrong!

The program also records your progress within and across sessions (it generates a 'Stats.dat' file that stores your current scores, so don't delete it unless you want to reset everything). For each character, the stats tab will give you the Hiragana, Romaji, the total number of times it's shown you that character, and a grade on how good you've been at recognising it the last 5 times you were given that character (A is best, E is worst). Correct answers tend towards A, Unsure answers tend towards C and incorrect answers tend towards E.

UPDATE: Improved the character selection to prioritise characters you've done badly at. Also added instructions to the About tab and added proper assembly info (so it shows the program version in windows explorer).

You can download it for Windows here: BitBucket Direct Download
Do be aware, it requires the Arial Unicode MS font. If you're using Vista or newer (which you really should be), it comes pre-installed with Windows so no worries.

You can also get the full source code here: BitBucket Repository
It uses C# and Windows Forms and while the code is only lightly commented, everything is named and it's fairly self-explanatory. Feel free to do what you want with it, I don't mind, just make sure I'm credited in the About tab.

Oh, and by the way. If you find this program useful and want to thank me for it, consider throwing a donation my way. The button's on the right and even a couple quid means a lot to me.

8 Mar 2014

CanJam 2014

Yes, it's happening again. Team Norwegian Blue is competing in this year's 24-hour Game Jam.

We're all set up and ready to go, however this year we have our own team twitter account!

Watch us slowly go insane at @DeadParrotDev

7 Feb 2014

Khemeia Update

So, there have been some developments regarding Khemeia, my magical combat game.

First of all, my old team from last year's Game Jam, Team Norwegian Blue, decided to get together and develop a game. We all pitched ideas and Khemeia came out on top as the game to develop.

Secondly, as I'm in the process of transferring Carthage to OpenTK, and as Khemeia will require 3D graphics and physics, we have elected to use Unity 3D to develop it. It's pretty powerful, flexible and free to use, so it's a good choice.

Thirdly, there has been development! I've been working on designing more forms, getting the Form system transferred to Unity and adding the remaining elements to the energy system. Forms, Nodes and Links are all implemented, as are Invocations and some even have fancy effects! I've also added the maths for curved links and the resistance system which limits energy transfer across long links. In the process, I've also redesigned the Thunderstorm Form that I was unhappy with the look of and renamed it to the Ignis Caelestis (Heavenly Fire) Form.

We've also been considering more of the gameplay elements of Khemeia, in particular gamemodes and player-player interaction and have come to some interesting conclusions:

  • Khemeia necessitates objective-based play to keep the pace of the game up. We discussed the idea of a deathmatch mode and it just didn't work with the idea of Forms.
  • Players need some kind of direct attack against other players. At first I was vehemently against this, as the entire idea behind Khemeia was to prevent direct attacks. However, as it was discussed we realised that players would need some way to attack opposing players that they encounter. We agreed on a non-damaging (in order to keep to the no-direct-attacks idea) stun attack that would blind anyone nearby for a few seconds but deplete the user's energy reservoir, meaning they couldn't use the ability or be as effective at powering forms for a short while.
  • Players would need some way to communicate messages and positions with their Archmage and vice versa. As a direct position marking system would defeat the purpose of the Beacon form, we decided that only the Archmage can mark positions that only he can see, and can drop beacons for the players on the ground to see. In addition, players and the Archmage can communicate using text and/or voice, as if we didn't add these features, people would use ventrillo, teamspeak and so on to do it anyway. In effect, non-location-specific communication is private, but positions can only be communicated publicly in the game world.
As a little bonus, here's a gallery of all the art I've created thus far for Khemeia. Most of them are Form designs, but there's also a selection of element symbols, a design for the player character's robes, a Form that is serving as Khemeia's temporary logo and a stylised version of the unity logo.
Beacon Form.
Used to signal to the Archmage and other players from the ground.
Basically a magical flare.
Azoth Form. Heals all players within its area, friend or foe.

Aetherial Form. Shrouds players within its area from others.
Calcination Form. Burns all those foolish enough to enter it, friend or foe.
Redesigned Thunderstorm Form, now Ignis Caelestis. Calls down lightning on all who enter its area.
Essence Prima Form. Captures the souls of those who die within it's area and converts them into energy.
Soul Thresher Form. Captures and stores the souls of all who die within its area. Used to power other high-level Forms.
A version of the Unity 3D logo, stylised to look like a form.
Khemeia Form. Khemeia's temporary logo. Shows off the majority of design conventions common to Forms.
A selection of alchemical symbols from real-life alchemic lore. Used in creating the Form designs.
Design for the player robes.
The main colour shows the team the player is on, the trim colour shows their specialisation.

17 Jan 2014

Update and Realisations

So, I just returned from a meeting of University of Lincoln indie game developers, organised by the glorious Sean Oxspring. Between throwing ideas around and listening to stories, I showed Sean a bunch of the stuff I'd been working on over the past year or so (in fact, it's the set of demonstration programs for my Professional Practice mock interview) and he was very, very impressed.

This puzzled me a little. I never really considered the stuff I'd done to be all that impressive. Cool, sure. Interesting, I hoped so. But impressive? I'd simply considered them 'Good Enough'. However, Sean's reactions made me realise exactly how much I'd achieved with my work, especially Carthage.

I normally see Carthage as my fun pet project, a game engine written to help learn how games tick and solve a bunch of problems I encountered when wrangling with XNA.

However, while showing Sean Carthage's features, I realised that it's a hell of a lot more than that. Carthage was built from the ground up to be as moddable as possible, allowing entire games to be defined entirely through runtime-loaded config files and external DLLs, even the system to read these configs can be expanded in this way, making it almost infinitely modifiable. It allows for screens and menus to be set up using only a few config tags, with the internal system handling everything else (as opposed to pure XNA which requires that state management be implemented from scratch by the game developer). It has a greatly-moddable and expandable 3D procedurally-generated world library, with an open save format designed to easily accommodate the extra data games need to store. It even has an expandable ingame command console to allow for simple debugging at runtime without having to breakpoint or stop the program to toggle debug features!

Only now do I realise that Carthage is an incredible achievement for me. Two and a half years ago I had almost no programming experience and knew practically nothing about how games were structured internally. Now I have a well-structured and expandable game engine that has already been tested in two game projects and proven its worth. It's amazing to think just how much I've achieved already!

But it's not only Carthage. Also in my portfolio of demonstrations is a virtual machine that uses image files as memory, an incredibly optimised program for finding Narcissistic Numbers, a very depressing game developed from start to finish in 24 hours and a 3D sandbox RTS prototype with fancy visuals and a working genetic system!

Maybe I really can live up to the title of 'Code Ninja Extraordinaire'...

In an unrelated note, last weekend I had my first go at shooting a bow instinctively (i.e. like how you can just throw a ball and it'll go where you want it, instead of having to actually aim). I did fairly well, and it feels a hell of a lot more natural than using a sight.