PureBoard

Alle Jahre wieder nehme ich wir was größeres vor ...
Wie unschwer zu erkennen, sind alle meine vorherigen Versuche gescheitert, bzw. ich hab in einigen Fällen selbst das Interesse verloren, in anderen Fällen den scope of things unterschätzt, wollte zu weit hinaus.
Diesmal will ich es (wirklich) kleiner angehen. Und zwar ein Rework von "Die Gemäuer von Kalawaum", ein kleines RPG welches ich hier bestimmt ein paar Mal bereits erwähnt habe, und welches mir in jugendlichen Jahren auf meinem Atari ST Stunden meiner Lebenszeit abgezwackt hat.
"Kalawaum" hatte sehr reduzierte Mechaniken, und mein erklärtes Hauptziel soll auch bleiben, das Erlebnis so original getreu wie möglich zu rekapitulieren, mit so wenig extra Fluff wie möglich, also die Chancen stehen gut, daß ich da erstmal dran bleibe.
Hier hat übrigens jemand das Spiel für den Commodore PET portiert, am Anfang des Videos sieht man aber auch das Original vom Atari ST:

https://www.youtube.com/watch?v=wOgAzdb ... =emb_title

Seid sarkastisch, motivierend, indifferent, whatever, nur bitte drückt mir die Daumen, daß ich das diesmal durchhalte!

Ob's was wird oder nicht, weiss ich natürlich nicht, aber das hier ist der "Showcase", soll heissen, hier stellst Du fertige, oder wegen mir halbfertige Spiele vor.
Die Idee ein Spiel anzufangen, gehört aber eher nicht hierher.

Jeder darf das natürlich machen wie er möchte, aber ich hätte ja eher wenigstens schonmal angefangen und was vorgestellt.
Ich träume ja auch schon seit ewigen Zeiten davon ein Remake von Castles of Dr.Creep zu machen, bin nur nie dazu gekommen und wird wohl als meine ganz persönliche unvollendete Arbeit (bzw. eher unangefangene) enden.
Aber das weiss ja sonst keiner... öhm... o.k., wusste ja sonst keiner

Ach ja:
Dem Typen, der das Video gemacht hat, sollte man Youtube Hausverbot erteilen, oder zumindest nen Kamerastativ spendieren.
Ist ja unglaublich, was die Leute da so alles reinstellen.

Entschuldigung.
Tatsächlich habe ich schon einiges Fortschritt - ich habe diesen Thread auf der Arbeit angefangen, mußte dann aber tatsächlich "an die Arbeit" und habs dann einfach abgeschickt, damit der Text nicht verloren geht. Die Idee war, da schnell weitere Beiträge drunter zu setzen (quasi als Entwickler-Tagebuch), die ich bereits in einem anderen Forum gepostet hatte (wo sich unter anderem der Autor vom originalen "Kalawaum" zu Wort gemeldet hat - was mich überhaupt erst auf die Idee gebracht hat, und die Entscheidung begünstigt hat, den Thread dort anzufangen, und nicht hier). Hier im Forum muß man Bilder extern hochladen und verlinken, um sie sichtbar zu machen, daß hat mir kurzfristig einen Strich durch die Rechnung gemacht, und nur trockenen Text ohne Anschauungsmaterial wollte ich nicht einfach rüberkopieren.
Also da kommt heute nachmittag garantiert noch was. Und Entschuldigung nochmal, kann nachvollziehen, daß das blöd gewirkt hat. Ich habe meine Lektion gelernt, und werde keine komplexen Forumsbeiträge mehr auf der Arbeit verfassen - wie zum Beispiel diesen hier.

HeX0R hat geschrieben:Dem Typen, der das Video gemacht hat, sollte man Youtube Hausverbot erteilen, oder zumindest nen Kamerastativ spendieren.
Ist ja unglaublich, was die Leute da so alles reinstellen.

Das Video ist soooo schlecht, da gebe ich dir recht. Aber es ist der einzige Online-Showcase, der zu diesem alten Spiel noch existiert.
LG, Alex

Hier ist der Link direkt auf die Projekt-Homepage der Porters nach Commodore:
http://tempect.de/senil/p2.html

Was für mich so befremdlich ist ist, dass das Spiel unter Public Domain läuft es aber den Quellcode nur auf Anfrage geben soll. Soll auch in Pascal entwickelt sein, was z. B. für mich kein Problem wäre.
Naja, ist halt auch die Frage, ob das alles nicht schon "tot" ist.

