Topic outline

  • Willkommensbereich

    Collapse all Expand all
    • Bild Beschreibung

      Arbeiten mit GB Studio

      Willkommen im Selbstlernkurs zur Game Engine 'GB Studio'. In diesem Kurs können Sie im 'eLM Game' die Arbeit der Abteilung 'eLearning.Medien' spielerisch kennenlernen. Im Kurs wird das Spieleprojekt samt Rohdaten komplett zur Verfügung gestellt. Mit dem Projekt und weiteren Infos zum Thema Games, Gamedesign und Game Making, können Sie sich hier eigenständig in die Themen einarbeiten, oder das Material in Ihrem Seminar oder Projekt verwenden für Ihre eigenen Spielideen.

      Dieser Kurs wird im Rahmen des Digital Learning Labs bereitgestellt. Bei Interesse an diesem und anderen Angeboten, wenden Sie sich gerne an folgende Adresse:

      BITS | eLearning.Medien

      Team Medienpraxis

      making.media.space@uni-bielefeld.de

      Zurück zum DLL-Portal

    • Was ist GB Studio?

      GB Studio ist eine leicht zugängliche Game Engine, mit der man auch ohne Vorkenntnis in der Programmierung eigene Spiele erstellen kann. Die Engine bietet die Möglichkeit per Drag and Drop Szenen und Spielmechaniken zu erstellen. Für fortgeschrittene Nutzer*innen ist aber auch die Möglichkeit gegeben über Plugins per C oder Assembly zu coden.


      Die Spiele können sowohl für den Webbrowser, als auch für originale Game Boy Hardware und Game Boy-Emulatoren exportiert werden.

      Link zur Engine

    • Etherpad Lite icon
      Feedback Etherpad Lite

      In dieses Etherpad kann Feedback eingefügt werden. Der Kurs soll durch Feedback der Nutzenden wachsen und an deren Bedürfnisse angepasst werden:

      • Welche Informationen wünsche ich mir?

      • Welche Ressourcen brauche ich?

      • Was sollte tiefergehend behandelt werden?

      • Etc.

  • Kursstruktur

    • Dieser Kurs bietet folgende Möglichkeiten:

      • Das eLM Game im Browser spielen

      • Das eLM Game-Projekt gebündelt herunterladen. Es ist die Projektdatei für GB Studio und alle Grafiken als Rohdateien enthalten. Hiermit kann man sich direkt in das Projekt einarbeiten und dadurch die Funktionsweise der Engine kennenlernen und sich in spezifische Problemlösungen einarbeiten. Das Projekt wurde mit einer älteren Version der Engine erstellt. Ggf. muss es für die neuste Version umgewandelt werden. Ebenfalls kann es nun bessere/effizientere Lösungen für Probleme geben.

      • Eine Einführung in die Konzeptionsphase von Spielen. Hier werden einige Stichpunkte aufgeführt, die dabei helfen sollen, eine Blaupause für das eigene Spiel zu erstellen. Im Idealfall hat man vorher das eLM Game oder andere in GB Studio erstellte Spiele gespielt, um die Materie besser greifen zu können.

      • Ein Leitfaden für den gesamten Produktionsprozess von einem Spiel. Die drei hier aufgeführten Phasen sollen dabei helfen, zu verstehen, wie man sich effizient zum fertigen Projekt hinarbeitet.

      • Ein Plan für eine mögliche Produktionspipeline, wie sie sich für die Erstellung eines Spiels in GB Studio eignet. Hier gibt es auch ein paar Einblicke in den Ablauf der Entwicklung des eLM Games.

      • Verlinkungen zu Tools, die in der Produktionspipeline verwendet wurden.

      • Ein paar Hinweise zu Best Practices, die dabei helfen sollen, Anfänger*innenfehler und Stolperfallen zu vermeiden.

      • Wer sich tiefer in die Engine und Gamemaking einarbeiten will, findet hier einige Hilfreiche Anlaufstellen und Tutorials, ebenso wie Bücherempfehlungen.

  • eLM Game

    • Hier kann das GB Studio-Spiel im Browser gespielt werden.

      eLM Game





  • eLM Game Projektdateien

    • In diesem Bereich werden alle im Rahmen des Projekt erstellten Dateien bereitgestellt. Sie können das GB Studio-Projekt und die Grafiken nutzen, um sich tiefer einzuarbeiten und um eigene Szenen zu erstellen bzw. zu verändern.

      Der Sinn ist es, sich selbstständig die Scripte des Spiels anzuschauen, um zu verstehen, wie Probleme gelöst werden können für spezifische Fälle. Indem man sich mit der Materie des Spiels beschäftigt, lernt man die Engine und ihre Funktionen besser zu verstehen.

      eLM Game Projektdateien

  • Konzeption - Game Design

    In der Konzeptionsphase soll man grob umreißen, worum es im Spiel gehen soll. Hauptelemente sind hier Story, Spielmechaniken und Genre. Für den Anfang reichen hier oft auch Stichpunkte und Notizen, mithilfe derer man sich organisiert und die einzelnen Elemente dann im Produktionsprozess zusammenführt. Man kann hier aber auch bereits feste Entscheidungen für Stil von Story, Grafik, usw. treffen. Dies kann aber auch dazu führen, dass man sich zu früh Restriktionen setzt, die die Gestaltung erschweren. Oft ändert sich die Ausrichtung während des Designprozesses auch wieder.

    • GB Studio eignet sich dafür Stories auf einer mehreren Ebenen zu vermitteln: Visuell, textuell, auditiv und durch Interaktivität. Dementsprechend sollte man all diese Elemente mitdenken, wenn man die Geschichte, die man erzählen will, ausgestaltet. Für die Konzeptionsphase eignen sich generell alle Methoden, die sich für Brainstorming, Produktivität und Organisation eignen, also z.B. White- oder Kanban-Boards.

      • Anfang und Ende: Man sollte mindestens eine Idee vom groben Ablauf der Geschichte haben, wie in sie eingeführt ist, und wo sie endet. Es muss klar gerahmt werden, worum es im Spiel geht und was die Ziele und Aufgaben sind.

      • Innerhalb der Rahmung kann man dann kleinschrittiger einzelne Elemente ausarbeiten: Charakter, Quests, Gegenstände, die Teil der Story sind oder eigene (Sub-)Stories darstellen. Diese Elemente sollte man dann jeweils definieren, um sich einen Überblick über die Inhalte zu schaffen, die dann in die Story eingebunden werden müssen.

      • Wenn man Story und Inhalte geplant und z.B. auf einem Whiteboard gesammelt hat, kann man noch parallel auf einem Moodboard Inspiration sammeln: Grafiken, Soundschnipsel, Musik usw. Dies soll dabei helfen sich stilistisch festzulegen und man bekommt oft neue Ideen dafür, wie man gewisse Elemente umsetzt.

      Spielmechaniken können je nach Spielziel variieren. So kann es auch sehr abstrakte Spiele, wie z.B. Tetris geben, in denen es keine Story gibt, bzw. diese nicht direkt ersichtlich ist. Oftmals sind Mechaniken aber mit der Story verbunden. Das heißt, dass man Teile der Story auch in interaktiven Elementen verpacken kann. Hier wird eher auf formallogischer und technischer Ebene geplant und verwirklicht.

      • Spielmechaniken können so einfache Sachen wie Konditionen sein: Eine Tür lässt sich erst öffnen, wenn man einen Schlüssel findet, ein Charakter gibt andere Dialoge aus, wenn man gewisse Bedingungen erfüllt, usw.

      • Spielmechaniken werden durch Gameplay Loops beschrieben. Diese können weitumfassend sein, aber auch klein. Oft sind Loops ineinander eingebettet, z.B. so:

      - Story Loop: Die gesamte Story des Spiels von Anfang bis Ende kann als größter Gameplay Loop gesehen werden.

      - Innerhalb des Story Loops kann es dann kleinere geben, sowohl für kleine Stories als auch rein technische Dinge, wie der Ablauf eines Minispiels. Hier plant man dann tiefergehend den Ablauf eines einzelnen, aber auch die Verbindung zu anderen Loops. Z.B. Vorbedingungen, um ein Minispiel spielen zu können, was passiert nach Beendigung, was passiert, wenn man gewinnt/verliert, usw.

      - Gameplay Loops: Hier muss man sich Regeln und Ziele ausdenken für das jeweilige Spiel: Wie wird das Spiel gespielt, wie gewinnt/verliert man, wie wird es initiiert/neu gestartet.

      • Auch für Spielmechaniken eignen sich White- und Moodboards. Hier kann man z.B. die Spiellogik visualisieren oder andere Game Boy-Spiele als Inspiration einbinden.

      Das Genre und die visuelle Aufmachung für das Spiel sollte auch grob bedacht werden, da es die Planung von Story und Mechaniken mit beeinflusst.

      • Auf Storyseite kann das Genre bestimmen, wie, und in welcher Form, erzählt wird. Eine Horrorstory kann sich vom Schreibstil her sehr von z.B. einer Komödie unterscheiden. Nicht alles muss durch Text direkt erzählt werden, man hat auch viele Möglichkeiten über Grafiken und Ton Inhalte zu vermitteln. Man sollte nur eine Gewisse Balance halten und priorisieren, wo Inhalte mit bestimmter Wichtigkeit genutzt werden. Je weiter man vom reinen Text abweicht, desto Abstrakter wird die Erzählweise, was auch dazu führen kann, dass man die Geschichte schwerer greifen kann.

      • Die Wahl des Genres kann auch bestimmen wie und welche Mechaniken umgesetzt werden. GB Studio bietet für jede Szene auch ein Dropdown-Menü, in dem gewissen Funktionen der Szene gesetzt werden können. Für actionreiche Spiele eignen sich z.B. „Shoot Em‘ Up“ und „Platformer“, da diese schon einige Funktionen und eine spezifische Steuerung mitbringen, wodurch man sich ggf. eigene Programmierarbeit erspart.

      • Grafiken sind durch Story und Genre bzw. Mechaniken bedingt. Auf Ebene der Story geht es rein darum, wie die Geschichte wirkt, und wie Inhalte vermittelt werden. Auf Ebene der Mechaniken, geht es eher um pragmatische Fragen: Die Größe von z.B. Charakteren kann unterschiedlich sein (16*16; 32*32; usw.). Projektile, Hindernisse und andere Objekte sollten auch immer im Verhältnis stehen zum Spielercharakter, wie er im Spiel erscheint. Größenverhältnisse sollten immer zueinander passen und nicht vermischt werden.

  • (Pre-)Production

    Game Design ist generell iterativ. Für die Produktionsphasen bedeutet dies, dass Konzeption, Pre-production, Production und Post-Production mehr oder weniger fließend ineinander übergehen. Dies gilt sowohl auf Ebene des ganzen Spiels, als auch für einzelne Inhalte, wie Grafiken, Spielmechaniken, Story, usw. Nach der Konzeptionsphase werden Elemente zuerst in der Pre-production erstellt, dann in der Produktionsphase als Prototyp umgesetzt, getestet, evaluiert und verändert. So würde man für ein Minispiel z.B. erst Grafiken und Logik konzeptionieren. Diese werden dann entworfen und in der Engine als spielbarer Prototyp umgesetzt. Dieser wird dann getestet und evaluiert. In der Testphase tauchen oft Probleme auf oder man wünscht sich noch andere Funktionen oder ein anderes Aussehen. Hier geht man quasi wieder in die Pre-production zurück und wiederholt diesen Prozess, bis das Element zufriedenstellend ist und so im Spiel bleiben kann.

    • Die Pre-Production ist die Phase nach der Konzeption. Hier werden die Ideen auf Grundlage der Konzeptionsphase festgelegt. Man erstellt erste Grafiken und andere Inhalte, wie Charaktere, Objekte, Texte, Sounds, Musik usw. Stellenweise kann hier auch noch Platzhaltern gearbeitet werden, wenn Grafiken noch nicht vollends ausgereift sind. Insbesondere bei Minispielen kann hier noch solchen gearbeitet werden, da hier die Funktionalität im Vordergrund steht.

      In dieser Phase wird eine erste, zweite, dritte, usw. Version des Spiels erstellt. Man produziert Räume, Szenen, Mechaniken, usw. Es geht darum eine nutzbare Version des Spiels zu erhalten. Die Kernfunktionen sollen hier schon enthalten sein. Dies ist meist die Hauptphase von iterativem Game Design.

      In der Testphase wird der erstellte getestet und bewertet: Funktionieren die Mechaniken, wie geplant? Macht es Spaß? Ist alles kohärent? Ist für die spielende Person verständlich, was getan werden soll? Auf Grundlage der Ergebnisse der Tests geht man nun wieder zurück in die Produktionsphase und verbessert Grafiken und Mechaniken, bis man zum finalen Produkt gelangt.

  • Produktionspipeline in GB Studio

    Hier wird exemplarisch der Produktionsablauf des eLM-Games beschrieben umrissen. Man kann sich das Ganze als Orientierungshilfe nehmen, man sollte sich aber auch nicht zu strikt daran halten, da jede Spieleproduktion letztendlich sehr individuell ist. Produktivitätssoftware eignet sich generell für jedes Projekt, spezifischer Programme, wie z.B. für Grafik, Sound usw., sind immer abhängig von den Bedarfen, die sich aus dem Projekt ergeben.

    • Beispiel Whiteboards Planung Spielverlauf

      Diagramm Spielablauf mit Story und Mechaniken Diagramm Spielablauf mit Story und Mechaniken

      Beispiel Moodboard und Kanban

      Kanban mit Aufgaben Moodboard mit Designideen

    • Mit dem Whiteboard und dem Kanban, kann man sich die Konzeptionsphase immer gut vor Augen halten. Danach kommt es drauf an, was man nun machen: Texte, Grafiken, Szenen, usw.

      • Texte können z.B. in einem einfachen Worddokument geplant und später an die richtige Stelle im Spiel eingesetzt werden. Der weg ins Spiel ist also Kurz.

      • Grafiken werden im Grafikprogramm der Wahl erstellt. Hier muss man auf die richtige Farbpalette und Größe achten. Für mehr Freiheit arbeitet man mit einer Rohdatei. Diese wird nach Fertigstellung dann nach .PNG exportiert und in den jeweiligen Ordner des Projekts gepackt: Charakter nach 'sprites', Hintergründe nach 'backgrounds' usw. Danach können diese Hintergründe in Szenen eingefügt werden Charakter und Objekte dann als Akteure in der jeweiligen Szene.

      • Hintergründe aus Tilesets: Wenn man Tilesets erstellt hat (im Grafikprogramm), um die Hintergründe für Szenen zu erstellen, macht man dies in Tiled. Hier wird das Tileset importiert und die Hintergründe werden quasi aus den grafischen Einzelteilen zusammengebaut. Tile bietet die Möglichkeiten die Grafiken auch so anzuordnen, dass sie eine Karte ergeben, wie sie im Spiel verbunden sein soll - dies hilft bei der Orientierung. Die einzelnen Räume können dann als .PNG exportiert und im Ordner 'backgrounds' im Projekt eingefügt werden. Danach bindet man die Hintergründe in Szenen an und befüllt diese mit Inhalten.

  • Tools für die Pipeline

    • Es gibt eine Menge Tools, die man nutzen kann, um Assets für sein Spiel zu erstellen, oder den Workflow zu verbessern. Hier sind die Tools aufgeführt, die für das eLM-Game verwendet wurden und eine Liste von weiteren Tools für viele der Bedarfe, die im Laufe von Game Design-Prozessen entstehen. Bitte jeweils eigenständig die Copyright-Bedingungen prüfen und richtig anwenden - insbesondere bei den Assets.

      • Für dieses Projekt wurden 'Tiled' und 'Aseprite' genutzt, um Grafiken zu erstellen und in das Spiel einzubinden. Für die Verarbeitung von Grafiken eignen sich aber generell alle Grafik-Programme, die pixelbasiert arbeiten.

      • Als kostenfreie Alternative für 'Aseprite' eignet sich Libsprite dies kann ebenfalls die Aseprite-Rohdateien verarbeiten.

      Für White- und Moodboards eignen sich von der Universität Bielefeld unterstütze Plattformen:

      Zoom

      Taskcards

      Zugang und Informationen zu TaskCards erhalten sie hier.

      • Eine große Auswahl an weiteren Hilfen und Anwendungen für das Erstellen von Grafiken, Sound usw. Hier gibt es auch einige vorgefertigte Assets aus der Community: https://gbstudiocentral.com/resources/

      • Insbesondere die Cheat Sheet ist hilfreich, um wichtige Formate und Anforderungen im Blick zu haben.

      • Wer noch mehr Assets braucht, findet auf itch eine Menge. Einige sind gratis, andere Kosten. Bitte jeweils Lizenzbedingungen beachten: https://itch.io/game-assets/tag-gb-studio

  • Best Practices

    Hier ist eine Auflistung an Aspekten, die man beachten sollte, wenn man sein Projekt plant. Das Vorwissen soll helfen, gewisse Stolperfallen zu vermeiden und Zeit zu sparen.

    • Man sollte sich zuerst eine solide Grundlage schaffen in der Konzeptionsphase schaffen. Zwar nimmt das Gestalten von z.B. Whiteboards viel Zeit in Anspruch, aber man spart dadurch wertvolle Zeit in den Produktionsphasen. Genauso sollte man die Möglichkeiten und Limitationen der Engine kennen. Dies erreicht man z.B. durchs spielen anderer Spiele, die in der Engine gemacht wurden, oder dadurch das man selbst mit den Funktionen der Engine herumprobiert. Je besser man die Materie versteht und je ausgefeilter das Konzept ist, desto weniger Zeit muss man auf Neuplanung anwenden.

      Die Engine hat Grenzen innerhalb derer man arbeiten muss, wenn man Mechaniken und Grafiken erstellt oder plant. Die Dokumentation der Engine gibt einen guten Überblick über z.B. Maße und Farben.

      - Der Game Boy hat eine limitierte Farbpalette von 4 Farben. Sprites können maximal 3 Farben + Transparenz haben.

      - Hintergründe können nur eine bestimmte Anzahl einzigartigen Tiles (8*8 Pixel-Felder) haben.

      - Konsistenz ist wichtig, wenn man Grafiken erstellt. Ein Spiel, dessen Stil einheitlich ist, wirkt besser.

      - Grafiken auf dem Game Boy sind klein. Hochkomplexe Zeichnungen sollten heruntergebrochen und abstrahiert werden. Meist eignen sich für Charakter und Objekte Maße von 16*16 oder 32*32 Pixel.

      - Der Game Boy hat eine begrenzte Rechenpower, somit kann nicht zu viel gleichzeitig auf dem Bildschirm passieren. Zu viele Charakter und Animationen auf einmal werden zu Fehlern in der Darstellung führen. Oftmals kann man visuelle Elemente in den Hintergrund der Szene verlagern.

      Ein Prototyp muss nicht gut aussehen oder perfekt funktionieren. Für Grafiken, wie z.B. Charakter reichen für den Anfang auch Skizzen und Platzhalter. Für Mechaniken reichen Grundfunktionen, wie Initiierung und Ablauf. Es geht anfangs immer darum, schnell testen und bewerten zu können, ob etwas funktioniert oder wie es wirkt. Sobald die Grundlage sich solide anfühlt, kann man auf der Grundlage von Feedbacks aus den Testphase weiter auf das Endprodukt hinarbeiten. Ein Shoot Em‘ Up kann z.B. am Anfang einfach aus schnell gezeichneten Formen bestehen, um die Mechaniken zu testen. Sobald diese sich gut anfühlen, ändert man die Grafiken.

      Anstatt den Hintergrund jeder Szene neu zu zeichnen, kann man über Tilesets arbeiten. Hier zeichnet man Objekte, die über mehrere Szenen verteilt genutzt werden können. Für Innenräume wären das z.B. Regale, Türe, Wände, Fußböden usw. Man arrangiert diese in einer großen Grafik in der Richtigen Größe (ausgerichtet an 8*8 Pixel für GB Studio) und puzzelt danach in Programmen wie ‚Tiled‘ die einzelnen Räume zusammen. Umgekehrt ist es aber auch Möglich eine Szene zu zeichnen, und diese dann als Tileset aufzubereiten.

      Es lohnt sich, ausreichend viele Testphasen einzuplanen. Einzelne Spielmechaniken und Szenen zu testen hilft dabei, schnell Fehler zu finden. Testet man erst am Ende ein Prototyp oder das fertige Spiel, ist es oft schwer die Ursache einzelner Fehler nachzuverfolgen.

      Man sollte in regelmäßigen Abständen versionierte Backups erstellen. Kommt man an einen Punkt, wo Mechaniken absolut nicht reparierbar sind, kann man so auf eine frühere Version zurückgreifen, ohne den kompletten Fortschritt der Entwicklung zu verlieren.

      Ordnerstrukturen und klare Benennung helfen dabei, den Überblick zu behalten. Der Name einer Datei oder eines Scripts sollte klar darauf hinweisen, wofür es benutzt wird.

      Geduld und Resilienz sind wichtige Fähigkeiten, insbesondere wenn es um das Testen geht. Bugs sind oft unerklärlich und einfach ein Produkt der Eigenheit der jeweiligen Engine. Ein Problem zu lösen dauert oft lange und braucht viele Anläufe, bis man die Quelle des Problems findet.

  • Ressourcen

  • Bücherempfehlungen

    • Für diejenigen, die sich tiefer in die Materie des Game Designs einlesen wollen, ist hier eine kleine Auswahl an Büchern. Die Bücher sind in der Universitätsbibliothek der Universität verfügbar - teilweise auch als E-Books.

      • Anna Antrophy, Naomia Clark - A Game Design Vocabulary (Addison-Wesley)

      • Gunther Rehfeld - Game Design und Produktion (Hanser)

      • Tracy Fullerton - Game Design Workshop (Morgan Kaufmann)

      • D. S. Cohen, Sergio A. Bustamanae II - Producing Games (Focal Press)

      • Richard A. Bartle - Designing Virtual Worlds (New Riders)

  • Distribution

    • Das Digital Learning Lab bietet die Möglichkeit, eigens erstellte Projekte in unserem Projectboard zu teilen. Hier gibt es eine Auswahl an Projekten, die im Rahmen unseres Unterstützungsangebots entstanden sind. Die Projekte können so also innerhalb der Infrastruktur der Universität einem Publikum zur Verfügung gestellt werden.

      Alternativ können Spiele auch - nach Erstellung eines eigenen Accounts - auf itch.io im Browser gespielt werden.