[Project 2024]

#0 – Einleitungsblabla

Frage: WAS will ich tun?
Antwort: Ein RPG im Shadowrun-Universum programmieren.

Die absolute Wunschvorstellung meinerseits wäre es ja die Grafiken vom 1993er SNES-Shadowrun zu grabben, den Rollenspielteil der Shadowrun Returns-Triologie als Vorbild zu nehmen aber mit einer eigenen an Biowares Infinity/Aurora-Engine angelehnten „jederzeit pausierbaren Echtzeit-Kampf„-Engine* zu verknüpfen und mir mein eigenes „Shadowrun 2“ zu basteln.

* = Das System der „jederzeit pausierbaren Echtzeit-Kampf„-Engine ist eigentlich nichts anderes, als das die aus den gängigen Rundenkämpfen bekannte Initiative-Leiste ohne Einwirkung des Spielers abgearbeitet wird. Das merkt man vor allem an den elendiglich langen Pausen zwischen den Angriffsanimationen. Entschließt sich der Spieler doch Befehle zu geben, werden diese an der korrekten Stelle eingereiht.

Da sich das grabben der Grafiken aber noch höflich formuliert „in Arbeit befindet“ (Siehe Blogeinträge zum Thema SXT.) liegt diese Idee aber vorerst auf Eis. Vor allem die Inkompatibilität von QB64PE und dem effing M$-Defender @wrk macht mir einen derben Strich durch die Rechnung da ich @home dank ESO nur extrem selten die Muse zum programmieren finde.

Mein SRRDM-Projekt ist zwischenzeitlich noch nicht ganz aber doch schon ziemlich sehr an seiner Komplexität erstickt. Meine „Quick&Dirty Just4fun“ 8x8px-Tile-Iso-Engine die unter dem Namen „Projekt Silvester“ läuft, ist trotz wirklich bemerkenswerter Fortschritte dann doch noch aufgrund der Konzeptlosigkeit an die Wand gefahren.

Je mehr ich hier schreibe desto mehr zieht es mich wieder in Richtung SR:SNES:DRMM zurück. Warum auch nicht? Genug Zeit hätte ich da ja schon hineingesteckt. (Der SXT ist ja ein Teil davon.)

Okay, damit ist es fix. Ich reanimiere das Projekt SR:SNES:DRMM denn wirklich glücklich macht mich die rundenbasierende SRRDM-Idee nicht wirklich. Einer der Hauptgründe warum ich mich überhaupt in diese Richtung gedreht hatte, waren ja meine Zweifel ob man die Kämpfe des SNES-SR überhaupt in die Gegenwart holen kann ohne einen Twinstick-Shooter daraus machen zu müssen. (Ein Genre das mich zwar fasziniert, in dem ich aber mangels Skills nie wirklich Land gewinnen kann.) Genauso benötigt die Welt von Shadowrun meiner Meinung nach kein weiteres Strategie-RPG. Die perfekte Lösung wäre es meiner Ansicht also für den Adventure/Rollenspiel-Part die SNES-Steuerung beizubehalten (inkl. optionaler Mouse & WASD-Steuerung sowie einer Highlight- als auch einer möglichst intelligenten Snap-Funktion für interaktive Gegenstände.) In den Kämpfen soll oberflächlich ebenfalls alles beim alten bleiben. Der Gegner wird anvisiert und dann der Angriff initiiert. Drückt man dann die Pause-Taste, wird das optionale Gitter eingeblendet (Eventuell schaffe ich es das rote Leuchten aus Fallout 1 zu kopieren?) , die Initiative-Leiste und und und. Drückt man die Pause-Taste ein weiteres mal, verschwindet der Taktik-Teil wieder und man kann „einfach so weiterballern“, auch wenn im Hintergrund alles nach einem an die Regeln angelehntes System abläuft. Optional soll es natürlich auch möglich sein alle Kämpfe im Schneckentempo rundenbasierend abzuarbeiten, aber mir geht es mehr darum zumindest für 08/15 Konfrontationen den Spielfluss aufrecht zu erhalten.

Meine sonstigen Wünsche an meine Version wären dann noch:

• Ich würde gerne eine Art Deckungssystem einbauen, da mich bei meinem aktuellen Playthrough der SNES-Version wieder einmal fasziniert das sich die Kontrahenten regungslos gegenüberstehen und einfach nur aufeinander schießen.

• Überhaupt soll das reale Regelwerk viel mehr Beachtung bekommen.
• Koop ist Pflicht. Wie sich das mit den Kämpfen verträgt muss man sich wenn es eines Tages dann tatsächlich einmal so weit ist noch genau anschauen.
• Bessere/detailliertere/hoch aufgelöstere Grafiken müssen ebenfalls her. Theoretisch müsste es „genügen“ die originalen Tiles zu skalieren und dann zu bearbeiten.
• Ein CRT-Shader sollte ebenfalls nicht fehlen.
• Freies Speichern und Autosaves natülich auch nicht.
• Modding alias eine modulare Bauweise um leicht alles Erweitern zu können liegt mir auch noch sehr am Herzen.

