Ein Gamedev* im technischen Bereich muss die Grundlagentechnik beherrschen (Basic Layer). Wird ein neues System angegangen geht es darum, grundlegendste Fähigkeiten zu erarbeiten. Praxis des Vorgehens etwa bei der Einarbeitung in ein unbekanntes System wie den C64 erfolgt oft wie folgt:

Coding-Layer:

Wie kann ich überhaupt auf einer Platform coden? Welche Sprachen sind möglich und sind akzeptabel für das Produkt/Game bzw. für die Entwickler.

Output-Layer: Displays – Gebräuchlichste Graphik & Sound

• Grafik: Darstellung von Objekten meist Grafiken später auch 3DModelle
  Die konkreten Fragen: Graphikmodelle, Abbildung RAM, Punkte Zeichnen. Auf diesem kann alles weiter aufgebaut werden. Grundlagentechniken.
• Grafik: Technische Machbarkeit von statischen Gameobjekten(Hintergrund) und Sich-bewegendem (Anfangs Sprites)
  Konkretes einbetten von extern erstellten Grafiken. Wie lädt man diese? Wie stellt man sie dar? Nächste Stufe: Wie kann man bewegende Objekte alias Avatar und NPCs darstellen und handeln.
• Sound: Wie kann Sound generiert werden als Grundlage? Wie funktionieren Soundeffekte, wie kann Music implementiert werden.

Input-Layer: Interaktivität – Gebräuchlichste Tastatur, Joystick, Maus

• Wie funktioneren diese technisch? Wie lassen sie sich einbinden?

Mangement-Layer: Management des Spiels

Spiele verfügen über Anforderungen, die sich zumindest in der Frühzeit der Computerspiel mehrheitlich bei den Spielen finden (Sie sind keine reinen Input-Output-Programme vgl hierzu auch Brainfuck vs Brainfuckconsole74).

Nebenläufigkeit/Scheinbare Gleichzeitigkeit

Nebenläufige Tasks: Games benötigen meist einen Loop (nur so sehen Ingamelebenswelten auch so aus, als würden sie ‚leben‘), der wiederholend auf Interaktivität ‚wartet‘ und gleichzeitig das Spiel prozessiert.

Objekt-Datenmanagement

Aufbauend darauf stellt sich die Frage, wie prozessiert man die alle die Einzelaktivitäten des Spiels wie Output/Input/Daten-Management. Das kann man eher die Datenverarbeitungskomponente des Spiels nennen und ähnelt in der Mehrheit der Fälle einem Excel-Sheet mit Gameobjekten.

Historische Entwicklung – Verlorene Spielmechaniken

Der dargestellte Prozess bezieht sich vor allem auf die frühe Gameentwicklung, wo die Gamedevs eigentlich die ganze Grundlage auf Basis der jeweiligen Hardware entwickelt haben. Damit haben sie selbst eigene Gameengines erstellt, in denen dann jeweils ein Spiel programmiert wurde – öfters Hardverdrahtet genau für dieses Spiel. Erst später (noch konkret zu erforschen) kommen vermehrt GameEngines auf, die Entwicklung heben und zu einer Art Betriebssystem (Jahrmann) werden für die Spielentwicklung. Dabei gehen interessanterweise Dinge auch wiederum verloren. So arbeiten heutige Engines fast alle mit Objekten (Objektorientierter Ansatz) und zwar auch im Display. Dadurch ist es heute viel schwieder Tile basierte Spiele oder gar Pixelbasierte Spiele zu entwickeln.

Komplexität – Konstanter Mainstream

Interessant is auch, dass die Spiele in ihrem Management oder dem ‚was-gehandelt‘ wird gar nicht soviel komplexer geworden sind. Meist sind es 1-6 Objekte die sich bewegen: Avatar und ein paar Gegner. Selbstverständlich gibt es seit den BulletHell-Shootern und Strategiespielen auch den Trend zu massig vielen, der gerade auch aktuell ein Trend ist.Aber im Grossen und Ganzen sind die 8 Sprites etwa des C64 immer noch das, was Spieler handeln können. Wobei das Handling in 3D Spielwelten eher weniger als 8 aktive handelbare Gameobjekte umfasst. Es scheint, als seien mehr zu kontrollierende Objekte nicht handelbar oder einfach zu stressig.