Teooria

Mängudisain otsese tegevusena hõlmab eelkõige mängureeglite ja mängukeskkonna analüüsi ja loomist ning struktureeritud talletamist disainidokumentatsiooni vormis. Üldjuhul on disaini väljundiks kas dokument või graafik (nt. flowchart või klassidiagramm), mis seletab konkreetset osa mängu tegevusest, eelkõige mängija vaatepunktist.

Mängijakeskne disain on suuresti sarnane äriinfotehnoloogias levinud "kasutajalugudele" (User Story) keskendunud töövoogudele. Eelduseks on see, et on olemas mängija, kellele pakutakse teatud tegevusi, mille abil teda premeeritakse mängu sisu läbi mängides. Selleks, et mängijat teavitada, missugused tegevused on mängureeglite kohaselt korrektsed ehk mida on vaja teha, et mängus edasi progresseeruda või see võita, on tarvis anda mängijatele selle kohta ohtralt tagasisidet.

Et alustada mänguidee formaliseerimist, on üldiselt soovitatud läbi mõelda mängu põhitsükkel (Core Loop või Core Gameplay Loop), mis määrab ära üldises sõnastuses mängija poolt käivitatavad põhilisemad tegevused ja nendega seotud nii mängumehaaniline kui ka visuaalne tagasiside.

Selleks, et jõuda mänguideest millegi päriselt mängitavani, on kolm väga põhilist sammu.

1. Ideede formaliseerimine disaini vormis

2. Disaini tõlgendamine implementatsiooniplaaniks

3. Implementatsiooniplaani elluviimine prototüübi vormis

Mängu omaduste (features) ja mängukava (gameplay) laiendamiseks kasutatakse sageli täpselt sama üldist kolmesammulist protsessi, tavapäraselt ka iteratiivselt, st. kui on valminud läbimängitav prototüüp, analüüsitakse seda ja jõutakse uute ideedeni, mis formaliseeritakse disainiks ja mida järjekordselt edasi prototüübitakse.

See pole ainus viis, kuidas mänge teha, kuid annab suhteliselt lihtsasti järgitava struktuuri nendele, kes ei tea täpselt, kuidas nad mängude loomisega algust sooviksid teha. Igaühel on oma isiklikud disainiprotsessid, mille läbi nad jõuavad oma eesmärkideni ja nagu iga loomeprotsessiga - õigeid vastuseid ei ole, on ainult teostus, mis kas vastab visioonile või mitte. Visiooni hoidmine, st. esialgse mänguidee säilitamine läbi mängudisaini ja implementatsiooniprotsesside on mängudisaini ning mängude produktsiooni üks kõige olulisemaid aspekte. Kui mängul puudub koherentne ja üheselt mõistetav visioon selle loomise käigus, siis on seda üldjuhul ka mängijatele märksa raskem seletada.

Nii viivadki mängudisaini teekonna esimesed sammud tavaliselt mänguloojate ideedest selleni, kuidas mängija nende visiooni valmis mängus ellu viiks, mis omakorda tähendab seda, et mängija potentsiaalseid tegevusi kirjeldades on alati vaja arvesse võtta seda kuidas mängija liidestub mänguga ehk kuidas on võimalik mängijal pakkuda mänguprogrammile sisendit.

Sisend ja tagasiside

Mängija sisendit loetakse sisendseadmetelt, nt. hiir, klaviatuur, eri kontrollerid. Igale sisendile vastab mängus mingisugune tegevus, olgu selleks tegelase või kaamera liigutamine, ekraanide avamine, sulgemine või seal olevate elementidega interakteerumine või kiirkäskude andmine.

Mänge on väga palju ja nende sisendi olemus võib erineda tohutult mängust, kuid oluline on teha mänguprogrammis kasutajale mängureeglitega interakteerumine võimalikult mugavaks. Sealjuures saab rakendada kasutajaliidese ja kasutajakogemuse (UI/UX) disaini, mille ülesanne on välja töötada eri meetodid, kuidas mängija saab mängu juhtida.

