Yet Another Simple Memory

by V · 2025.09.30.

Különleges lesz ez az írás, mivel egy általam készített játékról szól, amit az idei (azaz 2025-ös) Árok Party játékfejlesztő versenyére készítettem.

Ez egy klasszikus memóriajáték, melynek alapszabálya elég egyszerű: egy rácsos elrendezésű táblán (beállítástól függően 40-64 mezővel) lefordított csempék helyezkednek el, amelyek közül a játékos párokat keres, vagyis egyszerre kettőt fordít fel. Ha a két kiválasztott csempe képe megegyezik, akkor azok eltűnnek a tábláról. Ellenkező esetben viszont visszafordulnak és a játékosnak meg kell jegyezni a helyüket, hogy a következő próbálkozására már ezek ismeretében kerüljön sor. A játék addig tart, amíg az összes csempe el nem tűnik vagy amíg a rendelkezésre álló idő el nem fogy.

A kezdőképernyőn balra a játéktábla, jobbra pedig a különböző – a nehézségi szintet befolyásoló – beállítási lehetőségek látszanak.
Az F7-tel lehet a tábla méretét 5×8 és 8×8 közötti értékre állítani. Értelemszerűen a kisebb táblát könnyebb kipucolni.
Az F5 nyomogatásával a rendelkezésre álló időt módosíthatjuk 120 és 240 másodperc között, 30-as lépésközzel.
Az F3 segítségével háromféle csempekészlet közül lehet választani, vagyis a csempéken levő képeket variálhatjuk. (Apró jótanács: néhány kör után érdemes cserélni, mert néha bele tud zavarodni az ember abba, hogy éppen az aktuális vagy a korábbi játékban látott egy bizonyos csempét egy adott pozíción.) A választható csempe témák az alábbi ismert játékok figurái, hátterei lehetnek: Giana Sisters, Impossible Mission és Henry’s House.
Ha mindent beállítottunk, akkor az F1 megnyomásával indul a játék.

A visszaszámlálás után segítségképpen egy rövid ideig – soronként – megnézhetjük a felfordított csempéket, majd megjelenik az összes immáron lefordítva és indul az óra, kezdődhet a próbálgatás. Akinek jó a rövidtávú memóriája, az az előzőleg felvillantott „preview” alapján néhány párt kapásból megtalálhat, ám a többit végül úgyis próbálgatással kell összepárosítani.

Kezdéskor a bal felső mezőn (sakkozóknak A1) levő csempe van kijelölt állapotban, azaz sárga színnel jelölve. Ezt a jelölést lehet a táblán ide-oda mozgatni és ilyen módon kiválasztani a felfordítani kívánt csempét. A kurzor irányítására többféle lehetőség van. A balkezeseknek a PC-ről ismerős WASD gombok használata javasolt, míg a jobbkezeseknek, illetve az emulátort használóknak inkább a FEL-LE és JOBBRA-BALRA kurzorbillentyűk eshetnek inkább kézre. Az aktuális csempe felfordítására a SPACE vagy a RETURN gombok valamelyike használható. Persze az igazi retro játékos érzést talán a joystickos irányítás adja meg, ami a 2. portra csatlakoztatva szintén használható, bár megvallom őszintén én inkább billentyűzetpárti vagyok ennél a játéknál.

Mivel párokat keresünk, ezért logikusan két csempét kell felfordítani minden egyes próbálkozás során. Ha sikerül párt találni, akkor azok a csempék eltűnnek és a helyükön egy kis pipa (✓) jelenik meg.
Ahogy fogynak a lefordított csempék, úgy lesz egyre könnyebb a további párok megtalálása, de az idő nagy ellenség, szóval igyekezni kell a forgatással.

Ha menet közben esetleg csörög a pizzafutár, vagy a sok elfogyasztott folyadék kikívánkozik, akkor a P gombot (Pizza, Pössentés vagy Pause, ahogy tetszik) használva meg lehet állítani a játékot. Ha pedig a játékos úgy dönt, hogy inkább feladja a küzdelmet és nem kívánja folytatni az adott pályát, akkor az F5 megnyomásával erre is lehetősége van. Ilyenkor visszakerül a kezdőképernyőre és módosíthat a beállításokon mielőtt újra próbálkozik.
Ha pedig letelik az idő vagy elfogynak a megtalálható párok, akkor a játék kimenetelének megfelelő kis animáció megtekintése után szintén visszajutunk a kezdőképernyőre és új menetet kezdhetünk.

