Tuomas Suokko Pelimoottorin kehittämisen kannattavuus

Insinööri (AMK) Tieto- ja viestintätekniikka Kevät 2020

Tiivistelmä

Tekijä: Suokko Tuomas

Työn nimi: Pelimoottorin kehittämisen kannattavuus

Tutkintonimike: Insinööri (AMK), tieto- ja viestintätekniikka

Asiasanat: Pelimoottori, kannattavuus, ohjelmistokehitys, yritystoiminta

Tämän tutkimuksen tavoitteena oli selvittää, onko peliyritykselle kannattavaa kehittää oma pelimoottori, kun ilmaisia kaupallisia pelimoottoreita on markkinoilla. Tutkimuksen toimeksiantajana toimi Linna Games Oy, joka toivoi selvitettäväksi pelimoottorin kehityksen aika-arvion ja kustannukset. Linna Games Oy:n työ- harjoittelussa kehitettyyn prototyyppi 2D-pelimoottoriin ja sen kehityskokemuksiin viitattiin tutkimuk- sessa. Tutkimuksessa myös hyödynnettiin neljän eri pelialan ammattilaisten mielipiteitä ja kokemuksia pelimoottorikehityksen suhteen.

Ensin kaupallisia pelimoottoreita vertailtiin toisiinsa erityisesti niiden lisenssimaksujen suhteen. Seuraa- vaksi käsiteltiin pelimoottorin kehityksen menetelmät, hyödyt ja haitat. Tämän jälkeen omakehitteisen pelimoottorin kehityksen kustannuksia vertailtiin kaupallisten pelimoottoreiden lisenssimaksuihin. Lisens- simaksujen laskelmissa käytettiin kahta kuvitteellista peliä, joiden menestystason perusteella laskettiin käy- tettyjen pelimoottorien osuus esimerkkiyrityksen kokonaiskustannuksista.

Vaikka oman pelimoottorin kehityksen voisi nähdä eduksi sen rajattomien kehitysmahdollisuuksien nimissä, tämän suuret kustannukset ja aika-arviot eivät puoltaneet tätä kannattavampana vaihtoehtona verrattuna kaupallisiin pelimoottoreihin. Pelimoottorin kehityksen pystyisi näkemään kannattavana, jos pelimoottorin skaala olisi tarpeeksi pieni tai yrityksellä löytyisi tarpeeksi resursseja kehittääkseen erityisominaisuuksia vaativia pelejä. Toimeksiantajan kannalta pelimoottorin kehitystä ei voida nähdä erityisen kannattavana vaihtoehtona, mutta jos tämän haluavat kehittää, 2D-pelimoottoria suurempaa projektia ei suositella. Toimeksiantajalle suositeltiin Godot-pelimoottorin käyttöä tämän MIT-lisenssin vuoksi.

Pelimoottorin kehittäminen on haastava ja ajallisesti vaativa työ, jota peliyrityksen tulisi harkita omia resursseja vasten. Monet peliyritykset ovat siirtymässä pois omien pelimoottorien käytöstä kohti kaupallisia pelimoottoreita. Pelimoottorit kuten Unreal Engine ja CryEngine tarjoavat isoille yrityksille kaiken tarpeellisen laadukkaiden pelien kehitykseen ilman, että näiden kustannukset olisivat merkittäviä. Unity- ja Godot pelimoottorit tarjoavat samalla laadukkaan ja kustannustehokkaan vaihtoehdon pienimmille yrityksille ja näiden käyttämät lisenssit ovat entistä edullisempia.

Abstract

Author: Suokko Tuomas

Title of the Publication: The Profitability of Creating a Game Engine

Degree Title: Bachelor of Engineering, Information Systems

Keywords: Game engine, profitability, software development, business operations

The purpose of this Bachelor’s thesis was to determine, whether it would be profitable for a company to develop their own game engine, when there are many commercial game engines on the market with free licenses. The client of this research is Linna Games Oy, who wished to find out the needed time estimate and costs for game engine development. The author’s personal experiences in developing a prototype 2D-game engine for Linna Games Oy during his internship were used as reference. Four game industry professionals were also interviewed for their experience and opinions regarding game engine develop- ment.

First, the commercial game engines were compared to each other, especially regarding their license fees. After that, the process of developing a game engine was analyzed. With all the needed data, the total costs of using commercial game engines and developing a new game engine could be compared. To calculate the license costs of the different commercial game engines, two different games with differing success rates were compared. The costs of using the commercial game engines were calculated from the total expenditures of an example company.

While creating a game engine can be seen beneficial due to giving the creators unlimited creative possibilities, due to the expenses and time needed for development, it cannot be a more profitable solution, compared to using a commercial game engine. However, if a company has enough resources or the scale of the game engine is low enough, or the tools of commercial game engines do not meet the needs of the game being created, only then game engine development is a viable solution. For Linna Games Oy, creating a game engine cannot be seen as a viable option, but if inclined to develop one, it is not suggested to create anything larger in scope than a 2D-game engine. Godot was suggested to the client for its MIT-license.

Game engine development is a challenging and time-consuming process that game companies should only consider while taking into account their own resources. Many game companies have moved on, from updating their in-house game engines, into using commercial ones. Game engines such as Unreal Engine and CryEngine give large companies all the needed tools to create massive games without the costs having major impact. Meanwhile, game engines such as Unity and Godot give smaller companies a more cost efficient alternative.

Sisällys

1 Johdanto ...... 2

2 Pelimoottorit ...... 4 2.1 Käyttötarkoitus ja historia ...... 4 2.2 Pelimoottorien ansaintamallit ...... 5 2.2.1 Unity ...... 6 2.2.2 Unreal Engine ...... 7 2.2.3 Game Maker Studio ...... 8 2.2.4 Godot ...... 9 2.2.5 CryEngine...... 9

3 Pelimoottorin kehitys ...... 10 3.1 Pelimoottorin kehityshuomiot ...... 10 3.2 Linna Games Oy:n pelimoottorin kehitys ...... 12 3.3 Pelimoottorin kehittämisen hyödyt ja haitat ...... 14 3.4 Pelimoottorin kehityksen kannattavuus ...... 15

4 Kaupallisen pelimoottorin valitseminen ...... 17 4.1 Kaupallisen pelimoottorin valinta pelinkehityksen kannalta ...... 17 4.2 Kaupallisen pelimoottorin valinta taloudelliselta näkökulmalta...... 21

5 Kokemuksia pelialan kehittäjiltä ...... 23 5.1 Ari Arnbjörnsson (Housemarque) ...... 23 5.2 Zach Laster (Critical Charm) ...... 24 5.3 David Barr (javidx9 Youtube-kanava) ...... 25 5.4 Mathilde Nord (Avalanche Studios) ...... 27

6 Pohdinta ...... 28

7 Yhteenveto ...... 31

Lähteet ...... 32

Liitteet

1

Sanastoluettelo

2D-peli: Peli, jonka visuaalinen tyyli muodostuu kaksiulotteisesta grafiikasta.

3D-peli Peli, jonka visuaalinen tyyli muodostuu pääosin kolmiulotteisesta grafiikasta.

API: Application Programming Interface. Ohjelmointirajapinta. Joukko funktioita ja menettelytapoja, jotka mahdollistavat sovellusten kehityksen, joilla on pääsy käyttöjärjestelmän ominaisuuksiin tai tietoihin.

Asset: Kaikki mitä voi kuulua peliin, mukaan lukien grafiikka, äänet, koodi ja työkalut pelinkehitykseen.

Avoin lähdekoodi: Koodi, joka on vapaasti saatavilla ilman käyttörajoituksia.

Graafinen käyttöliittymä: Tietokoneohjelmiston interaktiivinen visuaalinen esitystapa.

Indie: Itsenäinen pelinkehittäjä, joka ei kehitä pelejä suurelle peliyritykselle.

Refaktorointi: Ohjelmistokoodin uudelleenjärjestäminen tai -kirjoittaminen.

Renderöinti: Graafisen kuvan toteuttaminen tietokoneen näytölle.

Skriptikieli: Ohjelmointikieli, jonka kirjoitetusta ohjelmasta käännettyä koodia tulkitaan ajon aikana, sen sijaan että koodia täytyisi kääntää konekielelle ennen ajoa.

Sprite-arkki: Kuvatiedosto, joka sisältää useita pienempiä kuvia laatoitetussa ristikkojärjestyksessä. 2

1 Johdanto

Tämän tutkimustyön tavoitteena on selvittää, missä tilanteissa peliyritys voisi kokea oman pelimoottorin kehityksen taloudellisesti kannattavana vaihtoehtona. Viimeisen kymmenen vuoden aikana kaupalliset ilmaispelimoottorit ovat olleet suuressa suosiossa Indie-pelikehittäjien joukossa ja monet pelialan yritykset ovat nyt siirtyneet pois omien pelimoottorien käytöstä kohti kaupallisia pelimoottoreita. [1.] Tavoitteena on selvittää syyt, miksi peliyritykset ovat siirtyneet pois oman pelimoottorin kehityksestä.

Tutkimuksen toimeksiantajana toimii Linna Games Oy, joka on toivonut tutkimuksen selvittävän pelkistetyn 2D-pelimoottorin lopulliset kustannukset ja aika-arvion. Pelkistetyksi luokitellaan tässä tutkimuksessa pelimoottori, joka ei sisällä graafista käyttöliittymää ja jolla voisi lopulta kehittää esimerkiksi 2D-tasohyppelypelejä. Näihin kustannuksiin otetaan huomioon, että pelimoottoria kehittää vain yksi henkilö. Lopullisten kustannusten perusteella voidaan päätellä, olisiko firman järkevämpi hyödyntää valmiita kaupallisia moottoreita ottaen huomioon näiden pelimoottorien mahdolliset tekijänoikeusmaksukustannukset.

Tutkimusta varten on myös haastateltu eri pelialan ammattilaisia, joilla on pitkä pelimoottori- kehityshistoria takanaan. Tutkimuksen tueksi otan huomioon myös omat kokemukset 2D-peli- moottorien kehityksessä. Oman harjoittelukauteni aikana työstin Linna Games Oy:lle yksinkertai- sen 2D-pelimoottorin. Harjoittelun tavoitteena oli osoittaa Linna Games Oy:lle, kuinka lyhyessä ajassa voi pelkistetyn pelimoottorin prototyypin luoda.

Pelimoottorin taloudellista kannattavuutta voidaan ensin mitata sen perusteella, millaisia pelejä sillä on lopulta tarkoitus kehittää. Seuraa kuitenkin kysymys, minkä vuoksi peliyrityksellä olisi tarvetta kehittää oma pelimoottori, koska ilmaiset pelimoottorit tarjoavat lähes kaiken, mitä pelinkehitykseen tarvitaan. Pelifirmojen itsensä kehittämillä pelimoottoreilla voidaan luoda järjestelmiä, jotka antavat kehityksellisiä vapauksia, joita muut moottorit eivät pysty tarjoamaan. Pelimoottorien sisäiset järjestelmät ovat usein suunniteltu toteuttamaan niitä erityisiä tarpeita, mitä pelifirma tarvitsee oman pelinkehityksensä kannalta. Näihin tarpeisiin voi kuulua pelimaailmojen luomisen helpottaminen, jota Bethesda Game Studios hyödyntää Creation Enginen avulla, nopeaa ja joustavaa graafista renderöintiä, jota Valve on hyödyntänyt Source- moottoreillaan tai tarinankerronnallisia työkaluja, joita CD Projekt Red käyttää REDengine 3

-moottorillaan. On huomioitava, että edellä mainittujen pelifirmojen pelimoottorit ovat olleet jat- kuvassa kehityksessä jopa kymmeniä vuosia, joten oman moottorin kehittäminen vertailtavaan laatuun lyhyessä ajassa olisi mahdotonta. [2.] [3.] [4.]

Pelimoottorien käyttö ei tule usein ilman kritiikkiä. Bethesda Game Studios julkaisemastaan pelistä Fallout 76 sai suuren määrän negatiivista palautetta, josta iso osa koski pelin käyttämää pelimoottoria. Fanit ihmettelivät valtavaa määrää ohjelmointivirheitä, jotka olivat yleisiä jo Bethesdan edellisessä pelimoottorissa Gamebryo. Tämä on johtanut tilanteeseen, jossa fanit epäilivät tulevien pelien laatua jo etukäteen, jos Bethesda käyttää vielä samaa pelimoottoria [5.]. Unity-pelimoottorilla tehdyt pelit ovat saaneet kielteistä palautetta, sillä pelimoottorin suuren amatöörikäyttäjäkunnan kehittämät keskinkertaiset pelit ovat täyttäneet suosituimman pelikauppasivuston Steamin tarjontaa. Pelimoottorien kehittämä brändi voi vaikuttaa pelin myyntiin yhtä lailla kuin niiden graafiset ominaisuudet ja teknologiset mahdollisuudet. [6.]

4

2 Pelimoottorit

Tässä luvussa kuvataan pelimoottoreiden toiminnalliset kokonaisuudet sekä suosittujen kaupallisten pelimoottorien käyttämät rahoitusmallit. Pelimoottorien rahoitusmalleissa otetaan huomioon niiden käyttöehdot, mahdolliset kauppasivustot ja niiden asettamat tekijänoikeusmak- suehdot.

2.1 Käyttötarkoitus ja historia

Pelimoottori voidaan määritellä yksinkertaisena ohjelmointirunkona pelien kehitykseen. Tutkiel- massaan ”History and comparative study of modern game engines” tutkijat Partha Sarathi Paul, Surajit Goon ja Abhishek Bhattacharya määrittelevät pelimoottorin “alustana, joka hoitaa yleisiä tehtäviä, kuten renderöintiä, fysiikkaan liittyviä laskelmointeja ja syötteitä, jolloin pelinkehittäjät voivat keskittyä yksityiskohtiin, jotka tekevät peleistänsä uniikkeja” [7.]. Pelimoottoreita voi verrata luurankoon ja lihaksistoon, jotka pitävät sen avulla rakennetun pelin pystyssä ja toiminta- kelpoisena. Niiden avulla ohjelmointikoodi ja graafinen työ yhdistyvät pelikokonaisuudeksi.