Kui tuua näitena lihtsamad mängud, nagu näiteks Pong, kus mängija liigutada on üks ristkülik, mille vastu saab põrgata simuleeritud pall, on võimalik mängijal vaid üks tegevus: liigutada oma "reketit". Reketit saab liigutada üles ja alla, mille jaoks on eraldatud tavaliselt kaks eri iseloomuga sisendit, milleks võivad olla näiteks klaviatuuril üles ja alla nupp, W ja S nupp või kontrolleri peal D-pad'il üles/alla nupud või siis analoogpulk, mis annab analoogsisendi vastavalt sellele kui palju mängija surub seda üles või alla.

Pong'i puhul on tegemist liikumisega vaid ühes dimensioonis. Kui Pong'i reeglistikku muuta nii, et mängija saaks liikuda ka oma reketiga vasakule/paremale, liigutakse kahes dimensioonis. Kui seda veelgi laiendada ja lisada sügavus dimensioonina, oleks tegu juba kolmemõõtmelise mänguga, kus mängija saab liikuda kolme eri telje peal ning iga telje jaoks on vaja lahendada (tavaliselt) kaks sisendit: liikumine positiivses ning ka negatiivses suunas. St. oletades, et meie teljed on markeeritud kui X (horisontaalsus), Y (vertikaalsus) ja Z (sügavus), et mängija saaks liikuda ühe nende telje peal, on vaja sellele omistada mingi sisend, mis liigutab mängija kontrollitud mänguelementi mängijale soovitud suunas.

Liikumise puhul on mängijale tegevuse tagasiside üldjuhul silmaga nähtav. Kui mängija aktiveerib mingisuguse liikumissisendi, nende kontrolli all olev mänguelement, näiteks Pong'i reket, liigub teatud suunas. Seda saame nimetada otseseks tagasisideks. Kui võtta natuke keerulisem näide, näiteks First Person Shooter'ite (FPS) maailmast tuntud mäng Doom, on meil lisaks liikumisele võimalik ka tulistada relvast kuule välja. Jällegi, kui mängija aktiveerib sisendi, mis tulistab kuuli, peaks mäng näitama, et kuul tekib ning liigub iseseisvalt mängija sisendist olenemata edasi, algses sihitud suunas. Mängureeglite kohaselt saame ära määrata kui kaugele kuul võib liikuda, mis juhul see mängumaailmast kaduma peaks (näiteks kokkupõrkel takistuse või vaenlasega) ja mis juhtub, kui see põrkab millegagi kokku.

Mängudes pidevalt muutuva ja mängija poolt manipuleeritava maailma kirjeldamiseks kasutatakse sageli terminit "Game State" ehk mängu olek. Mängu olek on nimelt mänguprogrammi poolt käideldava simulatsiooni hetkeseis. Mängu olek saab oma alguse mängu alustades ning oma lõpu mängu lõpetades. Oluline on ka mängu oleku puhul täheldada, et seda üldjuhul peaks olema võimalik salvestada, et mängija saaks teha mängust pausi, mänguprogramm kinni panna ning hilisemal hetkel uuesti see mänguprogrammi sisse laadida ning taastada eelnev olek. See pole küll kohustuslik osa mängudest, kuid on üldjuhul hea tava see mingil määral lisada. Osad mängud lihtsalt salvestavad mängusessiooni lõppoleku näiteks selleks, et talletada mängija poolt kogutud sessiooni jooksul kogutud punktid või muud mängija tegevusi kirjeldavaid parameetreid, näiteks mitmenda tasemeni ta on jõudnud.

Selleks, et neid parameetreid ka mängijale näidata kasutatakse eelkõige visuaalset tagasisidet. Näiteks: kui tulistada vaenlast, siis lõpuks tema elupunktid saavad otsa ja ta "hävib", näidates mängijale animatsiooni, et see on juhtunud ning mille eest mängija saab näiteks punkte. Samas neid punkte, mis on mängija kogunud, näidatakse kasutajaliideses.

