GAMELAB.CH

Früher wurde beim Fernsehen viel gezapped. Das heisst: Es wurde weitergeschaltet, ein anderer Fernsehsender und damit Inhalt gezeigt.

Es war der Versuch Herr oder Frau zu werden über das Massenmedium „Fernsehen“ mit seinem linearen Programm. Es ging von Fernsehsender 1-7 (mehr gab es nicht). Dabei wurde kurz reingeschaut und dann wieder weitergezapped bis die Aufmerksamkeit irgendwo einige Zeit hängen blieb. Es lief ja auch immer öfter Werbung, gerade mit der Einführung der Privatsender. Und es bildeten sich geradezu Sendergruppen, diese synchronisierten dann selbstverständlich auch noch ihre „Werbeunterbrechungen“, so dass es auch da wenig Entkommen gab. Also Sender wechseln, sofort und per „Klick“! Oder war es gar ein „Abschiessen“? Siehe dazu auch Zapping auf Wikipedia >

Der folgende Video heisst zwar „Zappen durch … “ ist aber insofern nicht korrekt, als dass der Controller an der Fernbedienung nie so lange gewartet hätte bis zum Weiterschalten!

Voraussetzung war natürlich die kabellose Fernbedienung – sonst hätte man/frau/teen/kind aufstehen müssen und zum Fernsehgerät gehen. Es sollte so etwas wie die Kontrolle zurückgeben.

Mehr dazu auf Wikipedia >

ABAgames und damit ist bald Jahrzehnten ein Geheimtipp für innovatives Gameplay. Und so schlägt der Entwickler von ABAgames aus Japan wieder zu mit zwei 1D-Gameplays: PacMan und einem Shooter.

https://abagames.itch.io/paku-paku

https://abagames.github.io/crisp-game-lib-11-games/?chargebeam

It’s one of the most fundamental questions in the demoscene: why is there almost no visible source code in demos, even though it’s actually all about code. Ultimately, that’s where the magic is, the magic. This is especially true for the sub-genre of size coding. It is always about the – scientific – once important, now rather obsolete – question: What is the smallest algorithm to solve a problem?

One can now answer: Why should you? It’s just distracting! Neither the performing arts, nor texts, nor theater, nor film usually do that. But there is the 4th wall breakthrough, there is the Dada way of creating a poem or the algoart that exposes its constructions (such as Tinguely), where you are sometimes even standing in the construction. All these works of art break the cage of construction and allow us to look into the algorithms, ultimately deconstructing the simple consumption of “Ahhh” or “Ohh” or making it even more incredible. The Magic Circle itself becomes the subject. It would therefore be an empowerment. And one difference to older physical algoart is that digital algoart is not carried out by machines or humans but by computers. So we write to computers first and not to people.

Die Stadt schrieb vor einem Jahr oder schon 2 Jahren (?) einige Räume aus in Oerlikon für eine Zwischennutzung. Die Dauer war 5-6 Jahre.

Der SwissGameHub suchte auch nach einer neuen Bleibe. Ein Raum war besonders interessant – die folgende Halle: 2500 m2 und es war davor schon ein CollabSpace gewesen. Die Stadt würde da den Mietern auch sehr entgegen kommen mit Inventar wie Tischen etc.

Eine Idee, die damals aufkam: Warum nicht diesen Raum attraktiver machen und ein bisschen Kultur reinbringen. Ein Game-Museum. Dadurch würde der Ort das Gamedesign in der Stadt verankern und die digitalen Welten würden endlich einen eigenen Ort haben. Das würde natürlich als Nebeneffekt auch die die Attraktivität fürs Gesuch steigern.

Sobald das Gesuch dann wider Erwarten bewilligt wurde, ging es daran dieses Konzept des Museums auszuarbeiten (Wobei das Museum im Endkonzept anscheinend nicht mehr Teil des Vertrages war). Der neue Name des Projektes House of Gamez. Mit dabei waren alte Köpfe neben Beat Suter, René Bauer (gamelab.zhdk.ch) auch Ivo Vasella vom outlane.ch. Das dabei entstandene Konzept und die Vorarbeiten findet sich als Projektbeschrieb bei gamelab.zhdk.ch hier. Es war schon sehr ausgereift und die wichtigsten Sachen waren geklärt.

Und dann entschied sich der SwissGameHub im Feb 2025 dagegen: Begründung kein Platz!

(Die Begründung war nicht: „Wir können es uns nicht leisten!“ Das wäre etwas gewesen, was man ja noch verstehen könnte.)

Selbstverständlich ist dieser Entscheid zu respektieren, wenn auch nicht unbedingt nachvollziehbar bei dem vielen Raum. Was diese Entscheidung persönlich bedeutet und wieviel Vertrauen zerstörte wurde, soll hier nicht diskutiert werden. Was aber in der Geschichtsschreibung der Gamekultur der Schweiz interessant ist, sind die Voraussetzungen und Implikationen dieses Entscheids.

(Tipp von Francisco V)

