cover-image

Image

Patrick Völcker arbeitete fünf Jahre als Mobile-Experte und Web-developer bei der renommierten Webagentur Jung von Matt/Neckar, bevor er 2011 als Rich Media Innovation Tech zu Google wechselte. Freiberuflich ist er als Programmierer für mobile Endgeräte und als Gastdozent der Internationalen Filmschule Köln und der Popakademie Baden-Württemberg im Bereich »Mobile Games« tätig. Seit 2008 bloggt er auf mobile-zeitgeist.de über den Schwerpunkt »Mobile Games«.

Spiele entwickeln für
iPhone und iPad

Programmierung, Grafik, Sound und Special Effects

Patrick Völcker

Image

Patrick Völcker
patrick@iosgames.de

Lektorat: René Schönfeldt · Gabriel Neumann
Copy-Editing: Annette Schwarz, Ditzingen
Herstellung: Birgit Bäuerlein
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:
Buch 978-3-89864-725-0
PDF 978-3-86491-176-7
ePub 978-3-86491-177-4

1. Auflage 2012
Copyright © 2012 dpunkt.verlag GmbH
Ringstraße 19 B
69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Ich spiele Computerspiele nicht gerne. Wirklich nicht. In meiner Jugend war das noch ganz anders: Auf meinem C64 zockte ich ein Spiel nach dem anderen, und wenn ich mal wegen Mittagessen eine Pause einlegen musste, dann war das nicht schlimm, denn das Spiel forderte mich nicht über Tage und Wochen hinweg, sondern ein Level war innerhalb von Minuten gewonnen ... oder auch nicht. Aber auf jeden Fall konnte ein Spiel gestartet und beendet werden, wann immer man es wollte.

Damals war das bei Computerspielen üblich, heute werden Spiele mit dieser Eigenschaft unter dem Begriff »Casual Games« zusammengefasst. Diese Eingrenzung ist nötig geworden, denn 1993 hielt u.A. mit »Doom« die 3D-Grafik Einzug in die Spielewelt, und von da an wurden nicht nur die Rechner viel leistungsfähiger, auch die Spielewelten wurden komplexer. Mein persönlicher Eindruck war, dass bei der Entwicklung eines Spiels statt der Kreativität die Technik immer mehr in den Fokus rückte und dabei der Spielspaß ins Hintertreffen geriet. Um mich selber zu bespaßen, wollte ich allerdings nicht 200-seitige Anleitungsbücher durchlesen und vor jedem Spieldurchgang zehnminütige Dehnübungen mit meinen Fingern durchführen, um auch alle wichtigen Tasten (»Perspektivwechsel«, »Waffentausch«, »Munition nachladen«, »Übersichtskarte anzeigen«, »Zielen«, »Schießen« etc.) möglichst gleichzeitig bedienen zu können. Also ließ ich vom Spielen ab, denn die neue Generation schien mir mehr Sport als kurzweiliger Spaß zu sein.

Als Folge setzte ich mich hin und begann, meine eigenen Spiele zu entwickeln. Bereits nach den ersten Zeilen Code war ich davon total angetan, denn ich merkte, dass Spiele zu entwickeln weitaus mehr Spaß bereiten kann, als welche zu konsumieren:

Man entwirft eigene Rätsel und Regeln, lässt seiner Kreativität bei der Gestaltung fantasievoller Welten freien Lauf und freut sich, wenn diese später von anderen geteilt, bespielt oder mitgestaltet werden. Spielentwicklung ist Malerei ohne Pinsel und Macht ohne Armee, allein durch Worte kann man Welten erschaffen und damit andere Menschen zum Lachen bringen, Freude bereiten und die gesamte Klaviatur der menschlichen Gefühle bedienen. Der unabhängige Spieleentwickler arbeitet damit wie ein Autor, aber mit den technischen Möglichkeiten eines Filmregisseurs. Und dies lediglich durch ein paar Befehle, die ein paar Schaltern und Speicherstellen in einem Mikroprozessor erteilt werden.

Wenn Sie beim Brettspiel »Scotland Yard« lieber Mister X als die Polizisten spielen oder bei einer Schnitzeljagd öfter Gejagter denn Jäger sein möchten, sind Sie von Natur aus der geborene Spieleentwickler. Denn ein solcher liebt es, Rätsel zu entwerfen und anderen Spielern aufgrund seiner eigenen Ideen Spielfreude zu bereiten.

Zuerst testete ich die halbfertigen Spiele an meinen Geschwistern aus, doch irgendwann stellte ich fest, dass ich diese nicht mehr zu Ende programmieren konnte, weil der einzige Computer im Haus ständig von Familienmitgliedern besetzt war, die meine Spiele zockten.

Geld verdienen konnte man damit allerdings nicht. Denn so viel die Games auch Spaß bereiteten, verkaufen ließen sie sich nicht, denn an technischer Qualität waren sie kommerziellen Spielen natürlich weit unterlegen.

Dann kamen mit Flash die ersten kleinen Browsergames und später die ersten Handyspiele auf den Markt, und mit einem Mal befanden wir uns wieder auf dem technischen Stand von 1985. Damit wurden die Spiele wieder auf ihre zugrunde liegenden Ideen ohne Effekthascherei reduziert, und der Spielemarkt boomte, denn mit einem Mal spielten auch Menschen Videospiele, die nicht nächtelang Katakomben durchstreifen wollten. So sind es heute vor allem die Mobile- und Browsergames, die für positive Verkaufszahlen in der gesamten Branche sorgen.

Einer Prognose des Marktforschungsinstituts PricewaterhouseCoopers zufolge werden Mobile Games in den Jahren 2011 bis 2015 um 17% und Browserspiele um 12% wachsen, wohingegen der restliche Spielemarkt lediglich um 3–4 Prozent wächst.

Drei gute Gründe, das Buch gleich wieder zurückzugeben

Mit dem vorliegenden Buch möchten wir uns also ausschließlich mit der Entwicklung großartiger Spielideen und deren Umsetzung für das iOS beschäftigen. Und weil vor allem für das iPhone viele Spieleentwickler ihre Ideen meist alleine oder nur in einem sehr kleinen Team umsetzen, lernen Sie auf den vorliegenden Seiten nicht nur die technische Umsetzung, sondern erhalten auch eine Einfüh-rung, wie Sie mit einfachen Mitteln und Techniken großartige Grafiken und auch den passenden Sound dazu entwickeln.

Da die Spielewelt so einzigartig vielfältig ist und viele Games grundverschieden aufgebaut sind, werden wir uns nicht nur um die Ausarbeitung eines einzelnen Spiels kümmern, sondern insgesamt 13 (!) Spiele programmieren (das ist eines mehr, als auf dem Buchumschlag versprochen wird, aber zwei der Spiele – »Neptune Patrol« und »Gems3D« – sind nur abgewandelte Versionen von zwei vorhergehend behandelten Codes, die zähle ich fairerweise nur zur Hälfte!). Diese werden wir jeweils nur als Grundgerüst bauen, damit Sie genügend Freiheit haben, Ihre eigenen Spielideen darauf aufbauend weiterzuentwickeln.

