Eine kleine Geschichte der Gewalt||akzeptanz in Games Teil I (In Arbeit Letztes Update 1.11.2024)

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.

https://www.gamelab.ch/?s=gewalt

Der Inbetween-Entwicklungszustand bei der Entwicklung eines neuen Spiels – Developmentmorphosen

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.

Weiterlesen

Experimentelle Archäologie: Züri Brännt (Amiga)

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).

Weiterlesen

AvatarDimensionen: Point&Click-Adventure – Riesensprites [In Arbeit]

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.

Weiterlesen

Adventure = Verdinglichung von If-Bedingungen

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(); }

Die ReleaseReactionMethode: Case Squarez 18. Oktober+ 2024

Squarez ist ein Spiel aus dem Forschungsfeld ExperimentelleArchäologie des Projekts CHludens.ch. Zusammenfassend kann gesagt werden, dass SQUAREZ ein Demake eines Flash-Games ist, dass die Frage stellt: Wie lässt sich auf dem Amiga in Assembler ein einfaches Games umsetzten? Warum gibt es nicht so viele abstrakte Games in der Homecomputer-Area? Und warum ist die Maus im Bereich der Amiga & Actionspiele nicht wirklich beliebt ist.

Der Outcome sieht folgendermassen aus:


Die Findings folgen nun hier.

Antwort A: Settings, Vermittlung & grössere Möglichkeitsraum



Die Antwort(en) ist natürlich vielschichtig und die ersten Antworten finden sich beim Erstellen
und damit in den ForschungsBlog-FingingsEinträgen etwas hier:
Mehr dazu findet sich hier >

Antwort B: Community Antwort

Weiterlesen

Raum: Analog vs Cyberspace



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

Necronom oder die neuen Möglichkeiten der Homecomputerspiele

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.

Gamedesign: Möglichkeitsräume von Computern (Kategorisierung) – vorallem in der HomecomputerArea

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).

Ausgelieferte und dokumentierte HardwareHardwarenahe ProgrammierungMaximal ausgenutzte Hardware
Beschrieb
Dies umfasst die Hardware und die vorgesehene Nutzung. Dies ist meist dokumentiert in den Manuals, die anfangs ausgeliefert wird. Oft sind die Möglichkeiten dann auch in höheren Programmiersprachen abgebildet als Funktionen.

Nutzung
Die Nutzung ist meist dokumentiert, Beispiele vorhanden. Es lässt sich als Entwickler einfach anwenden.

Lebenszyklus einer Hardware
Vor allem am Anfang einer Platform sind es vorallem diese Funktionen die genutzt werden.

Cases
C64: Auflösungen, Auflösungsänderungen, feste Farben, Tilebasierter Hintergrund (Chars), 8 Sprites 24*21 Pixel, SID, 6502

Atari ST: Auflösungen, 2,4,16 Farben, freie Farbwahl freie Farbwahl, 68k

Amiga: Auflösungen, Auflösungsänderungen, 8,16,32 Farben, freie Farbwahl, 8 Sprites, Blitter, Soundchip, Copper

Consolen: Wie Computer allerdings meist sehr viele Spirtes. Einfach zu implementieren. (+Collisionen)
Beschrieb
Hier finden sich Tricks, die zwar vorgesehen sind und aber einigermassen unzugänglich sind.

Nutzung
Rudimentär dokumentiert. Schwieriger für Entwickler einzubeziehen, verändert das Gameplay.

Lebenszyklus
Werden vermehrt eingesetzt nach der ersten Nutzung der Platform.

Cases

Beispiel: Wiederverwenden von Sprites durch geschicktes nachträgliches Umplatzieren der Sprites

C64: Vielfach genutzt beim

Amiga: vielfach genutzt, etwa für Hintergründ (Amiga typische Hintergründe)
8Fach Scrolling

Atari ST: eigentlich alles, was mit Scrolling zu tun hatte oder Sprites (keine Hardwarespirtes), DigitalMusic
Beschrieb
Ausnutzung der gesamten Hardware, von Fehlern,Tricks, Fehler und Tricks, die sehr viel Anpassung benötigen und teilweise Umbau der gesamten Architektur des
Vorallem gegen MItte bis Ende der Zeit einer Plattform genutzt.

Nutzung
Aufwand teilweise enorm. Effekte müssen ein- und angepasst sein. Verhindert teilweise die Entwicklung allgemeiner Frameworks oder Engines, weil so Hardware nahe.

Cases
– Abzählen der ausgeführten Befehle in Assembler
– Nutzung von Seitenrändern etc.
– Amiga: Blitter rechnet im Hintergrund, gleichzeitig wird mit der CPU gerechnet