Videopelien kehityshistorian alussa pelejä kehitettiin ilman mitään alustustyötä suoraan alla olevan laitteiston päälle. Vasta 1990-luvun alussa id Softwaren kehittämän pelin Doomin jälkeen uudelleenkäytettävä ohjelmistokoodi nähtiin eduksi pelienkehityksessä, sillä tämä leikkasi ohjelmointiaikaa huomattavasti. [8.]

Pelikehittäjien ei tarvinnut pelimoottoreilla tehdä enää samoja alustustöitä jokaiseen peliprojektiin, vaan he pystyivät suoraan toteuttamaan pelillisiä ominaisuuksia ja piirtämään grafiikkaa näyttöihin. Doom-pelin aivan uusi pelimoottori Id Tech 1 käytti id Softwaren aiemmin julkaistun pelin Wolfenstein 3D:n pelimoottoria pohjana. Doomin julkaisun jälkeen id Software jatkoi tämän pelimoottorin kehitystä ja käytti id Tech 1 -pelimoottoria pohjana tekemiinsä peleihin vuoteen 1997 asti [9.]. Tämän jälkeen id Tech-pelimoottori on ollut jatkuvassa kehityksessä tähän päivään asti uusilla versioilla ja nykyisellä versiollaan id Tech 7:llä luotiin Doom-pelisarjan uusin tuotos Doom Eternal, joka julkaistiin 20.3.2020. [10.]

5

2010-luvun alussa indie-pelienkehittäjien käytetyimmät pelimoottorit olivat tuolloin Unity ja Game Maker Studio. Kun näillä pelimoottoreilla kehitetyt pelit menestyivät, ne samalla keräsivät pelimoottoreille huomiota ja kasvavaa käyttäjäkuntaa [11.]. Unity Technologies on ilmoittanut verkkosivuillaan, että puolet pelimarkkinoiden peleistä on kehitetty Unityn pelimoottorilla. Syy Unity-pelimoottorin suureen suosioon johtuu tämän hinta-laatu-suhteesta tavalliseen itsenäiseen kehittäjään nähden [12.]. TechCrunchin artikkelissa ”How Unity build the world’s most popular game engine” viitataan Clayton Christensenin “Disruptive innovation” -teoriaan: pelimoottorit, jotka keskittyvät monien miljoonien peliyritysten tarpeisiin uusimmilla teknologioilla, jättävät Unitylle käyttöönsä itsenäisten kehittäjien markkinaraon. Tällä markkina- raolla ne voivat kehittää vähemmän tehokkaan pelimoottorin, joka kuitenkin riittäisi näiden kehittäjien tarpeisiin. [13.]

Unity-pelimoottorin käyttäjäystävällisyys ja laaja käyttäjäkunta avustusvideoineen ovat antaneet uusille pelinkehittäjille aloittelijaystävällisen kuvan. Tämä käyttäjäystävällisyys on vahventunut Unityn siirryttyä pois maksumuurista kohti maksutonta järjestelmää, joka pakottaa käyttäjän maksulliseen lisenssiin vain, jos moottorilla kehitetty peli on ylittänyt määrätyn tulorajan. [14.]

2.2 Pelimoottorien ansaintamallit

Pelimoottorit hyödyntävät useimmiten yhtä ansaintamallivaihtoehtoa kolmesta. Ensimmäinen näistä on ilmainen Massachusetts Institute of Technology lisenssi eli MIT-lisenssi. Tämä takaa käyttäjälle täyden oikeuden käyttää, kopioida, yhdistää, julkaista, jakaa, ali-lisensoida ja/tai myydä kopioita kyseistä lisenssiä käyttävää ohjelmistoa, niin kauan kunnes seuraava tekijänoikeusilmoitus löytyy kaikista ohjelmiston luoduista kopioista.

” THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPY- RIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.” [15.]

6

Seuraava käyttöoikeusvaihtoehto on ilmaislisenssi, joka takaa käyttäjälle ilmaisen käyttöoikeuden kehitysohjelmistoon, mutta pelimoottorilla on oma tekijänoikeusmaksuehto. Tämä takaa tietyn prosentin kaikista tuotoista pelimoottorin kehittäjille pelimoottorilla luodusta pelistä, jos pelin tuotot ylittävät pelimoottorin kehittäjien määräämän rajan. Toinen ehto voi olla lisenssimaksun päivitys versioon, joka vaatii käyttäjän maksamaan kuukausimaksua moottorin käytöstä peli- moottorin kehittäjille. [16.]

Kolmas vaihtoehto on maksullinen lisenssi. Tätä vaihtoehtoa käyttävät pääasiassa suurituloiset peliyritykset, joilla on oma moottori kehitettynä. Esimerkkinä id Softwaren kehittämä id Tech 3 -pelimoottorin käyttölisenssihinta muille yrityksille oli 500 000 dollarin rajoilla per tehty peliprojekti. [17.]

Sivutuloina pelimoottorien kehittäjät hyödyntävät pelimoottorin kauppasivuston ylläpitoa. Kauppasivuston tarkoitus on antaa käyttäjille mahdollisuus myydä joko pelejään tai pelinkehitys- tuotteita. Nämä tuotteet, joita kutsutaan termillä ”asset”, voivat olla joko koodia, grafiikkaa, äänitiedostoja tai työkaluja pelinkehitykseen. Näillä kauppapaikoilla suosituimpien komponenttien kehittäjät voivat tienata oman elantonsa ja pelimoottorin kehittäjät ottavat oman prosentuaalisen osuuden kaikista kauppapaikalla myydyistä tuotteista. [18.]

2.2.1 Unity

Unity Technologiesin kehittämä Unity-pelimoottori on käyttänyt ilmaislisenssimallia vuodesta 2016 alkaen. Ennen tätä Unity-moottori käytti kertamaksulisenssiä, joka salli moottorin käytön hintaan 1500 €, jonka pystyi maksamaan 75 € kuukausimaksulla. [19.]

Yritykset voivat ladata ja käyttää Unity-moottoria peliprojekteihin ilman alustavia lisenssimaksuja. Maksuraja tulee vastaan vain, jos käyttäjä on kehittänyt tuotteen Unity-moottorilla ja tämän tuotteen tuotot ovat olleet yli 100 000 dollaria viimeisen kahdentoista kuukauden aikana. Tämä velvoittaa käyttäjiltä lisenssin päivittämistä joko Unity Plus- tai Unity Pro -malleihin. Unity Plus-malli sisältää 40 dollarin kuukausimaksun, mutta tämä tarjoaa käyttäjälle laadukkaita oppimisresursseja, Live-Ops-analytiikkatyökaluja ja reaaliaikaista pilvidiagnostiikkaa. [20.] 7

Unity Plus tarjoaa käyttäjille mahdollisuuden muokata pelin aloitusruutua. Ilmaisversio Unity- moottorista pakottaa kehittäjien sisällyttämään peleihinsä aloitusruudun, joka ilmoittaa pelaajille, että peli on tehty Unity-moottorilla. Unity-moottori on kehittänyt itselleen vuosien myötä vaikutelman huonolaatuisena ja halpana moottorina suuren amatöörikehittäjäkäyttäjä- kunnan vuoksi. Tämän vuoksi on kehittäjiä, jotka päivittävät Unity Plus -lisenssiin vain saadakseen tämän aloitusruudun poistettua ja saadakseen korkealaatuisemman vaikutelman heidän kehittämistään tuotteista. [6.] [21.]

Jos Unity-moottorilla on kehitetty tuote, joka on tuottanut tuloja yli 200 000 dollarin edestä viimeisen kahdentoista kuukauden aikana, Unityn käyttöehdot vaativat päivittämistä Unity Pro -lisenssiin. Unity Pro -lisenssiin kuuluu 150 dollarin kuukausimaksu, johon kuuluu kaikki, mitä Unity Plus -lisenssi sisältää, mukaan lukien korkean prioriteetin asiakaspalvelua, tukea ja pääsyä Unity-moottorin lähdekoodiin. [20.]

Jos yrityksellä ei ole viimeisen 12 kuukauden aikana ollut yli 100 000 dollarin tuloja ja kaikki muut tilauksen maksut on maksettu, niin vasta tällöin tilauksen voi peruuttaa ja siirtyä takaisin Unity- moottorin ilmaislisenssiin. Kuukausimaksujen kuluissa yritysten on hyvä huomioida, että hintaan ei kuulu EU-alueella olevaa arvonlisäveroa. [16.]

Unity Technologies on hyödyntänyt ansaintamalleissaan ”Unity Asset Store” -kauppasivustoa 10. marraskuuta 2010 alkaen. Kauppasivustolla myynnissä olevista pelinkehitystuotteista Unity ottaa 30 prosentin osuuden kaikista käyttäjien kehittämistä myyntituotteista. Vuonna 2018 Unity Technologies ilmoitti, että sen kauppasivustolla oli tehty yli 40 miljoonaa latausta. [22.] [23.]

2.2.2 Unreal Engine

Epic Gamesin kehittämä Unreal Engine 4 on käyttänyt ilmaislisenssimallia vuodesta 2015 alkaen. Unreal Enginen lisenssimaksuraja tulee vastaan 3000 dollarin jälkeen, jolloin kehittäjä on velvoitettu maksamaan 5 prosenttia tekijänoikeusmaksuja kaikista pelin tuloista. Epic Games antaa ehdoissaan esimerkin: ”Jos tuotteen tulot ovat 10 dollaria, niin Applen App Store ottaa tuloista 30 prosentin jakelumaksuosuuden, Epic Games taas ottaa 5 prosentin osuuden koko tulosta”. Tekijänoikeusmaksut ja tuotekohtainen maksuraportti tulee lähettää Epic Gamesille 45 päivän sisällä jokaisen kalenterineljänneksen jälkeen. [24.] [25.] 8

Epic Games hyödyntää myös ”Unreal Engine Marketplace” kauppasivustoa ansaintamallissaan. Yrityksen kauppasivustolla käyttäjien myymistä tuotteista otetaan 12 prosentin osuus [26.]. Tämä muutettiin 30 prosentista vuonna 2018, sillä Epic Gamesin julkaisema Fortnite Battle Royal muuttui sen pääasialliseksi tuottonsa lähteeksi. Tuloja maksetaan kehittäjille vasta jokaisen 100 dollarin myyntitulojen jälkeen. Myyntiprosentin muutos on nähty strategisena päätöksenä erottua pelimoottorimarkkinoilla, sillä tämä on pelimoottorikauppasivustojen pienin tulojenjako- prosentti. [27.]

2.2.3 Game Maker Studio

Yoyo Gamesin kehittämä Game Maker Studio 2 sisältää sekä kertamaksuvaihtoehdot että kuukausimaksuvaihtoehdot. Kertamaksuvaihtoehdot nousevat hinnassa sen mukaan, mille alustoille haluaa kehittää pelejä. Kertamaksuvaihtoehdot ovat seuraavat (taulukko 1):

Alusta Hinta PC, Mac, Ubuntu $ 99 HTML5 $ 149 Universal Windows Platform & $ 199 Xbox Creators Program iOS & Android mobiililaitteet $ 199 Taulukko 1. Game Maker Studio 2:n kertamaksuvaihtoehdot [28.]

Game Maker Studio 2 -moottorille voi myös hankkia 12 kuukauden käyttölisenssin. Tietokonealustalisenssin tälle ajalle voi ostaa 39 dollarilla ja modernien pelikonsolien (Xbox One, Playstation 4, Nintendo Switch) kehityslisenssit voi ostaa samalle ajalle hintaan 799 dollaria per konsoli. Vaihtoehtona annetaan myös mahdollisuus kehittää jokaiseen moderniin pelikonsoliin yhdessä hintaan 1500 dollaria. [28.]

Yoyo Games hyödyntää myös ansaintamallissaan kauppasivustoa. Kyseisellä kauppasivustolla kehittäjät voivat myydä pelinkehityskomponentteja, kuten muiden moottoreiden kauppasivustoilla sekä kehittäjät voivat myydä Game Maker Studio 2 -moottorilla kehitettyjä pelejä. Kaikista myydyistä tuotteista Yoyo Games ottaa 30 prosentin osuuden tuotoista. [29.] 9

2.2.4 Godot

Godot-pelimoottori käyttää MIT-lisenssiä, joten Godot ei käytä mitään ansaintamallia. Godot -pelimoottorin kehittäjät pitävät moottorin kehitystä yllä järjestämällä kuukausittaisen Patreon-rahankeruun. Pelimoottorin kehittäjille voi lahjoittaa eri hintatasojen mukaan ja lahjoituksista saa erilaisia korvauksia lahjoituksen suuruuden mukaan. Vuoden 2020 huhtikuun aikana Godot-moottori oli kymmenen päivän sisällä kerännyt yli 10 000 dollaria lahjoituksia yli 1200 lahjoittajalta. Näillä lahjoituksilla Godot-moottorin kehittäjät pääasiassa palkkaavat kehittäjiä moottoria varten. [30.] [31.]

Helmikuussa 2020 Godot perusti oman kauppasivustonsa Godot Marketplace. Godot Marketplace ottaa 30 prosentin osuuden käyttäjien myymistä tuotteista, joista 20 prosenttia menee kauppasivuston omistajilla ja ylläpitäjillä VicCircle GmbH:lle ja 10 prosenttia menee suoraan Godot-pelimoottorin kehitykseen. [32.]

2.2.5 CryEngine

Crytekin kehittämä CryEngine käyttää tekijänoikeusmaksulisenssimallia. Moottorin käyttö on kehittäjille ilmaista, mutta julkaistuista peleistä Crytek ottaa 5 prosentin osuuden, jos julkaistun pelin tuotot ylittävät 5000 dollarin rajan. Crytekin kauppasivusto CryEngine Marketplace ottaa myös 30 prosentin osuuden jokaisesta käyttäjän myymästä tuotteesta. [33.]

10

3 Pelimoottorin kehitys

