Kenttien suunnittelu videopeleissä

Samankaltaiset tiedostot
Kenttien suunnittelu videopeleissä

Selainpelien pelimoottorit

arvostelija OSDA ja UDDI palveluhakemistoina.

Aika/Datum Month and year Kesäkuu 2012

18 Komponentit, ulkoasu ja visuaalisuus. Materiaalit CC-BY 4.0 Mikko Lampi

Pelisuunnittelua tulevaisuudessa. Karoliina Korppoo / Colossal Order

Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages

Pro gradu -tutkielma Meteorologia SUOMESSA ESIINTYVIEN LÄMPÖTILAN ÄÄRIARVOJEN MALLINTAMINEN YKSIDIMENSIOISILLA ILMAKEHÄMALLEILLA. Karoliina Ljungberg

Maailman muutosta tallentamassa Marko Vuokolan The Seventh Wave -valokuvasarja avauksena taidevalokuvan aikaan

! #! %! & #!!!!! ()) +

Luonnontieteiden popularisointi ja sen ideologia

Koht dialogia? Organisaation toimintaympäristön teemojen hallinta dynaamisessa julkisuudessa tarkastelussa toiminta sosiaalisessa mediassa

Matopeli C#:lla. Aram Abdulla Hassan. Ammattiopisto Tavastia. Opinnäytetyö

Nollasummapelit ja bayesilaiset pelit

Board Game Lab. 4 Teema. Materiaalit CC-BY 4.0 Mikko Lampi

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008

Ohjelmiston toteutussuunnitelma

Tarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen

AutoCAD-natiiviobjektin toteutus

Katsaus korruption vaikutuksesta Venäjän alueelliseen talouskasvuun ja suoriin ulkomaisiin investointeihin

KODU. Lumijoen peruskoulu

Pelilabra. Pelilabra on noin minuuttia pitkä, pääasiallisesti nopaton skenaario jossa pelaajat kokevat tyypillisen Oululaisen pelikoulutuksen.

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

PERCIFAL RAKENNETUN TILAN VISUAALINEN ARVIOINTI

Testaaminen ohjelmiston kehitysprosessin aikana

Oppimateriaalin kokoaminen ja paketointi

Asuntojen neliöhinnan vaihtelu Helsingissä ( )

Harjoitus Morphing. Ilmeiden luonti

Ohjelmistojen mallintaminen, mallintaminen ja UML

Tiedekunta/Osasto Fakultet/Sektion Faculty Valtiotieteellinen tiedekunta

INTERAKTIIVINEN PELI, JOKA SAA OPPILAAT LIIKKUMAAN JA OPPIMAAN - TÄYDELLINEN TUOTE LIIKKUVIIN KOULUIHIN!

Strategiset suunnittelupelit: SimCity ja Civilization

OHJ-2710 Peliohjelmointi. Syksy 2012 Timo Kellomäki

Hallintomallit Suomen valtionhallinnon tietohallintostrategioissa

Seminaari: HL7 versio 2

Ohjelmistojen mallintaminen. Luento 11, 7.12.

KYMENLAAKSON AMMATTIKORKEAKOULU. Ubuntu. Yukun Zhou

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digitaalinen oppimispeli VauvaPolku uutena perhevalmennuksen työvälineenä

Arkkitehtuurinen reflektio

Piirrä oma valolinjasi

Uudelleenkäytön jako kahteen

Seuraavat kysymykset koskevat erilaisia tekijöitä, jotka liittyvät digitaaliseen mediaan ja digitaalisiin laitteisiin kuten pöytätietokoneet,

Ohjelmoinnin perusteet Y Python

TIE Ohjelmistojen suunnittelu. Luento 2: protot sun muut

AUTOCAD-TULOSTUSOHJE. Tällä ohjeella selitetään Autocadin mittakaavatulostuksen perusasiat (mallin mittayksikkönä millimetrit)

T Loppukatselmus

TIE Ohjelmistojen suunnittelu. Luento 2: protot sun muut

