Archiv für den Monat: November 2023

Einfaches Action-Spiel in Basic (Experimentelle Archeologie)

Wie hier eingeführt verfügt der C64 ebenfalls über eine Basic-Schnittstelle als ‚Interface‘ für den C64 wie auch um zu Programmieren. Es ist mehr oder weniger die erste eingebaute Anwendung.

BASIC entstand bekanntlich 1964 als einfach erlernbare Programmiersprache, der man bis heute ihren klassischen Sprachansatz ansieht. Es ist eine Art Shellerweiterung mit Zeilen.

Viele 8Bit-Computer kamen ebenso wie der C64 mit Basic daher. Einige waren einfacher gestrickt als der C64 für Games andere mehr (vgl. Atari 400) in Sachen Farbe, Sprites, Scrolling. Diese Features wurden natürlich damals bis heute genutzt in BASIC-Aptippspielen, die zusätzlich noch oft auch Assemblerpasagen enthielten. All diese mache recht komplexe Spiele in Basic möglich. Am besten sieht man das bis heute etwa an Super-Marble-Boy des Amiga Game Design Veteranen Roman Werner.

Minimales Actionspiel in Basic?

Turnbasierte Spiele in Basic gibt es selbstverständlich viele. Eines der Kursspiele in den 80er Jahren war etwa HangMan. Simple und einfach und doch gut zu zeigen, wie eine Spielmechanik programmiert werden kann.

Standardbasic

Aber ist es möglich (eine Recherche steht noch aus) ein Action-Spiel zu machen, das allein in BASIC programmiert ist und auf allen Systemen läuft? Was natürlich jede Art von Spezialfeatures per se ausschliesst und das ausgehend vom C64 Basic.

Ausgabe: Print

In Sachen Ausgaben ist BASIC nicht gerade der Hit. Die meisten Basics aber besitzen sicher PRINT. Und was auch interessant ist – es gibt meist PRINT String und PRINT String Return. Einen allgmeinen Standard zum Positionieren des Cursors existiert – soweit bekannt – in Basic nicht. Es gibt nur sehr viele Hacks für jedes System. Und damit sollte sich doch auch ein Actionspiel machen lassen. Zudem bringt PRINT mit RETURN die Möglichkeit mit den Bildschirm zu scrollen.

Gamekonzept?

Ist es möglich in einer Linie ein Gamekonzept zu erschaffen? Ein einfaches Shoot-Em-Up oder Sammlerspiel? Diese Frage hat vor einigen Jahren eigentlich Robin Baumgarten beantwortet mit seinem Line Whobbler. Es ist ein eindimensionales Rollenspiel mit einem LED-Lichtstreifen und einem Extrakontroller. Das Konzept ist beeindruckend einfach und funktioniert sehr gut.

Ausgehend aus diesem Konzept liess sich schnell etwas entwickeln, was an Line whobbler erinnert, aber visuelle einen anderen Weg ging.

Version 1: ein kontrollierbarer Punkt – Endpunkt

Ein simple kontrollierbarer Punkt. Er kann nach links und rechts gesteuert werden und zieht automatisch gescrollt einen Schweif hinter sich her.

Technisch wird zuerst die Position per Space geschrieben und danach der Avatar hingehängt. Das Ganze ist je weiter links umso schneller (weniger Spaces), als gegen rechts. Das Ergebnis ist interessant.


Allerdings bricht das Spiel schon die erste Regel: Es nutzt einen Peek, um die Tastatur auszulesen. Basic war 1964 in dem damaligen Paradigma natürlich als Input/Output-Sprache (ohne Keypressed-Abfragen – sondern mit Return als Abschluss einer Eingabe – Input) designed.

Version 2: Fange ein Zeitextra

