Gamedesigner bei C-thirty6

Spiele erfinden, designen, testen, verändern, spielen… Klingt schon nach einem Traumjob. Ist es natürlich auch. Doch jetzt kommt es, das rhetorische „Aber“: Das dieser Job nicht nur aus „spielen“ besteht und der Weg zum Gamedesigner etwas länger dauern kann, beschreibt unser Kollege Benjamin Cory bei Gamasutra. Er nimmt Euch mit auf eine Reise durch die Spiele-Industrie seit 2007 in seinen bereits zwei veröffentlichen Beiträgen. Viel Spaß beim lesen.

Update 1. Juli 2014: Der dritte und vorerst letzte Teil von Benjamins Reise ist auf Gamasutra nun nachzulesen.

 

Der Kickertisch im Büro, eine fast gewöhnliche Geschichte

Als die ersten Kickertische die Büros eroberten, konnten die Geschäftführer noch behaupten, sie seien Business Punks und vor allem um das spaßige Wohl ihrer Mitarbeiter bemüht. Heute gilt ein Kickertisch in vielen Büros schon zur Standardausstattung. So auch bei uns. Umso stolzer sind wir, dass der Tisch den Ehrgeiz einiger viele geweckt hat und sich mehr als nur ein paar Feierabend Kurbler abends um den Tisch versammeln. Und so geschah es, dass wir vor ca. 1,5 Jahren den Ministrantischen Kicker Bund gründeten und pro Quartal eine Kickermeisterschaft austragen.

Logo Ministrantischer Kickerbund

Für das Zusammenstellen von ausgeglichenen Teams für unser Kicker-Turnier brauchten wir eine Übersicht der Spielerstärken. Anfangs hatten wir das über eine Excel-Liste gemacht, indem ein paar Leute eingeschätzt haben, wir stark die jeweiligen Spieler sind. Aber in einer Coder-Butze kann man das ja auch automatisiert über die Begegnungen berechnen, die jeden Tag gespielt werden.

Von anderen Spielen kannten wir bereits die ELO-Zahl, die zur Berechnung von Spielstärken verwendet wird. Weltweit wird dieses System (erfunden in den 60ern für die Schach-Weltrangliste) in allen möglichen Sportarten und Spielen verwendet.

Das System basiert darauf, dass man mit einem bestimmten fiktiven Wert (z.B. 1000) startet und nach der Spielstärke des Gegners bei einem Match Punkte gewinnt oder verliert. Ist der Gegner stärker als man selbst (er hat also einen höheren ELO-Wert), gewinnt man bei einem Sieg viele Punkte und verliert bei einer Niederlage wenige. Je stärker der Gegner, desto niedriger die Wahrscheinlichkeit eines Sieges und desto mehr Punkte würde man gewinnen. Da das System für Einzelspieler entworfen wurde, haben wir es leicht angepasst für Teams.

Dadurch, dass alle Spiele gespeichert werden (und nicht nach der Berechnung des neuen ELO-Wertes der Spieler verworfen werden), können vielzählige Statistiken erstellt werden, wie z.B. der Verlauf des ELO-Wertes über die gesamte Karriere, Lieblings- und Hass-Mitspieler, Lieblings- und Hass-Gegner und theoretisch noch viel mehr.

Desweiteren gibt es eine Noob-Liste, in der alle Spieler mit weniger als 20 Spielen geführt werden. In diesen 20 Spielen soll sich der ELO-Wert des Spielers an seinen realen ELO-Wert annähern. Ist ein „Noob“ mit am Tisch, verlieren und gewinnen alle anderen Nicht-Noobs keine Punkte. Dieses soll verhindern, dass z.B. ein neuer Spieler die ELO-Werte der bestehenden Spieler zu stark beeinflusst.

Statistik im Detail

Ihr seht, wir nehmen selbst den Spaß sehr ernst. Solltet ihr mal nach 18 Uhr in unseren Räumlichkeiten sein, seid euch sicher, dass ihr in der “Noob”-Liste landet. Und wir hoffen natürlich, dass ihr auch den Ehrgeiz entwickelt, möglichst schnell unter den Profis zu landen.

 

The Digital Agency

Liebe LeserInnen,

Der nachfolgende Beitrag wurde in gekürzter (deutscher Fassung) in der LEAD digital Nr. 22 am 30. Oktober 2013 veröffentlicht. Viel Spaß beim lesen.

A digital agency is a tech company.

This article is an examination of one aspect of what a digital agency is or should be. It is about an aspect than has some misconceptions. One of these misconceptions, perceives that digital agencies are there for making pretty images (digitally). Another comes from “serious” software companies. They often have the attitude, that digital agencies are not making “real” software. To clear these up, I will ask you to change your assumptions and accept two claims.

Firstly, a digital agency is not an advertising agency on bytes.

Although digital agencies are involved with advertising and marketing, they are making things that have programmable code.

