Umzug auf sammigames.de

Der aktuelle und vollständige Blog befindet sich auf sammigames.de.

Analoges Game Design #1 - Einfachheit und Entscheidungen

Seit einiger Zeit hatte ich ein plötzliches Verlangen ein analoges Spiel zu machen. Etwas ganz einfaches, simples. Vielleicht tauchte es auf, nachdem ich mir endlich "Wizard" gekauft habe. Wizard ist ein Kartenspiel, das sich gerade dadurch auszeichnet, dass es eine extrem simple Spielmechanik hat, mit wenigen Kartentypen auskommt und trotzdem ein spannendes und taktikreiches Gameplay schafft. Und ich dachte: Sowas will ich auch machen!

Simplicity

Das Problem an genial einfachen Dingen ist, dass sie genial sind. Als Webdesigner kenne ich das Problem sehr gut: Man möchte ein reduziertes, puristisches Design machen, man schaut sich einige tolle Beispiele an und es sieht, natürlich, so "einfach" aus. Ist es aber nicht. Ganz im Gegenteil! Je einfacher ein gutes Design aussieht, desto schwieriger ist es umzusetzen.

Das ist wie ein Naturgesetz: Etwas genial einfaches und einfach geniales zu erschaffen erfordert Arbeit, es entsteht niemals einfach so aus dem Stand. Selbst die Natur, die uns durch ihre Genialität verblüfft, hat Millionen von Jahren für ihre Werke gebraucht und eine unzählige Reihe von Fehlversuchen.

Die erste Idee, die einem kommt fühlt sich meistens einfach und gut an. Man merkt aber, dass sie in diesem Stadium wertlos ist, wenn man versucht sie jemandem zu erklären. Spätestens dann merkt man, dass sie Ecken und große Löcher hat, man kann einfache Fragen nicht beantworten, verzettelt und widerspricht sich oft; die Idee ist nicht ausgearbeitet. Wenn man beginnt kritische Fragen zu stellen und die Idee langsam verbessert, wird sie immer komplexer. Neue Aspekte kommen hinzu, Hilfskonstruktionen, Bedingungen und andere Elemente. Irgendwann hat man einen echt soliden Entwurf mit dem man zufrieden sein kann, der aber alles andere als einfach ist. Um Perfektion zu erreichen, muss man nun entrümpeln, reduzieren und vereinfachen, aber ohne das Gute wegzunehmen. Wie sagte Antoine de Saint-Exupéry so schön: "Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann."

Ich habe immer gehofft ich könnte diesem Konzept ein Schnippchen schlagen und einfach so reduziert anfangen, dass gar nicht erst etwas da ist, das ich wegnehmen müsste. Ich hoffte, ich könnte ganz ganz klein anfangen, mit etwas super simplen und daraus könnte ein passables einfaches Spiel werden. Doch ich habe mich getäuscht. So funktioniert das nicht. Ganz klein anzufangen ist ein guter erster Schritt, aber es ist nur der erste von ganz vielen. Ich bin mir sicher, dass man mit sehr viel Erfahrung, Gespür und Intuition irgendwann einmal so gut sein kann, dass man im Stande ist, so etwas zu vollbringen. Aber bis man soweit ist, hat man viel Arbeit und Fleiß investiert, um überhaupt so gut zu werden. Es gibt einfach keine Abkürzung.

Seit ich mich mit analogen Spielen beschäftige, entwickle ich eine ganz andere Sichtweise auf ein Spiel und ein tieferes Verständnis für Spielmechanismen und das was Gameplay bedeutet. Das Problem an Computerspielen ist, dass die Verlockung, sich zu sehr auf Grafik, eingefahrene Themen und der Frage, welche Plattform/Programmiersprache/Editor man verwenden soll, konzentriert, satt auf das Wesentliche: Das Gameplay und den Spieler. Das schöne an einem analogen Spiel ist, dass man nichts weiter braucht, als einen Stift, etwas Papier und ein gutes Gameplay, um nahezu ohne technische Barrieren ein Spiel zu entwickeln.

Ein Beispiel

Ich möchte meine bisherigen Ausführungen an einem einfachen Spiel demonstrieren. Ohne viel Brainstorming und ohne große Suche nach einer bahnbrechenden Idee oder gar einem Thema, beginnen wir mit einer simplen Spielmechanik: Spieler müssen jeweils eine Spielfigur von A nach B bringen.

Schritt 1 - Einfache Regeln

Im ersten Schritt nehmen wir einen ganz einfaches Mechanismus:

• eine Reihe von Feldern (z. B. 12), das erste ist das Startfeld, das letzte ist das Zielfeld
• zwei Spieler beginnen auf dem Startfeld und bewegen sich nacheinander, je ein Feld, auf das Zielfeld zu
• wer als erstes das Ziel erreicht, hat gewonnen

Das ist nun wirklich sehr einfach. Und vor allem super öde. Wir haben zwar eine klare Siegesbedingung, aber es fehlen noch einige wesentliche Elemente eines Spiels. Gehen wir aber langsam, Schritt für Schritt vor. Was ist im Moment das größte Problem?