Kasutajaliides

Kasutajaliides (User Interface) on mänguloojate üks kõige paindlikum viis kuidas mängu olekut mängijale selgeks teha. See võib olla ekraanilt alaliselt nähtav ning võib näidata mängijale mistahes parameetreid, mis disainer otsustab, et mängija jaoks võiks vajalik olla. Näiteks: punktid, elupunktid, kuulide arv, kogutud esemed, tegevused, mida mängija peab tegema, et mängus edasi jõuda ning lugematu hulk asju, mis oleneb juba mängu enda spetsiifikast.

Kasutajaliides kasutab mängu olekust saadud andmeid, et seda kuvada mängijale ekraanil. Üldjuhul seda informatsiooni dubleerima ei pea, vaid kasulik on otse mängu olekust andmeid pärida, et ei tekiks võimalust, et tegu oleks kuidagi valesti arvutatud või ajutiste andmetega mängu olekust. Samas, kasutajaliidesele on vaja kirjutada reeglid, mis juhtudel uuendada andmeid, mida mängijale näidatakse. See on samuti osa mängudisainist. Esmalt on vaja otsustada, mis andmeid üldse näidata ja kui see on otsustatud, siis tuleb välja mõelda, millal neid uuendada.

Et mängijat kursis hoida, mis tema tegevuste tagajärg on olnud mängu mängides, on üldiselt kõige kasulikum uuendada kasutajaliideses näidatud andmeid niipea, kui need mängu olekus muutuvad. See tähendab, et mänguprogrammis, nendes kohtades kus mängu olek (implementatsiooni käigus defineeritud muutujad) muutub, on vaja välja kutsuda ka vastavad funktsioonid kasutajaliideses, mis liideses defineeritud elementidel kajastuma peavad. See juba omakorda tähendab, et andmemudeli seisukoha pealt, on vaja luua seos mängu oleku ja simulatsiooni vahel ning kasutajaliidese vahel. Objekt-orienteeritud programmeerimise puhul on tegu reeglina eraldi koodiklasside ning täiesti eraldiseisvate ja iseseisvate objektidega.

Näide: 1. Koodiklass "Player" kus on kõik mängijale olulised parameetrid näidatud, näiteks tema elupunktide arv (HitPoints). 2. Koodiklass "HUD" (ehk Heads Up Display), kus on tekstielement, mis on võimeline kuvama numbreid mängija ekraanil.

Meile vajalik muutuja HitPoints on vaja toimetada kuidagi Player klassist HUD klassi ning seda võib teha kas nii, et HUD objekt küsib Player objektilt seda väärtust iga kord kui mängija elupunktid muutuvad või Player objekt saadab selle HUD objekti iga kord kui mängija elupunktid muutuvad. Kuidas täpselt implementatsioon on tehtud, ei oma olulist tähtsust kui see just ei häiri muud mänguprogrammiga seotud toiminguid. Mis on oluline, on see, et mängijale oleks selge, mis parasjagu mängu olek on. Mängija ei näe koodi, mis jookseb mänguprogrammis taustal, neile on kõige tähtsam see, et nende sisend ja tagasiside mis nad saavad oleks võimalikult selgelt arusaadav.

Mängureeglid ja mängumehaanikad

Mängijale hea kogemuse pakkumiseks mängu mängides on tarvis mängule välja mõelda põnev reeglistik. Esmalt on mõistlik välja mõelda, mis on mängus olevad olemid, mille läbi mängija saab oma sisendi abil mänguga liidestuda. Kas selleks on tegelane, kes kõnnib ringi, kosmoselaev millega saab vabalt kolmemõõtmelises ruumis manööverdada või hoopiski lihtsalt kummituslik vorm, midagi mida ei saagi näha otseselt kui mängija kontrollitud objekti, nagu on paljudes strateegiamängudes kombeks.