A játékot minősíteni nem szeretném hiszen, mint írtam, az a saját fejlesztésem. Az mindenesetre elmondható, hogy a címéhez hűen nem túl bonyolult, a kezelése egyszerű, a grafikája pedig minimalista. Mivel a játékmenet gyors, ezért casual játékosoknak ideális lehet.

Eddig az ismertető, most pedig jöjjön pár szó a fejlesztésről, hátha valakit az is érdekel. 🙂
Az, hogy kéne valamit készíteni az Árok Party Game Dev. compojára, már az előző évi találkozó után megfogalmazódott bennem. Sokáig csak fejben „készítettem” ezt-azt, vagyis agyaltam az elkészítendő programon, s nagyon sokáig egy teljesen más fajta játék megvalósítása körvonalazódott, ám továbbra is egyetlen sor kód írása nélkül. Egyszer aztán megláttam a TV-ben valamilyen vetélkedő részletét, ahol egy hasonló memóriajátékot játszottak. Mivel régebben játszottam már számítógépen ilyet és elég jó is voltam benne, ezért innentől kezdve ezt tervezgettem, s végül arra jutottam, hogy az én minimális programozói tudásommal is megoldható a játék elkészítése. Végül persze teljesen más lett, mint amilyennek először elképzeltem, de nekem ez is nagyon tetszett a programozásban, hogy a kezdeti ötletektől távolodva ugyan, de egyre formálódott, alakult a kód és változott a kinézet.

Na igen, a kinézet. Ez volt az első, amivel ténylegesen foglalkozni kezdtem. Ehhez Krissz remek PETSCII Editorát használtam, melynek megalkotásáért nagyon hálás vagyok neki. A szerző szavait idézve, ez egy „Teljes körű szöveges üzemmódú látványtervező program Commodore 64-es projektekhez. Az egyszínű, a bővített háttérszínes, és a multicolor módokat egyaránt támogatja. Karakterkészlet-szerkesztővel, sprite-szerkesztővel, különféle színsémákkal, CRT filterekkel és számos import/export funkcióval felvértezett szerkesztőprogram.” Itt olvashattok többet róla: blog.krissz.hu
Szóval ezzel a szerkesztővel tököltem nagyon sokat, amíg nagyjából azt a képernyőképet kaptam, amit elgondoltam és ami már nagyban hasonlított ahhoz, amit a játék végül tartalmaz.
Ezután szükség volt egy programra a kódoláshoz. Persze lehetett volna egy mezei szövegszerkesztőt is használni, de én valami direkt a retro fejlesztésre létrehozott célszoftvert akartam, beépített speciális funkciókkal. Egy ilyen IDE volt annak idején a Relaunch64, amit az IEC-ATA DOS készítésekor használtam. Ez azonban nagyon régen, ezelőtt 19 évvel volt és mint kiderült, a szoftvert 2016 óta nem fejlesztik. Szóval mást kellett helyette találnom.
Erre a célra jelenleg két ismertebb program elérhető: a CBM .prg Studio és a C64Studio
Ízlés kérdése, hogy kinek melyik a szimpatikus. Nekem az elsőre esett a választásom, bár volt olyan feladat (debug), amihez az utóbbit használtam.

Elgondolkodtam rajta korábban és tettem is néhány próbát a TRSE-vel, vagyis a Turbo Rascal Syntax Error nevű fejlesztőkörnyezettel is. Ígéretes és tulajdonképp nagyon jó kis keretrendszer ez is, de sajnos nagyon idegen volt számomra, így nem bírtam megbarátkozni a rendszer Pascal-szerű saját programnyelvével.
Maradt hát a CBM .prg Studio a fő fejlesztőkörnyezet, azzal a kis módosítással, hogy a beépített helyett a Kick Assemblerrel használtam.