Tässä luvussa esitellään pelimoottorin kehitysaskeleita. Tulen ottamaan analyysissä huomioon myös oman kokemukseni 2D-pelimoottorien kehityksestä. Luvussa käydään läpi pelimoottorin kehitysvaiheet, toteutussuunnitelma, riskit sekä kehittämisen aikataulu. Lopulta analysoin, millaisissa tilanteissa pelimoottorin kehittäminen olisi taloudellisesti kannattava vaihtoehto.

3.1 Pelimoottorin kehityshuomiot

Pelimoottorin kehitys pitäisi aloittaa pohtimalla pelimoottoriprojektin elinkaarta. Pelimoottorin perimmäinen tarkoitus on säästää aikaa pelien kehityksessä. Tämän vuoksi peliyrityksen on hyvä suunnitella moottori kelvolliseksi minimaalisella muokkauksella peliprojektien välillä. Mitä enemmän pelejä voi toteuttaa minimaalisin muutoksin pelimoottorin koodiin, sitä kannattavampi vaihtoehto tämä olisi. Ubisoft tunnetusti hyödynsi Assassin’s Creed -pelin hiipimispelimekaniikkaa uudelleen Watch Dogs -pelissä. Pelimekaniikka itsessään oli noin 100 000 riviä koodia, joten koodin uudelleenkäyttö antaa moottorille enemmän arvoa. [34.]

Peliyrityksen on myös huomioitava, että pelimoottorien kehitys vie huomattavan paljon aikaa ja resursseja. Yksinkertaisen moottorin toteutus voi viedä keskimäärin kolme kuukautta ennen kuin sillä voi kehittää yksinkertaisia pelejä ja kehittyneet moottorit vievät useita vuosia kehitysaikaa [35.]. Peliyrityksen on päätettävä, haluaako se kehittää pidemmän ajan pelimoottoria ennen kuin se voi työstää pelejä, vai jakaa resursseja siten, että osa tiimistä tuottaa pelimoottoria ja toinen osa pelejä.

Michael Kissner jakaa artikkelissaan ”Writing a Game Engine from Scratch” moottorin kehityksen viiteen osaan. Ensimmäisenä tulee olla tarkka suunnitelma siitä, mitä pelimoottorin on kyettävä tekemään sekä mitä sen ei tarvitse tehdä. Seuraavaksi tulee organisoida pelimoottorin tarpeet järjestelmiksi, joita moottori tulee käyttämään. Kolmantena tulisi suunnitella ohjelmistoarkkiteh- tuuri, joka yhdistää kaikkia näitä järjestelmiä. Neljäs ohje on parannella nämä suunnitelmat loppuun asti, kunnes viidennen ohjeen mukaan voi aloittaa ohjelmoinnin. [36.]

11

Pelimoottorin kehityksen seuraava huomioitava kriteeri on sen käyttämä ohjelmointikieli. Pelimoottoreita voi toteuttaa millä tahansa ohjelmointikielellä, mutta sen tarpeet tulevat määräämään kielen. Valtaosa kaupallisista pelimoottoreista on rakennettu käyttäen C++-ohjel- mointikieltä, vaikka pelienkehitys tapahtuisi toisella ohjelmointikielellä [37.]. C++-ohjelmointi- kieltä pääasiassa käytetään, sillä se tarjoaa kehittäjille nopeata suorituskykyä, tehokasta resurssinhallintaa ja skaalautuvuutta. [38.]

Pelimoottoreihin voi myös kehittää skriptikielten käyttömahdollisuuden. Skriptikielet nähdään usein pelienkehityksen kannalta hyödyllisenä, sillä tämä mahdollistaa nopeampaa muokkaamista kehitysprosessissa. Tämä sen vuoksi, koska pelimoottorin koodi käännetään toimivaksi kääntö- ajassa, joka voi kestää useista minuuteista tunteihin. Skriptikoodia voidaan päivittää ajoaikana, eli peliä ei tarvitse uudelleen kääntää ja käynnistää, jos haluaa nähdä tekemiään muutoksia pelissä. Skriptikielet antavat myös yksinkertaisemman ohjelmointikielen käyttöön kehittäjille, joilla on vähemmän osaamista ohjelmoinnin suhteen. [39.]

Ohjelmointikielen valinta tulee vaikuttamaan myös renderöintiohjelmointirajapinnan valintaan. Laajimman käyttäjäkunnan vuoksi on hyvä valita järjestelmäriippumaton API, eli ohjelmointi- rajapinta, joka mahdollistaa jokaiseen käyttöjärjestelmään kehitysmahdollisuuden. Eri renderöinti-API:t voivat olla suunniteltu pelkästään 2D-grafiikan toteutukseen, joten jos peli- moottorin kehitystulevaisuudessa on tarkoitus toteuttaa kolmiulotteista grafiikkaa, ajansäästön vuoksi on hyvä valita projektin alussa API, joka pystyy toteuttamaan tätä. Pelimoottorin renderöintikoodikerroksen voi toteuttaa myös API-agnostisesti, joka tarkoittaa, että koodia on kirjoitettu tukemaan kaikkia mahdollisia API-vaihtoehtoja. Tämä mahdollistaa tulevaisuudessa helpomman renderöinti-API:n vaihtamisen, jos tuleva peliprojekti vaatii sitä. [40.]

Fysiikan simuloinnin toteutusta on hyvä suunnitella etukäteen pelimoottoria varten. Oman fysiikkamoottorin toteutus voi viedä yhtä pitkän ajan kuin pelimoottorin toteutus, joten vaihtoehtoisesti voi hyödyntää valmiita ja avoimen lähdekoodin fysiikkamoottoreita kehittäjiltä. Fysiikkamoottorit, kuten Box2D, sisältävät kaikki tarvittavat monimutkaiset matemaattiset koodit fysiikan simulointia varten. [41.]

Muita huomioitavia seikkoja ovat tiedostotuki, ohjaintuki, kokonaiskomponenttijärjestelmä (ECS), muistinhallinta ja ohjelmointivirheenkorjausjärjestelmä. Kun tämän kaiken ottaa huomioon kehityksessä, pelimoottorin optimaalinen luominen voi olla erittäin kannattavaa pitkässä ajan juoksussa. [40.] 12

3.2 Linna Games Oy:n pelimoottorin kehitys

Kun pelimoottoria aloitettiin kehittämään, tarkoituksena oli luoda mahdollisimman yksinkertainen 2D-pelimoottori, joka sisältäisi vain välttämättömät komponentit pelienkehitykseen. 2D-pelimoottorin kehitys ei ole ongelmallinen erityisesti ajan suhteen, sillä tämä pelkistetty pelimoottori oli valmis käytettäväksi kahden kuukauden kehitysajan jälkeen. Kehitysaikaa pystyi säästämään, kun ei tarvinnut työstää 3D-pelimoottoreita varten tarvitsevaa monimutkaista matematiikkaa tai mahdollista graafista käyttöliittymää. Pelimoottori toimi pelkästään koodin ja ulkoisten tiedostojen avulla.

Yksi esimerkki pelimoottorin ominaisuuksista on graafisten tiedostojen lukeminen. Kehittäjä pystyisi käyttämään pelinkehityksessä ”sprite-arkki”-kuvatiedostoja, joiden tarkoitus on sisällyttää useita kuvia yhdessä tiedostossa. Esimerkki sprite-arkista löytyy kuvasta 1. Näiden tarkoitus on vähentää tarvittavien ulkoisten tiedostojen määrää, sillä sen sijaan, että olisi lukuisia erillisiä 2D-graafisia tiedostoja, nämä kaikki tarvittavat kuvat voidaan sijoittaa yhteen tiedostoon. Pelimoottorin avulla voi sitten helpommin ottaa halutun kuvan käyttöön sprite-arkista.

Kuva 1. Esimerkki sprite-arkista. [42.] 13

Jos omakehitteinen pelimoottori ei sisällä graafista käyttöliittymää, tämä voi osoittautua hankalakäyttöiseksi esimerkiksi artisteille ja suunnittelijoille, jos he eivät ole kokeneita ohjelmoijia. Pelimoottorien kehittäjät eivät välttämättä halua luoda hankalakäyttöisiä pelimoottoreita, mutta tiukat kehitysaikarajoitukset voivat johtaa tähän. On tärkeää, että pelimoottoria suunnitellaan koko kehitysryhmä huomioiden, esimerkiksi kehittämällä pelinkehitystyökaluja.

Esimerkkinä työkaluista Linna Games Oy:n pelimoottoriin kehitettiin Tiled-ohjelmiston tuki. Tiled antaa suunnittelijoille työkalun kehittää peleihin kenttiä ilman, että joutuisi ohjelmoimaan. Antamalla Tiled-ohjelmistolle sprite-arkin suunnittelija voi piirtää kenttiä. Esimerkin Tiled-ohjelmiston toiminnasta voi nähdä kuvasta 2. Luoduista kentistä Tiled muodostaa oman tiedoston, jota lopulta pelimoottori pystyi lukemaan ja esittämään ruudulla.

Kuva 2. Tiled-ohjelmiston näkymä. [43.]

Yksi ongelma omatekoisen moottorin käytössä on sen opettaminen toisille käyttäjille. Kun omaa pelimoottoria on kehittänyt, tämän mahdolliset epäjohdonmukaisuudet, jotka itse saattaa tuntea, voi olla toiselle käyttäjälle hankala omaksua. Pelimoottorin käytöstä löytyy dokumentaatiota ja esimerkkikoodia käyttäjille, mutta käyttäjäomaksumista ei ole testattu. Tärkeätä on, että moottorin kehittämisen ohella huomioidaan myös muiden käyttäjien käyttökokemus ettei pelimoottori lopulta kehity liian hankalakäyttöiseksi. Kaupallisilla pelimoottoreilla on etuna se, että peliyritys voi vaatia palkatuilta henkilöiltä niiden osaamista etukäteen ennen palkkausta. Omatekoisten pelimoottorien käytön suhteen voi vaatia esimerkiksi käytettävän ohjelmointikielen osaamista. 14

3.3 Pelimoottorin kehittämisen hyödyt ja haitat

Pelimoottorin kehityksen suurin hyöty tulee sen järjestelmien täydellisestä tuntemuksesta ja kontrollista. Kokonaisuuden tunteminen helpottaa jatkuvaa kehitystä ja moottorin muokkaamista. Muutamien kaupallisten pelimoottorien suurin heikkous on estää kehittäjiä katsomasta tai muokkaamasta pelimoottorin koodia. Esimerkiksi jos projektissa tulee ohjelmoinnissa vastaan koodivirhe moottorin puolelta ja moottori ei salli käyttäjän muokkaavan pelimoottorin tiedostoja, kehittäjät joutuvat odottamaan seuraavaan päivitykseen, kunnes voivat kehittää eteenpäin senhetkistä järjestelmää. Omien moottorien ja avoimen lähdekoodin pelimoottorien suurin etu on, että kehittäjät voivat korjata nämä ongelmat välittömästi pelimoot- torin puolelta ja tällöin jatkaa omaa projektia kuluttamatta kehitysaikaa odotteluun. [44.] [45.]

Kaupallisissa pelimoottoreissa voi olla käyttöehtoja, jotka estävät tietynkaltaisten projektien kehittämisen. Esimerkiksi Crytek ei salli uhkapelien luomista CryEngine-pelimoottorillaan ja Unity- moottorin uhkapelilisenssi voi olla liian kallis yrityksille. Tästä syystä Godot-pelimoottori on kerännyt suosiota uhkapelimarkkinoilla, sillä sen MIT-lisenssi ei estä kehittäjiä luomasta uhkapelejä [46.]. Esimerkiksi Veikkaus on tämän vuoksi kehittänyt omia pelimoottoreitaan rahakoneautomaatteja varten, jotta se voi parantaa yhtiön tulevaisuuden tuotantokyvykkyyttä ja kustannustehokkuutta. [47.]

Oman pelimoottorin kehitys edellyttää sen, että se sisältää vain kehittäjälle tarpeelliset ominaisuudet. Monien kaupallisten pelimoottorien ongelma on, että ne sisältävät paljon ylimääräisiä ominaisuuksia, joita moni kehittäjä ei tule koskaan käyttämään pelikehityksensä aikana. Nämä turhat ominaisuudet johtavat tavallista suurempiin tiedostokokoihin, jotka ovat erityisesti ongelmallisia, jos pelin tiedostokoon on tarkoitus pysyä pienenä. Unreal Engine -pelimoottorilla tehty tyhjä projekti voi olla esimerkiksi kooltaan yli 100 Mb. [48.]

Pelimoottorin kehityksen suurimpia heikkouksia on kehitysaika, jos tarkoituksena on kehittää pelejä. Pitkät kehitysajat pitkittävät pelienkehityksen aloittamista. Jatkokehityksessä, jos omaa pelimoottoria täytyy päivittää seuraavaa peliprojektia varten, tämä vie ohjelmointiaikaa pois pelinkehityksestä. Pelimoottorin huono suunnittelu voi johtaa tilanteisiin, joissa uusien ominaisuuksien lisääminen hankaloituu ajan myötä jatkuvasti, mikä voi pahimmassa tapauksessa johtaa pelimoottorin koodin uudelleenkirjoitukseen eli refaktorointiin. 15

3.4 Pelimoottorin kehityksen kannattavuus

Pelimoottorien kehityksen kannattavuus tulee olemaan täysin riippuvainen siitä, mitä tarpeita pelimoottorin tulee täyttää. Uusien ominaisuuksien lisääminen tulee vaatimaan oman kehitysjakson, joka voi kestää useita kuukausia. Nämä kuukaudet sisältävät ominaisuuden suunnittelun, toteutuksen, testaamisen, ohjelmointivirheiden korjaamisen, mahdollisen refaktoroinnin ja toisen testauksen, kunnes pelimoottori on valmis käytettäväksi. Kannattavuus itsessään vähenee moninkertaisesti, kun kehitetään 3D-pelimoottoria, sillä moottorin käyttämä matematiikka on merkittävästi monimutkaisempi verrattuna 2D-matematiikkaan. Tämä johtaa hankalampaan optimointiin, joka vie enemmän kehitysaikaa. [49.]

