NES:n kehittäjät keskustelevat sukupolvea määrittäneiden klassisten retropelien luomisprosessista

Nintendo Entertainment System ja sen japanilainen vastine Famicom eivät esittelyjä kaipaa – jos luet tätä lehteä, tiedät, että 8-bittinen laitteisto nostatti Nintendon maailmanlaajuiseen johtoasemaan videopelibisneksessä, ja se sisälsi lukemattomien klassikkosarjojen ensimmäiset versiot.

Vaikka markkinoinnilla oli tärkeä rooli tässä kaupallisessa ja kulttuurisessa menestyksessä, se ei olisi ollut mahdollista ilman laitteistoa. Loppujen lopuksi ColecoVision ja Atari 5200 olivat alle vuoden vanhoja, kun Famicom julkaistiin Japanissa vuonna 1983, ja 3DO ja Atari Jaguar olivat jo markkinoilla, kun kehittäjät lopulta hylkäsivät NES:n vuonna 1994. Kone ei yksinkertaisesti voi pysyä merkityksellisenä niin kauan ilman laitteistoa, joka on tarpeeksi joustava ja kykenevä pysymään pelaajien muuttuvan maun mukana.

Uutta maaperää

nes

(Kuvan luotto: Evan Amos)Tilaa tänään

Retro Gamer

(Kuvan luotto: Future)

Tämä artikkeli ilmestyi ensimmäisen kerran Retro Gamer -lehdessä. Tilaamalla Retro Gamer -lehden painettuna tai digitaalisena, saat syvällisempiä artikkeleita klassisista peleistä ja konsoleista suoraan kotiovellesi tai laitteellesi.

NES ei kuitenkaan ollut vain aikansa titaani – monet kehittäjät luovat laitteistolle uusia pelejä ja käyttävät sitä nykyaikaisilla kehitystyökaluilla kovemmin kuin koskaan. Kaksi prosessoria ja niiden johdannaiset hallitsivat 80-luvun kotikäyttöön tarkoitettuja laitteita: Zilog Z80, joka oli mukana ZX Spectrumissa, ColecoVisionissa ja Master Systemissä, ja MOS Technology 6502, joka oli mukana Atari 5200:ssa, Apple II:ssa ja Commodore 64:ssä. Nintendon insinööri Masayuki Uemura valitsi 6502:n NES:n käyttöön lähinnä siksi, että se oli niin pieni, että siru saattoi sisältää myös ääniominaisuudet.

Vuonna 2016 edesmennyt insinööri kertoi Retro Gamerille, että tämä valinta aiheutti ”valtavan ongelman yhtiössä”, sillä Nintendon hitti arcade-peli Donkey Kongissa oli käytetty Z80:tä, eikä sen lähdekoodia voitu käyttää uudelleen. Nintendon ulkopuolisten ohjelmoijien huomioiminen ei ollut ensisijaista, sillä yhtiö ei alun perin aikonut, että kolmannen osapuolen julkaisijat olisivat osa sen liiketoimintamallia. Laitteiston menestys Japanissa ja Pohjois-Amerikassa toki vaati lopulta kolmannen osapuolen kehitystyötä, jotta uusien pelien kysyntä pysyisi yllä.

Järjestelmällä ei ollut samanlaista vaikutusta Yhdistyneessä kuningaskunnassa, minkä vuoksi ohjelmoija Paul Machacek kohtasi sen vasta vuonna 1988, jolloin hän liittyi Rareen – yhteen harvoista brittiläisistä kehittäjistä, jotka keskittyivät Nintendon järjestelmään. Hänen aiemmin julkaisemansa pelit oli kirjoitettu Z80-pohjaisille tietokoneille, ja aluksi hänen tehtäväkseen annettiin kirjoittaa pelejä Z80-pohjaiselle RAZZ arcade -levylle, mutta pian häntä pyydettiin työskentelemään NES-projektin parissa. Onneksi Paul tunsi 6502-kokoonpanokoodin ajoiltaan Oric-1:n omistajana. ”Opin sen taas melko nopeasti”, hän sanoo, ”mutta unohdin kaiken sen numeroiden jongleerauksen, jota siinä tehtiin Z80:een verrattuna, koska 6502:ssa on niin vähän rekistereitä, mutta siinä oli vaihtoehtoisesti nopea nollasivuinen tallennus.”