Grund 1: Casual Games pur!

Falls Sie sich das Buch gekauft haben, weil Sie darin auf die Entwicklung von aufwendigen 3D-Shootern hofften, dann schlagen Sie die Seiten schnell zu und bringen Sie es zur Buchhandlung zurück. Es besteht noch eine Chance, dass Sie Ihr Geld zurückkriegen.

Denn obwohl in Kapitel 6 tatsächlich mit OpenGL ES die dreidimensionale Welt beschritten wird, nimmt dieser Teil nicht einmal 10% des gesamten Inhalts ein. Die dritte Dimension soll die Optik nur unterstützen und nicht Hauptbestandteil eines Spiels sein. Gerade Casual Games wirken optisch in 3D oft unnatürlich überfrachtet.

So decken wir Spielprinzipien ab, wie sie z.B. in »Super Mario Land«, »Doodle Jump«, »Tetris«, »R-Type« und »Breakout« vorkommen, und dies nicht nur mit Objective-C, sondern auch mit Frameworks wie Cocos2D oder OpenGL ES. Nebenbei erhalten Sie eine Einführung in die 3D-Software Blender, in das semi-professionelle Bildbearbeitungsprogramm Gimp oder in Digital Audio Workstations wie MuLab.

Grund 2: Nichts für pure Anfänger!

Damit wir all die Themen in vernünftigem Umfang abarbeiten können, muss ich leider auf eine Einführung in die Programmierung für iOS verzichten. Insofern sollten Sie bereits rudimentäre Objective-C-Kenntnisse besitzen und vielleicht schon mal ein anderes Buch über die App-Entwicklung zur Hälfte gelesen haben. In dieser Hinsicht kann ich »Programmieren für iPhone und iPad: Der Einstieg in die App-Entwick-lung« von Markus Stäuble für die Einführung und Entwicklung erster Apps mehr als nur empfehlen. Es ist der ideale Einstieg, um anschließend mit dem vorliegenden Buch weiterzumachen.

Wenn Sie auf der Suche nach einem Nachschlagewerk oder Lehrbuch waren, haben Sie mit dem Kauf dieses Buches ebenso ins falsche Regal gegriffen. Sie erhalten hier keine Referenz, keine Stichwortsuche oder detaillierte Erklärungen zu einzelnen Begriffen und Befehlen. Auch ist das Buch nicht dazu geeignet, trockenen Informatikunterricht zu begleiten.

Vielmehr wird elegant vom einfachen »Pong«-Spiel über Jump’n’Runs und Shooter das Wissen um technische Tricks, Special Effects und Raffinessen Stück für Stück erweitert, wobei die einzelnen Kapitel und Workshops fast immer aufeinander aufbauen.

Damit ist das Buch ideal für das Selbststudium geeignet. Und weil wir uns mit Spielen beschäftigen, darf der Spaß auch beim Lesen nicht zu kurz kommen, weswegen einige Kapitel und Absätze durchaus mit ironischen und nicht ganz ernst gemeinten Formulierungen aufwarten. So dass weder ich beim Schreiben noch Sie beim Lesen vor lauter staubtrockener Sachlichkeit geistig verdursten.

Grund 3: Dies ist kein Nachschlagewerk!

Sie werden in diesem Buch keine Erklärungen zu bestimmten Objective-C-Methoden oder -Techniken finden, sonst würden wir den Fokus auf die eigentliche Spielentwick-lung verlieren. Falls Sie allerdings buchbegleitend ein Nachschlagewerk benötigen, holen Sie sich unbedingt Max Seelemanns »Objective-C kompakt«, vor allem wenn Sie bereits andere Programmiersprachen wie Java oder C kennen sollten oder das Wesen von Objective-C näher kennenlernen wollen.

So, nachdem Sie das Buch erfreulicherweise noch immer in Händen halten, bleibt mir nur noch übrig, auf die buchbegleitende Webseite

www.iosgames.de

zu verweisen, auf der Sie alle Sourcecodes und Projekte, alle benötigten Dateien, Grafiken und Musiken sowie Links zu den kostenlosen Tools vorfinden, die wir im Verlauf des Buches benötigen werden.

Was müssen Sie beherrschen, damit Sie mit diesem Buch etwas anfangen können?

Wenn Sie bereits schon eine erste kleine App – sei es der klassische Kompass oder ein Adressbuch – aus einem anderen Buch nachgebaut und ein wenig mit dem Code experimentiert haben, dann sind Sie hier komplett richtig. Egal ob Sie die App bislang über den Interface Builder/Storyboard Editor oder programmiertechnisch erstellt haben, gleich im ersten Kapitel hole ich Sie an beiden Enden ab und gemeinsam marschieren wir dann schnurstracks in die Weiten des Spielekosmos.

Und weil sich so ein Buch über zwei Jahre lang nach Feierabend bis 3 Uhr nachts nicht von alleine schreibt, möchte ich als Letztes meiner großartigen Frau Céline und meinen beiden treuen Nachtwächtern Rala und Luna danken, die mich immer wieder aufgebaut und unterstützt haben, wenn mich Apple wegen zahlreicher verdammter Updates dazu zwang, große Teile des Codes neu zu schreiben. Und natürlich möchte ich meinem Lektor René Schönfeldt danken, der mit der Idee eines Buchs für iOS-Spielentwicklung 2010 an mich herangetreten ist und damit dafür gesorgt hat, dass ich in den vergangenen zwei Jahren kein Privatleben mehr hatte. Aber hey, so eine großartige Chance kriegt man nur einmal! Und dafür bin ich dankbar!

Und nun wünsche ich Ihnen, lieber Leser, viel Spaß mit dem vorliegenden Buch, der Entwicklung der darin besprochenen Games und vor allem viel, viel Erfolg in der App-Welt mit Ihren daraus hoffentlich entstehenden eigenen Spielen.

Denn dieses Buch habe ich nicht ohne Eigennutz geschrieben: Wenn Sie Erfolg haben, habe ich dank Ihnen zukünftig weiterhin viel kurzweilig-genialen Spaß auf meinem iPhone. Und das waren mir die letzten zwei Jahre wert.

Inhaltsübersicht

1      Der macht nichts, der will nur spielen ...

2      Loading ... Von der Idee bis zum Game-Design-Dokument

3      Level I: Klassische Casual Games

4      Level II: Moderne Casual Games

5      Level III: Casual Games für Profis

6      Level IV: Casual Games 3D

7      Der Endgegner: Die letzten 10%

8      Hidden Levels

9      Bonuslevel: Artwork und Grafik

10    Bonuslevel: Sound FX/Music

11    Hall of Fame

Literaturverzeichnis

Index

Inhaltsverzeichnis

1       Der macht nichts, der will nur spielen ...

2       Loading ... Von der Idee bis zum Game-Design-Dokument

2.1     Inspiration – Woher nehmen?

2.1.1      Inspiration von der Technik

2.1.2      Inspiration vom Spielen

2.1.2.1    Kreative Kombination alter Spielkonzepte

2.1.2.2    Umwerfen alter Spielkonzepte

2.1.2.3    Erweiterung bekannter Spielkonzepte

