spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Kürzlich wurde ich gefragt, ob ich ein paar Zusammenhänge und auch Begriffe in der Spieleentwicklung erklären könnte. Nun hatte ich den Gedanken, es könnte vielleicht von allgemeinem Interesse sein, bzw. für diejenigen die frisch mit der Spieleentwicklung anfangen möchten / kürzlich angefangen haben. Daher starte ich hier nun eine kleine Grundlagen Einführung. Beginnend mit den absolutesten Grund Infos.....

Wie schwierig/langwierig ist das alles?

Zuerst einmal die schlechte Nachricht: Am Spieleprogrammieren hängt so viel mehr als die Labertaschen in YouTube einem glauben machen wollen! Doch ich will keineswegs alle Hoffnung niedermachen. Im Gegenteil: Es geht mir nur darum, wegen total falscher Vorstellungen, eine große Enttäuschung, Frust und schnelles aufgeben, zu verhindern.
Stattdessen möchte ich ganz klar sagen: Es steckt zwar einiges darin, doch mit dem richtigen Ehrgeiz/willen, ist es absolut schaffbar!

Du hast ein großes Projekt vor und alle sagen dir „du spinnst doch, nicht zu schaffen!“ ?
Welche Leute sind das, die so etwas zu dir sagen? Haben die schon mal ein Spiel von vorne bis hinten fertig programmiert? Wenn nicht (egal ob diese Person es noch nie versucht hat oder es zwar versuchte aber nach paar Wochen oder mittendrin aufgegeben hat): gibt nicht zu viel auf die Worte dieser Person!
Die allermeisten Menschen, gehen nicht einmal einem Hobby wirklich ehrgeizig nach. Und noch viel weniger Menschen haben den echten Wunsch oder könnten es sich wirklich vorstellen, eine Sache länger als 4 Wochen zielstrebig zu verfolgen. Und nochmals viel weniger Menschen, haben den Wunsch (oder könnten es sich vorstellen) dass sie sich wirklich daran machen ein (zumindest kleines) Spiel zu programmieren.
Du bist (sonst hättest du den Weg hierher nicht gefunden und nicht so viel Text gelesen) offensichtlich ganz anders als diese allermeisten Menschen. Also warum solltest du auf diese Menschen hören, die offensichtlich ganz anders drauf sind als du und ganz andere Vorstellungen/Wünsche haben als du?

Versuche ein wirklich kleines Spiel zu erstellen. Von Anfang bis Ende. Ein Mini Spiel, aber eines mit allem Drum und Dran was so ein Spiel braucht. Aber was ohne Multiplayer. Ein Tetris, Space Invaders oder Moorhuhn Klon. Je nachdem wieviel Zeit du pro Tag/Woche zur Verfügung hast und wie eilig du es hast, dauert das zwischen vielleicht 2 Wochen und 6 Wochen.
Dann hast du den ganzen Prozess gesehen. Hast jede Baustelle mal selber durch gemacht und alle Unbekannten (welche dir jetzt vielleicht noch Angst machen) haben sich in Klarheit aufgelöst.
Du lernst so viel dabei! Und danach brauch dir keiner mehr was erzählen! Du kannst dann selber einschätzen, wie groß ein Projekt sein darf, das DU dir zutraust und wie lange DU so ungefähr meinst das es dauert.
Optimalerweise machst du dann erst einmal noch ein 2. Spiel. Eines das etwas größer ist als das 1. Mini Spiel. Aber noch immer klein genug das du es in ca. 2 oder 3 Monaten fertig bekommen kannst.
Dadurch sammelst du nochmals viel Erfahrung. Und wenn du dann immer noch Lust hast auf was viel Größeres… dann weist du selber wovon du sprichst und was du dir vor nimmst ??



Ein Wort noch zur „Größe des Spiels“.
Wenn wir von Größe sprechen, ist wohl eigentlich gemeint: Wie viel Arbeit es macht und wie kompliziert es ist.

Nun diese Größe hängt nicht an der Spielerzahl, oder wie Welt bekannt das Vorbild ist, von dem man einen Klon machen will. Sondern Dinge die es kompliziert und Aufwendig machen sind ganz besonders:

- Hat es Internet Multiplayer? Wenn ja, ist es eher ein ganz kleiner Multiplayer mit vielleicht 8 oder 16 Spielern (Counterstrike Klone) oder viel mehr Spieler? Sind immer ALLE Spieler gleichzeitig im selben Level/Szene? -> Wenn die Spieler gleichzeitig sich auf verschiedene Szenen/Level verteilen können (Online Rollenspiel, bei dem aber nicht ALLE Spieler immer am gleichen Ort in einer einzigen Gruppe sind), dann wird es echt kompliziert und aufwändig! Dazu solltest du schon viel Erfahrung im Spielprogrammieren gesammelt haben und kannst dann leider mit mehreren Jahren Entwicklungszeit rechnen.

- Braucht es sehr viele verschiedene 3D Modelle die benötigt werden? oder spielt es eher auf einer Einsamen Insel oder nur im Wald?

- Braucht es ein Dialog-System für ganze Gesprächsbäume mit verschiedenen Entscheidungsmöglichkeiten etc.?

- Nicht nur Dialoge mit viel Text, sondern es soll euch noch in mehreren Sprachen sein?