Üldjuhul kasutatakse mängus eri objektide vahel interaktsioonide tekitamiseks ja lahendamiseks maailmas olevat ruumi ja objektide vahelisi kaugusi. See tähendab, et kui kaks objekti saavad kokku või on piisavalt lähedal üksteisele võib midagi juhtuda, näiteks nad põrkavad kokku ja eralduvad. Pong'i puhul näeb see välja nii, et pall küll põrkab reketist eemale, aga reketi liikumine pallist ei olene. Strateegiamängudes nagu StarCraft saad mängija liigutada oma kontrolli all olevaid tegelasi üle kaardi, aga nad üksteise peale ei mahu, st. nad justkui lükkavad üksteist eemale. Ruum ja selles liikumine/orienteerumine on kõige levinum mängumehaanikate allikas. Super Mario puhul me jookseme mööda kaarti ehk liigume mööda kahemõõtmelist ruumi selleks, et jõuda taseme lõpuni. Candy Crush puhul me liigutame ruumis eri mänguelemente, et neid teatud seadistuses kombineerida, mille juhtumisel see kombinatsioon kaob ja uued mänguelemendid sajavad meie mänguväljakule uuesti peale. Point-and-click seiklusmängudes me liigume mööda stseene ja vajutame objektide peale, et nendega midagi juhtuks. Ja nii edasi ja nii edasi.

Mistahes interaktsioon kahe objekti vahel mängus selle reeglite poolt määratud on, kasutatakse selleks üldiselt ruumi. See tähendab seda, et meil on kujuteldav ala, kus asjad asetsevad, neil on oma asukoht ja oma kuju. Kui kuju kattub mingi teise kujuga, tekib kokkupõrge, mida me saamegi ära kasutada oma mängumehaanika kirjeldamiseks. Mis see täpselt olla võib - tuleb rakendada oma kujutlusvõimet. Olgu see kokkupõrge reketi ja palli vahel Pong'is, kuuli ja vaenlase vahel Doom'is või autoga vastu seina sõites Need for Speed'is, saame me alati välja mõelda midagi mängija jaoks tähenduslikku, kui meie mängus on olemas ruum.

Üldjuhul, et kokkupõrget tuvastada on mängumootorites ja mänguloome tarkvarateekides olemas rudimentaarne füüsikamootor. See tähendabki seda, et meil on võimalik mänguprogrammis defineerida mingi ruum (mänguala) ja seal olevad objektid ning anda nendele objektidele kuju (näiteks kera, ristkülik, kapsel või lausa humanoidne 3D mudel). Kui kokkupõrge toimub, saadetakse läbi füüsikamootori nendele objektidele sõnum (Event/Message), et kokkupõrge on toimunud ja üldiselt ka saadetakse nende funktsioonidega kaasa see objekt millega kokku põrgati. Selle peale saamegi ehitada oma mängu loogika. Kui objektiga tüüpi X põrkab kokku objekt tüüpi Y, siis juhtub midagi, näiteks kellegi elupunktide muutujat muudetakse. Või kui lausa elupunktid otsa saavad, objekt hävineb.

Samuti võib olla interaktsioon objektide vahel märksa passiivsem. Kui me vaatame näiteks platvormer tüüpi mänge, on mängu eesmärgiks ajastada oma liikumine sedavõrd hästi, et mängija saab ületada nende ette pandud takistusi. Ainus interaktsioon selle puhul ongi lihtsalt see, et mängija ei saa takistustest läbi liikuda - takistuste kuju keelab selle ära. Neil on vaja neist saada kuidagi üle või ümber ja see juba võimaldab mängijal kogeda väljakutset, et see ületada, tehes mängu nauditavaks kogemuseks. Sel juhul on mängudisaineri ülesandeks luua mängumaailm, mis on mängijale väljakutsuv kompositsioonilt. Mängija peab leidma tee oma alguskohast lõpp-punkti tajudes ruumi, kus ta mängib ja tajudes oma kontrollitud tegelase liikumist, et ajastada oma liikumine ja näiteks hüpped selliselt, et ta saaks ületada talle loodud takistusraja.

