Und plötzlich (? das gilt es noch zu klären) taucht das Wort Engine auf und zwar im Zusammenhang mit Adventures (ab 1980 ?). Dabei handelt es sich um ein Gamedesign-Szene weites Phänomen (zumindest im Homecomputerbereich). So entwickeln die Personen hinter KingsQuest (Sierra) eine oder die bekannte SCUMM Engine entsteht und auch im CHLudens-Korpus findet man mit Linel einen Publisher, der an einer Engine arbeitet. Es lässt sich also vermuten, dass es da noch mehrere solche Entwicklungen gab.
Arcade – wenige extrem oft verwendete Regeln
Prinzipiell scheint auch klar warum: Die meisten Action/Arcade getriebenen Spiele basieren meist auf wenigen unendlich oft wiederverwendbaren Regeln. Man vergleiche hier dazu einfach die Spielmechaniken etwa von R-Type und ManicMansion (// Konkret ToDo).
Adventure ist im Heimcomputerbereich, wenn die Tilebasierung nicht mehr reicht, um die gesamte Mechanik abzubilden. Denn verschiedenste Tiles haben mehr als eine Funktionalität, wenn überhaupt.
Ein Problem beim Coden von Games sind dynamische Strukturen gerade bei Adventures. Zum Beispiel möchte man verschieden lange Texte haben statt des Normalzustandes eine Liste mit etwa 40 Bytes langen Strings zu haben. In diesen kann man ja dann einfach Strings[10] finden mit 10*40. All das entfällt bei Strings die verschieden lang sind. Man bräuchte eine eigene Verwaltung dafür – also einen Index oder aber man sucht jedes Mal die „0“-Bytes am Ende. Und sucht einfach 10 davon, was nicht gerade optimal ist bei wenig Rechenzeit.
Hier ein Beispiel mit immer gleichvielen Bytes (PlanetCoward)
Eigentlich sind die 16/32Bitter ein Traum für jeden Programmierer* und seine Projekte. Es gibt viel RAM (512kb bei Atari ST und Amiga) und einen schnellen Prozessor.
Und dennoch ist es wieder soweit bei der Erweiterung der CryAEngine für Züri
Brännt kommt die Idee/Konzept der Umsetzung an die Grenze: Zu wenig Speicher.
Die Maus ist eine ungemein direkte Art etwas zu steuern nämlich den Mauszeiger. Es ist ebenfalls eine Gestensteuerung, vielleicht noch mehr eine Gestensteuerung als per Joystick. Man bewegt den Joystick nach Rechts (drückt ihn) und der Avatar geht nach Recht. Bei der Maus: Die Hand bewegt sich nach rechts, der Mauszeiger auch. Es erscheint zumindest als direktere Steuerung, weil die Bewegung der Hand die Bewgung des Gesteuerten direkt mitmacht (scheinbar, da die Maus ja kein absolutes Eingabegerät ist oder nur lokal absolut).
„Direkte Spielsteuerung“
Die erste Version des ZüriBrännt-Adventure war eine klassisch direkte Steuerung per Joystick. ZüriBrännt auf dem Amiga hingegen setzt auf die Maussteuerung. Interessanterweise ist das Feeling ein ganz anderes als mit der indirekten Maussteuer. Die Steuerung von Avataren direkt mit der Maus existiert soweit bekannt eigentlich nur bei „Ballrollspielen“ wie etwa RockNRoll, Arkanoid und etwa bei WAR HELI (CHLudens Korpus) oder ZARCH/VIRUS für die Steuerung des Raumschiffes. Sonst aber findet man fast keine direkten Steuerungen. Diese Steuerungen sind direkt, der Spieler* hat das Gefühl man treibt den Ball bei RockNRoll selbst an, als fliesse die Energie direkt in den Ball (oder beim Joystick direkt in die Figur und bewege sie).
Mousepointer und Tastatur (?!)
Was – soweit bekannt – fehlt ist der Mousepointer und die Tastur in einem Konzept. Konkret: man steuert direkt die Figur und mit der Maus handelt man. Heute gibt es einige dieser Spiele im Bereich „TwinStick-Shooters“ (eigentlich MiniStick-Maus-Shooter). Interessant ist auch hier die Frage: Sind nicht Spiele wie Doom3D+ nicht genau diese Art der Spiele. Damals war dieser Weg versperrt, da Joystick-Maus nicht in Frage (Arcadevorbilder) kam und auch nicht handelbar war und Tastatur mit Maus unpraktikabel (ausser bei Shortcuts) gesehen wurde. Die Frage ist warum nur? Kulturell, weil ein Game immer noch per Joystick gespielt werden musste?
Nachtrag: moderne Varianten von KingsQuest und SpaceQuests haben tatsächlich Tastatur und Mauspointer gleichzeitig.
Maus mit MousePointer
War die direkte Steuerung klar „Ich steuere und ich bin der Avatar“, ist es bei der indirekten Steuerung (Klicke und gehe dahin) ganz anders. Da ist einmal die Neuerung, die sicherlich in den Jahren der Einführung der Maus im Massenmarkt da war. Hier stellt sich die Frage, wie sahen die ersten Spiele aus in diesem Bereich. Hierzu muss man sicherlich einmal die Lisa/Mac-Spiele nochmals genauer anschauen. Die Homecomputer kamen ja erst einen Tick später heraus, aber diese waren bekanntermassen sehr schnell sehr erfolgreich und interessante neue Konzepte entstanden oder wurden popul=arisiert.
GewaltDesignrules in Filmen, aber keine GewaltDesignrules in Games? Betrachtet man die heutigen Games (etwa Baldures Gate etc), so scheinen Games keine Grenzen zu kennen, was die Darstellung (Visuell, auditiv) von Gewalt und deren Folgen (etwa zerstörte Körper) betrifft.
Eine der interessantesten Momente in der Spielentwicklung ist, wenn ein neues Projekt beginnt. Oft nimmt man dabei das Spiel, das am nächsten zum zu Entwickelnden Spiel ist oder man nimmt die neuste Version der Engine und fängt darin an zu implementieren, Grafik anzupassen etc. Dabei gibt es einen Moment, wo das alte Spiel visuell noch da ist, das neue aber langsam reinkommt. Man entwickelt damit gleichzeitig aus dem alten das Neue.
Im Nachfolgenden wird das Ganze gezeigt in einem frühen Stadium von „Züri Brännt“ ausgehend vom noch nicht fertigen Spiel „Planet Coward“.
Das folgende Video zeigt die ersten Anpassungen in Menubild und im Spiel.
B. Suter, L. Wild, D. Krummenacher, M. Kocher, *, R. Bauer
„Züri Brännt“ ist eine experimentelles ArchäologieProjekt mit den Fragen:
1. Wie funktioniert, das damals neue Genre der Point&Click Adventure? 2. Warum gab es praktisch keine Spiele mit politischem Inhalt? 3. Warum gab es wenig Spiele mit lokalem Inhalt? 4. Welche technischen Herausforderungen stellten Point&Click Adventures?
Das Spiel wurde schon einmal im Projekt CHLudens begonnen und zwar auf dem C64 (Engine war angepasst, erste Szenen standen siehe hier, Setting erarbeitet).
Avatargrössen sind im GameDesign mehrheitlich abhängig von ihrer Funktion in der Spielmechanik und dies wiederum ist abhängig von den Möglichkeiten der Hardware in der 8/16Bit Konsolen-Homecomputerzeit und umgekehrt.
OneScreen-Games: Meist kleine Sprites
Viele der ersten Spiele waren OneScreen-Games. Damit sie interessant sind, muss sich der Avatar bewegen können und verschiedene Task in der Szene ausführen. Müssen dann noch Gegner dabei sein, bleibt nicht allzu viel Platz für grosse Sprites. Selbstverständlich werden diese Grössen der Avatare im GameDesignProzess „ausgehandelt“, was nichts anderes heisst als ausprobiert bis es zu diesem Spiel passt und technisch möglich ist.
ShootEmUps
Viele ShootEmUps haben sehr kleine Sprite 1:10 oder sogar weniger. Es geht bei ShootEmUps ja auch ums Ausweichen. Und das ist grösse kein gutes Asset.
Das Spiel PacMan kann nur einen kleinen Avatar haben, weil es sich um ein OneScreen-Game handelt, es ums Einsammeln in einem Labyrinth geht und es noch Geister geben muss.
In „Adventuren“ werden If-()-Bedingungen meist zu Gegenständen ‚materialisiert‘ – und das trifft sowohl auf das IF wie auch auf das () zu. Und danach heisst die Bedingungen einfach: Hast du den Gegenstand ()? Ok, ja dann geht es weiter. Das mit Abstand einfachste solche Checksystem/Bedingungsystem (inklusive Motitvationsdesign) ist die geschlossene Tür. Finden des Schlüssel für eine Tür und das Anwenden – ist dann der Check, das Einlösen und Ausführen des Anweisungsblock. Selbstverständlich funktioniert der Rest von Adventuren auch nicht anders.
