Az jutott még eszembe, hogy léteznek eljárások, melyekkel labirintust lehet generálni. Itt a pálya sem olyan nagy, és még zzzippelve is lesz a program. Nem lehetne ilyet bedobni? Istvánnak volt ilyen eljárása, de az emlékeim szerint LUA-ból futott.
Itt mondjuk a falra is figyelni kéne, hogy megfelelően legyenek a vonalak benne, ha a program generál labirintust.

Még egy ötlet: ahogy megyünk előre újabb pályákra, picivel mindig magasabb lenne a hang, ahogy a sebesség is szép lassan nőne. Ez némi plusz számítással jár, de talán nem vészes.
[/quote]
Be kellene rakni egy FOR/NEXT ciklust  a programba megnézni mekkorát lehet még beilleszteni várakozásra az 1. pályán ami még elfogatható.Persze Zzzip-n tesztelve.
Ezután már csak elkel osztani a pályák számával és annyival csökkenteni a FOR/NEXT ciklust.

Hasonlót akartam én is és mivel CALL / DEF .... használsz bárhova kerülhet.
Írj egy teszt programot úgy 200 ciklusnyi CALL/ DEF , GOSUB /RETUN és GOTO ra TIME meg méri.
Végül is nem jelentős főleg ha Zzzip-eled.

Na most kezded értelmezni/érteni a programozást.

Ha most elkezded újra írni akkor a SPEEK is könnyebben bekerülhet.

Könnyebb újat építeni mint a régit foltozgatni.

Mindent nem kell tudni csak azt hogy hogyan működik a program.
Utána már könnyebb új szabályokat be írni.
Nem én írtam ezt a programot mégis ahogy kezdem megérteni úgy tudom javítani.
Mivel az elején van egy kis hely így elkezdhetem előre pakolni ami hátul van.
Ha még van egy kis idő akkor folytatom a rendezést vagy ne.
Ahogy rendezem nem átláthatóbb a program ?

Az összes karaktert akarod vagy csak egy párat?
A CHARS lehetne DEFAULT_CHARS akkor visszaállítja és egy KRIKSZKARAKSZ_CHARS
A Zzzip nek mikor lesz a baja ha sok a sorszám vagy ha magas az?
Sok sor számmal tovább pörög kevéssé pedig sokáig.
BASIC-ben 9999 sor lehet ezt a Zzzip nek le kell kezelnie.

Akkor folytatom a rendezéseket.

Egy tipp, hogy jól működik az emu:
Betöltöd a programot TEXT 80 és LIST ha nem látsz rendellenességet akkor talán jó.

Biztos ami biztos én EXOS2.1 és BASIC2.1 használok igaz ezeknél nekem nem megy a Zzzip 1.2 még.

Javítgattam és elkezdtem SPEEKelni igaz egyenlőre a MENÜ résznél.
Ezek csak probák.
A MENU résznél nem lassítja a programot látványosan a CALL mert csak alig alig van meg hívva.
Viszont a játékban nem valószínű de lehet lassulás.

A fejlesztés idejére szerintem jobb különszedni az utasításokat sorokra. Csak a végén érdemes összenyomorítani amit lehet, amikor már a végleges változatot készíted elő a kiadásra.

A 780 - 850 sor az mit akar jelenteni ? Valami maradvány ?

Oda soha nem jut el a végrehajtás?
A szörnyek irányát állítja be indulásnál. Megnézi, hol van mellettük fal. Volt egy bibi, mégpedig az, hogy a bogyókat is falnak nézte, és így valamelyik szörny el se indult.
Van egy olyan alapprobléma, hogy a KEP$ tömbben csak a pálya van benne, a falak. A bogyók nincsenek benne. A szörnyeknél ez nem is kellett, mert ők csak a falat nézik, és vagy bogyót tesznek maguk után, vagy szóközt. A bogyók azért sincsenek benne a KEP$ tömb értékében, mert akkor minden egyes bogyó felszedésénél vagy (szörny általi) lerakásánál módosítani kéne a KEP$ tartalmát, ami lassítaná a játékot. Viszont az is lassítaná, ha a szörny a falakat nem a KEP$ tömbből, hanem a képernyőről venné PRINT #102... és GET #102... utasításokkal. De mi már királyok vagyunk, mert ezeket mind helyettesíteni tudjuk a SPEEK-kel.

Azért néz ki olyan furán, hogy IF ... >"0", mert az olyan karakterekre vonatkozna az IF, melyek a "0" után vannak a kódjuk szerint. Tehát minden olyan karakterre igaz a feltétel, melyek kódja nagyobb, mint a 0-ás karakter kódja. Itt most azt hiszem, a varázstabci, a bogyó és a szóköz mint pályaelemek kódját akartam egy füst alatt elintézni. Írhattam volna azt, hogy IF ... ="<szóköz>" OR ... = "<bogyó>" THEN, vagy valami ilyesmi, csak az a sok OR úgy gondoltam, lassítaná az egészet.

Remélem, érthető. Tudom, bonyolult vagyok és összevissza gondolkodtam, azt se tudtam, mit akarok, lehet szidni.