Kehitä, mitä me teimme niillä työkaluilla, joita meillä oli käytössämme olevissa järjestelmissä, ja sano, ettet päätyisi tekemään jotain samanlaista.

Paul Machacek

Paulin käyttämä kehitysympäristö oli melko yksinkertainen. ”Alunperin Raressa kaikki käyttivät PDS:ää (Programmers Development System), joka oli tekstieditori ja koodin assembleri. Meillä oli itse rakennettuja liitäntäkortteja, jotka kytkettiin NES:n kasettipesään, ja ne oli liitetty nauhakaapelilla PC-tietokoneisiimme, joissa oli PDS”, hän kertoo. ”Meillä ei ollut verkkoa. PC:t olivat Amstradeja, joissa oli 20 megatavun (ei kirjoitusvirhe) kiintolevy. Aina kun kokosit koodisi – kaikki tehtiin yhdellä kertaa, meillä ei ollut vielä linkkereitä – koko binääri kopioitiin nauhakaapelin kautta liitäntäkortille, ja koodisi ajettiin kohdekoneella. Dokumentaationa meillä oli vain NES:n vakiomuotoinen käsikirja, jossa oli muutama kirjoitusvirhe, jotka oli korjattava, muuten homma ei toiminut, ja lisäksi kätevä 6502-käyttöohjeopas, jota voitiin käyttää silloin tällöin, varsinkin jos halusit kirjoittaa itseään muokkaavaa koodia.”

Jos olet ohjelmoija, joka nyrpistelee tästä, tilanne vain pahenee. ”Nykypäivän kaltaisia virheenkorjaustyökaluja ei ollut”, Paul jatkaa. ”Oli temppuja, joilla sai selville, mihin koodisi pääsi ennen kuin asiat menivät pieleen, esimerkiksi kirjoittamalla arvoja muistipaikalle ja katsomalla, mikä niistä kirjoitettiin viimeksi ennen kaatumista, ja käyttämällä sitten puolittaishakua, jolla voit rajata virheellisen koodin. Suorituskykytestausta varten sinulla oli yleensä jokin visuaalinen muutos näytöllä (näytön vaakasuuntaisen vieritysrekisterin siirtäminen tai väripaletin muuttaminen) toiminnon alussa, ja nollasit sen sitten lopussa niin, että voisit ’mitata’, kuinka kauan se kesti näytöllä piirtämällä merkkejä tusseilla tämän näkyvän indikaattorin ympärille ja katsomalla, muuttuivatko merkit lähempänä toisiaan, kun jatkoit koodin optimoimista. Kyllä, hyvät ystävät, näinä aikoina mitattiin koodin suorituskyky senttimetreinä!”

Se kuulostaa melko hankalalta työskentelytavalta, mutta Paul pitää sitä vain silloisten olosuhteiden tuotteena. ”Teimme silloin, mitä meidän oli pakko tehdä. Palatkaa 35 vuotta taaksepäin, kehittäkää, mitä me teimme niillä työkaluilla, joita meillä oli käytettävissämme, ja sanokaa, että ette päätyisi tekemään jotain samanlaista!” Onneksi tilanne parani lopulta Paulin ja hänen kollegoidensa osalta. ”Muutaman vuoden kuluttua Rare palkkasi läheisen yhteistyökumppaninsa Jon Ritmanin kirjoittamaan uuden järjestelmän nimeltä GLAM [Global Language Assembler Monitor], joka korvasi PDS:n. GLAM:llä pystyttiin käyttämään useampia erilaisia prosessoreita, ja siinä oli sekä linkkeri että assembleri, joten koko koodipohjaa ei tarvinnut koota joka kerta, kun jotain muutettiin, mikä nopeutti kehitystyötä. GLAM toimi todella hyvin.”