Joitain ominaisuuksia voidaan täyttää hyödyntämällä väliohjelmistoa. Väliohjelmisto on tarkoitettu liitettäväksi ohjelmointiprojekteihin suorittaakseen jotain erityisiä ominaisuutta. Pelimoottorien kehityksessä tulisi pääasiallinen tarkoitus olla pelien kehitys eikä esimerkiksi fysiikan simulointi tai äänen tuottaminen. Tämän vuoksi 2D-pelimoottoreissa usein hyödynnetään Box2D -fysiikkamoottori-väliohjelmistoa, jotta peli voisi käyttää realistista fysiikan simulointia eri pelimekaniikoissa. Rovio Entertainmentin Angry Birds on tunnetusti käyttänyt Box2D:tä pelihahmojen heittämisen ja rakennelmien tuhoamisen simulointia peleissään. [50.]

Peliyritys Blind Mystics artikkelissaan ”Create your own Game Engine but don't ever use it” kertoi pelimoottorikehityskokemuksistaan, minkä vuoksi ne lopulta otti Unity-pelimoottorin käyttöön. Ensimmäisen kehitysvuoden jälkeen 3D-pelimoottorinsa oli valmis käytettäväksi, mutta sisälsi vain murto-osan ominaisuuksista, joita kaupalliset moottorit sisälsivät. Aina kun uusi ominaisuus lisättiin, peliprototyypit piti päivittää toimivaksi päivitetyllä pelimoottorilla. Tämä ylimääräinen kehitysaika hidasti lopullisen projektin valmistumista liian paljon. Toisena on- gelmana tuli myöhäinen yhteensopivuuden kehitys konsoleille ja iOS-mobiilialustalle. Blind Mystics kokivat, että moottorin budjetti kaksinkertaistuisi, jos ne pyrkisivät enää näitä yhteensopivuuksia lisäämään niiden pelimoottoriin. [51.]

16

Yossarian King artikkelissaan ”Opinion: Why On Earth Would We Write Our Own Game Engine?” esittää, että ongelma pelimoottorien kehityksessä tulee vastaan niiden lopullisissa kustannuksissa. Heidän yrityksessänsä kustannukset tulisivat olemaan lähemmäs 100 000 dollaria, kunnes moottori olisi käyttökelvollinen. Samalla hinnalla he pystyisivät lisensoimaan monia kymmeniä kappaleita sen aikaisia Unity Pro -lisenssejä. Hän tuo artikkelissaan myös esille, että jos peliyrityksellä on oma pelimoottori jo käytössä, siitä pois siirtyminen voi johtaa omiin ongelmiin. Hän tuo esille esimerkin, missä EA Black Boxin julkaisema peli Need for Speed: The Run vaihtoi pois omatekoisesta pelimoottorista Frostbyte 2 -pelimoottoriin. Kyseinen pelimoottori oli erityisesti suunniteltu ammuntapelejä varten ja tämän koodin muokkaaminen toimivaksi ajopeliin vei vuoden kehitysaikaa. [52.]

17

4 Kaupallisen pelimoottorin valitseminen

Tässä luvussa esitellään kriteereitä, joiden vuoksi peliyritys haluaisi valita kaupallisen pelimoottorin käyttöönsä. Pelimoottorien ominaisuudet otetaan huomioon, sekä niitä ympäröivät yhteisöt ja kehittäjätuki. Lopulta pelimoottoreiden kustannuksia verrataan toisiinsa käyttämällä kahta kuvitteellista eri menestystason peliä.

4.1 Kaupallisen pelimoottorin valinta pelinkehityksen kannalta

Kaupallisten pelimoottoreiden lukumäärään nähden pelienkehittäjät voivat tarpeidensa mukaan valita sopivan pelimoottorin käyttöön. Merkittäviä tekijöitä pelimoottorin valintaan ovat käyttäjien ohjelmointikyvyt, pelimoottorin graafinen suorituskyky, pelimoottorin visuaaliset työkalut ja pelimoottoria ympäröivä nettiyhteisö.

Ohjelmointia on helpotettu pelimoottoreissa antamalla käyttäjille visuaalisia työkaluja koodin kehitykseen. Unreal Engine käyttää visuaalista skriptausjärjestelmää nimeltä Blueprints. Blueprintsin avulla kehittäjät voivat luoda tapahtumia, toimintoja ja muuttujia, yhdistää ja järjestellä näitä loogisesti. Unreal Engine luo näistä komponenteista taustalla koodia. Esimerkki Blueprintsin toiminnasta löytyy kuvasta 3. CryEngine, Godot ja Game Maker Studio 2 tarjoavat samankaltaista järjestelmää ohjelmoinnin helpotukseen, mutta pelimoottorit eivät pakota näiden työkalujen käyttöä kehittäjille. Kokeneet ohjelmoijat käyttävät vähemmän visuaalista ohjelmointityökaluja, koska tämä nähdään usein rajoittavana tekijänä. Visuaaliset skriptaustyökalut eivät aina sisällä kaikkia tarvittavia menetelmiä, joita ohjelmoija tarvitsisi kehitystä varten, joten ohjelmointi pelkästään näillä menetelmillä voi johtaa lopulta hankaliin kehitysongelmiin, joita voisi helpommin ratkaista perinteisemmällä ohjelmoinnilla. Tämän vuoksi niitä voidaan käyttää pääasiassa prototyypin luomiseen, jotta pelinkehittäjät voivat nähdä lyhyemmässä ajassa onko esimerkiksi pelimekaniikkaa toteuttamisen arvoinen, joka johtaa optimaalisemman version kehittämiseen perinteisen ohjelmointia käyttäen. [44.] [53.] 18

Kuva 3. Esimerkki Unreal Engine -pelimoottorin Blueprints visuaalisesta ohjelmoinnista [54.]

Pelimoottorien nettiyhteisöt voivat olla vaikutusvaltaisia tekijöitä pelimoottorin valinnassa. Unity on onnistunut pitkällä historiallaan luomaan laajan käyttäjäkunnan, joka avustaa toisia kehittäjiä foorumien, seminaarien tai opetusvideoiden avulla. Hyvänä esimerkkinä tästä on, että Unityn kauppasivustolla kehittäjät myyvät tekemiään opetusvideoita pelimekaniikkojen suunnitteluun ja ohjelmointiin. Monet kokeneemmat kehittäjät ovat pitäneet seminaareja ja luentoja liittyen Unityn pelienkehitykseen. Kaikki opetus- ja ohjausvideot, joita Unity-peli- moottoria varten on luotu, antavat uusille käyttäjille helpotetun aloitusmahdollisuuden. Yksinkertaisimmat ideat on toteutettu jo useaan otteeseen, jolloin näistä löytyy foorumeilta todennäköisimmin jo apua ja toteutustapoja. Kokeneet kehittäjät pystyvät erityisesti auttamaan pelimoottorin erikoisominaisuuksien kanssa. Unity tarjoaa myös asiakaspalveluja Pro-lisenssinsä asiakkaille, jos syntyy tilanne, että kehittäjä ei löydä vastauksia kehitysongelmiinsa foorumeilta tai jopa pelimoottorin dokumentaatiosta. [55.] [56.]

Lopullinen rajaava kriteeri pelimoottorin valintaan tulee kehitettävän pelin tarpeista. Vaikka kaupallisilla moottoreilla mainostetaan pelinkehityksen luovaa rajattomuutta, nämä kuitenkin on suunniteltu toteuttamaan tietynlaisia pelejä. Esimerkkinä CryEngine on alun perin kehitetty luomaan ensimmäisen persoonan ammuntapelejä. 3D-pelimoottorit ovat myös usein epäintuitiivisia 2D-pelien kehityksessä. 3D-pelimoottoreissa annetaan mahdollisuus kehittää 2D- pelejä, mutta usein 2D-pelejä varten suunniteltu pelimoottorit ovat kehitysajallisesti optimaalisempia vaihtoehtoja. [57.] [58.] 19

Tutkielmassaan “Overview and Comparative Analysis of Game Engines for Desktop and Mobile Devices”, Eleftheria Christopoulou ja Stelios Xinogalos vertailevat erilaisten pelimoottorien ominaisuuksia keskenään seuraavien ominaisuuksien perusteella: audiovisuaalinen tarkkuus, toiminnallinen tarkkuus, koostettavuus, kehittäjätyökalut, saavutettavuus, verkko-ominaisuudet, kehitysominaisuudet ja käyttöönottoalustat [59.]. Näiden ominaisuuksien tarkemmat kriteerit tulevat esille taulukosta 2. Christopoulouksen ja Xinogalosin tutkimuksen tulos oli, että Game Maker Studio on optimaalinen 2D-pelien kehitykseen, mutta Unity ja Unreal olivat kehittyneimmät pelimoottorit pelinkehityksessä, sillä nämä sisälsivät lähes kaikki ominaisuudet, mitä tarvittiin edellä mainittujen ominaisuuksien perusteella. Unreal Engine nähtiin parempana vaihtoehtona audiovisuaalisuuden ja avoimen lähdekoodin kannalta, mutta Unityn aloittelijaystävällisyys, yksinkertainen käyttöliittymä ja pelimoottorin yhteisö nähtiin suurempana etuna. Lopputuloksena Unreal Engine oli kokeneille kehittäjille parempi vaihtoehto, ja täten Unity oli parempi vähemmän kokeneille kehittäjille. 20

• Renderöinti • Animaatio Audiovisuaalinen • Ääni • 3D grafiikka tarkkuus mobiilialusteoille • Kohtauseditori • Skriptaus Toiminnallinen • Tekoäly tarkkuus • Fysiikka

• Sisällön tuonti Koostettavuus • Sisällön vienti

• Windows Phone SDK • iOS SDK Kehittäjätyökalut • Android SDK

• Android GDK

• Käytettävyys Saavutettavuus • Hinta

• Vertaisverkko Verkko- • Asiakas-palvelin Ominaisuudet • Monta pelaajaa

• Käyttöjärjestelmä Kehitys- ominaisuudet • Grafiikka API

• Mobiilialustat Käyttöönotto- • Tietokoneet alustat • Pelikonsolit

Taulukko 2. Taulukko, jota käytettiin pelimoottorein vertailussa. Taulukko on käännetty englan- nista suomeksi. [59.]

21

4.2 Kaupallisen pelimoottorin valinta taloudelliselta näkökulmalta

Tässä luvussa vertaillaan edellä mainittuja moottoreita taloudellisesta näkökulmasta. On tehty kaksi taulukkoa, jossa ensimmäisessä on esimerkki heikosti menestyvästä pelistä ja toisessa on menestynyt peli. Suuresti menestyneen pelin laskelmissa on otettu huomioon Linna Games Oy:n antamat esimerkkimäärät.

Tässä esimerkissä käydään läpi 15 euron peli, joka on myynyt 10000 kappaletta Valven Steam- pelikauppasivustolla. Peliä on kehittänyt kolmen hengen peliyritys vuoden, joilla kullakin on 2000 euron kuukausipalkka. Yrityksen kertaluonteisiin kuluihin ja menoeriin lasketaan 50 000 euron edestä investointeja. Myyntikustannuksissa on otettu huomioon Steamin ottama 30 prosentin osuus kaikista myydyistä peleistä [60.] sekä mahdolliset vuoden mittaiset lisenssi- maksut tai tekijänoikeusmaksut, mitä yritys on velkaa pelimoottorin kehittäjälle. Taulukossa 3 käydään läpi menestyneen pelin laskelmat. Unreal Enginen ja CryEnginen lisenssimaksut käsitellään kohdassa ”Royaltyt pelimoottorista”. Unity ja Game Maker Studion vuosimaksu- kustannukset käsitellään kohdassa ”Pelimoottorin vuosimaksu lisenssi”.

Peliprojektin tuloslaskelma Pelimoottorivaihtoehdot Unity Unreal CryEngine GMS Godot

Myynti kpl 10000 10000 10000 10000 10000 Hinta €/kpl 15 15 15 15 15 Myyntikustannus - Steam -30 % -30 % -30 % -30 % -30 % Royalty % 0 % -5 % -5 % 0 % 0 % Royaltykynnys € 100000 3000 5000 0 0

Liikevaihto 150000 150000 150000 150000 150000 Myyntikustannukset -45000 -45000 -45000 -45000 -45000 Royaltyt pelimoottorista 0 -7350 -7250 0 0 Henkilöstökustannukset -2000 3 -72000 -72000 -72000 -72000 -72000 Pelimoottorin vuosimaksu lisenssi -1440 0 0 -300 0 Käyttökate 31560 25650 25750 32700 33000 Poistot investoinneista 50000 -20 % -10000 -10000 -10000 -10000 -10000 Tulos 21560 15650 15750 22700 23000 Verot -20 % -4312 -3130 -3150 -4540 -4600 Voitto 17248 12520 12600 18160 18400 Taulukko 3. Heikosti menestyneen pelin kustannuslaskelma

22

Seuraavassa esimerkissä käydään läpi 20 euron peli, joka on myynyt 50 000 kappaletta Valven Steam-pelikauppasivustolla. Peliä on kehittänyt vuoden kahdeksan hengen peliyritys, joilla kullakin on 2500 euron kuukausipalkka ja 1000 euron henkilöstökulut. Yrityksen kertaluonteisiin kuluihin ja menoeriin lasketaan 100 000 euron edestä investointeja. Taulukossa 4 käydään läpi tämän esimerkkipelin kehityskustannukset.

Peliprojektin tuloslaskelma Pelimoottorivaihtoehdot Unity Unreal CryEngine GMS Godot

Myynti kpl 50000 50000 50000 50000 50000 Hinta €/kpl 20 20 20 20 20 Myyntikustannus - Steam -30 % -30 % -30 % -30 % -30 % Royalty % 0 % -5 % -5 % 0 % 0 % Royaltykynnys € 100000 3000 5000 0 0