- Braucht es ein Quest-System / Quest Tagebuch? Oder ist es eher Linear und der Spieler bekommt immer fest vorgegeben eine Aufgabe nach der anderen?

- Ist es Open World?

- Ist es Rollenspiel?



In diesem Sinne: Ein Online RPG für nur 4 Spieler, ist kein kleines oder Mittelgroßes Spiel, sondern schon ein recht großes Spiel… auch wenn es nur für 4 Spieler ist.
Und ja: Dadurch das es nicht nur Singleplayer ist für einen einzigen Spieler, sondern Multiplayer (2 Spieler oder mehr), wird der Aufwand (die benötigte Zeit) um ungefähr 70% mehr! …. Also aus einem Spiel das als Singleplayer 10 Wochen (oder 100 Wochen) brauchen würde, wird ein Spiel für das du ca. 17 Wochen (oder 170 Wochen) brauchen wirst, nur weil du das Spiel von Singleplayer erweiterst auf „2 bis 4 Spieler Internet-Multiplayer“.

Wobei ich in diesem Zusammenhang „Internet Multiplayer“ meinte.
Netzwerk Multiplayer wären ein gutes Stück einfacher.
Und Hot-Seat Multiplayer (alle Spieler sitzen vor dem gleichen Rechner und teilen sich Maus/Tastatur) sind nur noch wenig mehr Arbeit als ein reiner Singleplayer.

Was braucht ein Spiel damit es Spaß macht und der Spieler weiter spielen will?

Dies ist schon so grundlegend, dass sich kaum darüber Gedanken gemacht wird und dadurch oft entscheidende Dinge vollkommen vernachlässigt werden. Doch es braucht ein paar sehr wenige, aber wichtige Zutaten. Diese Zutaten sind auch je nach Spiel Genre, unterschiedlich stark ausgeprägt. Dennoch, damit ein Spiel fesselt und Spaß macht, sollte jedes dieser nachfolgenden Dinge zumindest ein wenig vorkommen! Ein vollkommenes fehlen eines davon lässt sich dabei NICHT kompensieren. Es wird dann den Spielern zwangsläufig recht schnell die Lust vergehen!
Jedoch schwach ausgeprägte Zutaten, lassen sich sehr gut ausgleichen in dem eine der anderen Zutaten, um so deutlicher und intensiver beigemischt wird. Das Spiel wird halt dadurch einfach nur entsprechend den ein oder anderen Typ Mensch/Spieler ansprechen ;-) … fehlen sollte nichts davon, doch die Mischung ist reine Geschmackssache.


- Unbekanntes zu Entdecken -> Je nach Genre kann auch schon ein Minimum ausreichen. Bei Tetris oder einem Autorennspiel reicht schon ein „Wenn ich die Runde erneut starte, vielleicht habe ich dann mehr Glück mit den zufällig generierten Steinen/Hindernissen/Leveln/Gegner-Typen …. Bis hin zu einem Rollenspiel welches eine interessante Story bietet und Geheimnisse hat die der Spieler mit dem voranschreiten des Spiels, herausfinden kann.
Kurz gesagt, es geht darum, die Neugierde des Spielers anzusprechen. Nicht nur einmal, sondern immer wieder und wieder im Spiel. Ihm das Gefühl zu geben „da gibt es noch was zu entdecken was ich noch nicht 1000x gesehen habe“. Fehlt dies, dann wird sich der Spieler bald langweilen.

- Einflussmöglichkeiten -> Ohne, bzw. wenn diese viel zu wenig vorkommen, dann wird der Spieler frustriert und enttäuscht sein. Frustriert, weil er das Gefühl hat, seine Handlungen würden eh nichts bringen. Und enttäuscht, weil er nicht so etwas wie einen Film zum bloßen konsumieren, sondern ein Game erwartet hat, bei dem er sich austoben kann (unbewusst möchte der Spieler aus seiner Passivität herausgeholt werden, und minimalst seinen Bewegungsdrang ausleben).

- Herausforderung -> Je nach Genre reicht das Spektrum von „Stein drehen links/rechts (Tetris)“, bis Rollenspiel-Herausforderungen und schwierigste Geschicklichkeitsspiele. Doch immer gilt: Es darf nicht zu leicht sein und es muss auch fair und schaffbar sein!
Die Einflussmöglichkeiten dürfen sich nicht nur darauf beschränken auf z.B „Weg A oder B?“… sondern es muss vom Spieler verlangen zu überlegen welche Entscheidung besser ist… und der Spieler muss bei einer schlechten Entscheidung, auch „unschöne“ Konsequenzen erleben können. Ohne die real existierende Möglichkeit des Scheiterns, ist auch ein „Ha! Geschaft!“ nichts wert ;-) … ist es viel zu leicht, dann existiert praktisch diese Möglichkeit zu scheitern auch nicht mehr. Doch erst durch das Gefühl, er habe eine Sache gut gelöst, wird es den Spieler auch befriedigen (das Gefühl von Zufriedenheit auslösen). Daher muss dem Spieler auch gezeigt werden, was das Ergebnis ist…. Im einfachsten Fall durch einen Punktestand.… oder bei RPG z.B. wie sich der Verlauf der Geschichte durch seine Tat verändert hat.