Lue myös  Dragon Age 4: n tuotantojohtaja poistuu Biowaresta 19 vuoden kuluttua

Donkey Kong NES

(Kuvan luotto: Nintendo)

Lopulta 6502-ohjelmointi ei ollut Paulille suuri ongelma uuteen alustaan siirtymisessä. ”Minulle suurempi muutos oli siirtyminen kotitietokoneista, joissa oli bittikartoitetut näytöt, NES:n merkkikartoitettuun järjestelmään, jossa oli erilliset väripalettien nimitykset, merkkipankit (ja niiden vaihto) sekä muistipankkien vaihto kärryillä”, hän muistelee. Nintendon Picture Processing Unit – lyhyesti PPU – oli Ricohin tilaustyönä suunnittelema, ja Morphcat Gamesin Nicolas BÉtoux’n mukaan ”tuon ajan muihin laitteistoihin verrattuna grafiikka- ja vieritysominaisuudet olivat loistavat”.

Kun Famicom julkaistiin vuonna 1983, sen lähin kilpailija Japanissa oli Segan SG-1000. Famicomin graafiset ominaisuudet olivat selvästi paremmat: Famicomissa oli yli 50 väriä, kun Segan järjestelmässä niitä oli vain 16. Spriteissä saattoi olla kolme väriä, kun niitä oli vain yksi, ja näyttöä voitiin vierittää pikselikohtaisesti eikä hahmokohtaisesti, mikä johti huomattavasti sulavampaan ulkoasuun. Nintendon laitteisto pystyi myös näyttämään enemmän sprittejä ja enemmän sprittejä skannausviivaa kohden. Sega esitteli graafisesti paremman Mark III -laitteiston vuonna 1985, joten kilpailu oli tasaisempaa, kun NES ja Master System tulivat kansainväliselle yleisölle.

Työkalut

Vaikka Nintendon 8-bittisessä laitteistossa oli edistykselliset graafiset ominaisuudet, grafiikan luomiseen käytetyt menetelmät olivat kaikkea muuta kuin edistyksellisiä. Taiteilija Kevin Bayliss ei ollut Paulin tavoin koskaan törmännyt NES:ään ennen kuin hän loi pelejä järjestelmään. ”Ensimmäisenä päivänäni Raren palveluksessa Tim [Stamper] näytti minulle pikselöintiprosessin perusteet ja opetti minulle, miten luoda töitä, jotka voitaisiin sisällyttää peliin”, hän kertoo.

”Minun piti periaatteessa piirtää taideteokseni ja sijoittaa se ruudukon alle suurelle piirustuspöydälle, joka oli täynnä fluoresoivia nauhoja. Sen jälkeen piirsin piirustukseni rasterin avulla pikseleitä lyijykynällä, ja sitten täytin pikselit huopakynillä. Sitten työ oli järjestettävä ja jaettava laatikoihin (8×8 spriteihin), ja sprite- ja sijaintitiedot oli laskettava heksadesimaalisesti päässäni. Tämä oli melko helppoa, mutta toisinaan hieman työlästä, ja usein tätä työtä ei halunnut tehdä, koska se ei ollut lainkaan luovaa. Halusit vain nähdä työsi pelissä.”

Jos sinua hämmentää tietokoneen puuttuminen tuosta prosessista, et ymmärrä mitään väärin. ”Ei ollut muita työkaluja kuin kynä, lyijykynä, paperi ja kirurginen skalpelli, jolla sai raapustettua virheet jäljityspaperille, kun laittoi pikselin väärään paikkaan tai halusi leikata pikseleitä pois hahmosta, jotta se mahtuisi pienempään datamäärään”, Kevin selventää. ”Mark Betteridgen kirjoittama yksinkertainen sprite-editori oli olemassa, mutta sitä ei oikeastaan käytetty, koska se oli hyvin rajallinen, eikä sen avulla voinut tarkastella animaatiota (niin kuin vanhoissa Disneyn ’kulissien takana’ -materiaaleissa – kääntämällä paperia edestakaisin animaation illuusion luomiseksi).”

