Wer nur einen Screen zur Verfügung hat als Spielfeld in einem digitalen Game, muss sich einiges einfallen lassen, dass dieser Screen interessant nutzbar ist und auch interessant bleibt. Dieser 1:1 Screen ist eine der Herausforderungen in den ersten Jahren des digitalen Gamedesigns. Es erstaunt deswegen auch nicht, dass der Screen regelrecht erweitert wird und dass er sehr schnell nicht mehr endet links oder rechts sondern endlos wird etwa bei Weltraumspielen (Asteroids und co) oder eben PacMan oder Bubble Bobble oder Rainbow Islands. Dadurch werden die Ränder nicht zu DeadEnds sondern sind begeh- und nutzbar.
Sehr schnell wird der Screen historisch erweitert und der Bildschirm wird zur flachen „Kamera“ in eine andere Welt – es wird dann der Raum ‚umgeschaltet‘ (Cybernoid) oder sehr bald dann gescrollt. Dadurch können dann auch die Figuren wiederum grösser werden, die Aufgaben über die Weite von Screens verteilt werden, denn nicht mehr alles passiert in diesem einen übersichtlichen Screen. Ganz am Ende dieser Radiation stehen dann letztlich 3D Spiele, die die Wahrnehmung des Raumes geradezu über unendliche Einstellungen verstreichen.
// Interessanterweise kämpfen aktuelle OneScreen-Games weiterhin mit denselben Problemen bis hinzu OneScreen-Batllern.
Wer Assembler programmiert (oder auch Basic mit Goto Zeilennummern/Sprungmarkenmöglichkeiten) stellt schnell fest, hier kann man viel mehr machen als in modernen strukturierten Programmiersprachen (mit derselben Anzahl von Zeichen). Moderne strukturierte Programmiersprachen ähneln mehr einem modernen Rezept, während unstrukturierte eher einem Hypertext ähneln.
Moderne strukturierte Programmiersprachen und ihr Baumkonzept
Moderne (strukturierte) Programmiersprachen und ihre Ablaufdiagramme sind eine Teilemenge (nicht eigentlich) der viel grösseren Menge der Maschinensprachen mit ihren JMP und GOTO Befehlen. Der Code springt in Unterroutinen und kehrt dann wieder zurück in den nächst höheren Prozess.
Dadurch entsteht eine Art Baum und wie bei Treestrukturen üblich, ist es jederzeit klar, wo sich der Programmpointer(‚man‘) befindet. Jeder Punkt ist klar definiert, weil der Rückweg immer klar ist – den Tree up. Je tiefer der Tree ist, umso grösser die Verwaltungsaufgabe, schliesslich muss man sich immer merken, wie man zurückkommt.
Prinzipiell hat C. Böhm ( https://en.wikipedia.org/wiki/Corrado_Böhm ) früh – 1963 – gezeigt, dass sich alle unstrukturierten Programmiersprachen in strukturierte überführen lassen. Er hat dazu eine theoretische Programmiersprache entwickelt mit sehr wenigen Befehlen. Eine wiedererfundene Version dafür kennt man heute Brainfuck von U. Müller, das nur von den Befehlen +-[] etc lebt. Diese Sprache hat natürlich einen Preis, die Source-Codes sind riesig.
Der Vorteil ist sofort klar: Lesbarere Strukturen (Trennung zwischen Fakten und Regeln klar), da es klare Ablaufdiagramme gibt.
An verschiedenen Stellen (raussuchen) wird darauf hingewiesen, dass gerade 8Bitter wegen RAM (auch in Sachen Tools) und kleinem Stack nicht in der Lage sind wirklich höhere strukturierte Programmiersprachen zu bieten. Es fällt auch auf, dass es wenige strukturierte Programmiersprachen gibt auf diesen Systemen und viele erst heute nachträglich entwickelt werden, um zu zeigen, dass es doch funktioniert.
// ToDo: Checken der These, dass es bei 8Bit-Homcomputern wenige Compiler und Hochsprachen gibt, weil das RAM fehlte bzw. die Stacks zu klein waren für gute Compiler.
// Trees sind deswegen bekanntlich sehr beliebt, da sie machttechnisch grösstmögliche Kontrolle erlauben. Natürlich lassen sich damit nur eine beschränkte Datenstruktur oder auch Prozessstruktur abbilden – aber für viele Systeme reicht es (oder eher muss es reichen).
Unstrukturierte Programmiersprachen – willkommen in rhizomatischer Ausführung
Assembler dagegen ist das potentiell offen in der Struktur. Es kann kreuz und quer Daten uns Code verteilt werden (nicht der beste Stil) – letztlich besteht darin auch kein Unterschied – das eine sind ausführbare Daten, das andere interpretierte Daten – aus Sicht des Programs.
Prinzipiell gibt es wenige Befehle. LDA (load A), STA (store A), CMP, JMP. Dadurch entstehen logisch stringente Programme. Ebenso ist das Rechenwerk meist sehr eingeschränkt (etwa beim billigen 6502): Register A,X,Y. All dies macht die Programm lang und oft schwer lesbar.
Als Flaschenhals kommt hinzu, dass viele Operationen nicht im allgemeinen (langsamen) RAM ausgeführt werden können, sondern nur im ‚Rechenwerk‘ und darum dahinein geladen werden müssen bsp. lda #1 (Lade 1 ins A-Register).
Der wichtigste Unterschied zu strukturierten Programmiersprache ist aber sicherlich die Möglichkeit des „Springens“ JMP (oder GOTO) und alle Flag-Abhängigen-Sprünge aus „Compares wie CMP“ wie BEQ (gleich), BNE (ungleich), BCC (kleiner als), BCS (grösser als) etc.
Ein fiktives Beispiel:
lda #10
ohje:
clc
adc #1
clc // clean the state-register
cmp #4
beq it_is_four // same
bne it_is_notfour // not the same
it_is_four:
jmp end_of_all
it_is_notfour:
jmp oh_je
end_of_all:
Dies ermöglicht dann alle möglichen Versionen von Ausführungen. Komplizierter wird das Ganze dann auch noch, wenn sich der Source-Code über mehrere Seiten erstreckt. Und selbstverständlich lassen sich Dinge in Unterroutinen verpacken, das Problem allerdings dann da: Handling der Parameter (auf den kleinen Stack oder in eigene Variablen?).
Im konkreten Programmierprozess müssen durch die Sprungmarken auch immer wieder neue Sprungmarken gefunden werden. Dies ist bei weitem aufwändiger als etwa in C. Die Haupbenennungsaufgaben sind quantitativ die Variablen/Members und die Methoden.
Die Variablen sind ähnlich aufwändig in Assembler:
a: .byte 0 vs byte a = 0;
Dasselbe gilt für die Funktionen/Methoden:
render_me:
[...]
rts
vs
void render_me() {
}
Viel aufwändiger wird es hingegen bei jeder kleine If-Abfrage bzw. in Sachen fornext (was ja eine verkürzte Schreibweise ist C). Hier müssen immer wieder neue Sprungmarkennamen gefunden werden (auch wenn moderne Assembler hier auch lokale relative Namings ermöglichen).
ldx #10
count_down:
clc
cpx #4
is_not4
is_not4:
inx
clc
cmp #0
bne count_down
vs
for (int i=0;i<10;i++) {
if (i==4) {
}
}
Selbstverständlich klingt, das im ersten Moment nicht nach viel. Das Problem potentiert sich aber dann mit jeder neuen Abfrage und jeder ForNext-Schleife.
BulletHell hat sich in den Jahren seit sie technisch machbarer geworden sind zu einem eigentlichen Grossgenre unter den ShootEmUps ausweitet. Was man dabei schnell vergisst, zu den BulletHell-Kerngenres gehören natürlich auch all die Robotron-Versionen und Tempest-Varianten mit dabei hier seit Jahrzehnten Jeff Minter mit seinem unverwechslich westlichen Mukokuseki.
Und man beachte die Parallelen von VampireSurvivors (nicht das Aussehen) und etwa Llamatron. Und ja VampireSurvivor führt in das System die Langzeitmotivation behaltbare Extras ein und ein monitäres System dazu. Wir leben heute ja auch in der Vollökonominiserung und nicht in den widerständigen 80er Jahren, wo das alles vorwärtsgetreiben wurde in England.
Bis anhin nutzte ich das einfach McDraw online. Das funktioniert auch einigermassen gut, einzig die Lupenfunktion und gleichzeitiges Malen funktioniert nicht. Darum die Frage, welches auf allen Platformen erhältliche Malprogramm würde noch funktionieren.
Warum nicht Aseprite wieder nutzen? Und wie arbeitet es sich ohne den Farbencheck (4 bzw. real aus 16 Farben)?
Als Template habe ich mal eine PNG benutzt, das ich McDraw exportiert habe mit allen Farben schon drin.
Das Raster lässt sich in den Einstellungen einfach darüber blenden und das Malen funktioniert wie immer gut.
Nun am Ausprobieren wie es mit den Farben und dem unintuitiven Zählen aussieht.
Commodore 64 Palette
Verwendet man die C64 Palette intern so hilft Aseprite noch zusätzlich wie man hier sieht (mit Verläufen, Dithering etc):
Folgendes Icon hilft:
Suche nach Commodore 64.
Ebenen
Nicht ganz eingängig sind noch die Ebenen. Mit restrikteten Farben ist die erste Farbe immer HIntergrundfarbe. Nur die erste Ebene kann eine intransparente Hintergrundfarbe haben. Die Ebenen findet man unten.
Verschiebbar sind die Ebenen mit einer seltsamen Tastenkombination. Mac: Control oder Option …
Farbencheck und Koala-Export
Dank des Lua-Scripting-Support lässt sich ein Farbenchecker realsisieren, was tatsächlich jemand schon gemacht hat. Das Ergebnis findet sich hier. Am Einfachsten die Script downloaden hier: https://github.com/Viza74/c64helperscriptsforaseprite
Anschliessend muss man den Ordnerinhalt in den richtigen Scriptornder kopieren:
Anschliessend (Neustart erforderlich?) stehen die Scripts Verfügung. Der Ordner enthält auch ein Demobild.
Nun kann man die Farben checken und anzeigen lassen. Es zeigt sich aber auch, dass das Aufsetzen eines eigenen Templates nicht so einfach ist, so dass es das einfachste ist, das Template zu nehmen und die Ebene mit dem Testbild zu löschen und eine neue zu kreieren.
Sogar als .kla lassen sich die Bilder (automatische entlayert) exportieren.
Ich suche tatsächlich im Source-Code herum nach markanten Stellen. Ich kenne den Source nach den Stellen und was dort für Variablen, Methoden vorkommen, wobei das letztlich in Assembler ja auch alles dasselbe ist. Ich habe sogar angefangen, Kommentare zur Suche verschieden zu kommentieren quasi zu taggen.
Als Beispiel etwa: – Anim System – Animation System – Sprite Animation system
Alles damit ich es mit verschiedenen Fragen finde.
Anbei die letzten Suchen in der Such-History von Sublime (Texteditor Mac/Win):
Zur Kontextualisierung: Ich entwickele seit einiger Zeit eine kleine GameEngine und wende sie auch gerade im aktuellen C64 Spiel an.
Das hässliche an 8bit Systemen (Zahlenraum 0-255) ist, dass alles im selben RAM rumliegt. Es gibt keine geschützten Bereiche. Das hat Vorteile – die BASIC-Coders* lieben es zu POKEN und zu PEEKEN. Auch die Cheaters* mögen es selbstverständlich. Aber es hat auch Nachteile: ‚entgleiste‘ Routinen treiben ihr Unwesen durch das ganze RAM, Grafiken, Tabellen, Sound, ausgeführter Code. Das Ergebnis – unklar warum genau was passiert. Es ist eine Art Migräne im RAM. Es wandert immer wieder über verschiedene Bereiche.
Und so kommen dann auch entflaufene Sprites nach der 255 Grenze wieder ins Bild.
Ein Teil der ShootEmUp-Szene lebt von den „vielen“ Gegnern und Schüssen bis hin ins Subgenre des Bullet-Hells. So viele Gegner waren zu haben mit: viele monochrome Sprites (Schüsse müssen nicht komplex sein) oder dann mit grossen wenigen Sprites, die man unterteilt (Multiplexer). Diesen Weg ging der C64. Bei dieser Methode ist aber dann auch klar: Die Sprites sind halb so gross und das funktioniert nur so richtig visuell in horizontalen ShootEmUps (Katakis lässt grüssen).
Kurzzusammenfassung der wichtigsten Details bezogen auf die Spielgeschichte.
Geschichte
J. Tramiel (1928 vgl. dazu Persönlicher Background von Personen – Jack Tramiel Mr Commodore C64, Atari ST) wurde als jüdischer Pole aus Auschwitz befreit, arbeitet fuer die US-Armee, dann als Contracter und gründete Commodore für Rechner, Büromaschinen (vgl. Sinclair). Dabei ging es immer um die Dinge für alle – Massen- bzw. Volkscomputer. Zuerst Büro- und dann Homecomputer. VC 20 etc. dann C64
Hardware & Entwicklung
Unabhängigkeit durch Kauf von MOS inklusive 6502/x (8bit). Zuerst Idee Console darum auch alles drin (Bilder, Scrolling, Sprites inspiriert bei Intellivision, Atari 400 etc). So billig wie möglich. Und 64KB Speicher, mehr als alle anderen und Spezialchips (Idee Console für Grafik VIC, Sound SID).
Schnittstellen: 2x Joystick, Datasette (1), Diskette – sehr langsam – darum oft Erweiterungen (8), serielle (Drucker) oder Cartdriges.
Produkt
Übername „Brotkasten“ in der Tradition der Homecomputer. Tastatur ist Teil des Computers.
Erste Applikation: Basic und Programmieren wie bei anderen Homecomputern.
Basic hat eine zweite wichtige Funktion: Laden und ausführen von Software.
Übung: – Suche ein Spiel (DiskImage) – Lass es laufen online / Vice – Versuche ein eigenes PRG hochzuladen.
Programmiermöglichkeiten:
Basic (default), Assembler etc
Basic
Allgemein langsames nicht kompiliertes Basic. Nicht upgedated, weil Commodore eine Version fuer alle Commodore Homecomputer kaufe. Mit : lassen sich Befehle zusammen hängen und damit OneLine-Spiele etc selbst herstellen.
Unten ist die Orginalanordnung zu sehen, oben eine eigene mit ‚Farbverwandtschaften/clustern‘, das beim Gestalten hilft.
Die Farbauswahl scheint als Geschmack der Entwickler* entstanden zu sein und nicht etwa mittels Evaluation und Anforderungen.
Multicolor: 40*25 Blöcke. Eine Hintergrundfarbe, eine Borderfarbe und jeweiles 3 eigene Farben pro Block Pixeling per Joystick! > Viele Grafiken ab 1985 auf dem Amiga/Atari ST kreiert.