- Erlebnis der Sinne -> Es ist ganz banal. Die Sinne des Spielers müssen gereizt werden. Ganz besonders Augen und Ohren, aber auch Feinmotorik (Bewegungsdrang, ich habe es schonmal angesprochen). Optimalerweise auch in dem, der Sinn nach Ästhetik zugleich befriedigt wird.
Nette Hintergrundmusik und Geräusche… paar nette kleine Grafikeffekte (funkeln, Farben) …. Und mit etwas Glück wenn es den Geschmack des Spielers gut erwischt, wird der Spieler alleine schon deswegen gerne wieder das Spiel weiter spielen wollen.



Es gibt noch weitere Punkte, durch die ein Spiel das Erlebnis für den Spieler erzeugen kann. Diese weiteren sind jedoch sehr Genre abhängig und daher eher „optional je nach Genre“. Die oben genannten hingegen, sollten keinesfalls fehlen!

Klar, dies alles ist irgendwie selbstverständlich, und das weiß man doch! Wo liegt nun die großartige Erkenntnis? … sorry, gibt’s nicht! …. Achte einfach darauf, diese Punkte im Hinterkopf zu behalten, damit nichts Wichtiges fehlt an deinem Spiel und deswegen den Spielern es nicht richtig spaß machen will, ohne das sie in Worte fassen könnten woran es liegt.
Bei Storylastigen Spielen oder RPG Artigen Quests, kann es sich übrigens seeehr lohnen, mal in das Konzept der „Heldenreise“ rein zu schnuppern und die Idee des MDA-Framework sich durchzulesen (wenn jemand eine gute DEUTSCHE Quelle dazu findet, wäre ich auch sehr dankbar dafür!).

Was braucht ein Spiel, damit es überhaupt ein vollständiges Spiel wird?

- Eine Aufgabenstellung / Ziel des Spiels. Der Spieler sollte zu jeder Zeit, eine Idee haben was er als nächstes tun kann/soll. Las ihn nicht ahnungslos im Regen stehen.

- Die Regeln nach denen das Spiel abläuft. Optimalerweise sind die Regeln nicht beschrieben, sondern das Spiel ist (nach SEINER Physik und Logik) in sich konsequent und fair. So dass der Spieler von alleine mit testen und Probieren, recht schnell und einfach raus bekommt wie die Mechaniken des Spiels funktionieren.

- Eine Anzeige des aktuellen Geschehens, auf deren Grundlage der Spieler seine Entscheidungen bestimmen soll.

- Eine Steuerungsmöglichkeit / Eingaben des Spielers so verarbeiten, dass er sich nicht wie „gefesselt“ fühlt oder ihm schwindlig wird weil z.B. „nach links“ dazu führt das die Kamera sich nach rechts dreht. Sondern er seinen „Wunsch“ dem Spiel möglichst einfach mitteilen kann, und das Spiel dann auch das tut was er wollte.

- Eine Endanzeige oder sonst wie geartete Darstellung des Ergebnisses, wie gut/schlecht sich der Spieler geschlagen hat.



Das wäre es. Mehr (aber auch nicht weniger) braucht es, und du hast ein Spiel. Sind die Regeln fair und kann der Spieler das Ergebnis vor allem durch sein eigenes Geschick steuern und ist nicht zu sehr vom Glück/Zufall abhängig. Dann wird es wahrscheinlich auch Spaß machen.

Doch da fehlt natürlich noch etwas. So einfach lässt sich ein Spieler nicht ködern.

- Hintergrundmusik, Töne, Grafiken, Animationen …. Zur Unterhaltung, Befriedigung der Sinne. Eigentlich das ganz offensichtliche. Daran denkt man sofort (und oft auch als ein einziges). Obwohl dies genau genommen, am ehesten noch weggelassen werden könnte und man hätte trotzdem noch ein vollständiges Spiel. Es ist fast also, nur das schmückende Beiwerk zum eigentlichen Spiel. Aber natürlich ist dies auch irgendwie der wichtigste Punkt. Denn dies ist es, was den Spieler in Stimmung versetzt, die Gefühle, das Wohlbefinden etc. anspricht. … dies ist es, mit dem das Spiel Werbung um sich selber macht, und den Spieler versucht in diese Spielwelt zu verführen.
Die Herausforderungen liegen auf der Hand… und deswegen wird sich der nachfolgende Rest nun um dieses Thema drehen!

Welche Software, bzw. was brauche ich?

Eine Handvoll ;-) … aber die gibt es alle Kostenlos (bzw. gibt es inzwischen auch immer kostenlose und gute Alternativen).


- Das eigentliche Programm mit dem du das Spiel erstellt. Das ist nicht die Programmiersprache! Sondern die „Game Engine“. GODOT, Unreal und Unity sind deine Freunde. Aber triff deine Entscheidung nicht leichtfertig, sie hat sehr großen Einfluss darauf, wie schwer du dir tun wirst speziell zu deiner Spiel Idee, und welche Möglichkeiten du später hast wenn du „mehr willst“.


- Ein 2D Grafikprogramm. Bei einem 3D game wäre dies zwar nicht ein absolutes MUSS. Doch spätestens wenn du deine Texturen ein bisschen individueller haben willst, wäre ein Grafikprogramm ganz nützlich. Photoshop und Krita wären da eine Anlaufstelle.