Käytössä ei ollut muita työkaluja kuin kynä, lyijykynä, paperi ja kirurginen skalpelli virheiden raapustamiseen.

Kevin Bayliss

Koska NES-kehitystyökaluja ei ollut standardoitu, eri yritykset käyttivät erilaisia taidetyökaluja. Nintendo käytti jossain vaiheessa käsin piirrettyjä spritejä, mutta loi lopulta hiirellä ohjattavan pikselitaidetyökalun, kun taas Namikolla oli sprite-muokkaustyökalu, jossa oli Kevinin kuvaama animaatioiden esikatselumahdollisuus. Hän kuitenkin piti Raren käyttämästä matalan teknologian lähestymistavasta.

”Oli itse asiassa aika mukavaa, että meillä oli rajallinen paletti. 16-bittistä konsolia varten ei olisi voinut mitenkään piirtää kaikkia grafiikoita paperille, koska kyniä ei olisi koskaan riittänyt, ja dekoodaaminen olisi vienyt koko päivän – ja olisit tehnyt niin paljon virheitä, että se olisi ollut mahdotonta”, hän sanoo. ”Mutta koska väripaletti oli yksinkertainen, resoluutio oli pieni ja spritejä oli vähän, grafiikan tekeminen paperille oli itse asiassa aika hauskaa ja tuntui paljon ”orgaanisemmalta” kuin sen luominen digitaalisesti SNES:llä, joten kai siitäkin on jotain sanottavaa.”

Riippumatta siitä, miten kehittäjä loi taidetta NES:lle, tekniset rajoitukset vaikuttivat lopputulokseen. ”Sprites per rivi (yli 64 täytettyä pikseliä vaakasuoralla skannausviivalla) oli ongelma, joten hahmoja ei yritetty tehdä kovin laajoiksi”, Kevin selittää. ”Muistan esimerkiksi, että kaikkien tekemieni WWF-pelien hahmojen piti joko ’kaatua taaksepäin’ tai ’maata maassa’, ja se tarkoitti tietysti sitä, että heistä tuli siinä asennossa melko leveitä. Hahmoja yritettiin usein kääntää kulmaan tai poseerata fiksusti, mutta sitä ei koskaan voitu välttää. Hahmot vilkkuivat ja vilkkuivat usein erityisesti tällaisissa beat-’em-up-peleissä, ja se oli ongelma, joka kaikkien yhtiöiden oli ratkaistava parhaalla mahdollisella tavalla.”

Tuo tyypillinen välkkyminen on itse asiassa nokkela ohjelmointikeino – NES yksinkertaisesti ohitti pikseleitä, jos näytössä oli liian monta spriteä, joten spritejen nopea vaihtaminen päälle ja pois takasi ainakin sen, että kaikki spritit näkyivät jossain muodossa.

NES

(Kuvan luotto: Nintendo)

NES-kehittäjät joutuivat usein käyttämään luovuuttaan toteuttaakseen visionsa – kuten Kevinin Cobra Triangle -peliin piirtämät valtavat pomohahmot. ”Cobra Trianglen kohdalla olimme onnekkaita, koska peli tapahtui isometrisessä ympäristössä, joten kaikkia grafiikoita katsottiin kulmasta, mikä vähensi leveyttä, jota normaalisti näkisi vaakasuoraan vierivässä pelissä”, hän sanoo.

Lue myös  Resident Evil 4 Remake Shooting -galleria ja kaikki viehätykset, jotka voit avata

”Pomohahmot olivat kaikki kokoelma isoja spritejä, ja pystyimme käyttämään veden pintaa saadaksemme asiat näyttämään upotetuilta lisäämällä niiden ympärille muutamia ’aaltoilevia’ spritejä. Esimerkiksi luomani merihirviö (Nessie) oli melko pitkä, ja sen takana olevat kumpareet liikkuivat itsenäisesti, ja kulman vuoksi spriteiden välkkyminen ei ollut kovin suurta.”