Először próbáltam az egyszerűbb megoldás felé fordulni és BASIC-ben elkészíteni a programot. Gondoltam úgy gyorsabban haladnék (ez biztosan így is lett volna) és a végén majd Simon’s Compilerrel lefordítom, hogy a sebességgel ne legyen gond. Szerencsére túl sok időt nem öltem bele, csupán a kezdőképernyő kirajzolását próbáltam ki ilyen módon, de az annyira lassú volt, hogy nincs az a fordító, ami értelmezhető sebességgel futó pszeudo kódot készített volna belőle. Szóval ezután egyértelmű volt, hogy assemblyben kell megírni a játékot.

Először kezdőképernyő és a tábla kirajzolása, majd a játék lényegi részeinek (kurzormozgatás, csempefelfordítás, stb.) programozása jött. Sajnos ahogy haladtam előre, úgy lett a kód egyre bonyolultabb (a vége egyébként egy tipikus spagetti kód lett) és jöttek elő olyan nehézségek, amikre először nem is gondoltam. Nagyon régen írtam bármit is assembly nyelven, ezért nem csak a „hogyan oldjam meg” volt sokszor a probléma, hanem a „miként” is, azaz az ötleteimet mindig le kellett egyszerűsíteni annyira, hogy megoldhatók legyenek a programnyelv korlátaival. Persze egy másodpercig nem tagadom, hogy mindezek a nehézségek az én felszínes ismereteimből adódtak. Szerencsére itt volt nekem a C64.Rulez.Org FTP szervere, ahol a könyvek szekcióban megtalálható minden magyar nyelvű tudásanyag a hőskorból, amelyekre támaszkodhat az egyszeri játékfejlesztő. (Köszi Lion!)
Viszont akárhogy is nézem, 2025-öt írunk és vétek lenne nem kihasználni a rendelkezésünkre álló lehetőségeket, így amikor elakadtam vagy gyors megoldás, esetleg hibakeresés kellett, akkor bizony igénybevettem a ChatGPT-t is, azon belül is egészen pontosan a C64 Assembly Coder nevű GPT-t, amelyik ugyan nem hibátlan, de sokat segített a fejlesztés során.

Amikor a program már rendben működött karakteres módban, azaz a felfordított csempéken képek helyett betűk és számok szerepeltek, akkor jött a grafikus rész fejlesztése. Vagyis neki kellett állnom spriteokat készíteni. Ugyebár a tábla maximális mérete 8*8, vagyis 64 mező, ami 32 képpárt jelent, így minimum 32 különböző sprite készítésére volt szükség. Azt már a tervezési fázisban eldöntöttem, hogy nem általános képeket szeretnék használni, hanem ismert játékokból származókat. Felmerült az ötlet, hogy vegyesen lesznek innen-onnan és a játék véletlenszerűen válogat majd közülük, de végül inkább amellett maradtam, hogy a játékos dönthesse el, hogy melyik játékból ismerős képek legyenek a csempék rejtett oldalán. Ezzel persze meg is nehezítettem a magam dolgát, ugyanis csak olyan játék jöhetett szóba, amiben van annyi eltérő grafikus elem, ami legalább megközelíti a 32-t. Nem volt egyszerű és emiatt vannak például itt-ott azonos grafikájú, de eltérő színű képek, illetőleg így került be a Giana Sisters-es csempekészletbe amolyan easter eggként Mario és Luigi.

Ezen felül a C64 sprite kezelésének korlátaival is meg kellett küzdenem, ugyanis feleslegesen és nagyon megbonyolította volna a kódot a különböző formátumú spriteok egyidejű képernyőre pakolása, ezért egységesen multicolor felbontású az összes. (Mivel memóriajátékról van szó, melyben a színek elég fontosan a különböző csempék megkülönböztetése szempontjából, ezért a hi-res mód a maga két színével gyorsan kiesett.) A multicolor spriteok több színének viszont az az ára, hogy a felbontásuk fele akkora csupán, azaz a 24*21 helyett csak 12*21 képpontosak, ezzel együtt vízszintesen dupla méretűek a pixelek. További nehezítés, hogy az egy csempekészletbe tartozó összes sprite esetében a háromból két szín, illetve a háttérszín is közös, csupán egy-egy saját, egyedi színe lehet minden kis képnek. Ezen korlátok miatt nem lehetett egyszerűen átemelni a spriteokat a három nagysikerű játékból, hanem egyesével kellett mindet újrarajzolnom, a fenti megkötések figyelembevételével. Nem is néznek ki olyan szépen, mint az eredetikben, de nagyrészt azért felismerhetők.