- Ein 3D Modelling Programm. Für ein 2D Game natürlich eher uninteressant. Doch bei einem 2.5D oder 3D game, ziemliches muss. Klar, du würdest auch ganz ohne auskommen. Wärst aber dann immer abhängig von dem was du so im Netz an 3D Modellen findest. Blender wäre hier ein guter Freund
Ansonsten, es gibt diverse Asset Stores, in denen es haufenweise 3D Modelle zu recht guten preisen zu kaufen gibt.

- Falls du Musikalisch /Soundmäßig hohe Ansprüche hast, wirst du vermutlich auch Sounds selber machen wollen. In dem Fall kennst du garantiert bessere Programme als ich. Für einen Tip wäre ich hier dankbar ?? … ansonsten, Sounds und Hintergrundmusik gibt es recht vieles, auch kostenlos und mit Freier Lizenz und in bester Qualität.



Womöglich vermisst du nun hier was zur Programmiersprache …. Doch diese, ergibt sich aus der Game-Engine. Die Frage ist also vor allem: Welche Game-Engine passt am besten zu dir, deinen (langfristigen-)Zielen und zu deinem Spiel?


Übrigens, Bücher sind eine echte Alternative zu YouTube klar, YouTube konsumiert sich leicht… aber aus einem guten Buch zu der Game-Engine deiner Wahl, oder allgemeine Einsteigerfreundliche Bücher zum Spieledesign oder zur Programmiersprache, können viel besser Wissen vermitteln, als diese mehr oder weniger losen YouTube Videos, die einfach nicht WIRKLICH aufeinander aufbauen, und oft sehr Lückenhaft sind.

Viele komplizierte Begriffe

Wie jedes Fachthema, bedient sich auch die ganze Spielentwicklung, verschiedenster Fachbegriffe. Als Einsteiger wird man förmlich davon erschlagen, teilweise verängstigt und tut sich sehr schwer… daher mal eine Erklärung der wichtigsten Begriffe und wie diese Dinge zusammen hängen.


Game-Engine
Ursprünglich bezeichnete dies einmal, einfach nur den Programmcode den ein Spieleentwickler erstellt hat, um leichter die absoluten Grunddinge eines Spiels leichter handhaben zu können. Und da hierin so viel Arbeit steckte, ohne das am eigentlichen Spiel gearbeitet wurde. Versuchten die Entwickler diesen Programmcode wiederverwendbar zu machen. Inzwischen enthalten die Game-Engines viel mehr. Sie sind zu einer halbwegs allumfassenden Spiele-Entwicklungsumgebung geworden (inkl. Programmierumgebung/Programmiersprache) und enthalten vorgefertigte Komponenten und Bausteine, für viele der typischen Arbeiten die beim Spieleprogrammieren anfallen. Dabei müssen diese Engines den schmalen Weg beschreiten zwischen „möglichst viel Arbeit für den Spieleentwickler vereinfachen“ und „möglichst vielseitig, um unterschiedlichste Arten von Spielen zu ermöglichen“. Doch nicht allen Engines gelingt dieser Kompromiss gleich gut.
Daher ist die Frage nach „mit welcher Engine mache ich mein Spiel?“ viel entscheidender (bzw. übergreifender) als die Frage „mit welcher Programmiersprache?“.


2D / 3D / 2.5D
Die ersten beiden sollten ziemlich klar sein.
Zu 2D läst sich noch sagen, üblicherweise ist damit ein Spiel gemeint das ohne 3DModelle abläuft, sondern bei dem alles (auch die Spielfigur inkl. Animationen etc.) kleine Bilder sind. Es ähnelt also sehr der Zeichentrick Technik. Aufgrund der Grafik haben diese Spiele ihren ganz eigenen Charm und Style und dieser ist sehr beliebt –> Pixel-Art
3D braucht wohl kaum eine Erklärung. Einzig: Dank der inzwischen sehr mächtigen Game-Engines, sind 3D Spiele nicht mehr viel schwieriger zu programmieren als 2D Spiele (ein Grundsatz der sehr lange Zeit galt, inzwischen aber immer weniger gilt).
2.5D … Dies bezeichnet ein 3D Spiel, bei dem jedoch die Kamera fest genagelt wird wie bei einem 2D Spiel und entsprechend auch die Sicht fest von Oben oder von Vorne auf die Spielwelt gerichtet ist. Zusammen mit Shader, Kamera und Licht Einstellungen, wird der Style eines 2D Spiels nachgemacht. Dies hat den Vorteil, dass nicht alle Grafiken von Hand gemalt werden müssen, sondern Animierte 3D Modelle verwendet werden können.


Zusammenhang: Objekte, Oberflächen, Textur, Lichter und die Kamera
Objekte bestehen aus einer Grundform (Geometrische Form) und einem „darüber gezogenem“ Bild (die Textur), welches dem Objekt die Farben gibt. Im Einfachsten Fall, z.B. einem Butten den der Spieler drücken kann oder ein Sprite/Bild in einem 2D Game, ist dieses Objekt einfach nur eine Quadratische Fläche. Kompliziertere Objekte, bestehen aus vielen solcher Flächen (Polygone). Doch auch wenn diese Objekte durch die Textur nun Farben haben, gibt erst das Licht, dem Objekt auch wirklich sein Erscheinen. Ohne Licht bleibt das Objekt/die Fläche dunkel. Die Kamera sagt nun dem Spiel, wo das Auge des Spielers ist, von dem aus er die Spielwelt sieht. Aus Blickrichtung der Kamera (und „Objektiv Einstellung“ / FOV) wird dann letztlich das Bild für den Bildschirm erzeugt. Dieses erzeugen/berechnen der Bilder, wird als das „Rendern“ bezeichnet, und erfolgt durch Shader Programme die auf der Grafikkarte in Shader Einheiten ablaufen.