Rajoitukset olivat vaikeampia, kun kehitettiin lisenssipelejä, kuten Rare usein teki. ”WWF-painipelejä varten meidän piti varmistaa, että hahmojen kanssa oli hyvä samankaltaisuus. Oli siis vaikeaa ’digitoida’ valokuvia käsin ja toistaa kaikkien ominaisuudet tarkasti, kun hahmon pääkuvalle oli vain noin 16×16 pikseliä valintasivulla”, Kevin kertoo. ”Muistan saaneeni hirvittävän laadukkaita fakseja, joissa oli painijoiden kuvia, ja minun piti yrittää luoda ne uudelleen niin alhaisella resoluutiolla ja kolmella värillä.”

Tämä johti kuitenkin hauskoihin kokemuksiin. ”Usein sain Amerikasta fakseja, joissa sanottiin, että ’grafiikka kaipaisi hieman huomiota’, koska yhdennäköisyys ei ollut tarpeeksi lähellä”, Kevin jatkaa. ”Sitten muutin vaikkapa yhden pikselin, ja seuraavana päivänä sain faksin takaisin, jossa sanottiin, että kuva oli paljon parempi. Se sai minut todella nauramaan, kun näin kävi. Kun työskentelin Beetlejuice-pelin parissa, minulla oli myös päinvastainen ongelma: otsikkosivun kuvitus näytti ilmeisesti liikaa Michael Keatonilta, joten minun piti tehdä se uudelleen, jotta se muistuttaisi enemmän Beetlejuicea – aika vaikeaa, kun he ovat sama henkilö.”

Shades between

Joskus järjestelmää oli mahdollista venyttää yli teoreettisten rajojensa. ”Jos katsot Super Off Roadia, huomaat, että ruudulla on toisinaan enemmän värejä kuin mitä laitteisto pystyy vakiona käsittelemään”, Paul sanoo. ”Käytössä oli neljä neljän värin palettia, mutta jokaisen paletin ensimmäinen väri oli sama taustaväri kaikille. Taustahahmojen värit voivat siis olla yhteensä 13. Super Off Roadissa niitä on enemmän, koska vaihdoin paletteja VRAM:n tarkkaan ajoitetulla käytöllä vaakasuuntaisen tyhjennyksen aikana. Tämä toimi hienosti”, Paul selittää, ennen kuin korjaa itseään. ”No, se toimi NES:n yhdysvaltalaisessa versiossa.

Kun peli oli valmis, minulle kerrottiin, että se julkaistaisiin Japanissa Famicomilla, joka oli laitteistoltaan hieman erilainen, ja valitettavasti värinvaihtoni ei toiminut siinä, joten uskon, että sitä ei julkaistu siellä.” Äänestä huolehti sama Ricoh 2A03 -piiri, joka sisälsi myös prosessorin. ”NES:ssä on neljä äänikanavaa, joilla työskennellä. Emme laske DPCM (sample) -kanavaa, emme käytä sitä, koska siinä on joitain haittoja”, kertoo nykyaikaisia NES-pelejä kehittänyt Nicolas.

”Oli miten oli, siinä on kaksi neliöaaltogeneraattoria, yksi kolmioaalto, jota käytetään usein bassolinjoihin, ja yksi kohinakanava, jota käytetään perkussiivisiin ääniin. Polyfonian ja äänensävyjen vaihtoehdot ovat siis rajalliset, mikä vaikeuttaa tunnelmallisemman soundtrackin luomista, jollaisia kuulee nykypeleissä. Todennäköisesti tämä on yksi syy siihen, miksi monet pelien soundtrackit aikoinaan korvasivat sen dynaamisilla sävellyksillä ja tarttuvilla melodioilla.”

NES

(Kuvan luotto: Nintendo)

