Kleine Spiele entwickeln, die an sich Spaß machen
(abagames.github.io)- Kleine Spiele sind Spiele, die in weniger als 10 Minuten abgeschlossen sind und sich leicht im Browser spielen lassen; schon der kurze Entwicklungsprozess selbst kann kreative Freude bereiten
- Die Erfahrung mit mehr als 350 entwickelten Spielen, darunter 139 in einem Jahr, zeigt, dass kurze Entwicklungszyklen das Experimentieren mit Ideen und iteratives Lernen stark fördern
- Sie lassen sich im besten Fall in etwa 2 Stunden, bei Schwierigkeiten meist in rund 10 Stunden entwickeln; wer sich jedoch tief in Artwork vertieft, kann unbegrenzt viel Zeit investieren
- Kleine Spiele werden oft als Übung vor größeren Projekten betrachtet, doch gute kleine Spiele können unabhängig von ihrer Größe eigene Qualität und eigenen Reiz besitzen
- Das Ausdenken neuer Mechaniken, ihre Umsetzung im eigenen Stil und das Zeigen des Ergebnisses für andere werden zu einem wichtigen Teil der Freude an der Spieleentwicklung
Der schnelle Entwicklungsrhythmus von 10-Minuten-Spielen
- Das Small Games Manifesto definiert kleine Spiele als Spiele, die in höchstens 10 Minuten abgeschlossen sind und sich gut im Webbrowser spielen lassen
- Es wurden mehr als 350 Spiele nach diesem Maßstab erstellt, außerdem gibt es die Erfahrung, mit einem patternbasierten Produktionsansatz 139 Spiele in einem Jahr entwickelt zu haben
- Die Beispielspiele sind so gestaltet, dass sie direkt im Browser gespielt werden können
- Ein einfaches Spiel, bei dem rote Balken auf die gleiche Länge geschnitten werden
- Ein Spiel, bei dem man per Tap Seile durchtrennt, ohne dass sie den unteren Bildschirmrand berühren; es lässt sich auch auf Touch-Panel-Geräten wie Smartphones spielen
- Der Kern des Reizes liegt in der kurzen Entwicklungszeit
- Im schnellen Fall lässt sich ein Spiel in etwa 2 Stunden erstellen
- Selbst bei Schwierigkeiten ist es meist in rund 10 Stunden machbar
- Wenn man sich tief in Artwork vertieft, kann der Zeitaufwand unbegrenzt wachsen
- Die hier gemeinten kleinen Spiele ähneln Spielen, die aus Ansätzen wie Game A Week entstehen, bei denen jede Woche ein neues Spiel entwickelt wird
- Auch aus Entwicklersicht müssen sie innerhalb begrenzter Zeit entstehen und werden dadurch ganz natürlich klein
- Weil die Entwicklungszeit kurz ist, lassen sich viele Ideen leicht ausprobieren, und schon der Prozess, ungewöhnliche Spiele zu bauen und zu testen, wird zum Vergnügen
Wert jenseits der Generalprobe für große Spiele
- Kleine Spiele werden häufig als Vorbereitungsphase für größere, ausgefeiltere Spiele betrachtet
- Make and release lots of small games before making a big one warnt davor, dass man beim direkten Bau eines großen Spiels die Motivation verlieren oder nach Jahren Arbeit ein Ergebnis haben kann, das man nicht mehr sehen möchte
- Doch auch kleine Spiele haben ihren eigenen Reiz, und How To Make Good Small Games behandelt, dass es gute kleine Spiele gibt und wie man sie entwickelt
- Die 12 Gedanken in diesem Beitrag trennen Umfang und Qualität voneinander
- Die Qualität eines Spiels ist unabhängig von seinem Umfang; je größer ein Spiel ist, desto mehr Aspekte müssen beachtet werden und desto größer wird die Wahrscheinlichkeit des Scheiterns
- Qualität ist auch unabhängig von der emotionalen Bandbreite; so wie Kurzgeschichten und Romane unterschiedliche Erfolgsbedingungen haben, besitzen auch kleine Spiele eigene Maßstäbe
- Ein Spiel definiert seine Erfolgsbedingungen selbst, daher sollte man diese Bedingungen akzeptieren und danach bewerten, ob es gut oder schlecht ist
- Neue Charaktere oder Mechaniken sind allesamt Versprechen an die Spieler, und ein Spiel ist erfolgreich, wenn es diese Versprechen einlöst
- Je kleiner die Versprechen sind, desto leichter lassen sie sich erfüllen; drei Ideen zufriedenstellend weiterzuentwickeln ist einfacher als zehn oder hundert Ideen
- Versprechen müssen auf interessante und unterhaltsame Weise eingelöst werden, und in diesem Prozess zeigt sich der persönliche Stil
- Man sollte Versprechen nicht übererfüllen, sondern das Spiel im richtigen Moment beenden
- Auch der Formfaktor ist Teil des Versprechens eines Spiels; wenn man die den Spielern gezeigten Informationen reduziert und das Spiel sofort nach dem Start spielbar macht, verändern sich die Erwartungen
- Bevor man ein unfertiges Spiel unter Namen wie „Demo“ oder „Prologue“ veröffentlicht, sollte man prüfen, warum man es vor der Fertigstellung veröffentlichen will
- Ein Spiel über lange Zeit in mehrere Episoden aufzuteilen und zu veröffentlichen, ist fast nie eine gute Abkürzung
- Man muss sich keine Sorgen um Viralität machen; kleine, konkrete Ziele ziehen ein kleines, konkretes Publikum an
- Wenn man kontinuierlich Spiele entwickeln kann, die einen selbst zufriedenstellen und sich wirklich gut anfühlen, ist man bereits viel weiter als viele andere Spieleentwickler
Die Freude am Machen selbst
- Ergänzend dazu wird als 13. Gedanke „Have fun :)“ vorgeschlagen
- Es macht Spaß, sich neue Mechaniken auszudenken und sie mit dem eigenen Stil in ein Spiel zu integrieren
- Noch größere Zufriedenheit entsteht, wenn eine angemessene Zahl von Menschen das entwickelte Spiel erlebt und daran Freude hat
- Die Entwicklung kleiner Spiele verbessert nicht nur die Fähigkeiten in der Spieleentwicklung, sondern wird zu einer Erfahrung, in der man vielfältige Ideen entwickelt, ausprobiert und zwischen Freude und Enttäuschung wechselt
- Einschließlich des Moments, in dem man das Ergebnis anderen zeigt, bleibt das Erstellen kleiner Spiele eine Entwicklungsaktivität, die an sich Spaß macht
1 Kommentare
Hacker-News-Kommentare
Ich habe gelernt, dass Game Design und Game Development völlig unterschiedliche Dinge sind.
Es braucht Kreativität, um zu wissen, welche Mechaniken stimmig sind und Spieler fesseln; Entwicklung braucht gnadenlose Umsetzungskraft.
Deshalb halte ich es am Anfang für gut, bestehende Spiele fast 1:1 nachzubauen und nur kleine Variationen einzubauen. So kann man eine Technik richtig beherrschen lernen, bevor man zum nächsten Schritt übergeht.
Eine freie Platzierungsvariante eines Spiels, an dem ich kürzlich gearbeitet habe: https://li-quoridor.vercel.app/ ist noch in Arbeit.
Design muss iterativ verbessert werden, und dafür braucht man Entwicklung. Nur sehr wenige professionell produzierte Spiele erscheinen genauso, wie sie ursprünglich konzipiert wurden, und selbst fast fertige Versionen werden nicht selten verworfen, weil sie einfach zu wenig Spaß machen.
Wenn das Ziel aber Game Design ist, sollte man Spielmechaniken zunächst als Papierprototyp bauen.
Die meisten rundenbasierten Spiele kann man auf einem Tisch testen, nur mit Dingen, die man zu Hause hat, und mit Regeln dafür, wie sich die Mitspieler bewegen sollen.
Bei Spielen mit vielen Berechnungen, wie RPGs, kann man ein kleines Rechner-Skript auf einem Laptop laufen lassen, damit man nicht an Mathematik hängen bleibt, die die Spieler tatsächlich gar nicht erleben. Trotzdem ist ein „Rechner-Skript“ viel einfacher als eine Game Engine.
Reflexbasierte Videospiele sind schwieriger zu prototypisieren, lassen sich aber über Analogien zu Spielen mit physischer Bewegung testen. Zum Beispiel kann man das Design eines neuen FPS als Live-Rollenspiel-Regelvariante auf Paintball, Airsoft oder Lasertag aufsetzen und ausprobieren.
Bei Plattform- oder Adventure-Spielen, in denen der Spieler-Avatar übermenschlich ist, sind die Mechaniken schwer direkt zu testen, aber man kann Papier-Schablonen wie Kreise für den Bedrohungsradius von Angriffen erstellen. Etwa indem man mit Lego, besonders mit Technics mit beweglichen Teilen, physische Dioramen baut und mit Papier-Schablonen prüft, ob ein Kurs zumindest machbar ist.
Anders als die vorherigen Strategien sagt diese Methode nicht unbedingt, ob das Spiel Spaß macht, aber sie ist nützlich, um bestehende Spielideen iterativ zu verbessern, ohne jede neue Idee programmieren zu müssen.
Fast unmöglich ohne tatsächliche Programmierung zu prototypisieren sind sehr künstlerische Spiele, die Licht, Spiegel, optische Täuschungen usw. auf eine Weise behandeln, die nicht zur Physik der realen Welt passt. So etwas sollte man besser nicht als erstes Spiel entwerfen wollen.
Game Design ist der Prozess, den Bauplan eines Spiels zu erstellen, während Game Development bedeutet, das Spiel tatsächlich zu bauen. Und Game Design ist deutlich schwieriger, als man erwartet.
Vor ein paar Jahren habe ich https://learnopengl.com/ durchgearbeitet, und das war sehr interessant, aber wenn man produktiv sein will, sollte man wohl eine bestehende Engine verwenden.
Gibt es Bücher oder Tutorials, die für jemanden mit Programmiererfahrung, aber ganz ohne Wissen über Game Development oder Design geeignet sind?
Es ist faszinierend, wie dramatisch sich allein dadurch Strategie und Spielstil verändern können. Ich habe einen Wordle-Ableger gebaut, der viel mehr Nutzer angezogen hat, als ich erwartet hatte: https://www.polygonle.com
Das Modell, Spiele schnell zu bauen, ist ziemlich spannend.
Zu Beginn der Pandemie habe ich ein paar Spiele gemacht, jedes davon hat vermutlich etwa 30 Minuten gedauert. Meine kleinen Kinder waren am Prozess beteiligt, indem sie zum Beispiel ausgesucht haben, welche Unicode-Emojis verwendet werden sollen, und sie haben die Spiele viel länger gespielt, als die Entwicklung gedauert hat.
Sie sind nicht so ausgereift wie das Spiel im eingereichten Artikel, aber sie haben den Kindern geholfen, Maus und Tastatur kennenzulernen.
Ich empfehle auf jeden Fall, es selbst auszuprobieren. Es macht Spaß.
https://alexsci.com/games/ Funktioniert nur bei bestimmten Bildschirmgrößen, manche brauchen eine Tastatur, und es gibt keine Anleitung.
Mein inzwischen 8-jähriger Sohn bittet mich immer noch gelegentlich, das „Spiel“ zu öffnen, bei dem er Emojis auswählt und eine Zahl eingibt, und dann werden entsprechend viele davon auf dem Bildschirm angezeigt.
Es ist kein „spaßiges“ Spiel, aber dass Papa es gebaut hat und er selbst an der Funktionsweise beteiligt war, ist für Kinder riesig.
Vom selben Autor gibt es noch einen weiteren interessanten Beitrag, „Joy of small game development“, der hier diskutiert wurde: https://news.ycombinator.com/item?id=37799387
Gestern wurde ein Spiel dieses Autors namens 1D pacman mit über 1.700 Punkten populär; man findet es hier: https://news.ycombinator.com/item?id=38845510
Das scheint ein ziemlich guter Beleg dafür zu sein, dass diese Person wirklich weiß, wovon sie spricht.
Ich habe viel Rust gelernt, indem ich mit Bevy ein Spiel gebaut und alles dokumentiert habe, was ich dabei gelernt habe: https://taintedcoders.com/
Je kleiner das Spiel ist, desto größer ist die Chance, es bis zum Ende fertigzustellen. Meist habe ich zuerst die Bewegung so gebaut, dass sie sich spaßig anfühlt, und dann spielartige Konzepte darum herum ergänzt.
Wenn man allein arbeitet, empfehle ich außerdem sehr, erst einmal Simulationen statt Spiele zu bauen. Es macht wirklich Spaß, etwas zum Leben erwachen zu sehen. Bei jeder neuen Engine Boids zu bauen, ist eine hervorragende Übung.
Nur anhand des Artikels sieht man es vielleicht nicht sofort, aber alle Spiele des Autors sind hier spielbar:
[1] http://www.asahi-net.or.jp/~cs8k-cyu/
Außerdem gibt es eine Seite, auf der die Spiele nach enthaltenen Spielmechaniken aufgeteilt und geordnet sind; persönlich finde ich diese noch interessanter.
[2] https://abagames.github.io/action-mini-game-mechanic-tags/index.html
Kleine Spiele machen wirklich Spaß
Tatsächlich war mein Pandemie-Projekt ein kleines Spiel zu bauen. Ich beschloss, dass endlich die Zeit gekommen war, solche Dinge auszuprobieren.
Am Ende baute ich zuerst ein Tool zum Zerschneiden und Annotieren von Tilemaps: https://tmt.computerpho.be/, und nutzte es dann, um einen minimalen Städte-Simulator für den Browser zu bauen: https://pc.computerpho.be/.
Diese Arbeiten waren zugleich Experimente damit, einzelne Datei-„Apps“ für den Browser zu bauen, was ebenfalls Spaß gemacht hat.
Über die Feiertage habe ich mit dem Playdate SDK(https://sdk.play.date) herumgespielt, und es eignet sich wirklich gut für kleine Spiele, wie der Autor sie beschreibt.
Die Einschränkungen durch den kleinen 1-Bit-Bildschirm und die etwa 150-MHz-CPU begrenzen stark, was man tun kann, aber gerade das wirkt ziemlich befreiend. Weniger Analyseparalyse, mehr Umsetzen.
Im selben Geist sehenswert: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
Ich liebe die Idee, Spiele zu bauen, und genau das hat mich zum Programmieren gebracht.
Es gibt kaum etwas Schöneres, als ein paar Tage lang mit SDL2 herumzuhacken und wie verrückt Dinge zu bauen. Die Zeit mit den Tutorials von lazy foo gehört zu meinen besten Erinnerungen.
https://lazyfoo.net/
Seit ich meinen Job gekündigt habe, baue ich ein Spiel und habe gerade eine der schönsten Zeiten meines Lebens.
Früher fühlte sich Spieleentwicklung für mich enorm einschüchternd an, aber vor einiger Zeit wurde mir klar, dass man alles zu einer Spielmechanik machen kann. Es gibt keine Regeln. Wenn überhaupt, dann nur die Regel, dass es Spaß machen sollte.
Vor ein paar Monaten habe ich Baldurs Gate 3 gespielt und wurde stark inspiriert. Ich habe lange RPGs gespielt, aber nie ein echtes „TTRPG“ ausprobiert; als Kind habe ich vor allem JRPGs gespielt. DnD kannte ich zwar, aber ich wollte es nicht wirklich im echten Leben ausprobieren, und irgendwie wirkte es auf mich „nicht so toll“.
Doch als ich BG3 spielte, verstand ich wirklich, was „RPG“ bedeutet. Dieses Spiel hat für mich alles richtig gemacht.