Ich würde dir empfehlen das nicht nachzuprogrammieren, sondern lediglich als mögliches Ziel vorzuhalten. So oder so, die Spieleentwicklung ist wie die Softwareentwicklung: Ein von vielen Stellen unterschätzter Zeit- und Leistungsaufwand.

BTW, gehört wirklicht unter Projektanfragen o. ä.

Atari-Magazin zum Spiel:
http://www.stcarchiv.de/tos1992/08/kalawaum

Ich programmiere es nicht anhanand des Quellcodes nach, sondern ich strebe ein Rework mit eigenen Mitteln nach. Also das Feeling möglichst original nachzustellen.
Ich werde mir selbstverständlich die Option offen halten, ein paar kleine persönliche Tweaks unterzubringen.
Das Original-Spiel habe ich unter DOS-Box zum Laufen gekriegt, das schmeiße ich zwischendurch immer mal wieder an, so als Erinnerungsstütze an damals.


Anyway, auf die Plätze, fertig, los:




Das sieht noch nach nicht viel aus, aber es ist tatsächlich schon eine ganze Menge passiert:
Zu allererst mußte ich ein paar grundlegende Fragen klären: wie speichere und lese ich die Maps aus, welche Daten sind besser in einem Array aufgehoben, und was verwalte ich als Elemente in einer strukturierten Liste)?
Zudem habe ich mich entschlossen, Auflösungs-unabhängig zu arbeiten, das heißt, daß Spiel erkennt die aktuell eingestellte Fensterbreite und -höhe und passt das Spielfenster dementsprechend an; alle Sprite-Dateien werden entsprechend skaliert.

"Kalawaum" ist Modul-basiert: man lädt ein Abenteuer, die Architektur ist fix, aber bestimme Aspekte des Spiels werden bei jedem Neustart randomisiert, was für immensen Wiederspielwert gesorgt hat. Also zum Beispiel waren Waffen und Schilde immer an denselben Orten, aber welche Waffe man letztendlich gefunden hat, war immer anders. Monstertypen, Anzahl und deren Location waren komplett zufällig. Schlüssel und zugehörige Türen waren fix, aber Türarten mit den respektiv zugehörigen Schlüsseln wurden ebenfalls randomisiert (für jedes Tür/Schlüssel-Pärchen wurde 1 von 3 Türarten ausgewürfelt), so war eine grobe Richtung vorgegeben, aber man konnte doch in jedem Spielverlauf andere Bereiche entdecken; ich werde mir erlauben eine optionale Möglichkeit einzubauen, Türen auch via Gewalt zu öffnen. Da geht dann natürlich irgendwas kaputt, oder sonstwas passiert damit es nicht die bevorzugte Methode bleibt, denn im Original konnte man sich allzu häufig in Dead End-Situationen manövrieren, wenn man die Schlüssel nicht in optimal vorgeschriebener Reihenfolge genutzt hat.
Man braucht also einen Editor um Module zu erstellen ...
Damit zusammenhängend kam die nächste Frage: erst Editor programmieren oder das Spiel? Habe mich dann für die dritte Option entschieden: beides gleichzeitig! Und zwar so synergetisch wie möglich, so daß man jederzeit während dem Editieren ins Spiel hüpfen kann um was zu testen, und dann ohne Zeitverlust direkt zurück in den Editor.

FORTSCHRITT BIS JETZT:
- Eine "Sprite-Factory" eingerichtet, die Grafiken initialisiert und in den Speicher lädt
- Man kann im Editor mit der linken Maustaste Wände malen und mit der rechten löschen
- Mit via Hotkey kann man eine Spielerposition an die entsprechende Mausposition setzen
- Man kann Maps speichern und laden
- Man kann ohne Umschweife in den Play-Modus switchen und die Map "spielen", also sich auf freien Feldern mit den NumBlock-Tasten bewegen (8 Richtungen)
- Durch gedrückt halten der Richtungstaste kann man schnell weite Strecken überwinden


Seid sarkastisch, motivierend, indifferent whatever, nur bitte drückt mir die Daumen, daß ich das diesmal durchhalte! :thumbup:

Nächster Meilenstein geschafft (auch wenns immer noch nicht nach viel aussieht): :problem:
Ein Abenteuer in "Die Gemäuer von Kalawaum" bestand nicht nur aus einem Screen, sondern aus vielen verschiedenen Maps, die über Sprungtüren und Teleporter verknüpft waren. In meinem Remake-Projekt ist es jetzt möglich, beliebig viele Maps hinzuzufügen, und auch wieder zu löschen, sowie zwischen den Maps schnell hin und her zu switchen.
Die Grafiken sind alle noch Platzhalter, klar. :geek:
Meine Entscheidung, das Spiel und den Editor synchron zu programmieren, scheint sich auszuzahlen. Man muß sich hier und da mehr Gedanken machen, aber dafür kann ich so auch viel Code sparen, da beide Instanzen aus demselben Pool schöpfen.

FORTSCHRITT BIS JETZT:
- Tile-Matrix im Editor-Modus
- Buttons für den Editor wurden initialisiert: bis jetzt sind nur zwei Buttons (Floor und Walls) aktiv, von denen kann ich aber schnell weitere hinzufügen, wenn jetzt im nächsten Schritt weitere Objekte hinzukommen. Floor und Wall-Tiles sind quasi immer aktiv, damit "malt" man mit rechter, bzw. linker Maustaste die Architektur. Andere Objekte (bis jetzt nur die Startposition für den Spieler) werden via Hotkey an die aktuelle Mausposition eingefügt.
- Mit dem Mausrad kann man von der aktuell aktiven Actor-Klasse Subtypen durchscrollen. Also z.B. verschiedene Tilesets.
- Mit der "F"-Taste (="Fill") kann man eine Map, je nachdem ob Floor oder Wall-Tiles angewählt sind, komplett mit Mauern oder Boden-Tiles füllen.

Habe gestern im Nachtdienst gute Fortschritte gemacht ...
Das Projekt wird zunehmend komplexer, aber es kommt auch mehr Struktur in den Code, da ich mir anfange, Gedanken zu machen, wie der Programmablauf später möglichst effizient über die Bühne geht. Also wann ich was initialisieren muß, welche Daten permanent im Speicher gehalten, welche temporär on the fly erstellt werden können, etc.


UPDATE:
- Die ersten Sprites erstellt. Die sind sicher noch nicht fix, aber so kriegt man schonmal optisch einen Eindruck, wie das später aussehen kann.
- Im Play-Mode gibt es einen FogOfWar, welcher erst für das richtige Adventure-Feeling sorgt, also daß man Schritt für Schritt seine Umgebung aufdeckt und erforscht.
- Grafische Abwechslung wird im Play-Mode automatisch intialisiert. z.B. die perspektivische Front-Ansicht der Mauer-Tiles existiert so im Editor nicht, die notwendigen Parameter werden automatisch bei Spielstart überprüft und entsprechend überschrieben.
- Standard-Türen sind funktional in den Editor implementiert. Man platziert eine Sorte geschlossener Türen, welche dann später, bei Spielstart, randomisiert werden (3 Varianten). Für diese müssen passende Schlüssel gefunden werden (noch nicht implementiert - die Routine fürs Öffnen der Türen existiert aber bereits).
- Obstacle()-Klasse eingefügt. Bis jetzt existiert nur der "Tree"-Subtype. Von dem existieren 3 Varianten, welche bei Spielstart randomisiert werden. Hat keine spielerische Konsequenz, dient lediglich der optischen Abwechslung.
- FloodFill-Routine optimiert: per Hotkey können jetzt alle beliebigen Base-Tiles (Boden und Mauern) mit anderen beliebigen Subtypen aus der Base-Klasse überschrieben werden.
- fixMap()-Routine gebaut, die beim Speichern die Maps auf kleine Fehler checkt (keine Mauer-Tiles unter Tür-Actors(), keine Floor-Tiles unter Obstacle-Actors(), fehlende Startposition), und wenn sie diese nicht fixen kann, zumindest via MessageRequester darauf hinweist.

UPDATE:
Immer noch kein Spieler-Sprite, aber die magischen Türen sind jetzt voll funktional; sie waren das wesentliche Rätsel-Element in "Kalawaum": durch die beiden Türen links im Bild (Magenta mit dem roten Kreis) kann nur der Spieler hindurch, keine Monster. Man muß sie auch nicht erst öffnen, sie ist quasi immer offen.
Die schwarze Tür rechts im Bild, mit dem Magenta-Dreieck, verhält sich konrär: durch sie kann der Spieler nicht hindurch, aber die Monster. Wenn jetzt der Spieler eines der beiden Pentagramm-Tiles betritt, kehren sich alle magischen Türen ins Gegenteil um.
Magische Türen haben kein randomisiertes Element: man kann im Editor gezielt beide Subtypen auswählen und platzieren.

