5. 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.