Wenn wir es jetzt spielen würden, würde der Jenige, der den ersten Zug macht automatisch gewinnen. Das hat mehrere Gründe:

1. jeder Spieler legt die gleiche Strecke pro Runde zurück
2. alle Spieler gehen die selbe Strecke
3. die Spieler können keine Entscheidungen treffen

Nummer 3 ist im Grunde das eigentliche Problem. Aber das 1. und 2. Problem lassen keinen Raum für Entscheidungen, weil wir keine Variablen haben, sondern nur Konstanten. Wir müssen also erst mindestens eines der ersten Probleme lösen, bevor wir an das dritte können.

Schritt 2 - Echte Entscheidungen

Wie können wir das Spiel erweitern, um dieses Problem zu beheben? Wir haben zwei Punkte bei denen wir ansetzen können:

1. die Strecke, die ein Spieler zurücklegt variieren
2. den Streckenverlauf variieren

Wir könnten es uns ganz einfach machen und Feuer mit Feuer bekämpfen: Die Spieler sollen die Entscheidung über Weg und Anzahl der Felder haben, die sie pro Zug zurücklegen. Aber das ist leider keine Lösung. Warum nicht? Weil das keine echten Entscheidungen wären.

Was bedeutet keine "echte" Entscheidung? Wenn ich die Wahl habe, ob ich ein Feld Richtung Ziel gehe oder zwei, dann wähle ich stets zwei Felder, weil es auf der Hand liegt, dass ein Feld die schlechtere Wahl wäre. Oder ob man einen längeren oder kürzeren Weg nimmt. Eine echte Entscheidung zu treffen, bedeutet die Vor- und Nachteile jeder Möglichkeit abzuwägen. Das setzt voraus, dass jede Möglichkeit sowohl Vorteile als auch Nachteile hat. Aber zwischen einem Vorteil und einem Nachteil zu wählen ist keine Entscheidung. Es ist die Wahl zwischen dem einzig richtigen Zug und einem dummen Zug. Wenn der Spieler also gewinnen will, hat er im Grunde keine Wahl, als stets den offensichtlich besten Zug zu machen: Die meisten Felder, den kürzesten Weg.

Schauen wir uns mal das Spiel aller Spiele an: Schach. Jeder Zug ist eine echte Entscheidung, die Gewicht hat. Oft gibt es Situationen, in denen ein guter Zug quasi auf der Hand liegt, aber dieser Zug ist nicht zwangsläufig der einzig richtige, denn je nach Strategie und Fähigkeiten des Spielers kann ein anderer, scheinbar abwägiger Zug noch besser sein. In Schach einen Zug zu machen ist eine Entscheidung ohne Gleichen; ein kleiner Zug mit dem Bauern kann alles ändern: Gehe ich ein Feld nach Vorne, werden Linien frei, andere gehen zu, eine Deckung wird aufgelöst, zwei andere Felder werden angegriffen. Vielleicht verliert die eine Figur ihre Verteidigung, für eine andere wird der Weg geöffnet. Was davon ein Vorteil ist oder ein Nachteil und für wen und für wie lange liegt einzig und allein im Auge des Spielers und nur er trägt die Verantwortung für seinen Zug. Wenn sich der Zug als schlecht erweist, dann hat er etwas übersehen, etwas nicht bedacht, etwas falsch eingeschätzt. Pech oder doofe Spielregeln haben damit nicht das Geringste zu tun. Ein Zug, der so viele Möglichkeiten und gleichzeitig so viel Tragweite hat, erfordert eine echte Entscheidung.

Ein wirklich schlechtes Beispiel fällt mir spontan nicht ein. Es gibt viele Spiele, die mit weniger und nicht so wichtigen Entscheidungen auskommen, aber oft trifft man auf Spiele, die Entscheidungen nur vorgaukeln, die aber tatsächlich keine echten Entscheidungen sind.

Im nächsten Artikel versuchen wir eine echte Lösung für Problem 1 und 2 zu finden und analysieren das Dilemma zwischen Glück und Können in einem Spiel.

Lichtblicke mit Construct 2

© 2013 Stanislav Silbermann

Was möchte ein Spieleentwickler am allerliebsten machen? Doch wohl Spiele entwickeln. Darum habe ich nach langem Suchen endlich eine Plattform gefunden, mit der ich für eine Weile glücklich werden könnte: Construct 2 von Scirra. Kennt ihr das, wenn man etwas so oft hört, dass man denkt, es nun doch verstanden zu haben? Und doch hat man nichts verstanden, weil Verstehen nicht das selbe ist, wie Begreifen. Eine Sache habe ich seit dem ich Contruct 2 entdeckt habe begriffen: Es gibt nicht die richtige Entwicklerumgebung oder die richtige Programmiersprache; es gibt nur deine Entwicklerumgebung und deine Programmiersprache. Eine, mit der du etwas erschaffen kannst und dich wohl fühlst. So eine habe ich gefunden.

 