2.1.3      Inspiration im Alltag

2.2     Casual Games: Wovon reden wir hier eigentlich?

2.2.1      Charakteristik

2.2.2      Zielgruppen

2.3     Garantierte Flops – Apples No-Gos

2.4     Game-Design-Dokument – Grau ist alle Theorie

2.4.1      Aufbau

2.4.1.1    Core Statement

2.4.1.2    Exposé

2.4.1.3    Grobkonzept

2.4.1.4    Feinkonzept

2.5     Zielgeräte – iPhone, iPod oder iPad?

2.5.1      Display

2.5.2      Größe

2.5.3      Zeit

2.5.4      Anspruch

2.5.5      Sozialer Aspekt

2.5.6      Die eierlegende Wollmilchsau

3       Level I: Klassische Casual Games

3.1     »Pong«

3.1.1      Das erste komplette Spiel

3.1.1.1    Vorbereitungen

3.1.1.2    Programmierung der Game Engine

3.1.1.3    Titelbild

3.1.1.4    Debugging und Codeoptimierung

3.1.2      Pong-Variationen

3.1.2.1    Pong einhändig

3.1.2.2    Zweidäumig

3.1.2.3    Ball mit Drall

3.1.3      Pong für zwei – Mensch gegen Maschine

3.1.4      Pong für zwei – Mensch gegen Mensch

3.2     »Breakout«

3.2.1      Programmierte UI

3.2.1.1    CADisplayLink – der bessere Timer

3.2.1.2    Licht an, Status aus

3.2.2      Verfeinerung der Kollisionsabfrage

3.2.2.1    Kollisionsabfrage zwischen zwei Bällen

3.2.3      Die Mauer muss weg!

3.2.4      Level 1 – 36

3.2.5      Erweiterungsmöglichkeiten

3.2.5.1    Vogelfreie Mauersteine

3.2.5.2    »BallOut« – der Rundum–Schläger

3.2.5.3    Erweiterung des Leveldesigns

3.2.5.4    Der Ball

3.3    »Lunar Lander«

3.3.1      Animation

3.3.2      Head-up-Display

3.3.3      Aufbau und Gameplay

3.4     »Marble Maze« aka »Labyrinth«

3.5     »Fire!« aka »Bouncing Babies«

3.5.1      Querformat

3.5.2      Die Klasse »Sprite«

4       Level II: Moderne Casual Games

4.1     Scrolling

4.1.1      Page-Scrolling

4.1.2      Einfaches Scrolling

4.1.3      Parallax-Scrolling

4.2     »Noodle Jump« aka »Doodle Jump«

4.2.1      Jetzt wird alles relativ

4.2.2      Performance-Optimierungen

4.2.2.1    Endlosphilosophie

4.2.2.2    Auf Konstanten können Sie zählen

4.2.2.3    Preloader

4.2.2.4    Erweiterungsmöglichkeiten

4.3     »iType« aka »R-Type«

4.3.1      Scrolling

4.3.2      Virtual Joypad

4.3.3      Virtual Touchpad

4.3.4      Optimierung der Kollisionsabfrage: Maskierung

4.3.5      Verlieren mit Bumms!

4.3.6      Aliens und Game-Balance

4.3.7      Schüsse, Sterne, Funken, Rauch und Explosionen: Partikel

4.3.7.1    Die Aliens schießen zurück

4.3.7.2    Kosmetik: Sterne und Explosionen

4.3.8      Bonuslevel: Faszination Partikel

4.3.8.1    Funkenflug

4.3.8.2    Brandherd

4.3.8.3    Rauchschwaden

4.3.8.4    Nebelschwaden

4.3.8.5    Niagarafälle

4.3.8.6    Wunderkerze oder Lunte

4.3.8.7    Feuerwerk

4.3.9      Endgegner und andere Erweiterungen

4.4     »Neptune Patrol« aka »Moon Patrol«

4.5     »The Little Jungle Sisters« aka »The Great Giana Sisters«

4.5.1      Dynamisches Scrollen

4.5.2      Kompletter Code

4.5.3      Ebenensortierung

4.5.4      Detaillierte Animationen

4.5.5      Parallax-Scrolling – ein Hauch von 3D

4.5.6      Einäugige Sumpfmonster

5       Level III: Casual Games für Profis

5.1     Tilemaps

5.1.1      UIView vs. CALayer

5.1.2      Tiled – ein kostenloser Tilemap-Editor

5.2     »1783 – Montgolfière« aka »1942«

5.2.1      Pseudo 3D

5.2.2      Tile-Engine für Animation

5.3     »Nuke Control« – Programmieren mit Cocos2D

5.3.1      Installation von Cocos2D

5.3.2      Einführung in Cocos2D

5.3.3      Draw-Steuerung

5.3.4      Spielkonzept und Grafiken

5.3.5      Herstellung der Grafiken

5.3.6      Draw-Steuerung (Choreografie, Muster)

6       Level IV: Casual Games 3D

6.1     OpenGL ES

6.2     »Jellybears« aka »Collapse!«

6.2.1      Grafische Umsetzung

6.2.2      Technische Umsetzung

6.2.3      Spiellogik

6.2.4      Rekursiver Steinbruch

6.3     »Gems 3D« aka »Collapse!«

6.3.1      Meshes aus .OBJ laden

6.4     Blender

6.4.1      Ikosaeder

6.4.2      Edelstein

6.4.3      Metaballs

7       Der Endgegner: Die letzten 10%

7.1     Die Menüstruktur

7.1.1      Methode 1»Eine für alles«

7.1.2      Methode 2: »Storyboard«

7.1.2.1    Programmiertechnischer Wechsel

8       Hidden Levels

8.1     Face Detection

8.2     Face Tracking

8.3     Einstellungen

8.4     Highscore

8.5     GameKit

8.6     Facebook

8.7     Videosequenz

8.8     Location

8.9     Kompass

9       Bonuslevel: Artwork und Grafik

9.1     Gimp

9.1.1      Installation

9.1.2      Einführung für komplette Neulinge

9.1.3      Zeichnen mit Niveau: Ebenen in Gimp

9.2     Farbtheorie

9.2.1      Die wichtigsten Farben

9.2.1.1    Himmel

9.2.1.2    Haut

9.2.1.3    Metalle

9.2.2      Ambiente

9.2.3      Farbnutzung

9.2.4      Licht und Schatten

9.3     Sprites

9.3.1      Helden

9.3.1.1    Typ »Doodle«

9.3.1.2    Typ »8-Bit Pixel Art«

9.3.1.3    Typ »Vektorgrafik«

9.3.1.4    Typ »16-Bit«

9.3.1.5    Typ »3D«

9.3.1.6    Typ »Eigenkreation«

9.3.2      Animationen

9.3.2.1    Rollige Helden

9.3.2.2    Läufige Helden

9.3.2.3    Rundgang

9.3.3      Plattformen (16 Standard Tiles)

9.3.4      Minisprites: Gems

9.3.5      Explosionen

9.4     Hintergrundgrafiken

9.4.1      Wolken

9.4.1.1    Typ »Kinderspiel«