#1 – Übersicht über die Teilstücke

Für den Anfang bleibe ich bei meinem Plan „nur“ das originale SNES-SR zu replizieren. Dazu ist a) der SXT notwendig um an die Grafiken zu kommen und b) ein Neustart von Projekt Silvester um zu schauen was ich mit den Grafiken anstellen kann.

Die Sprache meiner Wahl ist … QBJS. Wie erwähnt ist es mir ohne Adminrechte nicht möglich QB64PE in der Arbyte zu verwenden, ergo bin ich auf die Browservariante angewiesen. Das einzige Problem hierbei ist die aktuelle https-Abhängigkeit und das einbauen von Spielständen. Zu ersterem werde ich eines Tages mal im Forum nachfragen, zweiteres muss ich bei Zeiten mal austesten. Da QBJS als Webandwendung aber ziemlich sicher keinen Zugriff auf Mouse, Tastatur und Desktop erhalten kann, wird der SXT weiterhin in QB64PE umgesetzt. Obwohl der Browser via QBJS meine Wunschplattform darstellt, möchte ich mir dennoch die Option eine Desktopversion bzw. allein lauffähige .EXE zu erstellen offen halten, weshalb ich die Kompatibilität zwischen QB64PE und QBJS nicht aus den Augen verlieren sollte.

Je nachdem wie viele Daten im Savegame stehen, kann ich eventuell die für mein eXcom-Reehmake angedachte Version übernehmen. Angelehnt an QR-Codes, soll das Savegame eine Bilddatei sein, welche einen Screenshot enthält in dessen Rahmen alle gespeicherten Daten farbkodiert eingepixelt sind. Wenn ich am Anfang eine Versionsinformation einsetze, müsste es sogar mögllich sein „alte“ Spielstände in neuere Versionen zu laden. Aber das ist ferne Zukunftsmusik…

---

Der SXT ( = Sprite Extraktor, damit es hier auch einmal ausgeschrieben ist.)

Der aktuelle Stand ist, das vSNES korrekt konfiguriert gestartet, die aktuelle Datei geladen wird und dann auf die richtige Ebene gewechselt wird. Diese wird dann zur Übersicht exportiert und eigentlich sollte dann mein Fake-OCR loslegen,

Meine Sorgenkinder sind a) das Format in dem ich die erhaltenen Daten ablege und b) die Pausen die der SXT einlegt um darauf zu warten das vSNES die Eingaben umsetzt. Außerdem habe ich trotz übermäßigem Gebrauch von Kommentaren nach all den Jahren keine Ahnung mehr was wie funktioniert.

Schritt#1-1 wäre es also das Skript zu analysieren.
Schritt#1-2 besteht daraus einen Weg zu finden wie ich von „warte 1 Sekunde“ auf „warte so lange es notwendig ist“ komme. Dazu muss ich herausfinden welche Teile des Bildschirms sich als letztes ändern und bla…
Schritt#1-3 ist dann das Auswerten der aktuellen Daten. Wenn ich diese in ein Array schreibe kann ich dieses dann nach Lust und Laune in beliebiger Reihenfolge in eine .txt schreiben. Für den Anfang wäre es glaube ich nicht verkehrt so viele Daten wie möglich auszulesen. Vielleicht kann ich auch noch herausfinden wie ich die .txt formatieren muss damit es als .csv weiter verarbeitbar ist.
Schritt#1-4 stellt dann den Wechsel auf die nächste Ebene sowie das Auswerten eben dieser dar.
Schritt#1-5 wäre der Sprung zur nächsten Datei in der Liste.

Schritt#2-1 ist dann die Auswertung aller extrahierter Tiles, Dabei geht es in erster Linie darum alle Duplikate zu identifizieren und zu entfernen.
Schritt#2-2 wäre es dann die übrig gebliebenen Tiles mit denen aus der (zukünftig existenten) Datenbank zu vergleichen.
Schritt#2-3 ist dann die Erstellung eines Map-Files anhand dieser Daten.

Bis Schritt#2-3 erreicht ist, sollte Projekt Silvester im Stande sein diese Map-Files verarbeiten zu können.

---

Projekt Silvester (Heißt so weil es am 31.12.2023 @wrk gestartet worden ist.)

Bevor hier gestartet werden kann, ist ein wenig Recherche notwendig, Wie baut das SNES den Bildschirm auf? Wie verhält es sich mit den Positionierungen der Sprites? Wie wird das Scrolling gehandhabt?