Habe mich jetzt doch entschieden, die Fenstergröße nicht komplett frei zu skalieren, sondern mit einem Faktor von 16 (=tileSize), da die Sprites mit dem #Raw-Tag (ohne Interpolation) "resized" werden (ansonsten würde die Farb-Index basierte Maskierung flöten gehen).
- Nachteil: das Fenster wird kleiner
- Vorteil: die Grafiken wirken "cleaner" und schöner (Nicht, daß ich mich für einen großen Künstler hielte ... ).
Später, in der Polish-Phase überlege ich eh, die Ansicht mit einem mobilen Viewport zu realisieren, dann würde man nur einen quadratischen Ausschnitt um den Spieler herum sehen, welcher mit der Bewegung mitwandert. Da wäre dann die Größe der Tiles GAR KEIN issue mehr, und man könnte ohne weiteres auf eine 50x50 oder 100x100 Ausdehnung der dungeonMap() gehen, da eh nur der Bereich um den Spieler herum gezeichnet wird. Macht zudem atmosphärisch was her, und würde dem Exploration-Aspekt des Spiels zugute kommen.
Entsprechenden Code habe ich natürlich vorliegen, will aber momentan streng vertikal entwickeln. Um Details kümmere ich mich später.

WEITERE UPDATES:
- Es gibt jetzt Geheimtüren: durch die kann nur der Spieler hindurch, Monstern bleibt der Eintritt verwehrt. Man kann sie an einem vagen Riss im Mauerwerk erkennen, ein bißchen genauer muß man aber schon hinsehen.
Na, wer entdeckt den geheimen Durchgang? :think:

UPDATE:
- Item()-Klasse mit Subtyp "Key" initialisiert
- 3 verschiedene Schlüssel können platziert werden
- reguläre Türen existieren sowohl in geschlossener, als auch geöffneter Variante
- Schlüssel können im Play-Mode aufgesammelt werden
- Die aktuelle Anzahl jeden Schlüsseltyps wird im Inventar-Bereich angezeigt
- Abgeschlossene Türen können aufgeschlossen werden.
- Offene Türen werden beim Verlassen des Tiles abgeschlossen, sofern man den zugehörigen Schlüssel im Inventar trägt
- Lock_KeyConfig() - Feature im Editor

Das war ein bißchen mehr Arbeit, bis alles so funktionierte wie ich es mir vorgestellt habe. :geek:
Der Clou beim originalen "Kalawaum" war, daß zwar alle Türen und Schlüssel fix platziert wurden, aber welcher Schlüssel zu welcher Tür passte, wurde zu Beginn jeder Session neu ausgewürfelt. Die essentielle fiese Schikane war, daß wenn man eine offene Tür durchschritt, deren Schlüssel man im Inventar trug, diese Tür beim Verlassen des Tiles abgeschlossen wurde und der zugehörige Schlüssel verloren ging (immerhin war es erlaubt, Items abzulegen). Dementsprechend mußten die Maps designt sein, daß stets verschiedene Wege zur Wahl standen, den Dungeon zu navigieren - wenn man es ungeschickt anstellte, konnte es aber passieren, daß man sich unwiderruflich eingeschlossen hatte, bzw. der Weg nach vorne versperrt blieb. Da blieb einem nichts anderes übrig, als ein neues Spiel zu starten; "Kalawaum" war da ziemlich gnadenlos.
Hier werde ich mir jedoch erlauben, eine optionale Möglichkeit einzubauen, mit einem ausgerüsteten Schild oder einer Waffe jede beliebige Tür auch mit Gewalt zu öffnen - mit dem Risiko, daß entsprechendes Item zerstört wird, bzw. das Öffnen abhängig von Stärke des Items auch fehlschlagen kann. Soviel Roguelike muß sein!

Als zusätzliches QoL-Feature für den Editor habe ich die Option eingebaut, eine bestimmte Schlüssel/Key-Konfiguration für Testzwecke zu "locken". Das funktioniert jedoch nur, wenn man das Spiel aus dem Editor heraus startet - bei einem regulären Spielstart wird die Konfiguration ausgewürfelt und bleibt für die jeweilige Session fix.