Labyrintti. Pelihahmon toiminta. Piirrä pelihahmo (älä piirrä esim. sivusta, ettei hahmon tarvitse

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ammatti: Pelisuunnittelija

Sosiaalisen median mahdollisuudet & hyödyt

VINKKEJÄ CV-NETIN KÄYTTÖÖN.

AUDIOVISUAALISEN VIESTINNÄN AMMATTITUTKINTO. Valmistavan koulutuksen koulutussuunnitelma, peligrafiikan osaamisala

Ampumahiihto. Hiihto. Pelihahmon piirtäminen. Jos tahdot animoida hiihtämisen, Peli muodostuu kahdesta erilaisesta osasta: ensin

Action Request System

Tasohyppelypeli. Piirrä grafiikat. Toteuta pelihahmon putoaminen ja alustalle jääminen:

Luku 2: Peliteollisuus. Historiasta nykypäivään Pelin tuotantoprosessi

Lakki. Lisää ot sik k o osoit t am alla. Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010

Pikaohje QPR-käyttöön

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

KOLMIULOTTEINEN TIETOKONEGRAFIIKKA PELEISSÄ

ESSE 1, PUUKAUPUNKISTUDIO 2015

Tietotekniikan koulutusohjelman suuntautumisvaihtoehdot

Osa 7: Hahmojen ohjelmointi ja hienosäätö

Kajak Games uuden sukupolven yrittäjät. Pressure Cooker Kimmo Nikkanen, Kajak Games Osk

SISÄLTÖ Xbox LIVE... 2 OHJAUSKOMENNOT... 2 PELIN ALOITTAMINEN... 3 PELINÄYTTÖ... 4 ASIAKASTUKI... 5

Salasanojen turvallinen tallentaminen KeePass ohjelmalla

Board Game Lab. 7 Pelimekaniikat ja -systeemit. Materiaalit CC-BY 4.0 Mikko Lampi

OHJELMISTOKEHITYS -suuntautumisvaihtoehto

Ohjelmistojen mallintaminen Tietovuokaaviot Harri Laine 1

Mainonta ja tuotesijoittelu digitaalisissa peleissä. Olli Raatikainen Viestintätieteet

Lasse Leponiemi, Ada Kukkonen,

3D-PELIEN KENTTÄSUUNNITTELU

Yhteistyötä sisältämätön peliteoria

Tutkittua tietoa. Tutkittua tietoa 1

EKAPELI-ALKU LUKEMAAN OPETTAMISEN TUKENA

Menetelmäraportti - Konfiguraationhallinta

VERKKOSIVUANALYYSI Suomalaisen musiikin tiedotuskeskus FIMIC

Tapahtumakalenteri & Jäsentietojärjestelmä Toteutus

INFORMAATIOALAT JA TYÖN TULEVAISUUS

Tietotekniikan laitoksen uusi linja

Projektityö

Europass-ansioluettelo

Sudenkuoppia, yllätyksiä, pään vaivaa

Avoin lähdekoodi hankinnoissa Juha Yrjölä

SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen Kevät 2016

Anna Siikaniemi. BITSBOARD sovelluksen käyttöopas

Harjoituksen aiheena on tietokantapalvelimen asentaminen ja testaaminen. Asennetaan MySQL-tietokanta. Hieman linkkejä:

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

OpenUP ohjelmistokehitysprosessi

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Pelit (ja sosiaalinen media) matkailussa. Jaakko Suominen FT, digitaalisen kulttuurin professori Turun yliopisto / Porin yliopistokeskus

Johdanto. Agenda. Tuotantoprosessi. Historiallinen kehitys. Konsepti. Tuotantoprosessin vaiheet

Harjoitus Bones ja Skin

Board Game Lab. 5 Pelimaailma. Materiaalit CC-BY 4.0 Mikko Lampi

Transkriptio:

hyväksymispäivä arvosana arvostelija Kenttien suunnittelu videopeleissä Pirkka Hartikainen Helsinki 19.2.2008 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Pirkka Hartikainen Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Kenttien suunnittelu videopeleissä Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Tiivistelmä Referat Abstract ACM Computing Classication System (CCS): A.1 [Introductory and Survey], K.8.0 [General] 19.2.2008 13 sivua Avainsanat Nyckelord Keywords pelisuunnittelu, kentät, ohjelmistotuotanto Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

Sisältö ii 1 Johdanto 1 2 Kenttäsuunnittelu osana ohjelmistotuotantoprosessia 2 2.1 Ammattina kenttäsuunnitelija...................... 2 2.2 Kenttäsuunnittelun prosessi: esituotanto................ 2 2.3 Kenttäsuunnittelun prosessi: tuotanto.................. 3 2.4 Kenttien testaus.............................. 4 2.5 Kohti julkaisua.............................. 4 3 Kenttäsuunnittelun tekniikka 5 3.1 Kolmiulotteisten pelien tekninen kehitys................ 5 3.2 Kolme teknistä komponenttia: muotoilu, tekstuurit ja valaistus.... 9 3.3 Vaiheet: mallista viimeistelyyn...................... 10 3.4 Kenttäsuunnittelun työvälineet..................... 11 3.5 Proseduraalisesti luotu sisältö...................... 12 3.6 Satunnaisesti luodut kentät....................... 12 4 Kuinka suunnitellaan toimivia kenttiä 12 4.1 Tavoitteet................................. 12 4.2 Yksinpelit................................. 12 4.3 Moninpelit................................. 12 4.4 Bugit.................................... 12 5 Yhteenveto 12 Lähteet 13

1 1 Johdanto Designing game spaces is not a new phenomenon. Children do it on a daily basis, constructing complicated games governed by rule sets that can change at the drop of a hat. - Sam Shahrani Englanninkielinen termi level design kuvaa pelitilojen suunnittelua video- ja tietokonepelien puitteissa. Termin alkuperä on sikäli mielenkiintoinen, että ensimmäisissä videopeleissä tasot (engl. levels) kuvasivat lähinnä vaikeustasoja: pelit olivat niin yksinkertaisia, että usein pelin uusi taso merkitsi lähinnä suurempaa vihollisten määrää, pelin nopeutumista tai muuta pelaamista vaikeuttavaa tekijää. Seikkailullisten elementtien myötä peleissä kuitenkin alettiin toteuttamaan yhä monipuolisempia karttoja ja näiden myötä pelin tasot tai kentät alkoivatkin enemmän muistuttaa itsenäisiä virtuaalimaailmoja tai niiden osia. Näin voidaan sanoa että tasosuunnittelu tai kenttäsuunnittelu alkoi tarkoittaa pikemminkin pelimaailmojen tai -tilojen suunnittelua kuin uusien vaikeustasojen (engl. diculty levels) suunnittelua. Terminä level design on kuitenkin vakiintunut käyttöön siitä huolimatta ettei uusimmissa peleissä välttämättä ole enää lineaarisessa järjestyksessä pelattavia kenttiä, sen enempää kuin välttämättä vaikeustasojakaan. Suomeksi käännettynä voidaan puhua joko taso- tai kenttäsuunnittelusta tarkoittaen samaa asiaa. Kenttäsuunnittelu tarkoittaa siis video- ja tietokonepelien puitteissa pelimaailmojen suunnittelua ja toteutusta, ja nimenomaan konkreettisella tasolla eli sen lopputuloksena ovat suoraan ne ympäristöt joiden kanssa pelaajat ovat vuorovaikutuksessa. Käytännössä kenttäsuunnittelussa yhdistyvät virtuaalinen arkkitehtuuri, pelisuunnittelu ja taiteellinen suunnittelu. Tämä kirjoitelma jakautuu kolmeen osaan, joista ensimmäisessä käsitellään kenttäsuunnittelua osana ohjelmistotuotantoprosessia, toisessa kenttäsuunnittelun tekniikkaa ja kolmannessa kenttäsuunnittelun tavoitteita ja suunnittelumalleja. Tavoitteena on antaa yleiskuva kenttäsuunnittelusta ohjelmistotuotannon näkökulmasta. 2 Kenttäsuunnittelu osana ohjelmistotuotantoprosessia Peliteollisuus on kasvanut huimasti 70- ja 80-luvuilta jolloin oli yleistä että kaupallisen pelin suunnittelusta ja teknisestä toteutuksesta kokonaisuudessaan saattoi

2 vastata ainoastaan yksi tai kaksi henkilöä. Vielä 90-luvun alussa voitiin ajatella että pelin yhden tason suunnitteluun ja luomiseen kuluu muutamia tunteja. Pelien tuotantobudjettien yhä noustessa aiheesta kirjoitetaan nykyisin jo kirjoja ja järjestetään yliopistotason koulutusta. Pätevistä pelisuunnittelijoista on enemmän kysyntää kuin tarjontaa [?] alalla joka on jälleen lyönyt myyntiennätyksensä vuosina 2006 ja 2007 [?]. Kenttäsuunnittelun vastuualueena on tuottaa pelaajia viihdyttäviä skenaarioita jotka kuljettavat pelin juonta eteenpäin halutulla tavalla. Kenttien suunnitteluun tarvitaankin pelisuunnittelutaitojen lisäksi myös taiteellista näkemystä, vaikka lopulta oleellisinta kenttäsuunnittelussa onkin kentän toimivuus itse pelaamisen näkökulmasta eivätkä taiteelliset arvot. 2.1 Ammattina kenttäsuunnitelija Vasta 90-luvun puolivälin tienoilla kenttäsuunnittelija alkoi eriytyä omaksi ammatikseen, vaikka jotkut kenttien suunnittelijat kuten Richard Levelord Gray olivatkin jo keränneet mainetta hyvin suunnitelluilla kentillään. 2000-luvulle siirryttäessä kenttäsuunnittelijan ammatti on edelleen jakautunut erikoistuneempiin nimikkeisiin, kuten kenttätaitelijoihin, skriptaajiin ja varsinaisiin kenttäsuunnittelijoihin. Tyypillisesti suuremmissa projekteissa onkin useampia kenttiä suunnittelevia tiimejä. 2.2 Kenttäsuunnittelun prosessi: esituotanto Kenttäsuunnittelu alkaa peliprojektin esituotantovaiheessa, ja voidaan aloittaa heti kun pelin tarina on kasassa ja peli voidaan jakaa tasoihin joista kukin kuljettaa oman osansa tarinasta. Kullekin tasolle määritellään suunnittelija tai suunnittelijatiimi joka kommunikoi pelin pääsuunnittelijan kasnsa. Vapaaseen liikkumiseen perustuvissa Hiekkalaatikkopeleissä suunnitteluvastuuta voidaan jakaa maantieteellisesti koska näissä ei ole varsinaisia kenttiä kuten perinteisemmissä peleissä. Tyypillisesti kentän suunnittelun alussa siitä piirretään jonkinlainen luonnos tai diagrammi, johon merkitään kentän oleellisimmat pelilliset tapahtumat. Samanaikaisesti taidetiimi kehittää kenttään liittyviä konsepteja ja visuaalista kuvastoa käyttäen hyväksi kirjallisuutta, elokuvia tai muuta lähdemateriaalia sekä projektin taiteellisen

3 johtajan ohjausta. Kentän pelisuunnittelun ja taidesuunnittelun ohella kenttää suunnittelevan tiimin täytyy olla yhteydessä tekniseen tiimiin, jotta nämä pystyisivät toteuttamaan suunnitellut visiot itse pelissä. Esimerkiksi sumun tai voimakkaan tuulen kaltaisten olosuhteiden mallintaminen pelimoottorissa voisi olla vaatimus jonka kenttäsuunnittelija voisi esittää tekniselle tiimille esituotantovaiheessa. Tekninen tiimi on vastuussa sekä itse pelimoottorista että työkaluista joiden avulla kenttäsuunnittelijat ja taiteilijat pystyvät luomaan pelin sisältöä. Kenttäsuunnittelijoiden ja koko peliprojektin kannalta on oleellista että pelin sisältöä tuottava liukuhihna saadaan kuntoon heti projektin alkuvaiheessa. Tämä ei ole triviaali tehtävä siksi, että usein tarvitaan konversioita vaikkapa 3d-ohjelmistojen ja pelimoottorin tai muiden työkaluparien välille. On yhä harvinaisempaa että koko pelimoottori ja kaikki sisällöntuotannon työvälineet tehdään alusta asti itse. 2.3 Kenttäsuunnittelun prosessi: tuotanto Kun pelin toteutussuunnitelma ja teknologiset valinnat on tehty voidaan projektille näyttää vihreää valoa ja siirtyä tuotantovaiheeseen. Tuotantovaiheessa pelin kentistä tehdään prototyyppejä joiden graaseen viimeistelyyn ei panosteta ennen kuin taso on saatu pelillisesti toimivaksi. Esimerkiksi pintojen tekstuureina käytetään väliaikaisia markkeeraustekstuureja ja mallit voivat olla kömpelöitä raakaversioita joiden yksityiskohtia tai animaatioita ei ole vielä toteutettu. Tarkoituksena on saada kentän perusominaisuudet ja tärkeimmät skriptatut tapahtumat toteutettua ja testattua ennen kuin se lähetetään taidetiimille. Taidetiimin tehtävänä on puolestaan lisätä prototyyppikenttään tekstuurit, valaistus ja yksityiskohtaisemmat mallit. Taiteellinen johtaja tarkastaa että työ on pelin linjan mukaista. Lisäksi taidetiimin pitää huolehtia yhteistyössä teknisen tiimin kanssa siitä että pelin moottorissa riittää resursseja kaiken sisällön esittämiseen. Esimerkiksi muistin puute rajoittaa tyypillisesti käytössä olevien tekstuurien kokoa ja määrää, jolloin kenttätaitelijoiden täytyy osata priorisoida muistin käyttöä järkevästi. 2.4 Kenttien testaus Kenttiä testataan tyypillisesti kahdessa vaiheessa: alfa- sekä betavaiheessa. Alfavaihe tarkoittaa sitä että peli voidaan pelata alusta loppuun asti ja sisältää kaikki siihen

4 oleellisesti kuuluvat toiminnot. Betavaiheessa peli on vieläkin viimeistellympi, ja periaatteessa kaikki tehtävät muutokset ovat bugikorjauksia eikä siihen enää lisätä uutta sisältöä eikä uusia toimintoja. Pelejä testataan manuaalisesti - käytäntö jota muualla softakehityksessä pidetään worst practice -käytäntönä kalliin hintansa takia, mutta joka tuntuu sopivan paremmin pelialalle kuin suppeampia käyttäjäsyötteitä vastaanottaviin tai toimintavarmuudeltaan hyvin kriittisiin sovelluksiin. Manuaalisen testauksen laajan käytön vuoksi testaus ja laadunvarmistus ovatkin tyypillisiä rooleja joissa uudet tekijät työllistyvät pelialalle. Pelitestaajien työnä on pelata testisuunnitelman määrittelemää osuutta pelistä ja kirjata havaitsemiaan ongemia tietokantaan, jossa Level Design for Games -kirjan mukaan käytetään yleensä neliportaista luokittelua: Estävät virheet, esimerkiksi pelin kaatumista aiheuttavat virheet jotka estävät pelin pelaamisen. Kriittiset virheet, esimerkiksi näkymätön seinä tai muu selkeästi havaittava virhe jotka vaikuttavat merkittävästi pelikokemukseen. Ei-kriittiset virheet, esimerkiksi väärä tekstuuri kohteessa tai kohteen väärä animaatio, jotka vaikuttavat jossain määrin pelikokemukseen. Parannusehdotukset, joissa testitiimi haluaa ehdottaa parannusta peliin eikä raportoi virheestä. Alfavaiheessa testaustiimi ja kehittäjät kommunikoivat virheitä ja kehitysehdotuksia sisältävän tietokannan välityksellä, ja lisäksi eri kehitystiimit pyrkivät sisäisesti saattamaan jokaisen pelin kentän viimeistellylle tasolle. Tässä vaiheessa taiteelliset tiimit lisäävät kenttiin yksityiskohtia ja muita tunnelmaa luovia elementtejä. 2.5 Kohti julkaisua Peliteollisuus on siitä kiinnostava ohjelmistoteollisuuden ala, että sen sisäinen dynamiikka poikkea huomattavasti tyypillisistä ohjelmistotuotantoprojekteista ainakin yhdessä asiassa. Siinä missä yleensä asiakas vaatii tuotteelta lisää ominaisuuksia ja toteuttaja puolestaan haluaa saada sen valmiiksi, on peliteollisuudessa asetelma usein toisenlainen: asiakkaana toimiva pelin julkaisija haluaisi että projekti loppuisi

5 ja päätyisi kaupan hyllylle, kun taas pelin kehittäjät yleensä haluaisivat lisätä uusia hienoja toimintoja ja hioa peliä vaikka loputtomiin jos se suinkin olisi mahdollista. Käytännössä peliprojektin sanotaan siirtyneen betavaiheeseen silloin kun projektissa on määrätty ettei uutta sisältöä tai uusia toimintoja saa enää lisätä peliin. Betavaiheessa kehittäjien ainoa tavoite on eliminoida mahdollisimman paljon virheitä pelistä jotta se voitaisiin saada julkaisuvalmiiksi. Betavaiheen päätteessä pelistä käännetään julkasukandidaatti. Tätä versiota testataan kunnes voidaan varmistua että kriittisiä tai estäviä virheitä ei enää siitä löydy. Mikäli niitä löydetään, ne korjataan välittömästi jotta peli saadaan uudestaan hyväksymistestamiseen. Pelille saatetaan asettaa joku tietty tuntimäärä jonka verran jokaista julkaisukandidaattia täytyy testata virheitä löytämättä jotta se painaa gold master -kopioksi, eli versioksi joka lähetetään painoon julkaisua varten. Konsolipeleissä paine julkaisuversion virheettömyydelle on korkeampi kuin tietokonepelien puolella, koska konsolipeleihin ei perinteisesti ole julkaistu korjauspaketteja ollenkaan. Uuden sukupolven verkkoyhteyksillä ja muistikortteja laajemmalla tallennuskapasiteetilla varustetut konsolit mahdollistavat korjauspakettien julkaisun, mutta silti ei voida olettaa että uusimmatkaan konsolit välttämättä olisivat aina korjausten verkkojakelun ulottuvilla. 3 Kenttäsuunnittelun tekniikka Kenttäsuunnittelu voidaan karkeasti jakaa kaksiulotteisten ja kolmiulotteisten kenttien suunnitteluun. Kaksiulotteisten kenttien suunnittelu on enemmänkin pelisuunnitteluun ja taiteeseen liittyvä haaste, kun taas kolmiulotteisiin kenttiin liittyy huomattavasti enemmän teknisiä haasteita ja selkeästi monimutkaisemmat työkalut. Kaksiulotteisten kenttien suunnittelutekniikat on rajattu tämän esseen ulkopuolelle. 3.1 Kolmiulotteisten pelien tekninen kehitys Ensimmäinen kuluttajille suunnattu 3D-peli oli Battlezone joka julkaistiin vuonna 1980. Pelin kenttäsuunnittelu oli hyvin primitiivistä, sillä pelissä oli vain yksi vuorten ympäröimä tasanko kenttänä. Toki näinkin yksinkertaisessa mallissa pelaaja pystyi esimerkiksi suojautumaan vihollisten tulitukselta tasangon esineiden taakse piiloutumalla. Pelimoottorin vanhanaikaisuudesta kertoo se, että kaikki esineet ovat

läpinäkyviä - pelin resurssit eivät siis riittäneet pelaaja lähimpien polygonien taakse jääneiden viivojen piilottamiseen. 6 Kuva 1: Battlezone - ensimmäinen kaupallisesti julkaistu 3D-peli. Ensimmäiset täytetyt polygonit tulivat markkinoille vuonna 1987 pelissä Elite Plus. Tämän jälkeen saatiin odotella vielä viisi vuotta ennen kuin 3D-pelaamisen saralla alkoi oikeasti tapahtua - vuonna 1992 nimittäin julkaistiin kaksi todella merkittävää kolmiulotteisen pelaamisen virstanpylvästä: Wolfenstein 3D ja Ultima Underworld. Kahdesta ensimmäisestä vapaaseen liikumiseen perustuvasta 3D-seikkailusta kehittyneempi ja uraauurtavampi oli Ultima Underworld. Sen pelimoottori tuki mm. vaihtelevan korkuisia huoneita, 45:n asteen kulmia seinissä sekä portaikkoja - kaikki toiminnallisuuksia jotka puuttuivat Wolfenstein 3D:stä. Oleellisinta molemmissa peleissä oli kuitenkin tekstuurien käyttö polygonien pinnoilla ja vapaa liikkuminen kolmiulotteisessa maailmassa, idea jonka Wolfensteinin tekijät nappasivat nähtyään sen ensin Ultima Underworld -projektissa. Toki molempien pelien sisällöstä suurin osa oli toteutettu perinteiseen tapaan spritegraikalla eikä peleissä siis ollut muita todellisia 3D-elementtejä kuin itse ken-

7 Kuva 2: Ultima Underworld: Stygian Abyss, teknisesti käänteentekevä 3D-peli. tät. Helpommin lähestyttävästä Wolfenstein 3D:stä tulikin massiivinen hitti PCpelimarkkinoilla ja se käännettiin kaupallisesti seistemälle muulle alustalle. Tämä peli oli alkusoitto rst person shooter -pelien valtakaudelle jonka voidaan katsoa jossain määrin jatkuvan vieläkin. Jo vuonna 1993 id Softare julkaisi seuraavan pelinsä nimeltään Doom, joka tarjosi kenttäsuunnittelun näkökulmasta paljon uusia edistyaskeleita. Kenttien koostumusta pystyttiin muuttamaan lennosta kesken pelin, jolloin pystyttiin esimerkiksi ohjelmoimaan nousevia tai laskevia kattoja ja lattioita huoneisiin. Pelikenttissä oli oikeita 3D-mallinnettuja esineitä. Seinät eivät rajoittuneet 90 asteisiin kulmiin vaan mitä tahansa astelukuja voitiin käyttää. Katoissa ja lattioissa voitiin käyttää tekstuureja, samoin pelikentän taivaalle voitiin asettaa tekstuuri joka loi kenttiin uudenlaista tilan tuntua. Lisäksi kentän valaistusta pystyttiin vaihtelemaan paikasta toiseen. Doomin viholliset ja esineet oli yhä toteutettu spriteinä, ja pelimoottorissa oli vielä rajoituksia kuten esimerkiksi se, ettei kaksi huonetta voinut olla kentässä päällekkäin. Nämä rajoitukset eivät kuitenkaan pelin suosiota haitanneet, ja siitä tuli edel-

8 täjänsä tavoin suuri hitti. Erityisen kiinnostavaa id Softwaren strategiassa oli, että he antoivat pelin mukana ilmaiseksi työkalut pelin sisällön muokkaamiseen, toivoen että tämä hillitsisi luvattomasti muokattujen versioiden muodossa tapahtuvaa piratismia ja rohkaisisi pelaajia luovuuteen. Pelin fanit alkoivatkin tuottaa Doomista täysin muokattuja versioita joissa kaikki graikat, kentät ja musiikit oli vaihdettu toisiin. Kenttäeditoreja oli sisällytetty peleihin jo 80-luvulla, mutta id Softwaren lähestymistapa on vaikuttanut vahvasti peliteollisuuteen ja siihen kuinka pelien fanit on päästetty hyödyntämään pelin rakentamisessa käytettyjä työkaluja vapaasti. Harrastelijavoimin tehdyt versiot peleistä eivät välttämättä yllä parhaiden kaupallisten pelien tasolle, mutta toimivat oivana tapana päästä harjoittelemaan pelialan työtä ennen työllistymistä alalle. Kaiken edellämainitun lisäksi Doom oli vielä yhdellä merkittävällä tavalla ensimmäinen: se mahdollisti kahden pelaajan vastakkaisen pelin lähiverkon tai puhelinlinjojen yli ja synnytti deathmatch -pelityypin jonka pohjalta kehittyneiden nettimoninpelien suosio jatkuu yhä, kuten miljoonia myyvät pelien kuten Halo 3 tai Battleeld 2 todistavat. Pari vuotta Doomia myöhemmin Descent toi ensimmäisenä peleihin polygneista koostuvat viholliset, ja vuonna 1996 julkaistiinkin Quake jossa kaikki esineet koostuivat polygoneista eikä sprite-graikkaa käytetty enää lainkaan. Samana vuonna julkaistu Duke Nukem 3D puolestaan toi 3D-peleihin tuhottavat ympäristöt, eli antoi pelaajalle mahdollisuuden raivata tieltään esteitä. Muita 90-luvun loppupuolen innovaatioita olivat veden mallintaminen, varjot, värilliset valonlähteet ja pyöristetyt esineet. 2000-luvulla kenttien toteutustekniikkojen kehitys on mennyt eteenpäin esimerkiksi luonnollisten ympäristöjen kuten viidakkojen ja metsien mallintamisen saralla (Far Cry, Crysis) sekä proseduraalisesti luotujen maastojen osalta (ruotsalainen peli X). Voidaan kuitenkin sanoa että suuri osa varsinaisista innovaatiosta tehtiin 90-luvulla ja 2000-luvulla samoja asioita on vain tehty tehokkaammin ja suuremmilla pikselimäärillä.

9 Kuva 3: Quake, ensimmäinen täysin polygoneihin perustuva rst person shooter. 3.2 Kolme teknistä komponenttia: muotoilu, tekstuurit ja valaistus Kolmiulotteisen kentän suunnittelussa on kolme teknistä päävaihetta. Ensin muotoillaan kenttä, eli määritellään minkä muotoisista pinnoista se koostuu. Seuraavaksi määritellyt pinnat värjätään tekstuureilla. Kolmanneksi määritellään kentän valonlähteet. Luonnollisesti kenttien suunnitteluun kuuluu myös esineiden ja pelihahmojen sijoittelu sekä näihin liittyvä skriptaus, samoin kuin äänisuunnittelu. Muotoilu, tekstuurien lisääminen ja valaistus tuottavat kuitenkin valmiin näköisen joskin kuolleen kolmiulotteisen maailman. Kaikki kolme työvaihetta voidaan tehdä käyttäen pelimoottorin mukana tulevaa kenttäeditoria, tai vaihtoehtoisesti jotain muuta 3D-työkalua josta kenttä voidaan muuntaa pelimoottorin ymmärtämään muotoon. Kenttäeditoreja on perinteisesti ollut kahdenlaisia, additiivisia ja substraktiivisia. Additiivisissa kenttäeditoreissa tyhjään avaruuteen lisätään objekteja, kun taas substraktiivisissa editoreissa kiinteään

10 Kuva 4: Näkymä ilman tekstuureja pelistä Halo 3. kappaleeseen ikäänkuin kaivetaan tunneleita ja huoneita leikkaamalla siihen tyhjää tilaa. Näitä kahta eri tekniikkaa voisi verrata vaikkapa maalaukseen ja kuvanveistoon. 3.3 Vaiheet: mallista viimeistelyyn Kentän toteutus lähtee liikkeelle esituotantovaiheessa tehdyn suunnitelman tai luonnoksen pohjalta. Aluksi kenttään mallinnetaan suuret suuntaviivat kuten huoneet, käytävät, rakennukset ja kukkulat. Alkuvaiheessa rakennuksia ja muita suurempia esineitä voidaan hyvin mallintaa eri yksinkertaisilla monitahokkailla (ikäänkuin venytetyillä kuutioilla), kunnes ne myöhemmin korvataan oikeilla malleilla. Tämän jälkeen kenttään voidaan merkata pelaajan saapumispaikka ja kentästä ulos johtavat reitit sekä pelillinen sisältö: esineet, pelihahmot, kentän liikkuvat osat, salareitit, tallennuspisteet ja niin edelleen. Nämä tietysti vaativat skriptausta eli käyttäytymisen ohjelmointia: miten kentässä vastaan tulevat pelihahmot liikkuvat ja käyttäytyvät, mitä muutoksia kentässä tapahtuu kun vivusta vedetään tai nappia painetaan, mitä ehtoja pelaajan tulee täyttää että hän pääsee kentästä seuraavaan jne. Viimeistelyvaiheessa kentän tunnelmaa hiotaan muokkaamalla tekstuureja, ääniä,

11 animaatioita, valaistusta ja musiikkia. Lisäksi kenttään skriptataan tyypillisesti välianimaatioita, jotka kuljettavat tarinaa eteenpäin tai kommunikoivat jonkun oleellisen tiedon pelaajalle. On mahdollista että välianimaatioiden tekemisestä vastaa kokonaan eri tiimi kuin kentän suunnittelijat. Välianimaatiot saattavat näyttävyyden lisäksi olla myös teknisesti eri tavalla toteutettuja kuin pelimoottori, vaikkakin sellaisen ratkaisun katsotaan usein rikkovan pelaajan immersiota. 3.4 Kenttäsuunnittelun työvälineet Kenttäsuunnittelun tärkein työväline on peliin sopiva kenttäeditori. Kenttäeditorit voidaan jakaa useaan eri ryhmään: Pelirman sisäiseen käyttöön tarkoitetut pelikohtaiset kenttäeditorit. Julkiseen käyttöön tarkoitetut pelikohtaiset kenttäeditorit. Useisiin peleihin samanakaisesti tarkoitetut kenttäeditorit. Yleiskäyttöiset 3D-työkalut ja niihin tehdyt pelispesiset lisäominaisuudet (pluginit). Peleihin sisäänrakennetut kenttäeditorit (Doom 3, Halo 3). Epäviralliset fanien tekemät kenttäeditorit. Monissa peleissä kenttäeditori on tarkoitettu pelkästään kehittäjätalon sisäiseen käyttöön. Doomin jalanjäljissä kuitenkin monien PC-pelien yhteydessä on julkaistu pelaajayhteisön käyttöön tarkoitettuja kenttäeditoreja ja näiden ympärille onkin syntynyt aktiivisia harrastelijakehittäjien eli modaajien yhteisöjä, joista puolestaan monet ammattilaiskehittäjät ovat ponnistaneet alalle. Pelikohtaisten editorien lisäksi on olemassa yleiskäyttöisempiä kenttäeditoreja kuten id Softwaren QtkRadiant ja avoimen lähdekoodin QuArK. Lisäksi 3D-ohjelmistoja kuten 3D Studio Max, Blender, AutoCAD, Lightwave, Maya ja Softimage XSI voidaan käyttää pelikenttien suunnitteluun, varsinkin höystetynä pelikohtaisilla apuohjelmilla (plugin). Joissakin peleissä kenttäeditori tulee myös mukana itse pelissä, tosin tällaiset editorit eivät yleensä tarjoa mahdollisuutta pelin sisältöobjektien muokkaamiseen vaan

tarjoavat valmiin paletin jonka avulla pelaajat voivat rakentaa haluamansa kaltaisia kenttiä, mahdollisesti käyttäen ainoastaan peliohjainta syötevälineenä. Lisäksi harrastelijat ovat onnistuneet luomaan kaupallisesti myytäviin peleihin epävirallisia kenttäeditoreja, jotka eivät kuitenkaan ole kiinnostavia kaupallisen pelituotannon kannalta koska niillä voi muokata ainoastaan jonkun tietyn tekijänoikeuksiltaan suojatun pelin kenttiä. 4 Kuinka suunnitellaan toimivia kenttiä 4.1 Tavoitteet 4.2 Yksinpelit 4.3 Moninpelit 4.4 Bugit 5 Yhteenveto Kenttäsuunnittelu on yksi onnistuneen pelin tärkeimmistä tehtävistä: hyväkään pelimoottori ja taustatarina eivät riitä jos pelin kentät ovat tylsiä, turhauttavia tai ristiriidassa pelin kantavien ideoiden kanssa. Hyville tasosuunnittelijoille on siis varmasti kysyntää niin kauan kun peliteollisuus pysyy voimissaan. Toisaalta taas voidaan kysyä, että onko tasosuunnittelijan ammattinimike enää kurantti kaikissa peliprojekteissa. Tasojen suunnittelu jakautuu käytännössä yhä erikoistuneempiin tehtäviin kuten skriptaukseen, arkkitehtuuriin, tehtävien suunnitteluun ja taiteeseen samanaikaisesti kuin monissa uusissa peleissä ei ole enää perinteistä tason käsitettä ollenkaan. Työnimikkeiden muuttuessa on kuitenkin varmaa että samoja taitoja joita perinteisesti on vaadittu kenttäsuunnitelijoilta tullaan tarvitsemaan kaiken kokoisissa peliprojekteissa. Lähteet