Ich habe mir selbst immer die Fragen gestellt, wie Spieleentwicklung funktioniert, was man dafür können muss und vor allem, wo fängt man an. Ich habe immer wieder versucht einen Einstiegspunkt zu finden, habe einige Versuche unternommen aber nie wirklich den Zugang gefunden. Ohne Anhaltspunkte ist das aber schwer und selbst Google hat mich da nicht schlauer gemacht. Dank meines Studiums habe ich mittlerweile die nötige Übersicht und möchte mit der Artikelserie “Einstieg in die Spieleentwicklung” ein bisschen Klarheit schaffen und die nötigen Einstiegspunkte für Interessierte aufzeigen.
Aller Anfang ist schwer
Bevor es so weit ist, muss man sich klar werden wie und womit ein Spiel entsteht. Früher haben ein paar Leute einige Zeilen Code produziert und fertig war das Spiel, heute ist die Game-Branche eine Multimillionen-Dollar-Industrie und liegt mit ihren Umsätzen weit vor dem Film und Musikgeschäft. Spiele entstehen mithilfe einer Vielzahl an Tools und an den mehrjährigen Entstehungsprozessen sind unzählige Menschen beteiligt.
Das soll aber nicht heißen, dass man alleine oder in kleinen Teams keine Spiele mehr entwickeln kann. Man muss zu Beginn eine wichtige Frage beantworten können: Bin ich eher der Grafiker und möchte Welten und Charaktere zeichnen und modellieren oder möchte ich lieber die Spielmechanik entwickeln.
Die Artikelserie kümmert sich um diejenigen die sich für zweiteres entschieden haben. Bevor man sich näher mit der Spieleentwicklung auseinandersetzt muss man sich im klaren sein dass man das nötige Wissen nicht von heute auf morgen erwirbt. Mein erster und vermutlich wichtigster Rat: lernt programmieren. Möchte man sich ernsthaft mit der Spieleentwicklung befassen kommt man nicht darum herum. Es macht wirklich wenig Sinn sich auf irgendwelche Tools oder Engines zu stürzen, wenn man nicht zumindest über die Grundlagen der Programmierung befasst.
Was muss man können?
Für diejenigen die noch gar nicht programmieren können empfehle ich: befasst euch mit den Grundlagen, die sind sprachunabhängig. Was die Wahl der Sprache angeht mit der man am Besten beginnt, da gehen die Meinungen auseinander. Ich selbst bin mit Java direkt in die Welt der Objektorientierung eingestiegen. Der Umstieg auf andere Sprachen, vor allem C und C++, ist mir daher eher schwer gefallen. Mein Tipp, beginnt mit C, dort lernt man die Grundlagen am Besten. In den Hochsprachen wie Java und C# wir einem viel Arbeit abgenommen. Auch bei den meisten Informatikstudien wird mit C begonnen. Danach kann man relativ leicht andere Sprachen lernen.
Natürlich kann jeder für sich entscheiden welche Sprache ihm am geeignetsten scheint. Man muss auch nicht gleich umsteigen wenn man schon mit einer anderen Sprache vertraut ist. Zur besseren Übersicht noch eine kleine Erklärung der einzelnen Sprachen in Bezug auf die Spieleentwicklung.
Java: Ja man kann Spiele mit Java erstellen (z.B. Minecraft) aber Java ist was PC und Konsolenspiele angeht nicht wirklich verbreitet. Java eignet sich aber hervorragend für Mobile-Games, vor allem auf Android-Geräten.
C# ist Java sehr ähnlich und der Umstieg ist nicht sehr schwierig. C# findet sich bei einigen Engines als Skriptsprache wieder (Unity 3D) und bietet mit XNA ein eigenes Framework für 2D und 3D Spieleentwicklung. XNA bzw. Das Microsoft GameStudio für Visual Studio erlaubt Spiele für den PC und die XBox Konsolen zu entwickeln. Auf dem PC hat sich XNA zwar nicht durchgesetzt (Terraria ist das bekannteste XNA Beispiel) aber für Microsofts Konsolen ist es die einzige Möglichkeit der Spieleentwicklung. Allerdings gibt es unter Windows 8 keine Unterstützung mehr für XNA. Das heißt, man ist auf Windows 7 und Visual Studio 2010 angewiesen. Wie die Spieleentwiklung für Windows 8 Apps und die kommende XBox Generation aussieht ist noch nicht bekannt.
C++ ist die Sprache in der Spieleentwicklung und man wird kaum um sie herum kommen. Zum einen basieren viele Skriptsprachen auf C zum anderen sind die meisten Engines für PC Spiele in C++ geschrieben. Auch die Entwicklung für Playstation und Nintendos Konsolen läuft über C++. Das heißt natürlich nicht, dass man nicht auch ein PC Spiel in einer anderen Sprache entwickeln kann.
Die Grundbedingungen wären geklärt. In den folgenden Artikeln geht es dann um die verschiedenen Einstiegsmöglichkeiten.
Hallo…ich bin weder Programmierer oder selber aktiver Gamer. Habe aber eine spannende Story für ein browserbasiertes Game entwickelt. Wie gehe ich am besten vor, um Programmierer zu finden, die mit mir ins Risiko gehen wollen (Indy) ?
Besten Dank für die Tipps…
Alexander
Hallo Alexander,
Wenns international sein darf, kannst du auf Indie-Plattformen wie itch.io im Forum dein Projekt vorstellen und nach Unterstützung suchen.
Wenns nationaler sein soll, dann gibts teilweise im Internet nationale Indie-Seiten, es gibt auf Facebook Spieleentwickler-Gruppen und auf Spielemessen gibt es auch oft Indie-Bereiche wo sich die Leute treffen. Auch auf Reddit findet man einen Indie-Bereich. Die eine Anlaufstelle gibts leider nicht. Da ist meist viel Networking notwendig. Also am besten ein paar Indie-Foren raussuchen, schauen wie aktiv die Leute dort sind und dann dort das Projekt vorstellen.
Grüße
Andreas
Ich bin auch eher der OOP-Typ, angefangen mit HTML/PHP/Javascript, später auch Java, mittlerweile C#…
C++ ist da schon wirklich schwer, besonders einen Einstiegspunkt zu finden. Es geht ja auch nicht um die Methoden/Klassen, sondern eher um den Kerngedanken dahinter.
Ich möchte ein 3D-Spiel entwickeln, das steht fest. Anfänger, die aber noch nie mit diesem Thema in Berührung kamen ist das ganze schon sehr schwer zu verstehen, insbesondere die unzähligen Engines.
Unity hört sich zwar super an, für mich aber ein No-Go. Denn: Alles wird in Szenen gemacht, jede Szene besitzt seinen eigenen Code. Man kann hier schlecht einen Einstiegspunkt nutzen, um komplexe Ideen umzusetzen. Klar, es gibt zwar sogenannte Hooks, aber das ist nur Augenwischerei, denke ich. MonoGame ist da schon anders. Hier erhält man direkt die grundlegende Basis des Spiels. Man kann direkt von Anfang an selbst entscheiden, ob zum Beispiel die Szene direkt aufgerufen wird oder ob man erst etwas machen möchte (Verbindung zum Server, whatever). MonoGame allerdings ist ziemlich nervenaufreibend, weil hier eben einfach ein eigenes Tool für den Content (Texturen, Grafiken, o.ä.) verwendet wird.
Dann gibt es noch das Thema mit Shader: Welche Versionen muss ich benutzen? Was muss ich dabei beachten?
Bei den meisten Engines “nervt” mich allerdings: Alles arbeitet mit Szenen. Wo ist da der Kerngedanke? Den verstehe ich nicht.
Klar, was eine Szene ist, ist bekannt. Aber warum braucht man vom Game unzählige Szenen? Wenn man eine Terrain-Map haben möchte, wo man herumlaufen kann ist es nur eine einzige Szene. Ich möchte kein Menü, ich will keine Gebäude zum betreten haben, ich will eine 3D-Map, wo man herumfliegen kann. Wofür der Sinn dahinter steckt, verstehe ich zum Beispiel nicht. Nahezu alle Engines haben halt das Thema “Szenen”, aber dafür habe ich persönlich keinen Nutzen. Kann man da vielleicht einmal drauf eingehen?
Hallo Adrian,
Grundsätzlich muss man unterscheiden was man programmieren möchte und das musst du dich auch fragen. Der eine versteht unter Spieleprogrammierung Gameobjekte zum Leben zu erwecken, sie miteinander interagieren zu lassen, also die Gamelogic, und in weiterer folge dann das eigentliche Spiel zu programmieren. Letzteres kann man im Code direkt machen, oder wenn man eine Engine nutzt, dann meist über die Scripting-Schnittstelle der Engine (entweder über eine Scriptsprache oder mit einer OOP-Programmiersprache).
Andere verstehen unter Spieleprogrammieren das Programmieren von Teilen einer Engine oder sogar einer ganzen Engine, also Rendering, Assets laden, etc. Wieder andere verstehen darunter eine Mischung aus beiden.
Unity ist eine Engine, d.h. es ist schon alles da, was man für ein Game braucht (und teilweise auch mehr). Das heißt, man muss sich nicht mehr um die Basismodule wie Rendering, Sound, etc. sowie andere Elemente kümmern, die ein Spiel braucht (Game-Loop). Ich verstehe nur nicht ganz, was dich an Szenen stört. Das Konzept ist weit verbreitet und das nicht grundlos. Wenn du nur eine 3D-Map haben möchtest, dann hast du eben nur eine Szene in deinem Spiel. Unity (und andere Engines) können für Projekte unterschiedlicher Größe eingesetzt werden, natürlich findet man da auch Elemente, die man in kleinen Projekten nicht braucht.
Und mit Unity lassen sich sehr wohl komplexe Ideen umsetzen, sieh dir Games an, die mit Unity gemacht wurden (z.B. Gwent, Thronebreaker: The Witcher Tales, Pathfinder: Kingmaker). Man muss nur wissen wie. Die Hooks der Game-Loop nutzt du nur, um den Code im Hintergrund aufzurufen. Es hindert dich aber niemand daran komplexe Klassenhierarchien damit umzusetzen. Das Problem ist hier, dass die meisten Unity-Tutorials nur relativ einfache Skripte erstellen und meist Jaavscript verwenden. Wenn sie schon C# verwenden, dann aber auch nur als Skriptsprache. Tutorials, in denen C# als vollwertige Programmiersprache verwendet wird, sind schwerer zu finden. Sollte dir das nicht reichen, besteht immer noch die Möglichkeit den Source-Code der Engine zu ändern. Bei Unity weiß ich nicht wie da der aktuelle Stand der Lizenz ist und ob man den Source-Code bekommt, bei der Unreal-Engine sollte er dabei sein. Es gibt auch kleinere Engines die einen offenen Source-Code haben.
MonoGame ist eher ein Game-Framework. Es beinhaltet alle Basiskomponenten wie Rendering, Sound, Asset-Loading und eine rudimentäre Game-Loop. Alles andere muss man sich selbst entwickeln oder auf Plugins zurückgreifen.
Was die Shader angeht: Wenn du eine Engine oder ein Framework benutzt, musst du dir darüber eigentlich keine Gedanken machen. Wenn dich Shaderprogrammierung interessiert, besteht aber die Möglichkeit für Unity und andere Engines eigene Shader zu verwenden. Oder du willst deine eigene Renderengine schreiben da musst du dann selbst die Shader schreiben.
Du musst dir überlegen was du selbst machen möchtest und was du lieber als fertige Lösung verwendest. Gerade als Anfänger kann es zu viel sein, alles selbst zu machen.
Ich hoffe ich konnte dir etwas weiterhelfen.
Grüße
Andreas
Der Kerngedanke bei Szenen ist das Aufteilen des Spiels in Unterteile, um letztendlich zuv erringern wie viel vom Spiel zu jedem gegebenen Zeitpunkt im Speicher geladen ist, mit dem “Preis” von Ladebildschirmen während die Szene gewechselt wird. Im falle eines Open-World spiels wäre ein (kleines) Beispiel: Warum muss die Open World geladen sein, wä hrend man noch im Hauptmenü + Submenüs ist? Warum muss das Hauptmenü als Game Object irgendwo noch im Speicher liegen, wenn man im Hauptspiel ist? Ein Pause-Menü ist deutlich abgespeckter.
Anstatt also in einer einzigen Szene die für das Hauptmenü nötigen Game Objects zu erstellen, und dann zu löschen wenn das Spiel geladen wird, baut man eine Hauptmenü-Szene und eine Hauptspiel-szene, und das Laden & Entladen passiert automatisch beim Wechseln der Szene. Im Falle eines Hauptmenüs ist der Gewinn natürlich eher klein (wenn man nicht gerade eine 3D-World als Hintergrund für das Menü nutzt), aber a) gerade auf resourcen-beschränkteren Systemen zählt jedes Bisschen, b) läppert es sich wirklich zusammen, wie viel man mit ein wenig Kreativität auslagern kann. In einem Skyrim-Artigen game wäre es z.b. möglich, sämtliches Crafting & Inventar-Management in eine eigene Szene zu verlegen so dass alle Animationen, High-Fidelity-Modelle der Items (für closeups im Inventar) und Texturen nur dann geladen sein müssen, während das Inventar offen ist.
Eine Weitereintwicklung ist das Trennen vom “eine einzige Szene umfasst das gesamte Game” Ansatz, zugunsten des Zusammenstellens von Szenen/Leveln aus mehreren Subszenen/Subleveln (terminologie unterscheidet sich zwischen Engines). So werden sie erheblich zum Resourcen-Management benutzt:
Die Beleuchtung in ein Sublevel zu rendern ermöglicht, zu gleichbleibender Geometrie Beleuchtung von variabler Qualität hinzuzuladen, je nach dem wie es die Leistungscharakteristik des Systems verlangt (Memory-Auslastung, z.b.), oder die Beleuchtung komplett auszutauschen für z.b. eine andere Tageszeit in der gleichen Umgebung. Unreal bietet ausserdem eine auf Subleveln basierende Lösung zum Streaming naheliegender Umgebungen für nahtlose große Welten, so dass du nicht deine gesamte Open World zugleich in den RAM werfen musst. Ich glaube, Unity hat ein ähnliches System, auch wenn ich mir die noch nie angesehen habe. Sollte dein Spiel selbstgeschriebenes LoD nutzen, können auch da Subszenen genutzt werden um mehr oder weniger komplexe Geometrie/Modelle zu laden.
Sehr cooler Artikel, werde mir die anderen auch noch reinziehen! Ich hatte ja mit Javascript und Phaser.io die ersten Gehversuche in der Spieleprogrammierung gemacht, habe diesen Artikel dazu gefunden: http://programmierenanfangen.de/spiele-programmieren-lernen/