Spawnen / NPCs / Spiele KI
NPCs sind „nicht Player Character“. Also alle die Spielfiguren (egal ob Tier, Mensch, Elf etc.) die NICHT von einem Menschlichen Spieler gesteuert werden, sondern durch den Computer. Die durch menschliche Spieler gesteuerten Spielfiguren/Avatare sind die PC (Player Character).
Wenn neue NPC’s frisch erzeugt werden, also z.B. dem Spieler als Kanonenfutter vor die Füße geworfen werden, dann bezeichnet man dieses erzeugen als „spawnen“.
Die Spiele KI, ist übrigens mehr schein als sein ;-) Da Spiele sehr schnell laufen müssen, bleibt oft einfach nicht genug Rechenleistung übrig, um die KI Entscheidungen genau zu simulieren. Meist wird einfach nur ein sehr simples System programmiert. Beispiel: Laufe von A nach B nach C und dann wieder zurück und wenn du einen Player (PC) siehst, dann greife ihn an. … und fertig ist die KI der Wache.


Textur / Bild-Datei
Dies sind die Grundlegenden Grafiken des Spiels. Es sind Bilder/Fotos wie du sie von überall kennst. Doch Texturen enthalten die Bilddaten so gespeichert, wie sie eine Grafikkarte am schnellste/optimalsten verarbeiten kann.
Texturen werden in einem Grafik Programm erstellt (z.B. Photoshop oder Krita) und als ganz normale Bild Datei gespeichert (bei JPG möglichst wenig komprimieren!).
Das Bild wird sozusagen zur Textur, indem es in die Game-Engine importiert wird.


Sprites
Die vielen kleinen Bildchen aus denen die 2D Spiele bestehen, werden in Sprites eingebettet. Eigentlich enthalten Sprites nur flache Bilder/Texturen ;-). Doch Sprites sind für 2D optimiert und bieten zusätzliche Techniken/Funktionen welche die Typischen Arbeiten in einem 2D Spiel unterstützen und vereinfachen.


3D Mesh
Ein 3D Mesh (Netz) besteht aus vielen Eckpunkten und diese Eckpunkte werden verbunden zu Flächen und ergeben dadurch die Form (ohne Farbe/Textur/Bild) der Objekte und Spielfiguren in einem 3D Spiel bzw. 2.5D Spiel.
Solche 3D Meshes werden in einem 3D Programm erstellt (z.B. Blender).


Vertex / Vertices
Dies ist der Name der Eckpunkte in einem 3D Mesh.


Edge
Werden in einem 3D Mesh, zwei Vertex / Vertices / Eckpunkte miteinander verbunden, so ergibt es eine Kante. Der Name dieser Kante ist „Edge“


Polygon / Face / Triangle / Tri
Werden drei oder noch mehr Vertex / Vertices / Eckpunkte miteinander verbunden, so ergibt dies eine Fläche. Dies Flächen werden Face bzw. Polygon genannt.
Für die Grafikkarte ist es am optimalsten, wenn ein Face/Polygon aus ganz genau 3 Vertices besteht. Diese können bei weitem am schnellsten verarbeitet werden. Mit Polygon meint man bei der Spielentwicklung normalerweise deswegen ein Face mit 3 Eckpunkten. Manchmal werde diese auch Triangle oder Tri genannt.
Faces mit 4 Eckpunkten lassen sich schon aufwändiger berechnen, sind aber noch „erträglich“, daher „schlucken“ Game-Engines solche Daten auch noch.
3D Programme zum Erstellen von 3D Modellen, verwenden häufig aber auch Faces/Polygone mit mehr als 4 Ecken. Doch da diese noch viel langsamer zum berechnen (der Beleuchtung etc.) sind, wandeln die Game-Engines diese Daten beim Import normalerweise automatisch um in Polygone mit 3 Ecken.
Die Anzahl der Polygone in einem 3D Modell / Mesh, ist ganz unterschiedlich. Bei der Spieleentwicklung sollte sehr darauf geachtet werden, dass die Modelle nur die nötigste Anzahl an Polygone haben um so gut auszusehen wie gewünscht. Und nicht viel viel mehr als nötig. Denn die Anzahl der Polygone hat einen sehr großen Einfluss darauf, wie flüssig das Spiel später laufen wird.


3D Modell / 3D Objekt
3D Model und Mesh werden irgendwie in eine Schubblade geworfen. Und daran ist eigentlich auch nichts Falsches.
Doch mit 3D Modell meint man normalerweise eine 3D Mesh Datei + dazugehörige Textur Bild-Datei(en). Denn auch wenn beides zusammen erst das fertige Modell ergibt und wirklich nach was schönem aussieht, sind dies Daten voneinander getrennt. Es sind verschiedene Dateien.
Das Mesh ist der Rahmen eines Autos. Die Texturen sind die farbig lackierten Bleche. Beides zusammen ergibt ein schönes Auto (das 3D Modell).


