Projects

In this page I tell more about the management work that I have been involved in, and the results.
Jump to: StarChaos, Bubble Wonderland or Overlord2


StarChaos

click on images to open large version


Basic description: I managed the project the project to bring it to a release ready state. I also designed the updates.

The Game: StarChaos is a game in which the player builds and upgrades his base, creates an army, and competes with other players who do the same on the server. It is set in the future and takes place in space.

Involved people:

Challenges:

Situation:
When I started working on this project, the development of the game was done, though it contained a lot of bugs. The CEO wanted rigorous changes to be made in the interface and gameplay. I was to design these changes and manage the artist, the developers and the testers. The project wasn't easy at first, mainly due to above mentioned challenges. All throughout the project new features and changes were requested without any notice and the CEO was micromanaging the project. This could not be changed, but I managed to streamline this through the implementation of certain scrum techniques.

Results:
I created a SCRUM/kanban board. It allowed me to show the CEO the progress we made in a very simple way, and allowed him to modify and add features in the backlog. The present iteration (sprint) was never affected anymore this way, which let us deliver much better work.
Short daily meetings (standups) allowed us tell us what we were working on, how much time it took, and ask for help if needed. Each day we could check what each project needed and assign people to the right tasks. In that way, we made sure that each project would run on schedule and would not cannibalize each other.
Weekly meetings let people share their progress and the current status of their projects. Project issues were discussed and solved. Problems would no longer remain invisible and linger, or be lost in the noise of other projects. People could focus on their work now, they delivered more quality, and were happier working on their projects.
The game is planned to go live at the end of June.

Bubble Wonderland

click on images to open large version


Basic description: I designed the game and managed the development, which was done by external developers.

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.

Involved people:

Challenges: The project was a challenge from the start. The following issues occurred:

Situation:
The development started before the Game design document was finished. Because the features were unsufficiently documented, the development team couldn't start working. It also created uncertainty as to what had to be finished for each milestone, because the scope hadn't been defined either.
Just like in the StarChaos project, there was no clear overview of what had to be done and when, as there was no planning. The game also required people to make level designs, but no one had the time or training to do this.

Results:
The documentation solved by creating a short document to describe the basics of the game, without going into details and wireframes. The developers got a better understanding of the scope now, and could plan their work better. From there on I made regular updates to the design document, adding detailed features one by one that the developers could already start working on.
To keep track of the project progression I created a scrumboard for this project as well (just as I did for StarChaos). Again, the CEO could add or remove features at any time without affecting our work.
I talked to the Chinese project manager so we could get a more detailed understanding of when the features could be delivered, and what was part of the original contract. This prevented misunderstandings of contractual expectations. This also helped me to advice the CEO as for when certain milestone payments had to be made.
When levels had to be made, The CEO suggested to let the testers do this. I ensured that they had enough time per day to dedicate tothis task, and made sure that the CEO knew and accepted how this would impact their other activities. I taught the testers about the basics of level design. Luckily they were eager to learn and do this. We set up a plan for level themes and progression, and a planning for when all the levels had to be made. The resulting levels were fun to play and together it presented a smooth learning curve for the players of the game.

Sadly, I could not prevent the project from running longer than planned, as the planning was too unrealistic. Together with the developer lead I made a new planning and decided which features were critical. I was able to pinpoint a new date based on that. The CEO agreed with this new planning.
Currently, the game is almost done.

Overlord 2

  • Worked on:09/2007 - 08/2009
  • Primary Roles:Integration Manager, Game Logic Scripter
  • Secondary Roles:Level Designer, Tester
  • Company: Triumph Studios

click on images to open large version


Basic description: Controlling and managing all the ingame text, including creation, implemention and translation.

The Game: Overlord2 was a major game, coming out for playstation 3, Xbox360 and PC. 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.

Involved people:

Situation:
Towards the end of the development of Overlord 1, it was convenient for everyone that I handled and edited all the text sheets, since I was so involved in the text implemention already. For the development of Overlord 2 this role was expanded. The outlines of the story had been created, and it was the task of the writer to create the details and the text to be used in the game.
When it came to bringing the story to life, many questions had be be answered:

The level designers also needed help from the story team. They needed story bits to support and explain the gameplay. For example, let's say that the player is supposed to set a specific bit on fire, he needs to know what is expected of him and how to do it.
The interface text also had to be checked: each console manufacturer has its own rules on what kind of technical terms have to be used and how much space the text can occupy in the interface. This had to be checked for each language.
Later on in the development the audio team and the localization team not only needed the text to record and translate, but a lot of background and context, and information about the constraints they had to work with.
In the end there were a lot of last minute requests for changes and additions. This meant that even when the entire story was written, translated and recorded, new material still had to be made against tight deadlines.

Results:

To make sure that the story was presented well while still going hand in hand with the gameplay, I discussed the story with the level designers, the writer and the cutscene team. By keeping everyone involved we made sure that the work could be done, the story would be fun and that it did not clash with the gameplay. After having found the best way to present the story bits, the writer could write what was needed, and storyboards were made by the cutscene team. I was the middle person to facilitate this and keep an overview of what needed to be done. When the level designers needed help from the story team to support their gameplay, we ran through the same process. As a result, the story wasn't 'tacked on' late in the process, but the story development and game development went hand in hand.
Later in the project I created all the documentation needed for voice actors to tell what the characters were like and what their lines were. I had created a system in the line sheets to enter information about intonation and timing. I also included background stories, concept art, and voice directions; generic and per line. Everyone got all their information in time, and there was no confusion on voice types or on the intonations, and the voice actors had a proper context to work with. The same information was provided to the localization team, which prevented timing issues in cutscenes, and good quality voice acting in all the supported languages.
In the end I checked all the interface text, to make sure that it fit all the rules and regulations of the console manufacturers, and to make sure that all the translated text following the size specs.
The last minute changes were managed by keeping everyone informed about the deadlines through various channels (face to face, whiteboards, meetings). This meant that the level designers would plan text checkups in their schedule and got all their requests in on time. Exel sheet magic allowed the localization and recording team to see what still had to be recorded and translated. As a result, everything that was needed made it into the game with only a limited amount of deadline stress.