9.4.1.2    Wolkenmeer

9.4.1.3    Typ »Comic«

9.4.2      Landschaft

9.4.2.1    Hügel

9.4.2.2    Wald und Bäume

9.4.3      Wetter

9.4.4      Schnörkel

9.4.5      Weltraum

9.4.5.1    Panel »Raumschiff«

9.4.5.2    Panel »Versuchslabor«

9.4.5.3    Panel »Felsplanet«

9.4.5.4    Panel »Alienplanet«

9.4.5.5    Panel »Eiskristall«

9.4.5.6    Panel »Elektro«

9.4.6      Puzzlehintergründe

9.4.6.1    Fraktale

9.4.6.2    Pinsel

9.5     Titelbild

9.5.1      Titelbildloser Titelscreen

9.5.2      Titelbilder, wie sie sein müssen

9.6     Grafiken in Code einbinden

9.6.1      Standardauflösung vs. Retina

9.6.2      Ladescreen

10     Bonuslevel: Sound FX/Music

10.1   Musikproduktion

10.1.1    Software

10.1.1.1  Elektronische Musik

10.1.1.2  MuLab 4.1

10.1.2    Virtuelle Instrumente

10.1.3    So spielen Sie keine falschen Töne

10.1.3.1  Akkorde

10.1.3.2  Tonleiter

10.1.3.3  Akkordfolgen

10.1.3.4  Rhythmik

10.1.3.5  Percussion

10.1.3.6  Bass

10.1.3.7  Melodie

10.1.4    Jingles

10.1.5    Musik

10.1.5.1  Reggae

10.1.5.2  Samba

10.1.5.3  Elektro

10.1.5.4  Rap

10.1.6    Sound FX

10.1.6.1  Bibliothek

10.1.6.2  Cfxr

10.1.6.3  Aufnahme

10.1.7    Sounds für die App vorbereiten

10.2   Auftragsmusik

10.3   Sound in Objective-C

10.3.1    Dateiformate

10.3.2    Cleveres Musikmanagement

10.3.2.1  Atmosphäre erzeugen

10.3.2.2  Loops

10.3.3    Wiedergabe über Objective-C

10.3.3.1  Sound FX

10.3.3.2  Hintergrundmusik

11      Hall of Fame

11.1    Sehen Sie die Spieler an

11.2    Helden mit Macken

11.3    Pfeifkonzert

11.4    Gefühlsduselei

11.5    Öfter mal was Neues

11.6    Oster- und Mogelei

11.7    Bescherung

11.8    Humor

11.8.1    Slapstick

11.8.2    Situationskomik

11.8.3    Anspielungen, Hommagen, Zitate

11.9    Erschöpfung

11.10  Blitzreinkarnation

11.11  Kreative Sensoren

11.12  Kopierschutz

   Literaturverzeichnis

   Index

1 Der macht nichts, der will nur spielen ...

»Der Mensch spielt nur, wo er
in voller Bedeutung des Wortes Mensch ist,
und er ist nur da ganz Mensch, wo er spielt.«

(Friedrich Schiller)

Autsch! Ein Fachbuch über Spieleprogrammierung, das mit einem literarischen Zitat anfängt? Sind Sie sicher, dass Sie das richtige Buch in den Händen halten? Sie wollten doch nur etwas über die Entwicklung von Spielen lernen?

Ich kann Sie beruhigen, Sie sind hier vollkommen richtig! Spätestens seitdem der Deutsche Kulturrat den Bundesverband der Entwickler von Computerspielen (G.A.M.E.) im August 2008 aufgenommen hat, dürfen wir Spieleentwickler uns als kreative Kulturschaffende bezeichnen. Und mit diesem Hintergrund (und der Tatsache, dass ich in Schillers Geburtsstadt geboren wurde) passt das Eingangszitat zu den folgenden Seiten, in denen Sie und ich eine ganze Menge über Spieleentwicklung für iPhones und iPads lernen werden.

Dabei werden wir andere Wege gehen als vergleichbare Bücher. Normalerweise werden ein bis zwei Spiele von Anfang bis Ende durchprogrammiert, und zum Schluss haben Sie ein Spiel auf Ihrem Handy, welches alle wichtigen Elemente enthält ... außer dem Spaßfaktor. Es bringt Ihnen nichts, wenn Sie ein Jump’n’Run programmieren möchten, in einem Buch aber nur Kenntnisse darüber erhalten, wie Tetris-Steine am einfachsten zu steuern sind. Da allerdings kaum ein Spiel alle Anforderungen abdeckt, werden wir auf den folgenden Seiten insgesamt über 12 Spiele »nachbauen«, um diese Techniken eventuell in Ihre eigenen Ideen einfließen zu lassen. Diese Spielauswahl ist nicht nur zufällig gewählt, sondern orientiert sich stark an realen Vorbildern, die ihre Erfolge entweder im App Store oder ganz allgemein auf anderen Plattformen mehrfach bewiesen haben. Dabei geht es mir mehr ums A als ums O, also mehr ums KApieren als ums KOpieren der Strukturen, die einem jeden Spiel zugrunde liegen.

Der Vorteil: Sie erhalten so einen großen Überblick über die verschiedenen Techniken und können sie auf Ihre eigenen Ideen anwenden. Den Nachteil dieser Methode möchte ich auch nicht verschweigen: Sie werden nicht alles vorgekaut bekommen, sondern müssen dabei viel Wissen transferieren, denn aufgrund der Vielfalt werden wir die Spiele auch meist nur als Fragment und nicht komplett zu Ende programmieren (z.B. nur die ersten zwei Level oder drei unterschiedliche Plattformen, die restlichen können Sie dann nach eigenen Ideen gestalten). Sie haben sicherlich sowieso schon Ihre eigenen Ideen im Kopf und benötigen deswegen nur die grundsätzlichen Spielprinzipien in Codeform. So werden Sie ein durchgestyltes Head-up-Display (HUD) nur einmal implementieren »müssen«. Es ergibt in meinen Augen keinen Sinn, dieses in jedem Spiel vollständig zu implementieren (wir werden uns stattdessen in den meisten Workshops auf die ästhetisch unanspruchsvolle, aber einfache Ausgabe per UILabel beschränken). Wir würden uns nur wiederholen, unnötig Seiten vollschreiben und wieder für ein paar Bäume weniger im Regenwald verantwortlich sein. Stattdessen verweise ich einfach auf die behandelnden Kapitel im Buch und belasse den Code einigermaßen kurz und übersichtlich.

Image

Hiermit lade ich Sie also ein, auf den folgenden Seiten einen Blumenstrauß an Grundlagen der Spieleprogrammierung zu erarbeiten, die sich doch beträchtlich von der Programmierung »normaler« Apps unterscheiden. Wer einen einfachen 2D-Shooter programmieren möchte, muss sich nicht nur in Sachen Prozessorleistung gut auskennen, er sollte auch perfekt mit der Speicherverwaltung jonglieren und flüssige Animationen programmieren können, mit ViewControllern arbeiten und Ahnung von Benutzerfreundlichkeit haben. Von der Anbindung der Spielerdaten an eine Datenbank samt Verwaltung und der Verbindung mit sozialen Netzwerken ganz zu schweigen. Wer dann noch gute Grafiken zeichnen und seine Titelbilder und Level mit flotter Musik unterlegen kann, hat aus technischer Sicht schon halb gewonnen. Doch die andere Hälfte hat es ebenso in sich: Wie werden gute Level entworfen, was muss ein gutes Leveldesign auszeichnen, damit die Spieler lange daran Spaß haben? Und vor allem: Wie kann man das Spiel so gestalten, dass es überhaupt Anklang in der Spielergemeinde findet?