Mängumehaanika võib kajastuda ruumis ka kaudselt, nii, et mänguobjektid üksteisega ei interakteeru, vaid on osa pikemast interaktsioonist mängija poolt. Klassikalised näited nagu laevade pommitamine ja trips-traps-trull on ideaalsed nö. kaudse ruumilise interaktsiooni iseloomustamiseks. Mängijad toimetavad ruudustiku peal, objektid omavahel kokku ei puutu ning mängumehaanika seisneb eelkõige mängija otsustest interakteeruda ruudustikuga ning üritada üle kavaldada oma vastane oma otsustega.

Üks lihtsamaid viise, kuidas kontrollida, kas mängumehaanika on kuidagi loogiline, on luua nö. paberprototüüp ehk füüsiline prototüüp. See ei pea tingimata olema paberil. Trips-traps-trulli puhul on see võib-olla ilmselgem, kuidas seda teha, kuid ka keerulisemate mängude puhul on võimalik prototüüpida mängumehaanikaid pärismaailmas. First Person Shooter mänge saab väga edukalt prototüüpida inimeste ja puuroigastega (või Airsofti/Paintballi relvadega kui on võimalust), strateegiamänge saab "simuleerida" paberil joonistatud kaartidega, seiklusmänge saab välja mõelda kui põgenemistubasid, võimalusi on palju. Füüsilise prototüüpimise mõte on võimalikult palju võimalusi ning probleeme kaardistada mis mänguideega seonduda võivad. See aitab läbi mõelda mängu mehaanikaid - nimelt seda informatsiooni, mis on vaja mängijale näidata, et ta mängust aru saaks ja läbi mängida stsenaariumeid, mis viiksid mängu võidu või kaotuseni.

Viimase sammuna, niipea, kui on välja mõeldud mängu disain ja sellest tulenev implementatsiooniplaan, ongi mängu enda prototüüpimine käivitatava mänguprogrammina.

Mängureeglite ja mängumehaanikate disainiprotsess

Võtame jälle näiteks klassikalise mängu Pong.

Mängu iseloom on võrdlemisi lihtne. Mängus on 2 mängijat, kumbki mängija kontrollib talle omistatud reketit. Reket saab liikuda üles/alla (esimene tegevus) teatud mänguväljaku piires (esimene piirang). Samuti liigub reket kindla kiirusega, mida mängija oma sisendiga ületada ei saa (järgmine piirang). Lisaks reketile on mängus ka pall, mis põrkab vastu mängualas olevaid seinu ja vastu mängijate reketeid. Mängija, selleks et mängu võita, peab liigutama oma reketit, et pall selle vastu põrkaks ning selle tegevuse abil suunama palli teise mängija reketi taha olevasse alasse. Selle tegevuse edukal sooritamisel saab mänguvoor läbi ning mängija, kes edukalt suunas palli vastase tagalasse saab punkti.

Õigemini tuleks seda reeglit defineerida nii, et mängija, kelle tagalasse pall ei jõudnud, saab punkti, sest et programmeerimise seisukoha pealt päästab valla punkti saamise tagajärje see, et pall jõuab ühe mängija tagalasse. Ja see mängija, kelle tagalasse pall jõudis, ei saa punkti - selle saab hoopiski tema vastane. See, mis meile mängijana tundub intuitiivne, võib olla koodi poole pealt teostatud hoopiski vastupidiselt meie kõhutundele. Seetõttu ongi soovitatav mängu disainides luua disainidokument, mis seletab ära, kuidas mängu reeglid on sätestatud ning juba siis arvesse võttes, kuidas selle implementatsioon võiks välja näha.