Die zweite Version addierte einen Extra, das man holen musste, um weiterspielen zu können. Sobald es gefangen war, wurde es per Zufall wieder anderswo ‚gespawnt‘. Im gesamten eine minimale Gamemechanik. Idee: Läuft die Zeit aus, ist das Spiel zu Ende. Wie weit bist du gekommen?

Weiterlesen

C64: Der ShellEditor – ein mysteriöses Interface (aus Darthmouth?) – Starting up mit Basic für alles

Viele der 8Bit-Homecomputer kamen mit einem Basic als Entwicklungsumgebung und auch als eine Art Betriebssystem daher. Disketten ansehen & Programme laden lief letztlich alles über Basic. [Siehe auch andere BlogEinträge in diesem Blog] So auch beim C64.

Basic war so quasi ein Verkaufsargument: Du kannst auch selber etwas mit dem Computer machen. Vergleichweise gut kann man das gerade beim ZX81 sehen. Da wird der Rechner als erweiterter Taschenrechner verkauft vom Design bis zur mitgelieferten Anleitung.

Das Basic ist beim C64 im ROM vorhanden und wird in den Speicher geladen beim Aufstarten. Und ist anscheinend 64k – 38911 Byte gross. Es ist ein schon damals uraltes Basic von Microsoft (siehe dazu Blogeintrag um Jack Tramiel).

Computer Handling in Basic

Der Text-Bildschirmspeicher (Textmode) ist dabei eine Art Editor. Lädt man etwa das Listing einer Diskette mit

LOAD "*",8,1

So befindet sich danach das Listing im Speicher. Und mit List lässt es sich ausgeben.

LOAD "TEST.PRG",8,1

Danach tippt man ein load „test.prg“,8,1 und lädt das Programm oder man fährt mit dem Cursor zur entsprechenden Zeile und hängt davor ein ‚load „‚ und danach ein ‚“,8,1″ und drückt RETURN. Schon wird das PRG geladen.

RUN

Mit dem ebenfalls Basic-Befehl RUN startet man das Programm. Und zwar egal ob, eine EXE oder ein Basic-Programm. Letztlich sind alle Binaries Basic Programme.

Mischung aus Shell und Editor (ShEd)