Liikevaihto 1000000 1000000 1000000 1000000 1000000 Myyntikustannukset -300000 -300000 -300000 -300000 -300000 Royaltyt pelimoottorista 0 -49850 -49750 0 0 Henkilöstökustannukset -3500 8 -336000 -336000 -336000 -336000 -336000 Pelimoottorin vuosimaksu lisenssi -14400 0 0 -800 0 Käyttökate 349600 314150 314250 363200 364000 Poistot investoinneista 100000 -40 % -40000 -40000 -40000 -40000 -40000 Tulos 309600 274150 274250 323200 324000 Verot -20 % -61920 -54830 -54850 -64640 -64800 Voitto 247680 219320 219400 258560 259200 Taulukko 4. Menestyneen pelin kustannuslaskelma

Taulukoista voidaan päätellä, että Unreal Engine ja CryEngine tuottavat eniten menoja näiden 5 prosentin tekijänoikeusmaksulisenssien vuoksi. Pienemmässä yrityksessä näiden pelimootto- rien osuus kaikista kustannuksista oli noin 5,3 prosenttia. Suuremmassa peliyrityksessä tämä nousi 6,38 prosenttiin. Unity-pelimoottorin vuosilisenssi oli vain prosentti kustannuksista pienemmässä yrityksessä ja kaksi prosenttia suuremmassa yrityksessä. Godot-pelimoottori tämän MIT-lisenssin vuoksi oli kannattavin vaihtoehto.

Kun lisenssien hintoja vertaillaan esimerkiksi Yossarian Kingin artikkelin antamiin kustannus- lukemiin, kaupallisten pelimoottorien lisenssit kustantavat puolet vähemmän mitä pelimoottorin kehitys kustantaisi vuodessa. Tämän vuoksi Yossarian King artikkelissaan tuo esille, että aika ja kustannukset, mitä pelimoottorin kehitykseen voisi pistää, on järkevämpi sijoittaa peliprojektei- hin. Se, mitä mahdollisesti voisi säästää lisensseissä, ei ylitä tuotantokustannuksia. [50.] 23

5 Kokemuksia pelialan kehittäjiltä

Tässä luvussa käydään läpi eri pelialan kehittäjien mielipiteitä pelimoottorien kehitykseen liittyen. Ensimmäiset kaksi haastattelua suoritettiin 10.3.2020 Helsingissä IGDA Finlandin järjestämässä verkostoitumistapahtumassa. Ari Arnbjörnsson haastattelussaan viittasi omaan Assembly 2019- seminaariinsa ja Zach Lasterin haastattelu oli nauhoitettu. David Barrin haastattelu suoritettiin 8.4.2020 Discord-sovelluksen viestinnän kautta. Mathilde Nord Avalanche Studiosilta vastasi kysymyksiin 17.4.2020. Zach Lasterin haastattelu löytyy liitteestä 1, David Barrin haastattelu liitteestä 2 ja Mathilde Nordin haastattelu liitteestä 3.

5.1 Ari Arnbjörnsson (Housemarque)

Ari Arnbjörnsson, johtava peliohjelmoija Housemarquella, kertoo vuonna 2019 julkaistussa Assembly-seminaarissaan ”Lessons Learned from a Year of UE4 AAA Development”, Housemarquen kokemuksesta, kuinka ne siirtyivät pois oman pelimoottorin käytöstä Unreal Engineen. Hän johdattaa seminaariaan kertomalla syitä, miksi oman moottorin käyttö aiheutti niin paljon ongelmia pelinkehityksessä.

Ensimmäinen ja yleisin ongelma oli jatkuva moottorin uudelleenkehitys, kun siirryttiin uuden pelin kehitykseen. Jokainen peli vaati tuolloin omanlaista pohjaa, jonka päälle piti rakentaa itse projekti ja vaikka pelimoottori itsessään täyttää suurimmalta osalta tämän pohjan, sitä joutui aina muokkaamaan tyydyttääkseen pelin omia vaatimuksia. Tämä johti lopulta siihen, että pelitiimin kokeneimmat peliohjelmoijat oli siirretty moottorinkehityspuolelle, jolloin itse pelin kehitys mekaniikkojen kannalta hidastui huomattavasti, kun sijalle vaihdettiin junioriohjelmoijia.

Moottorinkehityksessä syntyi usein hetkiä, jolloin aikaa ei hyödynnetty järkevästi kehittämällä valmiita moottorin komponentteja jatkuvasti uudelleen. Vaikka refaktorointi voi luoda laadukkaampaa koodia jatkossa, uusien menetelmien kehittäminen vain siksi, että niitä voitaisiin kehittää uudelleen voi hidastaa kehitysprosessia huomattavasti. Pelimoottorin alkuvaiheissa, kun ei ollut käytössä työkaluja tai graafista käyttöliittymää, kehittäminen osoittautui hitaaksi suunnittelijoille ja graafikoille. Koska suurimmat resurssit laitettiin moottorinkehitykseen, pahimmillaan pelinkehitys alkoi vasta vuoden jälkeen, kun moottoria oli kehitetty eteenpäin tarpeeksi, jotta pelinkehitystiimi pystyisi hyödyntämään tätä. Tämä oli yksi syy, miksi House- 24

marque siirtyi Unreal Engineen, koska jos moottorinkehitys ei edistä pelinkehitystä, tämä lopulta olisi taloudellisesti suuri tappio. Resurssien rajallisuus vaatii, että pelejä työstetään jatkuvasti, eikä tätä prosessia pysäytettäisi ollenkaan. Ari Arnbjörnsson painotti lopulta, että pelifirman tar- koitus on työstää pelejä eikä moottoreita. [61.]

5.2 Zach Laster (Critical Charm)

Zach Laster, tekninen johtaja Critical Charmissa, kertoi haastattelussaan historiastaan, kuinka hän on kehittänyt pelimoottoriaan jo vuodesta 2005. Hän kertoo, kuinka moottorinkehitys oli siihen aikaan huomattavasti erilaisempaa. Kaupalliset moottorit eivät olleet saavuttaneet vielä suosiota tuolloin, joten pelinkehitys vaati, että joko kehitettiin oma moottori pohjalle tai kehitettiin jonkun toisen työn pohjan päälle oma versio pelimoottorista. Zach kertoo, että kehitysprosessissa kesti hänellä vähintään vuosi ennen kuin hän alkoi kehittämään pelejä itse moottorilla. Moottori oli kehitetty tukemaan OpenGL- ja DirectX-teknologioita ja pelit itsessään hyödynsivät alkeellista neuroverkkotekoälyjärjestelmää. Kokonaisuudessaan hän oli työstänyt moottoria vuoteen 2013 asti, jonka jälkeen hän ei nähnyt enää hyötyä moottorin kehittämisessä.

Suurimpia haasteita pelimoottorin kehityksessä 2000-luvun alussa oli tiedon keräämisen ja versiohallinnan suhteen. Internetissä oleva tieto moottorikehityksestä oli rajallista, joten akateemisia kirjoja joutui hyödyntämään huomattavan paljon. Aikaa kehityksessä menee turhaan, kun pyrkii oppimaan asioita itse sen sijaan, että hyödyntäisi valmista tietoa aiheesta. Zach haastattelussaan lopulta kertoo, että jos yrityksen on tarkoitus luoda pelejä, niin moottorin kehittäminen tulisi olla viimeinen vaihtoehto.

Nykyiset kaupalliset pelimoottorit ovat sen verran ympäripyöreästi suunniteltuja, että uuden moottorin kehittäminen vaatisi sen, että moottori pystyy johonkin, johon kaupalliset moottorit eivät pysty, tai moottorin avulla voidaan optimoida vakaita simulaatiojärjestelmiä, joissa matematiikalla ja laskelmatehoilla on itsessään valtava merkitys. Pelimoottorin kehitys olisi myös kannattavaa vain, jos yritys on suunniteltu myymään tätä pelimoottoria käytettäväksi kaupallisesti, jolloin tästä olisi myös rahallista hyötyä firmalle.

25

Zachin mielestä pelimoottorin kehitys ei ole taloudellisesti kannattavaa, koska tarvittavan työn määrä ennen kuin itse pelejä voi alkaa kehittämään, on liian valtava ja täten nykyajassa ei ole mitään syytä tämän kehitykseen, jos haluaa säästää rahaa peliprojektien suhteen. Hän suosittelee Unreal Engineä pääasiassa ensimmäisen persoonan ammuntapeleihin [FPS], Unity-moottoria yleiseen 3D-pelien kehitykseen ja 2D-pelien kehitykseen. Hän suosittelee myös tutustumaan eri moottoreihin, riippuen siitä, mitä peliprojekti itsessään kaipaa teknologioiden ja mekaniikkojen puolesta.

5.3 David Barr (javidx9 Youtube-kanava)

David Barr on tutkimus- ja kehityspäällikkö Phoenix Inspection Systems Ltd:ssä. Hänellä on myös yli 140 000 tilaajan Youtube-kanava nimeltään javidx9, jossa hän opettaa peliohjelmointia C++- ohjelmointikielellä. Hän on kehittänyt ”olc Pixel Game Engine”-pelimoottorin, joka on kerännyt suosiota sen yksinkertaisuuden vuoksi. Haastattelussa selvitin hänen kokemuksiaan kyseisen pe- limoottorin kehityksestä. [62.]

David Barr kertoo, että moottori oli rakennettu hänen aiemman pelimoottorinsa olcConsoleGameEnginen päälle, jolla oli itsessään kehitysaikaa 50 tuntia. Hänen halunsa antaa Linux-käyttäjille mahdollisuus kehittää sillä pelejä, muovaantui lopulta Pixel Game Engine pelimoottoriksi. Edellisen moottorin uudelleenohjelmoinnissa meni työtunteja keskimäärin 80 tuntia. Uudet 2D-, 3D-, ääni-, ohjain- ja muut tarvittavat pelinkehityskomponentit veivät kokonaisuudessaan 200 tuntia. Hänellä on tällä hetkellä kehitteillä Pixel Game Engine pelimoottorin seuraava versio, joka on vienyt häneltä noin 120 tuntia kehitysaikaa.

David Barr vahvistaa, että pelimoottorien kehityksessä suurin hyöty on moottorin kehittäminen omiin tarpeisiin. Hän halusi kehittää Pixel Game Engine pelimoottorin yksinkertaisesti siten, että se ei vaatinut laitteen vakiokirjastoja lukuun ottamatta mitään ulkoisia ohjelmointikirjastoja toimiakseen missä tahansa laitteessa. Tämä takaisi myös sen, että pelimoottori toimisi jopa vähemmän tehokkaissa tietokoneissa.

26

David Barr moittii kaupallisia moottoreita niiden rajallisista kustomointimahdollisuuksista, mikä saa kaikki moottorilla tehdyt pelit vaikuttamaan samankaltaisilta toisiinsa verrattuna. Nämä kaupalliset pelimoottorit eivät myöskään mahdollisesti tue tiettyjä pelillisiä ominaisuuksia, joita kehittäjät haluaisivat mahdollisesti luoda. Tilanteessa, jossa kehittäjä haluaisi kustomoida käyttämäänsä kaupallista pelimoottoria, kehittäjällä täytyy olla pitkä käyttöhistoria sen ymmärtämisessä ja tämä sitoutuneisuus moottoriin voi johtaa pettymykseen, jos kustomoinnin lopputulos ei ollut sitä mitä kehittäjä halusi.

Oman pelimoottorin lisenssivapauden ja täyden muokkausvapauden hän näkee myös suurina etuina. Täysi vapaus kehittää moottori sellaiseksi, mitä hän haluaa, on johtanut myös ongelmiin, sillä yksin kehittäminen ei anna hänelle paljoa tukea kehittäjänä. Suurimpia kehityshaasteita tuli vastaan hänen Youtube-yleisönsä myötä. Monet fanit ottivat moottorin käyttöön ja suuri määrä vikailmoituksia tuli julkaisun jälkeen. Monet käyttäjät hyödynsivät moottoria tavoilla, joita hän ei odottanut. Se johti siihen, että hänen täytyi lisätä ominaisuuksia näiden epätavallisten käyttäjien miellyttämiseksi. Tästä tuli ongelmallista, sillä tärkeämmät tarvittavat ominaisuudet lykkääntyivät eteenpäin ja moottori sisälsi nyt mahdollisia turhia ominaisuuksia. Käyttäjäkunta osoitti myös tyytymättömyyttä, kun päivitykset rikkoivat vanhempien versioiden projekteja.

David Barr on nyt julkaisemassa hänen seuraavaa versiota Pixel Game Engine -moottorista, joka tulee sisältämään ominaisuuksia, joita yhteisö on toivonut jo pitkään. Näihin kuuluu nopeampaa kuvarenderöintiä, integroitua laitteistokiihdytettyä 3D-grafiikkakäyttöliittymää ja uudistettu audiojärjestelmä. On myös liitetty WebGL-tuki, joka saa moottorin toimimaan verkkosivuilla, mikä helpottaa kehitystä erityisesti aloittelijoille. Kokonaisuus on myös paljon kevyempi, mikä kannustaa moottorin käyttöä erikoisiin tarkoituksiin.

David Barrin mielipiteet ja kokemukset tuovat esille kuinka kannattavaa omakehitteisen 2D-peli- moottorin kehitys voisi olla. Hänen erityisasemassaan, hän sai välittömästi suuren käyttäjäkunnan pelimoottorille, joka huomattavasti nopeutti moottorin kehitystä. Jatkuvalla käyttäjäkokemus- syötteellä hän on pystynyt kehittämään pelimoottoriaan paremmaksi, joka osoittaa käyttäjäkokemuksen ja testaamisen merkityksen.

27

5.4 Mathilde Nord (Avalanche Studios)

Avalanche Studios on ruotsalainen peliyritys, joka perustettiin vuonna 2003. Ne ovat kehittäneet ylistetyn Just Cause -pelisarjan omalla Avalanche Engine-pelimoottorillaan, jonka nimeä vaihdettiin myöhemmin Apex Game Engineksi. Mathilde Nord toimii Avalanche Studiosin teknisenä koordinaattorina ja suostui antamaan haastattelun liittyen Apex Game Engine pelimoottorin kehitykseen.

