Subscribe to:

The Kiwi's TaleWitchBlasterDerelict Blow Stuff Up

Syndicate content

The Earok Engine is now on hold

I have come to the conclusion recently that I have been spreading myself too thin with personal projects. Asides from the Earok Engine, there have been others carving up my time - such as BlitzMax port of an old Blitz3D indie title (Details are under wraps for the time being), a new website for Auckland Game Works, and the game design document for what may be my ultimate game. With so many projects going on at the same time, I can't properly commit to any of them, so the plan is to put the EE on hold until the others are out of the way. I'll renew my focus on the EE at the start of February.


EE Dev Post #1

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.


Played Doom the other day

I was hosting a LAN Party the other day and, at about 3am in the morning, we were struggling to come up with a game to play. One of my mates suggested Doom, so I downloaded the shareware edition from the internet and linked it through to jDoom, and a few minutes later three of us were space marines knee deep in the dead on Phobos.

And.. it was awesome. No, it was f*cking awesome. I was astounded that the free shareware version of a game from 1993 could hold our interest longer then modern first person shooters or real time strategy games.

The shareware Doom is filled with traps; nearly every switch, every keycard, every ammo cache has a  squad of demons and gun-toting zombies waiting behind a nearby wall. But it was incredibly satisfying turning the traps, so elaborately set by John Romero and Sandy Petersen, into ambushes for the monsters as we slaughted them from every direction.

We'd have one point-man sent to spring the trap, one person sent in as a sidekick to cover his back, and the third person would act as sniper, providing fire support from the entrance or a near by ramp. There were other times when a particular room was equally approachable from two entrances, so we split up to overwhelm the enemy from both directions.

Also, when approaching a door when suspected had enemies behind it, we'd all line up together so the poor bugger on the other side would be hit by three shotgun blasts simutaneously. We also carefully rationed ammo and health packs between us when one of us was running low. Sure, it made the game really easy, but it felt really good.

I want to emulate the experience I had that night in my own games, so it got me thinking about Project Firestart and Derelict. Asides from adding online multiplayer (which will be an absolute top priority for any future versions of either of them) it got me thinking about how I could change the fundamental gameplay of Derelict to make it more varied, interesting and satisfying - instead of focusing on perpetual defence while you moved your team from A to B (even the boss fights were tactically defensive) making it so that a fair bit of the game was offensive - working out ways to launch coordinated attacks on certain enemy infested areas - would make the game far more enjoyable.


Happy New Years

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.

The Kiwi's Tale Reviews

Reviews for The Kiwi's Tale are trickling in:

Idealsoft (Translated from Italian) - Positive

Captain D - Positive Softonic - 4 out of 5

Zolyx - Positive (Translated from Czech) - 8 out of 10

Up to Down - Positive

iDNES (in Czech) - 80%

Freegame.Cz (Translated from Czech) - 87%


Overall I am extremely happy with the critical reaction to the game. The amount of foreign language reviews was surprising though! I'll definitely take localisation far more seriously for my future projects.

The Kiwi's tale: Some lessons

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, 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.

My next project

A couple of months ago I had another look at Derelict again with fresh eyes. Instantly I saw serious correctable flaws with the game that I had either missed or brushed aside, and knew I had to fix them.

So my plan had been to do a second edition of Derelict, with massive amounts of recoding to make the game a more immersive experience. The first part of it the planned project was to seperate the graphics engine (the part that does the bumpmapped walls) into a seperate codebase, the idea being that I could reuse it for other projects. I also wanted to extend the graphics engine a bit, by adding code for Terrains, since I wanted to set part of the new version of Derelict on the ice world in the background.

Then I realised that the upgraded engine could be used for games that were completely disimilar as well. The same code that renders the walls and floors, for instance, could be tweaked to render buildings and roads. The level editor I made for Derelict could, with a bit of work, become a more general purpose level editor for making levels for practically any 3D game that uses a tile system.

There were also lots of little pieces in the Derelict codebase, such as 3D Bitmap fonts, a 3D Sound system and an A* pathfinding algorithm that I could also chuck in the engine, as well as parts from my other projects. I thought that, if could extract much of the Derelict codebase to put into a seperate engine, then I could use that same engine to finish some of my abandoned projects (Raid Over Moscow, Traffic Department 2192, Luger Me Now) significantly improve some of my previous released projects (Project Firestart, Derelict, Blow Stuff Up) and use for brand new projects (Such as a First Person RPG, the Prince Mince RPG or Derelict Online). The problems of needing to continually write and rewrite boilerplate code for each new project would be gone, and upgrading the engine would upgrade every game that was hooked into it.

