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

Experimental digital archeology: Coding a game through the technical platform history. Case: SQUARES [In progress]

How were games created? What was the corresponding effort for the design, the programming and ultimately the game mechanics? How can diachronic efforts be compared?

Game( existing technology of the time ) – Game depends on the technological possibilities

One idea is to take a game and see how complex it was to realise this game in the respective time with the respective default game technology. So the question is not about on-the-edge games – these were different depending on the platform anyway – but about a simple game realised through time and, where not available, ‘recreated’ as an experimental archaeology.

Approach: Classics>Today

Of course, there are games that have been realised time and again throughout the history of gaming, such as the classic games like PacMan or Galaxy etc. This would be a classic-today approach. This would be a classic-today approach. There are already series – especially in magazines – that show these developments. The problem here is that development is seen as a forward-looking ‘development’ and there is little discussion about possible twists and turns.

Approach: Today>Yesterday

Another approach – and the one favoured here – is to take a game that has since been discarded, which appeared relatively late (Flash game) and which, unlike all the games of the 80s, has no real setting and is also actually an ‘endless runner’. In other words, a game that could have been made very early on, but – as of 2023 – has no concrete predecessor. And neither mechanically nor visually (abstractly). The game should also be easy to realise and be able to show some patterns of game design.

SQUARES (Flash)

// Still to be found – did this version ever exist?
// Todo: Enquiry @ gavin

Developer: Gavin Shapiro

Or was the original game even called 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/

SQUARES 2 is currently being used. SQUARES 2 introduced extras into the gameplay. These can be easily removed.

Developer: 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

The concrete basic game mechanics (Squares 1):

In principle, there are objects – squares. These differ in colour (red, black) and size. There is a kind of friend-foe distinction (coding). Black is good, red is evil. The objects move horizontally or vertically. They do not influence each other. The player controls an avatar via the mouse (Flash) – a rotating black square. There is therefore relatively absolute control in the gameplay. The game ends when the avatar touches a red square. New objects are constantly being added.

Points are awarded for ‘collecting’ black squares. Depending on the size, more or fewer points are awarded. The micro-mechanics are correspondingly simple: avoid the red squares and collect the black ones. The macro mechanic is to score as many points as possible (or to hold out as long as possible). The speed of the game increases steadily, there is a kind of levelling system (speed and number of squares).

There are also strategic action decisions, as the whole thing is a kind of dynamic labyrinth. The player* must therefore anticipate where paths will be created (few red squares, etc.) and where risks can be taken. The edges, for example, are interesting, but also dangerous – because you can’t see what’s coming.

SQUARES 2 on the InternetArchive:
https://archive.org/details/squares2_202011

Technical conditionality

Technically, the game is banal from today’s perspective. Management of different objects, different sizes that can fly in 4 directions, different speeds and a box collision system for avatar vs. all objects. Graphics: Very simple with the most primitive kind of primitives – rectangle concrete square. Easy to realise.

Squarez 2014 (Intellivsion 1979+, Assembly)

Implementing squarez on the Intellivision was very easy. On the one hand, there are simple examples. A console is primarily designed to make games. All functionalities were available: Sprites, simple joystick support, display of text for the high score. These are all things that later home computers lacked by default directly in assembler.

SQUAREZ 2016 (Vectrex 1982+)

Vectrex is technically an interesting console. The technical background is very good: a 6803 processor, the blueprint for the 6502, easy to programme and consistent compared to the 6502. And then of course the vector screen. This requires new and different design challenges. Everything has to be drawn in one stroke. There are 3-4 lines per sprite. But things also look very modern = abstract. It is more difficult to differentiate between the various blocks. Here it would actually be easier to switch to a setting. There are no sprites. In other words, the whole thing is like developing a modern pre-Unity and Unreal game. More or less management work. Everything is contained in the data (so there is no position data in the sprites).

Compare this with the resulting game:
VecZ and the demo .

Squarez 2023 (C64, 6510 Assembly)

// ToDo: Details …

Squarez Amiga 2024

Here it is clear: it would be possible to make a concrete setting, the whole thing would not have to be abstract. Throughout the development process, you are tempted to realise the whole thing with a setting like tanks, aliens or soldiers.

ToDo: More details about the development process.

More about the reactions here: https://research.swissdigitization.ch/?p=2490

Squares ( Flash ) Original

Discussion on Flash implementation.
https://archive.org/details/squares2_202011

Squarez (Unity3d)

not yet done. to easy .-)

SquareU ( Unreal – BluePrint )

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

SquareZ (Pico8 – Fantasy Console)

In fantasy consoles, speed is not a problem, which means that everything is easily achievable.

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

// Todo: Beschreibung & Kategorien