November 10, 2014

An Indie game development post mortem

As Biodrone Battle is now sprinting towards its finishing day, it is time to look back with this pre-post-mortem.

The history:

In the 80s of the past century (whoa, that always sounds a bit bombastic) I used to play the famous Paradroid from time to time and when I replaced my C64 with an Amiga 500, I decided to do someting similiar. Rooms, walls and more or less living things rushing by. In those days, to achieve acceptable gaming performance, you had to face the ugly head of Assembler and directly program the graphic chip. The summary is: things were moving, but too slow. I probably experienced a lot of guru meditations as well :)
If there was only Assembler, I had another profession. Think of it, today's hardware is so fast that games like Biodrone Battle are developed for virtual machines and can benefit from scripting languages.
Anyway, in the mid 90s I started working as developer for business software and as games evolved to huge mega-budget productions, it seemed that the time for independent developers was over, for good.
The times they are-a-changing, and so did Indie games rise from the dead in the last few years.

A summary of all jobs and tasks which came up has already been published:
The Multiple Personalities of the Solitary Indie Game Developer
Now, let's start with the first closer look at one of the topics.

Game art:

Maybe the biggest problem was to not have a dedicated graphic designer as constant team member. I did not know any designer when I started. Thus, I had to use the internet to find someone, which turned out surprisingly difficult. I needed someone who was good, affordable, available and reliable. A challenging combination. Luckily I was finally successful. Several times in fact, as the game art was done by multiple people.

There are tons of free textures to be found in the internet, even 3D models are often available for little money. Can't you just use them ? Sometimes you can, very often not. Because art styles are too diverse and mixing assets wildly leads to a some kind of unprofessional patch work game appearance. For Biodrone Battle, textures were often too realistic and did not fit the existing hand drawn assets.

Game art is not finished after receiving your outsourced assets. Inevitably, there will be adjustments to be made, again and again, which can be very time consuming. Having someone taking care of all of it is an invaluable enrichment.
To be on the safe side, if you outsource art, in any case add the original sources (Photoshop files mostly) explicitly as part to the contract.

What about pixel art, isn't that much easier ? First of all, good pixel art is not easily done at all and takes much experience as well. Then, as I grew up gaming wise in the 80s, I rather look at it as something which has luckily been overcome. Finally, pixel art is currently to be seen everywhere and I got kinda bored of it (again). Each to their own.

In the beginning, one open design decision was whether to create a game with a top-down or a side view. As you all see, top-down won. In retrospect, I think a side view would have been better. Simply because it leaves more options for creating the game world.

Graphics programming

I started off by using Java2D, simply because it was easy and straightforward to use without the need to learn a lot.
It wasn't a bad decision performance wise. As long as you use Java2D for simply rendering textures, it is pretty fast (as opposed to repeated contrary statements). But to play in the gaming league of today, a game has to offer impressive graphics effects like lighting and particles. To deal with that, it was time to say goodbye to Java2D and look out for something more practicable to do the job. For the Java platform, it means OpenGL and most probably LWJGL. Furthermore, if you don't want to mess with low level details, Libgdx is the way to go. So, in the middle of development, I had to switch the frontend from Java2D to Libgdx. Luckily, because Biodrone Battle was planned and had already been developed as multiplayer game (more about that decision later...), this task wasn't such a drawback as one might think. There were relatively few places to change and reimplement.

By the way, why on earth did I start to develop a serious game with a language and platform  everybody knows is slow ?
Two simple answers:
1. I knew Java very well due to my daytime job as business software developer. No learning efforts means more time for nothing but game programming.
2. Java is more than fast enough for the job.

And you probably all know that the most insanely successful Indie game ever was written with Java :)

As Biodrone Battle's maps are made of square tiles, I needed a map editor to create them. Because programming my own editor would have taken valuable time, I looked for a ready-to-use piece of software and stumbled upon Tiled. Using Tiled started out as very convenient, but as graphic features like lights and particles were added it became more and more cumbersome to create maps. Level design was one largely underestimated task anyway.

The multiplayer plague

One driving idea and key feature was to not simply to create a Paradroid-inspired game, but if anything, it should become a multiplayer game.
Every game of today is multiplayer ready, isn't it ? So, Biodrone Battle got a full blown client-server architecture and worked nicely as network game. As local network game, to be precise. Because for the internet, you have to deal with lag, latency, client prediction, you name it.
To make things worse, Biodrone Battle uses the physics libary Box2d, which makes it very hard if not impossible to let a game work in a client/server setup. Furthermore, in a 2D game, every discrepancy between clients and server is hard to hide.
End of story, multiplayer support is history for this game. I still kinda regret it, thinking of very nice and fun game play enhancements, and the wasted development efforts. But it was right to do so. Would there have been enough people to play the game anyway ? And if there were, who would have run game servers to play on ?
It is regretful, but was the right decision.

More to come. Stay tuned.

November 2, 2014

The Multiple Personalities of the Solitary Indie Game Developer

Did you ever think of creating a computer game all on your own ? There is probably much more to be done than you can think of. 
Various topics are to be covered which makes it both interesting and challenging. As such a project evolves, sensations of being overwhelmed might come up as well..