Bones
Wenn man nun ein 3D Modell / Mesh hat, welches nicht einfach irgendein Ding darstellt, sondern etwas Lebendes, also ein Tier oder Mensch etc. So möchte man normalerweise auch dass sich z.B. die Arme und Beine bewegen lassen. Also man möchte Gelenke haben, die man dann in einer Animation auf natürliche Art bewegen kann. Genau diese Gelenke sind die Bones.
Bones befinden sich innerhalb des 3D Mesh. Und jeder Eckpunkt (Vertex / Vertices) hat nun eine Information, an welchen Bone er wie stark gebunden ist. So könnte z.B. ein Vertex im Gesicht, mit 40% Gewichtung an den Nacken/Hals Bone gebunden sein und mit 60% an den Kopf-Bone. Wird nun der Kopf bewegt, so würde dieser Vertex (und damit auch das entsprechende Polygon) zum Teil der Kopf Bewegung folgen, zum Teil aber auch sich nach dem Hals richten. Insgesamt ergibt dies also den Effekt der sich dehnenden Haut.
Bones gehören also zum 3D Modell und sind meist auch in der gleichen Datei enthalten. Doch nur die wenigsten Modelle / Mesh brauchen Bones. Sondern nur eben die, welche sich wie ein Lebewesen verformen und bewegen lassen sollen.


Skinned Mesh
Dies ist ein ganz normales 3D Mesh das sich auch ganz normal benutzen lässt, doch es hat zusätzliche Informationen.
Wenn bei einem 3D Mesh die Vertices / Eckpunkte, eine Gewichtung enthalten wie stark sie an Bones gebunden sind, dann wird es durch diese zusätzliche Information zu einem Skinned Mesh. Für dich macht das nicht wirklich einen Unterschied. Doch die Game-Engine wird dies automatisch berücksichtigen und die zusätzlichen Möglichkeiten des Skinned Mesh nutzen.


Animation
Dies bezeichnet so ziemlich alles was sich in einem Spiel, auf wiederkehrende Art bewegt. z.B. ein sich drehender Deckenventilator, eine sich öffnende Türe, und eben auch Bewegungen der Spielfigur, Tiere etc.
Und so vielfältig die Animationen sind, so unterschiedlich sind auch die Arten und Möglichkeiten wie sie in einem Spiel erstellt werden. Im allereinfachsten Fall kann dies eine einzige Programmzeile sein wie diese: transform.Rotate(0, 60*Time.deltaTime, 0);
Bis hin zu den wohl kompliziertesten Animationen: Natürliche Bewegungen eines Menschen, z.B. Lauf-Animation.
Diese zuletzt genannten Animationen, werden erstellt indem in einem 3D Programm (z.B. Blender) aus Bones die Gelenke nachgestellt werden, und dann diese Bones animiert/bewegt werden.
Diese Animation wird dann wieder in einer 3D-Datei gespeichert (kann zusammen mit dem 3D Mesh / Modell gespeichert werden, oder getrennt davon).


3D Datei
Dies ist ganz simpel die Datei, welche aus dem 3D Programm (z.B. Blender) heraus exportiert wird für die weitere Benutzung im Spiel.
Eine 3D Datei kann enthalten: Animationen, Bones, 3D Mesh (Polygone, Vertices etc.)
Diese Dinge können sowohl zusammen in einer Datei stecken als auch getrennt.
Die beiden verbreitetsten Formate sind FBX und OBJ. Wobei zunehmend FBX die Nase vorne hat, da es beim Austausch zwischen verschiedenen Programmen etwas weniger Probleme macht als OBJ. Allerdings, ganz egal welches Format, Probleme machen sie alle mehr oder weniger ;-)


Blit
Wenn die Grafikkarte einen ganzen Bildausschnitt von einer Textur in eine andere Textur kopiert (oder als Ziel, in die Bildschirm-Ausgabe) dann wird dieser Kopiervorgang, als Blit bezeichnet.
Ein „Blit“ ist extrem schnell!


Rendern
Wenn die Grafikkarte nicht einfach nur einen Bildausschnitt kopiert, sondern Pixel für Pixel irgendwelche Berechnungen macht (Beleuchtung, Farbe etc. bei 3D) dann wird der gesamte Vorgang als Rendern bezeichnet. Rendern ist also der Vorgang des „Berechnens und malen für die Ausgabe“


Shader
Das rendern/malen macht die Grafikkarte mit kleinen „Shader“ Programmen die direkt in der Grafikkarte ausgeführt werden. Diese kleinen Programme werden in speziellen Teilen des Grafikchips (den Shader Einheiten) ausgeführt. Wobei Spieleprogrammierer fast immer mit „Shader“, das kleine Programm meinen.
Diese Shader sind sehr vielseitig verwendbar und es lassen sich viele schöne spezielle Grafikeffekte mit ihnen machen. Aber auch für die ganz normale Darstellung von 3D Modellen, bestimmt der Shader ganz entscheidend, in welchem Style es dargestellt wird. So kann das gleiche 3D Modell eines Menschen, je nach Shader entweder recht realistisch aussehen, wie eine Comic Figur oder recht nahe an Pixel-Art herankommen.
Shader bestimmen auch, wie Schatten, oder Halb-Durchsichtige Objekte (z.B. Glasscheiben) berechnet und dargestellt werden.
Kurz gesagt, Shader bestimmen maßgeblich wie ein Spiel dargestellt wird, wie es wirkt und sie sind sehr wichtig.
Leider sind die Möglichkeiten eigene Shader zu erstellen bzw. die vorhandenen zu verändern, in den verschiedenen Game-Engines, auch sehr unterschiedlich. Es reicht von „ganz einfach und sehr mächtige/performante Möglichkeiten“, bis hin zu „nur schwer und mittels Operation am offenen Herz“.
Je nachdem welche Art von Spiel und welcher Grafikstiel angestrebt wird, können Shader für dich etwas ziemlich Unwichtiges sein mit denen du dich nie beschäftigen wirst, oder extrem wichtig werden.


