Student Postmortem: Technical University of Dresden's BOUND

By Sina Jafarzadeh [09.30.08]

 The making of BOUND, a cooperative, arcade, touchscreen game, was a semester-long project by Sina Jafarzadeh and Benjamin Gnauk at the Technical University of Dresden in Germany. The task was to develop software for a specific two touchscreen system, which was built by other students in a previous semester.

An important part of the task was to analyze the given system and identify its strengths -- and equally important, its weaknesses. Additionally, the use cases and potential users had to be considered. Given those requirements, it is not unreasonable to draw comparisons between this project and game development for consoles.

The system itself can be described as a desk with two touchscreens facing each other. Both screens are single-touch, which is of course a restriction, and both are connected to the same PC. The screen is cloned for both touchscreens so that both users see the same screen all the time.

Since the system is relatively new and no specific use case or use place is defined by the chair, the most sensible ones have been considered. One idea we had was to place the system in the faculty's cafeteria. The system is actually most often used in special one-day, tradeshow-like events for the faculty.

What both use cases have in common is that the potential users do not have much time to interact with the system, and most of the time there are more potential users than two, waiting to be able to interact with the system. Because the users have likely never seen or touched this particular system before, it is quite important to develop software that promotes brief and not too complicated interactions, which can also attract other potential users.

If the software is a game, it is important to design a game with a simple but fun gameplay with a short play time. Furthermore, the gameplay and the visuals need to be interesting not only for the players, but for the spectators as well, whetting their appetites to play, too. The most obvious genre of game that fits all this criteria is arcade games.

One other important design idea was to create a cooperative game and enhance the communication between both players using their physical proximity. The advantage of a cooperative game is that even a weak player can play with a good player and have fun, instead of feeling frustrated. Nevertheless a weak player can frustrate the good player in a cooperative game, if the stronger player cannot help the weak one out of tricky situations.



All these points were considered for BOUND. Two figures are flying through a tunnel-like level. Both figures are bound together by a line, but they have a margin where a movement of one player does not have influence on the other player. If one player is too near to the other player, he pushes the other away, and if one player is too far from the other, he pulls him in his direction.


 There are two sections in the game that alternate all the time, making the game speed steadily accelerate.

In an "obstacles" section of the game, both players have to fly through the level without hitting any obstacle with their figures or the line between them. Both players have to communicate with each other; if one player goes to dodge an obstacle quickly without telling the other player in which direction she is moving, the other player could collide with the obstacle, with a Laurel and Hardy-esque bang.

In another level of the game that we call the virus section, enemies arise and shoot at the players, and to defeat them, both players have to hit the enemies in the same order. The first player who hits an enemy becomes the initiator and thus has to set the order in which the rest of the enemies are hit. The initiator then has to communicate to the other player the order in which she must now strike the enemies. Each enemy has a different color, which is chosen from a specific pool of colors.

What Went Right?
1. Cooperative aspect. Due to the type of system for which we were developing this game, supporting multiple players was nearly mandatory. But with multiplayer comes at least two contrasting modes: versus and cooperative. Each has advantages and disadvantages, so the use case had to determine the ideal mode for the game.

In trying to guarantee an interesting match in a versus-mode, there is the problem that either the game is not built heavily on skill or both players have to be equally skilled. The second point is very problematic in the given use case, because many differently skilled players play this game. The first point can be achieved, but there is the problem that the communication between the players would be either missing or based on competition.

Another important point was the cloning of the screen and therefore the restriction of not being able to produce one specific screen per player.

So the cooperative-mode was chosen with both players being able to influence each other by pushing or pulling the other player's character, which can have either advantageous or foolish effects. For example, one strategy of play in the "virus" stage is for one player to push the other away from projectiles, while the second player focuses on hitting the enemies.

The game gets progressively faster, and to survive in the later levels, both players have to work as a team and communicate clearly.

2. Communicative aspect. The cooperative aspect of the game is intensely coupled with communication, particularly verbal communication. One very important part of verbal communication is being able to describe something not only in a comprehensible way, but also simply. BOUND supports that in its restriction to move only in two dimensions. Players can express their movements and strategies quickly and simply due to the limited range of possibilities.

Besides that, the players have to be able to talk about the different enemies. As mentioned, we used colors to denote different enemies. Colors have two attributes, which are very important for this game. First, the colors we chose are clearly distinct, and second, each shade we chose can be expressed in one word. Despite the skill level and experiences of different players, they are all on fairly level playing field when it comes to vocalizing their colors.

Considering people with red-green color blindness (which is the most common kind of color blindness), red and green were made exclusive.



 3. Graphics and sound. Even with great gameplay, the game has to draw people in to play it for the first time, and we rely on the visuals primarily to do this.