Das C64 Basic Interface ist eine Mischung aus Shell und Editor. Es ist eine Art Shell, weil man Befehle eingeben kann überall. Ein Editor, weil man konkret editieren kann. Dennoch ist es keine reine Shell (wie bei Unix, Apple II, MS-DOS, die ja eigentlich nur eine Zeile ist, in der Befehle eingeben werden können. Das Davor und das Danach ist der Output der Shell. Das ist im C64 Basic Editing fundamental anders. Hier ist alles gemischt. Hier führt das Return die aktuellste Zeile aus. Ein ähnliches Konzept findet sich auch noch in der Oberfläche der LILITH, wo auch jeder Text ausgeführt werden kann (soweit ich weiss, unabhängig vom Prg).

Tastatur

Im der Prä-GUI-Zeitalter ist die Tastatur, das wichtigste Eingabegerät. Sie ist tatsächlich qualitativ recht hochwertig für einen so ‚billigen‘ Computer (was ja im Design berücksichtigt wurde). Erinnert an die PC1-Tastatur. Auch die Höhe wirkt sich nicht, wie erwartet negativ aus, man kann damit gut arbeiten. Allerdings gibt es auch Unverzeihlichkeiten: etwa kein Cursorfeld (dadurch ist es wirklich schwierig zu navigieren auf der Oberfläche). Es muss mit Shift-Pfeil-Rechts nach links navigiert werden und dasselbe nach oben.

Die Tastatur übernimmt auch viele Dinge, die später dann ins GUI ausgelagert wurden und so strotzt sie wie fast alle 8Bit-Tastaturen vor Spezialktasten (Ebene Grafikblöcke, RUN/STOP etc).

Editing Basic

Das Basic nutzt nun diesen ShellEditor-Komplex auch massiv. Zusätzlich kommt hinzu, dass beim Editieren des Sourcecodes die Zeilennummern wichtig sind. Damit scheint der Editor zu erkennen: „Aha es gehört zum Source-Code“.

Weiterlesen

Erfahrungsbericht 1989: Listingspiel entwickeln und veröffentlichen

1988 hatten wir (mein Bruder 16, ich 17 und meine Schwester 15- wir lebten auf Bauernhof in der Ostschweiz Region Bodensee.) einen Atari 520 ST, den wir damals uns über den Musenalpexpress (eine weitverbreitete Sache wie man auch hier sieht) – einem papierenen Socialmedia aus heutiger Sicht (viele Gedichte und eigene Texte) – gekauft hatten mit eigenem Geld (zwei Jahre davor?).

Im Gespräch war auch noch ein Schneider CPC (mit 3.1 Zoll Disketten). Am Ende machte es aber (Gott sei Dank) ein Computer mit einer grafischen Benutzeroberfläche wie der Mac, den ich 2 oder 3 Jahre vorher in einem Computercamp in Romanshorn kennen gelernt hatte. Ein Ah-Erlebnis im Vergleich zur MS-DOS-Shell in der wir Basic starteten und programmierten in dem Camp und dem C128 in der Sekundarschule. Der Atari ST war günstig und mit bestem Preisleistungsverhältnis und er war vorallem modern: Grafik, GUI, Maus und schnell. Aber: Als Erstes mussten wir unser Single-Disk-Laufwerk (360kb) mit einem DoubleDisk (720kb) nachrüsten. Dieses besorgten wir uns ‚ennet‘ der Grenze in Konstanz.

Unser Haupttreffpunkt war aber der Computerladen „Rietman“ in der Frauenfelder Innenstadt. Wo man nach der Schule hinging und Dinge wie Spiele ausprobierte, die man sich nicht leisten konnte.

Aus einem Ricardo-Inserat, der Sticker auf einem Commodore PC.

Weiterlesen

Entscheidungspoint: Wie weiter nach den 8bit Prozessoren bei den Homecomputern? Eine oft gewählte Option – Motorola 68000 in Mac, Atari ST, Amiga, Sinclair QL, NExT [InArbeit]

Die 70er und Anfang 80er Jahre waren geprägt von 8bit-Prozessoren allen voran dem 680x (der als teuer galt), 650x (der darauf schon billiger entworfen wurde), japanischen NEC-Varianten und den Intel-‚kompatiblen‘ 8008 und ZX80. Diese waren billig aber durch ihre 8Bittigkeit auch beschränkt. Was allerdings nicht all zu sehr störte, da die Anforderungen nicht besonders hoch waren (Selbst die Arcades seit Space Invaders 1978 arbeiteten mit Prozessoren) und viele Extras im Gamebereich wurden von der Hardware ausgeführt wurde (etwa Sound, Sprites oder Scrolling).

Der Prozessor & Assembler

Die Zukunft war zu dieser Zeit weiter offen, als dies heute der Fall scheint im Rückblick. Es gab viele verschiedene Computerhersteller mit eigenen Hardwaredesigns. Der Hauptprozessor war zwar nur ein Teil des Computers. Da aber gerade im Gamebereich viel in Assembler gemacht wurde, war der Prozessor bzw. die spezifischen Kenntnisse davon schon massgeblich in Sachen Portabilität. Danach folgten Speed des Prozessors oder/und Videofähigkeiten (Sprite, Scrolling) und Audiofähigkeiten. (Durchgesetzt haben sich bekanntlich vorallem die Intel-Schiene in den 90ern und PowerPC und heute wieder vermehrt die ARMs).

Siehe dazu auch im Vergleich die Entwicklung der Videokonsolen https://de.wikipedia.org/wiki/Spielkonsole#8-Bit-Ära_bis_zum_Video-Game-Crash_(November_1976_bis_1982) oder die Prozessoren der Arcades.

Die neue Generation 16/32-Bit: 68000

Neben Intels Schiene kam vorallem ein Prozessor mehr und mehr in den Fokus der Firmen und der Entwicklung: Das Nachfolgemodell des Motorola 680x. Der Motorola 68000 wurde 1979 auf den Markt gebracht. Er besitzt 32Bit-Register, einen 32Bit Adressraum, 8 Datenregister (D0-D8) und 8 Addressregister (A0-A8) und einen 16 Bit Adressbus.

// ToDo: Ähnlichkeiten/Weiterentwicklung 680x vs 68000

Wikipedia fasst den Werdegang folgendermassen zusammen:

68000: Designed for Workstations

Bereits zu Beginn der 1980er Jahre fand die CPU, dank optionaler MMU, ihren Weg in die Unix-Welt. Sie wurde in hohen Stückzahlen in die Workstations von Apollo Computer (Apollo), HP (HP 9000-300) und Sun (Sun-1) oder auch von Digital Equipment Corporation (Vax 100) und SGI verbaut.

Mitte der 1980er Jahre folgten dann Personal- und Home-Computer, der erste war Lisa von Apple, die schon bald vom Macintosh (Mac) abgelöst wurde. Er wurde auch im CommodoreAmiga, im Atari ST und Sinclair QL (68008) verbaut.

Ende der 1980er und Anfang der 1990er fand er sich dann in Spielkonsolen wie dem Sega Mega Drive oder dem Neo Geo. Auch in Schachcomputern (wie z. B. im Fidelity Mach IV als 68020 mit 20 MHz und Mephisto Amsterdam als 68000 mit 12 MHz) wurde der Prozessor verwendet.

https://de.wikipedia.org/wiki/Motorola_68000

Ein gewichtiger Punkt ist sicherlich auch, dass der 68000 auch in vielen Arcades zum Einsatz kam. Hier spielt der Preis der Platine bei einem Kasten der 5-10k kosten kann nicht so eine Rolle.

Video game manufacturers used the 68000 as the backbone of many arcade games and home game consoles: Atari’s Food Fight, from 1982, was one of the first 68000-based arcade games. Others included Sega’s System 16Capcom’s CP System and CPS-2, and SNK’s Neo Geo. By the late 1980s, the 68000 was inexpensive enough to power home game consoles, such as Sega’s Sega Genesis console and also the Sega CD attachment for it (A Sega CD system has three CPUs, two of them 68000s). The multi-processor Atari Jaguar console from 1993 used a 68000 as a support chip, although some developers used it as the primary processor due to familiarity. The Sega Saturn console used the 68000 as a sound co-processor. In October 1995, the 68000 made it into a handheld game console, Sega’s Genesis Nomad, as its CPU.[44]

https://en.wikipedia.org/wiki/Motorola_68000

Neu, einfacher, schneller und komfortabler: Motorola 68000

Das Wichtigste ist dabei der „Quantensprung“ in Sachen Speed und Handhabung.

Anzahl Befehle

Rechnen & Co

Das Wichtigste in Apps aber vorallem in Games ist Datenprozessing/Datenmanagement, also das Rechnen mit Daten, Verschieben von Daten und das Abprüfen von Daten.

Datenraum

Rechnen mit nur 8bit ist unendlich mühsam. Denn in 0-256 oder -128 – 128 passen einfach nicht viele Daten hinein. Dies geht einigermassen bei einfachen Systemen mit einem Videoscreen von 128 x 128 aber endet dann bei Computern wie dem C64. Hier sind die Screencordinaten über dem 8bit-Datenrange und es muss permanent mit Low- und High-bytes gerechnet werden. Dasselbe gilt natürlich auch für das konkrete implementieren von Spielmechanik. Hier überlegt es sich der Entwickler* zweimal, ob nun alles zwischen 0-256 spielt oder zwischen 0-512 etc.

Der 68000er bietet mit seinen möglichen 32bit natürlich viel mehr Datenformate an: Es gibt also nicht nur 0-256 (byte), sondern 0-512 (word), 0-1024 und 0-2048.

In Assembler ist das auch minimal einfach nutzbar:

move.b #4,d0
move.w #510,d0
move.l #2111,d0

Rechnen

Der 6510 (es gibt auch komfortablere 8bitter mit mehreren Datenregistern) hatte nur ein Datenregister (a) und zwei Indexer (x,y). Man muss also alles in dieses Register reinladen, dort rechnen, vergleichen und es dann wieder verteilen. Die Indexer helfen dabei, dass man in Listen Dinge laden und speichern kann (relativ: Speicherstelle,X entfern davon). Bei nicht so komplexen Dingen kann natürlich (langsamer) im Speicher gerechnet werden. Dadurch entsteht sehr viel Verwaltungs- und Managementaufwand. Die Metaphorik hinter dem Assembler ist das Reinladen der Zahlen und dann Addieren.

lda #10 ; lade 10 in den accumulator
clc     ; je nach mode: clearing der statusbits
sec     ; spezieller mode
adc #5 ; addiere 5

Im 68000er-Assembler sieht das folgendermassen aus:

move.l #10,d1 ; schiebe 10 ins datenregister 1 (lösche es acuh gerade)
add.l #5,d1 ; addiere 100 als long-word

Der 68000er hat auch in der Assembler Metaphorik einen Sprung gemacht. Es erinnert jetzt mehr an höhere Programmiersprachen:

oder anders gesagt:
10 -> d1 oder moderner d1=10
d1 + 5 -> d1 oder moderner d1 += 5

Noch kein Standard-Floating-Point-Unit

Immer wichtiger werden auch Floating-Point (gerade auch für 3D). Dies muss standardmässig weiterhin simuliert werden.

Memory

Paging (Aufteilung des Speichers in Segmente). Der Unterschied zwischen Zahl und Adresse verschwindet weitgehend.

Grafik

Ein Game programmiert durch die Geschichte der digitalen Games abhängig von der Technologie – SQUARES [In Arbeit]

Wie sind Spiele entstanden? Was war der entsprechende Aufwand ans Design, die Programmierung und letztltich die Spielmechanik. Wie lassen sich diachron Aufwände vergleichen?

Spiel( vorhandene Technologie der Zeit )

Eine Idee ist es, ein Spiel zu nehmen und zu schauen, wie aufwändig war es konkret dieses Spiel umzusetzen in der jeweiligen Zeit mit der jeweiligen Default-Game-Technologie. Es soll also nicht nach den On-The-Edge-Games gefragt werden – diese waren je nach Platform sowieso unterschiedlich sondern nach einem einfachen Game realisiert durch die Zeit und wo nicht vorhanden als experimentelle Archeologie ’nachgezimmert‘.

Ansatz: Klassiker>Today

Selbstverständlich gibt es Spiele, die durch die Spielgeschichte immer wieder realisiert wurden etwa die klassischen Spiele wie PacMan oder Galaxy etc. Dies wäre ein Klassiker-Today-Ansatz. Dazu gibt es schon – vorallem in Magazinen – angefangene Reihen, die diese Entwicklungen zeigen. Das problematische hier – Entwicklung wird als vorwärtsgerichtete „Entwicklung“ gesehen und es wird wenig um die möglichen Wendungen diskutiert.

Ansatz: Today>Yesterday

Ein anderer Ansatz – und der wird hier favorisiert – ist es, ein – inzwischen ausrangiertes – Game zu nehmen, das relativ spät auftauchte (Flash-Game) und das anders als all die Spiele der 80er Jahre über kein wirkliches Setting verfügt und zudem eigentlich ein ‚Endlosrunner‘ ist. Also ein Spiel, das sehr früh hätte hergestellt werden können, aber – Stand 2023 – über keinen konkreten Vorläufer verfügt. Und das Spielmechanisch wie auch nicht visuell (abstrakt). Das Spiel sollte auch einfach umsetzbar sein und einige Patterns des Gamedesigns zeigen können.

SQUARES (Flash)

// Muss noch gefunden werden – gab es diese version je?
// Todo: Anfrage @ gavin

Entwickler: Gavin Shapiro

Oder ist hiess das Ursprungsspiel gar SQUARED? (IPhone?)
https://iphonetech78.wordpress.com/2009/11/02/squared-game-review/


SQUARES 2 (Flash) 2010?

2006: https://gigazine.net/gsc_news/en/20061006_squares2/

Anbei wird mit SQUARES 2 gearbeitet. SQUARES 2 führte Extras ins Gameplay ein. Diese lassen sich einfach wegdenken.

Entwickler: Gavin Shapiro

„Squares 2, a popular flash game from the early 2000s. Set to the beat of Daft Punk’s 1997 song Revolution 909, you guide your cursor to black squares while avoiding the red ones.“

https://archive.org/details/squares2_202011

Die konkrete Grundspielmechanik (Squares 1):

Prinzipiell gibt es Objekte – Quadrate. Diese unterscheiden sich in Farbe (Rot, Schwarz) und Grösse. Es gibt eine Art Freund-Feind-Unterscheidung (Codierung). Schwarz ist gut, Rot – böse. Die Objekte bewegen sich horizontal oder vertikal. Sie beeinflussen sich nicht. Der Spieler konktrolliert einen Avatar via Maus (Flash) – ein drehendes schwarzes Quadrat. Es gibt also eine relativ absolute Kontrolle im Gamplay. Das Spiel endet, wenn der Avatar ein rotes Quadrat berührt. Es kommen immer wieder neue Objekte hinzu.

Es gibt Punkte für das „Einsammeln“ von schwarzen Quadraten. Je nach Grösse gibt, es mehr oder weniger Punkte. Die Micromechanik ist dementsprechend einfach: Den roten Quadraten ausweichen, die schwarzen einsammeln. Die Makromechanik ist es, möglichst viel Punkte zu machen (bzw. möglichst lange durchzuhalten). Die Geschwindigkeit des Spiels steigt stetig, es gibt eine Art Levelssystem (Geschwindigkeit und Anzahl Quadrate).

Dabei gibt es durchaus Strategeische Actionentscheidungen, da das Ganze eine Art dynamisches Labyrinth ist. Der Spielende* muss also vorhersehen, wo enstehen Wege (wenige rote Quadrate etc) , wo kann man welches Risiko eingehen. Die Ränder etwa sind interessant, aber auch gefährlich – weil man ja nicht sieht, was gerade kommt.

SQUARES 2 auf dem InternetArchive:
https://archive.org/details/squares2_202011

Technische Bedingtheit

Technisch ist das Spiel aus heutiger Sicht banal. Verwaltung von verschiedenen Objekten, verschiedene Grössen, die in 4 Richtungen fliegen können, verschieden schnell und ein Box-Collision-System für Avatar vs allen Objekten. Grafik: Sehr einfach gehalten mit der primitivsten Sorte von Primitiven – Rechteck konkreter Quadrat. Lässt sich einfach realisieren.

Squarez (Intellivsion, Assembler)

SQUAREZ (Vectrex)

Squarez (C64, 6510 Assembler)

Squares ( Flash ) Original

Diskussion zur Flash-Umsetzung.
https://archive.org/details/squares2_202011

Squarez (Unity3d)

not yet done

SquareU ( Unreal – BluePrint )

Siehe Realisierung.

https://imachina.zhdk.ch/index.php?id=114460&argument=&argumentsub=

SquareZ (Pico8 – Fantasy Console)

https://www.lexaloffle.com/bbs/?tid=34622

// Todo: Beschreibung & Kategorien