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.

Galaxian (1979, Arcade, AvatarHeigthScreenRatio: 1:12)

Abschiessen und Ausweichen im ShootEmUp.

PacMan (1980, Arcade, AvatarHeigthScreenRatio: 1:14)

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.

// ToDo: IF Tür(Schlüssel) { ZerstöreTür(); }

Raum ist im Analogen selbstverständlich. Gerade deswegen ist es so schwierig, über ihn nachzudenken. Und gerade darum wurde er auch im Cyberspace sehr schnell „irgendwie“ simuliert.

Analoger Raum hat verschiedene Dimensionen (mindestens). Diese werden alle von der Realengine (Atome) bestimmt:

– Visuelles Display
– Auditives Display
– Interaktionsmöglichkeiten

Digitale Welten (Cyberspace)

Im Digitalen ist dieser Raum auf den verschiedenen Ebenen jeweils ein Regelset und wirkt zusammengesetzt wie ein Raum.

In klassischen Games (Homecomputer):

– Videoram (Oft basierend auf Tiles)
– Sound (Programmierung)
– Manuelle Engines (Programmierung)
– Programmierung

In modernen Games:

– Grafikengine
– Soundengine
– Physikengine
– Interaktivität ZusatzProgrammierung

Dass das Leitmedium der einen Hälfte der Videogames die Arcade war, kann man so stehen lassen. Dass die Homecomputerspiele aber weit über das Medium Arcade hinausgegangen/-gewachsen sind, zeigen allein schon die neuen Möglichkeiten: Etwa die Möglichkeit des Speicherns (WAR HELI) oder dass man mit erspielten Codes später wieder einsteigen konnte.

Dabei spielt hier gerade nicht nur mit, wie lange ich spiele (Arcades), sondern dass ich ans Ende kommen kann und dabei was erleben kann.

Eine der grundsätzlichen Fragen ist immer: Sind die Beobachtungen in anderen Datensets dieselben wie in unserem Datenset? Lassen sich Ergebnisse und Erkenntnissen anderer Datensets auf unser Datenset übertragen? „Gibt ein Datensatz gewisse Aussagen her? „

Vermutlich muss der Möglichhkeitsraum von Computern (für die Gameentwicklung) – also das Gameplay für Devs – klarer differenziert werden – sowohl abhängig von der Hardware und zeitlich von den Tricks. Nur so lässt sich letztlich ‚verstehen‘, wie Spiele entstanden, wie etwa Ports einfach oder kompliziert war und wie nicht tricksende Gamedevs* dennoch interessante teilweise neue Spiele – jenseits des Leitmediums – entwickeln konnten. Das klassische neue Homecomputerspiel – ein eigenes „Genre“ mit eigenen Regeln (Spiel zu Hause, teilweise speicherbar, optional die Maus nutzend, Themen, die näher an den Spielenden waren, die Möglichkeit selbst Spiele zu erstellen etc).

Es ist schon interessant mit welcher „Hingabe“ das Gamedesign versucht realistischer zu werden in der Homecomputerarea, als müsste es dasselbe bieten, was der Fernseher mit nicht viel grösserer Auflösung (Interlaced) zu bieten hatte. Der Abstand schien damals machbar, irgendwann einholbar. Als wäre es ein Kampf des neuen nicht anerkannten Underclassmedium Games gegen den Fernseher, der immerhin im Hintergrund das schon anerkannte Kulturgut Film hat.

Es fällt die Absenz des Abstrakten gerade im Medium Game der Homecomputer auf (Als gäbe es dies im Film ausser im Experimentalfilm). Das Medium ist nämlich anders als der Film, sehr wohl ein abstraktes Medium – ein regelbasiertes Medium. Dies zeigen ja auch all die frühen Computergrafikexperimente mit Linien und Flächen, die man dann auch als Fortführung oder Inspiration für die abstrakte Kunst lesen kann (selbstverständlich auch umgekehrt). Im Sinne von: Endlich ein Algorithmus der das mühsame genau Zeichnen übernimmt.

Vor der realistischen Abbildung ist der Computer eine visuelle Symbolmaschine. Abbildung mit Wiedererkennungswert kommt erst spät in der Genese der Games.

Vielleicht so die erste These zerfiel das neue EntertainmentSegment des Computers in zwei Teile oder eine Form emanzipierte sich von der ersten mit dem Medium Crackintros basierend auf der Gamescene. Die zweite Scene – die Demoscene – entstände damit als eine Art Graffiti (Suter) auf dem in seinen Möglichkeitsräumen nach HyperRealismus strebenden Videogames. Es nähme die Entwicklungen aus der abstrakten Kunst auf, varierte sie: Das Unkommerzielle als Vorspann für das radikal Kommerzielle der Games mit all ihren Stereotypen und wenig Experiment. Aber sind nicht beide Szenen bis heute sehr wertkonservativ?

Im Bereich Demos sieht man dennoch ab und zu erstauntlich Neues während die „elektronischen Games“ sich doch sehr dem Markt angepasst haben. Interessant dies auch im Set der Schweizer Games von 1970-2000 nachzuzeichnen.

Wer mit endlichen Ressourcen arbeitet und ein begrenztes Rechensystem hat, was gerade bei Homecomputerspielen der Fall und ein Problem ist, der* arbeitet oft mit Pools für die endlichen Ressourcen. Die Ressource wird dann zur Verfügung gestellt, genutzt und nach der Nutzung einfach wieder ‚eingestellt‘ in das Pool-Regal. Von dort wird sie dann wieder abgeholt. Dabei ist klar: Es kann zu keiner Überlastung des Systems kommen, weil die Ressourcen die Möglichkeiten und das System total einschränken. Der maximale Möglichkeitsraum ist klar.

In den meisten Fällen sind das bei Consolen oder Computergames, die Sprites. Beim Amiga sind das ärmliche 8 Sprites für die Zeit der Veröffentlichung 1985. Sie kommen meist begrenzt daher und sind gratis für die Rechenpower eines Systems. Sie brauchen de facto keine Rechenzeit. Anders sieht es mit Grafikprozessoren wie dem Blitter auf dem Amiga aus. Diese kosten Rechenpower und sind dadurch beschränkt, auch wenn es offen ist, was man mit ihnen macht. Selbstverständlich muss man auch hier über Pooling nachdenken.

Im folgenden Fall sieht man die Nutzung vom Poolregal von Sprites in Action. Die ungenutzten Sprites sind links oben dargestellt. Dinge werden geholt und wieder zurückgestellt. Das Spiel verwendet aber auch grafische BlitterObjekte und diese werden nicht im Spritepool verwaltet, sind deswegen auch nicht sichtbar. Die Gesamtzahl der genutzten „movable Objects“ findet sich in der links angezeigten Zahl.

Aus dem Spritepool kommen im obigen Beispiel: der Cursor und die Schüsse des Avatarschiffes. Diese werden über den Screen geblendet und sind nicht Teil des Videomemories. Der Rest der Objekte sind BlitterObjekte die direkt in den Screen gerendert werden und dann auch wieder entfernt werden müssen.

; 'CPU Variablen' A0-A7 wie auch D0-D7 sind sehr schwierig auseinanderzuhalten, gerade weil alles linear ist
; 'Variablen' für For-Next-Schleifen d0-d7 schwer auseinanderzuhalten
; .b(yte)/.w(word)/.l(long) schwierig auseinanderzuhalten bei vergleichen, moves etc. > darum fast alle w?
; Man benötigt viele Sprungmarken und irgendwann ist auch die Phantasie weg und dann entstehen, schwer auseinanderhaltbare und wartbare Sprungmarken!
; ...