All the figures, backgrounds, and obstacles in the game are hand-drawn sprites. The 3D effect is achieved through scaling (see the work of SEGA's legendary Space Harrier) and then superimposing a radial gradient black-to-white overlay. We've also incorporated a special tile pattern to enhance the appearance of depth.

These graphical decisions have two important advantages. First, it gives the game a special and unique look, and second, it allowed us to develop the game more quickly than if we had spent our time creating and texturing impressive 3D models. We could have made more abstract models like, for example, in United Game Artists' Rez, but then it would have been a challenge to do an abstract and interesting model rather than an abstract and dull one. Also by using black and white drawings, the colors we used to signify important objects and act as a communication tool are accentuated.

The tunnel effect we created in BOUND contributes to the sense of speed, allowing the player to concentrate on one point and immerse himself in the game. Together with speed-dependent retro arcade music and sound effects, this special look and feel can be greatly enhanced.

4. Teamwork in development phase. Since there were only two of us on our development team -- and working in a tight timeframe -- good teamwork was essential to produce a game of decent quality. Luckily, we complement each other very well, which is one of the most important parts of being on a team. Having respect and trust in each other's work helped us to mitigate potential conflicts. We were both open to constructive criticism, too, which helped to produce a good game.

Conflict in a two-man team would have been deadly. It's a risk all small teams take on, whether they realize it or not. But a small team also has many advantages, like less communication overhead and fast decision making.

We set strict and distinct roles, which helped us to be more productive than if we had just decided what to do on the fly. I created the design while Benjamin taught himself some game programming, which he had never done before. It was an incremental process, and we worked in parallel starting to create the tunnel effect, then the obstacles, and so on. Our process was very similar to a Scrum approach.


5. Knowing our strengths and weaknesses. Teamwork can only work if each team member knows himself. Goals can only be determined if the strengths and weaknesses are clear and considered. I have experienced throughout my university career on software projects in which students overestimated their abilities, set goals that were too high, and finally failed.

I actually advise students to talk about their strengths and weaknesses honestly in the very first meeting, especially if the team members are strangers. In our case, we did not know each other before the project. Benjamin likes programming, but has never worked on a game or with 3D graphics before. He additionally does chiptune as a hobby. I myself have a strength in abstract design, and although my drawings are probably miles away from professional ones, I can handle the pencil.

These are the kinds of things that influenced the game design and at the end, the game. We could have done a 3D touchscreen tactical shooter, but the risks of failing or developing something with bad quality were high and therefore not acceptable. I myself had many different ideas, but this one seemed to fit the criteria regarding effort and risks.

 What Went Wrong
1. The beginning. The beginning of the project was very problematic. The system was prepared for a tradeshow-like, one-day event, so our access to the hardware was restricted at a time when it is important to have full access to the system.

Additionally, I had a different team partner originally who dropped out because he thought the system was not decent enough. His complaints were about 1) the lack of multi-touch abilities and 2), in his opinion, bad pointing and dragging qualities of the touchscreen.

The second point was the result of the student-made software on the system: A Pong clone and chess. One of the problems of both games was that the hit-area was simply too small, thus creating the illusion that the touchscreen is not working very well. Every user has a different way of pressing a touchscreen, and the pressure point of the finger is mostly under the pointing point, so that a bigger hit-area is essential.

These points were of course bad for the timeframe. On the positive side, this probably simulated to an extent the situations that developers go through on launch titles. Another positive outcome was that the teammate whom I ended up with worked very well with me.


2. No prototyping of different ideas. Partly because of the above mentioned points, different game ideas could not be tested beforehand with a prototype, so the best sounding game idea was taken and developed. The result turned out well, but nonetheless, it is something that could have went wrong and should be avoided. Prototyping decreases the risk of going the wrong path.

We will never know for sure if one of the other game ideas would have been better suited for the system. Additionally, we could have tried integrating some aspects of a game idea into another one by prototyping.

3. Time problems. Time was an issue because we had, alongside lectures and seminars, other projects to do. Dedicating our full concentration to the game project was difficult. In three months, we had up to three occasions when we could not work on the project for a whole week. Starting and stopping not only shortened the timeframe but also destroyed the flow.

Sometimes we lost time working on very specific details that should have be done in less time. Another problem was the initial coding, which was in some parts unstructured and problematic in case of software extensibility and needed to be structured first. Extensibility is a very important to be able to try out many ideas very easily and this was not pursued at the beginning. As a result there was less time for refinements at the end of development, so it can be said that some quality points were lost because of that.

4. No boss fights. The initial design for BOUND included boss fights, but we could not implement them in this version of the game because we ran out of development time. Although the constant increase in gameplay speed gives both players a good challenge, a third element alongside the obstacle stage and the virus stage is noticeably missing.

Having boss fights would have enhanced the cooperation and the communication aspects of the game, as one part of our idea was to have the players make gestures cooperatively and complete a series of shapes together.

5. System was too specific. Developing a game for a very specific system is not a bad point per se, but in the case of being able to present the game to others, this is a really big restriction. Maybe it would have been better to invest in developing a PC game instead, which would be not only more accessible to many people thanks to the internet, but also easier to integrate in our personal portfolios. On the other hand it was a valuable lesson to work with such a system.

Big Takeaway: Prototyping
BOUND was the first game project for both of us and in my opinion the development went very well, despite the problems that occurred. The mechanism of two players being bound together has interesting applications, and I already can think of other games that could benefit from such a mechanism.

One point that I will always consider from now on is the prototyping phase, especially for upcoming probably bigger projects. Of course prototyping is always a time issue - and having a strict three-month timeframe can be problematic, especially if you cannot have your full concentration on the project. Therefore, I personally hope I can do a game-related work for my diploma thesis.

Sina Jafarzadeh is a media and computer science student at the Technical University of Dresden in Germany and he is in the 6thsemester with three semesters to go. Please visit the forum for links to a video presentation and for feedbacks about the game and this article.


Game Data

Return to the web version of this article
Copyright © UBM TechWeb