Na, wenn der das sagt ...

Die Gamer-Legende John Carmack, der Erfinder des ersten 3D-Ego-Shooters »Doom«, sagte Ende 2011 in einem mit spiegel.de geführten Interview: »Spielentwicklung ist viel anspruchsvoller als Raketenforschung. Das klingt lächerlich, stimmt aber. Wenn man die Programmierung zusammenrechnet, die für das Apollo-Programm nötig war, dann ist das ein winziger Bruchteil dessen, was wir heute in einem Spiel machen.« (www.spiegel.de/netzwelt/games/0,1518,787621,00.html)

Viele wichtige Bereiche der Programmierung müssen also nicht nur unter einen Hut gebracht werden, sie sollten auch noch sehr performant miteinander harmonieren. Kurz: Wenn die Entwicklung von Kalendern und Kompassen zum Pflichtprogramm eines Programmierers gehört, dann ist die Spiele- neben der Demoentwicklung schon immer die Kür gewesen! Selbst Casual Games fordern Entwicklern einiges ab.

Am Anfang eines jeden guten Spiels stehen natürlich immer erst mal eine sehr gute Idee und die technischen Grundlagen. Das Letztere bringen Sie mit, und mit dem Rest wie Ideenfindung und dem Game-Design-Dokument beschäftigen wir uns nun kurz auf den nächsten Seiten, bevor wir dann in »Level I« (ab S. 41) so richtig loslegen können.

2 Loading ... Von der Idee bis zum Game-Design-Dokument

2.1 Inspiration – Woher nehmen?

Womöglich haben Sie bereits eine geniale Idee im Kopf, die Grafiken sind auch schon vorbereitet, und nun warten Sie nur noch auf den Startschuss? Herzlichen Glückwunsch!

Oder haben Sie alle Pflichttutorials, die man als Programmiereinsteiger von Objective-C angeboten bekommt, nachprogrammiert und erweitert, vom Kompass über ein einfaches Adressbuch bis zur Kamera-App? Und nun möchten Sie endlich den Pflichtteil hinter sich bringen und mit der Kür – Ihrem eigenen Spiel – beginnen und brauchen dafür nur noch eine Idee?

Von Tetris-Clones haben sicherlich nicht nur Sie genug, und wenn Sie mit Ihrem Spiel bei der Fülle an Konkurrenzprodukten Erfolg haben wollen, müssen Sie auffallen. Da spielen spätestens bei der Veröffentlichung natürlich auch Marketingstrategien eine Rolle, aber wenn man nur ein sehr geringes Budget hat, dann muss sich das Spiel auch ohne Werbung vom Rest durch etwas abheben, was auch gerne als der Heilige Gral bei der Entwicklung von Spielen betrachtet wird: der außergewöhnlichen Spielidee und einem kreativen Gameplay. Nur mit diesen beiden Zutaten erreicht man einen viralen Effekt (kostenlose Werbung in Form von Empfehlung von Freunden), der die Verkaufszahlen steigen lässt, weil die Spieler gerne weitererzählen, wenn ihnen etwas Spaß macht, sie andere daran teilhaben lassen wollen oder sich mit ihnen darin gar duellieren möchten.

Die letzten Sätze klingen nun sogar für binsenweisheitliche Maßstäbe ziemlich abgedroschen, und man kommt nach den sehr vielen innovativen Spielideen, die in den ersten beiden Jahren nach der Einführung des iPhones auf den Markt kamen, schnell in Verlegenheit zu sagen, dass aus dem Gerät nicht mehr viel spielerische Innovation herauszukitzeln ist.

2.1.1 Inspiration von der Technik

Tatsächlich sind viele grundsätzliche Spielideen erst möglich geworden, weil das iPhone mit dem Touchscreen, dem Kompass, dem Accelerometer und dem Weglassen der üblichen Buttons und Tasten neue Interaktionsfeatures erforderte bzw. ermöglichte, die große Handhelds wie der Nintendo DS oder die Playstation Portable bis dato nicht boten. Klassiker wie »Flight Control«, »Doodle Jump«, »Mega Jump«, »Rope’n’Fly«, »High Noon«, »Fruit Ninja«, »Angry Birds« oder »Labyrinth« waren die Vorreiter einer anschließenden Flut von vielen kreativen Mobile Games, die vor allem Casual Gamer begeisterten und für extrem hohe Downloadzahlen im App Store sorgten (und ihren Erfindern ein paar Geldsorgen weniger bereiteten).

Dank Apple kommt mittlerweile mindestens einmal im Jahr ein neues Gerät der mobilen Produktpalette heraus, das bislang immer ein derart innovatives Feature beinhaltete, dass sich völlig neue Spielgenres oder zumindest Steuerungsmöglichkeiten auftaten (z.B. »Siri«). Man kann darauf vertrauen, dass diese jähr-lichen technischen Updates weitergehen werden, zumindest so lange, wie Apple seine Spitzenmodelle nicht mit einem 3D-Display, einem eingebauten Scanner oder einen Beamer ausgestattet hat. Deren spielerisches Potenzial zu erkennen und darauf frühzeitig ein Spiel oder eine Fun-App zu entwickeln, welche nur mit diesem Feature (und nicht nur der reinen Innovation zuliebe) Sinn ergeben oder gar Spaß bereiten, das ist nach wie vor einer der wichtigsten Schlüssel zum Erfolg eines iPhone-Games.

Erst waren es nur der Touchscreen (»Flight Control«, »Fruit Ninja«) und der Accelerometer bzw. Beschleunigungssensor (»Labyrinth«, »Doodle Jump«, »Mega Jump«), die der mobilen Spielewelt neue Spielideen ermöglichten. Damit waren nun Mobile Games mit völlig neuen Bedienkonzepten möglich, vom einfachen Ziehen einer Figur mit einem Finger (Dragging) über Pinchen bis zur einhändigen Steuerung, indem man nur das Gerät in eine Richtung kippen musste. Auch wurde dem Spieler durch diese Techniken mehr (intuitives) Geschick bei der Steuerung abverlangt als bislang beim bloßen Drücken von Knöpfen oder Tasten wie bei anderen mobilen Endgeräten. Der Touchscreen beschleunigte generelle Spielweisen auch im Vergleich zu herkömmlichen Desktopspielen, denn nun kann der Spieler mit seinem Finger schneller auf Situationen reagieren und muss nicht erst umständlich den Mauszeiger grobmotorisch an eine bestimmte Position bringen, um dort reagieren zu können. Durch die Multitouchfähigkeit ist durch Gesten auch mehr Aktionsmöglichkeit als bislang mit nur einem Mauszeiger gegeben.

