A Nintendo Entertainment Systemet és japán megfelelőjét, a Famicomot nem kell bemutatni – ha ezt a magazint olvasod, akkor tudod, hogy a 8 bites hardver a Nintendót globális vezető pozícióba repítette a videojáték-iparban, és számtalan klasszikus sorozat első változatának adott otthont.
Bár a marketing fontos szerepet játszott ebben a kereskedelmi és kulturális sikerben, a hardver nélkül mindez nem lett volna lehetséges. Elvégre a ColecoVision és az Atari 5200 még egy éves sem volt, amikor a Famicom 1983-ban megjelent Japánban, a 3DO és az Atari Jaguar pedig már a piacon volt, amikor a fejlesztők 1994-ben végleg lemondtak a NES-ről. Egy gép egyszerűen nem maradhat ilyen sokáig releváns olyan hardver nélkül, amely elég rugalmas és képes ahhoz, hogy lépést tartson a játékosok változó ízlésével.
Új alapokra helyezve
(Kép hitel: Evan Amos)Iratkozzon fel ma
(Kép hitel: Future)
Ez a cikk először a Retro Gamer magazinban jelent meg. Ha még több, a klasszikus játékokat és konzolokat feltáró, mélyreható cikket szeretne kapni, egyenesen az Ön ajtajára vagy készülékére, iratkozzon fel a Retro Gamer nyomtatott vagy digitális változatára.
A NES azonban nem csak a maga korának titánja volt – rengeteg fejlesztő készít új játékokat a hardverre, és a modern fejlesztői eszközökkel minden korábbinál keményebben nyomulnak rajta. Két CPU és származékai uralták a nyolcvanas évek otthoni hardveres színterét – a Zilog Z80, amely a ZX Spectrumban, a ColecoVisionben és a Master Systemben volt látható, valamint a MOS Technology 6502, amely az Atari 5200-ban, az Apple II-ben és a Commodore 64-ben szerepelt. A Nintendo mérnöke, Masayuki Uemura a 6502-es chipet választotta a NES számára, elsősorban azért, mert elég kicsi volt ahhoz, hogy egy chip hangképességeket is tartalmazzon.
A néhai mérnök 2016-ban a Retro Gamer-nek elmondta, hogy ez a választás „hatalmas problémát okozott a cégen belül”, mivel a Nintendo sláger árkád játéka, a Donkey Kong egy Z80-ast használt, és a forráskódot nem lehetett újra felhasználni. A Nintendón kívüli programozók figyelembevétele nem volt prioritás, mivel a vállalat eredetileg nem tervezte, hogy harmadik féltől származó kiadók is részei legyenek az üzleti modelljének. Természetesen a hardver sikere Japánban és Észak-Amerikában végül szükségessé tette a harmadik féltől származó fejlesztéseket, hogy lépést tudjanak tartani az új játékok iránti kereslettel.
Az Egyesült Királyságban a rendszer nem volt ugyanilyen hatással, ezért Paul Machacek programozó 1988-ig nem is találkozott vele, amikor is csatlakozott a Rare-hez – azon kevés brit fejlesztők egyikeként, akik a Nintendo rendszerére koncentráltak. Korábban kiadott játékai Z80-alapú számítógépekre íródtak, és kezdetben a Z80-alapú RAZZ árkád tábla számára való írással bízták meg, de hamarosan felkérték, hogy dolgozzon egy NES-projekten. Szerencsére Paul jól ismerte a 6502-es assembly kódot az Oric-1 tulajdonosaként eltöltött időből. „Elég gyorsan elsajátítottam újra” – mondja – „de elfelejtettem a Z80-hoz képest a rajta végzett számzsonglőrködést, mivel a 6502-nek olyan kevés regisztere van, de váltakozva a gyors nulladik oldalas tárolóval.”
Fejleszd ki, amit mi csináltunk azokkal az eszközökkel, amelyekkel a használt rendszereinken rendelkeztünk, és mondd, hogy a végén nem csinálnál valami hasonlót.
Paul Machacek
A fejlesztőkörnyezet, amellyel Paul dolgozott, meglehetősen egyszerű volt. „Eredetileg a Rare-nél mindenki a PDS-t (Programmers Development System) használta, ami egy szövegszerkesztő és kód-asszembler volt. Saját készítésű interfészkártyáink voltak, amelyeket a NES kazettafoglalatába illesztettünk, és egy szalagkábellel csatlakoztak a PC-inkhez, amelyeken a PDS futott” – magyarázza. „Nem volt hálózatunk. A PC-k Amstradsok voltak 20 MB-os (nem elírás) merevlemezekkel. Minden alkalommal, amikor összeraktad a kódodat – ez mind egy menetben történt, még nem volt linkerünk -, a teljes bináris állomány átmásolódott a szalagkábelen az interfészkártyára, és a célgépen futtattad a kódodat. Ami a dokumentációt illeti, csak a szabványos NES kézikönyvünk volt, amelyben volt néhány elírás, amit ki kellett javítani, különben nem működtek volna a dolgok, valamint a praktikus 6502-es utasításkészlet kézikönyv, amire időnként hivatkozhattál, különösen, ha önmódosító kódot akartál írni.”
Ha programozóként összerezzensz, a dolog még rosszabb lesz. „Nem voltak olyan hibakereső eszközök, amilyeneket ma ismernénk” – folytatja Paul. „Voltak trükkök, amelyekkel kideríthetted, hogy hova jutott a kódod, mielőtt a dolgok elromlottak, például értékeket írhattál egy memóriahelyre, és megnézhetted, hogy melyiket írtad ki utoljára, mielőtt lezuhant, majd egy felező kereséssel leszűkíthetted a hibás kódot. A teljesítményteszteléshez általában volt valami vizuális változás a képernyőn (a képernyő vízszintes görgetési regiszterének eltolása, vagy egy színpaletta módosítása) egy funkció elején, majd a végén visszaállítottad, hogy „mérni” tudd, mennyi ideig tartott a képernyőn, úgy, hogy jelölőtollal jeleket rajzoltál e látható jelző köré, és figyelted, hogy a jelek közelebb kerülnek-e egymáshoz, ahogy tovább optimalizáltad a kódod. Igen emberek, ezekben az időkben a kód teljesítményét hüvelykben mérték!”.
Ez elég kínos munkamódszernek hangzik, de Paul szerint ez csak az akkori körülmények terméke. „Azt tettük, amit akkoriban tennünk kellett. Emberek, menjetek vissza 35 évet, fejlesszétek azt, amit mi tettünk azokkal az eszközökkel, amik a rendelkezésünkre álltak az általunk használt rendszereken, és mondjátok nekem, hogy ti nem valami hasonlót csináltok!” Szerencsére ez a helyzet végül javulni fog Paul és kollégái számára. „Néhány év múlva a Rare szerződést kötött Jon Ritmannal, egy közeli munkatársával, hogy írjon egy új rendszert, a GLAM [Global Language Assembler Monitor] nevű rendszert a PDS helyettesítésére. A GLAM a processzorok szélesebb körét tudta megcélozni, és volt linkerje, valamint asszemblere is, így nem kellett minden egyes alkalommal, amikor valamit megváltoztattunk, a teljes kódbázist összerakni, ami felgyorsította a fejlesztést. A GLAM nagyon jól működött.”
(Képhitel: Nintendo)
Végső soron a 6502-es programozás nem jelentett nagy problémát Paul számára az új platformra való átállás során. „Számomra a nagyobb átállást az jelentette, hogy a bit-térképes képernyővel rendelkező otthoni számítógépekről áttértem a NES karaktertérképes rendszerére, a külön színpaletta-megjelölésekkel, karakterbankokkal (és cserével), valamint a memóriabankok cseréjével a kocsikon” – emlékszik vissza. A Nintendo Picture Processing Unit – röviden PPU – a Ricoh egyedi tervezése volt, és Nicolas BÉtoux, a Morphcat Games munkatársa szerint „az akkori más hardverekhez képest a grafika és a görgetési képességek nagyszerűek voltak”.
Valóban, amikor a Famicom 1983-ban megjelent, a legközelebbi versenytársa Japánban a Sega SG-1000 volt. A Famicom grafikai képességei egyértelműen jobbak voltak – a paletta több mint 50 színből állt, szemben a Sega rendszerének mindössze 16 színével, a sprite-ok három színnel rendelkeztek, szemben az egy színnel, és a képernyőt nem karakterenként, hanem pixelenként lehetett görgetni, ami lényegesen simább megjelenést eredményezett. A Nintendo hardvere összességében több sprite-ot, és több sprite-ot tudott megjeleníteni scanline-onként. A Sega 1985-ben mutatta be a grafikailag jobb Mark III hardvert, ami azt jelentette, hogy a verseny kiegyenlítettebb alapokon zajlott, mire a NES és a Master System a nemzetközi közönség elé került.
A szakma eszközei
Bár a Nintendo 8 bites hardvere fejlett grafikai képességekkel rendelkezett, a grafikák létrehozásához használt módszerek minden voltak, csak nem fejlettek. Paulhoz hasonlóan Kevin Bayliss művész sem találkozott még soha NES-szel, mielőtt játékokat készített volna a rendszerhez. „A Rare-nél töltött első napomon Tim [Stamper] megmutatta nekem az alapvető „pixelezési folyamatot”, és megtanította, hogyan kell olyan munkát létrehozni, amelyet ténylegesen be lehet tenni egy játékba” – meséli.
„Alapvetően meg kellett rajzolnom a művemet, és egy rácslap alá kellett helyeznem egy nagy rajzlapon, amely tele volt fluoreszkáló csíkokkal. Ezután átrajzoltam a rajzomat úgy, hogy a rács segítségével ceruzával pixeleket határoztam meg, majd filctollal kitöltöttem a pixeleket. Ezután a művet rendszerezni és dobozokra (8×8 sprite-okra) osztani kellett, és a sprite-adatokat és a pozícióadatokat mind hexadecimálisan, fejben kellett kidolgozni. Ez elég egyszerű, de időnként kissé fáradságos volt, és gyakran nem akartad ezt a munkát elvégezni, mert egyáltalán nem volt kreatív. Csak látni akartad a munkádat a játékban.”
Ha zavarba ejt, hogy ebben a folyamatban nem volt számítógép, akkor nem értesz félre semmit. „Nem voltak más eszközök, mint a toll, ceruza, papír és egy sebészi szike, amivel ki lehetett firkálni a hibákat a pauszpapírra, ha rossz helyre tettél egy pixelt, vagy ha le akartál vágni pixeleket egy karakterből, hogy kevesebb adatba préselődjön” – tisztázza Kevin. „Volt egy egyszerű sprite-szerkesztő, amit Mark Betteridge írt, de ezt nem igazán használták, mert nagyon korlátozott volt, és nem tette lehetővé, hogy megnézd az animációdat (ahogy a régi Disney ‘színfalak mögötti’ felvételeken teszik – a papírt előre-hátra lapozgatva, hogy az animáció illúzióját keltsd)”.”
Nem voltak más eszközök, mint a toll, ceruza, papír és sebészi szike a hibák kifirkálásához.
Kevin Bayliss
Mivel a NES fejlesztői eszközei nem voltak szabványosítva, a különböző cégek különböző művészeti eszközöket használtak. A Nintendo egy időben kézzel rajzolt sprite-okat használt, de végül létrehozott egy egérrel vezérelt pixel-art eszközt, míg a Namco egy sprite-szerkesztő eszközzel rendelkezett, amely rendelkezett a Kevin által leírt animációs előnézeti lehetőséggel. Mindazonáltal tetszett neki a Rare-nél alkalmazott alacsony technikai megközelítés.
„Tulajdonképpen nagyon jó volt, hogy korlátozott palettával rendelkeztünk. Úgy értem, kizárt, hogy bármelyik 16 bites konzolhoz az összes grafikát papírra rajzolhattad volna, mert sosem lett volna elég tollad, és egy egész napba telt volna a dekódolás – és annyi hibát vétettél volna -, hogy lehetetlen lett volna” – mondja. „De a színpaletta egyszerűsége, az alacsony felbontás és a sprite-ok kis száma miatt, amelyekkel többnyire foglalkoztunk, a grafika papírra készítése valójában nagyon szórakoztató volt, és sokkal „organikusabbnak” éreztem, mint a digitális készítést a SNES-en, szóval azt hiszem, van mit mondani erről.”
Bárhogyan is alkotta meg egy fejlesztő a művészetet az NES-re, a technikai korlátok szerepet játszottak a végeredményben. „A soronkénti sprite-ok (64-nél több kitöltött pixel egy vízszintes scanline-ban) problémát jelentettek, ezért igyekeztél nem túl széles karaktereket készíteni” – magyarázza Kevin. „Például emlékszem, hogy a WWF-játékok összes karakterének, amit készítettem, vagy ‘hátra kellett esnie’, vagy ‘a földön feküdnie’ kellett, és ez természetesen azt jelentette, hogy ebben a pózban elég szélesek voltak. Így gyakran megpróbáltad őket szögbe állítani, vagy ügyesen alakítani a pózt, de sosem tudtad igazán elkerülni. Láthatod, hogy a karakterek gyakran villogtak fel és le, különösen az ilyen beat-’em-up játékokban, és ez egy olyan probléma volt, amellyel minden cégnek a lehető legjobban kellett megbirkóznia.”
Ez a jellegzetes villogás valójában egy ügyes programozási megoldás – a NES egyszerűen kihagyta a pixeleket, ha túl sok sprite jelent meg, így a sprite-ok gyors ki-be kapcsolása legalább biztosította, hogy valamilyen formában mind megjelenjen.
(Képhitel: Nintendo)
A NES-fejlesztőknek gyakran kellett kreatívnak lenniük, hogy megvalósíthassák elképzeléseiket – ilyenek voltak például a hatalmas főnökfigurák, amelyeket Kevin rajzolt a Cobra Triangle-hez. „A Cobra Triangle esetében szerencsénk volt, mert a játék izometrikus környezetben játszódott, így az összes grafikát szögből néztük, ami csökkentette a szélességet, amit egy vízszintesen görgethető játékban általában látni szoktunk” – mondja.
„A főnöki karakterek mind nagy sprite-ok gyűjteménye volt, és a víz felszínét használhattuk arra, hogy a dolgokat víz alá merültnek tüntessük fel azzal, hogy néhány ‘hullámzó’ sprite-ot adtunk köréjük az alapjukon. Így például az általam készített tengeri szörny (Nessie) karaktere elég magas volt, és a mögötte lévő buckák egymástól függetlenül mozogtak, és a szög miatt nem volt túl sok sprite-ok villódzása.”
A korlátozásokkal még nehezebb volt megbirkózni, amikor licencelt játékokat fejlesztett, ahogyan azt a Rare gyakran tette. „A WWF birkózójátékoknál meg kellett bizonyosodnunk arról, hogy a karakterekkel jó a hasonlóság. Így nehéz volt kézzel „digitalizálni” a fényképeket, és mindenki jellemzőit pontosan reprodukálni, amikor csak körülbelül 16×16 pixel állt rendelkezésre egy karakter fejképéhez a kiválasztott oldalon” – mondja Kevin. „Emlékszem, hogy kaptam ezeket a borzalmas minőségű faxokat, amelyeken a pankrátorok képei voltak, és nekem kellett volna megpróbálnom újraalkotni őket ilyen alacsony felbontás és három szín felhasználásával.”
Ez azonban néhány vicces élményhez vezetett. „Sokszor kaptam vissza faxokat Amerikából, amelyekben azt írták, hogy ‘A grafikára ráférne egy kis odafigyelés’, mert a hasonlóság nem volt elég közel” – folytatja Kevin. „Aztán megváltoztattam, mondjuk egy pixelt, és másnap kaptam vissza egy faxot, hogy a kép sokkal jobb lett. Igazán megnevettetett, amikor ez történt. Amikor a Beetlejuice játékon dolgoztam, akkor is az ellenkező problémám volt, és a címlap grafikája túlságosan hasonlított Michael Keatonra, úgyhogy újra kellett csinálnom, hogy jobban hasonlítson Beetlejuice-ra – elég nehéz, amikor ugyanaz a személy.”.
Árnyalatok a következők között
Néha sikerült a rendszert az elméleti határain túlfeszíteni. „Ha megnézed a Super Off Roadot, észreveheted, hogy időnként több szín van a képernyőn, mint amennyit a hardver alapból kezelni tud” – mondja Paul. „Négy paletta volt egyenként négy színből, de minden paletta első színe ugyanaz a háttérszín volt mindegyiknél. Így a háttérkaraktereknél megjeleníthető színek száma összesen 13. A Super Off Roadon azért jelenik meg több, mert a VRAM-hoz való gondosan időzített hozzáféréssel változtattam a palettákat a vízszintes ürítés során. Ez jól működött” – magyarázza Paul, mielőtt kijavítja magát. „Nos, a NES amerikai változatán működött.
Amikor a játék elkészült, úgy értesültem, hogy Japánban a Famicomra fogják kiadni, ami hardver szempontjából kissé más volt, és sajnos a színváltásom nem működött rajta, így azt hiszem, ott nem adták ki.” A hangot ugyanaz a Ricoh 2A03 chip kezelte, amely a CPU-t is tartalmazta. „A NES-en négy hangcsatornával dolgozhattál. A DPCM (sample) csatornát nem számoljuk, nem használjuk, mivel van néhány hátránya” – mondja Nicolas, a modern NES-játékok fejlesztője.
„Akárhogy is, ez két négyszöghullám-generátor, egy háromszöghullám, amelyet gyakran használnak basszusvonalakhoz, és egy zajcsatorna, amelyet az ütős hangokhoz használnak. Látod tehát, korlátozottak a lehetőségek a polifónia és a hangszín tekintetében, ami megnehezíti egy hangulatosabb hangsáv létrehozását, mint amilyeneket a modern játékokban hallhatsz. Valószínűleg ez az egyik oka annak, hogy annak idején sok játékzene dinamikus kompozíciókkal és fülbemászó dallamokkal kárpótolta a játékokat.”.
(Képhitel: Nintendo)
A NES-hangzásnak van néhány különösen jellegzetes tulajdonsága, nem utolsósorban a háromszöghullámok, amelyek a rendszer 4 bites hangfeldolgozásának köszönhetően inkább lépcsőzetesek, mint egyenletesek. „A korlátozott számú csatorna miatt azzal is tisztában kell lenni, hogy a hangeffektek megszakíthatják a zenét” – teszi hozzá Nicolas. „Ideális esetben a hangeffekteket csak azokon a csatornákon játszatja le, amelyeket a kísérethez használ, így nem némítják el a dallamot.”
A hangzás szintén az egyik megkülönböztető pont a Famicom és a NES között, mivel a Famicom támogatja a bővített hangot a kazettaporton keresztül – ezt a Famicom Disk System és bizonyos speciális kazettachipek ki is használják. Mivel a NES nem rendelkezik ezzel a képességgel, az olyan játékok japán változatai, mint a The Legend Of Zelda és a Castlevania III: Dracula’s Curse érezhetően jobb zenével rendelkeznek, mint nemzetközi társaik. Valójában a speciális chipek voltak az egyik legfontosabb tényezői a NES hosszú élettartamának. Amellett, hogy a NES mind a ROM-ot, mind a RAM-ot támogatta a kazetták nyomtatott áramkörein, a Nintendo által Memory Management Controllernek nevezett chipeket is használhatott.
Ezek a chipek lehetővé tették a bankváltást, amely túllépett az eredeti kazettaspecifikáció tárolási korlátain, és extra funkciókat biztosítottak a játékfejlesztés, illetve a Famicom esetében még a bővítő hang is. Végül is így volt képes a rendszer egy évtized alatt olyan játékoktól, mint a Donkey Kong, olyan sokkal összetettebb címekig eljutni, mint a Kirby’s Adventure. Persze még az eredeti 40 KB-os ROM-kapacitást jóval meghaladó ROM-kapacitás mellett is gyakran küzdöttek a fejlesztők minden egyes byte-ért. „Akkoriban gyakori probléma volt, hogy megpróbáltuk a játékokat a nekünk adott apró kazettákra zsúfolni” – mondja Paul. „A NES/Game Boy (mindkettő 8 bites rendszer 64 KB-os memóriatérképekkel) esetében ezt bonyolította a bankváltás, ahol a régiót négy 16 KB-os blokkra lehetett felosztani, és különböző ROM-bankokat lehetett váltogatni.
Tehát gondosan meg kellett szervezni, hogy melyik kód és adat hol van, és hogyan ugorjunk egyik ROM-bankból a másikba ugyanazon a címtartományon belül, a szabványos átugró táblázatok segítségével a tartomány elején. Adattömörítési rutinokat is ki kellett fejlesztenünk, gyakran különbözőket a különböző típusú adatokhoz – karakteradatok, térképadatok, szövegadatok, zenei adatok. A Huffman-tömörítést elég sokat használtuk, de sok időt töltöttem azzal, hogy más típusú adatok kinyomtatásait bámultam, és olyan mintákat kerestem, amelyekhez tömörítő szoftvert tudtam fejleszteni.”
8-bitten
James hasonlóan elismerően nyilatkozik a szoftverről: „A közösség nagyszerű, és a tracker alkalmazások használatához szükséges erőforrások bárki számára elérhetőek, akár tapasztalt zeneszerző vagy, akár csak egy chiptunes rajongó”. Ezekkel a modern eszközökkel a rendelkezésükre álló NES-fejlesztők manapság hajlamosak nagyon ambiciózus projekteket kipróbálni. A négyjátékos akciójátékok ritkaságnak számítanak NES-en, de a Morphcat Games egy kiválót alkotott a Micro Mages-ben. Ehhez a hardver igen takarékos felhasználására volt szükség.
„A NES lehetővé teszi, hogy egyszerre maximum 64 hardveres sprite legyen a képernyőn” – kezdi Nicolas. „Ezek a sprite-ok 8×8 pixel méretűek (van 8×16-os mód is, de annak megvannak a maga hátrányai), és nagyobb sprite-ok kialakítására összeilleszthetők.” Tehát ahhoz, hogy az első módban egy 16×16-os sprite-ot kapj, négy hardveres sprite-ot kell használnod. Ha mind a négy játékos 16×16-os sprite-okat használ, az a játékosokon használt összes rendelkezésre álló hardveres sprite egynegyedét jelenti! Emellett van egy hardveres korlátozás, amely szerint ha nyolcnál több sprite van egy vízszintes sorban, akkor azok elkezdenek eltűnni” – folytatja. „Hogy ezt orvosoljuk, és mégis sok más objektum és grafikai effektus jelenjen meg a képernyőn, a Micro Mages játékos karakterei egyenként egyetlen 8×8-as sprite-ot használnak.”
Nicolas szerint a 8 bites CPU szintén korlátozó tényezőnek bizonyul. „Ha egy játékban van egy olyan ellenség, amely csak oldalra mozog és megfordul, amikor falba ütközik, akkor ez korlátozott számú ellenőrzést jelent, amelyet el kell végezni. Az emberi játékosok ezzel szemben jokerek, ők minden körülöttük lévő dologgal olyan módon lépnek interakcióba, amit a fejlesztő nem tud teljesen előre jelezni.
(Kép hitel: Nintendo)
Imádtam kódolni a NES-t, teljesen más architektúra volt, mint az otthoni számítógépek, amelyeken korábban dolgoztam.
Paul Machacek
Emellett, ha a játékosok lövöldözni is tudnak, a képernyőn lévő tárgyak száma gyorsan összeadódik – meséli -, ez egy egyszemélyes játékban nem olyan nagy probléma, és egy kétjátékos játékban általában megúszhatóak a dolgok. Egy négyjátékos játékban azonban? Aú! A Micro Mages-ben sok időt töltöttünk az optimalizálással, hogy elkerüljük a lagot. Négyjátékos módban azonban előfordul, hogy a játék még mindig lelassul, ha túl sok minden történik.”
A modern fejlesztők egyik előnye, hogy a memóriakezelő megoldások – manapság inkább mappernek nevezik őket – széles skálájából választhatnak. „Egyszerűen annyira érdekes ezeket kipakolni, és fejleszteni rájuk” – mondja James. Annak ellenére, hogy a legerősebbek állnak rendelkezésre, nem mindig ezek az alapértelmezett választás. „Amikor a Mega Catnél egy játék fejlesztését tervezzük, visszafelé kezdünk el dolgozni abból kiindulva, hogy mi szükséges ahhoz, hogy az alapvető játékmenet szórakoztató legyen” – magyarázza James. „Néhány esetben végül alapértelmezésként valami olyan erőset választunk, mint az MMC3 mapper. Más esetekben egyszerűbbek maradunk, és egy diszkrét mapper-t használunk, például egy NROM-ot.” A japán Karu_gamo fejlesztő nemrég megjelent NES-játéka, a Blazing Rangers kifejezetten a legegyszerűbb mapperrel, az NROM-mal készült, hogy nosztalgiát ébresszen a Famicom korai időszakában. Valójában ez a lényege annak, hogy a fejlesztők folyamatosan vonzódnak az NES-hez – nem csak technikailag érdekes rendszer, hanem olyan is, amely erős nosztalgikus vonzerővel bír.
Még azok is érzik ezt a nosztalgiát, akik először munkájuk során találkoztak vele, mint például Kevin. „Élveztem művészként a NES-en dolgozni, mert végül tényleg ismerted a rendszert. Akár háttereket, animált sprite-okat, címlapokat vagy front-end (eredménytábla) grafikákat készítettél – volt egy rendszer, amit egy korábbi játékban használtál, és időnként kitaláltál valami újat, hogy egy kicsit továbblendítsd és vizuálisan még többet facsarj ki belőle. Egyszerű idők, de szórakoztatóak!”.
Bár Paul sajnálja a 6502-re való programozással járó számzsonglőrködést, mégis szeretettel emlékszik vissza a rendszerre. „Imádtam a NES kódolását, teljesen más architektúra volt, mint az otthoni számítógépek, amelyeken korábban dolgoztam, érdekes trükkökkel lehetett játszani a karaktertérképes képernyővel, amelyeket ki lehetett használni a mélység megteremtésére – nézd meg a Battletoads játékainkat NES/Game Boy-on -, és mindezt érdekes technikai kihívásnak tekintettem, hogy új problémákat „oldjunk meg” ezen az alternatív hardverarchitektúrán.”
A múlt jövője
De a rendszer programozásának minden szórakozása mellett Paul joggal mutat rá ennek a munkának az eredményeire, mint a NES sikerének okára. „Nem szabad elfelejteni, hogy a Nintendo hihetetlen játékkatalógussal rendelkezett a rendszereken, nevezetesen a Super Mario és a Zelda. A Super Mario Bros 3 hatalmas előrelépés volt, és abszolút csúcsot jelentett abban az időben” – mondja.
Ha retrojátékok készítésére vágysz, a NES lehet, hogy ideális platform számodra. „A NES-kódot, a grafikát és a hangot könnyen kezelheti egy-egy ember a csapatban” – mondja Nicolas. „A mostaniakhoz képest a programozási nyelvet homályosabbnak és bonyolultabbnak érzem, mint a modern nyelveket. A korlátozások miatt mindenre több időt kell szánni” – ismeri el. „De arra is kényszerít, hogy minden egyes ötletet kétszer is átgondolj. Végül a játékmenet szempontjából legfontosabbakra tudsz koncentrálni.
Ezek a korlátozások kordában tarthatják a játékod terjedelmét – csak ennyi mindenre van lehetőséged.” Ha úgy érzed, hogy vonz a gondolat, hogy nekivágj ennek a technikai kihívásnak, mutasd meg nekünk egyszer az eredményt – mindig szívesen látjuk.
Ez a cikk eredetileg a Retro Gamer magazinban jelent meg. További fantasztikus funkciókért és interjúkért itt iratkozhatsz fel a Retro Gamerre nyomtatott vagy digitális formában.