Archiv der Kategorie: Uncategorized

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

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

Gab es eine Differenzierung im Entertainmentsektor des neuen Raums (Cyberspace) in möglichst viel Realismus (GameDesign) vs Abstraktheit (Demoscene) Ende der 80er Jahre? [EssayNotiz]

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.

Pools in Action – Sprites als endliche Ressource in 8/16Bit Umgebungen

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.