Hallo Besucher, der Thread wurde 12k mal aufgerufen und enthält 86 Antworten

letzter Beitrag von JeeK am

Wer hat Lust ein Text-Adventure zu programmieren? (C64 Basic 2.0)

    Hallo zusammen,


    wer Lust und Laune hat ein Textadventure auf den C64 zu programmieren, kann sich gerne melden.
    Ich bin selber noch ein Dinosaurier und Anfänger und lerne täglich dazu.
    Story und alles andere steht so gut wie fest !


    Programmiert wird auf den C64. Raum Berlin wäre perfekt - aber kein muss !




    Einfach anschreiben, danke.


    Gruss ---Bishop ---

    Zitat von Bishop

    Wie hast du denn das mit den Parser gemacht?

    Du könntest http://www.stojalowski.de/BasEdit/ verwenden um einfacher unter Windows den Sourcecode anschauen zu können.

    Wahrscheinlich werde ich gleich geschlagen, aber ... wieso tut sich jemand so ein Projekt in BASIC überhaupt an? Textadventures sind zwar in der Regel nicht zeitkritisch, also muss es nicht unbedingt Assembler sein. Aber sie sind groß und komplex, also ist es doch sehr von Vorteil, wenn die verwendete Sprache eine gewisse Strukturierung erlaubt? BASIC ist da IMHO noch schlechter als ein guter Assembler. Für so ein Projekt drängt sich doch geradezu die Sprache C auf? :)

    Zitat von zrs1

    Wahrscheinlich werde ich gleich geschlagen, aber ... wieso tut sich jemand so ein Projekt in BASIC überhaupt an? Textadventures sind zwar in der Regel nicht zeitkritisch, also muss es nicht unbedingt Assembler sein. Aber sie sind groß und komplex, also ist es doch sehr von Vorteil, wenn die verwendete Sprache eine gewisse Strukturierung erlaubt? BASIC ist da IMHO noch schlechter als ein guter Assembler. Für so ein Projekt drängt sich doch geradezu die Sprache C auf? :)

    Also meine Motivation ist follgende:
    Ich möchte ein Grundprogramm schreiben, das sowohl auch dem C64 wie auch auf dem C65 läuft und nur kleine Teile in denen es unterschide gibt wegkapseln.
    Es geht mir dabei darum Wege aufzuzeigen, wie man Software für den C65 produzieren kann und dabei auch was für den C64 macht, so dass man keine Angst haben muss etwas zu entwickeln was dann zu wenig User haben könnte.


    Zitat von oobdoo

    Du könntest http://www.stojalowski.de/BasEdit/ verwenden um einfacher unter Windows den Sourcecode anschauen zu können.

    Ich hatte den Code das letzte mal schon als source beigelegt, nur wollte das Forum bas nicht haben. Hier nochmal als txt.


    Für Verbesserungen an der Engine bin ich offen.


    Was aber viel wichtiger ist, ist die Storry - oder besser gesagt viele Storries.
    Die kannst Du auch gerne in Excel programmieren. (Ich hänge auch mal das Excel an, aus dem die DataZeilen entstehen (O.K., das Forum mag auch kein cvs, also auch als txt)).
    Ich hatte noch keine Zeit ne Doku zu schreiben - wie gesagt, das ganze ich ganz frisch und bis gestern war ich noch einem Interruptproblem auf der Spur.


    Der Pharser ist noch recht primitiev, er erkennt "Sätze" mit bis zu 4 Wörtern:



    Auch die Eingaberoutine ist noch rech simpel.
    Man kann noch nicht unter den geschriebenen Text hin und her scrollen und Buchstaben dazwischen einsetzen und auch eine History (welche auch erst dann Sinn macht) gibt es noch nicht.
    Und auch eine Textcompletion ist noch in weiter ferne.

    @Zaadii wenn man fies wäre könnte man fragen: Was zum Geier ist ein C65? :D Ja, ich weiß, es gibt ein Projekt, endlich mal einen funktionierenden C65 zu bauen. Nunja. Ich sehe trotzdem nicht, warum man sich dafür dieses antiquierte BASIC ans Bein binden sollte. Auf dem C64 war es ja effektiv so: BASIC war drin, weil sich das besser verkaufen lies, wenn irgendne "Hochsprache" integriert ist, so dass jeder direkt loslegen kann. Ernstzunehmende Softwareentwicklung passierte damals allerdings in Assembler. Heute sind wir ein paar Schritte weiter -- klar, virtuelle runtimes (wie die Java VM oder die .NET CLR) sind außerhalb der Reichweite eines alten 8-bitters, aber die kommen eh langsam wieder aus der Mode, dank schlanker Userland-VMs, wie sie die FreeBSD jails eingeführt haben und Docker jetzt endlich in die Breite bringt ... aber ich schweife ab. Jedenfalls hat man heute, also schon ziemlich lange, auch Hochsprachen, die sehr gut strukturiert sind und sich direkt in nativen Maschinencode compilieren lassen. Sowas würde ich für so ein Projekt jederzeit bevorzugen, und wenn es für den C65 noch nichts gescheites an Crosscompilern gibt, wird es höchste Zeit ;)

    @zrs1 (cool diese @ sache kannt ich noch garnicht).
    Ich gehe da lieber einen anderen Weg. Ich halte lieber die Daten allgemien - also eine Algemeine Definition des Spiels oder viel wichtiger der Spiele. Die Beschreibung ist extra so konzipiert, dass sie auch eine umsetzung in (8-Bit) Assembler berücksichtigt.


    Von dort aus kann man dann nach Basic, Assembler oder z.B. (was ich mittelfristig auch vor habe) nach Android generieren.


    Wenn Du Lust hast, kannst Du gerne auch eine C-Engine beisteuern. Die Community wäre bestimmt begeistert das selbe Spiel in verschiedenen Umsetzungen zu sehen.


    Überigends werde ich vermutlich eine kelinen Teil der Engine in Assembler umsetzen, und zwar den Teil der die eingegebenen Gegenstände von Text in IDs umsetzt, und zwar soblad ich in zu große Laufzeitprobleme Laufen sollte.


    Inputs zu Erweiterung der Beschreibungssprache nehme ich gerne auch auf.
    Aus meiner Sicht fehlen noch Consumables und Charaktere - aber die ersten Games werde ich wohl ohne machen.

    @Zaadii klingt erstmal interessant :) Also um ehrlich zu sein, ich habe noch nie etwas in C für den C64 fertiggestellt, einfach weil ich immer an dem Punkt "jetzt wäre Assembler doch einfacher" ankam :D Aber ein Textadventure klingt eben schon nach Bauchgefühl nach einem idealen Usecase für C. Wundere mich eben nur nach wie vor, warum sich jemand für so ein Projekt heute noch BASIC ans Bein binden mag ... vielleicht ist das eine besondere Form der Nostalgie :)


    Das mit Android müsstest du noch erklären glaube ich :o Soweit ich die Plattform kenne ist man da doch sehr stark an die Dalvik VM gebunden?


    Jedenfalls, für ein Textadventure ist es sicher ein guter Plan, ein "storyfile" zu spezifizieren, das dann von einer Engine abgearbeitet wird. Trotzdem glaube ich eben, dass das in BASIC unnötig kompliziert werden könnte ;)

    @zrs1:
    C auf den C64 ? Ich weiss nicht.
    Mein Grundgedanke war ja, allen ernstes ein Textadventure mit Basic zu schreiben. Das geht, wenn auch etwas umständlich (mit Nostalgie hat das weniger zu tun). In Assembler kenne ich mich noch nicht so gut aus. Hatte auf den Amiga ein paar Versuche mit Assembler getätigt. Mit zugegeben, eher mässigen Erfolg. Dafür bin ich einfach nicht gut genug. Ist Fakt.


    Das Basic 2.0 auf den C64 nicht gerade beliebt ist, weiss ich. Aber mich reizt halt die Tatsache, es genau in dieser Sprache umsetzten zu wollen.
    Was sollte auch verkehrt daran sein? :)


    Danke für deinen Beitrag.


    Gruss aus dem verregneten Berlin...Bishop

    Hi ZeroZero,


    Ihr könnt gerne eigene Geschichten erstellen. Die Idee ist ja, dass sich daraus eigene Programme ergeben.
    Wie gesagt ich habe noch keine Doku, da das ganze noch recht jung ist, aber ich fasse mal kurz zusammen.
    In dem Excel (ich verwende Open Office, aber em ende braucht man einfach ein CVS) gibt es Sectionen die durch eine Zeile eigeleitet werden und dann in jeder Zeile einen Eintrag enthalten:
    %%ROOMS
    RaumName, ID des Raums der mit diesem nach Norden verbunden ist, osten, süden westen, Raumbeschreibung.
    Dabei haben die Räume die ID in austeigenden Reihenfollge wie sie im Excel auftauchen, wobei der erste Raum die ID 1 hat.
    Eine Eintragung von 0 bei den Richtungen bedeutet, dass es in diese Richtung nicht weiter geht.


    %%OBJECTS


    Objekt-Name, Initialer Ort (ID des Raumes (oder eines anderen Objektes)), Gewicht, Lesbar (noch nicht verwendet), Beschreibung
    Objekte mit einem Gewicht von 255 können nicht mitgenomme werden, wobei in diesem Fall die Engine nicht mit dem Gewicht argumentiert. So können Möbel, Felsen, Bäume und dergeliche Modelliert werden.


    %%USE
    Object-name1, notwendiger Zustand von Object1, Object-name1, notwendiger Zustand von Object1, Ojbektname, neuer Ort der Objektes, neuer Zustand des Objektes , Ojbektname, neuer Ort der Objektes, neuer Zustand des Objektes , Text


    Dabei ist bei Zustand und Ort der Wert 255 ein (Egal (im Lesefall) oder ein "Nicht Ändern (im Schreibfall).


    Beispiel:



    REVOLVER 0 MUNITION 255 REVOLVER 255 5 MUNITION 253 255 DU LÄDST DEINEN REVOLVER NACH



    Verwende Revolver mit Munition.


    Geht nur wenn Revolver Zusatnd 0 hat (dann ist er nicht geladen)


    Zustand der Munition ist egal.


    Ausserdem testet die Enging, noch ob Revolver und Muni im Inverntar oder aktuellen Raum sind.


    Passt das alles so geschiet follgendes:


    Es wird ausgegeben: Du lädst der Revolver.


    Der Revolver bekommt den neuen Zustand 5, sein Ort (inventar oder Raum) bleibt unverändert.


    Die Munition wandert nach Out-Of-Game (253) und der neue Zustand ist egal.




    %%EXAMINE
    Examineeinträge sind optional. Sie greifen wenn "Untersuche" eigegeben wird. Wird untersuche eingegeben, so wird normalerweise die Brschreibung der Objekts ausgegeben. Ist jedoch ein Examine-Eintrag mit richtigen Zustand vorhanden so wird dieser stattdessen ausgegeben.
    Beispiel:


    REVOLVER 1 HUCH! NUR NOCH EINE KUGEL DRIN
    REVOLVER 2 LANGSAM GEHT DIE MUNITION AUS! NOCH ZWEI KUGELN IM REVOLVER
    REVOLVER 3 NOCH DREI KUGEL SIND DRIN
    REVOLVER 4 FAST VOLL: VIER KUGELN
    REVOLVER 5 KOMPLETT GELADEN MIT ALLEN FÜNF KUGELN




    Und das Revolver Objekt selber:



    REVOLVER 254 102 255 KEINE MUNITION MEHR!




    Objekte starten immer mit dem Zustan 0
    Eventuell füre ich hierfür noch eine Sektion ein, um das zu ändern.


    %%DOORS
    Türen_Name,raum1(id), raum2(id), stastats (open0,cosel1,sealed2), Name des Schlüssels (ein slocher Schlüssel muss unter Objekte definiert sein) oder "no" falls es keinen Schlüssel gibt, Textuelle Türbeschreibung.


    %%MULTIITEMS
    Objekt-Name (muss genauso als Objekt definiert sein),raum1(id), raum2(id),raum3(id), raum4(id), Textueller Grund - warum das Objekt nicht itgenommen werden kann.


    Multiitems sind objekte die in mehreren Räumen auftauchen können. Sie haben rein dekoratieven Charakter und können nicht mitgenommen werden und keine anderen Zustand al 0 haben.





    So weit hab ichs grad.
    Ich denke das ist so das Minimalset mit dem man ein Adventure machen kann.


    Jeder kann also sein eigenes Storyboard haben :-)

    Also ich verstehe schon @zrs1 Sichtweise und mag seine persönliche Präferenz sein, aber so eine auf Interpreter basierende Entwicklung hat dennoch das gewisse Etwas im Vergleich zu einer Cross-Entwicklung. Die Turn-around-Zeit, um eine Kleinigkeit zu variieren oder zu korrigieren ist in einer Cross-Umgebung doch auch nicht zu unterschätzen, oder?


    BASIC 2.0 als interpretative Umgebung mag wohl nicht die sauberste und ideale Hochsprache sein und auch für eine etwaige Portierung eher hinderlich sein. Aber als "Glue-Language" für die Rahmenprogrammierung find ich sie persönlich ganz praktisch und überschaubar. Das gewissen Teile auch aus Maschinencode bestehen, kann ja dennoch sein und durchaus zu einem ansehnlichen Ergebnis führen.
    Ich weiß nicht, ob es jetzt etwas bringt zu versuchen, den Initiator radikal auf einen anderen Pfad der Entwicklungsumgebung zu überreden? Jedem das Seine. Das eigene Mitwirken sollte jedenfalls nicht davon abhängig gemacht werden, ob nun die eigenen Vorlieben erfüllt werden. ;)


    Ich bin jetzt nicht so der Textadventure-Fan, aber programmiertechnisch interessiert mich Grundsätzlich BASIC 2.0. Wenn es um Optimierung und Struktur geht, bin ich interessiert und helfe gerne. Speziell bei - auch meinen eigenen - Projekten mit String-Lastigkeit, wäre eine eventuelle Berücksichtigung der Garbage-Collection-Problematik anzudenken, siehe z.B. alternative GC

    Das wäre ohnehin ausschließlich für das Basis-Verständnis des Prozesses - heute wird natürlich überwiegend mit Skripting oder Bausteinen entwickelt. Das ist nur, weil ausdrücklich nach absoluter Basis gefragt wurde. Lasse da gerne, sehr gerne, andere Ansätze rein, die Bishop hilfreicher sein können. Bitte mischt Euch rein! Ist absolut ernst gemeint!

    Ich vermute das Bishop keine großen Programmiererfahrungen hat oder wenn dann sind sie 30 Jahre her.
    Schlechter Ruf vom V2 hin oder her. Ich finde es absolut Ok erstmal nur bei BASIC zu bleiben.