Often you can cut things. because it is all the same.
WeiterlesenSizeCoding – also a PuzzleGame Motivation
Schreibe eine Antwort
Archiv des Autors: admin
Sizecoding-Case: Breakout und die Erkenntnisse
Die ist auch ein Case für die Idee Sizecoding als Designmethode zu diskutieren. Siehe dazu hier Sizecoding [DesignMethode] >
Wer das erste Mal ein Breakout programmiert denkt: Kein Problem. Da gibt es ja nur einen Schläger, einen Ball und Steine (Playfield). Die Grafik verwundert, ist sie doch in einer Zeit der monochromen Monitore entstanden. Das Problem löst sich dann, wenn man liest, dass es sich um eine Farbfolie handelt. Aber Farbe ist heute ja auch kein Problem mehr.
Genese – Spielemechanik & Technologie
Das Spiel selbst ist letztlich ein auf den Kopf gedrehtes Pong-Arcade (auch physisch) und aus dem einen Gegner wurden statische AIs alias Blöcke. Aus einem Spiel mit 3 Sprites, die dieselbe Technologie benutzten (Sprites) wird ein Spiel mit Vordergrund 2 Sprites und einem Playfield und einem Hintergrund. Aus einem Multiplayerspiel wird ein Singleplayerspiel mit ganz anderer Motivationsmechanik und viel höherer Reichweite.
Klassische Implementation
Die klassische Implementation setzt auf einen Hintergrund mit zwei movable Objects. Wie die genau Implementation des Orginalautomaten von Wozniack/Jobs (Atari Arcades) tatsächlich ist, wurde hier nicht genauer betrachtet.
Die klassische Programmierung findet man im folgenden Spiel „imagoBreakout“ in Aktion:
Mehr zum Spiel – bei dem das Visuelle zunehmend ausgeblendet wird – hier >
WeiterlesenSizeCoding – a method of cognition
SizeCoding is an attempt to pack things into as little code or compiled code as possible. In this way, the method also follows the human endeavour to pack ‘a lot into a little’ and still keep it controllable. So a small model has great significance. But science also sings its song of simple formulas with a lot of power. Today, the whole thing is also a question of sustainability – for example in the discussion about big data AI and learning.
In other words, it’s about power and control. The fewer characters are used, the more magical/powerful the ‘code’ is. Here, of course, homage is also paid to the machine and the disembodied ‘self’. Hence, of course, the connection to the demoscene and its emergence as intro crack demos.
Of course, size coding used to be a must in game design. How much ‘game’ can you fit into an 8K module, etc.? Today, size coding is rather obsolete – because readability and therefore maintainability are usually neglected.
Sizecoding-Method
But size coding is also a cognitive and therefore scientific method.
WeiterlesenCafegespräch zum C64 und Amiga
Dies hier sind einige Notizen zu einem Cafe-Gespräch rund um den C64 und Amiga. Damals wie heute. Die Gesprächsnotizen sind anonymisiert, weil das Gespräch weder aufgenommen wurde und es liegt auch keine Bestätigung zur Veröffentlichung vor. All dies wird in einem zweiten Gespräch nachgeholt werden. Dennoch sind die einzelnen Punkte gewichtig genug, sie als Fragen festzuhalten.
Einige, der diskutierten Themen:
Ein neues C64-Game
Es geht darum, wie komplex es heute ist ein neues C64-Game zu machen. Gerade wenn es sich noch an einen Klassiker anlehnt. Was darf übernommen werden, was nicht? Durch den Kontakt zu den Urhebern wird klar, die Rechte sind immer noch da und werden noch benutzt, etwa für RetroKonsolen.
Interessante Diskussion zur Frage, wie das Artwork des Titelbildes entstand und wie hier zuerst das analoge Bild entstand und erst danach die C64 Version erstellt wurde. Allgemein die Frage, wie arbeitet man heute zusammen – direkte Instant-Kommunikation, Emails.
Kurz vor dem Release wurde klar: Das Spiel ist zu Nahe am Orginal. Praktisch alles muss überarbeitet werden (Font bis Figur und Name) – in einem Monat.
Es geht auch um die Frage, der höheren Programmiersprachen. Wann und wo kommt und kam Basic zum Einsatz. Welche Basics gab es. Dies ist umso wichtiger, als dass der Gesprächspartner noch heute im Bereich Basic-Games unterwegs ist. Auch fürs nächste Projekt für den C64 arbeitet der Gesprächspartner wieder mit Basic als Grundlage, weil einfach Assembler für Management-Spiele nicht machbar ist oder zumindest masochistisch ist. Die Diskussion dreht sich auch noch darum, dass es Entwickler gab (vor allem grosse Entwickler?), die auf schnellen PCs kompiliert haben und das Ganze dann auf dem C64, Amiga ausprobiert haben.
Wechsel C64-Amiga oder die Aneignung der Amiga Technologie
Es gibt eine Diskussion darüber wie der Übergang von C64 zu Amiga lief. In der CHLudens Experimentellen Archeologie wurde klar, dass dies nicht ein einfacher Übergang war. In den Berichten von Damals wird es als „Befreiung“ – ein neuer „Möglichkeitsraum“ gesehen – die Probleme kommen eher nicht vor. Der Amiga hat – mit dem 68k – Dinge sehr vereinfacht: „endlich“ Rechnen mit Zusammenzählen, Multiplikation, Division. Das sei schon fantastisch gewesen. Wir sind uns auch einig, dass die 256er Grenze in den Bytes aufgehoben wurde, und das viel vereinfacht hat.
WeiterlesenWarum versuchen viele CrackIntros/Demos & Games so ästhetisch regelhaft zu sein? (vs DemoBrute)
Auch die Demoscene hat viele Probleme. Ein Problem der Demoscene allerdings sticht hervor: Die Demos möchten mehrheitlich ’schön‘ sein. Die Demo oben verkörpert einen Gegenentwurf dazu, auch wenn sie selbst aus wenigen Elementen zusammengsetzt ist.
Das Schöne und Regelhafte
Und vermutlich ist „schön“ das falsche Wort: Sie möchten einen Stil haben. Denn über Stil lässt sich bekanntlich nicht streiten. Ein Stil ist eben mehr als nur Zufallsdesign, es ist eine Setzung, es ist gestaltet. Ein Stil, das ist meist ein visuelles Design, das visuellen Regeln folgt und diese durchsetzt. Dadurch wird es zum (Design-)System. Dadurch erscheint das Design nicht willkürlich. Es erscheint dagegen lesbar. Und ja durchdesignte Dinge können trotzdem langweilig wirken, gerade wenn die visuellen Regeln bekannt bzw. verbraucht sind. Aber selbst dann: Es sind noch Regeln, die man mögen kann oder eben nicht. Man akzeptiert den visuellen Magic Circle oder eben nicht – aber es bleibt doch einer. Ihm seine Designheit abzusprechen geht allerdings nicht. In diesem Sinn sind kohärente visuelle Welten ’schön‘ – egal wie „hässlich“ sie sind, denn sie sind grundsätzlich ‚regelbasiert‘. Sie sind kein Chaos – sie sind aufgeräumt. Bis hin zu den Tools, die anzeigen, wo der Abstand im Design derselbe ist (Parallelität, Hilfslinien). Selbstverständlich kann man auch überdesigned unterwegs sein. Dann wenn alles sich nur an Designregeln orientiert und kein Interpretationsspielraum mehr übrig ist. Und auch die Challenge, die Regeln zu finden, wird dabei unterlaufen, weil die Regeln so oberflächlich sind.
WeiterlesenZeichensatzgrafiken in der PC1- & Homecomputerzeit, der Tod mit dem AtariST/Amiga und die Wiederauferstehung heute
Looking through the 16/32Bits Homecomputer Eyes: 320×200 pxs und 16 oder 32 Farben (Atari ST/Amiga)
Ist man grafisch unterwegs (design) auf den Homecomputern, so fängt man die verschiedenen Homecomputersysteme nicht nur auditiv, sondern auch als eigene Systeme/Instrumente zu sehen. Also eine Art Malkasten je nach Homecomputer. Nicht alles ist möglich durch Auflösung und die Farben. Es bleibt ein enger Möglichkeitsraum für die Gestaltung.
Der C64-Malkasten – rudimentär, brute
Der C64 kommt mit seinen 16 Farben und der meist verwendeten Auflösung von 160×120 Pixeln daher in 16 vordefinierten Farben und dann sehr vielen Einschränken. etwa 8×8 und 4 Farben etc. Das erzeugt dann schon eine gewisse dieser Grafik eigentständige Radikalität. Die wie im Nachfolgenden sichtbar schon eine gewisse Brutalität besitzen kann.
16/32Bit Malkästen – wählbar
16/32Bit Homecomputer hatten dagegen oft keine brutale Grafik. 320×256 Pixel bei wählbaren Farben 16/32 beim Atari ST oder 32 beim Amiga (maixmal). Hier lässt sich auch viel mehr wählen. Und da wurde dann auch gewählt. Brutal wirkt die Grafik selten. An was könnte das liegen?
Die offene Welt oder das Interface von ManiacMansion, ZakMcCracken, MonkeyIsland und Co – SCUMM-VM
Wer je schon ein MUD (MultiUserDungeonn) oder ein TextAdventure gespielt hat, ist am Anfang überfordert von den vielen Möglichkeiten bzw. der Radikalität des Interfaces: Es gibt nur Text und eine Eingabeaufforderung. Alles scheint der Imagination ausgesetzt. Und dann lernt man per HELP oder sonst per TryAndError kenne, was alles möglich ist. Die Welt ist damit per Sprachinterface erlebbar und interaktiv.
Die Nachfolger haben da angesetzt und 1/3 des Screens sind nur zusammensetzbare Handlungsmöglichkeiten oder Befehle. Dadurch sieht die Welt sehr interaktiv aus, es sieht nach massiv vielen Möglichkeiten aus – wie bei den Textadventures.
Erst mit der Zeit wird klar, dass nur ein Bruchteil davon auch wirklich eine Auswirkung hat und das meiste eigentlichh nichts bringt. Dennoch ist man immer damit beschäftigt, zu schauen, wie es vorwärts geht. Ganz besonders dann, wenn die klassische Logik nicht mehr funktioniert und man* schon alles ausprobiert hat. Dann versucht man mal alles mit allem zu kombinieren. Auch das meist ohne Erfolg.
WeiterlesenIn Assembler simple – heute fast unmöglich
Will man ein GUI-Element machen, dass einfach alles dahinter „verschluckt“ und deaktiviert. ist das recht simple in Assembler. Man* zwingt den Computer einfach in eine temporäre Schlaufe. Man denke dies in Tools wie Unity/Unreal. Chancenlos diese einfache Lösung.
Techn. Herausforderungen von Point&Click-Adventuren [Notiz]
Die meisten Point&Click-Adventures müssen auch Dinge abbilden wie Kommentare, Infotexte, Gespräche und Inventare. Oder anders gesagt, das Genre benutzt so etwas wie ein GUI und damit wird alles viel komplizierter als fast alle anderen Genres.
Hier der Versuch ein GUI darüber zu blenden, in der dann der Text kommt. Fragen die Aufkommen, was passiert mit dem Rest des Spiels? Angehalten, läuft es weiter? Und wie verwaltet man* das?