Seda, kuidas disaini teostus välja näeks koodi poole pealt, võib nimetada tehniliseks disainiks. Seda, kuidas mäng toimib mängija vaatepunktist võib nimetada mängureegliteks, mängudisainiks, mängumehaanikateks, kuidas endal mugavam on. Universaalset terminoloogiat mänguarenduses on suhteliselt vähe, kuid oluline on see, et mängu loomisel saaksid kõik sellega seotud inimesed üheselt aru.

Mängureeglite sõnastamisel tasuks mängu loojatel paika panna oma sõnavara, et nad kõik saaksid aru ühtemoodi sellest, kuidas mingi osa mängust toimima peaks. See on võrdlemisi keeruline kuna inimesed kõik mõtlevad erinevalt aga ka see on mängudisaineri üks ülesanne. Minu eelnev kirjeldus Pong'i kohta on vaid üks võimalus kuidas kirjeldada seda, mida see mäng endast ette kujutab. Kui see kirjeldus anda ilma muu seletuseta programmeerijale ülesandeks implementeerida, siis parimal juhul suudab programmeerija selle välise abita valmis teha, kuid implementatsiooni käigus tõenäoliselt siiski tekiks palju küsimusi. Näiteks: kuidas mängija mängu alustab? Kui kaua kestab üks voor? Kui kaua kestab üks mängusessioon? Mitu punkti on võimalik mängijal saada? Mis on kiirus, millega reketit liigutatakse? Mida näidatakse mängijale kui mängusessioon on läbi? Kus on kasutajaliideses see ala, kus mängijate punkte näidata?

Kõik see spetsiifika on vaja mängu disaini jooksul formaliseerida ehk teisisõnu kirja panna. Kui implementatsiooni käigus tekib küsimusi, on alati võimalik refereerida dokumentatsiooni, mis on disaini käigus tekkinud. Kui implementatsiooni käigus tekib küsimusi, millel ei ole lahendust, on ka need lahendused vaja kirja panna, et oleks, jällegi, ühtne visioon sellest, kuidas mäng käituma peaks.

Testimine, itereerimine ja viimistlemine

Niipea, kui soovitud mängumehaanikad on implementatsioonini jõudnud, tuleb neid ka testida, veendumaks, et disain töötab nagu on ette nähtud (works as intended). Testimisel eristatakse eri testimisviise, millel on oma taust ja mõte ning need võivad olla kas manuaalsed või automatiseeritud.

1. Smoke Test - Käivitatakse mänguprogramm ja mängitakse testija oma suva järgi, et näha kas mäng jookseb kokku või satub raskesse veaolekusse. Kui mänguprogramm jääb püsima, isegi, kui see ei tööta nii, nagu ette nähtud, loetakse test õnnestunuks.

2. Monkey Test - Mänguprogrammile antakse käsitsi suvalisi sisendeid ja vaadatakse, kas see viib mängu veaolekusse. Kui mäng töötab nii nagu ette nähtud, loetakse test õnnestunuks.

3. Feature/Functionality Test - Testitakse konkreetset mängumehaanikat või gruppi mängumehaanikatest, et näha, kas mäng töötab nagu ette nähtud. Kui töötab, on test õnnestunud.

4. Unit Test - Automaatne test, millega testitakse konkreetset mänguprogrammi funktsiooni või gruppe funktsioonidest, et näha, kas need töötavad nii, nagu ette nähtud. Kui test töötab eelduste kohaselt, on test õnnestunud.

5. Soak Test - Mänguprogramm käivitatakse ja jäetakse tööle ettenähtud olekus ning vaadatakse, kas mäng jõuab veaolekusse. Kui ei jõua, loetakse test õnnestunuks.

6. Play Test - Mänguprogrammi mängitakse nii nagu eeldatakse, et mängija seda mängida võiks. Kui kõik mängus implementeeritud mängumehaanikad töötavad nii, nagu ette nähtud, loetakse test õnnestunuks.

