What is Karoshi?
“Karoshi!” was our entry for a game contest on the German programmer forum ZFX. The task was to develop a strategy or puzzle game with the following themes: chocolate, oil, storm or bureaucracy. The time remaining to develop the game was 1 1/2 months.
Although oil and storm would have made a good serious game about the Mexican Gulf, we rather decided to make a parody of bureaucracy. (We're Germans, after all.) Right from the start we wanted to create a multiplayer game, also to avoid implementation of AI. Plus most of our last game prototypes had multiplayer functionality.
The game takes place in an office which is rent by more than one company at the same time. The player's task is to defeat the opposing business by destroying the desk of the boss. You have to employ interns who can be trained to be geeks (earn money), mobbers (who bully your enemies) or vandals (to destroy furniture). To restore an employee's energy you have to feed him or her with chocolate through vending machines.
What went good?
Although we didn't had that much time, we started right of with the Unity 3D game engine. Jana did her diploma project with Unity and Friedrich challenged the overnight contest at the “Devmania 2010” with it. Through this choice we avoided a laborious search for another engine. Also Unity does a good job when you are more of a designer than a programmer.
With a straight time schedule and clear division of work we developed “Karoshi!” nearly full time for more than one month. But we don't want to brag about what was cool (you can play it yourself, haha) but rather what went wrong.
What went wrong? (Graphics)
It was cool that our idea around the game was developed very fast. The ideas were flowing, but instead of a little planning we started with scripting (Friedrich) and designing (Jana) the characters. Although we did a small game design idea paper, we should have planned more, especially about the character design, because their spontaneous development was - for reasons I'm going to describe here - a mistake.
Like in every strategy game, the character's look should also represent his/her skills. Fighters look strong and archers are agile and have wooden bows. But instead of remembering this lesson, Jana focused more on creating office stereotypes like the hip designer, the nerd with glasses or the dress man. At this time we planned to let them have individual looks. Special abilities should be earned through weapons like laptops, staplers or cactuses. Jana liked those characters so much that right after their planning she modelled three men and two women.
But then we decided that each of the different characters could have a different pace … and that the appearance COULD reflect this. Or maybe you could see from their looks if they are good workers or not. Jana really loves strategy games, but while making “Karoshi!” we forgot some essential things about them and their design principles. (Feedback, feedback, feedback!)
We wanted to create something brilliantly new, as usual - and ended up with character classes which thereby were created a little too late in the process. So, after the first iteration (individual characters plus weapons) we decided to go with these skill types: productivity, bullying qualities and vandalism efficiency. But the time ran out and Jana needed to finish the characters to built the furniture and - which was most of the work - the interface.
Four classes but five different looking characters were a problem. So we divided them in hindsight of the classes and Jana created - like in real life - a male AND a female character for each class. Content-wise, this is just too many characters, but she wanted to have the classes consistent instead of one female here and one male there.
The characters that were developed in this way caused problems. The worst thing was that our testers couldn't identify the classes immediately or even describe which man and woman formed one class, because they looked too different from each other. As an example, the geek guy has a belly, wears shorts and has a long plait - like a cliché nerd. But the geek girl is more trendy with her big hipster glasses, the two braids and her red jeans.
The mobbers both wear suits which was obvious - for us. And the solar tanned fraction are the vandals, which was the only attribute easy to manage, but also not obvious for everybody.
Another problem that walks by with the one described above is a clear description of our assets (models, folders, materials, textures). Because we didn't know the classes at the project start Jana had big problems to invent names for the files.
At the beginning the female geek was planned as an intern and is signified as "braid girl" in the working folder. The current intern was planned as geek and called "striver" in the folder, for when we didn't have character classes. Sometimes this really created confusions about who is who. And Friedrich often had to ask which character is the one he can implement.
This sounds trivial with eight characters and one month production time. But it would have been a mess if we did this kind of work two weeks longer.
What went wrong? (Scripting)
In terms of programming, a contest where the participants have two months for the completion of their entries is good and bad at the same time. Of course it's good because such a relatively long timespan makes it possible to actually finish it and create a complete game. But it is also bad because – as usual – one probably will misjudge the size of the project he or she can accomplish, and overestimating a two-month-game can really fray ones nerves.
Concentrating on clean code only functions as long as you know exactly what you're doing - which isn't necessary the case in a “rapid prototyping”-like production process with a hard deadline. So it's possible that you're about to build a huge mess for two months, which might not be very satisfying.
Thus, while Friedrich programmed some parts of “Karoshi!” pretty nicely, the game in itself and its vision was too big for just one or two months, especially when it came to polishing. The contest version had some bad bugs which made the game nearly unplayable. As everybody wants to learn new things when beginning a new project, doing so in a contest isn't the best idea, as you will make mistakes and have to redo things. This was the case with “Karoshi!”, as we never did a full strategy game before.
Friedrich used Aron Granberg's Pathfinding-Addon for Unity3D so he didn't have to implement it himself. It even supports many different types of levels (terrain, mesh, gridbased), and it seemed like a piece of cake to use it. But while the pathfinding itself worked perfect, it was a hassle to script with the whole package as it wasn't written with the needs of “Karoshi!” in mind (of course). Besides the familiarization with the addon, time was spent on adjustments and changes. All in all we think it would have made more sense if Friedrich just would have used some generic A*-script and did most of the other stuff (building the grid, collision, etc.) himself.
Even though some of our former projects were prototypes for multiplayer games, the networking parts always were crafted suboptimal. And as the deadline drew nearer day for day, “Karoshi!” shared the same fate – all scripts for the multiplayer functionality suffered from being some kind of addon of the logic. It would have been better if they rather were a design guide. To reduce the work the server has to do, every client got the control of its own game logic (movement of minions, making damage, etc.), which is very prone to hacks/cheats and should never be done at home, kids! Some of the biggest bugs came from the networking code, too; for example, some RPC methods produced constant errors because of the delayed deletion of characters on some clients – and errors always were written into a log file, which made the game very slow. Fortunately, with version 1.1 we got rid of the most evil slowdowns in this regard.
A big portion of development time was spent on the GUI. After all, it's a strategy game and we never saw a strategy game without an extensive GUI; nonetheless we underestimated the time which was needed for implementing and design the 2D interface.Although Unity's GUI system isn't the best – some members of the community forum advise to not use it at all - Friedrich managed to make it adaptive to the current screen resolution; it automatically rescales (if necessary!) to always look good, even at the strangest ratios. But because every button's and label's position and size had to be hardcoded, testing was a nightmare. Especially choosing the right font for the different resolutions seems to be a science in itself. The complete process of planning and constructing the whole GUI of “Karoshi!” was the most stressful part of the development.
So, for the next project we are going to think about what kind of game we're going to do and what it will need for a genre like that. When you have the time and work within a bigger team (more than one) you should take the time and plan a little bit around, even for a contest. This sounds trivial, but it always is a lesson learned on the hard way.
And never forget the time to make a tutorial for your players, even when YOU know that your game is playable. But if there is to much information needed to play or actually start the game, you definitely need a tutorial. Because of the short time of the contest, ours is just three sheets you have to read - unfortunately this is something nobody really does voluntary.
In the end, “Karoshi!” is absolutely playable and fun, but only if you have another player AND you both take the time to read three pages of tutorial stuff.Thanks for reading this Post Mortem!