The kernel-based game engine is designed to take care of these problems. It does add some overhead to the main loop, but it's still fast enough for most games out there, and the added flexibility really helps further down the line.

This model splits things into two sections: the Kernel object, and a collection of Service objects.

The Kernel takes care of running the loop, and dispatches messages to Service objects.

Each Service object takes care of a single piece of functionality. This can include updating game entities, managing game screens or handling input. Keeping the functionality of services limited helps to make things reusable as time goes on, and prevents things becoming too complex.

Our loop now looks something like this:

do {
    kernel.update();
    kernel.render();
} while (!kernel.isFinished());

Note: The "render" method is optional, but makes things much easier once different update & render priorities come into play. For example, a service may need to render last but be updated before other services update (see Render Method for a more detailed explanation).

Here are a few services from games under development:

The first two or three hours were spent coming up with an idea that would work with the theme. The contest started at 9pm local time, so I probably wasn't at my most creative, but I wanted to get a good start.

Normally a quick image search will bring up some good ideas, but 90% of the top image results for "tiny worlds" were terrariums which didn't help that much, although I toyed with the idea of using them.

The initial concept for the game had you start in the ship's stasis room, and you would have to walk to the various biomes. The biomes would have been small pods in a lab, and you would control a miniature robot to rescue the animals from invaders. I liked the idea, but realised I was adding an unnecessary amount of art which would work as a menu.

The final concept kept the robot controls and multiple areas, although a couple of things ended up being cut.

• Live updates – Not really development related, but I was really pleased with how the live update stream functioned. It was pretty simple to add new updates and images, and pushes to GitHub also showed up (although I didn't commit code nearly as much as I would have liked).
• Architecture – I went with a component-based object approach this time, which made adding new entities much simpler. Rather than sub-classing behaviour, components are added at run-time. This made it easy to keep a list of objects with certain behaviours, such as shootable entities or entities that move. The code is (obviously) a little scrappy, but I really enjoyed how it worked.
• Bestiary – Granted, I wanted to add more animals (and some with animation), but I felt the bestiary was the nicest way to add some incentive for scanning animals. Writing text is easier than adding a new feature, so I wanted to make parts of the game data-driven to take the burden off coding and making art.
• It works – Almost forgot that one. The core gameplay works pretty well, although there's no balance and it's quite rough around the edges. It's still cool to have a little robot moving around.

• Polish before features – Towards the end I started polishing up the menus and adding a nicer looking title screen. I think it helped make things more presentable, but at the time there was only one level and the code to switch levels didn't work.
• Cuts – I ended up cutting out dozens of features. There were plans for an upgrade center, as well as ammunition and different weapons. The destructible crates were supposed to drop items (and the code is there), but it was pretty clear by the end of Saturday that they wouldn't make it, so it had to go. There were also supposed to be multiple areas per zone, and some statistics (such as % scanned, moves used to complete etc).
• Balance – The player and enemies have the same weapon strength (seeing as there is no equip screen), and as there's no health it's pretty much down to chance if you survive a level. I'm pretty sure the tundra level is impossible to complete with all the enemies.

• Emergent gameplay is your friend – When you're on a tight deadline you need to make use of as many tricks as you can. Rather than use a lot of hard-coded behaviours, it's better to add a few elements that can interact. It doesn't really play a part in the game due to the level layouts, but animals in Ineptia are shootable. This means they can occasionally get in the way of combat, forcing the player to choose where they move to avoid casualties, although as there's no penalty for animal death it doesn't matter too much.
• Take your idea and halve it – After that, halve it again. You absolutely have to take the smallest thing possible and expand it once it's finished. I tried to do this, but failed miserably.
• Keep a log – Having a frequently updated time log helped keep me motivated. It also made writing a post mortem easier ;)
• Code quality is important (sometimes) – After adding a few movements (forwards, turn right) I took some time to remove duplicate code and package it in a few reusable classes. This made adding new movements easier, and without it I probably wouldn't have been able to add animal scanning in the time limit.

I know lines of code aren't a great metric for productivity or quality, but I thought it was interesting:

I tried to remove copy/pasted code, but near the end time was too tight so some menus share the same copied code.

I'm torn on the finished result. I like the idea, and although it's simple I think there's potential. Out of the three jams, I definitely learnt the most on this one. It ended up being a great test of some concepts I've wanted to implement, so even though it didn't live up to the vision I had, it wasn't wasted effort.