NormalMap und BumpMap
Ein 3D Modell besteht aus dem Mesh (Polygone, Vertices, Edges) und der Textur (dem Bild welches als Haut über das Objekt drüber gezogen wird). Zusammen mit den Lichtern in der Spielwelt, berechnet nun der Shader, wie die Farben, Schatten, Glanzlichter usw. des Objekts aussehen.
Die Textur gibt dem Objekt die Farben und Struktur. So wird aus einer 5m x 5m großen Flachen Platte, und der Textur (Bild) von Pflastersteinen, etwas das aussieht wie eine Straße aus Pflastersteinen. Doch es bleibt eine Flache Platte. Nun könnte man natürlich mit sehr vielen Polygonen, im 3D Modell jeden Stein ausformen. Doch das würde die Polygonzahl extrem steigen lassen. Besonders wenn man dies mit allen möglichen Dingen macht (ein Wald voller Bäume, und die Rinde jedes Baums mittels Polygone eine Struktur geben). Es muss also eine andere Lösung her.
Und hier setzt die Idee der NormalMap und BumpMap an. Bei beiden handelt es sich um Bilder/Texturen. Und beide machen ziemlich das gleiche bzw. werden für die gleiche Idee benutzt. Und zwar sollen sie dem Shader zusätzliche Informationen darüber geben, wie die Struktur der Oberfläche ist.
NormalMap und BumpMap können entweder zusammen/gleichzeitig auf einem Objekt benutzt werden, oder nur eines davon. Meistens hängt es davon ab, was der Shader kann (manche Shader können keines davon, manche nur das eine, das andere oder beides) und ob man mit zu dem 3D Modell überhaupt eine NormalMap und/oder BumpMap hat.
Beides zusammen wirkt natürlich auch bisschen besser als nur eines davon, doch braucht auch mehr Rechenleistung. Meistens ist eines davon schon vollkommen ausreichend.
Die NormalMap erkennt man am komischen blau des Bildes. Die Farben geben Informationendarüber in welche Richtung die einzelnen Stellen des Bildes gedreht sind.
Die BumpMap ist ein weis/grau/schwarz Bild. Die Farben geben Information über die Höhenunterschiede in der Struktur.
Aus diesen Informationen, kann nun der Shader berechnen wie das Licht auf der Struktur, Schatten wirft bzw. Stellen die passend zum Licht stehen, heller erscheinen lassen. Dadurch wirkt ein Flaches Objekt, plötzlich viel realistischer und fast so als hätte es wirklich echte Struktur, Erhöhungen und Vertiefungen.


UV Map
Entgegen des Namens, handelt es sich hierbei nicht um ein Bild oder Textur. Und es ist auch keine eigenständige Datei. Doch es hat etwas mit der Textur des 3D Objekts zu tun ;-)
Die UV Map ist eine Karten Information. Ganz nach dem Vorbild der Landkarten oder wie beim Stadtplan. Die UV Map steckt im 3D Mesh. Während des erstellen des Modells im 3D Programm, wird dem Mesh diese UV Map Information mitgeteilt.
Und zwar sagt die UV Map, von wo die einzelnen Polygone, von der Textur ihr Bild beziehen sollen. Es ist sozusagen die Information „diese 15 Polygone welche den Mund der Figur formen, sollen von der Textur im oberen mittleren Bereich den Bildausschnitt verwenden, denn dort sind im Bild die Lippen abgebildet“.


3D Material
Alles Grafische in deinem Spiel, besteht nun also aus:
- 3D Mesh (selbst ein Sprit sind 2 Polygone, welche zusammen eine viereckige Fläche / Mesh ergeben.
- Textur (das Bild mit den eigentlichen Farben des Objekts)
- NormalMap und/oder BumpMap (evtl. falls vorhanden)
- Shader der aus diesen Dingen, die Farben, Licht etc. berechnet und somit ein schönes Objekt auf den Bildschirm malt.

Diese letzten 3 Dinge (Textur, Shader und evtl. NormalMap und BumpMap) werden nun zusammen gefasst. Wie ein Ordner in dem man alles zusammen packt. Und diese ergeben das Material. z.B. das Material „Weiser Marmor“.
Das ist nützlich, da sehr oft das gleiche Material, für verschiedene 3D Modelle verwendet wird. Stell dir vor du möchtest einen Raum mit Boden, Wände, Säulen und Decke, die alle aus dem gleichen Marmor bestehen sollen ;-)
Übrigens, diese Einstellungsmöglichkeiten welche du vielleicht bei dem Material findest für Glanzlicht, Rauheit/Glätte, Albedo Farbe usw…. dies sind die Einstellungen des ausgewählten Shaders. Hier siehst du unmittelbar, wie entscheidend der Shader ist für das Ergebnis wie die Grafik letztlich rüber kommt.