Egy kis érdekesség: Sok játékban használták és az általam a képekhez forrásként szolgáló klasszikusokban is van rá példa, hogy egy karakter nem egy spriteból áll, hanem több darabból, amelyek együtt mozognak. Pl. a Giana Sistersben a 16. pályán van egy sárkány, ami vízszintesen annyira széles, hogy egyértelműen több – ha jól emlékszem 3 db – spriteból áll. Ennél még eggyel finomabb trükk, amikor a sprite-okat nem egymás mellé, hanem egymásra pakolják a fejlesztők. Ugyanebben a játékban, ha közelről megnézzük Giana figuráját, akkor látható, hogy bár a mérete pont akkora, mint egy szabványos multicolor sprite, de a színek száma meghaladja a megengedettet. Ennek az az oka, hogy ebben az esetben két multicolor és egy hi-res sprite van egymásra rakva. A fix háttérszín mellett van két közös szín a képernyőn levő multicolor spriteok esetében, illetve darabonként még 1+1. Ez már 4 előtér szín és erre jön még a hi-res sprite egyedi előtér színe ötödiknek, illetve a kisebb, egy képernyőpontnyi, vagyis vízszintesen nem duplikált pixeleket is ez utóbbi adja.

Egy sprite grafikus adata 504 bit, azaz 63 byte méretű, ez azonban nem egy kerek szám. A könnyebb kezelhetőség miatt célszerűbb 64 byteos blokkokban tárolni a képadatokat. Így viszont szabadon maradt mindegyiknél 1 byte, ami remekül felhasználható a képenként egy egyedi szín tárolására. Így is tettem és a CBM .prg Studio szerkesztőjével, illetve a már említett PETSCII Editor-ral elkészített sprite adatokba még utólag a HexEd.it használatával szerkesztettem bele az adott kép egyedi színét.

A játék készítése során folyamatosan alakítgattam azt az egyedi karakterkészletet, amit a fejlesztés legelején betettem, a programba. Bár angol nyelvű a szoftver, így ékezetes betűkre nem volt szükségem, ám így is tudtam, hogy nem lesz elég az alap charset. Szóval ahogy létrejöttek az új funkciók, fejlődött a képernyőkép és ehhez mindig szükség volt egy-egy új, egyedi karakterre. Először ezt is a már említett PETSCII Editorral próbálgattam, de aztán gyorsan áttértem a CBM .prg Studio beépített karakterszerkesztőjére. Praktikus, mindig kéznél van, így ez volt az optimális megoldás.

Miután ezzel is megvoltam, már csak a címképernyőt kellett megrajzolnom. Bár rajzolgattam már korábban is, de nem közel sem vagyok grafikus. Ahogy persze programozó sem, inkább csak amolyan mindenbe belekontárkodó Mekk Elek. Szigorúan ennek tükrében szemlélve a végeredményt, az egészen vállalható lett.
A rajzoláshoz a Pixcen, a mcDRAW és az ALBERT nevű programokat használtam. Mindegyik másban volt erős. Utóbbi egyébként egy multi-platform pixel editor program a C64-es képkészítéshez, amivel a keretre is lehet rajzolni, programozói tudás nélkül is és ami remekül fut MacOS-en, így nem kellett – mint a többi korábban említett szoftver esetében – RDP-n keresztül Windows-os gépet használni, hanem rajzolhattam natívan.

A fejlesztés közbeni teszteléséhez mondhatni természetesen a VICE-t, vagyis a the Versatile Commodore Emulator-t használtam, mint szinte mindenki, aki modern környezetben használ C64-et akár játékra, akár fejlesztésre.

