Michael S. Debus, PhD

Twisted Arcade was both a great success and a massive failure. As I came up with the idea (more about that below), I assumed the role as Lead Game Designer and Project Manager. Our group consistet of two game designers/artists, two gameplay programmers, and myself.

The Idea

During a unity workshop at Aalborg University two presenters worked on a game for the duration of the workshop. In the end, they presented a “horse race” game, where players had to control a rectangle on two ends to jump towards a goal line. Everyone had a good laugh watching the four competitors trying to achieve their goals, while some of them hopped off screen. Having learned about the concept of designing a feeling into a game, it was this amusement we wanted to capture.

The Success/Failure

In the end we succeeded – just not the way we wanted. We created a game including multiple minigames, with the core mechanic of players chosing their own controls for each game. During play, these would switch between players, including a “fuck up button” that would stall your character.

Long story short, the game was massively frustrating for players due to a lack of agency, control, and mastery. However, the audience loved the game. We realized we succeeded in reproducing the audience’s emotion while ignoring the players’.

What I learned

The biggest learning process, I already described above: Designing experiences is hard and often does not lead to the desired outcome (or it does in the wrong ways).

In terms of game development, Twisted Arcade was the first time I realized first hand that people from different knowledge domains speak different languages. Designs developed by Artists and Game Design ended up being implemented very accurately by the programmers, but we left rooms for interpretation in the designs, which were filled differently than expected.

Regarding project management, Twisted Arcade taught me that applying systems top-down doesn’t work, and individual solutions must always be found. For example, we aimed to use SCRUM as development style, with daily standups and end-of-day reports. However, due to the individual living situation and responsibilities outside the course of our team members, I had to shift the organization to a SCRUM-light approach, utilizing a Kanban board and asynchronous communication more.