No screenshot this time! All I've done is just coding so far so a screenshot wouldn't be very informative. I will post screenshots of the new level editor when I actually start work on it though! I'm going to use this blog post to explain the central philosophy behind the project, and how I hope to achieve it.

The philosophy is simply that the source code of a particular project should be kept to a bare minimum. Writing more code adds more time, complexity and potential bugs, so I'm all for keeping it lean and tidy.

Three of the principles of my philosophy are

1. Code that isn't game specific should go in the engine

If I could reuse code for another game, then it should be in the engine. Asides from not needing to rewrite the code for each new project, this allows me to backport updates to older games that also use the engine.

2. Data should not be in the code

All of the data in Derelict determining character attributes (walking speeds, health etc) is hard coded in the game. By contrast, in The Kiwi's Tale, nearly all of the character and vehicle attributes are stored in plain text files. This allows team members (and even the general public!) to edit enemies without needing to recompile the source. The Earok Engine will contain several functions to handle importing data and scripts at runtime.

3. Loading of files should be automatic For example, by default in Blitz, you need to type something along the lines of 'HANDLE = LOADSOUND("SOUND.WAV")' for each new file you wish to load. This can be especially painful if you make a typo in the filename! The Earok Engine requires a folder called 'engine\sound' to be in the project folder, and it will automatically load all sound files from there (regardless of whether it's an OGG, WAV or MP3) and add it to an object collection. This isn't 100% efficient as the objects can't be directly referenced (just found from a list), but this should be unnoticible in the game, and will save a lot of coding and debugging time.

I am about a third of the way towards the first milestone, which is simply to extract and refine the core of the Derelict engine. I expect to begin the second milestone within the next couple of weeks. Stay tuned.

Happy New Years from Earok.Net

2008 was a pretty good year for me - asides from finally ditching blogspot, establishing my own website and releasing two full length games - It's been exactly one year since I hooked up with my wonderful partner Kirsty.

2009 will be a year that I focus relentlessly on establishing myself as an indie gamer. I will establish my own company for my new indie games, the name is yet to be confirmed. I expect to release three or four new games (or, at the least, much improved versions of old games). I also have a sales goal for my games for this year; exactly one - a signed boxed copy sold to some lucky person who'll be able to sell it for a mint in twenty years time if he holds onto it.

Now that it's January 1st, It's time to get to work on the Earok Engine. The first step is to rip the guts out of the Derelict engine, refactor it to increase readability and flexibility, change the function and variable names to match a new naming convention, while keeping the Derelict codebase stable enough to compile and play. I've already shifted Derelict's sound, music and fading libraries to the engine.

A dev post will be on the blog soon. Stay tuned.

Even though I have been programming games as a hobby for literally years, I always learn something new and important with every game I release. Here are some lessons I learned from our semi-remake of The New Zealand story:

1. 2D is not easy

After making several complicated 3D games in Blitz3D, I had made the assumption that an old school 2D game would be really easy. In fact it was really difficult, the engine took far longer to produce then I had originally thought (I was still programming it right near the end of the competition deadline!) and I easily put more effort into the collision detection functions then I did on Derelict. The single greatest freeware 2D platformer ever, Cave Story, took four years to make - 16 times longer then the deadline of our competition. The fact of the matter is, if 2D was easy, then we'd literally be flooded in games that are of that quality.

2. Version Control is nice

The Kiwi's Tale was the first of my projects to use SVN (Thanks Vijay P) which is a system that uses a central repository to synchronize  changes to the project. This allows for instantaneous updates, using the click of a button to download or upload only the files that have changed, even when the other team members are not online. In previous projects I had normally used email to forward updates to the other team members, which was obviously extremely cumbersome in comparison. I had also used the Shared Files function of Windows Live Messenger for another project, which was okay but it only works between only two team members, and only when they're both online. We were using Assembla to manage the source for The Kiwi's Tale, but they changed their pricing structure half way through the competition and no longer offer free project spaces for non open source projects. I'll definitely look at XP-Dev for my next project.

3. Frequent communication and collaboration is important

Stephen set up a Google Group was set up for the project, and using it to be our mailing list made communication between team members extremely easy. Half way through the project we began meeting every weekend at my place, to develop the game together as a team rather then individually and scattered. During these meetings we easily produced as much for the game in an afternoon as we had done over the preceding week.

4. Plan your To-Do list

While having a To-Do list is important, I found that producing a weekly to-do list with a different game task on each day rapidly sped up development. The other team members immediately noticed, going so far to describe my work as "Power Programming"! Asides from having the pressure of a deadline to push me to get things done, I found that if I knew I had a programming task due on a particular day, I'd subconsciously work on the task while doing other things, programming within my mind. I have since started studying the Getting Things Done (GTD philosophy) and using Rememberthemilk.com, which I expect to help me with my future projects both at home and at work.

5. When remaking, you don't need to do it too closely

This is a lesson I should have learned during Derelict, some of the criticism aimed at the Beta versions was aimed at features I had only included because they were in Space Hulk. From a game design point of view they were completely pointless for my game, and it became better when they were dropped. Likewise, in The Kiwi's Tale, there were several features that were only added because they were in The New Zealand Story, such as not being able to jump off balloons when in mid air. The game became more playable when this was dropped.

6. Good level editors are not easy to find

We were investigating two level editors for the project, Tile Studio and Mappy. Even though Tile Studio had some nice features, such as an integrated tile editor, it had a terrible export function: You can only export levels as source code, which makes it impossible for anyone to add or change levels unless they can recompile the source. Mappy was a little better so we used that instead, but it was still pretty flawed. The biggest flaw is that the tile art is integrated in the level files, meaning that each level in The Kiwi's Tale has its OWN seperate tileset. This made it extremely difficult to maintain a consistent look throughout the game, the filesize of levels became unnecessarily inflated, and it was an annoyance having to import and configure the tile art for each level. There may be better level editors out there, but until then, I'll enhance the Derelict editor and use that instead.

Kai Kasai did some really fantastic artwork for the game, including this awesome title screen graphic.

The competition deadline expired a couple of hours ago, I posted a copy of the game to the judges yesterday and a slightly newer one this morning. Three months and one week of work have come to a close. Thanks to all of the other Auckland Game Works guys as well as everyone who submitted a playtesting form. I am really happy to have my newest game released, the second one for 2008.

So what's next for me? Well, I've already got my first game project for 2009 planned, but I'm keeping it hush-hush at the moment. Announcement on the blog will come next week. I'm also really looking forward to playing the other entries in the competiton (already played a couple!) no doubt there'll be some fantastic ones out there. The competition build is available on the website here. EDIT - Download link fixed