Die sehr gute GPS-Ortsbestimmung des iPhones machte die bislang nur in Nerd-Kreisen bekannten LBS-Games (Spiele, die Location Based Services nutzen) einer breiten Öffentlichkeit zugänglich.

Durch den größeren Bildschirm des iPads wurde die Spielfläche größer, damit war es nun möglich, zu zweit gleichzeitig auf einem Spielfeld zu agieren. Ganze Brettspiele konnten damit nun mobil sinnvoll umgesetzt werden.

Mit dem Gyroskop im iPhone 4 kam die Bestimmung der Rotation hinzu, die sich allerdings bislang erst bei Location-Based-Services-Apps wie »Layar« oder Augmented-Reality-Apps sinnvoll einsetzen ließ. Und mit einer Kamera, die auch Bilder auf der Frontseite empfangen kann, tun sich völlig neue Spielideen auf, die mit der bisherigen Kamera nicht möglich waren, weil der Spieler nun sein eigenes Gesicht ins Spielfeld rücken kann, welches seit der Einführung des iOS 5 mit der Gesichtserkennung des Core Image Frameworks mehr an Bedeutung gewinnen wird und so den Spieler Teil des Spiels werden lässt (Stichwort »Augmented Reality«). Zukünftige Versionen des iPhones oder des iPads (oder AppleTVs) werden sicherlich weitere innovative Sensoren und Gadgets haben, für die es bislang keine herkömmlichen Spielideen oder -konzepte gab.

Image

Interessiert man sich als Game Designer und Programmierer ab der Präsentation neuer Geräte für deren neue Features und kann sich erste Gedanken über deren Funktionalität und deren Einsatz in einem Spiel machen, ist die Wahrscheinlichkeit groß, dass die Early Adopters – also die ersten Besitzer der neuen Geräteversion – sich genau diese Software herunterladen, um ihren Freunden auf unterhalt-same Weise zu zeigen, was das neue Gerät kann.

Wichtig bei all dem ist aber: Um langfristig Erfolg zu haben, muss die Steue-rung über den neuen Sensor sinnvoll und darf nicht nur Mittel zum Zweck sein (also nicht: »Schau mal, damit kann man es auch steuern. Ist zwar nicht so praktisch, aber es geht!«).

In allererster Linie muss man sich bei der Entwicklung neuer Aktionskonzepte fragen, ob nicht eine der bisherigen gängigen Steuerungsmöglichkeiten wie Dragging, Touching oder über den Accelerometer je nach App sinnvoller wäre. Ist dies der Fall und fühlt sich die Steuerung damit intuitiver an, kann man die »neue« Idee getrost verwerfen, denn dann leidet die Benutzerfreundlichkeit, und das vermeintlich innovative Feature ist gar nicht mehr so toll und sorgt sogar für Frust beim Spieler.

Technik als Selbstzweck

Ein Beispiel für misslungene Benutzerfreundlichkeit ist z.B. das Konzept, mit dem iPhone Pingpong zu spielen und das iPhone dabei tatsächlich wie einen Schläger zu halten und zu nutzen, mit Rückhand, Schmettern und allem Drum und Dran. An sich eine tolle Idee, die ja auch auf der Spielkonsole Wii hervorragend funktioniert. Nur fallen bei intensiver Betrachtung gleich mehrere Nachteile auf:

Wenn ich das iPhone wie einen Tischtennisschläger halte, sehe ich auf dem Display weder, wo sich aktuell der Ball befindet, noch habe ich als Spieler Übersicht über die Tischtennisplatte. Zudem sind Spiele mit solchen Steuerungskonzepten (und das ist für Casual Games fast zwingend erforderlich) in einer U-Bahn nur schwer spielbar, ohne andere zu verletzen. Und zu schlechter Letzt: Schneller kann man sein iPhone nicht schrotten, als wenn man es bei einem Schmetterschlag aus Versehen aus der Hand gleiten und an der gegenüberliegenden Wand oder im gegenüberliegenden Gesicht zertrümmern lässt.

Aus diesen Gründen musste ich einmal einen lukrativen Programmierauftrag zurückweisen: Der Kunde wollte eine Art iPhone-Version des One-Player-Strand-tennis haben, also diese Tischtennisschläger, an denen direkt an der Schlagfläche ein Gummiball an einem Gummiband befestigt ist und mit dem man versuchen muss, den Ball so oft wie möglich im richtigen Takt zu schlagen und aufzufangen ... also sehr, sehr casual!

Die Schlagtechnik wäre leicht umzusetzen gewesen, bei der minimalen Bewegung hätte noch nicht einmal die Gefahr bestanden, dass der Spieler das iPhone aus seiner Hand gleiten lässt, und über den Bewegungssensor hätte man sogar logisch feststellen können, in welche Richtung der Spieler den Ball schlägt und ob er ihn überhaupt trifft. Das Kernproblem war aber die visuelle Kontrolle: Der Spieler hatte bei der schnellen Bewegung keine Chance, den Ball optisch richtig auf dem Display wahrzunehmen, und somit wäre jeder Rekord, den er mit dem Spiel aufgestellt hätte, reiner Zufall gewesen, und damit hätte das Spiel schnell für Frust gesorgt. Und für Frust mag man noch nicht einmal 0,79 € im App Store bezahlen!

Solche Geschichten sollte man also immer im Hinterkopf behalten, wenn man versucht, innovative Konzepte in seine Spielmechanik einzubauen.

2.1.2 Inspiration vom Spielen

Wenn Ihnen zu den neuen Hardwaremöglichkeiten partout kein innovatives und logisches Konzept einfallen will, selbst wenn Sie diese mit anderen Sensoren kombinieren (z.B. Touch und gleichzeitig kippen), ist das sicherlich kein Grund aufzugeben. Es gibt noch genügend andere Spielkonzepte, die auf »klassischen« Steuerungsprinzipien beruhen, völlig innovativ sind, richtig Spaß machen und die trotzdem noch keiner erfunden hat.

Wer dafür Inspirationen sucht, sollte seinen alten C64, Amiga 500 oder Gameboy herauskramen und ein paar der alten Games darauf spielen, die einen früher begeistert haben und die rein technisch noch nicht mit aufwertender Grafik punkten konnten, so dass auf Entwicklerseite viel mehr Wert auf den Spielspaß und eine gesunde Game Balance als teilweise bei heutigen Spielen gelegt werden musste.

Nehmen Sie sich unbedingt die Zeit, holen Sie Ihre alten Kisten wieder hervor, zocken Sie diese Spiele und lassen Sie sich dabei inspirieren. Machen Sie sich ein paar Gedanken darüber, warum Ihnen diese Spiele damals so viel Spaß bereitet haben und welche Eigenschaften sie haben, die sie besser als vergleichbare Spiele machten. Ob es die Steuerung, der Schwierigkeitsgrad, die Animationen oder der Humor des Spiels waren, das gesamte Gameplay, die gute Musik, die zugrunde liegende Spielidee oder die Grafiken, die Ihnen gefielen – notieren Sie es sich, machen Sie sich mit den alten Spielen noch einmal vertraut, denn in ihnen steckt nach wie vor die Essenz der meisten heutigen Spiele. Vielleicht werden Sie dabei erkennen, dass sich die grundlegenden Eigenschaften und Mechaniken von »Super Mario« und »Lara Croft« stark ähneln, und vielleicht bringen Sie diese Erkenntnisse auf eine neue, glorreiche Spielidee?