Here is my list of tasks that occurred for Biodrone Battle:



  • some kind of basic architecture
  • game startup/setup and shutdown
  • loading and caching of assets and levels
  • switching screens
  • sending and receiving in-game events
  • DRM
  • thoroughly taking care of threading
  • asynchronous asset loading
  • player registration
  • saving and resuming games in a database
  • game lobby with game options
  • levels configurable by property files
  • adding helpful log statements


  • making decisions for all drone types with individual goals and states
  • path finding

Graphics *

  • creating assets *
  • manage all assets in three basic sizes (64x64, 96x96, 128x128)
  • laying out sprite maps
  • adjusting colors, brightness and contrast
  • rendering sprites with OpenGL
  • drawing (layered) tile maps
  • lighting
  • designing particles
  • controlling the frame rate, interpolating view for smooth movement
  • switchable screens (lobby, levels, transporter between levels)
  • HUD
  • UI controls
  • triggering particles, light and other effects on receiving relevant events
  • switching light on and off, rotating cone lights, player focusing spot lights
  • effects like light flickering, sreen shaking, drone materializing, game over noise
  • sprite animation (looped or once)


  • creating or licensing sound and music *
  • adding effects like reverb, distortion, compression
  • taking care of fades and loopable sounds
  • adjusting volumes
  • playing, stopping, fading and resuming sound
  • triggering sound effects on receiving relevant events

Physics *

  • creating physics objects for walls, enemies, player, bullets
  • collision handling
  • bullets
  • calculating line-of-sight/field-of-view


  • handling of keyboard, mouse and controller events
  • mappable key events


  • tutorial / showing in-game context dependent hint
  • showing HUD help layers
  • writing documentation

Game play 

  • first of all, defining the game play *
  • implementing the game's rules
  • acting on collision events
  • watching life power of all drones
  • using gadgets like invisibility, super speed, damage doubling, etc.
  • walking upon special tiles for powering-up
  • opening and closing doors 
  • watching out for finished levels, won and lost games


  • setting up build files for automatically bundling complete game packages
  • optionally asset encryption
  • handling version numbers
  • taking care of beta, demo and full versions
  • create proprietary game launchers for Windows, Mac and Linux

Level design

  • designing maps that are fun, unique, challenging, diversified, have the right size *
  • adding doors, objects, particles and lights
  • tweaking lights
  • adding enemies

Testing *

  • looking for bugs
  • overall balancing
  • tweaking difficulty, drone/bullet velocity and power
  • testing on Windows, Linux and OSX
  • testing for various hardware and drivers
  • writing unit tests


  • tweaking graphics, sound, menus, colors, particles, help and levels, playing, balancing, adding more graphic assets - again and again


  • for outsourced tasks, writing job offers, choosing the right people, pushing to work, reviewing and integrating finished work 
  • taking breaks (I have a vague feeling I have to mention it...)


  • Website
  • Twitter
  • Blog 
  • Youtubers
  • Forums
  • Press
* with the help of external libraries
* outsourced, at least partly

December 13, 2013

A Layered Game Architecture III - Scenes and Directors

Scenes and Directors

Apart from actor AI, states and physics as describe in the first backend post, there is much more to be controlled in a game like:
  • handling collision events
  • watching actor's life power
  • collecting visible actors for each player
  • using gadgets like invisibility, super speed, damage doubling, etc.
  • walking upon special tiles for powering-up
  • opening and closing doors
All this is controlled by various directors. A director is the controller counterpart in a MVC architecture. Its models are actors and scenes.

Scene directors control game scenes. A scene is the model of one part of a running game. Games can have one or multiple scenes.
Examples for scenes are:
  • a shop to buy new weapons 
  • the battlefield where the action takes place
  • a screen to switch levels 
  • a built in mini game
  • an underground dungeon as opposed to the day light world
Now, just like in the real world, directors like to delegate work. Here, there are various sub directors, each specialized for one kind of task. For all the listed tasks at the beginning of this post, there is one sub director.
There are two given abstract implementations of sub directors:
  1. Directors that operate on a (dynamic) list of actors of one defined type, like for example:

    BlackHoleDirector - for droids and bullets
    Loops through its actors and drags them into nearby black holes if applicable.

    ActorLifeDirector - for droids
    Removes droids with a power of zero.

    PhysicsDirector - for droids, bullets and level gadgets
    Listens for added and removed scene actors and notifies the physics module about it. Creates appropriate events for actor collisions.
  2. Directors for tasks that are not bound to given actor lists, like for example:

    Does not work on a list of actors, but on incoming collision events between droids and bullets detected by the physics director.

    Does not work on a list of actors either, but on incoming player requests to become invisible. Activates and publishes according looks and disables invisibiltiy after a given time span.

    Does not work on a list of actors but on the list of current players. Each player gets a personal list of currently visible actors.
If neither AbstractSubDirector or AbstractActorsSubDirector suits a given task, ISubDirector can be implemented and plugged in as well.

Some important characteristics of sub directors:
  • They allow to modularize game control into smaller maintainable tasks.
  • They are invoked one after another from the game loop.
  • They can be invoked for each game frame or after a defined time span, like every 100ms.
  • They realize a plugin concept for the whole game direction sub system.
  • They can be enabled and disabled at runtime.