Osastoa
Pelisuunnittelijan työ on pelaajan toiminnan suunnittelemista: mitä pelissä voi tehdä, miksi valinta tuntuu kiinnostavalta ja miten pelaaja ymmärtää tekojensa seuraukset. Hyvä idea on lähtökohta, ei valmis työsuoritus. Suunnittelijan täytyy muuttaa ajatus kokeiltavaksi, huomata sen heikkoudet ja kehittää ratkaisua yhdessä muiden tekijöiden kanssa.
Ammatti kiinnostaa usein paljon pelaavaa ihmistä. Pelaamisesta kertynyt tuntemus auttaa, mutta työssä näkökulma vaihtuu. Oman suosikkipelin puolustamisen sijaan on pystyttävä tutkimaan, miksi jokin ratkaisu toimii tietylle pelaajalle ja miksi toinen ei ymmärrä sitä. Tähän oppaaseen koottu käytännön esimerkki näyttää, miten suunnittelupäätös etenee tavoitteesta prototyyppiin, testiin ja työnäytteeksi. Samalla selviää, millaista osaamista koulutuksessa ja omissa projekteissa kannattaa rakentaa.
Mitä pelisuunnittelija tekee?
Pelisuunnittelija määrittelee pelin sääntöjä, tavoitteita, etenemistä ja vuorovaikutusta. Suunnittelun kohteena voi olla yksi hyppy, kokonainen kenttä, pelaajien välinen resurssijärjestelmä tai tarinan valintatilanne. Työtä yhdistää kysymys siitä, mitä pelaaja tilanteessa havaitsee ja tekee. Näyttävä ympäristö ei yksin ratkaise, löytääkö pelaaja reitin tai ymmärtääkö hän epäonnistumisensa syyn.
Työnimikkeiden rajat vaihtelevat studioittain. Pelimekaniikan suunnittelija keskittyy esimerkiksi liikkumisen ja toiminnan sääntöihin. Kenttäsuunnittelija rakentaa tiloja, reittejä ja haasteiden rytmiä. Järjestelmäsuunnittelija tutkii resurssien, arvojen ja etenemisen suhteita. Narratiivinen suunnittelija yhdistää tarinan tapahtumia pelaajan toimintaan. Käyttökokemuksen suunnittelussa painottuvat puolestaan ymmärrettävyys, käyttöliittymä ja pelaamisen sujuvuus.
Suunnittelija ei automaattisesti ole pelin ohjelmoija, kuvittaja, käsikirjoittaja ja tuottaja samassa henkilössä. Pienessä tiimissä tehtäviä voidaan yhdistää, suuressa tuotannossa vastuu voi rajautua yhteen järjestelmään. Ammatin kannalta olennaista on ymmärtää myös muiden työtä: millainen muutos vaatii uuden animaation, mikä kuormittaa ohjelmointia ja mikä voidaan kokeilla muuttamalla yhtä arvoa?
ScreenSkillsin pelimekaniikan suunnittelijan tehtäväkuvaus korostaa juuri tätä teknisen toteutuksen ja luovan suunnittelun välistä yhteistyötä. Sen brittiläisiä koulutuspolkuja ei silti pidä tulkita Suomen yleisiksi kelpoisuusvaatimuksiksi. Työpaikan todellinen sisältö löytyy nimikkeen lisäksi tehtävistä, tiimin rakenteesta ja odotetusta kokemuksesta.
Suunnittelun lähtökohta on rajattu pelaajakokemus
Idean ensimmäinen kuvaus voi olla laaja: jännittävä tutkimusmatka, rentouttava rakennuspeli tai ystävien yhteinen seikkailu. Tuotannon aloittamiseksi sitä täytyy tarkentaa. Mitä pelaaja tekee toistuvasti? Kuinka pitkään yksi pelikerta kestää? Pelataanko yksin vai yhdessä? Millä laitteella ja millaisessa tilanteessa peliä käytetään? Vastaukset auttavat erottamaan ydintoiminnan kiinnostavista mutta tarpeettomista lisäideoista.
Kohderyhmä ei tarkoita vain ikää. Ensimmäistä kertaa ohjainta käyttävä pelaaja ja saman pelilajin kokenut harrastaja tulkitsevat vihjeitä eri tavoin. Lyhyessä mobiilipelikerrassa keskeytyksen käsittely voi olla tärkeämpi suunnittelukysymys kuin pitkässä rauhallisessa pulmapelissä. Suunnittelijan kannattaa kirjoittaa oletuksensa näkyviin, jotta niitä voi myöhemmin tarkistaa pelaajien kanssa.
Hyödyllinen lähtökuvaus mahtuu usein yhdelle sivulle. Siinä kerrotaan tavoiteltu kokemus, pelaajan ydintoiminta, tärkeimmät rajat ja avoin kysymys. Esimerkiksi ”pelaaja valitsee turvallisen ja riskialttiin reitin välillä” on tutkittavampi tavoite kuin ”pelistä tehdään koukuttava”. Ensimmäinen kuvaus auttaa rakentamaan kokeen. Jälkimmäinen ei vielä kerro, mitä pitäisi toteuttaa tai mistä onnistumisen tunnistaisi.
Käytännön esimerkki: reittipulma paperilla
Kuvitellaan pieni harjoituspeli, jossa pelaaja kuljettaa hahmon lähtöpaikasta ovelle. Oven avaamiseen tarvitaan avain. Lyhyt reitti kulkee vaarallisen ruudun kautta, pidempi reitti on turvallinen. Ensimmäiseen prototyyppiin riittävät paperille piirretyt ruudut, hahmoa esittävä nappula ja avainkortti. Tässä vaiheessa ei tarvita valmista tarinaa, hahmomallia tai musiikkia.
Suunnittelijan kysymys on, syntyykö reittien välille todellinen valinta. Jos lyhyt reitti on sekä nopeampi että aina turvallinen, kiertotie ei tarjoa syytä poiketa suoralta polulta. Jos vaarallisen ruudun seuraus puolestaan paljastuu vasta epäonnistumisen jälkeen, pelaaja voi kokea päätöksen sattumanvaraiseksi. Pulman vaikeus ja sen sääntöjen epäselvyys ovat eri ongelmia.
Ensimmäiseen kokeeseen kannattaa valita vain yksi epävarmuus. Ymmärtääkö pelaaja, että avain täytyy hakea ennen ovelle siirtymistä? Tämän selvittämiseksi ei tarvitse vielä tasapainottaa pisteitä tai rakentaa kymmentä kenttää. Suunnittelija antaa pelaajan kokeilla reittiä ja kirjaa, missä järjestyksessä kohteet huomataan. Jos avain jää järjestelmällisesti huomaamatta, sen paikkaa tai esitystapaa voi muuttaa.
Paperimallilla on myös rajansa. Se sopii sääntöjen, vuorojen ja valintojen kokeilemiseen, mutta ei kerro, miltä hahmon ohjaaminen tuntuu. Jos pelin ydin on ajoituksessa tai liikkeessä, seuraava koe kannattaa tehdä digitaalisena. Prototyypin muoto valitaan siis kysymyksen perusteella, ei siksi, että näyttävämpi versio vaikuttaisi ammattimaisemmalta.
Mitä prototyypistä kirjataan talteen?
Tallenna alkuperäinen sääntö, testissä nähty ongelma, tehty muutos ja seuraavan kokeen tulos. Esimerkin ensimmäisessä versiossa pelaaja voi kulkea suoraan ovelle ymmärtämättä avaimen tehtävää. Toisessa versiossa lukittu ovi antaa selkeän palautteen puuttuvasta avaimesta. Kolmannessa avain sijoitetaan reitin varrelle niin, että pelaaja kohtaa sen ennen ensimmäistä valintaa. Nämä ovat vaihtoehtoisia ratkaisuja, eivät automaattinen kehityslista parhaaseen tulokseen.
Vertailussa voi paljastua, että oven viesti tekee säännön ymmärrettäväksi mutta keskeyttää etenemisen. Avaimen siirtäminen taas voi poistaa koko reittivalinnan. Suunnittelijan tehtävä ei ole vain korjata yhtä havaintoa, vaan tarkistaa, säilyikö kokemuksen tavoite muutoksen jälkeen. Juuri tämän päättelyketjun näyttäminen tekee pienestäkin kokeesta hyödyllisen työnäytteen.
Milloin kokeilu on valmis siirrettäväksi eteenpäin?
Prototyyppiä voi hioa loputtomasti, jos valmistumisen ehtoa ei ole sovittu. Harjoitusprojektissa ehdoksi voi asettaa, että ulkopuolinen pelaaja pystyy aloittamaan, tekemään tarkoitetun valinnan ja päättämään kierroksen ilman tekijän jatkuvaa apua. Tämä ei vielä tarkoita valmista myyntituotetta. Se tarkoittaa, että kokeilun alkuperäiseen kysymykseen on saatu riittävästi tietoa seuraavaa päätöstä varten.
Kirjaa myös, mitä prototyyppi ei tutki. Paperinen reittipulma ei esimerkiksi osoita verkkomoninpelin toimivuutta, ohjaustuntumaa tai kaupallista kiinnostusta. Rajaus auttaa välttämään liian suuria johtopäätöksiä. Seuraava työvaihe voi olla digitaalinen liikkumiskoe, uusi sääntövertailu tai päätös jättää idea sivuun. Myös perusteltu lopettaminen säästää työtä, jos kokeilu osoittaa, ettei suunniteltu valinta synny.
Pelitestaus auttaa erottamaan havainnon tulkinnasta
Kun suunnittelija tuntee pelin säännöt valmiiksi, hän voi huomaamattaan täyttää puuttuvat ohjeet omalla tiedollaan. Uusi pelaaja ei tee näin. Siksi testissä kannattaa seurata ensin toimintaa ja kysyä kokemuksesta sen jälkeen. Jatkuva neuvominen saattaa auttaa pelaajaa eteenpäin, mutta samalla se peittää ongelman, joka pitäisi ratkaista itse pelissä.
Testin tavoite voi olla hyvin rajattu: löytääkö pelaaja avaimen, tunnistaako hän vaarallisen reitin tai ymmärtääkö hän, miksi ovi ei aukea? Kirjaa havainto mahdollisimman konkreettisesti. ”Pelaaja palasi lähtöön kolme kertaa” kertoo enemmän kuin ”pelaaja ei tajunnut peliä”. Vasta tämän jälkeen arvioidaan, liittyikö toiminta vihjeeseen, ohjaukseen, tavoitteeseen vai johonkin muuhun.
Kysymysten muotoilu vaikuttaa vastauksiin. ”Oliko tämä vihje selkeä?” ohjaa arvioimaan suunnittelijan valitsemaa asiaa. ”Mitä odotit tässä tapahtuvan?” antaa tilaa pelaajan omalle tulkinnalle. Pelaajan ehdottamaa ratkaisua ei tarvitse toteuttaa sellaisenaan, mutta ehdotuksen takana oleva tarve kannattaa selvittää. Toive suuremmasta kartasta voi esimerkiksi kertoa eksymisestä eikä lisätilan kaipuusta.
Pieni testiryhmä voi paljastaa käytettävyysongelmia, mutta sen perusteella ei voi luvata kaikkien pelaajien pitävän pelistä. Kirjaa myös osallistujien olennainen tausta: tuntevatko he pelilajin ja ovatko he nähneet aiemman version? Tutun pelaajan sujuva suoritus ei osoita, että uuden pelaajan aloitus toimii. Testihavaintojen arvo kasvaa, kun niiden rajat tunnetaan.
Vika, epäselvyys vai tarkoituksellinen haaste?
Jos toimintopainike ei reagoi, kyse voi olla ohjelmavirheestä. Jos painike toimii mutta sen tarkoitusta ei ymmärretä, ongelma voi olla käyttöliittymässä tai opetuksessa. Jos toiminta ymmärretään mutta ajoitus epäonnistuu, haaste voi kuulua pelin tavoitteeseen. Sama näkyvä lopputulos, kuten pelaajan putoaminen kuiluun, ei siis yksin kerro oikeaa korjausta.
Muuta mieluiten yhtä olennaista asiaa kerrallaan ja säilytä vertailtavat versiot. Jos ohjaus, kamera, kenttä ja palaute muuttuvat yhtä aikaa, onnistuneen tuloksen syytä on vaikea tunnistaa. Käytännön tuotannossa muutoksia ei aina voi erottaa täydellisesti, mutta selkeä muutosloki auttaa tiimiä ymmärtämään, mitä todella kokeiltiin ja mitä seuraavaksi pitää tarkistaa.
Kenttäsuunnittelu opettaa, rytmittää ja yllättää
Kenttä ei ole vain ympäristön pohjapiirros. Se ohjaa huomiota, esittelee toimintoja ja järjestää haasteet mielekkääseen suhteeseen. Reittipulmassa ensimmäinen tila voisi opettaa avaimen ja oven suhteen ilman vaaroja. Seuraavassa tilassa samaa tietoa käytetään kahden reitin vertailuun. Vasta myöhemmin pelaajan täytyy soveltaa opittua uudenlaiseen tilanteeseen.
Opettaminen ei edellytä pitkää tekstiohjetta. Kohteen sijoittelu, liike, ääni tai toiminnasta saatava palaute voivat auttaa pelaajaa huomaamaan säännön. Vihje ei kuitenkaan toimi vain siksi, että suunnittelija tarkoitti sen vihjeeksi. Siksi kenttää kokeillaan myös ilman selittävää tekijää. Jos pelaaja katsoo väärään suuntaan, lisäteksti ei välttämättä korjaa tilan rakennetta.
Haasteen rytmiä voi tarkastella kysymällä, mitä pelaaja tekee juuri ennen vaikeaa kohtaa ja sen jälkeen. Vaativa vaihe voi tarvita rauhallisen valmistautumisen ja ymmärrettävän palautteen. Jos epäonnistuminen pakottaa toistamaan pitkän jo opitun osuuden, turhautuminen voi johtua paluun pituudesta eikä itse haasteesta. Tarkistuspisteen paikka on tällöin osa suunnittelua.
Tarinallinen valinta tarvitsee pelillisen seurauksen
Narratiivinen suunnittelu ei tarkoita vain vuoropuhelun kirjoittamista. Reittipulmaan voisi lisätä tilanteen, jossa pelaaja antaa avaimen toiselle hahmolle ja joutuu etsimään oman ulospääsynsä eri tavalla. Tällöin tarinallinen päätös liittyy suoraan toimintaan. Jos valinta muuttaa vain yhden repliikin mutta peli lupaa suuren seurauksen, pelaajan odotus ja toteutus voivat erota toisistaan.
Suunnittelijan on kuvattava myös vaihtoehtoiset tapahtumajärjestykset. Mitä jos pelaaja ei keskustele hahmon kanssa? Voiko avaimen antaa ennen oven löytämistä? Entä jos tehtävään palataan myöhemmin? Näiden kysymysten ratkaiseminen yhdistää kirjoittamista, sääntöjen suunnittelua ja toteutuksen testaamista. Kaikkea ei tarvitse haarauttaa: joskus yksi tarkasti rakennettu valinta palvelee tarinaa paremmin kuin suuri määrä lähes samanlaisia vaihtoehtoja.
Järjestelmät ja tasapaino: arvot vaikuttavat toisiinsa
Pelissä yksittäisen numeron muuttaminen voi vaikuttaa moniin valintoihin. Jos reittipulman lyhyestä reitistä saa enemmän pisteitä, pelaaja saattaa valita sen aina. Jos epäonnistuminen vie liian paljon jo kerättyä edistymistä, varovainen pelaaminen voi puolestaan syrjäyttää kaiken kokeilun. Tasapaino ei tarkoita, että kaikkien vaihtoehtojen pitäisi olla samanlaisia, vaan että niiden erot tukevat tavoiteltua kokemusta.
Taulukkolaskenta auttaa vertailemaan esimerkiksi kustannuksia, palkintoja ja etenemisnopeuksia. Se ei silti korvaa pelaamista. Paperilla samansuuruinen hyöty voi tuntua pelissä erilaiselta sen mukaan, kuinka nopeasti palaute tulee ja miten helposti pelaaja ymmärtää valinnan. Suunnittelija tarvitsee sekä arvojen tarkastelua että käytännön kokeita.
Ennen lisäsääntöä kannattaa tutkia, ratkaiseeko se ongelman vai peittääkö se aiemman epäselvyyden. Jos jokaiselle poikkeukselle rakennetaan oma sääntö, järjestelmästä voi tulla vaikea oppia ja ylläpitää. Yhden tarpeettoman resurssin poistaminen saattaa selkeyttää peliä enemmän kuin uuden ohjenäkymän lisääminen. Karsiminen on yhtä lailla suunnittelutyötä kuin uusien ominaisuuksien keksiminen.
Työpäivä on yhteistyötä, dokumentointia ja rajauksia
Työpäivä voi alkaa edellisen peliversion kokeilemisella ja jatkua kentän muokkaamisella, suunnitteludokumentin päivittämisellä tai keskustelulla ohjelmoijan kanssa. Toisena päivänä painopiste on testipalautteessa. Prototyypin rakentaminen, tuotanto ja julkaistun pelin ylläpito vaativat erilaisia tehtäviä, joten yhtä kaikille sopivaa päivärytmiä ei ole.
Hyvä suunnittelukuvaus kertoo tavoitteen lisäksi toiminnan rajat. Oven toteutuksessa tarvitaan esimerkiksi tieto siitä, milloin avaaminen on mahdollista, mitä tapahtuu ilman avainta, kulutetaanko avain ja millainen palaute onnistumisesta annetaan. Pelkkä ”lisätään kiinnostava ovimekaniikka” jättää ratkaisevat päätökset muiden arvattaviksi. Selkeä kuvaus vähentää erilaisten oletusten varaan rakentamista.
Dokumentin ei tarvitse olla pitkä. Sen pitää löytyä, vastata nykyistä toteutusta ja erottaa päätetty asia avoimesta kysymyksestä. Kun avaimen käyttö muuttuu, myös asiaan liittyvä tehtäväkuvaus ja testin odotettu tulos päivitetään. Muuten eri tiiminjäsenet voivat korjata peliä keskenään ristiriitaisten ohjeiden mukaan.
Yhteistyössä tulee vastaan myös luopumista. Suosikki-idea voi vaatia enemmän animaatioita tai ohjelmointia kuin aikataulu sallii. Suunnittelija voi ehdottaa pienempää toteutusta, siirtää ominaisuutta tai poistaa sen kokonaan. Perustelun kannattaa liittyä pelaajan kokemukseen ja projektin tavoitteeseen, ei siihen, kuka idean alun perin esitti. Hyvä kompromissi säilyttää olennaisen ilman tarpeetonta tuotantoriskiä.
Työkalut valitaan tehtävän, eivät listan pituuden perusteella
Unity ja Unreal Engine ovat esimerkkejä pelimoottoreista, joilla tehdään prototyyppejä ja pelejä. Suunnittelijan tarvitsema ohjelmointi tai visuaalinen skriptaus riippuu roolista. Tekninen ymmärrys auttaa keskustelemaan toteutuksesta ja rakentamaan kokeiluja, mutta kaikkien suunnittelijoiden ei tarvitse hallita kaikkia ohjelmointikieliä. Aloittelijan kannattaa opetella yksi rajattu työketju kunnolla ennen seuraavan työkalun lisäämistä.
Käyttöliittymiä voi hahmotella Figmassa, visuaalisia ideoita Photoshopissa tai muussa piirtotyökalussa ja pelin arvoja taulukkolaskennassa. Paperi toimii sääntökokeissa. Työnäytteessä ohjelman nimi on silti sivuasia verrattuna siihen, mitä sillä selvitettiin. Pelkkä pitkä ohjelmistoluettelo ei osoita kykyä suunnitella ymmärrettävää toimintaa.
Myös tiedostojen järjestys kuuluu käytännön osaamiseen. Nimeä kokeiluversiot, säilytä toimiva lähtötilanne ja sovi tiimin kanssa, miten muutokset yhdistetään. Jos projekti rikkoutuu, pitäisi pystyä selvittämään, mitä viimeksi muutettiin. Versionhallinnan ja yhteisten työtapojen opettelu tukee yhteistyötä, vaikka harjoituspeli olisi pieni.
Tiimissä kannattaa varmistaa myös, että kaikki testaavat samaa versiota. Muuten jo korjattu ongelma voi palata keskusteluun vanhan tiedoston perusteella. Merkitse testimuistiinpanoon version tunniste ja käytetty laite. Kun havainto voidaan toistaa samoissa olosuhteissa, ohjelmoijan ja suunnittelijan on helpompi erottaa uusi virhe tunnetusta keskeneräisestä ominaisuudesta.
Saavutettavuus erottaa tarkoitetun haasteen turhasta esteestä
Vaikea pulma ja vaikeasti luettava käyttöliittymä eivät ole sama asia. Pelaajan pitäisi voida havaita toiminnan kannalta olennainen tieto, vaikka pelin ratkaiseminen vaatisi ajattelua tai harjoittelua. Suunnittelussa voidaan tarkastella tekstin kokoa, kontrastia, ohjauksen muokkaamista ja sitä, välittyykö olennainen tieto muullakin tavalla kuin yhdellä värillä tai äänellä.
Microsoftin tekstin esittämistä koskeva saavutettavuusohje käsittelee muun muassa luettavuutta ja pelaajan säädettävissä olevia esitystapoja. Ohjetta voi käyttää tarkastelun apuna, mutta yksittäinen asetus ei tee koko pelistä kaikille saavutettavaa. Ratkaisuja on kokeiltava siinä tilanteessa ja sillä laitteella, jossa peliä käytetään.
Reittipulmassa vaaran merkitseminen vain punaisella ruudulla voi jättää tiedon osalta pelaajista huomaamatta. Muoto tai kuvio voi täydentää väriä. Jos avainta kuvaava symboli jää pieneksi, pelkkä ruudun alareunan selitysteksti ei välttämättä auta. Tällaiset kysymykset kannattaa ottaa mukaan jo prototyyppiin, jolloin sääntöjen ja esitystavan muuttaminen on vielä kevyempää.
Koulutuspolun valinta alkaa omasta osaamistarpeesta
Pelisuunnitteluun voi suuntautua erilaisten opintojen ja omien projektien kautta. Yhtä kaikissa tehtävissä vaadittavaa tutkintoa ei ole. Työnantaja arvioi roolin vaatimaa osaamista, kokemusta ja työnäytteitä. Koulutuksen nimi ei yksin kerro, painottuuko kokonaisuus suunnitteluun, ohjelmointiin, grafiikkaan vai tutkimukseen.
Konkreettinen suomalainen esimerkki on Aalto-yliopiston Game Design and Development -maisteriopintokokonaisuus. Teknillisen tutkinnon ohjelmasivu kuvaa 120 opintopisteen, kahden vuoden englanninkielisiä opintoja, joissa käsitellään esimerkiksi kenttäsuunnittelua, pelien tasapainoa ja käyttäjätutkimusta sekä tehdään tiimiprojekteja. Kyse on maisterivaiheen vaihtoehdosta, ei suoraan kaikille aloittelijoille avoimesta peruskurssista.
Koulutuksia vertaillessa kannattaa selvittää, pääseekö tekemään pelattavia töitä ja saako niistä yksilöityä palautetta. Tarkista myös, miten monialainen tiimityö järjestetään ja mitä pohjataitoja opinnot edellyttävät. Jos ohjelmointi on jo vahvaa mutta testien suunnittelu vaikeaa, tarvitset erilaista harjoittelua kuin hyvän visuaalisen taustan omaava aloittelija.
Itsenäisessä opiskelussa suurin haaste voi olla palautteen puute. Verkkomateriaalin läpikäyminen ei vielä osoita, että opittua osaa soveltaa. Valitse siksi pieni oma tehtävä, jonka ratkaisu ei tule suoraan oppaan mukana. Tee toimiva kokeilu, anna toisen ihmisen käyttää sitä ja kuvaa, miten havainto muutti suunnitelmaa. Näin oppiminen näkyy päätöksissä eikä vain suoritettujen sisältöjen määrässä.
Pelianalyysi harjoittaa perustelemista
Valmista peliä voi käyttää opiskelun välineenä ilman, että kopioi sen ratkaisuja omaan projektiin. Valitse lyhyt tilanne ja kuvaa ensin tapahtumat: mitä pelaaja näkee, mitä hän voi tehdä ja millaista palautetta toiminnasta seuraa? Erota tämä omasta arviostasi. ”Peli näyttää oven vieressä avaimen kuvan” on havainto; ”kuva tekee tavoitteen kaikille selväksi” on vielä oletus.
Kokeile seuraavaksi ajatuksellista muutosta. Mitä tapahtuisi, jos vihje puuttuisi tai palkinto tulisi vasta myöhemmin? Perustele, miten muutos vaikuttaisi pelaajan päätökseen. Näin analyysi etenee mielipiteestä suunnittelukysymykseksi. Sama taito auttaa tiimikeskustelussa: ”en pidä tästä” voidaan muuttaa täsmälliseksi huoleksi siitä, ettei pelaaja saa valintansa seurauksesta riittävää tietoa.
Portfolio näyttää ajattelun, ei pelkästään lopputuloksen
Suunnittelijan portfolioon sopii pieni valmis kokeilu paremmin kuin suuri toteutumaton lupaus. Työnäytteen pitäisi kertoa nopeasti, mitä tavoiteltiin, mikä oli oma vastuu ja miten ratkaisu kehittyi. Pelattavan version rinnalla lyhyt video tai kuvasarja auttaa ymmärtämään työn myös ilman asennusta. Merkitse tiimin muiden jäsenten panos ja käytetyt valmiit aineistot selvästi.
Reittipulmasta voisi rakentaa työnäytteen, jossa esitellään alkuperäinen sääntö, ensimmäisen testin havainto ja kahden ratkaisuvaihtoehdon vertailu. Mukaan ei tarvita kaikkia muistiinpanoja. Valitse se päätös, joka parhaiten osoittaa suunnittelutaitoa. Kerro myös, mitä jäi ratkaisematta: rajattu avoin kysymys on uskottavampi kuin väite täydellisestä pelikokemuksesta.
Valitse työnäytteet tehtävän mukaan. Kenttäsuunnittelussa pelattava tila voi osoittaa opetuksen ja haasteen rytmitystä. Järjestelmäsuunnittelussa havainnollinen taulukko tarvitsee rinnalleen selityksen siitä, miten arvot vaikuttavat pelaamiseen. Konseptikuva kertoo visuaalisesta ajatuksesta, mutta ei yksin todista sääntöjen toimivuutta. Samasta projektista voi siksi painottaa eri asioita eri hakemuksissa.
Harjoitusprojektissa kannattaa myös sopia työn käyttöoikeuksista ja esittämisestä muiden tekijöiden kanssa. Kaikkea työpaikalla tehtyä ei voi julkaista omassa portfoliossa. Jos materiaalia ei saa näyttää, älä korvaa sitä paljastavalla kuvauksella, vaan selvitä, millaisen oman osuuden esittely on sallittua. Ammattimaisuutta osoittaa myös yhteistyökumppanien ja luottamuksellisen aineiston kunnioittaminen.
Peliala Suomessa ja työn hakemisen todellisuus
Rovion Angry Birds sekä Supercellin Clash of Clans ja Clash Royale ovat tunnettuja suomalaislähtöisiä peliesimerkkejä. Ne ovat tiimien työn tuloksia, eivät yhden suunnittelijan itsenäisiä suorituksia. Alan tehtäviä on myös pienissä studioissa ja alihankinnassa, joissa suunnittelijan vastuut voivat poiketa paljon suuren tuotannon erikoistuneesta roolista.
Neogamesin vuoden 2024 toimialaraportti kuvaa kaksijakoista kehitystä: henkilöstömäärä kokonaisuutena kasvoi vuosina 2022–2024, mutta osa studioista vähensi työntekijöitä tai sulkeutui. Historiallinen kasvuluku ei siis kerro, kuinka helppo aloittelijan on työllistyä juuri nyt. Työmahdollisuuksia arvioidaan ajantasaisten tehtävien ja oman osaamisen, ei pelialan yleisen maineen perusteella.
Työpaikkailmoituksesta kannattaa selvittää, haetaanko uuden pelin kehittäjää vai julkaistun pelin järjestelmien ylläpitäjää. Kysy myös, miten suunnittelua testataan, kenen kanssa työskennellään ja kuinka itsenäistä vastuuta tehtävään kuuluu. Kansainvälisessä tiimissä selkeä englanninkielinen viestintä on hyödyllistä. Etätyö, työskentelymaa ja käytännöt ovat kuitenkin työnantajakohtaisia, eivät ammattinimikkeen takaamia etuja.
Julkaisun jälkeenkin tarvitaan harkintaa
Julkaistussa pelissä suunnittelija voi seurata palautetta, rakentaa uusia sisältöjä ja muuttaa tasapainoa. Pelaajien toiveet voivat olla ristiriidassa keskenään. Runsas palaute yhdestä ryhmästä ei välttämättä kuvaa kaikkia pelaajia, eikä pitkä peliaika yksin osoita hyvää kokemusta. Mittareita kannattaa verrata havaintoihin ja siihen, millaista toimintaa peli oikeastaan haluaa tukea.
Muutos voi myös vaikuttaa jo opittuihin toimintatapoihin. Jos tuttu resurssi menettää arvonsa tai vaikeus muuttuu äkisti, pelaajan aiemmat valinnat voivat tuntua turhilta. Siksi päivityksen suunnitteluun kuuluvat vaikutusten arviointi, testaaminen ja ymmärrettävä viestintä. Uuden sisällön määrä ei korvaa johdonmukaista kokonaisuutta.
Tekoäly, virtuaalitodellisuus ja muut uudet välineet voivat tarjota kokeilumahdollisuuksia, mutta ne eivät ratkaise suunnittelun tavoitetta tekijän puolesta. Teknologiaa kannattaa arvioida sen mukaan, mitä se tuo pelaajan toimintaan ja mitä sen käyttäminen vaatii tiimiltä. Työkalun tuottaman aineiston laatu, käyttöehdot ja sopivuus projektiin on silti arvioitava.
Mistä aloittaa, jos pelisuunnittelijan työ kiinnostaa?
Valitse yksi pieni sääntö tai valintatilanne, älä kokonaista unelmapeliä. Kirjoita, mitä pelaajan pitäisi ymmärtää ja millainen päätös hänen pitäisi tehdä. Rakenna tätä kysymystä varten mahdollisimman yksinkertainen kokeilu. Pyydä toista ihmistä pelaamaan, kirjaa havainto ja tee sen perusteella yksi harkittu muutos.
Kun kokeilu toimii, kokoa siitä lyhyt selitys: tavoite, toteutus, havainto, päätös ja seuraava avoin kysymys. Tämä harjoitus paljastaa myös, mikä työssä itseä kiinnostaa. Nautitko sääntöjen vertailusta, tilojen rakentamisesta, pelaajien havainnoimisesta vai suunnitelman toteuttamisesta? Vastaus auttaa valitsemaan seuraavan projektin ja tarvittavat opinnot.
Pelisuunnittelijan työ ei lopulta ole parhaiden ideoiden vartioimista. Se on kykyä tehdä ajatus ymmärrettäväksi, kokeilla sitä käytännössä ja muuttaa suuntaa perustellusti. Pieni loppuun asti tutkittu peli voi opettaa tästä enemmän kuin laaja suunnitelma, jota kukaan ei ole vielä pelannut.