2.1.2.1 Kreative Kombination alter Spielkonzepte

Eine Möglichkeit, neuartige Spielideen zu kreieren, ist die Kombination zweier oder mehrerer Spielkonzepte. Suchen Sie sich zwei Computerspielklassiker aus, die eine gewisse Ähnlichkeit miteinander haben, wie z.B. »Tetris« und »Break-out«. Beide bestehen hauptsächlich aus Blöcken, nur wird mit beiden völlig unterschiedlich verfahren.

Image

Abb. 2–1 Ein Tetris-Stein als Jump’n’Run-Held? Nicht wirklich innovativ!

Während bei »Tetris« die Steinformationen sinnvoll angeordnet werden müssen, werden sie bei Breakout durch das Jonglieren mit einem Ball eliminiert. Kann man diese beiden Spielprinzipien nicht miteinander kombinieren? Fällt ein Tetris-Baustein erst herunter, wenn man ihn vorher mit einem Ball getroffen hat? Muss man die herunterfallenden Steine durch das Abschießen mit einem Ball erst in die richtige Form bringen, damit sie nahtlos in das bestehende Gerüst eingepasst werden können? Müssen Tetris-Bausteine in ihr passendes Loch mit dem Schläger jongliert werden? Fragen über Fragen, die eventuell zu einer neuen Spielidee führen könnten. Versuchen Sie, die verrücktesten Ideen miteinander zu kombinieren, die als Ergebnis trotzdem spielbar bleiben und nicht absolut konfus und krampfhaft innovativ erscheinen. Verlassen Sie dabei gerne auch die Grenzen der Computerspiele, suchen Sie nach Möglichkeiten, Brett- oder Kinderspiele (Fangen, Verstecken etc.) mit einem Computerspiel zu kombinieren. Herauskommen wird dabei sicherlich ein Casual Game, denn die frühen Spiele sind konzeptionell und technisch allemal diesem Genre zuzuordnen und sind teilweise wie geschaffen für ein mobiles Endgerät mit einer übersichtlichen Displaygröße wie dem iPhone.

Achtung, aufgepasst!

Das Zocken alter Spieleklassiker als Inspiration ist eine hervorragende Brainstormingmethode, allerdings sollte als Endergebnis kein Spiel herauskommen, das einem zahlreiche Marken- oder Patentverletzungsklagen beschert. Manche Spielideen sind mittlerweile frei von Rechten, weil viele Softwarestudios nicht mehr existieren (und wo kein Kläger, da kein Richter), aber trotzdem sollten Sie beim Entwurf einer solchen Idee genauestens recherchieren, ob nicht irgendwelche Markenrechte verletzt werden könnten, weil bei der Insolvenz die Rechte an den Werken teilweise an andere Entwicklungsstudios verkauft wurden oder sie anderweitig geschützt sind. Vermeiden Sie z.B. unter allen Umständen einem Tetris-ähnlichen Spiel (das Konzept ist nicht geschützt) einen Namen mit der Endung »-tris« (der Name hingegen ist geschützt) zu geben und es in den App Store zu stellen, Sie werden garantiert schnell unerfreuliche Post in Ihrem Briefkasten finden.

Um dem Erinnerungsvermögen ein wenig nachzuhelfen, welche Spielklassiker es auf verschiedenen Systemen gibt, hier eine kleine Auflistung, wobei die Liste schier unendlich erweitert werden kann:

Image Tetris

Image Pac Man

Image Breakout

Image Summer Games

Image Sudoku

Image Minesweeper

Image Monkey Island

Image Adventureland

Image After Burner

Image Archon

Image Atomino

Image R-Type

Image Battle Chess

Image Strip Poker

Image BlockOut

Image BoulderDash

Image Bubble Bobble

Image Burgertime

Image Street Fighter

Image Sim City

Image Frogger

Image Impossible Mission

Image Zelda

Image Nibbles

Image Last Ninja

Image Paperboy

Image Pirates!

Image Pole Position

Image Q*bert

Image Qix

Image Rock’n’Roll

Image Sokoban

Image To Be On Top

Image Worms

Image The Great Giana Sisters

Image Pokemon

Image Donkey Kong

Image Lemminge

»Sudoku« mit »Minesweeper« kombinieren? Da lässt sich doch was machen. »Atomino« und »Frogger«? Schwierig, aber vielleicht trotzdem machbar? »Atomino« und »Sokoban«, das ginge schon eher! »Pac Man« und »Rock’n’Roll«? Da ließe sich doch prima der Accelerometer einbauen. Oder doch lieber »Pac Man« in »Last Ninja«-Optik? Wie wäre ein Jump’n’Run, bei der die Spielfigur »Tetris«-Blöcke erklimmen und von Stein zu Stein springen muss, bevor sie den Boden berührt, oder ein Frosch, der den Steinen ausweichen muss, um die andere Straßenseite zu erreichen?

Wichtig ist dabei, dass das Spielprinzip verändert wird und Sie nicht nur die Akteure austauschen. Wenn beim letzten Vorschlag (Frosch, der Tetris-Bausteinen ausweichen muss) das Prinzip von »Frogger« beibehalten wird und statt Autos und Baumstämmen einfach nur Bauklotzvarianten kreuzen, mit denen weiter nichts veranstaltet werden muss, dann ist das nicht gerade innovativ, sondern wirkt verkrampft.

2.1.2.2 Umwerfen alter Spielkonzepte

Sie kennen sicherlich den Evergreen »Super Mario«, haben ihn entweder schon 1989 auf dem Gameboy oder erst kürzlich auf der Wii durch alle Welten gejagt und teilen bestimmt mit einem Großteil der Spieler die Meinung, in Sachen Jump’n’Run wurde alles programmiert, was man als Jump’n’Run spielen kann! Doch haben Sie schon einmal überlegt, das Spielkonzept einfach umzuwerfen? Erfinden Sie ein Spiel, in dem der Held daran gehindert werden muss, sein Ziel zu erreichen, in dem der Spieler nicht den Helden spielt, sondern die Gegner im Vorfeld innerhalb des Levels platziert, um dem Helden so das Leben schwer zu machen. So wird aus dem Jump’n’Run ein Action-Strategiespiel.

Warum in »Tetris« immer alles abbauen? Warum daraus nicht mal eine Aufbausimulation entwickeln? Oder statt der Aufgabe, die Steine in die bisher gefallenen Klötze einzupassen, einfach die bereits gefallenen Steine so umherzuschieben, dass der herunterfallende Stein, den man nicht steuern und drehen kann, genau in die Lücke passt? Dazu noch ein bisschen physikalische Besonderheiten einbauen (Schwerkraft, Reibung) und wir haben ein perfektes Sandboxgame. Oder zumindest den Prototypen davon, denn ob das neue Spielprinzip dann immer noch Spaß macht, das ist leider schwer vorhersehbar.