NES-äänessä on joitakin erityisen erikoisia piirteitä, eikä vähiten kolmiotaaltoja, jotka ovat porrasmaisia eivätkä tasaisia, mikä johtuu järjestelmän 4-bittisestä äänenkäsittelystä. ”Kanavien rajallisen määrän vuoksi on myös otettava huomioon, että äänitehosteet voivat keskeyttää musiikin”, Nicolas lisää. ”Ihannetapauksessa äänitehosteet toistetaan vain säestykseen käytettävillä kanavilla, jotta ne eivät hiljennä melodiaa.”

Ääni on myös yksi Famicomin ja NES:n erottava tekijä, sillä Famicom tukee laajennettua äänentoistoa kasettiportin kautta – tätä Famicom Disk System ja tietyt erityiset kasettisirut hyödyntävät. Koska NES:ssä ei ole tätä mahdollisuutta, The Legend Of Zelda- ja Castlevania III: Dracula’s Curse -pelien kaltaisten pelien japanilaisissa versioissa on huomattavasti parempi musiikki kuin kansainvälisissä versioissa. Erikoissirut olivatkin yksi NES:n pitkäikäisyyden avaintekijöistä. Sen lisäksi, että NES tuki sekä ROM- että RAM-muistia kasettien piirilevyillä, se pystyi käyttämään siruja, joita Nintendo kutsui Memory Management Controllereiksi.

Nämä piirit mahdollistivat pankkien vaihtamisen, joka ylitti alkuperäisen kasettispesifikaation tallennusrajoitukset, ja lisäksi ne tarjosivat lisäominaisuuksia pelinkehityksen helpottamiseksi ja Famicomissa jopa laajennusääntä. Tämän ansiosta järjestelmä pystyi vuosikymmenen aikana siirtymään Donkey Kongin kaltaisista peleistä Kirby’s Adventuren kaltaisiin monimutkaisempiin peleihin. Vaikka ROM-kapasiteetti ylitti huomattavasti alkuperäisen 40 kilotavun kokonaiskapasiteetin, kehittäjät taistelivat usein jokaisesta tavusta. ”Tuohon aikaan yleinen ongelma oli yrittää ahtaa pelit pienille kaseteille, joita meille annettiin”, Paul sanoo. ”Tätä vaikeutti NES:ssä/Game Boyssa (molemmissa 8-bittisissä järjestelmissä oli 64KB:n muistikartat) pankkien vaihtaminen, jolloin alue saatettiin jakaa neljään 16KB:n lohkoon, ja eri ROM-pankkeja voitiin vaihtaa niihin ja niistä pois.

Oli siis järjestettävä huolellisesti, mitä koodia ja dataa oli missäkin ja miten hyppäsi ROM-pankista toiseen samassa osoiteavaruudessa käyttäen tavanomaisia overlay-hyppytaulukoita avaruuden alussa. Meidän oli myös kehitettävä datan pakkausrutiinit, usein eri tyyppisille datatyypeille – merkkidata, karttadata, tekstidata, musiikkidata – eri rutiinit. Huffman-pakkausta käytettiin melko paljon, mutta vietin myös aikaa tuijottaen muun tyyppisten tietojen tulosteita etsien malleja, joita voisin käyttää pakkauksen ohjelmiston kehittämiseen.”

Lue myös  Zelda-kyyneleet valtakunnan Iun-OROK SHRINE -oppaasta ja esittelystä

8-bitten

James on samalla tavalla täynnä kiitosta ohjelmistolle: ”Yhteisö on mahtava ja resurssit tracker-sovellusten käyttämiseen ovat kaikkien saatavilla, olitpa sitten kokenut säveltäjä tai vain chiptunes-fani.” Näiden nykyaikaisten työkalujen ansiosta NES-kehittäjät kokeilevat nykyään usein hyvin kunnianhimoisia projekteja. Neljän pelaajan toimintapelit ovat harvinaisuus NES:llä, mutta Morphcat Games loi erinomaisen pelin Micro Magesissa. Se vaati laitteiston erittäin säästeliästä käyttöä.