And secondly: anything that has programmable code is software.

A digital agency understands the medium it works with and continues to adapt and grow with changing technology. The medium is not just a surface for static content or moving images. It interacts — and soon there will be little left that does not interact.

If we are creating software as soon as we start writing code, then digital agencies are involved in software processes — no matter what they are making. Therefore they not only need to understand the technology but also they (and their clients) must learn software development processes.

Paradigm change

Software is not put together on a conveyor belt. It is a creative process involving many different skills — from start to launch and beyond. Successful, creative, innovative projects require a paradigm change.

“Agile” is a buzzword that even classical agencies are starting to use. But “agile” is not just about being flexible. It is about re-thinking processes and about involvement.

Embracing change was a new thing for software developers back when people were used to writing everything down ahead of time — getting it absolutely right — before a single line of code was written. Unfortunately it is almost impossible to get it “absolutely right” at the beginning, and so agile processes emerged.

But (classical) agencies have always been used to change. Painfully so. The attitude has been, to always say “yes” to the clients wishes, no matter how late or difficult the change is. The problem here is usually misleading or missing communication, which in turn is the fault of “factory thinking” and not because a client is “fickle”.

“Factory thinking” is what happens when a client’s “order” is put on a conveyor belt through an agency, progressing through different teams who know nothing of project until it has been placed on their desk. The client sees the project again at the end of the line. Most likely, it is not quite what the client was expecting, and last minute changes and corrections are the consequence.

However the solution is quite simple: Involve everyone in the entire process.

Involvement and Partnership with the client.

At MINISTRY we have been involving our clients in the entire project process for several years now. Although some clients are still hesitant, those who have embraced this kind of partnership, have enjoyed successful and creative processes that have lead to great products.

Involvement throughout the process does not mean more work. It is a shift away from concentrating on the beginning and end of a project. Cooperation is spread over the whole process. By doing so, the risks of not being on time and of dissatisfaction, even conflict, are practically eliminated. Most last minute changes are due to misunderstandings. The agency misunderstood what the client wanted. The client was not so sure what he wanted. The client misunderstood what the agency was planning.

Involvement is a cure for this. It allows us (the agency and the client) to adapt, adjust and prioritise. We can decide together what we can change immediately, what we can do later in order to stay on time, what cannot be changed and must be accepted. The consequences of every decision are carried together.

Scrum & Co.

Methodology is a great place to start, but internalising the principles is more important. At MINISTRY we began a few years ago with “Feature Based Programming”, a method shared with us by Stefan Richter of freiheit.com. Currently we are trying out “Scrum” for larger projects. But in their basic principles all agile processes are very similar. Here is an example of how we use them:

A project typically begins with workshops involving the client, a project manager from the agency and people who have the skills of a developer, a quality manager and a designer. The purpose of the workshops is for all to find out what the project is about, what the desired result is and what we can do to get it done. The result of this phase is not a book about the project, but rather a feature list, which describes what we plan to do — in a style and language that all participants understand. Features can be split it up into blocks and can be made into a roadmap. The important thing here is that we try to get it right from the beginning, but it is possible that some change will come with time. It is important that we define what we are going to do, not how we are going to do it. That will be decided in the next phases.

There is an important difference between this process and trying to get it “absolutely right” before programming. We define what we want to do to the best of our knowledge, but we leave room for course correction along the way, and we never say “how” we are going to something, because we often cannot know that until we get there.

The process that follows is a series of iterations and checking back with the client. Milestones can be presentations of a “clickable” prototype (wireframe), a style guide or layout. Later software releases allow the client glimpses of the real working product, where a designated set of features is already programmed. The product takes shape and is being created at the same time and the client is involved in the entire process.

This is quite different than showing pretty designs at the beginning and coming back shortly before launch to make sure that all that was done in the meantime is OK for the client.

Since designers and developers are involved in the whole process, we can assume that we are saving time by not coming up with ideas that might not work or might take too much time. Since the client is involved throughout the process we can assume that we are staying on track with what the client wants and can adjust throughout to make sure.

Cooperations

Some agencies have entered partnerships with tech companies. That’s fine as long as the technology partner is involved in the entire project process.

The advantage of being a true digital agency (and therefore a tech company) is that you do not have to double up. Each skill is already based on an understanding of making software, whether the consultant, the project manager or the designer — and needless to say, we have developers and testers on each project the whole time.

And if you buy my assumption about what software is, then any agency without skills in the process of making software and knowledge about technologies involved should not use the word “digital”. A digital agency that does not do software is like an automotive designer, who does not know how to build cars. You might get a lot of fantastic looking vehicles out there that don’t work, or many very similar looking functional cars.

So what is a digital agency?

Digital agencies are tech companies that are experts in making software that is enjoyable to use, nice to look at and that attracts customers. They understand software processes and can create fantastic functional interactive products. Incidentally this also has something to do with advertising and marketing in a digital world.