Image

Abb. 2–2 Das Tetris-Prinzip als »echtes« Puzzlespiel wäre neuartig.

Bei Umkehrideen geht es darum, entweder die Position des Gegners einzunehmen und dessen Aufgaben zu meistern oder aus Sicht des Spielers das gegenteilige Ziel zu erreichen (und damit gegebenenfalls die Grundstruktur des Levels anzupassen).

Weitere Umkehrideen wären z.B.

Image »Anti Minesweeper«, das Spiel, in dem die Bombe so schnell wie möglich gefunden werden muss.

Image »Anti Sudoku«: Nehmen Sie bei einem fertig gelösten Sudoku-Rätsel so viele Ziffern wie möglich weg, so dass das Rätsel noch lösbar bleibt.

Image »Anti R-Type«: Formieren Sie die Gegner, damit das Heldenraumschiff keine Chance hat auszuweichen.

Image »Anti Pac Man«: Entwickeln Sie eine »Scotland Yard«-Version des Spieleklassikers, in der der Spieler die Geister steuert und Pac Man so in die Enge treibt.

Image »Anti Street Fighter«: Lassen Sie zwei Friedensnobelpreisträger aufeinander los und lassen Sie die Spieler versuchen, der Konfrontation aus dem Weg zu gehen. Oder lassen Sie den User einen Schiedsrichter spielen, der versucht, zwischen den beiden Kämpfern zu vermitteln und den Streit zu schlichten.

Die Seite zu wechseln oder völlig andere Ziele zu verfolgen, ist sicherlich ein Spaß! Die Überlegung, wie lange dieser beim Spieler dann anhalten wird, führt zur nächsten Frage: Besticht das neu erfundene Spiel nur durch diese Idee? Und wie kann ich diese notfalls erweitern, damit das Prinzip nach drei Leveln nicht monoton wird und der Spielspaß schlagartig schwindet?

Womöglich klingt eine solche verkehrte Spielidee zu Beginn ganz logisch, doch dann kommen mitten in der Entstehung neue Fragen auf: Wie soll gesteuert werden? Setze ich die Gegner rundenbasiert oder in Echtzeit? Wie steuere ich die Figur, die sonst der Spieler übernimmt, kann ich die dafür erforderliche Künstliche Intelligenz (KI) überhaupt ausreichend simulieren?

Da Sie mit der Umkehr eines Spiels praktisch spielerisches Neuland betreten, gibt es dafür auch wenig Hilfe. Normalerweise gibt es für jede Programmiersprache und jedes Problem im World Wide Web Tutorials zu finden, weil irgendjemand schon einmal ein ähnliches Problem hatte und in einem Forum nach einem Lösungsweg dafür gesucht hat. Doch diese Hilfe wird Ihnen bei umgekehrten Spielkonzepten verwehrt bleiben, denn sonst gäbe es Ihr Spiel ja schon. Die Programmierarbeit könnte also sehr schnell ausufern und ungeahnte Dimensionen annehmen, bis Sie vielleicht irgendwann entnervt aufgeben (vielleicht ist das auch der Grund, warum es solche Spiele bislang nur wenig gibt).

Deswegen ist hier das Anfertigen eines ausführlichen Game-Design-Dokuments vor der ersten Zeile Code das A und O, um solche Probleme rechtzeitig erkennen zu können. Auch die Fertigung eines einfachen Prototyps mit den ersten Ideen zum Testen der Spielidee ist unvermeidbar. Mit diesem werden Sie schnell feststellen, ob Ihr Konzept überhaupt längerfristig Spaß machen kann oder nicht.

2.1.2.3 Erweiterung bekannter Spielkonzepte

Sicherlich nicht allzu innovativ, aber doch unterhaltsam kann die Erweiterung eines bekannten Spielkonzepts durch zusätzliche Elemente sein. Wie wäre es denn, wenn einen Jump’n’Run-Helden während des Spiels die Kraft verlässt, er womöglich sogar stark altert, deswegen im Verlauf des Spiels immer weniger hoch springen kann und andere Lösungsansätze benötigt, um eine höhere Platt-form zu erreichen?

Wie würde ein »Die Sims«-Spiel aufgebaut sein, bei dem ein Meteorit auf die Erde zurast und der Spieler nur noch eine Woche zu leben hat: Wie würden die Protagonisten reagieren, würde Chaos ausbrechen? Würde der Spieler all das in Kürze nachholen, was er bisher in seinem digitalen Leben verpasst hat? Und wenn der Meteorit dann doch die Erde um wenige Kilometer verpassen und der große Knall ausbleiben würde, wie würden die Menschen mit den Erlebnissen der letzten sieben Tage umgehen? Natürlich wären wir bei einem solchen Spielkonzept weit entfernt von Casual Games (und dafür ein ganz heftiges Stück tiefer im Bereich Kultur), die Produktion würde Jahre dauern, und außerdem wäre vor den kommerziellen Erfolg ein riesiges Fragezeichen zu setzen, aber mir geht es auch nur darum aufzuzeigen, dass bei Weitem noch nicht alle Spielideen umgesetzt wurden.

Image

Es geht bei der Erweiterung einer Spielidee um das Hinzufügen einer Situation, die man in einem Spiel nicht zwangsläufig erwarten würde. Erweitern kann man aber auch die Dimension, in der das Spielgeschehen stattfindet. »Tetris« in 3D gibt es schon, räumliches »Mine-sweeper« oder »Sudoku« könnte dem Spieler völlig neue Lösungskonzepte abverlangen. Davon gibt es als Desktopversionen im Internet zwar schon zahlreiche Gameplay-Experimente, die allerdings alle bislang mehr oder weniger gescheitert sind. Zumal die Dreidimensionalität einem Casual Game gerne seine Leichtigkeit nimmt und die Steuerung ebenfalls komplexer wird, was die typische Zielgruppe abstoßen könnte. Doch um einen 10×10×10 Blöcke großen »Mine-sweeper«-Quader in 3D lässt sich z.B. mit der Gyroskop-Steuerung prima herumnavigieren, die Blöcke, die in Ziffern die Anzahl der angrenzenden Bomben (0–26) enthalten, lassen sich dann mit einer einfachen Berührung entfernen bzw. aufdecken.

Weitere Elemente für eine Erweiterung von klassischen Spielideen könnten sein:

Image »Asteroids!« mit Schwerkraft

Image »Tetris« ohne Schwerkraft oder physikalisch komplett korrekt (mit Schwerpunkt, ohne freischwebende Steine etc.)

Image »Pac Man« oder »Sokoban« in einem dreidimensionalen Röhrensystem

Image »Tron« mit schwebenden Bicycles, im endlosen Innenraum einer Kugel, auf einem Möbiusband oder mit stufenloser Lenkmöglichkeit statt auf 90 Grad eingeschränkte Abbiegemöglichkeiten

Image »Super Mario World« im Nebel oder bei Nacht, so dass die Sicht stark eingeschränkt ist