Physik Engine / Simulation
Zur Game-Engine gehört immer auch eine Physik Simulation. Je nach Engine und ggf. ob sie auf z.B. 2D spezialisiert ist etc. Ist die Physik Simulation mehr oder weniger stark ausgeprägt. Doch auch wenn diese meist sehr mächtig sind, bilden sie doch nur das ab, was wir alltäglich im normalen Leben so erleben. Also: Beschleunigung, Luftwiderstand, Gravitation und ggf. verbundene Dinge (Zahnräder, oder eine Stange welche etwas anderes anschieben). Dies alles erleichtert das Leben sehr! Dennoch, besondere Dinge, die wir in unserem Alltagsleben nicht deutlich erleben, werden nicht Simuliert und müssten per Hand selber programmiert werden.


Rigid Body
Die ganzen grafischen Objekte, sind erst einmal genau nur das: Grafische Objekte. Sie sind wie eine Illusion, Hologramme in der Luft. Damit sie sich wie feste Körper verhalten, also z.B. die Physik Engine durch die Gravitation, etwas nach unten zieht, braucht es noch die Information „Rigid Body“. Dies sagt der Spiele Engine: Dieses Objekt ist so und so schwer, und hat den Luftwiderstand einer Feder, und es soll von der Gravitation angezogen werden.


Collider / Trigger
Wie bereits beim Rigid Body geschrieben, sind diese grafischen Objekte, erst einmal nur einfach etwas Optisches… Illusionen. … oft ist dies erwünscht, ebenso oft aber, will man das diese Objekte auch feste Hindernisse werden. Also, dass sie, wenn sie sich berühren, voneinander abprallen. Hierzu gibt es die Collider. Sie dienen dazu, dass Kollisionen der Objekte auch erkannt werden.
Doch Collider können auch als Auslöser, also als Sensoren (Trigger) verwendet werden. z.B. ein Auslöser auf dem Boden, und wenn der Spieler darüber läuft, wird dies erkannt und 30m weiter entfernt werden neue Gegner erzeugt die dann Richtung Spieler laufen.


RayCast
Manchmal möchtest du in deinem Spiel wissen: „Wenn ich gedanklich eine Linie ziehe von hier nach dort, treffe ich dann auf ein Objekt/Hindernis?“ … z.B. für den Schuss aus einer Waffe … oder du möchtest testen, ob der Computer-gesteuerte-Gegner, eine freie Sicht zum Spieler hat und diesen sehen kann, oder nicht?
Genau dafür gibt es RayCasts (in verschiedenen Arten). Sie ermöglichen es, auf sehr einfache Art, genau solche Dinge zu prüfen ;-)


Physik Material
So wie das 3D Material Information darüber gibt wie ein Objekt optisch aussieht, gibt ein Physik Material darüber Informationen wie die Oberfläche des Objekts sich Physikalisch verhält.
Das Physik Material ist jedoch eine ganz einfache Sache
Zum einen, sind diese etwas was du zusätzlich nutzen kannst (und oft gar nicht brauchst). Zum anderen, vereinfacht gesagt, ist das Physik Material kaum mehr als ein Schieberegler für „so rau bzw. rutschig ist diese Oberfläche“.
Dies ist nützlich z.B. für einen Eis Boden, auf der jedes Objekt das darauf liegt und bewegt wird, ewig lange rutscht bevor es von alleine langsamer wird und stehen bleibt. Oder eine Gummiartige Oberfläche, auf der alles praktisch unmittelbar abgebremst wird.


Partikel System
Zur Game-Engine gehört auch ein Partikel System. Größere Objekte, aus festen Körpern, lassen sich ziemlich gut durch 2D oder 3D Objekte, Flächen und Textur darstellen. Doch neben diesen großen / festen Objekten, will man oft auch so etwas wie Rauch oder Staub in der Luft, darstellen oder Feuer/Flammen, Magische Lichteffekte eines Zaubers usw.
Diese Dinge bestehen jedoch nicht aus einem 3D Modell das man vorher, wie ein Bildhauer bei einer Skulptur, formen/designen könnte. Sondern es ist etwas „nicht festes“, eben Partikel die irgendwie in der Luft glitzern oder (als Rauch/Staub) die Sicht irgendwie erschweren. Und solche Effekte bestehen oft aus bis zu mehreren Hundert einzelnen Partikeln. Genau hierfür gibt es nun das Partikel System. Dieses ist genau auf diese Aufgabe optimiert.
Partikel Systeme sind gar nicht sonderlich kompliziert und die ersten Effekte lassen sich in wenigen Minuten erstellen. Doch einen Effekt perfekt so hin zu bekommen um etwas ganz spezielles auch realistisch nach zu bilden, genauso wie man es sich vorgestellt hat, ist eine hohe Kunst und kann Stunden dauern
Dabei gilt: sowas wie Magie (also etwas zu dem man kein reales Vorbild hat) ist viel schneller/leichter gebastelt, als etwas von dem man eine sehr genau Vorstellung hat wie es „in Echt aussehen muss“ wie z.B. Flammen und Explosionen … die man dann wegen der Performance, auch mit „nur 30 Partikeln“ erstellen möchte und nicht mit 300 Partikeln. Denn das ist die 2. Sache: etwas mit sehr vielen Partikeln schön zu bekommen, ist viel leichter, als es ähnlich schön aber nur mit 1/10 der Partikel zu erstellen.