So, I'm announcing my next project now: The Earok Engine, or just EE. Currently, I plan for it to include the following components:

General Libraries

  • 3D Bitmap Fonts
  • 3D Image Drawing
  • 3D Sound
  • Configuration File Management
  • Media management (Automatic loading of textures and sound files)
  • Misc math, physics and general functions

Level Libraries:

  • 90 degree architecture combined with bumpmapping (As seen in Derelict)
  • Object placement
  • AI* Pathfinding
  • Skybox and Terrain Management


  • Level editor, which can be used in 2D overhead or 3D first person modes.

I plan to spend a couple of months doing the primary development of the engine, but I'll continue to refine and upgrade it as I work on game projects. I won't be making this project publicly available, but I would definitely consider any requests for it if someone else wanted to use it in their game project. I'm really excited about this project. Work begins in January. Stay tuned.


NZ Story Remake Dev Post #15 - It's done!

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

Blog Bits #3

1. AGW Meetup last Sunday

Our last AGW meetup for the year was on Sunday. RvB were kind enough to allow us use of their TV screens, which made playtesting the game far easier then it would be if we had to do the usual thing and crowd around a laptop (!). We had a new attendee, a guy who works for Virtual Spectator, the company that developed the broadcasted 3D Sailing simulators for the America's Cup. The highlight of the Meetup for me was BlitzBasic creator Mark Sibly gracing us with his presence, it was really good to see him giving his approval for the game. I also had a quick word with him regarding his future plans, which are all very hush-hush at the moment, but they're very exciting to say the least.

2. Competition update

Only 36 hours to go until the Retro Remakes 2008 competition is at an end! The guys and I will be meeting tomorrow to finalise the competition build and post it to the judges. Expect to see a copy of the competition build hosted here in the next day or so. After the competition ends, I intend on reviewing each and every competition entry in my blog, though I'll do this over several weeks.

3. The Escapist on 'Falling, Failing, Feeling'

I came to the Escapist for Zero Punctuation, but find myself coming back again and again for the interesting articles! This recent one is definitely worth a read. I haven't actually played either of the games it discusses (Prince of Persia and Mirrors Edge) but it's suggestion that the perceived difficulty of games can be more to do with the storytelling of the game rather then the required effort, time and skill, I found to be extremely fascinating. I finally understand why gamers don't find modern games to be too ridiculously easy, even though in most cases they are!


NZ Story Remake Dev Post #14

Yikes, this one is late! I've had this in my draft bin for several days now so I thought I should get the bloody thing out.

This is from my new Punakaiki level. I thought that it'd be cool to have a section in the game where you have to navigate a biplane through a tight, spike lined passageway. So, I made it. A tad tricky, but you've got the option of skipping the tunnel entirely by taking the easy route (and forfeiting the bonus letters). Stephen did nice cool blue cave tileset. F

eedback forms have started to trickle in, thanks to everyone who wrote them. Remember, if you want your name to appear in the game as a playtester, please download the form on the header bar above, fill it in and send it to us.

I was planning to upload a second beta version but it's a tad too late now, we wouldn't be able to get much valuable feedback before the deadline passes. As shown by the counter above, it's now less then three days until the deadline. Scary.

I added a fairly major new feature this week - level selection. Basically, you can access any level you've previously reached instantly from the map screen. You can also decide to skip levels and replay earlier ones to see if you can find more lives. This should make the game a lot less frustrating for people who reach the final levels of the game but run out of time to finish it!

Today, for the first time ever, I tried compiling the code on a Mac. It actually worked pretty nicely, though there is one major snag - fullscreen mode makes the game crash so, unless I can fix that bug, I'll need to exclude the feature from the Mac builds entirely. I'll probably eventually release Mac PPC, Mac Intel and Linux builds but they certainly won't be available this year.

The competition deadline is midnight Saturday GMT, which means for us the deadline is 1PM Sunday. I'm hoping to get a competition build uploaded 1PM Saturday (our time) so we've got a full 24 hours to reupload the game if we suddenly realise there was a mistake in the build. This is the very last dev post before the competition build, stay tuned!