In this page I tell more about the projects in which I have been involved in as a designer.
Jump to: Overlord2, Overlord1, Bubble Wonderland or Urbville


  • Worked on:2008 - 2009
  • Company: Triumph Studios
  • Responsibilities:Level Design, Game logic scripting,
  •                                       Implementing story.

click on images to open large version

Basic description: My main role was implementing all spoken text into the game throughout all the levels. I also designed two levels, seleveral multiplayer levels and helped out with game logic scripting - making sure that everything loads in the correct state.

The Game: Overlord2 was the sequel to Overlord1. It was a major game, coming out for playstation 3, Xbox360 and PC at the same time. It was an action RPG in which an evil overlord had to conquer the world with a group of loyal gremlin-like minions. The game received good ratings just like Overlord1, again due to its wicked humor.

Level Design:
I designed the level of Nordhaven. To get an impression, watch the folowing videos: Walkthrough 1, Walkthrough 2, and Walkthrough 3.

The level was in the earlier parts of the game, where gameplay is still relatively straightforward. However, the player just obtained ranged attack minions and had to train with spawning enemies, of which the spawn spot had to be destroyed before the enemies would stop. I made a combination of nice straightforward bashing battles with oppertunities to use the ranged attackers by setting up platforms. I also added surprise attacks where enemies would come running out of the forest, or use bombs if the player charged in too fast.

Implementing story:
In the project page on my website you can read how I managed the creation of the story for the game. The implementation of all the lines that characters could say was a task that required specific knowledge. I had already grown into that task during the previous project, and this time I did all of it. I had to make sure that all the lines were randomized well enough, that story bits were paced out well and no important bits could be broken off or skipped by accident. Overlord2 was a game with lots of spoken text, so it was a challenge to make sure that all the text was implemented and paced out well.


  • Worked on:2006 - 2008
  • Company: Triumph Studios
  • Responsibilities:Level Designer, Cutscene creator,
  •                                     Game logic scripting.

click on images to open large version

Basic description: I started working on the project half way, as a level designer. Later on I also focussed on cutscenes and implementing game logic.

The Game: Overlord2 was a major game, coming out for Xbox360 and PC, and later also the PS3. It was an action RPG in which an evil overlord had to conquer the world with a group of loyal gremlin-like minions. The game received good ratings, especially for its wicked humor.

Level Design:
I created the elven temple level - see the walkthrough part 1 and part 2. I also created the setup for the halfling homes (walkthrough part 1 and part 2). I learned a lot about how to set up fun battles. For example, instead of throwing a big bunch of enemies at the player at once, use the environment to create a challenge. Put ranged attackers in hard to reach places, which require minion sweeping skills. Just as the player thinks he succeeds, more enemies enemies surprise him from another angle. It sounds simplistic on paper, but to get the timing and difficulty right was a real challenge.
I also created multiple multiplayer levels. The focus was on aquiring as much as life force as possible, aquiring spells, and leaving minions behind as boobytraps. Th multiplayer levels were fun, and even after testing it many times, it stayed fun to play.

Creating cutscenes:
During the creation of the single player levels, I discovered that I had a knack for making cutscenes. I was paired with and artist to create all the cutscenes in the game. I handled the technical side (scripting) and he would create the animations and camera points. For this job I also learnt the basics of camera view points and movements.

Game Logic scripting:
I had a knack for scripting, and since I was butting into everyone's levels to create cutscenes, I also scripted certain gamelogic events - mainly to make sure that levels would load in the right state. In the tower, which served as the home and main hub in the game, this was a lot of work, as all the player actions were reflected here, leading to scripts consisting of hundreds of lines.

Bubble Wonderland

click on images to open large version

Basic description: I designed the game and managed the development. I also taught others the basics of level design, and guided them as they created new levels.

The Game: The game was a bubble shooter game, inspired on bubble island. The player can play through dozens of levels, which keep getting more difficult as he progresses. The player can compare his scores with those of his friends and other players.

Game Design:
The task was to create a game like bubble island. The reason to develop a bubble game was that bubble games were popular on the website, which is also owned by the CEO. He hoped that a bubble game like this would be popular with the audience of the site.
The Development started one week after I had started working on this. Because of this, I had to adjust how I worked on this. Instead of creating a detailed document about every feature in the game, I started with a very generic document, describing the general play experience and outlines of the game. The document was done in less then a week, and allowed the developers to start working on the basics. In the meantime I started working on the details, and released a new iteration of the document every few days. I discussed with the lead developer which information was needed first, and gave a higher priority to these details. The final document contained all the details about the interface structure, flow, functionalities and gameplay. It also contained a description for the artstyle, theme and a moodboard.
Because the scope had not been clear at the start from the project, some features had to be moved for after launch, or adjusted. As I also managed the project I took care of that as well (read more about that on the project page).

Level Design:
As a lead level designers I taught and instructed the people who had to make the levels, as they were new to this. I started by letting them play certain levels in other games, and discussed with them what was fun and what was not so fun, and why. From there I gave them short lessons in the basics of level design, how to challenge players and what makes them feel good. Together we designed a level flow and themes, on which the individual levels would be based. I reviewed the levels and gave feedback. As a result, the levels made by these people presented a good learning curve and were fun to play.


click on images to open large version

Basic description: I designed the game and managed the development for a short while.

The Game: The game is a city building game, in which the player can create an increasingly bigger city with houses to live in, businesses to generate coins and plants to generate goods. The game was based on Cityville, as this was requested by the CEO.

Game Design:
The basis of the game is Cityville. The reason to develop this game was that the game would fit with the demographic of, which is also owned by the CEO.
The goal was to make a Big Design Document™ in which every detail of the game was described and documented. The Gameplay and flow had been set by other people, it was my job to come up with the details and the descriptions of the moment to moment interaction. This included wireframes, flowcharts, formulas, Gameplay flow, NPC's and quests. This document would be passed on to the external developers who would create the game (code & art) based on this. I made a list of headers for each and every feature that the game should have and continued to fill in the details.

I did learn a few things though. First of all, Bag Bad Design Docs™ aren't always that helpful. It's better to document feature by feature. It helps to find everything back, and the documents become smaller and easier to manage. On top of that, no one wants to review a 90 page design document in detail, so all mistakes get overlooked - until the developers stumble upon it. Third: making changes to features, adding features or removing them is easier this way. Four; it's easier to develop the game in scrum style when features are documented apart instead of being all over the place.
I managed to use this knowledge when desiging updates for another game. The design process became much more versitile, and the designs were easier to adapt and change.