Was macht Contstruct 2 aus und warum gefällt es mir

2D ist verständlicher

Erstens ist es 2D. Das klingt banal, ist aber für mich sehr wichtig. Oft habe ich in Foren den Hinweis gelesen, man solle mit 2D-Spielen beginnen, da sie etwas einfacher sind, als 3D. Und das stimmt. Was mich vor 2D abschreckte war die Tatsache, dass man für 2D-Spiele Grafiken braucht und die optische Qualität des Spiels ist direktproportional zur Qualität der Grafiken. Wenn man sich nicht traut Grafiken zu erstellen oder fremde zu benutzen fühlt man sich einbischen wie eine Schildkröte auf dem Rücken. Deshalb neigte ich zumindest zur dritten Dimension, weil sie den Anschein hat, ohne viel Mühe gut auszusehen. Aber der Schein trügt!

Es ist tatsächlich viel einfacher eine Grafik zu erstellen und dann mit ihr in zwei Dimensionen zu arbeiten, als drei Dimensionen zu bewältigen.

Javascript

Für mich ist es das erste mal, dass ich nicht das Gefühl habe, ich müsste von Vorne anfangen. Denn Javascript kann ich. Und was kann Construct 2? Javascript! Es kann nicht nur Javascript, es ist spuckt sogar welchen aus. Das Spiele, das damit generiert wird, läuft auf einem HTML5 Canvas-Element und unterstützt sogar WebGL. Für mich löst das fast alle bisherigen Sorgen:

• Hat diese Technologie Zukunft?
• Kann ich das Spiel auf möglichst vielen Plattformen verbreiten?
• Lohnt es sich diese Technologie zu lernen? Ist sie universell?

Nun kann ich all' diese Fragen mit einem deutlichen "Ja" beantworten. Die letzte trift gerade bei mir den Nagel auf den Kopf: Als Frontend-Entwickler im Web, ist das mein Milieu! Ich könnte mir sogar vorstellen mit dem Tool interaktive Webanwendungen zu erstellen ...

Man merkt vielleicht, ich bin begeistert.

Projekte abschließen

Weil Contruct 2 so einfach zu bedienen ist und man sich ein Spiel regelrecht "zusammenklickt", kann man ziemlich schnell Prototypen basteln und kleinere Spiele recht schnell fertigbekommen. Das ist gerade am Anfang wichtig. Natürlich ist gerade das ein Kritikpunkt: Ein "zusammengeklicktes" Spiel ist weniger Wert, als eines, das selbst programmiert wurde. Achja? Das habe ich auch gedacht. Aber ganz ehrlich: Wenn dabei ein gutes Spiel entsteht, ist das dem Spieler sowas von egal, ob da jemand selbst programmiert oder nur "zusammengeklickt" hat.

Ich gabe zu, dass ich selber gerne Code schreibe und manchmal vermisse ich die BlitzBasic-Zeiten. Aber genau so viel Spaß wie Code zu schreiben, macht es mir Spaß Spiele zu machen und das Ergebnis zu sehen; und letztendlich kommt es nur darauf an.

Bambooception

© 2013 Stanislav Silbermann

Flash reizt mich

© 2013 Stanislav Silbermann

Viele Spiele, die mich wirklich beeindruckten, wurden in Flash erstellt. Doch bisher habe ich mich nie an Flash ran getraut – ich habe Angst vor Flash. Warum? Aus den gleichen Gründen, aus denen man vor den meisten Dingen Angst hat: Weil man sie nicht kennt.

Was ich über Flash zu wissen glaube:

• Flash kann Vektoren (das ist gut!)
• Flash kann Scripte und Animationen
• Flash läuft nicht auf iOS Geräten
• Flash ist groß und langsam
• Flash ist irgendwie ein Urgestein des Web 1.x
• Flash ist teuer

Ich muss dazu sagen, dass ich als Webdesigner und Webentwickler gelernt habe Flash um jeden Preis zu meiden. Das war sogar einer der Gründe, warum ich so intensiv Javascript gelernt habe: Was Flash kann, kann auch Javascript – nur besser. Was ich dabei natürlich nicht gelernt habe ist Flash.

Stattdessen entdeckte ich Unity 3D. Dieses mächtige Tool, dass auch noch kostenlos zu haben ist und von allen Plattformen und Geräten unterstützt wird, bis hin zu Konsolen, hat mich in seinen Bann gezogen. Aber 3D hat nun mal eine ganz andere Dimension – in mehrfacher Hinsicht; es macht Dinge einfacher, aber auch komplizierter. Einmal erstellt, kann man ein Objekt drehen und wenden wie man möchte. Andererseits ist das Texturieren und Animieren komplizierter.

Letztendlich muss ich einfach eingestehen: Es gibt keinen plausiblen Grund, Flash nicht auszuprobieren – sondern nur Zweifel.

Ich werde mich an Flash trauen, aber lohnt sich das? Wie viel Zukunft hat Flash? Wie erfolgreich kann man damit sein? Und wie besorgt man sich das Teil, ohne bankrott zu gehen?!