SeizeCoding (vorallem am Anfang 8Bit) Zeigen, was möglich ist Challenge / Konkurrenz Community Community um einen Computer herum (Idenität) Kontrolle Freizeitbeschäftigung unter Kollegen Credits
SeizeCoding SeizeDesigning
SeizeCoding (vorallem am Anfang 8Bit) SeizeDesidning (bis heute) Identitätsstiftend und Challenge gegen andere Platformen (Bsp. Atari ST vs Amiga)
Produktinterne Motivation
Visuelle, technische Finesse, Tricks Challenge „Wie geht das?“, „Könnte ich das auch?“ Echtzeitberechnung
Visuals, Storytelling
Spielmechanik (Challenges) Interaktion Echt- und NIchtechtzeit
Genutze Techniken
Visuell, Auditiv
Interaktion, Taktil
Visuelle Effekte
Massiv
Kollisionen
Meist keine ausser vielleicht Physikdemo
Kollisionen extrem wichtig für die Spielmechanik
Darstellung wie gemacht
Flackereffekte, Aufbau
Meistens kein Metalayer eher verborgen, seltene Ausnamen
Wer sich Games anschaut eines Computersystems ist meistens erfreut, was es da alles gibt. Da denkt der Recipient: WOW – Unglaublich. Gerade wenn eine Selektion so visuell ist wie die Nachfolgende.
Dabei linearisiert natürlich das Medium Film die interaktive Erfahrung und die Spielmechanik oder das Gameplay spielt keine Rolle. Das ist letztlich die Sicht des Konsums, der Konsumenten. Und damit reproduziert sowohl die Fans, Interessierte Spieler und ganze Teile der Wissenschaft nur den Markt.Beziehungsweise nicht mal den Markt, denn da wäre auch zu nennen, wieviel die Spiele gekostet haben. Meist wird geurteilt ohne jeglichen Bezug einfach nur absolut. Selbst die Entsehungszeit wird oft gnadenlos ausgeblendet,
Die Produzenten*- und Entwickler*-Perspektive
Noch viel schlimmer ist allerdings nur das Betrachten des Endproduktes. Dies ist auch der Marktlogik geschuldet. Der Rezipient*/Spieler* ist ja der Käufer*, der Herrscher über das erstandene Produkt. Wie dieses entstanden ist und zu welchen Kosten auch menschlichen interessiert bis heute in der Gameindustrie niemanden. Das Produkt ist transparent im Informatik-Sinn: Es spielt keine Rolle wie. Deswegen fehlen bis heute im Gamebereich jegliche Labels. Dabei ist es essentiell unter welchen Bedingungen Games entstanden sind.
Dabei spielt es massiv eine Rolle unter welchen Bedingungen, Zeit, Geld, Teams ein Spiel entstand. Die Würdigung des Geleisteten ist nur so möglich und dies ist Teil vom Designprozess. Und hier zeigt sich denn auch bis heute von was Gamer* profitieren. Viele der oben genannten Spiele sind nur durch ausserordentliche Nutzung überhaupt möglich geworden. Das bedeutet letztlich – vermutlich anders als im Consolenbereich – unter massiven Anstrengungen und menschlichen Ressourcen. Teilweise vermutlich jenseits von irgendwelcher möglicher Rendite und angenehmen Arbeitsbedingungen. Nicht dass dies heute anders wäre, wo vorallem der Content so erarbeitet wird. Aber es ist auch diese Spur, die es offen zu legen gilt, um mit dem ’schönen‘ Spiel richtig umzugehen und es einordnen zu können.
Dabei muss jedem* klar sein, so einfach und lustig wie die Leute hier erzählen sind diese Tricks nicht zu implementieren. Auch dies gehört zum Habitus des Geniekults den Aufwand, die Irrungen nicht klar zu machen.
Hier ein paar Tricks ohne die viele Amiga Games etwa nicht möglich wären:
Wer nach dem C64 erwartete, es wird nun alles einfacher mit den Homecomputer 16/32-Bittern ab 1985, der wurde eher beim Atari ST glücklich oder vom Sinclair QL. Das waren Computer mit viel RAM und einem fantastischen Prozessor (Motorola 68000), der endlich auch auf Entwickler zugeschnitten war und nicht tot gespart war wie der 6502. Der Atari ST war billig, den Jack Tramiel trieb auch hier sein Spiel für billig und für die Massen, darum wurde an Grafik aber vorallem an Audio gespart (Der Amiga war ja auch mal als Atari Produkt im Gespräch, endete aber bei Commodore).
Der Amiga eingeführt kurz nach dem Atari ST 1985+ war das Homecomputer-Highend-Produkt (neben dem Macintosh und anderen 68000er based Workstations) und am Anfang auch eher teuer (mit wenig RAM 256k), erst der Amiga 500 (1987+) änderte dies grundlegend.
Als Entwickler* sieht die Sache dabei im ersten Moment super aus: Wow, der Amiga, der kann soviel, soviel mehr als der C64 und auch als der Atari ST. Die Facts sind überragend, verschiedenste Bildschirmmodis, die Möglichkeit den Bildschirm mit verschiedenen Screens zu füllen, Hardwarescrolling, Sprites, digitalisierter Sound und sogar Aufgaben können an den Co-Prozessor abgegeben werden. Zudem ist die Grafik skalierbar über Bitplanes. Pro Bitplane kann man die dargestellten Farben vergrösseren. 1 Bitplane 2 Farben, 2 Bitplanes 4 Farben bis zu 5 Bitplanes mit 32 Farben und mit Spezialmodis noch mehr. Was allerdings auch sehr viel mehr Rechnzeit braucht. Aber was will Entwickler* mehr?
Hier muss vermutlich ein Unterschied eingeführt werden zwischen: Entwickler* für die Demoscene und Entwickler* für die Gamedesignscene. Für Erstere* ist der Amiga bis heute eine technische Herausforderung – ein Instrument aus dem bestehenden noch mehr herauszuholen. Die grosse Challenge oder ein Spiel. Für Zweitere* ist der Amiga nur Mittel zum Zweck. Natürlich gab und gibt es auch Mischformen, wie man an vielen Games als technischen Meisterleistungen schnell erkennt. Aber eben nicht unbedingt.
In einem Telefongespräch meinte ein Entwickler letzthin, dass Computer (falls ich ihn nicht falsch verstanden habe) so etwas wie Hosentaschen gewesen seien. Da kannte man jeden Ecken, es waren einfach 64 * 1024 Bytes Memory im C64 und das sei alles gewesen, alles. Und man kannte jede Adresse oder zumindest die Ranges. Anders gesagt: Es war alles so klein und festgeschrieben, dass einfach alles vor einem lag. Wo findet man den aktuellen Modus des Screen, wo muss man reinschreiben, dass er sich ändert. Wo liegt das Memory für die Joysticks etc. Dinge die heute alles über Spezialhardware und oft deren Schnittstellen erledigt werden muss.
Und es ist tatsächlich so – dass die Leute in Lemon64 immer noch die absoluten Adressen in Hex angeben(!). Sei es in Assembler oder in Basic! (Pokes/Peeks) Nicht etwa in Konstanten aus Libraries, wie heute üblich.
Diese absolute Kontrolle ist selbstverständlich verloren gegangen und so gibt es einige Entwickler*, die danach aufhörten, denn in Windows etwa sei einfach nicht mehr alles unter Kontrolle gewesen.
Der Weg raus aus der Hosentasche in den vielfältigen Overall, wo dauernd, was anderes in der Tasche vielen war. Erklärt auch ein bisschen den Aufstieg der Hochsprachen auch in diesem Millieu. Kontrolle.
Fragestellung: Ist es möglich ein Basic-Game zu entwickeln, das auf den meisten 8Bit-Homecomputern wie C64,MSX,MS-DOS,ZX81 etc läuft? Läuft bestenfalls mit keinen! bis kleinen Änderungen?
BASIC war die Sprache der 8Bit Homecomputer. Sie war alt (Darthmouth 1964), klein, eine Interpretersprache und dadurch relativ einfach zu implementieren.
Erste Erkenntnisse zur „Lingua-Franca“ BASIC
Es würde also nahe liegen sie als die Lingua-Franca zu benutzen über alle 8bit-HomeComputer hinweg. Und das trifft mehr oder minder für den ersten Darthmouth-Standard auch zu. Mehr oder weniger läuft alles dadrauf – nimmt man es nicht so genau mit Strings (Definierte Stringlänge bei Atari400/800, kein einfaches Concat mit +, Input) oder dem RND-Befehl (RND(4) QW-Basic).
Leider war Basic aber auch auf Input-Output-Programme für die frühe Entwicklung von Programme entwickelt worden, das heisst letztlich die Shell. Und so fehlt der Sprache per Standard jede Art von Keypressing-Funktionalität oder auch Grafikmöglichkeiten. Und hier legten sich die verschiedenen Computerhersteller wirklich ins Zeug Inkompatibilität aufzubauen. Allein die Geschichte um das Atari Basic zeigt auf was die Probleme waren: Der normale Interpreter brauchte schon 8k (Rom-Grösse mit akzeptablen Preis) – Atari wollte aber logischerweise auch Grafik-Commandos im Basic haben. Wie also reduzieren das Ganze? Indem man Befehle strich und anschliessend Befehle zusätzlich ins ROM verlagerte (wo es anscheinend unendlich langsam war).
All dies zeigt auf, dass diese Homecomputer letztlich zuerst als Hardware-Software-Paket verkauft wurden (obwohl Atari sein Basic zuerst seperat verkaufte). Die Kompatibilität war zuerst einmal da, indem man die meisten BASIC Lernkurse damit machen konnte. Danach wollten alle einzeln brillieren. Damit liessen sich natürlich de facto keine Platform übergreifende Software entwicklen und verkaufen, zumal auch keine Compiler existierten. Natürlich hatte auch jede Platform ihren eigenen Zeichensatz mit eigenen GrafikChars.
LineJeweled – Game in der Lingua-Franca „BASIC“
Um überhaupt eine Game über verschiedene Plattformen entwickeln zu können, musste also benutzt werden, was im Standard-Output möglich ist. Und das ist Print und Print ; (Lineprinter waren mal sehr in Mode). Ein Grafikaufbau mit CLS (Clearscreen) ist wegen Geschwindigkeit und Verfügbarkeit des Befehls oder seiner Simulation (30x Print „“) leider nicht möglich.)
Das heisst letztlich musste eine Spielmechanik gefunden werden, die ein einfaches Actiongetriebenes Game doch möglich macht und auch funktioniert, wenn man nicht auf dem Bildschirm zeichnen kann. Nach vielen Experimenten stellte sich heraus, dass man am Besten sich mit einer Variante von BeJeweled oder 3+ Gewinnt bedient. Das Spiel schreibt fortwährend das Spielfeld fort und der Spieler kann bei der Cursorposition einen zufälligen Edelstein einfügen. So kann der Spieler* 3+ Reihen in jede Richtung generieren und Punkte sammeln. Technisch muss auch nichts im Spielfeld geändert werden. Und das Spiel lebt vom Printen von Linien und verlängert das Spielfeld automatisch gegen oben. Dadurch entsteht ein für die Verhältnisse komplexes Spiel.
Auf dem C64 sieht das wie folgt aus:
Da die Anzeigen nicht immer neu gezeichnet werden, müssen sie einmal pro Linie geschrieben werden. Dadurch schreibt das Spiel auch seine eigne History per PRINT ins Fenster.
Was in heutigen Programmiersprachen gang und gäbe ist, die Technik Dinge von X nach Y zu kopieren und dort anzupassen, ist in Assembler nicht so einfach möglich. Der Grund: In heutigen Programmiersprachen gibt es keine Sprungmarken mehr, diese müssen aber mühsam angepasst werden Assembler. Es darf ja (ausser bei modernen relativ adressierbaren Assembler) keine zwei gleichlautende Sprungmarken geben. Anders gesagt: Copy&Paste ja, aber zu einem Preis: Generierung von vielen neuen Labels und damit auch jede Menge möglicher Fehler und viel Neu-Testing.
Und dies trifft Videogames besonders, da Videogames geradezu von Bedingungen leben (ifs, loops etc).
Gridrunner (Jeff Minter) – 68000 ATARI ST Assembler:
// {} vs a: b: // Mehr Subroutinen in Assembler > Frage an die Entwickler // Vgl dazu die Demoscene
Es ist eine Sache Software/Games für alte Systeme auf Emulatoren zu entwickeln und eine andere sie dann lauffähig zu machen auf Orginalhardware. Die Unterschiede sind schnell erklärt: Viele Emulationen ’simulieren‘ über Probleme hinüber (Werte sind meist geleert oder null gesetzt, Hardware ist doch leicht anders etc).
Am Besten sieht man das etwa bei sehr spezialisierter Hardware wie der Vectrex (Beispiel VecZ). Beim Simulator gibt es kein Flimmern, keine Hardware am Anschlag, keinen Kathodenstrahl, der kondensiert die gesamte Helligkeit abbildet etc.
Aus diesen Gründen war es interessant zu sehen, ob das Spiel TheHolyCube einfach so läuft auf einem Orginal C64.
Das Spiel kann per FlashCard und einem SD2iEC (Simuliert ein C64-Diskettenlaufwerk – Karte und Stecker zum C64-Laufwerk) relativ leicht als .PRG ‚aufgespielt‘ werden.
Das Resultat: Es läuft – in den ersten Test ohne Probleme. Selbstverständlich ist der Screen ein modernes TFT und dadurch erscheinen die Pixel als Pixel und sind nicht verschwommen wie bei einem Orginal CRT. Dies muss als nächstes getestet werden, um dem ursprünglichen Phänomen und der Wirkung gerecht zu werden..
Nutzung der C64 Architektur für eine GameEngine in Assembler.
Prinzipiell stellt der C64 Bildschirminhalt (wie schon mehrfach beschrieben) im Textmode oder im Grafikmode dar. Es gibt verschiedenste Grafikmodi: 320*200 in 2 Farben oder 160*200 in 16 vordefinierten Farben (Multicolormode). Wobei nur 4 Farben pro 8*8 oder 4*8 Block gesetzt werden können: 3 jeweils wählbare neben der allgemeinen Hintergrundfarbe. Dabei lassen sich diese Modi wie beim inspirierenden System Atari 400 hin und herschalten anhand des Rasters und damit Mischen. Sichtbar in unendlich vielen Spielen und auch Grund für die Teilung des Screens bei ManicMansion.
Das Problem: C64
Betrachtet man die Spiele, die mit dem C64 entstanden sind, ist man einigermassen fasziniert, da wirklich alles aus dieser ursprünglich als Gameconsole konzipierten Maschine rausgeholt wurde. Dabei ist der C64 alles andere als ein Paradies für Entwickler. Angefangen von den Text/Grafikmodis, über die Repräsentation des Bildschirms als RAM in Blöcken. Dann die maximale Auflösung von 320*200, die völlig überdimenstioniert ist für den Prozessor, der nur 8Bit ist (650x). Die Hardware und der Prozessor sind dabei eigentlich nicht aufeinanderabgestimmt und vieles ist einfach möglich günstig gelöst. Als Entwickler* hat man zu keinem Zeitpunkt das Gefühl, dass auch nur einen Moment an die Entwickler* gedacht wurde. So fehlen elementarste Dinge für Gamedevs – etwa (und das haben alle Consolen natürlich eingebaut) die Möglichkeit Text in den Grafikmode zu rendern. Hier soll allen Ernstes mit Modis umgeschaltet werden. Dies führt dann auch zu der immer künstlichen Trennung von Bild und Text in C64 Games. Die Sprites können von 0-386(?) in X und 0-300 (?) gesetzt werden. Dadurch können sehr schön Sprites reinhuschen in den Screen, dafür ist es die „Hölle“, die Sprites zu verwalten, da der Prozessor nur von 0-255 rechnet. Dann muss ein LowerByte hin. Wer dann auch noch eine eigene Kollisionsabfrage will, ja der hat viel „Spass“. Anders gesagt: Der C64 ist ein Bolide mit einem schwachen Herz. Zu erst sieht der Prozessor ja einigermassen schnell aus, bis man die Taktrate und die möglichen Instruktionen runterrechnet auf eine Frame. Dann zeigt sich dann sehr schnell, dass ohne die Zuatz-Hardware für Sprites, Scrolling oder die Zusatzmöglicheiten des SIDs, der C64 recht langsam ist. Es ist dann auch verständlich warum, der Apple II leider nie zum Gamecomputer avanzieren konnte in die Breite. Selbst mit den grosszügigen 64KB RAM stösst man sehr schnell auf Probleme bei der Entwicklung und es wird schnell klar, warum viele Spiel auf dem C64 so sind, wie sie sind..
Man mag Jack Tramiel danken für sein „Computer to the masses and not classes“, aber dass darum die Programmier* dabei Unterklasse werden, das bleibt im Dunkeln und wird auch fast nicht thematisiert, wenn man* so gemütlich ein C64 Spiel spielt.
GameEngine: ‚Philosophie‚ (Designrules)
In der entwickelten GameEngine wurde versucht aus diesem „Ungetüm C64“ etwas zu machen, das keine Herausforderung in der Nutzung ist, sondern den Entwicklern* hilft. Es ist eine TopDown-Entwicklung. Die Engine wurde auch so entwickelt, dass sie für verschiedene Genres genutzt werden kann. Nicht implementiert sollte Scrolling werden, da dies immer eine je eigene Entwicklung benötigt (Playfieldgrösse, vertikale oder horizontale Ausrichtung etc) und schwer abstrahierbar ist.
// ToDo: Vergleiche mit real entwickelten Spielen in jener Zeit und deren Ansatz – je eine eigene Engine für jedes Spiel oder eine Metaengine
Technologie: KickAssembler
Als Sprache wurde KickAssembler benutzt. Dies ist ein scriptbare Assembler in Java mit der Möglichkeit klassische C/Java-Kommentare zu machen // & /* */. Zusätzlich gibt es vordefinierte Scripts. Durch Java als Grundsprache läuft der Assembler auf allen Systemen. Eine Anforderung, die wichtig ist, weil Entwickeln auch auf Mac ein Goal des Projektes ist. Die meisten anderen Tools laufen vor allem auf Windows bzw. sind Plugins im Universum von Microsofts VisualStudio.
Das Compilieren ist (nach Installation von Java und dem Wechseln in den Ordner) simple:
Er funktioniert einfach mit Drag&Drop, lädt sehr schnell, die Joysticks etc sind Standard mässig installiert. Dinge die gerade beim Platzhirsch VICE (https://vice-emu.sourceforge.io) konfiguriert werden muss.
EngineArchitektur
Die Architektur der Engine orientiert sich an frühen Engines (keine Eventengine) und basiert auf einem oder mehreren Loops (die linear angeordnet sind). Hier sind es: Titelbild-Loop, Menuloop, Submenloops und der Gameloop.
In der Organisation und Bewirschaftung der Daten wird auf die Eigenheiten/Verteilung durch die Hardware eingeganen. Das heisst, es gibt nicht nur eine Klasse GameObjekte (wie etwa in Unity), die alles abbildet sondern zwei Teilsysteme:
Diese zwei Objektkategorien sind bei Consolen und auch beim C64 als eigene Hardware/Teilsysteme abgebildet.
Dies führt dann auch zu verschiedenen Interaktionen/Events zusammen.
Auflösung und Playfield
(Viele 8Bit-Consolen nutzen Playfields für den Background bzw. die Umgebung/Architektur vgl. Intellivsion Ausnahmen natürlich Atari 2600 und Vectrex)
Für die entwickelte Engine wurde der Multicolormode genutzt. Damit lässt sich am meisten rausholen aus den Grafikmöglichkeiten (Die meisten Games verwenden auch diesen Mode). Anstelle des vermutlich gedachten Playgrounds mit einem Multicolorzeichensatz verwendet die Engine 8*16 Pixel grosse Blöcke. Das sind pro Block 4 Blöcke des C64 Grafiksystems.
Die Nutzung eines so „Niedrig“ aufgelösten Rasters erlaubt es, dass das Playfield eine Liste von 0-255 Feldern ist und so leicht manipuliert und abgespeichert werden kann.
Die Engine nutzt dabei eine Liste mit den Blöcken (Blocks) und ein aktuelles Playfield. Dieses kann gerendert werden in den Screen. Einzelne Blöcken lassen sich updaten. Es gibt ein System zu Animationen der Blöcke (synchron) für Gameplay wichtige Animation und ein System, das asynchron Animation bietet.
Die Menuszenen wie auch die einzelnen Szenen (alias Levels) sind als Levels im Speicher abgelegt. Dadurch muss nur ein System betreut werden und auch in Menuscenen kann etwa das Animationssystem benutzt werden.
Block & Playfieldtool
Um dies nicht nur im Code nutzen zu können, wurde ein Tool entwickelt in Processing. Dieses Tool ist zum einen ein Designtool für die Blöcke und zum Anderen ein Tool zum Gestalten der Playfielder (Levels).
Das Tool speichert die Daten als „rohe“ JSON Daten bei den Blocks und einzelne Levels. Gleichzeitig werden die Daten per .asm File gespeichert und können dann eingezogen (include) werden.
Das Tool ist so aufgebaut, dass man jeweils nach links Blocks designed und nach rechts die Levels. Im Bereich des Blockdesigns müssen die Farben nicht ausgelesen werden, sondern werden automatisch aus den benutzten selektiert. Dies macht es einfacher zu designen. Eine farblich angeordnete Palette macht das Pixeln einfacher.
// ToDo: Welche Spiele nutzten Leveleditoren und wer arbeitet Hardcore in den Listen/Tables oder nutzte einfach Files? Zumindest für die 16Bit Generation lassen sich Leveleditoren nachweisen (Bsp. WAR HELI) und sind sogar in die Games (KRACKOUT) eingebaut.
Gestaltung von Blocks/Szenen
Das Gestalten von Blocks zur nachfolgenden Mehrfachverwendung ist eine Designsparte für sich. So müssen die Blöcke zwar unique aussehen, dürfen aber auch nicht zu unique aussehen, damit sie nicht zu fest ausfallen. Das Umgekehrte gilt für den Hintergrund, dieser muss Regelmässig aber nicht zu regelmässig aussehen. Die Limitation des C64 pro Tile/Segment nur 4 Farben (Hintergrund nicht wählbar und 3 Vordergrundfarben) machen es sehr schwierig interessante Dinge zu gesalten. Erschwerend kommt die wirklich schwierige (weil einfach seltsame Farben) Farbpalette hinzu. Zu guter letzt ist erst auf dem C64 laufend, dann klar, wie es wirklich aussieht. Da liegen dann die eine oder andere Farbe schon gar eng beieinander.
In die Blocks gehört auch ein Alphabet und Zahlen. So lassen sich Strings mit Zahlen ausgeben in der Grafik. Zusätzlich verfügt die Engine über die Möglichkeite 1/4 Blocks, klassische Tiles/Blöckchen zu zeichnen. Dadurch lassen sich normale Texte in 4×8 Pixeln rendern.
Gestaltung von Levels/Szenen
Levels besitzen wie Blöcke eine spielmechanische wie auch visuelle Funktion. Um Levels zu gesalten gibt es besondere „Commandsblöcke“, diese Spawnen etwa den „Spieler“ oder den Gegner etc. Diese werden dann umgewandelt in normale etwa Hintergrundblöcke.
Die visuellen Designregeln transportieren die Mechanik, dürfen aber auch nicht zu statisch sein und sollten irgendwie leben. Siehe dazu anderen Blogbeitrag.
Einige Beispiele:
Menuscene ohne Menupunkte
Ein Level mit Spielerspwanpunkt und Enemyspawnpunkt
GameObject bzw. Sprites
Das problematischste Element ist die GameObject/Spriteverwaltung. Diese besteht aus einer Liste von GameObjekten, die auch gerade Sprites abbilden.
Ein Objekt hat jeweils die Länge von 17 Bytes:
0
1
2
3
4
5
6
5
6
7
8
9
10
11
12
13
14
15
16
x
xshift
y
yshift
w
h
state
statesub
arg
behaviour
animtodo
animindex
mina
maxa
animtype
animeoden
Positionen
Die Sprites können in zwei Modis genutzt werden. Von 0-255 im Boxmode. Hier endet die Darstellung nach 256 Pixeln oder im 320 Pixel-Mode: Hier rechnet die Engine intern mit 2 Pixeln und dem Offset. 270 Pixel in X Richtung sind: 135 Pixel (x). Möchte man das Sprite auf 271 Pixel bewegen, so gibt es dafür eine ShiftNumber (x-shift). Da der C64 einen Rahmen von 20 px und 50 px hat, muss dies jeweils abgezogen werden für Vergleich oder Kollisionen mit dem Playfield.
320 Pixel-Mode (0-160, 0-250):
Animationssystem
Das Animationssystem ist simpel. Jedes Gameobject hat einen Animationstyp (Endlos,einmal,einmal&destroy). Per MinAnimation und MaxAnimation definiert man die Animation. Und los geht es.
GameObject-GameObject-Collision
Die Engine führt eine Kollision von jedem Objekt mit jedem anderen durch. Kollisionen können in der Schleife abgefragt werden.
Avatar-Playground-Collision
Die Engine prüft per Default Avatar-Playground-Kollisionen und ist damit in der Lage Objekte aufzunehmen. Objekte können dadurch einfach Objekte ‚auflesen‘ aus dem Playfield.
Spritetool
Das SpriteTool arbeitet ähnlich wie das Blockeditor-Tool. Geht aber auf die Eigenheiten von Sprites ein. Das heisst es können zwei Grundfarben ausgewählt werden und dann pro Sprite jeweils eine Zeichenfarbe.
Anwendung
Die GameEngine wurde bis anhin in 3 Projekten angewendet: – Squarez – ein einfaches Spiel, das im Rahmen des CHLudens-Projekts durch die Geschichte der Computer nachprogrammiert wird. – TheHolyCube – eine OneButtonSpiel von la1n ein OneButton JumpAndRun mit Animationen und vielen Levels – ‚Züri brännt‘ – ein einfaches Adventure im Rahmen des CHLudens-Projektes zur Frage der Machbarkeit und Einschränkungen der Hardware/Medium: Game(HardwareC64) (In Entwicklung)
Fazit
Die GameEngine umfasst die meisten genutzten Funktionalitäten in Spielen mit Ausnahme des Scrollings und des Sounds.