Yrityksen perustamisen alussa Avalanche Game Engineä kehitettiin samanaikaisesti niiden ensimmäisen julkaistun pelinsä Just Causen kanssa. Yrityksen tavoitteena oli tuolloin kehittää pelimoottoria sen mukaan, mitä peli itse silloin tarvitsi. Avalanche Studios on aina kehitetty pelimoottoriaan tulevien pelien ohella. Tarkoitus on ollut saada käytännöllisiä eroja peleihin kehittämällä pelimoottoria. Avalanche Studiosin pelimoottori sisälsi useita työkaluja, jotka helpottivat pelin sisällön kirjoittamista ja valmistelemista. Suurin näistä työkaluista on JustEdit-työkalu, joka avustaa kaikissa pelinkehityspuolissa. Pelimoottorin kääntäjät pystyvät myös tuottamaan pelit kaikkiin sopiviin alustaformaatteihin.

Mathilde Nord kertoo, että Apex-pelimoottori on optimoitu luomaan suuria avoimia pelimaailmoja ilman latausruutuja. Tämän erityispiirteen vuoksi kaikki Avalanche Studiosin pelit sijoittuvat suuriin maailmoihin, joten perinteisiä pelikenttiä ei varsinaisesti kehitetä niiden peleissään. Suurimpia haasteita, joita pelimoottorin kehityksessä on tullut vastaan, liittyivät pelialustatoimivuuteen ja pelien ajoajan optimointiin.

Avalanche Studiosin pitkä pelimoottorikehityshistoria on esimerkki siitä, mihin yritys voi päästä jatkuvalla kehityksellä. Vaikka Apex-pelimoottori osittain rajoittaa niiden pelejään samankaltaisiksi, se on samalla luonut heille oman brändin markkinoilla, josta kehittäjät ottavat mallia tai viittauksia, kun tavoitteena on luoda suuria avoimen maailman pelejä. Pelimoottorin kehityksessä suurilla tavoitteilla voidaan luoda innovatiivisia keksintöjä, jotka voivat lopulta johtavaa markkinoiden huipulle. 28

6 Pohdinta

Pelimoottorin kehityksen kannattavuus on riippuvainen yrityksen tavoitteista. Jos tavoitteena on olla markkinoiden kärjessä kehittämillään peleillään, kaupallisten moottoreiden käyttö on hidastava tekijä. On lähes mahdotonta erottua markkinoilla käyttämällä samaa kaupallista pelimoottoria, mitä muut kehittäjät käyttävät. Pelit voidaan brändätä negatiivisesti käytettyyn pelimoottoriin nähden, mitä yleensä tapahtuu Unity-pelimoottorilla tehtyjen pelien kanssa. Positiivista brändäystä voi myös syntyä, kuten Unreal Enginellä tehtyjen pelien vaikuttavista graafisista esityksistä. Ongelma syntyy, kun jokainen Unreal Engine-pelimoottorilla tehty peli näyttää yhtä vaikuttavalta, jolloin siitä syntyy graafinen standardi. Jos kehitetty peli on osa standardia, on lähes mahdotonta erottua taas kerran joukosta. Peliyritykset, jotka ovat kehittäneet oman pelimoottorinsa käyttävät myös sen kehitystä myyntivalttina, esittämällä mahdollisuudet mitä pelimoottorilla voi tehdä ja täten luomalla innovatiivisen kuvan itsestään.

3D-pelimoottorin kehittäminen on kustannuksellisesti erittäin vaativa työ. Vaikka projektia työstäisi useampi henkilö, moottoria tulisi työstää vähintään vuoden, kunnes tätä voisi edes käyttää ensimmäiseen peliprojektiin. Jopa tällöin, moottorin ominaisuudet ovat todennäköisimmin verrattavissa kaupallisiin moottoreihin, paitsi jos tarkoituksena oli kehittää alusta asti ainutlaatuinen pelimoottori. Tämän pitkän kehitysajan aikana peliyrityksellä kuitenkin tulisi olla tavoitteena kehittää pelejä pysyäkseen toiminnallisena.

Peliyrityksen täytyy suunnitella usean vuoden päähän pelimoottorin kehityskaarta, ennen kuin alkavat kehittämään sitä. Peliyrityksen pitää tasapainottaa myytävien peliprojektien tuotantotah- tia ja tulevan pelimoottorin kehitystä. Pelimoottorin kehityksessä täytyy olla yrityksen osaavim- mat ohjelmoijat, mutta peliprojekteissa tulee olla myös ohjelmoinnin suhteen vähintään tukea näiltä samoilta ohjelmoijilta.

Kehitysaikaa voidaan helposti vähentää pienentämällä pelimoottorin skaalaa. 3D-pelimoottorin voi alentaa 2D-pelimoottoriksi. Graafisen käyttöliittymän voi jättää välistä. Kehitysalustatukea voidaan rajoittaa pelkästään mobiilialustoille tai tietokoneille. Nämä kaikki vähentävät moottorin kehitysaikaa, joka voi johtaa nopeampaan pelienkehitykseen itse pelimoottorilla. Peliyrityksen tiimin tarpeet täytyy tässä kuitenkin huomioida. Jos pelinkehitystiimissä on henkilöitä vähäisellä ohjelmointiosaamisella, täysin koodilla käytettävä pelimoottori voi osoittautua liian hankalaksi, 29

joka lopulta hidastaa pelin kehitysaikaa. Pelimoottorin koodia voidaan kehittää käyttäjäystäväl- liseksi antamalla esimerkiksi skriptaustyökaluja, joissa ohjelmointikoodi on huomattavasti yksin- kertaisempaa käyttää henkilölle, joka ei ole ohjelmoija.

Oman pelimoottorin opetus yrityksen uusille kehittäjille tulee myös huomioida pelienkehitysaika- arviossa. Kaupallisten moottoreiden etu on, että peliyritykset voivat vaatia pelimoottorin osaamista entuudestaan, jolloin niiden ei tarvitse käyttää kustannuksiaan pelimoottorin opetukseen.

Pelimoottorin kannattavuus on häilyvä, jos peliyrityksellä on tavoitteena julkaista mahdollisimman monta peliä vuodessa. Kaupallisten pelimoottoreiden käyttö antaa tilaisuuden välittömään kehitykseen, mutta jos itsekehitetty pelimoottori antaa kehittäjille tarvittavat työkalut nopeampaan kehitykseen, pelienkehityksen tuottavuuden kasvu voi ylittää sen, mitä kaupallisilla moottoreilla voi saada aikaiseksi. Pelimoottorien kehittäjien täysi tuntemus omasta moottorista voi estää ongelmatilanteita, missä kehittäjän on hankala saada tukea, mitä syntyy useammin käyttämällä kaupallisia pelimoottoreita.

Kaupallisia pelimoottoreita voidaan myös käyttää pelien prototyyppien luontiin. Yritys voi kehittää pikaisen version pelistä kaupallisilla pelimoottoreilla ja suunnitella sen perusteella tarvittavan pelimoottorin. Ongelmana on, että jos kyseisellä tavalla kehitetty pelimoottori on liian spesifi, seuraavan kehitettävän pelin täytyy olla saman tyylinen, jos tavoitteena ei ole uudelleen kirjoittaa pelimoottorin koodia.

Pelimoottorin kehityksen kannattavuus on asetettu taulukossa 5 nelikenttään, josta selviää millaisten pelien kehitys on kannattavaa omalla tai kaupallisella pelimoottorilla. X-akseli määrää sen hetkisten resurssien ja tarvittavan ajan määrän. Oman pelimoottorin kehitys korostuu, jos tarkoituksena on kehittää yksinkertaisia mobiilipelejä tai jotain, johon kaupalliset pelimoottorit eivät pysty. Kaupalliset pelimoottorit ovat kannattavia nopeasti tuotettavien ja monialustaisten pelien tekoon.

30

OMA PELIMOOTTORI Yksinkertaiset 2D mobiili- tai PC pelit Markkinoiden kärjessä olevat pelit

LISENSOITU PELIMOOTTORI Massatuotantopelit Monialustaiset pelit

VÄHEMMÄN AIKAA TAI RESURSSEJA PALJON AIKAA TAI RESURSSEJA

Taulukko 5. Pelimoottorin kehittämisen kannattavuuden nelikenttä.

Oman harjoittelukauteni aikana työstin 2D-pelimoottoria Linna Games Oy:lle. CEO Henri Partanen oli kokenut turhautumista Unity-pelimoottorin luomiin rajoitteisiin ja mahdollisiin lisenssimaksui- hin ja halusi todistaa, kuinka lyhyellä ajalla olisi mahdollista toteuttaa mahdollisimman yksinker- tainen 2D-pelimoottori. Kokonaisuudessaan moottoria kehitettiin kaksi kuukautta, jolloin tällä aloitettiin pelidemojen tekeminen seuraavat kaksi kuukautta. Pelidemojen tekemisen ohella työs- tettiin uusia ominaisuuksia pelimoottoriin, jotka edesauttaisivat seuraavaa pelidemoprojektia. Linna Games Oy oli lopulta tyytyväisiä lopulliseen projektiin ja sen mahdollisuuksiin, sillä se antoi hyvän kuvan siitä, mitä yksi ohjelmoija pystyy tekemään harjoittelukauden aikana. Kehittämääni pelimoottoria ei lopulta käytetty muihin projekteihin, mutta se antoi tämän tutkimuksen ohella kuvan Linna Games Oy:lle, mitä tulee huomioida lopullisen pelimoottorinsa kehityksessä.

31

7 Yhteenveto

Tutkimuksen tavoitteena oli selvittää missä tapauksissa pelimoottorin kehitys voisi nähdä kannat- tavana vaihtoehtoa kaupallisten pelimoottorien käytön sijasta. Tutkimuksessa selvisi, että jos peliyrityksen kehittämän pelin tarpeita ei voida toteuttaa kaupallisilla pelimoottoreilla, oman pelimoottorin kehitys olisi kannattava vaihtoehto. Pelimoottorin kehitys on yritykselle kuitenkin suuri investointi tulevaisuuden kannalta. Kehityksen kustannuksia voidaan säätää pienentämällä kehitettävän moottorin skaalaa, mutta jopa yksinkertaisen 2D-pelimoottorin kehitykseen voi kulua yli 300 työtuntia aikaa. Pelimoottorin kehityksen etuina tulee ilmi sen kehityksen rajattomuudesta, optimoinnista ja täydestä tuntemuksesta, mutta ollakseen laskelmointitehojen ja muistinhallinnan suhteen optimaalisempi verrattavissa muihin pelimoottoreihin vaatii osaavia kehittäjiä ja paljon kehitysaikaa.

Luvussa 2 käytiin läpi eri kaupallisten pelimoottoreiden tekijänoikeusmaksuehtoja ja luvussa 4 vertailtiin näiden vuosikustannuksia, jos peliyritys onnistuisi kehittämään menestyneen pelin. Laskelmissa tuli ilmi, että kaupallisten pelimoottoreiden lisenssikustannuksia ei tule pelätä, sillä näiden osuus on merkittävän pieni, jos niitä joutuu edes maksamaan. Pienille yrityksille suositellaan Unityn, Godotin ja Game Maker Studio 2:n käyttöä, sillä näiden kustannukset ovat merkittävästi alhaisemmat verrattavissa Unreal Engineen ja CryEngineen.

Godot-pelimoottori tuli esille suositeltavimpana vaihtoehtona Linna Games Oy:lle, jos he haluavat kehittää pelejä nopealla tahdilla mahdollisimman pienillä kustannuksilla. MIT-lisenssi ei rajoita heidän kehitystään millään tavalla ja lisenssimaksuja ei myöskään tarvitse ajatella. Oman pelimoottorin kehitystä voidaan vain suositella, jos tarkoitus on luoda 2D-pelejä mahdollisimman optimaalisesti. Omakehitteisen pelimoottorin ylläpito ja opetus uusille käyttäjille voi kuitenkin viedä ylimääräisiä kustannuksia, mitä voisi ennemmin käyttää pelienkehitykseen.

Tutkimus osoitti minulle, että vaikka pelimoottorin kehitys oli opettavainen kokemus, sen tekeminen ja jatkuva ylläpito voi osoittautua hyvin raskaaksi työksi sekä itselle, että yrityksille. Ari Arnbjörnssonin kommentti, että peliyritysten tulisi kehittää pelejä eikä moottoreita, kiteyttää tämän tutkimuksen tulokset.

32

Lähteet

(1) Mark Maratea (22.4.2019). Why do AAA game companies use Unreal Engine? Saatavilla osoitteesta: https://www.quora.com/Why-do-AAA-game-companies-use-Unreal-En- gine

(2) John Papadopoulos (10.11.2018). Bethesda will use an upgraded version of the Creation En- gine for The Elder Scrolls 6 and Starfield. Saatavilla osoitteesta: https://www.dsoga- ming.com/news/bethesda-will-use-an-upgraded-version-of-the-creation-engine-for-the-elder- scrolls-6-and-starfield/

(3) Valve Developer Community authors (1.10.2012) Source Engine Features. Saatavilla osoitteesta: https://developer.valvesoftware.com/wiki/Source_Engine_Features

(4) OXM Staff (23.12.2018) The most crucial part of video-game development explained - and how it powered Fortnite's runaway success. Saatavilla osoitteesta: https://www.games- radar.com/what-is-a-game-engine-and-what-does-it-do/

(5) Paul Tassi (2.11.2018) 'Fallout 76' Shows Bethesda's Engine Has Gone From Meme To Liability. Saatavilla osoitteesta: https://www.forbes.com/sites/insertcoin/2018/11/02/fallout-76-shows- bethesdas-engine-has-gone-from-meme-to-liability/#42b14f92123a

(6) Laura Kate Dale (6.7.2015) Unity - does indie gaming's biggest engine have an image problem? Saatavilla osoitteesta: https://www.theguardian.com/technology/2015/jul/06/unity-indie-ga- mings-biggest-engine-john-riccitiello

(7) Partha Sarathi Paul, Surajit Goon, Abhishek Bhattacharya (21.5.2012) History and comparative study of modern game engine. Saatavilla osoitteesta: https://www.researchgate.net/publica- tion/259496289_History_and_comparative_study_of_modern_game_engines

(8) Julie Wilmore (7.2010) Dissecting the Video Game Engine and a Brief History. Saatavilla osoitteesta: https://juliewilmore.files.wordpress.com/2010/07/tc339finalpaper.pdf

