Archiv des Autors: admin

Das ist virtueller Raum: Ausgeführte Regeln

Raum ist letztlich ein Regelsystem im Virtuellen (auch im Analogen dort nicht programmiert sondern durch Atome bestimmt). Das Raumregelsystem besteht meist aus einer Visualisierung des Raums und den Regeln innerhalb des Raumes. Allerdings kann ein Raum auch ohne visuelle Visualisierung auskommen – etwa nur aus Klang. Raum kann also im krassesten Fall nicht mal ein Display besitzen sondern ist nur Reaktion auf eine Aktion in ihm. Und diese Reaktion kann Raum sein.

Eine Frage des Codes

In diesem Sinn ist Raum in Games nur Code . Er wird konstruiert. Er wird erfahrbar durch die Handlungen in ihm und dessen Visualisierung. Und auch Visualisierung ist letztlich Code. Selbst als Processor ist Grafik gebauter Code.

Nachfolgend der Code für einen NPC-Roboter in einem Tilebased Raum (seine Logik) des experimental archeologischen Amiga Spiels PLANET COWARD. Der NPC-Roboter bewegt sich dem Grid entlang nach unten, stösst auf Dinge und entscheidet sich per Zufall für Links oder Rechts. Die Regeln sind rein virtuell. Es gibt keine analoge „Natürlichkeit“ in ihnen. Die ‚Wirklichkeit‘ des Spiels entsteht als eine Art Rekonstruktion von analogen Regeln des Realen – als Übertragungn.

Weiterlesen

Necronom und radikales Colorcycling

Es ist eine gute Frage, ob das jemals ein Spiel so radikal nutze wie Necronom. Der gesamte Screen wird Colorcycled (Die Nutzung von def. Farben um darin die Farben zu verschieben)? (Ok man könnte dagegen halten, dass auch viele Atari 2600 Spiele so gearbeitet haben – aber halt alles nicht in der Auflösung und vorallem nicht wirkliches 16/32 Farben Colorcycling). Und seltsamerweise funktioniert der Effekt auch noch einigermassen! Es wirkt wirklich sehr 3D!

Tiles-based-Design und Pixeln (Erfahrungsbericht – Amiga)

Bild des Block-Editoren der cryAGameEngine. Visuelles zu Planet Coward Version 0.5

Tiles – Nutzung

Tiles werden aus verschiedensten Gründen verwendet. Hier kurz einige davon:
– Tiles sind eine sehr sparsame Datenverwaltung (visuelle Referenzliste)
– Tiles lassen sich sehr gut einbauen ins Gameplay (Wand, Gang)
– Tiles lassen sich platzsparend abspeichern als Felder oder als Ascii-Strings
– Tiles sind einfach implementierbar (bzw. sind Teil des Hardwaresystems oder Fontsystem)
– Tiles lassen sich bei gutem Design gut kombinieren
– Das einzelne Tile ist einfach erstellbar – Veränderungen sind instant in allen Levels. 
– Tiles eigenen sich gut im LevelDesign
– Es lassen sich schnell grosse Welten kreieren (TileWorldEditor)
– Es gibt viel informelles Wissen mit aktivem 20 Jahren Tiledesign
– Aber: Tiles sind auch sehr schnell erkennbar und haben klare Kannten (bei ‚unpassendem Design)

Tiles: Seamless (Kachelbar)

Tiles müssen um ihre Möglichkeit maximal zu nutzen seamless sein – quasi kachelbar. Dies ist eine schwierige Aufgabe – gerade vor dem Hintergrund, dass Tiles immer begrenzt sind in ihrer Anzahl (im obigen Fall 256 Tiles a 16×16). Das heisst der Charakter von Tiles „viereckig zu sein“ muss gebrochen werden mit verschiedensten Techniken.

Weiterlesen

Darstellung – Manuell designte Perspektive – Objektorientierte Perspektiven (Lokale Perspektiven)

Die Möglichkeiten von freiem Design sind eigentlich unendlich. Menschen können auf ein Blattpapier malen, was sie möchten, können Perspektiven mischen und Stile etc. Diese Möglichkeiten waren (und sind es bis heute) bestimmend gewesen in den 8- und 16/32Bit Games. Es gab damals nur diese Möglichkeiten neben den beschränkten 3D Möglichkeiten wie Wireframe oder Polygonen. Also musste gerade detailiertes 3D machbar (als Pixel) visualisiert werden. Neben bekannten Darstellungen (etwa Iso) entstanden wildeste neue Kombination und Darstellungen. Dabei nutzte man* meist ein Visuelles Konzept für den Hintergrund und passte den Rest an vgl. TopDown Perspektive bei Gauntlet. 3D wurde möglich über Formen und Farben. (Dies im Gegensatz zu 3D-Frameworks wie OpenGL etc, die eigentlich die Visualisierung des Contents vorgeben und damit stärker restingieren als manuelles ‚Rendering‘)