Két fontos dolog, amit még terveztem, de sajnos nem tudtam megvalósítani: High Score tábla és hangok. Előbbi talán nem is hiányzik annyira, pedig csak azért maradt ki, mert nem volt már több időm az Árok Party kezdetéig. Agyaltam rajta, hogy miként lehetne osztályozni a játékosok teljesítményét, hisz több olyan változó van a beállítások között, amik befolyásolják a nehézséget. Az idő és a pályaméret egyértelműen, de még a használt csempekészlet is befolyásolhatja a sikerességet, mivel szerintem pl. a Henry’s House készlet egyértelműen könnyebben, míg az Impossible Mission nehezebben megkülönböztethető csempékből áll.
Szóval valamilyen komplex számítást terveztem, ami egy 0-255 között értékre konvertálja ezt a három tényezőt, hozzákeverve még a játékból megmaradt időt is természetesen. Ha ez meglett volna, akkor jött volna a funkció beépítése a programba, illetve annak megoldása, hogy ezt a lemezre is írja, hogy a későbbiek során összevethető legyenek a régebbi eredmények az újakkal. Mint említettem, ez a funkció végül nem került bele a programba, de talán nem is hiányzik annyira, hisz ennél a játéknál nem több órás erőfeszítéseket kell tennie a felhasználónak, aminek a jutalma lenne a legjobb pontszerzők közé kerülés, hanem csupán csak 2-3 perces gyors menetek követik egymást, amúgy kikapcsolódásként.

A hangok hiánya viszont fájó! Már a címképernyő megjelenítésekor jó lett volna, ha felcsendül valamilyen melódia. Kerestem is néhány megfelelőt, illetve felmerült bennem, hogy megkérem valamelyik a scenen a mai napig alkotó C64-es zenészt, hogy segítsen ki egy frappáns dallammal. Végül erre nem került sor, mivel – az idő rövidségével párhuzamosan – kifogott rajtam a dolog.
Már az is, hogy a címképernyő alatt szóljon valami, pedig ott még lehetőség lett volna a továbblépés során visszaállítani a zenéhez szükséges regisztereket, illetve a megszakítási rutint is, de ez sem jött össze.
A játék során pedig szerettem volna, ha a lapok felfordításakor, vagy legalább a párok megtalálásakor és a játék megnyerésekor lenne valamilyen hanghatás, de mivel a visszaszámláló óra időzítése is fontos (értsd: a megszakítások nem hozzáértő buzerálása hibát okoz), ezért nem találtam megoldást arra, hogy ez működjön. Egy idő után pedig feladtam a dolgot. Egyértelműen kevés a tudásom a játékfejlesztés ezen a részéhez.

Végül, bár nem sikerült idén eljutnom az Árok Party-ra, de távnevezésként beadtam a játékfejlesztő versenyre a végül Yet Another Simple Memory névre keresztelt játékomat. Korábban az „n+1 memory” néven gondolkodtam, de mivel az inkább csak nekünk magyaroknak értelmezhető, ezért lett egy hasonló jelentésű, de jóval hosszabb, ám remekül rövidíthető (YASM), külföldiek számára is világos név.
Az erős mezőnyben végül a 7. helyen végzett a játék, ami bár lehetne jobb is, de nekem nem volt csalódás. Sokat dolgoztam vele, de jó érzés volt a fejlesztés, már ezért megérte.

Mivel egy party-n jött ki hivatalosan és nem csak úgy csendben felkerült mondjuk erre az oldalra, ezért lett egy kis híre és utóélete is a játéknak. A CSDB-re én töltöttem fel és nem kellett egy nap, s máris kapott egy cracket meg egy örök idő trainert a Laxity csapattól. A két release, csak a CSDB-n együttesen már több száz letöltést számlál. Később több Youtube videóban viszontláttam és C64-es megjelenésekkel foglalkozó weboldalakon is olvastam az általam készített programról. Ez azért büszkeséggel töltött el és megerősített abban, hogy érdemes lenne megvalósítani a még a fejemben levő további játékötleteket, még ha soha nem is lesz belőlük korszakalkotó stuff ezen az öreg hardveren.