Mi történik, ha 1997-es böngészőkre célozva építesz egy webes játékot? Nincs React, nincs CSS Grid, nincs fetch API, csak nyers PHP, <table> elrendezés és <font> tagek. Üdv a Retro Dynartnál!
A forráskód itt található: https://github.com/DynartInteractive/retro.dynart.net
A kihívás
A szabályok egyszerűek voltak: építs egy teljes értékű tologatós kirakójátékot, ami fut Netscape Navigator 4.04-en és Internet Explorer 3.0-n. Semmi csalás „graceful degradation”-nel: natívan kellett működnie ezekben az ősi böngészőkben, elsődleges célként.
Ez azt jelentette, hogy szinte mindenről le kellett mondani, amit egy mai webfejlesztő magától értetődőnek vesz:
Nincs CSS fájl (minden formázás HTML attribútumokkal, mint a bgcolor és a <font>)
Nincs onclick eseménykezelő a képeken
Nincs document.images és new Image() IE 3-ban
Nincsenek sütik (a session azonosító URL-paraméterben utazik)
Egyáltalán nincs JavaScript a játéklogikához: minden lépés egy teljes oldalújratöltés
Tiszta PHP, nulla JavaScript
Az egész játék a szerveroldalon fut. Rákattintasz egy csempére, a böngésző lekér egy új oldalt ?move=5-tel az URL-ben, a PHP frissíti a rácsot a sessionben, és visszaküld egy friss HTML-oldalt az új táblaállással. Mai szemmel abszurdnak hangzik, de ez az egyetlen megközelítés, ami mindkét célböngészőben megbízhatóan működik.
A rács egy lapos tömb sorfolytonos sorrendben, ahol a 0 jelöli az üres helyet. A játék rendes 15-ös kirakó mechanikát tud: ha az üres hellyel azonos sorban vagy oszlopban lévő csempére kattintasz, az összes köztük lévő csempe elcsúszik, nem csak a szomszédos.
Képszeletelés PHP GD-vel
Minden kirakóképet a PHP GD könyvtára szeletel fel dinamikusan csempékre. A generateSlice() függvény fog egy forrásképet, kivágja belőle az egyes darabokat, és opcionálisan ráteszi a csempe számát elmosott szövegárnyékkal (4 menetes Gauss-elmosás, pixelenként összekomponálva).
Hogy ne kelljen minden oldalbetöltéskor újragenerálni a csempéket, a szeletek egy MD5 hash alapú hierarchikus könyvtárszerkezetben cache-elődnek: cache/{hash[0]}/{hash[1]}/{hash}.jpg. Ez a cache kritikusnak bizonyult: a Netscape 4.04 egyszerűen eldobott képeket, ha túl sokat kellett egyszerre betöltenie, és néha még így is kell egy frissítés...
A pályarendszer
A játéknak 8 pályája van egy csavarral: a páratlan pályák (1, 3, 5, 7) ugyanazt a képet mutatják számozott csempékkel segítségként, a páros pályák (2, 4, 6, 8) pedig pontosan ugyanazt a képet, de számok nélkül. Előbb segédkerekekkel tanulod meg a képet, aztán bizonyítod, hogy tényleg megjegyezted.
A rács mérete 3×3-tól 6×6-ig nő:
| Pálya | Rács | Számok |
|---|---|---|
| 1-2 | 3×3 | Igen/Nem |
| 3-4 | 4×4 | Igen/Nem |
| 5-6 | 5×5 | Igen/Nem |
| 7-8 | 6×6 | Igen/Nem |
A pontozás a lépéshatékonyságot (100-ról indul, lépésenként egyet levonva) kombinálja egy időbónusszal, ha 2 percen belül teljesíted a pályát. Egy tartós toplista követi a legjobb 5-öt, szerializált PHP tömbként egy sima fájlban tárolva.
Tanulságok 1997-ből
Ezekre a böngészőkre fejleszteni néhány kemény leckével járt:
Az onclick az <img>-en nem működik. Sem az IE 3, sem a Netscape 4 nem támogatja. Minden kattintható képet <a href="javascript:...">-be kell csomagolni, vagy – a mi esetünkben – egy sima <a href>-be, ami a PHP végpontra mutat a lépés paraméterével.
A Netscape 4-nek képbetöltési limitje van. Ha nagyjából 15-nél több képet töltesz be egyszerre, néhányat csendben eldob. A megoldás az volt, hogy az összes csempeképet előre legeneráltam statikus, cache-elt fájlként, ahelyett hogy PHP végpontokon keresztül szolgáltam volna ki őket.
Nincs süti, tehát URL-alapú session. Az oldal minden egyes linkje hordoz egy sid paramétert. Egy makeLink() segédfüggvény automatikusan hozzáfűzi, de ha egyszer kifelejted, a játékos elveszíti a játékállását.
A táblázat a te CSS Grided. Az egész elrendezés egy 620px fix szélességű táblázat 164px-es oldalsávval és 456px-es tartalomterülettel. Maga a kirakórács egy beágyazott táblázat, az 1px-es fehér kereteket a kitöltő cellák bgcolor-ja adja. A megfelelő térközökhöz mindkét böngészőben szülő táblázatokba kellett csomagolni a táblázatokat: ez minden szempontból rossznak érződött, de tökéletesen működött.
A stack
Az egész projekt vanilla PHP, nulla függőséggel:
- Nincs framework, nincs Composer, nincs build lépés
- XAMPP Apache-csal és PHP GD-vel
- ISO-8859-1 kódolás (nem UTF-8, korhűen)
- Output buffering sablonrendszerként (
ob_start/ob_get_clean) - Fájlalapú tárolás mindenhez (számláló, toplista, képcache)
A tesztelés két lépcsőben történik: gyors ellenőrzés egy modern böngészőben localhoston, aztán az igazi teszt valódi Netscape 4.04-en és IE 3.0-n DOSBox-X-ben.
Megérte?
Abszolút. Van valami kielégítő abban, ha szélsőséges korlátok között építesz. Amikor minden <td> számít és minden képbetöltés fontos, mélyen megtanulod értékelni, hogy mit is csinálnak valójában a böngészők, és hogy mennyit fejlődött a web közel 30 év alatt.
A játék teljesen játszható, a toplista megmarad, és olyan böngészőkben fut, amelyek régebbiek a Google-nél. Néha a modern web megértésének legjobb módja az, ha építesz valamit nélküle.