Jedes Tile mit einem eigenen Fluchtpunkt

Im Nachfolgenden sehen wir die ersten Screens eines Spiels (Experimentelle Archeologie von CHLudens) hier hat eigentlich jedes Gebäude (Tile) eine eigene 3D-Perspektive mit Fluchtpunkt nach unten. Dadurch entsteht bei jedem Objekt, das angesehen wird eine Art Miniperspektive nach oben gegen die Kamera oder das eigene Auge als Betrachter*. Es simuliert eine Art psychologische 3D-Tiefe. Objektiv gesehen gibt es eine solche Perspektive nicht. Sie simuliert aber beim Hinsehen, Perspektive. Dennoch scheint klar ersichtlich, dass von oben auf diese Welt geschaut wird.

Davon weicht das Gras ab und der Panzer ab. Das Gras hat einen anderen Winkel und der „Panzer“ ist ganz Top down.

Weiterlesen

Explosionen – was explodiert: die Granate oder das Ziel?

Eine Interessante Designfrage in einem Game, was explodiert eigentlich. Was soll designtechnisch manuell gerendert werden?

A Das ‚realistische‘ Variante: Die Granate explodiert am Haus
oder
B Die symbolische Variante: Das Haus explodiert

Im Gamedesign geht es selbstverständlich wenig um „Realismus“ (den müssten wir ja auch noch kennen, leider ist gerade der Krieg in der Ukraine ein gutes Beispiel zu sehen, wie Realität aussieht – leider jeden Tag in Europa .-( ), sondern eher um Effekt und das was wir erwarten.

Des wegen hier die Videos mit Variante a und Variante b aus einem Forschungsamigaspiel von CHLudens:

Variante a: ‚Realistisch‘

Einfach realisierbar. Der Schuss verwandelt sich einfach in eine Explosion:

Das Resultat:

Das Ganze sieht auch unnatürlich aus, weil man nicht den echten ‚Effekt‘ sieht, also eine „Einbeulung“ des Gebäudes.

Weiterlesen

Perspektive und Kamera-Position in Gauntlet

Eine der interessantesten Aspekte in der Zeit des manuellen „3D“ der Pixelwelten ist die Konstruktion von Perspektive. Hier das Beispiel Gauntlet (oder Garrison) – psychologisch nehmen wir die Regeln dieser 3D Welten sofort an. Die Kamera scheint von oben (top down) herunterzublicken. Irgendwo in der Mitte. Sichtbar sind fast alle 4 Seiten. Wobei die linke und rechte Seite überdimensional hervorgehoben sind. Das Licht ist von links unten gemalt. Es scheint eine parallele Lichtquelle zu sein.

In einer ‚echten‘ 3D Welt würden selbstverständlich die Maueren im Bezug zur Kamera verschieden sein müssen – adaptiv. Die Wände wären sichtbar von Innen nach Aussen in Relation zur Kamera. Anders gesagt: die Umgebung besitzt eine eigene Kamera. Selbstverständlich wäre eine dynamische Anpassung der Perspektive nicht möglich gewesen zu dieser Zeit (keine 3D Engines bzw. die Rechenzeit alle zu berechenen und darzustellen oder die 3D Varianten vorzuzeichnen).

In den Detail interessant ist dann etwa wie die einzelnen Objekt/Avatar/NPCs (Sprites) im Spiel ausgerichtet sind, etwa die Figuren oder Truhen, diese haben eine eigene kleine Kamera on top und sind da Zentralperspektivisch manuell gerendert.

Weiterlesen

move.l: Verschieben oder Kopieren?

Der Move-Befehl ‚verschiebt‘ einen Wert von A nach B – so sagt es zumindest das Naming. Eigentlich verschiebt er den Wert nicht nur, sondern er kopiert ihn. Aber selbstverständlich wird er damit auch ‚verschoben‘. Es wäre auch eine gute Frage, falls er ihn ‚verschieben‘ würde, was an dessen Stelle wäre am alten Ort. Das wäre ja ein ‚echtes‘ Verschieben.