(9) Dan Griliopoulos (9.4.2016) The Making of Doom: id’s shooter masterpiece. Saatavilla osoitteesta: https://www.pcgamesn.com/making-doom-ids-shooter-masterpiece

33

(10) id Software (10.3.2020) Doom Eternal – Launch Details. Saatavilla osoitteesta: https://bet- hesda.net/en/article/5Wx9QeorMSfMZCwLg6VpoS/doom-eternal-launch-details

(11) Tabitha Baker (19.10.2018) The Complete History of Indie Games. Saatavilla osoit- teesta:https://www.indiegamewebsite.com/2018/10/19/the-complete-history-of-indie-games/

(12) Unity Technologies authors (2020) This is why creators choose Unity. Saatavilla osoitteesta: https://unity.com/our-company

(13) Eric Peckham (17.10.2019) How Unity built the world’s most popular game engine. Saatavilla osoitteesta: https://techcrunch.com/2019/10/17/how-unity-built-the-worlds-most- popular-game-engine/

(14) Alex Wawro (31.5.2016) Unity drops mobile fees, debuts new 'Plus' plan in a bid to expand its reach. Saatavilla osoitteesta: https://www.gamasutra.com/view/news/273679/Unity_drops_mobile_fees_ debuts_new_Plus_plan_in_a_bid_to_expand_its_reach.php

(15) Massachusetts Institute of Technology (Myöhäinen 1980-luku) MIT License. Saatavilla osoitteesta: https://opensource.org/licenses/MIT

(16) Unity Technologies (2020) Can I make a commercial game with Unity Free/Personal Edi- tion? Saatavilla osoitteesta: https://support.unity3d.com/hc/en-us/articles/205253119-Can-I- make-a-commercial-game-with-Unity-Free-Personal-Edition-

(17) Gestalt (26.6.2000) The Engine Licensing Game - The ups and downs of licensing a game en- gine. Saatavilla osoitteesta: https://www.eurogamer.net/articles/engines

(18) Daniel Bratcher (4.11.2014) Happy birthday to us – Unity Asset Store turns four. Saatavilla osoitteesta: https://blogs.unity3d.com/2014/11/04/happy-birthday-to-us-unity-asset- store-turns-four/

(19) Clive Downie (31.5.2016) New Unity products and prices launching soon. Saatavilla osoitteesta: https://blogs.unity3d.com/2016/05/31/new-products-and-prices/

(20) Unity Technologies (2020) Plans and pricing. Saatavilla osoitteesta: https://store.unity.com/

34

(21) Jessica Famularo (1.3.2018) What indie developers think of Unity in 2018. Saatavilla osoitteesta: https://www.pcgamer.com/what-indie-developers-think-of-unity-in- 2018/

(22) Kristyna Hougaard (19.7.2013) Funding Indie Games with the Asset Store. Saatavilla osoitteesta: https://blogs.unity3d.com/2013/07/19/funding-indie-games-asset-store/

(23) Rebekah Valentine (19.7.2018) Unity: "Games wouldn't see the light of day" without asset stores. Saatavilla osoitteesta: https://www.gamesindustry.biz/articles/2018-07-19-well-88-per- cent-of-what-asks-unitys-global-head-of-asset-store

(24) Tim Sweeney (2.3.2015) If You Love Something, Set It Free. Saatavilla osoitteesta: https://www.unrealengine.com/en-US/blog/ue4-is-free

(25) Epic Games (2020) Frequently Asked Questions (FAQ). Saatavilla osoitteesta: https://www.unrealengine.com/en-US/faq

(26) Dana Cowley (11.7.2018) Epic announces Unreal Engine Marketplace 88% / 12% revenue share. Saatavilla osoitteesta: https://www.unrealengine.com/en-US/blog/epic-announces-un- real-engine-marketplace-88-12-revenue-share

(27) Epic Games (2020) Payouts. Saatavilla osoitteesta: https://www.unrealengine.com/en- US/marketplace-faq?active=payouts

(28) Yoyo Games (2020) Product Choice. Saatavilla osoitteesta: https://www.yoyogames.com/get

(29) Mark Alexander (1.2020) Publisher – When will I get my money. Saatavilla osoitteesta: https://help.yoyogames.com/hc/en-us/articles/217380797-Publisher- When-will-I-get-my-money-

(30) Juan Linietsky & Godot Core Contributors (2020) Godot Engine Patreon. Saatavilla osoitteesta: https://www.patreon.com/godotengine

(31) Juan Linietsky, Ariel Manzur and contributors (2020) License. Saatavilla osoitteesta: godotengine.org/license.

(32) VisCircle GmbH (2020) Godot Marketplace EULA and Distribution Agreement. Saatavilla osoitteesta: https://godotmarketplace.com/eula-and-distribution-agreement/ 35

(33) Crytek GmbH (2020) Licensing. Saatavilla osoitteesta: https://www.cryengine.com/sup- port/view/licensing#

(34) Twarit Waikar (15.1.2019) How I made a game engine from scratch? Saatavilla osoitteesta: https://medium.com/the-virtual-diary/how-i-made-a-game-engine-from-scratch-bcacb2df0503

(35) Koen Samyn (4.12.2015) How long would it take to build a 2D game engine for retro style games? Saatavilla osoitteesta: https://www.quora.com/How-long-would-it-take-to-build-a-2D- game-engine-for-retro-style-games

(36) Michael Kissner (27.10.2015) Writing a Game Engine from Scratch – Part 1: Messaging. Saatavilla osoitteesta: https://www.gamasutra.com/blogs/MichaelKiss- ner/20151027/257369/Writing_a_Game_Engine_from_Scratch__Part_1_Messaging.php

(37) Wikipedia authors (28.4.2020) List of game engines. Saatavilla osoitteesta: https://en.wikipe- dia.org/wiki/List_of_game_engines

(38) Codementor authors (4.2018) Why Learn C++? Saatavilla osoitteesta: http://www.bestp- rogramminglanguagefor.me/why-learn-c-plus-plus

(39) Robert Huebner (3.10.1997) Adding Languages to Game Engines. Saatavilla osoitteesta: https://www.gamasutra.com/view/feature/131641/adding_languages_to_game_engines.php

(40) Yan Chernikov (21.10.2018) DESIGNING our GAME ENGINE. Saatavilla osoitteesta: https://www.youtube.com/watch?v=etdSXlVjXss

(41) Juan Belon Perez (26.8.2013) How to create 2D Physics Games with Box2D Library. Saatavilla osoitteesta: https://www.gamasutra.com/blogs/JuanBelonPerez/20130826/198897/ How_to_create_2D_Physics_Games_with_Box2D_Library.php

(42) Paul Vincent Craven (2017) Platformer With Sprite Sheets. Saatavilla osoitteesta: http://programarcadegames.com/python_examples/en/sprite_sheets/

(43) Tiled (2019) Features. Saatavilla osoitteesta: https://www.mapeditor.org/

(44) MCV Staff (14.4.2015) Why a plucky band of developers build their own game engines. Saatavilla osoitteesta: https://www.mcvuk.com/development-news/why-a-plucky-band-of-de- velopers-build-their-own-game-engines/ 36

(45) GameDesigning.org authors (31.3.2020) Build Your Own Video Game Engine. Saatavilla osoitteesta: https://www.gamedesigning.org/learn/make-a-game-engine/

(46) Juan Linietsky (25.3.2018) Godot is doing well at GDC 2018! Saatavilla osoitteesta: https://godotengine.org/article/godot-doing-well-gdc-2018

(47) Veikkaus Oy (2018) CORPORATE GOVERNANCE -katsaus 2018. Saatavilla osoitteesta: https://cms.veikkaus.fi/site/binaries/content/assets/dokumentit/vuosikertomus/2018/veik- kaus_corporate-governance_2018.pdf

(48) Damian Nowakowski (11.12.2018) Reducing build size of Android game in Unreal Engine 4. Saatavilla osoitteesta: http://zompi.pl/reducing-build-size-of-android-game-in-unreal-engine-4/

(49) Glyn Williams (27.7.2014) What is the main difference between 2D and 3D game develop- ment? Saatavilla osoitteesta: https://www.quora.com/What-is-the-main-difference-between- 2D-and-3D-game-development

(50) Matthew Humphries (2.3.2011) Box2D creator asks Rovio for Angry Birds credit at GDC. Saatavilla osoitteesta: https://www.geek.com/games/box2d-creator-asks-rovio-for-angry-birds- credit-at-gdc-1321779/

(51) The Blind Mystics (12.7.2017) Create your own Game Engine but don't ever use it. Saatavilla osoitteesta: https://zeroequalsfalse.com/posts/build-game-engine/

(52) Yossarian King (19.12.2011) Opinion: Why On Earth Would We Write Our Own Game Engine? Saatavilla osoitteesta: https://www.gamasutra.com/view/news/128765/ Opinion_Why_On_Earth_Would_We_Write_Our_Own_Game_Engine.php

(53) Eddy Njiki (22.11.2019) Prototyping workflow with Machinations and UE4. Saatavilla osoit- teesta: https://www.gamasutra.com/blogs/EddyNJIKI/20191122/354536/Prototyping_work- flow_with_Machinations_and_UE4.php

(54) Thomas Hilfert (6.2015) Low-Cost Virtual Reality Environment For Engineering And Construc- tion - Figure 2. Saatavilla osoitteesta: https://www.researchgate.net/figure/Example-of-blue- print-logic-modelling-in-UE4-Figure-3-shows-the-implementation-inside-a_fig6_283573952 37

(55) TNW DEALS (24.3.2016) This engine is dominating the gaming industry right now. Saatavilla osoitteesta: https://thenextweb.com/gaming/2016/03/24/engine-dominating-ga- ming-industry-right-now/

(56) Jacqueline Zenn (16.10.2018) What’s The Best Game Engine For You? Saatavilla osoitteesta: https://gameanalytics.com/blog/best-game-engine.html

(57) Marie Dealessandri (16.1.2020) What is the best game engine: is CryEngine right for you? Saatavilla osoitteesta: https://www.gamesindustry.biz/articles/2020-01-16-what-is-the-best- game-engine-is-cryengine-the-right-game-engine-for-you

(58) M. S. Farzan (4.11.2019) What 2D Game Engine to Use for Your Next Game. Saatavilla osoitteesta: https://www.freecodecamp.org/news/what-2d-game-engine-to-use-for- your-next-game/

(59) Eleftheria Christopoulou, Stelios Xinogalos (12.2017) Overview and Comparative Analysis of Game Engines for Desktop and Mobile Devices. Saatavilla osoitteesta: https://www.researchgate.net/publication/322027338_Overview_and_Comparative_Ana- lysis_of_Game_Engines_for_Desktop_and_Mobile_Devices

(60) Nick Statt (30.11.2018) Valve’s new Steam revenue agreement gives more money to game developers. Saatavilla osoitteesta: https://www.theverge.com/2018/11/30/18120577/valve- steam-game-marketplace-revenue-split-new-rules-competition

(61) Ari Arnbjörnsson (3.8.2019) Lessons Learned from a Year of UE4 AAA Development. Saatavilla osoitteesta: https://www.youtube.com/watch?v=SGPleVfrPyo

(62) David Barr (9.9.2018) olcPixelGameEngine. Saatavilla osoitteesta: https://www.youtube.com/watch?v=kRH6oJLFYxY Liite 1 1/7

Liitteet

Zach Lasterin (Critical Charm) haastattelun äänityksen litteroitu muistio.

Tuomas Suokko = TS Zach Laster = ZL

TS: What was the point when you started to develop a game engine for a company?

ZL: Oh no, I didn’t actually develop a game engine for a company. I built one for myself. I men- tioned that I taught at the university. One of the things that I was teaching was game engine architecture. So, obviously that obviously had influences on the thing I was building and building this thing made it more interesting to teach at the class.

TS: Was this around what time?

ZL: Well I started building it in high school. That would’ve been 2005. It was in C++. it went through a couple of rebuilds at different points, I restructured it at different times. The last time I was actually working on it was 2013.

TS: A pretty long history with that. You never started over?

ZL: Oh, I did actually. Well, I refactored it significantly.

TS: There was still some legacy code in it though?

ZL: In different places yeah.

TS: It’s like the old philosophical question, if you change the boards of a boat completely…

ZL: Ship of Theseus

TS: Exactly! It’s like, is it the same boat? Yes, no, maybe, depends on your point of view…

TS: OK so, I’m guessing OpenGL, 3D, what did you start with?

ZL: I actually was referencing Irrlicht, which was an existing engine at the time, It was a 3D engine, (I did all the game stuff otherwise) for a lot of the way I did 3D stuff. I had it set up to be able to Liite 1 2/7 handle OpenGL or DirectX, optionally. It was Windows, but it also supported Linux later on. And…what was the rest of the question?

TS: Like did you start wit h3D originally, or did go from a 2D to semi 3D kind of thing?

ZL: Oh, I think it started 3D originally. It did have support for 2D things. A lot of that was screen overlay. Screen space thing… and they were very different systems. So, nowadays I would com- pare it to Godot. Where it was not as well engineered as Godot is, and especially not originally. But if I were to compare it to something like Unity… Unity I would think of as a 3D engine. It CAN do 2D, if you beat it over the head enough.

TS: yeah, but you really shouldn’t…

ZL: You shouldn’t! If you wanna do 2D, you wanna still do 2D in a 3D environment. But if you’re doing something that was actually 2D, I’d recommend doing Godot. And the thing I build was like Godot, it had a 2D system. It had a 3D system! And, you could switch between them, you can have them both running at the same time actually! But communicating between them might get a lot… at least in terms of screen space. But yeah, I had these kind of systems working. I built all sorts of things for generic… it was modular. I had it so I could pull in whatever parts of the engine I needed. Like file systems and whatnot.

TS: Any scripting languages?

ZL: Lua, it supported Lua. At one point I tried AngelScript.

TS: AngelScript? What is AngelScript?