Dazu benötige ich ein weiteres Tool. Da es darum geht das vom zSNES erstellte ZMV-Dateien Frame für Frame als ZST-Dateien abzuspeichern schlage ich den absolut unschlagbar kreativen Arbeitstitel ZMV2SRT vor.

Dieses öffnet zSNES, das Rom, sofern notwendig das Savestate und abschließend das ZMV. Dieses wird dann automatisiert Frame für Frame abgespielt und auch als .ZST abgespeichert. Um nicht extra wieder vSNES öffnen zu müssen wird auch gleich ein Screenshot erstellt. Anhand dieser Screenshots kann dann kontrolliert werden ob sich auf dem Bildschirm überhaupt etwas verändert hat. (Damit der SXT nicht umsonst robotet…)
Falls mir schrecklich langweilig ist, kann ich noch schauen ob ich gleich in QB64PE aus den Screenshots ein .AVI oder eine ähnliche Videodatei erstellen kann.
Details hierzu folgen sobald ich mich ausgiebig genug mit zSNES befasst habe.

Was soll Projekt Silvester also können? Als erstes muss einmal klargestellt werden, das aus Projekt Silvester eines fernen Tages die Engine von SR:SNES:DRMM entstehen wird. (Gesäubert, optimiert und und und…) Für den Anfang reicht es mir allerdings wenn die Morgue umgesetzt und benutzt werden kann. Sprich, die Map wird geladen, die Sprites und Objekte ebenfalls, das „Jake-steht-auf“-Script läuft ab und danach ist bis zum Verlassen des Hauses jegliche Interaktion korrekt möglich.

Die erste und wichtigste Komfortfunktion wird die skalierte Darstellung sein. Die nativen 256×240 Pixel sollen zwar eine Option bleiben, aber x2 / x3 / x4 (512×480 / 768×720 / 1024×960 ) müssen auf jeden Fall verfügbar sein. Wichtig ist erfahrungsgemäß hierbei das nicht in der Originalauflösung berechnet und dann erst hochskaliert wird, sondern das bereits von Anfang an mit den skalierten Werten gearbeitet wird. Vielleicht wäre es klug, das Tileset selbst hochzuskalieren anstatt diesen Schritt jedes mal beim kopieren auszuführen?

Die nächste Komfortfunktion soll eine Maussteuerung sein. Nicht für das Spiel selbst, sondern fürs Debugging. Mouseover zeigt in der Console Infos zu den Tiles an, das obligatorische Highlighting, etc.

Dies geschieht alles in QBJS und ist somit das Einzige das ich auch unterwegs machen kann.

Um irgendwo anfangen zu können muss einmal das Format der Map definiert werden.
Und um das tun zu können, muss ich im Vorfeld ein paar grundlegende Regeln fesetlegen.

• Die Map ist in quadratische 8x8pxTiles und nicht in rautenförmige 16×16 Felder aufgebaut.
  Dadurch entstehen in den Ecken zwar Leerräume aber da der Ausgabebildschirm rechteckig sein wird, würden diese sowieso generiert werden.
• Weil ich Ich bin, und ich vom ASCII komme, ist x vertikal und y horizontal. (Siehe LOCATE X,Y). Die klassische Auflösung 640×480 ist demnach y,x. Das mag für jeden Anderen verwirrend sein, fühlt sich für mich aber natürlicher an.
• Die Map wird in ein mehrdimensionales Array eingelesen.
  MapData%(Mapnummer%, TilePosX%, TilePosY%, Layer%)
  Mapnummer% = kA warum, aber ich erachte es als wichtig das einzubauen.
  TilePosX%/TilePosY% = Die x/y-Koordinate des 8x8px Tiles
  Layer% = Ich orientiere mich am SNES und möchte unterschiedliche Layer einbauen.
  Imo wären ein Layer für den Boden, einer für die Wände, einer für statische Objekte, einer für Sprites die in diese Objekte oder díe Wände integriert sind und explizit bewegt werden müssen (zB. Türen, Leichenfächer) und einer für Sprites die ständig animiert werden notwendig.

An dieser Stelle fällt mir ein Problem auf! Der Sprite Layer darf afair nicht an das 8x8px-Grid gebunden sein. Aber dazu ist, wie weiter oben bereits erwähnt, noch eine Recherche über die Positionierung der Sprites notwendig.

Okay, dann lassen wir vorerst Sprites Sprites sein und konzentrieren uns auf die korrekte Darstellung der Map sowie Basic-Scrolling. So wie ich mich kenne, dürfe ich damit eh bis kurz vor der Apokalypse beschäftigt sein. 😉

Da mir zum einem nichts mehr an dieser Stelle Erwähnenswertes einfällt und sich zum anderen meine Nachtschicht dem Ende zuneigt (Soviel zum gemütlichen Filmschauen…) schließe ich diesen Text hiermit vorläufig ab. [Donnerstag 22/02/2024, 05:45]

Hier geht’s weiter.