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.
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.
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).
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.
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
WeiterlesenRaum: 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.
Das Game-Datenset CHLudens 1970-2000
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? „
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 Hardware | Hardwarenahe Programmierung | Maximal 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 |