Testimismetoodikaid ja testimise vorme on veel palju erinevaid, kuid kõikide põhimõte on veenduda implementatsiooni õigsuses ja vastavuses disainile. Testimise põhiline eesmärk on veenduda, et mäng toimib nagu ette nähtud ja vaid üksikute testimismeetodite eesmärk on veenduda implementatsiooni vastavust tarkvaraarendusstandarditega. Eelkõige on vaja veenduda, et missioonikriitilised osad mängust, mis lubaks mängijal mängida mängu algusest lõpuni probleemideta, töötaksid.

Hea tava on mänge testida pidevalt arenduse käigus, eriti niipea, kui on implementeeritud uus mehaanika ja sageli tehakse seda ka implementatsiooni käigus sammhaaval, et vältida olukorda kus implementeeritud süsteem ei tööta nagu ette nähtud ning jääb avastamata täpne moment kus implementatsioon on ebaõnnestunud.

Testimisel on mõttekas eraldada teste mängija kogemuse parandamiseks ja mängu funktsionaalsuse tagamiseks. Esimene prioriteet peaks olema pea alati mängu funktsionaalsuse tagamine ja järgnev testimine, kui see on tagatud testimisel positiivsete tulemustega, peaks keskenduma mängija kogemuse parandamiseks. Mängija kogemus seisneb selles, mis on mängijate subjektiivne arvamus, kuidas mäng töötab, st. kas mingi osa mängust on frustreeriv, kas sisendite andmine on kohmakas või kas mängureeglid tunduvad õiglased või ebaausad. Selle käigus toimub tavaliselt palju muudatusi peenhäälestuste näol mängu põhimehaanikate osas ning mängijale esitatava informatsiooni osas kasutajaliidese abil.

Lõppkokkuvõttes on testimise eesmärk valideerida esiteks, kas mäng töötab nii, nagu disainitud ja teiseks, kas mängu on lõbus mängida. Kui testimise käigus selgub, et kas mäng ei tööta nii nagu ette nähtud või ei täida oma eesmärki mängija lõbustamiseks, on vaja võtta samm tagasi ning naasta disaini ja/või implementatsiooni itereerimise juurde. See tähendab, koguda kokku testimisel kogutud materjal, seda analüüsida ja muuta selle uue informatsiooniga mängu disaini ja/või implementatsiooni.

Iteratiivset arendust võib vaadelda kui omaette mängu - mängureegleid välja kujundades ja sellele vastavaid koodijuppe kirjutades selgub, mida saab paremini teha ja seeläbi omaenda oskusi mänguloojana parendada. Selle protsessi käigus selgub ka rohkem, mis ideed sobivad mängu visiooni ning just nendele ideedele keskenduda, mis pakuvad mängijale rahuldavat kogemust. Ideed, mis tunduvad mängijatele kohmakad või frustreerivad tuleb muuta või disainist ja implementatsioonist eemaldada. Seda protsessi nimetatakse viimistlemiseks (polishing) ja selle eesmärk on jätta mängijatele võimalikult hea mulje mängust.

Viimistleda saab mänge jällegi mitmel eri viisil ja üldjuhul see jääb põhiliste mängumehaanikate, visuaalide ja kasutajaliidese/sisendi töötlemise valda. On tavaline, et alles viimistluse faasis jõutakse selleni, et mäng on tõesti nauditav ning pakub mängijatele head meelelahutust. Mänguarendusringkondades sageli jagatakse anekdooti, et esimese 90% mängu loomisest võtab sama palju aega kui viimase 10% loomine ning seda just viimistlemise pärast. Eelkõige keskendutakse selles faasis tugevale iteratiivsele protsessile, kus tehakse järjest väiksemaid muutusi, et tulemus oleks mängijale võimalikult sujuv, koherentne ja stabiilne.