”NES sallii enintään 64 laitteistospriten olevan ruudulla kerrallaan”, Nicolas aloittaa. ”Nämä spritit ovat kooltaan 8×8 pikseliä (on olemassa 8×16-tila, mutta siinä on haittapuolensa), ja ne voidaan liittää yhteen muodostaakseen suurempia spritejä.” Eli saadaksesi 16×16 spriten ensimmäisessä tilassa sinun täytyy käyttää neljää laitteistospriteä. Jos kaikki neljä pelaajaa käyttävät 16×16-spritejä, se on neljäsosa kaikista käytettävissä olevista laitteistospriteistä, joita käytetään pelaajissa! Lisäksi on olemassa laitteistorajoitus, jonka mukaan jos yli kahdeksan spriteä on samalla vaakasuoralla rivillä, ne alkavat kadota”, hän jatkaa. ”Tämän korjaamiseksi ja silti monien muiden objektien ja graafisten efektien sallimiseksi ruudulla Micro Magesin pelaajahahmot käyttävät kukin yhtä 8×8 spriteä.”

Nicolasin mukaan myös 8-bittinen prosessori osoittautuu rajoittavaksi tekijäksi. ”Jos pelissä on vihollinen, joka liikkuu vain sivuttain ja kääntyy ympäri törmätessään seinään, se on rajallinen määrä tarkistuksia, jotka on suoritettava. Ihmispelaajat taas ovat jokereita, jotka ovat vuorovaikutuksessa kaiken ympärillään olevan kanssa tavoilla, joita kehittäjä ei voi täysin ennakoida.

NES

(Kuvan luotto: Nintendo)

Rakastin NES:n koodaamista, se oli täysin erilainen arkkitehtuuri kuin kotitietokoneet, joiden parissa olin työskennellyt aiemmin.

Paul Machacek

Lisäksi jos pelaajilla on mahdollisuus ampua, ruudulla olevien esineiden määrä kasvaa nopeasti, hän kertoo. ”Tämä ei ole niin suuri ongelma yksinpelissä, ja kahden pelaajan pelissä pääsee yleensä helpolla. Mutta neljän pelaajan peli? Auts. Micro Magesissa käytimme paljon aikaa optimointiin viiveen välttämiseksi. Neljän pelaajan tilassa peli kuitenkin hidastuu toisinaan, kun liikaa tapahtuu.”

Yksi etu, joka nykyaikaisilla kehittäjillä on, on mahdollisuus valita monista erilaisista muistinhallintaratkaisuista, joita nykyään kutsutaan yleisemmin mappereiksi. ”Niitä on vain niin mielenkiintoista purkaa ja kehittää”, James sanoo. Huolimatta siitä, että käytettävissä on tehokkaimmat, ne eivät aina ole oletusvalinta. ”Kun peliä suunnitellaan Mega Catissa kehitettäväksi, lähdemme liikkeelle siitä, mitä tarvitaan, jotta pelin ydin on hauska”, James selittää. ”Joissakin tapauksissa päädymme käyttämään oletusarvoisesti jotain tehokasta, kuten MMC3-karttaajaa. Toisissa tapauksissa voimme pitää asian yksinkertaisena ja käyttää erillistä karttaajaa, kuten NROM:ää.” Japanilaisen Karu_gamon hiljattain julkaisemassa NES-pelissä Blazing Rangers käytettiinkin nimenomaan yksinkertaisinta mapperia, NROM:ia, herättääkseen nostalgiaa Famicomin alkuaikoihin. Tämä on oikeastaan kehittäjien jatkuvan NES:ään kohdistuvan viehätyksen ydin – se ei ole vain teknisesti mielenkiintoinen järjestelmä, vaan se tarjoaa myös vahvan nostalgisen vetovoiman.