ZL: OLD. And probably dead. It was…a scripting language. It… worked. I don’t recommend it. Lua is much better. But I wanted to try it out, just because its main claim to fame, the main reason I wanted to try it out was because it betterintegrated with C++. Where as Lua, is C, and binding it is complicated. And building binds for things like C++ is really complicated. Because getting those objects in is…egh… I remember doing it. Which means…

TS: How many weeks?

ZL: I don’t remember that! But I remember doing it… But AngelScript was kinda like, ok, you can just drop in AngelScript and it will integrate with C++ automatically. It has a concept of objects and you bind these things… but yeah “I’m gonna try that!”. It was not always great. There were a couple of interesting bugs in the project I built with it. At that point I was actually using Irrlicht Liite 1 3/7 and AngelScript. And I wrote for me project, for the game programming course, this was 2008- ish, I built a project using these two things and I remember asking the instructor if I could use these things going “You may…, but I can’t help you if you do… You sound like you know what you’re doing, but I can’t be able to help you, if you do it!”. So that was basically his response and I went with it. So, I was using AngelScript and I had some interesting bugs where objects would go out of sync, because they’d exist on the script side but not on the engine side. I probably could’ve, like I probably wasn’t managing something very properly. But yeah, AngelScript didn’t make that as easy as I would’ve liked. And Lua made it easier.

TS: So, during your engine development phase, did you ever stop and start making a game with it? How long until you went: “This has enough features, I’ll make a game”.

ZL: Well…a couple of times. Because remember, I re-built it. So, I had this engine, I had all these things built together, already a version of it in high school. And I built a game in high school. I never released it. I might still have a copy of it. I have no idea if I could compile it. It was built for Windows XP. I graduated High School in 2007, so this game would’ve been built in 2006. And it worked! It was pretty good. I was actually my second one, I built a game before that. So the sec- ond one was a turn based tile based strategy game, set in space basically. You had planets and you would build things on the planets. You could then use the planets to make ships and things. You then could use the ships to colonize the planets and so forth. It was in retrospect, in game design context, WAY too complicated. But I had a lot of fun building it, and actually a bunch of people enjoyed playing it. The kind of people that enjoy Civ. But it was not so easy to pick up. The previous one I built for the science fair, because in the US we had the science fair and you’re required to participate. And that year I built…actually maybe I have the order of these wrong.

ZL: Anyway, I built two of these. That was a real-time strategy game, like StarCraft. And I built this game for the sole purpose of building an AI for it, for the science fair. My science fair project was “Artificial intelligence in strategy games”. And it went really far…It got all the way into the state level competition, and I had encountered a lot of people who were really excited about the pro- ject. At the state level you compete at the local university, and there was one guy walking around from the AI department of the university and he goes: “This is cool, let’s talk about it”.

ZL: In retrospect, it was cool I just didn’t realize it. I was doing neural networks and genetic algo- rithms in 2006 - 2007. But in any rate, yeah I built two different games with some version of this engine in high school. I built a game, a couple different things in university. I released none of it. But I built them. Liite 1 4/7

TS: Shame that you didn’t release them.

ZL: It’s one of those things that especially in the earlier times these were released in these kind of harder, not so common, and I’m really, really old school. Because, I started programming in 1998. I didn’t even have version control when I started. I would copy the whole folder, and I didn’t even have dipping tools. It was another time… The things I would’ve done for dipping tools and version control.

TS: What’re the biggest hurdles and something in hindsight you would’ve wanted to do differ- ently?

ZL: Version control. It existed, it had been around since the 80s. But it wasn’t easy then. We sure didn’t have GIT. But by -98, we would’ve had CVS, we probably would’ve had SVN by then. Cause these things were still proliferating, they weren’t really around.

ZL: This was still in the age of Sneakernet. I will preface this with, about half my stories are stolen or borrowed from the game industry when I was young. I’ve learned them from the industry ex- perts and the giants who came before. Version control in most software things, it’s still fairly recent. There were things that used it, but they were few and far between. It is a common thing, that is really recent. But in the early days of game development, what this meant was you used Sneakernet. This must be since you didn’t have necessarily good network between computers. What you’d do was you’d have a sticky note on the computer, that would indicate that it is the owner of a certain area of code. And when you needed to take the ownership of that code, you’d get a floppy, with the current version of this code, you would walk over to that computer and you would copy that version onto yours. Steal the sticky note, and take it back to your computer, you are now the, one of these terms was “The Flame”, so you’d be the Flame of the…pathfinding, or whatever. And when it came time to merge all these things together, you’d really have to like get all the different copies and put them together and get all to work together.

TS: Som anything else other than version control. What was a really time consuming part of the game engine development?

ZL: the main things I remember were things caused by versioning. And problems caused by not knowing things, because I was self-taught. I learned all these things from myself, and just kind of trying things out, and reading books on game development.

Liite 1 5/7

TS: How was information on the internet on that time? Probably non-existent?

ZL: It existed… well, some of it existed. By the time I was in middle school, Wikipedia was a thing. But it wasn’t reliable. By the time I was in high school, it was a reasonable reference for finding more information. Nowadays it’s really impressive. And, I think Stack Overflow was invented when I was in late high school. And of course, it didn’t have near the wealth of information.

ZL: So, all this started to be available, but most of them weren’t as good as they are now. There weren’t tons and tons of blogposts on “How to do X thing”. Unity didn’t exist, and this kind of stuff. So, if Unity would’ve existed, I wouldn’t have made my own engine. I would have not both- ered, but at the time, if you wanted to make a thing, you needed an engine. And if you really wanted an engine, you’d take an existing thing, and re-build it so it would work the way you wanted to. That was how you did stuff. Or you would made the engine from scratch, if you were like Lucas Arts. But they were really pioneers, so…

TS: And they had a lot more people making the engine.

ZL: They had a few more people than like one…and they had a lot more time. The stories I get out of Lucas Arts Entertainment, like they were a division of Lucas Arts, they were thrown a lot of money, and nobody knew what they wanted out of it. Like, “Go make a game. We don’t know what that requires, but make it good, go try your things”. They went and they built tools, they tried new stuff. They hired people based on really clever things. For instance, Mark Ferrari, is one of the pioneering pixel artists. And when they first hired him, he was saying that “I know nothing about computers”, and “that’s fine, we find it easier to teach artist computers, than teach com- puter guys art.”

TS: So last question, I kind of have the idea, that people really shouldn’t create game engines nowadays.

ZL: No, nowadays it’s not worth doing.

TS: Why do you think so?

ZL: I will back up slightly. It is not worth doing, if your intent is to make games. If you wanna make games, use an existing engine. Doesn’t really matter if you’re a big company, or a little company, or a solo dev, use an existing engine. This is starting to be the case if you wanna make movies! Use an existing engine. That’s becoming more and more of a thing, when you think of Pixar is using Unreal or something. Unreal and Unity are really trying to push into the movie industry. Liite 1 6/7

Which is hilarious and awesome. But the reasoning for… the thing is, you CAN make an engine, if your goal is to make engine and distribute that, sell that, market that, that would be the thing you’d make. Because, if that’s what you’re doing that a huge undertaking. An engine is complex, it’s huge, it requires tons and tons of work. If you’re trying to build a game, you’ll never get to it. You’ll never get to the point where you spend enough time on that, you’ll always be working on the engine. And it’s just not financially worth doing. If you’re looking at different time or actual monetary expenses, an engine costs too much to do in comparison to just “I’ll take this one and use it for free”.

TS: Even with a team of people creating the engine?

ZL: There are very, very specific cases I would think creating an engine being useful. And it’s if you’re building something really, really specific and very high performance. If you’re looking to build a extremely complex, robust simulation system, like Factoria, where you also don’t have to worry much about building really complex graphics system, that makes sense. Keen Software has built their own engine, that they built that engine for Space Engineers. And they’ve been pushing its abilities with Medieval Engineers. And it’s the same base engine. And the reason for this they’re doing really high performance, very complicated voxel systems. That makes sense. But, you have to be doing something pretty specific that you’re really not going to be doing well in Unreal or Unity. I can give general references for which engines I think work well for different things if you want.

TS: You can.

ZL: Unreal, still definitely has its roots in first person shooters, it clearly evolved out of that. It’s been working away from it, but its still definitely got it. Unity was built to be an engine, to do kind of general things, but it’s definitely a 3D engine. It is getting smarter about how it does things, there’s been a lot of points where I’ve been very annoyed on how it approaches certain things. They’ve gotten more clever with their package system, it’s very good now. They’re clearly working towards being a much more general, much more “All the thing you need, in order to do X”, which is the right direction I think. Unreal, I have not worked with enough in order to be super informa- tive on it. If you’re trying to do something super high performance, and you still want to use an existing engine, I think you might be able to get pretty far with Unreal. Mostly because of the way its built and the languages it uses. Which being C++ to do things. But these days you can use C++ to do things in Unity too. But the actual architecture of Unreal enables better performance, I think. And then if you wanna do a 2D thing, I’d go with something like Godot, but there’s tons of Liite 1 7/7 engines out there. Löve is very good, Löve is based on Lua. And literally, there’s so many, I wouldn’t bother going through a whole list. I work with Godot and Löve, they work for myself.

TS: Thank you so much for this interview. Liite 2 1/2

David Barr (javidx9) haastattelu

1. I'm assuming you've created the olc pixel game engine all by yourself. How long was a project of that size in development?

I did. It was a redevelopment of my previous olcConsoleGameEngine (CGE). The CGE took approx- imately 50 man hours to get to a state where I was happy to release it. It grew organically after that with additional tweaks and fixes, but it was usable and the core utility didnt change much. It had limitations, and I wanted to cater for Linux users, so I developed the PixelGameEngine (PGE). Since the interface was already there, this was a case of rewriting the back end, and this took about 80 man hours before I was happy with it. It also required testers using different flavours of Linux. If you include the extensions, 2D, 3D, Sound, Joypads etc, this was easily another 200 man hours. Im currently developing PGE2.0 which so far has been about 120 man hours, but I predict only another 10 or so before release.

2. If you had a team of developers creating an engine the same scope as the pixel game engine, what would be a reasonable estimate for a team of three programmers.

The PGE and its extensions have taken approx 300 man hours to date, so 100 with a team of 3. Easy huh?

3. What are the benefits of creating your own engine, compared to using other freeware engines?

The PGE is a little unique in this case because it was developed as a tool so I could make videos.

The fact that a community has developed around using it is a bonus. The main driver for me was to ensure it required no external libraries other than whats included with a default install of de- velopment tools on most systems. I also wanted it to use really old technology, but in a clever way, which significantly increased its adoption. Not everyone around the world has good com- puters or modern operating systems. These decisions ensured that beginners and experienced developers alike could immediately start working with the PGE. There's literally nothing to install.

But to answer your original question, off-the-shelf game engines will need customisation unless you want your project to look and feel like a "hello world". If you dont customize, you are limited to the features available to that engine, which may make your game feel very similar to others and may not even support a specific gamplay dymanic you are trying to achieve. Also, to get to the stage where you need to customize a game engine, you will need to have invested a lot of Liite 2 2/2 time into understanding it fully, at which point you may be committed to using it, and the end result may not be what you wanted originally. Having my own engines, I am not beholden to licences, and have complete control of their direction and utility, but...

4. What are the largest pitfalls that can happen during engine development?

...this can come at a significant cost. I dont have help. It's as simple as that. The pitfalls I experi- enced where unexpected usage, accelerated adoption and feature creep. Firstly, people started using the engine in ways I never envisaged, which is great, but starts placing demands on my time and reosurces as I try to accommodate the features that are missing. The adoption of my game engine was swift amongst the community, this meant bugs were discovered and needed fixing.

Finally, because it's my "baby", Im always trying to perfect it by adding more and more things that will likely never be used by anyone. Instead I should focus on using the engine rather than devel- oping it. I did experience an initial design flaw with the PGE which made it incompatible with previous versions, which frustrated the userbase. In hindsight it was obvious, but its surprising just how far you can run with an idea because you think it's right, even though the warning signs were already there.

5. What are some features that are missing that you would like to implement to the pixel game engine?

Heh, this is proprietary information! Are you a Patreon? XD

In the coming weeks Im releasing PGE2.0 which introduces features aimed more at the extended userbase rather than myself, including much faster sprite rendering, an integrated hardware ac- celerated 3D graphics interface, and an overhaul of the audio system. Its also significantly more portable to encourage all sorts of bizarre homebrew versions. Also its compileable to WebGL so it can run in the browser, making the deployment of PGE applications very easy, especially useful for jams and beginners.

Liite 3 1/2

Mathilde Nord (Avalanche Studios) haastattelu

1. What was the development process like during the beginning of the engine’s creation?

We have always worked with agile methods in the studio. In the beginning the focus was on mak- ing Just Cause and whatever we needed to make that game.

2. Did Avalanche create any other software during the development of the engine?

At the very start, the engine was developed at the same time as we did the first Just Cause. Then later Just Cause 2 and other titles. We have always had one or several titles in development and we have always focused engine development on things that make a practical difference for the games. As part of the engine development, we have made a number of tools to be able to author and prepare content for the engine. The biggest one is out JustEdit tool that allows you to author all aspects of the game and a build system with a comprehensive set of compilers to take content into suitable runtime formats.

3. How has the continuous development of the engine affected game development itself at Av- alanche?

Yes, in many ways. Because we have an engine that is really great at large scale outdoor scenes you notice that most of our games take place outdoors. We do not have the need for loading screens as everything is streamed, so our games typically don’t have levels in the traditional sense.

4. What were the main struggles during the creation of the engine?

Developing an engine is a continuous process that is never really done. We are still developing it alongside with the games we are doing. For the first Just Cause, gertting the streaming system to work efficiently on all platforms was a big challenge. For Just Cause 2 it was making the engine efficient on PS3. When we later did MadMax, getting the quality of the vehicle system and the AI to control the vehicles was a big hurdle, as well as threading to make the game run at 60 fps.

5. What are the advantages of using the Apex Game Engine?

The Apex engine is optimized for any game where you want to create a seamless large open world game without loading screens. One of its many great features is that its tools set and content Liite 3 2/2 pipeline are tuned to let us create competitive content with comparably fewer content creators than with many other engines.