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

Es gibt 86 Antworten in diesem Thema, welches 16.679 mal aufgerufen wurde. Der letzte Beitrag (10. März 2019 um 02:24) ist von JeeK.

  • Der Scott Adams der da erwähnt wird ist übrigens der Dilbert-Zeichner, wusste gar nicht dass der mal für den C64 programmiert hat.

    Nein. Bitte melde dich an, um diesen Link zu sehen.) vs Bitte melde dich an, um diesen Link zu sehen.
    Der erste Scott ist der bekannte Adventure Scott Adams.

    ___________________________________________________________
    Meine Kreationen: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • Nein. Bitte melde dich an, um diesen Link zu sehen.) vs Bitte melde dich an, um diesen Link zu sehen.Der erste Scott ist der bekannte Adventure Scott Adams.

    Ups, da habe ich mich von dem Link auf die Bitte melde dich an, um diesen Link zu sehen. - Seite verleiten lassen, danke für die Aufklärung! Ist auch spannend zu lesen, dass der Game Designer Scott Adams in letzter Zeit wieder was gemacht hat.

  • Kein Problem, ich war auch schon mal darüber gestolpert und hatte das dann eben auch nachgeschaut.
    Seine Adventures kann man z.B. hier runterladen: Bitte melde dich an, um diesen Link zu sehen.

    Offizielle Webseite: Bitte melde dich an, um diesen Link zu sehen.
    Hier noch eine Link Collection: Bitte melde dich an, um diesen Link zu sehen.


    Bei GET LAMP (sehenswürdige Doku) wurde er auch interviewed: Bitte melde dich an, um dieses Medienelement zu sehen.

    ___________________________________________________________
    Meine Kreationen: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • Hmmm...
    Nehmt mal den BasicBoss-Compiler.

    Ist mein Lieblinkscompiler. Kann da auch mein Basicdialekt verwirklichen.... kann mich davon nicht trennen, gehört einfach zum C64.
    Ich möchte nichts mit Sub und den modernen Zeugs.

    Mit dem BasicBoss kann man die Wünsche die hier Auftreten beseitigen.

    Ich mag auch kein ASM-Advanture schreiben, ist grässlich.

    demo.prg einfach in den Vice ziehen oder auf DSK für den echten C64.

    Gruss

  • Die Eingaberoutine ist der Teil von Zeile 20 bis 70, ich hatte im ursprünglichen Code noch die Steuerzeichen herausgefiltert, sodass die Eingaberoutine "cooler" als INPUT ist.
    Das erzeugt jedenfalls ordentlich temporäre Strings, Zeile 20 gibt das nach jeder Eingabe aus. FRE() habe ich hier bewusst nicht verwendet denn dass hätte jedesmal eine Garbage Collection getriggert. Zeile 10 ist übrigens nur zum Speicherplazverbrauchen da, damit nur wenig mehr als 2K überbleiben.
    Nach und nach werden die 2K weniger, aber wenn man lange genug herumtippt kommt es zu einer automatichen GC, die aufgrund des kleinen Stringspeicherbereichs nicht viel zum aufräumen hat.

    Langer Rede kurzer Sinn:
    1. Aufpassen mit derartigen Eingaberoutinen, Formel in Zeile 20 hilft, Speicherfresser zu entdecken
    2. ansonsten spricht meiner Meinung nach generell nichts gegen ein Textadventure in BASIC

    Ad Müllvermeidung: Ein Vergleich mit CHR$(13) ist z.B. so immer schlecht. CHR$() erzeugt immer einen temporären String. Besser wäre es, das Zeichen in eine Variable abzulegen. Wie gesagt, ist der Nutzen von FRE() recht beschränkt. Man steuert lediglich den Zeit, wann ein Maximum an freiem Speicher zur Verfügung steht und könnte so ein Maximum an Zeit heraus schinden, bis eine GC erneut (automatisch) zuschlägt. Zu mehr nützt es nichts.

    Zeile 10 für Speicherplatz verbrauchen - das sind Strings genau das Allerschlechteste. Die GC muss sich in jedem Durchlauf durch 12.000 Deskriptoren (auch wenn sie leer sind und nicht berücksichtigt werden müssen) wälzen. Wenn das Programm so schon sagen wir 100 nichtleere Strings hätte, dann multipliziert sich 12.000 mit 100, das heißt also 120.000 Durchläufe die dann ihre Zeit brauchen ...
    Besser wäre es die Speicherplatzverknappung mit einem Float- ode Integer-Array zu machen: Statt DIMA$(12000) also DIMA%(18000), entsprechend größer, da Integer nur 2 Bytes brauchen. Da wird gleich das ganze Array in einem Schritt übergangen und nicht wie im String-Array alle Elemente relative zeitraubend "angesehen".

    Der Conclusio schließe ich mich an, dass generell BASIC für Textadventures geeignet ist. Das zeigt ja auch die Vielzahl der vorhandenen Umsetzungen.
    Ergänzend nur um einen Irrglauben zu entgegnen: Wenn die Anzahl der Strings im Programm in 100er-Bereich ist, dann ist die normale GC verkraftbar. Dabei ist es aber kontraproduktiv, den freien Speicher künstlich zu verringern. Damit löst die GC nur nur öfter aus - unnötigerweise. Es kommt nämlich nicht auf die Menge des produzierten Mülls an, sondern *nur* auf die Anzahl der aktiven Strings an. Da sich diese aus dem Programm mehr oder weniger zwangsläufig ergibt, ist es eher besser, wenn viel freier Speicher vorhanden ist, weil dann die GC weniger oft auftritt. An der Laufzeit der GC selbst ändert das nichts.
    Wenn es Strings im 1000er-Bereich sind, dann ist die Verwendung einer alternative Implementierung, wie die SuperGC erwähnt im Bitte melde dich an, um diesen Link zu sehen. stark anzuraten. Da geht dann nichts mehr mit "Herumtricksen" ...


  • Zeile 10 für Speicherplatz verbrauchen - das sind Strings genau das Allerschlechteste. Die GC muss sich in jedem Durchlauf durch 12.000 Deskriptoren (auch wenn sie leer sind und nicht berücksichtigt werden müssen) wälzen. Wenn das Programm so schon sagen wir 100 nichtleere Strings hätte, dann multipliziert sich 12.000 mit 100, das heißt also 120.000 Durchläufe die dann ihre Zeit brauchen ...
    Besser wäre es die Speicherplatzverknappung mit einem Float- ode Integer-Array zu machen: Statt DIMA$(12000) also DIMA%(18000), entsprechend größer, da Integer nur 2 Bytes brauchen. Da wird gleich das ganze Array in einem Schritt übergangen und nicht wie im String-Array alle Elemente relative zeitraubend "angesehen".


    Hast recht, im konkreten Fall wollte ich aber einen Belastungstest schaffen. Hätte ich DIMA%() genommen, würde ich es der GC ja leichter machen.

    Mein Beispielprogramm sollte nur zeigen, dass eine EIngaberoutine so wie ab Zeile 30 ein Speicherfresser ist - bitte nicht nachmachen!


    Dabei ist es aber kontraproduktiv, den freien Speicher künstlich zu verringern.


    Verkleinerung im Demoprogramm war nur drin um ein Beispiel zu schaffen, dem der Stringspeicher ausgeht.

  • Mein Beispielprogramm sollte nur zeigen, dass eine EIngaberoutine so wie ab Zeile 30 ein Speicherfresser ist - bitte nicht nachmachen!

    Ja, das stimmt. Aber das an sich stört ja auch nicht, wollte ich nur klarmachen. Selbst wenn man CHR$(13) vermeidet, hat man immer noch s$=s$+a$ ... so etwas produziert auch immer String-Müll. In diesem Fall aber nur, wenn wirklich eine Taste gedrückt wird.Das ist ja nichts Böses - in erster Linie. Die Vermehrungsrate ist ja nicht allzu extrem. Natürlich, je schneller Müll produziert wird, desto eher wird der freie Speicher aufgebraucht und umso eher wird die GC aufgerufen. Die testweise Speicherplatzverknappung zeigt das hier ganz gut.