Jopa ne, jotka kohtasivat sen ensimmäisen kerran työelämässä, kuten Kevin, tuntevat tätä nostalgiaa. ”Nautin työskentelystä NES:n parissa taiteilijana, koska lopulta tunsit järjestelmän todella hyvin. Loitpa sitten taustoja, animoituja spritejä, otsikkosivuja tai etusivun (tulostaulun) grafiikkaa – sinulla oli käytössäsi järjestelmä, jota olit käyttänyt aiemmassa pelissä, ja toisinaan keksit jotain uutta, jotta voisit puskea sitä hieman pidemmälle ja puristaa siitä visuaalisesti enemmän irti. Yksinkertaisia aikoja, mutta hauskoja!”

Vaikka Paul valittaa 6502:lle ohjelmointiin liittyvää numeroiden jongleerausta, hän muistaa järjestelmän myös lämmöllä. ”Rakastin NES:n koodaamista, se oli täysin erilainen arkkitehtuuri kuin kotitietokoneet, joiden parissa olin työskennellyt aiemmin, ja hahmokuvioidulla näytöllä saattoi tehdä mielenkiintoisia temppuja, joita saattoi hyödyntää syvyyden antamiseen – katso Battletoads-pelit NES:llä/Game Boylla – ja pidin sitä mielenkiintoisena teknisenä haasteena ’ratkoa’ uusia asioita tämän vaihtoehtoisen laitteistoarkkitehtuurin ympärillä.”

Menneisyyden tulevaisuus

Vaikka järjestelmän ohjelmointi olikin hauskaa, Paul viittaa oikeutetusti tämän työn tuloksiin NES:n menestyksen syynä. ”Ei saa unohtaa, että Nintendolla oli uskomaton pelivalikoima järjestelmissä, erityisesti Super Mario ja Zelda. Super Mario Bros 3 oli valtava edistysaskel ja ehdoton huippu siihen aikaan”, hän sanoo.

Jos haluat luoda retropelejä, NES saattaa olla ihanteellinen alusta sinulle. ”NES-koodia, grafiikkaa ja ääntä on helppo hallita yhden henkilön voimin tiimissä”, Nicolas sanoo. ”Nykyiseen verrattuna ohjelmointikieli tuntuu nykyaikaisia kieliä hämärämmältä ja monimutkaisemmalta. Kaikki rajoitukset pakottavat käyttämään enemmän aikaa kaikkeen”, hän myöntää. ”Mutta se myös pakottaa miettimään jokaista ideaa kahdesti. Lopulta voit keskittyä pelattavuuden kannalta tärkeimpiin.

Nämä rajoitukset voivat pitää pelin laajuuden kurissa – voit tehdä vain rajallisen määrän.” Jos huomaat, että sinua viehättää ajatus tuon teknisen haasteen ratkaisemisesta, näytä meille tulokset jonain päivänä – olemme aina kiinnostuneita näkemään ne.

Tämä artikkeli ilmestyi alun perin Retro Gamer -lehdessä. Jos haluat lisää upeita artikkeleita ja haastatteluja, voit tilata Retro Gamer -lehden painettuna tai digitaalisena täällä.

Frenk Rodriguez
Frenk Rodriguez
Hei, nimeni on Frenk Rodriguez. Olen kokenut kirjoittaja, jolla on vahva kyky kommunikoida selkeästi ja tehokkaasti kirjoittamalla. Ymmärrän pelialaa hyvin ja pysyn ajan tasalla uusimmista trendeistä ja teknologioista. Olen yksityiskohtainen ja kykenen analysoimaan ja arvioimaan pelejä tarkasti, ja suhtaudun työhöni objektiivisesti ja oikeudenmukaisesti. Tuon myös luovan ja innovatiivisen näkökulman kirjoittamiseeni ja analyyseihini, mikä auttaa tekemään oppaistani ja arvosteluistani kiinnostavia ja mielenkiintoisia lukijoille. Kaiken kaikkiaan nämä ominaisuudet ovat mahdollistaneet sen, että minusta on tullut luotettava ja luotettava tiedon ja näkemysten lähde pelialalla.