Elgondolkoztam, hogy ha ilyen játékot akarnék írni basicben, akkor hogyan kéne megírni. Maga az irányítás nem probléma, de amikor odakattintunk egy mezőre, és végignézi a gép a fél pályát és felfedi az üres mezőket minden irányban a falakig, és még azt is figyelembe veszi, ha útközben nem üres a pálya, és azt is körbekerüli... ebbe belegondolva elvesztettem a fonalat. Ha üres mezőt talál, akkor abból mindig nyílhatnak újabb és újabb üres mezők, és erre az összes mezőre hivatkozást letárolni valahol, majd ha megnéztük, törölni a tárolási helyéről... nem is tudom elképzelni, ezt hogyan lehetne megcsinálni. Egyelőre még gondolkozom az elven. Addig is ErgoGnomik fórumtárs elképzelése az algoritmusról:
- Vizsgáld meg a kattintott mezőt! Ha bomba, véget ért a játék, ha bombával szomszédos mező jelenítsd meg a számot és vége a műveletnek.
- Jelenítsd meg az üres mezőt!
- Vizsgáld meg a körülötte található nyolc mezőt! Ha pályán kívüli, akkor nem csinálsz semmit, ha bomba, akkor hiba történt, ha szám, akkor jelenítsd meg, ha üres, akkor jelenítsd meg, és vedd fel a mezőt egy listába!
- Válaszd a lista soron következő (kezdéskor első) elemét!
- Vizsgáld meg a körülötte található nyolc mezőt! Ha pályán kívüli, akkor nem csinálsz semmit, ha bomba, akkor hiba történt, ha szám, akkor jelenítsd meg, ha üres, akkor jelenítsd meg, és vedd fel a mezőt egy listába!
- Folytasd a 4. ponttól, amíg el nem fogynak a lista elemei!
Kicsit gyakorlatiasabban:
Miután az IS-BASIC-ben nincs igazán dinamikus adatszerkezet,
ezért nincs más hátra, mint tömbökkel helyettesíteni. Mivel nem
egyszerű pontos becslést adni arra, hogy maximum mennyi elem kerülhet az
ellenőrzés során függő elemként bele, mondhatjuk azt, hogy a
játékterület nagysága mínusz az aknák száma legyen a tömb mérete. Ezzel
biztosan felülbecsültük az egyszerre tárolandó elemek számát.
Lehet
két tömb, amiben a megjegyzett elemek vízszintes és függőleges
koordinátáit tárolod, nyilván egy koordináta pár a két tömb azonos
indexű elemébe lesz beírva.
- Kell egy változó (pl. E), ami mindig a lista aktuális elejére mutat, aminek induló értéke a tömb első indexe.
- Egy másik változó (pl. V) mutasson mindig a lista aktuális utolsó elemére, ami induláskor szintén az első tömbindex. Ez utóbbi változót mindig eggyel növeled, amikor új elemet veszel fel.
- Amikor feldolgozod a listába beírt elemeket, akkor kiolvasod az első változóhoz (E) tartozó tömbelemet, és növeled ezt a változót addig, amíg az ismételt feldolgozásokkal el nem érsz a lista vége változó (V) értékéig.
- Közben természetesen egy harmadik változót (pl. K), aminek a kiinduló értéke a feldolgozás megkezdésekor vegye fel a vége pozíció értékét, arra használsz, hogy adminisztrálhasd az újonnan hozzáadandó elemeket az értékének hozzáadásonkénti növelésével.
- Ekkor meg lehet tenni, hogy a vége és a harmadik változó közötti elemeket a tömb elejére másolod, az eleje változót alapértékre állítod, a vége változó új értékét a harmadikból a vége kivonásával (V=K-V) kapod, a harmadik meg vegye át a vége értékét (K=V), és újra megkezdheted a feldolgozást.
- A feldolgozásnak akkor lesz vége, ha az előre másolás megkezdésekor a vége és a harmadik változó értéke egyező (V=K).
Egy másik probléma lehet a program megírásakor az aknák elhelyezésével kapcsolatban. Elvileg véletlenszerűen szórhatjuk szét az aknákat a pályán. Azonban figyelni kell, hogy bizonyos helyzeteket elkerüljünk, amikor a játék nem lesz teljesíthető logikával, csak szerencsével. Például, amikor egy mezőt mind a 8 oldalról körbevesznek aknák, nem tudhatja kikövetkeztetni a játékos, mi van azon a mezőn. Vagy, ha a pálya szélénél, ill onnan kettő karakterrel beljebb váltakozva fordulnak elő aknák, akkor se lehet mindig egyértelműen tudni, hogy egyes aknák mögött mi lehet. Lehetséges, hogy a windows-os aknakereső sem mindig véletlenszerűen szórja el az aknákat, hanem előre elkészített pályákon játszódik a játék.
No comments:
Post a Comment