Prototyyppaus eli prototyypin rakentaminen on tehokas ja toimiva tapa testata erilaisia ideoita ja iteroida niitä paremmiksi. Tyypillisesti prototyypillä pyritään kokeilemaan jotain selkeää osakokonaisuutta, ei koko tuotetta. Näitä osa-alueita voivat olla esimerkiksi käyttöliittymään liittyvät seikat, liikkumisen luontevuus tai erilaiset tavat esittää tilastodataa.
Prototyyppi voi periaatteessa toimia alustana varsinaiselle tuotteelle. Usein prototyypit pidetään kuitenkin erillisinä tuotantoina, joiden koodia ei sellaisenaan käytetä varsinaisessa tuotteessa. Tällä mahdollistetaan nopea ja "sotkuinen" prototyyppaus, jossa ei tarvitse keskittyä koodin tai muun tuotannon kauneuteen tai rakenteeseen, vaan pyritään ratkaisemaan se ongelma, jonka tutkimiseen prototyyppi on rakennettu. Toisinaan näistä irrallisista, nopeista prototyypeistä käytetään myös nimitystä spike.
Analogi, digitaali, simulaati
Protoilua voidaan suorittaa useilla eri tavoilla, joista protoilijoiden täytyy löytää tilanteeseen sopivin menetelmä. Mikäli tutkitaan esimerkiksi strategiapelin osumatodennäköisyyksiä tai kykyjen tasapainotusta, saattaa taulukkolaskentaohjelmalla toteutettu laskukaavasto ja taulukosto olla paras metodi. Tosiaikaisten pelien ohjaustuntumaa protoillessa tarvitaan toimivaa digitaalista prototyyppiä. Käyttöliittymien testaamiseen voi käyttää esimerkiksi Wizard of Oz -menetelmää tai paperiprotoilua, joka toimii mainiosti myös vuoropohjaisten pelien mekaniikan testaamiseen. Flashilla tai muilla vastaavilla nopean kehityksen välineillä voi kätevästi testailla tavallista monipuolisempia interaktiomalleja ja käyttöliittymäkomponentteja.
Välineen valinnassa kannattaa käyttää harkintaa. Paperiproto on nopea tehdä ja muutella, mutta sen rajat tulevat nopeasti vastaan. Digitaalisen prototyypin tekeminen saattaa viedä päiviä, eikä sen muuntelu ole välttämättä kovin nopeaa. Taulukkolaskentaohjelmalla on kömpelö kokeilla muuttuvia käyttöliittymiä. Tärkeintä menetelmän valinnassa on käyttää sitä välinettä, jolla nopeimmin pystyy toteuttamaan halutut toiminnot. Mikäli prototypointi sisältää paljon muuttujien säätämistä, kannattaa säätimet tuoda käyttäjien näkyville, jotta virittely käy nopeasti ja tehokkaasti. Esimerkiksi autopelin kitkan, ohjausnopeuden ja kiihtyvyyden säätäminen hauskalle tasolle vaatii paljon hienosäätöä, joten numeroarvoja on hyvä päästä muuttelemaan "lennosta".
Protokieriö
Protoilu pyörii suunnittelun, toteutuksen, käytön ja evaluoinnin muodostamaa kehää. Tyypillisesti kehää kierretään muutamia iteroivia kierroksia. Kolmen - neljän parannetun version jälkeen prototyypin jatkokehityksellä ei yleensä saavuteta kustannuksia vastaavia parannuksia, joten jatkaminen on epätaloudellista ja turhaa. Jokainen protokieriön osa-alueesta on syytä suorittaa huolella ja ajatuksen kanssa.
Suunnitteluvaiheessa mietitään, mikä osa-alue tarvitsee kokeilua. Ehkäpä jostain kontrollimekanismista tai näkymästä on olemassa useampia kilpailevia vaihtoehtoja, joiden paremmuusjärjestystä ei pysty suoralta kädeltä näkemään. Kenties jollakulla on käyttöliittymää varten vallankumouksellinen idea, joka kuitenkin sotii totuttuja käytäntöjä (konventioita) vastaan. Oleellista on hahmottaa ja määritellä mitä halutaan tutkia ja minkälaisia lopputuloksia odotetaan. Tämä ei tarkoita sitä, että pitäisi tietää heti alussa, mikä menee pieleen ja mikä toimii, vaan sitä, että jos tutkitaan esimerkiksi valikkorakenteen toimivuutta, tuloksena ei voi olla asiasisältöjen muotoilun muuttaminen.
Toteutusvaiheessa on tarkoituksena jollain metodilla (paperiprotona, Flash-koodina tms) toteuttaa oikeasti käytettävä versio tarkastelun alla olevasta osasta. Yleensä tarkoituksena on kokeilla osa-alueen toimivuutta, joten toteutuksessa kannattaa keskittyä toiminnallisuuksiin ulkoasun sijaan. On tietenkin tilanteita, jolloin täytyy kokeilla esimerkiksi fonttien näkyvyyttä tai värien käyttöä, mutta niissäkin pätee sama periaate: mahdollisimman nopeasti riittävän toimiva versio, jota hypistelemällä on mahdollisuus saada käsitys toiminnasta tai ulkoasusta.
Käyttövaiheessa prototyyppiä testataan. Tämä on osittain hyvin läheistä sukua käyttäjätestaukselle ja samoja metodeja voidaan hyödyntää. Mikäli protoillaan käyttöliittymää tai pelifiilistä, "flowta", voi olla hyödyllistä videoida tai muuten tallentaa protoilutilanteet. Tällöin on myös hyvä käyttää tekijäryhmän ulkopuolisia henkilöitä testauksessa. Lähes aina nämä ulkopuoliset testaajat onnistuvat löytämään prototyypistä tai toiminnoista joitain sellaisia puolia, joita asiaan perehtyneet tekijät eivät ole havainneet. Tilastollista arviointia varten annetaan esimerkiksi taistelusimulaation pyöriä satoja tai tuhansia kierroksia, joiden tulokset tallennetaan myöhempää analyysiä varten. Mitä tahansa menetelmää käytetäänkin, käyttövaiheesta tulisi jäädä jonkinlaisia muistiinpanoja tai tuloksia, joita voidaan evaluoida seuraavassa vaiheessa. Käyttövaihe voidaan myös lopettaa kesken, mikäli prototyypin toiminnassa havaitaan selkeästi fataali virhe, joka käytännössä tekee koko muun testaamisen turhaksi. Tällöin tuo virhe on korjattava ennen kuin käyttöä kannattaa jatkaa.
Evaluointi- eli arviointivaihe koittaa, kun prototyyppi on toteutettu ja sitä on käytetty riittävän paljon, että käsillä on jonkinlaisia tuloksia. Evaluointivaiheessa käydään läpi käyttövaiheessa kertyneet kokemukset ja tulokset ja verrataan niitä haluttuihin lopputuloksiin. Mikäli käytön aikana prototyypistä löytyi selkeitä parannustarpeita, ne huomioidaan. Tilastollisen simulaation ollessa kyseessä tarkastellaan tuloksia, joista saattaa paljastua esimerkiksi epätasapainossa olevia mekaniikkoja tai liian suuren painoarvon saavia nopanheittoja. Evaluoinnin tuloksena on lista asioista, jotka kaipaavat muutosta tai parannusta. Tämän listan kanssa voidaankin sitten pyörähtää protokieriön seuraavaan vaiheeseen, eli takaisin suunnitteluun, jossa mietitään ratkaisuja käytön ja evaluoinnin aikana löytyneisiin ongelmakohtiin.
Protoilun ajoitus
Toisinaan protoilu pyritään aloittamaan mahdollisimman aikaisessa vaiheessa, heti ensimmäisen idean synnyttyä. Tällöin protoilu toimii myös brainstormauksen välineenä. Oleellista on pitää kehityssykli mahdollisimman nopeana. Protoilu on usein ennemminkin kvantitatiivista kuin kvalitatiivista, eli kokeilujen määrä on tärkeämpää kuin niiden laatu. Tämä siksi, että toisinaan määrä johtaa laatuun, eli todennäköisyys hittituotteen tai loistavan ratkaisun löytymiseen kasvaa, mikäli pohjamateriaali (tässä tapauksessa proton iteraatiot ja versiot) on tarpeeksi laaja. Mikäli kyseessä on kehitysryhmän oma sisäinen testi, kannattaa muutokset protoon tehdä heti, kun niiden tarve huomataan. Näin päästään kokeilemaan uusia versioita heti, eikä vasta suunnitellun testin täytyttyä.
Kaikkia ominaisuuksia ei tietenkään voida protoilla heti projektin alussa. Usein esimerkiksi käyttöliittymäsuunnittelu seuraa vasta myöhäisemmässä vaiheessa projektia, kun kaikki halutut ominaisuudet ja toiminnot on saatu selville. Tällöin on mahdollista käyttää jo tuotettua materiaalia protoilun alustana. Esimerkiksi strategiapelin käyttöliittymän protoilussa kannattaa käyttää alustana aiemmin tehtyä peliengineä. Aito ympäristö on aina parempi alusta protoilulle kuin mock-up näkymät tai paperiprotot. Kustannustehokkuus täytyy kuitenkin pitää mielessä, eikä ole välttämättä mielekästä toteuttaa täydellistä käyttöliittymäprototyyppiä vain testiä varten. Ennemminkin kannattaa kokeilla yksi kerrallaan itsenäisiä osa-alueita, kuten protoillessa yleensäkin. Käytettäessä rinnakkain uutta ja vanhaa versiota voidaan helposti todeta uudemman version mahdolliset edut ja puutteet aiempaan verrattuna.
Seuraavassa vielä lista metodeista ja avainsanoista, joiden avulla löytyy protoilumetodeja ja muita aiheeseen liittyviä asioita:
- Wizard of Oz
- Paper prototyping
- Design probes
- Adobe Flash
- Spreadsheet simulation
- Jacob Nielsen: Usability Engineering
- http://www.usabilitybok.org/methods
torstai 14. huhtikuuta 2011
tiistai 5. huhtikuuta 2011
Pelisuunnittelun jakomielisyys
Pelisuunnittelija on ehkä pelimaailman vaikeimmin määriteltäviä tehtävänimikkeitä. Tyypillisesti pelisuunnittelija on se, joka kehittelee pelin mekaniikat ja keksii säännöt. Yleensä tämä ei kuitenkaan riitä, sillä vain harvassa yrityksessä on varaa maksaa palkkaa ihmiselle, joka keskittyy pelkästään pelimekaniikan hiontaan.
Tyypillisesti pelejä kehitetään mekaniikka edellä. Ideointivaiheessa on kyllä tyypillistä, että peli saa alkunsa esimerkiksi mielenkiintoisesta hahmosta, maailman skenaariosta tai jostain muusta lähtökohdasta. Mutta uskaltaisin väittää, että aina tämän jälkeen siirrytään kehittämään mekaniikkaa. Pelit ovat interaktiivisia teoksia ja ilman interaktiota, sääntöjä ja pelimekaniikan ja moottorin muodostamaa dynamiikkaa ei ole pelejä. Siksi pelimekaniikan ja sääntöjen ymmärtäminen ovat jokaisen pelisuunnittelijan perustyökalut. Näitä taitoja voi hioa esimerkiksi Brathwaiten ja Schreiberin erinomaisen Challenges for Game Designers -kirjan harjoituksiin paneutumalla. Aiheesta löytyy lukuisia muitakin kirjoja, esimerkiksi Rousen Game Design: Theory and Practice lienee alan perusteoksia. Oleellisinta on kuitenkin suunnitella itse ja paljon.
Ydintoimintansa ohella pelisuunnittelijat joutuvat / pääsevät tekemään myös lukuisia muita, aihetta sivuavia tehtäviä. Koska suunnittelijalla ainakin pitäisi olla kattavin käsitys kulloinkin tekeillä olevasta pelistä, on hän tietyllä tavalla koko pelituotannon keskiössä. Hänen täytyy pystyä antamaan tukensa ja selittämään peliin liittyviä asioita minkä tahansa osaston ihmisille. Kaikessa ei tietenkään voi olla ammattilainen, mutta kaikkea tulisi ymmärtää ainakin jotenkin.
Ohjelmointi
Brenda Brathwaithe julkaisi blogissaan erinomaisen kirjoituksen koodaamisen merkityksestä pelisuunnittelijoille. Kuten asiaan kuuluu, Brenda kärjistää sanomaansa. Mutta olen samaa mieltä siinä, että jokaisen suunnittelijan kuuluisi osata palanen ohjelmointia. Pelien säännöt ovat loogisia rakenteita, jotka ainakin digitaalisten pelien tapauksessa on automatisoitu koneen hallintaan. Ohjelmoiva suunnittelija voi itse rakentaa peleistään prototyyppejä ja kokeilla erilaisia mekaniikkoja ilman, että tarvitsee pyytää kiireisiä pelikoodaajia apuun. Protoillessa kaiken ei tarvitse mennä ihan oppikirjan mukaan paketeihin ja luokkiin, oleellista on päästä ihan omin käsin oikeasti kokeilemaan asioita, joita ollaan tekemässä.
Protoilun lisäksi ohjelmoinnin harjoittelusta on hyötyä myös logiikkalihaksen harjoittajana. Kun hallitsee ohjelmoinnin perusrakenteet ja ymmärtää silmukoiden ja ehtolauseiden merkityksen, voi näitä taitoja hyödyntää myös suunnitelmia tehdessään. Osittain saman asian ajaa myös matemaattisen logiikan ja Boolen algebran hallitseminen, mutta ohjelmoinnista saatava hyöty on paljon laajempaa. Ohjelmoidessa asiat täytyy purkaa atomeiksi, jotka asetetaan suoritusjonoon yksi kerrallaan toteutettaviksi. Myös pelin säännöt täytyy purkaa atomeiksi ja järjestää jonoon ajatuksen kanssa, koska järjestyksellä on toisinaan valtavan suuri merkitys.
3D-mallinnus ja grafiikka
Tunnen monia pelisuunnittelijoita, joiden tausta on ennemminkin graafisella kuin teknisellä puolella. Myös tältä pohjalta voi hyvin ponnistaa, sillä hieman pelityypistä riippuen maailman ja hahmojen suunnittelu on keskeinen osa pelin suunnittelua ja usein pelimekaniikka ja graafinen tuotanto vaikuttavat toisiinsa lähes yhtä paljon kuin suunnittelu ja ohjelmointi. Niputan tässä yhteydessä graafisen suunnittelun alle myös maailman luomisen, kenttäsuunnittelun, hahmojen tekemisen yms asiat, jotka mielellään ottaisivat oman, laajemman tilansa.
Kun suunnittelija pystyy itse tekemään ainakin prototyypit kentistä, voi hän kehittää maailmaa itsenäisesti ja kokeilla pelimoottorin rajoituksia ja mahdollisuuksia. Tässä on tietysti hyötyä myös arkkitehtuurin ja designin tuntemisesta. Esimerkiksi Alan Waken maailma perustuu puhtaasti todellisuuteen ja mielikuvitukselliset tai mahdottomat rakennukset rikkoisivat pelaajan illuusion ja immersion.
Mallintamisen kautta suunnittelijalle rakentuu käsitys maailmojen mittasuhteista ja tilojen avaruudesta. Yleensä peleihin mallinnetut tilat ovat huomattavasti paljon suurempia ja avarampia kuin reaalimaailman vastaavat. Syitä on monia, mutta ainakin venkuloivat kamerat ja kankeat kontrollit pakottavat suunnittelijat antamaan hahmoille lisää tilaa jotta pelikokemus pystyisi sujuvana. Sama pätee myös tasohyppelyihin ja 2D-kartalla tapahtuvaan toimintaan.
Suunnittelu, grafiikka ja ohjelmointi muodostavat pyhän kolmiyhteyden, joka mahdollistaa ainakin jonkin sortin pelituotannon. Jos suunnittelija hallitsee nämä kolme osa-aluetta ainakin välttävästi, voi hän toimia täysin itsenäisesti ja tuottaa pikkukivaa pelattavaa esim Kongregateen, mistä kuulemma joku on joskus saanut jopa rahaa. Äänet olisivat tietenkin bonus, mutta ilmankin tulee joten kuten toimeen.
Käyttöliittymäsuunnittelu
Käyttöliittymä- ja käytettävyyssuunnittelu mielletään hyvin usein myös pelialan ulkopuolella osaksi graafista suunnittelua. Käyttöliittymäsuunnittelijan oletetaan olevan kultasilmäinen graafikko, vaikka oikeasti hän on lähempänä psykologia, jonka alaa pelisuunnittelijan olisi myös mainota tuntea. Varsin usein hän on myös pelisuunnittelija.
Käyttöliittymän suunnittelu on pelisuunnittelijalle hyvin luontainen rooli. Pelisuunnittelijan tehtävänä on yrittää ymmärtää pelaajaa ja luoda hänelle mahdollisimman antoisa pelikokemus hioen pelijalokivestä pois repivimmät särmät. Käyttöliittymäsuunnittelijan tehtävän on yrittää ymmärtää käyttäjää ja pyrkiä antamaan hänelle mahdollisimman intuitiivinen ja läpinäkyvä rajapinta omien mahdollisuuksiensa ja järjestelmän toiminnan väliin. Nehän ovat kuin kaksi marjaa!
Fiiliksellä ja mutulla pääsee johonkin saakka - kuten suunnilleen kaikessa, mutta työkaluista on aina hyötyä. Persoonallisuustyyppien, tarvehierarkioiden ja kognitiotieteellisten teorioiden lisäksi olisi kiva saada jotain käytännönläheisempää. Onneksi käytettävyystieteilijöiden guru, sittemmin hieman huru Jakob Nielsen on kasannut näppärän listan käytettävyyden heuristiikoista. Hyvä lähtökohta ja Nielsenillä on muutenkin hyviä juttuja, mutta kannattaa suhtautua kriittisesti ja miettiä myös omilla aivoilla. Toinen erinomainen ymmärrystä lisäävä kirjailija on Donald Norman, jonka Design of Everyday Things on ehdottoman hyvä opus pelisuunnittelijoille, eikä Emotional Designkään ole ainakaan huono.
Matematiikka ja fysiikka
Sivusinkin matematiikkaa aiemmin koodauksen tienoilla. On äärimmäisen tärkeää, että pelisuunnittelija ymmärtää ainakin perusasiat todennäköisyyksistä, vektoreista ja erilaisista voimista. Fysiikkaan perustuvat pelit ovat olleet kovassa nosteessa etenkin indie-kehittäjien keskuudessa. Ennakoimattoman matematiikalla saa aikaan emergenttiä pelaamista, jonka parissa viihtyvät kaikki vauvasta vaariin, kuten Angry Birds on osoittanut. Nopeusvektorit ja kiihtyvyydet tulevat vastaan kaikessa missä jokin liikkuu tosiaikaisesti. Massa, inertia, kitka, kimmoisuus... koodaajien hommaa, mutta helpottaa huomattavasti, jos myös suunnittelija ymmärtää kyseiset asiat.
Todennäköisyyslaskennan ymmärtäminen on kenties pelisuunnittelun keskeisimpiä taitoja. Jos pelissä on mitään satunnaisuutta, tulee suunnittelijan pystyä myös laskemaan erilaisten kombinaatioiden vaikutuksia. Nopanheitot ja korttipakan rakentaminen ovat perussettiä, joiden päälle voidaan rakentaa paljon erilaisia pelillisiä elementtejä. Strategiapeleissä pelaajalle kerrotaan todennäköisyyksiä vihollisarmeijan lyömiseen. Räiskinnöissä ammusten hajaantumista voidaan mallintaa tilastollisesti. Facebookin Castle Agessa rahalla ostettavan arkun sisältöjen todennäköisyydet ilmoitetaan prosentteina.
Todennäköisyyslaskennan rinnalla kulkee sujuvasti tilastotiede. Pelien muuttuessa tuotteista palveluiksi (lisää aiheesta Tampereen yliopiston tutkimuksessa) pelifirmojen toimintatavat muuttuvat intuitiivisista mutu-metodeista laskennallisempaan suuntaan. Sosiaalisia pelejä tuottavien firmojen rekry-ilmoituksissa pelisuunnittelijalta vaaditaan kykyä ymmärtää pelaajien tuottamaa pelidataa ja muokata peliä sen perusteella. Verkottuneessa maailmassa myös muut keräävät enenevissä määrin dataa pelaajien käyttäytymisestä, koska datan perusteella voidaan helposti nähdä, mitkä ovat pelin kannalta tärkeitä ominaisuuksia, missä pelaajat turhautuvat jne.
Tarinankerronta
Suurimmassa osassa peleistä on jokin juoni tai taustatarina. Usein tarinaa kerrotaan vain kenttien välinäytöksissä, toisinaan tarina jää täysin pelimekaniikan ja suorittamisen taustalle. Näissäkin tapauksissa joku on kirjoittanut tarinan, suunnitellut välinäytökset ja tehnyt dialogit. Ohutkin tarina kannattaa kirjoittaa huolella. "All your base are belong to us" on hauskasti cämppiä, mutta ei siitä kovin laadukasta kuvaa jää. Kaahailuun keskittyvässä Flat Out -sarjassa tarina on äärimmäisen ohut, mutta pelissä on kuitenkin panostettu jonkin verran myös tähän puoleen. Kaikille kilpakumppaneille on annettu nimet ja kasvot, sekä jonkinlainen luonne. Peli itsessään on klassinen kasvukertomus sorakuoppien sankarista valtateiden valtiaaksi ja ovaalien omistajaksi.
Tarinankerronta on muutakin kuin pelihahmojen vuorosanoja ja tapahtumia. Alan Waken käsikirjoittajana toiminut Mikko Rautalahti kertoi Taikissa pitämällään luennolla tarinasuunnittelun olevan pelin ydinsuunnittelua. Tarinavetoisissa peleissä tarina täytyy kutoa pelimekaniikkoihin, hahmosuunnitteluun, kenttädesigniin jne. Hahmojen luonne määrittää sen, kuinka ne animoidaan ja mitä niillä pelatessa tehdään. Bioshockissa ja Alan Wakessa on lukuisia esimerkkejä siitä, kuinka tarinaa kerrotaan pelkällä kenttäsuunnittelulla. Huoneen nurkkaan sijoitettu ruumis haulikko sylissään, ympärillään erilaisia kemiallisia substansseja kertoo enemmän kuin tuhat sanaa tekstuaalista dialogia.
Yleisen keskustelun perusteella voisi kuvitella pelikirjoittajien olevan kaikkitietäviä yläastelaisia, jotka innokkaina suoltavat pihalle kaiken populaarikulttuurista oppimansa: näppäriä sanaleikkejä Liftari-trilogiasta, eeppisiä vuorosanoja Sormusten Herrasta, macho-bullshittiä mistä tahansa Hollywood-toimintaleffasta. Kriitikot, akateemikot ja jopa osa pelaajista huutaa hyvien käsikirjoitusten perään. Tiedän, että monet käsikirjoittajat ovat todella sivistyneitä ja tuntevat Runousoppinsa ja Robert McKeensä kuin omat taskunsa. Miksi hitossa sitten joudumme nielemään järkyttäviä kasoja kuluneita kliseitä, yhä uudelleen kerrottuja pikkumiehestä maailmanpelastajaksi -tarinoita ja päättömiä, heikosti motivoituja kostotarinoita.
Tyhjästä on paha ammentaa. Tove Idströmin sanoja mukaillen: kirjoittaessasi sinulla täytyy olla järvellinen materiaalia, josta voit poimia sen kupillisen, jonka tarvitset. Pelkkä pelisivistys ei auta kehittämään alaa eteenpäin, eikä tee suunnittelijasta hyvää. Tarvitaan myös kokemusta muusta viihteestä, sekä myöskin taiteesta. Ranskan uuden aallon elokuvista voi saada paljon ideoita, joita pelimaailman tarinoissa ei olla vielä nähty. Italo Calvino pukee sanoiksi paljon, asioita, joista ei voi tehdä elokuvia. Einstürzende Neubautenin musiikissa on jotain sellaista repivyyttä, mitä purkkapop-kansa ei pysty kehittämään. Näkymät, kuulopuheet, tarinat, tunnetilat, kaikki ovat tarinankertomisen materiaalia. Eikä Huuliharppukostajan katsomisesta analyyttisellä silmällä ole haittaa myöskään pelin rytmin, kuvakulmien, leikkauksen jne. kannalta.
Tyypillisesti pelejä kehitetään mekaniikka edellä. Ideointivaiheessa on kyllä tyypillistä, että peli saa alkunsa esimerkiksi mielenkiintoisesta hahmosta, maailman skenaariosta tai jostain muusta lähtökohdasta. Mutta uskaltaisin väittää, että aina tämän jälkeen siirrytään kehittämään mekaniikkaa. Pelit ovat interaktiivisia teoksia ja ilman interaktiota, sääntöjä ja pelimekaniikan ja moottorin muodostamaa dynamiikkaa ei ole pelejä. Siksi pelimekaniikan ja sääntöjen ymmärtäminen ovat jokaisen pelisuunnittelijan perustyökalut. Näitä taitoja voi hioa esimerkiksi Brathwaiten ja Schreiberin erinomaisen Challenges for Game Designers -kirjan harjoituksiin paneutumalla. Aiheesta löytyy lukuisia muitakin kirjoja, esimerkiksi Rousen Game Design: Theory and Practice lienee alan perusteoksia. Oleellisinta on kuitenkin suunnitella itse ja paljon.
Ydintoimintansa ohella pelisuunnittelijat joutuvat / pääsevät tekemään myös lukuisia muita, aihetta sivuavia tehtäviä. Koska suunnittelijalla ainakin pitäisi olla kattavin käsitys kulloinkin tekeillä olevasta pelistä, on hän tietyllä tavalla koko pelituotannon keskiössä. Hänen täytyy pystyä antamaan tukensa ja selittämään peliin liittyviä asioita minkä tahansa osaston ihmisille. Kaikessa ei tietenkään voi olla ammattilainen, mutta kaikkea tulisi ymmärtää ainakin jotenkin.
Ohjelmointi
Brenda Brathwaithe julkaisi blogissaan erinomaisen kirjoituksen koodaamisen merkityksestä pelisuunnittelijoille. Kuten asiaan kuuluu, Brenda kärjistää sanomaansa. Mutta olen samaa mieltä siinä, että jokaisen suunnittelijan kuuluisi osata palanen ohjelmointia. Pelien säännöt ovat loogisia rakenteita, jotka ainakin digitaalisten pelien tapauksessa on automatisoitu koneen hallintaan. Ohjelmoiva suunnittelija voi itse rakentaa peleistään prototyyppejä ja kokeilla erilaisia mekaniikkoja ilman, että tarvitsee pyytää kiireisiä pelikoodaajia apuun. Protoillessa kaiken ei tarvitse mennä ihan oppikirjan mukaan paketeihin ja luokkiin, oleellista on päästä ihan omin käsin oikeasti kokeilemaan asioita, joita ollaan tekemässä.
Protoilun lisäksi ohjelmoinnin harjoittelusta on hyötyä myös logiikkalihaksen harjoittajana. Kun hallitsee ohjelmoinnin perusrakenteet ja ymmärtää silmukoiden ja ehtolauseiden merkityksen, voi näitä taitoja hyödyntää myös suunnitelmia tehdessään. Osittain saman asian ajaa myös matemaattisen logiikan ja Boolen algebran hallitseminen, mutta ohjelmoinnista saatava hyöty on paljon laajempaa. Ohjelmoidessa asiat täytyy purkaa atomeiksi, jotka asetetaan suoritusjonoon yksi kerrallaan toteutettaviksi. Myös pelin säännöt täytyy purkaa atomeiksi ja järjestää jonoon ajatuksen kanssa, koska järjestyksellä on toisinaan valtavan suuri merkitys.
3D-mallinnus ja grafiikka
Tunnen monia pelisuunnittelijoita, joiden tausta on ennemminkin graafisella kuin teknisellä puolella. Myös tältä pohjalta voi hyvin ponnistaa, sillä hieman pelityypistä riippuen maailman ja hahmojen suunnittelu on keskeinen osa pelin suunnittelua ja usein pelimekaniikka ja graafinen tuotanto vaikuttavat toisiinsa lähes yhtä paljon kuin suunnittelu ja ohjelmointi. Niputan tässä yhteydessä graafisen suunnittelun alle myös maailman luomisen, kenttäsuunnittelun, hahmojen tekemisen yms asiat, jotka mielellään ottaisivat oman, laajemman tilansa.
Kun suunnittelija pystyy itse tekemään ainakin prototyypit kentistä, voi hän kehittää maailmaa itsenäisesti ja kokeilla pelimoottorin rajoituksia ja mahdollisuuksia. Tässä on tietysti hyötyä myös arkkitehtuurin ja designin tuntemisesta. Esimerkiksi Alan Waken maailma perustuu puhtaasti todellisuuteen ja mielikuvitukselliset tai mahdottomat rakennukset rikkoisivat pelaajan illuusion ja immersion.
Mallintamisen kautta suunnittelijalle rakentuu käsitys maailmojen mittasuhteista ja tilojen avaruudesta. Yleensä peleihin mallinnetut tilat ovat huomattavasti paljon suurempia ja avarampia kuin reaalimaailman vastaavat. Syitä on monia, mutta ainakin venkuloivat kamerat ja kankeat kontrollit pakottavat suunnittelijat antamaan hahmoille lisää tilaa jotta pelikokemus pystyisi sujuvana. Sama pätee myös tasohyppelyihin ja 2D-kartalla tapahtuvaan toimintaan.
Suunnittelu, grafiikka ja ohjelmointi muodostavat pyhän kolmiyhteyden, joka mahdollistaa ainakin jonkin sortin pelituotannon. Jos suunnittelija hallitsee nämä kolme osa-aluetta ainakin välttävästi, voi hän toimia täysin itsenäisesti ja tuottaa pikkukivaa pelattavaa esim Kongregateen, mistä kuulemma joku on joskus saanut jopa rahaa. Äänet olisivat tietenkin bonus, mutta ilmankin tulee joten kuten toimeen.
Käyttöliittymäsuunnittelu
Käyttöliittymä- ja käytettävyyssuunnittelu mielletään hyvin usein myös pelialan ulkopuolella osaksi graafista suunnittelua. Käyttöliittymäsuunnittelijan oletetaan olevan kultasilmäinen graafikko, vaikka oikeasti hän on lähempänä psykologia, jonka alaa pelisuunnittelijan olisi myös mainota tuntea. Varsin usein hän on myös pelisuunnittelija.
Käyttöliittymän suunnittelu on pelisuunnittelijalle hyvin luontainen rooli. Pelisuunnittelijan tehtävänä on yrittää ymmärtää pelaajaa ja luoda hänelle mahdollisimman antoisa pelikokemus hioen pelijalokivestä pois repivimmät särmät. Käyttöliittymäsuunnittelijan tehtävän on yrittää ymmärtää käyttäjää ja pyrkiä antamaan hänelle mahdollisimman intuitiivinen ja läpinäkyvä rajapinta omien mahdollisuuksiensa ja järjestelmän toiminnan väliin. Nehän ovat kuin kaksi marjaa!
Fiiliksellä ja mutulla pääsee johonkin saakka - kuten suunnilleen kaikessa, mutta työkaluista on aina hyötyä. Persoonallisuustyyppien, tarvehierarkioiden ja kognitiotieteellisten teorioiden lisäksi olisi kiva saada jotain käytännönläheisempää. Onneksi käytettävyystieteilijöiden guru, sittemmin hieman huru Jakob Nielsen on kasannut näppärän listan käytettävyyden heuristiikoista. Hyvä lähtökohta ja Nielsenillä on muutenkin hyviä juttuja, mutta kannattaa suhtautua kriittisesti ja miettiä myös omilla aivoilla. Toinen erinomainen ymmärrystä lisäävä kirjailija on Donald Norman, jonka Design of Everyday Things on ehdottoman hyvä opus pelisuunnittelijoille, eikä Emotional Designkään ole ainakaan huono.
Matematiikka ja fysiikka
Sivusinkin matematiikkaa aiemmin koodauksen tienoilla. On äärimmäisen tärkeää, että pelisuunnittelija ymmärtää ainakin perusasiat todennäköisyyksistä, vektoreista ja erilaisista voimista. Fysiikkaan perustuvat pelit ovat olleet kovassa nosteessa etenkin indie-kehittäjien keskuudessa. Ennakoimattoman matematiikalla saa aikaan emergenttiä pelaamista, jonka parissa viihtyvät kaikki vauvasta vaariin, kuten Angry Birds on osoittanut. Nopeusvektorit ja kiihtyvyydet tulevat vastaan kaikessa missä jokin liikkuu tosiaikaisesti. Massa, inertia, kitka, kimmoisuus... koodaajien hommaa, mutta helpottaa huomattavasti, jos myös suunnittelija ymmärtää kyseiset asiat.
Todennäköisyyslaskennan ymmärtäminen on kenties pelisuunnittelun keskeisimpiä taitoja. Jos pelissä on mitään satunnaisuutta, tulee suunnittelijan pystyä myös laskemaan erilaisten kombinaatioiden vaikutuksia. Nopanheitot ja korttipakan rakentaminen ovat perussettiä, joiden päälle voidaan rakentaa paljon erilaisia pelillisiä elementtejä. Strategiapeleissä pelaajalle kerrotaan todennäköisyyksiä vihollisarmeijan lyömiseen. Räiskinnöissä ammusten hajaantumista voidaan mallintaa tilastollisesti. Facebookin Castle Agessa rahalla ostettavan arkun sisältöjen todennäköisyydet ilmoitetaan prosentteina.
Todennäköisyyslaskennan rinnalla kulkee sujuvasti tilastotiede. Pelien muuttuessa tuotteista palveluiksi (lisää aiheesta Tampereen yliopiston tutkimuksessa) pelifirmojen toimintatavat muuttuvat intuitiivisista mutu-metodeista laskennallisempaan suuntaan. Sosiaalisia pelejä tuottavien firmojen rekry-ilmoituksissa pelisuunnittelijalta vaaditaan kykyä ymmärtää pelaajien tuottamaa pelidataa ja muokata peliä sen perusteella. Verkottuneessa maailmassa myös muut keräävät enenevissä määrin dataa pelaajien käyttäytymisestä, koska datan perusteella voidaan helposti nähdä, mitkä ovat pelin kannalta tärkeitä ominaisuuksia, missä pelaajat turhautuvat jne.
Tarinankerronta
Suurimmassa osassa peleistä on jokin juoni tai taustatarina. Usein tarinaa kerrotaan vain kenttien välinäytöksissä, toisinaan tarina jää täysin pelimekaniikan ja suorittamisen taustalle. Näissäkin tapauksissa joku on kirjoittanut tarinan, suunnitellut välinäytökset ja tehnyt dialogit. Ohutkin tarina kannattaa kirjoittaa huolella. "All your base are belong to us" on hauskasti cämppiä, mutta ei siitä kovin laadukasta kuvaa jää. Kaahailuun keskittyvässä Flat Out -sarjassa tarina on äärimmäisen ohut, mutta pelissä on kuitenkin panostettu jonkin verran myös tähän puoleen. Kaikille kilpakumppaneille on annettu nimet ja kasvot, sekä jonkinlainen luonne. Peli itsessään on klassinen kasvukertomus sorakuoppien sankarista valtateiden valtiaaksi ja ovaalien omistajaksi.
Tarinankerronta on muutakin kuin pelihahmojen vuorosanoja ja tapahtumia. Alan Waken käsikirjoittajana toiminut Mikko Rautalahti kertoi Taikissa pitämällään luennolla tarinasuunnittelun olevan pelin ydinsuunnittelua. Tarinavetoisissa peleissä tarina täytyy kutoa pelimekaniikkoihin, hahmosuunnitteluun, kenttädesigniin jne. Hahmojen luonne määrittää sen, kuinka ne animoidaan ja mitä niillä pelatessa tehdään. Bioshockissa ja Alan Wakessa on lukuisia esimerkkejä siitä, kuinka tarinaa kerrotaan pelkällä kenttäsuunnittelulla. Huoneen nurkkaan sijoitettu ruumis haulikko sylissään, ympärillään erilaisia kemiallisia substansseja kertoo enemmän kuin tuhat sanaa tekstuaalista dialogia.
Yleisen keskustelun perusteella voisi kuvitella pelikirjoittajien olevan kaikkitietäviä yläastelaisia, jotka innokkaina suoltavat pihalle kaiken populaarikulttuurista oppimansa: näppäriä sanaleikkejä Liftari-trilogiasta, eeppisiä vuorosanoja Sormusten Herrasta, macho-bullshittiä mistä tahansa Hollywood-toimintaleffasta. Kriitikot, akateemikot ja jopa osa pelaajista huutaa hyvien käsikirjoitusten perään. Tiedän, että monet käsikirjoittajat ovat todella sivistyneitä ja tuntevat Runousoppinsa ja Robert McKeensä kuin omat taskunsa. Miksi hitossa sitten joudumme nielemään järkyttäviä kasoja kuluneita kliseitä, yhä uudelleen kerrottuja pikkumiehestä maailmanpelastajaksi -tarinoita ja päättömiä, heikosti motivoituja kostotarinoita.
Tyhjästä on paha ammentaa. Tove Idströmin sanoja mukaillen: kirjoittaessasi sinulla täytyy olla järvellinen materiaalia, josta voit poimia sen kupillisen, jonka tarvitset. Pelkkä pelisivistys ei auta kehittämään alaa eteenpäin, eikä tee suunnittelijasta hyvää. Tarvitaan myös kokemusta muusta viihteestä, sekä myöskin taiteesta. Ranskan uuden aallon elokuvista voi saada paljon ideoita, joita pelimaailman tarinoissa ei olla vielä nähty. Italo Calvino pukee sanoiksi paljon, asioita, joista ei voi tehdä elokuvia. Einstürzende Neubautenin musiikissa on jotain sellaista repivyyttä, mitä purkkapop-kansa ei pysty kehittämään. Näkymät, kuulopuheet, tarinat, tunnetilat, kaikki ovat tarinankertomisen materiaalia. Eikä Huuliharppukostajan katsomisesta analyyttisellä silmällä ole haittaa myöskään pelin rytmin, kuvakulmien, leikkauksen jne. kannalta.
Tilaa:
Blogitekstit (Atom)