Die Perspektiven (!) von PacMan sind recht seltsam. Diese Tradition der verschiedenen gleichzeitigen Perspektiven gibt es aber auch im Brettspiel konkret beim „Verrückten Laybrinth“. Jetzt stellt sich natürlich die Frage, ist DAS VERRÜCKTE LABYRINTH ein Spiel in einer langen Reihe solcher Visualisierung oder einfach ein „Nachfolger“ der Idee von PacMan. Vergleiche dazu auch Landlords Game.

Beim DAS VERRÜCKTE LABYRINTH handelt sich um ein Spiel, wo der Möglichkeitsraum/Agency der Spieler das Schieben eines Streifens des Labyrinthes ist. Es wird also eigentlich ein Slice des Raumes verschoben. Dennoch sind die Avatare stehend als Figuren auf dem Brett.

Die Semiose startet mit dem Frame der Verpackung (heute): und klar – 3D-Labyrinth schräg von oben.

Auch die Geister und Schätze sind 3D.

In der „Realität“ des Spieles sieht es dann so aus:

Die Welt ist flach. Auch wenn es sicher einen Prototypen gab in 3D .-) Die Figuren sind symbolisch dargestellt: Die Grösse ist symbolisch. Die Objekte sind in ihrer Grösse nicht vergleichbar (Diamant, Käfer etc). Sie füllen immer einfach ein Tile aus. Die meisten Objekte sind von der Seite dargestellt (und zwar von verschiedenen Seiten (!) oder dann von oben (Käfer). Es kommen also verschiedenste Perspektiven zum Einsatz. Auch das Laybrinth scheint von der Seite dargestellt zu sein oder doch von oben? Dies bleibt unklar.

Über dem allem gibt es noch die Avatare in echten „Plastik-3D“.

See also: SizeCoding/Nanogames as a method of science: https://research.swissdigitization.ch/?p=2819

What is a ShootEmUp? This question alone answers the outcome of a nanogame development. But perhaps this will only crystallize during nanogame development and the definition will have to be changed several times to make it appear feasible.

The ShootEmup – the tasks

As we all know, there are a large number of different ShootEmUps. The simplest variant remains the subgroup of Space Invaders and later Galagas. Here the management/game mechanics are mostly based on the management of sprites independently of a background (or interactions with the background, see Xevious etc.) This means that only one type of object has to be managed (see games such as Breakout).

The most important interactions/queries are collisions. There are two different types of objects.

Own/Avatar objects:

Your own objects are divided into the avatar and the shot(s).
Avatar controls: Left and right of the avatar. Limitation of left and right.
Shooting: This interaction was also replaced by autofire in the previous case (idea from a nanogame developer). Less code
Shoot: Moves up.

Enemy objects:
The classic opponents react to the shot (destruction) and the shots (are not destroyed by the shots). To simplify matters, the enemy shots have been deleted in this case (additional cases: shot does not hit shot).
Enemy objects fall downwards. Move neutrally or tend towards the avatar.

Fail condition:

The opponents come behind the avatar and/or hit the avatar. In this case, however, the second implementation was deactivated again because the game was too difficult.

A concept similar to the one presented here was also used for a 256-byte nanogame for PICO8 for the LoveByte competition 2024.

Look also at TaipDefendor_256b (256 Bytes) and here the deluxe variant ION382b (386 Bytes in pico8)

Wie sollen wir beschreiben, was wir (tun und) getan haben, wenn wir etwas herstellen bzw. hergestellt haben mit einer AIs. „Ich habe einen Text geschrieben“ oder „Ich habe ein Bild gemacht bzw. generiert?“ oder „Ich habe dieses Programm mit Hilfe einer AI geschrieben?“ (Wobei dann die Frage des Anteils wichtig ist)

Wir – der ehrlichere Autor*

Der Vorschlag hier: Wir sollten das „wir“ verwenden und das aus mehreren Gründen. Dabei sollten wir momentan unterscheiden zwischen einem Borg-Wir (nach der Schwarmintelligenz der Borgs in Star Trek) und einem Mäjestätik-Wir.

GameDesign und die Weltgeschichte

Dass das GameDesign leider einen Einfluss auf die Weltgeschichte hat, ist etwas, was man langsam entdeckt. Der MagicCircle ist leider in Sachen Ideen durchlässig. Dabei ist das Spielen (und auch Designen) von Games eine der einfachsten Arten Computer zu beschäftigen/benutzen: Es ist schon eine Motivation in sich selbst – Spiel=(Arbeit&)Konsum. Dabei muss man* sich auch nicht mit komplexen Problemen aufhalten, sondern kann einfachste Spielmechaniken/Motivationsmechaniken und Weltbilder nutzen inklusive Bestrafung und Belohnung. Es sind erschaffene Probleme wohlgemerkt, die gelöst werden müssen. Das ist anders als bei Textverarbeitungen, die „nur“ Tools und Mittel zum Zweck sind, die Welt aber natürlich massiv verändert haben.

Es erstaunt deswegen kaum, dass viele im GameBusiness angefangen haben, eine der ersten digitalen Industrien – wie etwa Jobs/Wozniack (Breakout) oder schwierigere Persönlichkeiten wie Musk oder auch Steve Bannon (der bekennt, er habe da viel ‚gelernt‘ .-(. In diesem Sinn ist die Geschichte des GameDesigns auch eine Geschichte von Leuten, die danach in anderen Bereichen ‚berühmt‘ und teilweise ‚berüchtigt‘ wurden. Und vielleicht sagen deren Spiele, auch etwas über sie selbst aus – ganz im Sinne von „An ihren Spielen soll man sie messen“ .-)

Zusätzlich ist es wichtig, diese Spiele einzuordnen und zu kontextualisieren. Denn: All zu schnell wird damit weiter an der angeblichen „Genialitätsgeschichte“ der „Persönlichkeiten“ gebastelt. Musk und seine Anhänger tun das gerade wieder – dieses mal mit einem sehr alten Spiel. Es unterstreicht angeblich seine Legende vom TechVorreiter. Wobei er sich ja mehrheitlich erst später eingekauft hat wie etwa bei Tesla. Im Folgenden scheint es aber um ein Produkt zu gehen, das tatsächlich von ihm selbst stammt. Und da stellt sich die Frage: Warum geht es, was sagt es aus? Wie kann ich handeln (gameplay)? Was ist es für ein Wertesystem? Was für eine Motivationsmechanik?

BLASTAR 1984 – Übliches Listinggame

Von Elon Musk gibt es wie schon erwähnt das Game: „Blastar“. Der Titel könnte eine Lesart von „Blaster“ und „Star“ sein oder einfach anders ausgesprochen „Blaster“ (was allerdings schon für einen Spielautomaten vergeben war). Musk scheint als 13 Jähriger [Entwicklung mit 12, Publikation mit 13] (Forschung dazu steht noch aus) ein Listinggame eingeschickt zu haben und es wurde genommen und publiziert für 500$.

Code Golfing – size coding

Die Demoscene ist eigentlich Teil der grösseren Bewegung des Code-Golfings. Code Golfing ist ein Wettbewerb zur Frage, wie kann man* ein Problem (etwa den kleinsten Compiler, was zu FALSE, Brainfuck und Co führte) mit möglichst wenig Code in einer spezifischen Umgebung lösen (oder wie schaffe ich es eine Umgebung zu gestalten in der Probleme mit möglichst wenig Code gelöst werden können). Konkreter: Was ist der kleinstmögliche Code für ein Problem oder sportlicher: Mit wie wenig Schlägen komme ich ans Ziel. Mehr zu Codegolfing hier >

Demoscene: Feste Grösse, Golfen mit dem Resultat

Die Crackerszene des 8- und 16-Bit lebte vom Dilemma sich darstellen zu wollen und gleichzeitig wenig Platz zu haben (Die Disketten waren schon so rand voll mit Spielinhalten). Was zu interessanten Intros führte in denen die Cracker* alle funktionalen Inhalte wie Softwareübersichten, Auswahl, Trainer (Cheatmodes), Infos, Kommunikationswege und Werbung über sie (Postadresse, BBS), Greetings, Hatings möglichst kreativ verpackten in Texte, Scrolltexten, Spielen mit Schriften, Effekten. Es war also ein weiterer Wettbewerb entstanden: Wer kann wie viel mit wenig Platz. Dadurch wurden auch die teilweise ‘qualitativ’ schlechten Spiele wenigstens in ihren Intros etwas Grosses. 

Die Demoscene, die sich bekanntlich aus den begrenzten Ressourcen der Crackerszene entwickelte, hat für die Contest Kategorien geschaffen und damit die Ressourcen beschränkt 8byte, 64byte, 256byte (historische Kategorie wegen den ), 512b, 64kb etc. So dass es weiterhin heisst: Wer kann welche Effekte, Demos, Stories in minimalste Anzahl von Programm verpacken. Und damit alle die gleichen ‘ Chancen’ haben – begrenzt man die Kategorien. Ein Beispiel dafür wäre etwa: LoveBytes/Kategorien.

Neben den klassischen Computern (C64, Spectrum, Atari ST, Amiga, Windows) und Consolen (Atari 2600) haben seit längerem Fantasy Consolen/Computer Einzug gehalten wie Tic80 oder Pico8. Mehr dazu hier >

Gamedesign-Golfing, Nanowettbewerb

Zunehmend taucht nun in Demosceneevents auch die Kategorie «Nanogames» auf. Meist sind sie dann – blöderweise in der selben Kategorie – wie Demos. Etwa 256b Games. Dabei wird wenig Rechnung getragen, dass eine Spielechanik meist auf if und loops Bedingungen aufbaut. Vermutlich wäre eine 384 Byte Untergrenze etwa für Fantasy Consolen sinnvoll. Nichts desto trotzt führt das zur Frage: Was lässt sich in so wenig Bytes machen? Und die Frage dahinter: Was ist Gamedesign Golfing? Was ist das Verhältnis von Code und Game von den Visuals bis zur Mechanik. Und vielleicht interessanter: Was sind die kleinstmöglichen Spielmechaniken für ein Genre?

Im Nachfolgenden soll anhand des Lovebyte-Contest 2023 diesen Fragen an der Oberfläche nachgegangen werden.