TEKNILLINEN KORKEAKOULU Tietotekniikan osasto
Ohjelmistoliiketoiminnan ja -tuotannon laboratorio
Vesa Oinonen
Pelin kehitys hyödyntäen avoimen lähdekoodin ohj elmistokomponenttej a
Diplomityö Espoossa 17.8.2006
Professori Reijo Sulonen Valvoja:
Ohjaaja: FT Mikko Välimäki
TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ Tietotekniikan osasto
Tekijä Päiväys
Vesa Oinonen 17.8.2006
Sivumäärä
71
Työn nimi
Pelin kehitys hyödyntäen avoimen lähdekoodin ohjelmistokomponentteja
Professuuri Koodi
Ohjelmistoliiketoiminta ja -tuotanto T3003
Työn valvoja
Professori Reijo Sulonen
Työn ohjaaja
FT Mikko Välimäki
Diplomityössä tutkitaan markkinoilta löytyviä avoimen lähdekoodin ohjelmistokomponentteja, joi
ta on mahdollista käyttää kaupallisen tietokonepelin kehityksessä. Diplomityössä toteutetaan keilai- luaiheinen tietokonepeli. Pelin toteutuksessa käytetään hyödyksi avoimen lähdekoodin komponent
teja seuraaviin toiminnallisuuksiin: 3D-moottori, fysiikkamoottori ja äänikirjasto. Komponenttien käyttämisellä pyritään pienentämään tuotekehityskustannuksia merkittävästi.
Teoriaosassa käsitellään ohjelmistokomponenttien valitsemismenetelmiä ja avoimen lähdekoodin ohjelmistojen erityispiirteitä. Avoimen lähdekoodin erityispiirteitä ovat lisenssiehdot ja kehittä
jäyhteisöt.
Työn tuloksena saatiin kartoitus markkinoilla olevista pelinkehitykseen soveltuvista avoimen läh
dekoodin ohjelmistokomponenteista sekä kehitettiin ja julkaistiin ilmaisena versiona tietokonepeli.
Pelistä on mahdollista jatkokehittää kaupallinen tuote myöhemmässä vaiheessa.
On olemassa useita avoimen lähdekoodin 3D-moottoreita, jotka täyttävät nykyaikaisen kaupallisen tietokonepelin vaatimukset. Laadukkaita avoimen lähdekoodin fysiikkamoottoreita ja äänikirjastoja on kuitenkin määrällisesti vähän. Pelin kehitys osoitti, että avoimen lähdekoodin komponenttien käyttäminen mahdollistaa tuotteen kehityksen pienillä tuotekehityskustannuksilla. Huomattavaa on kuitenkin se, että markkinoilta löytyvät pelin kehitykseen soveltuvat avoimen lähdekoodin kom
ponentit häviävät ominaisuuksiltaan hieman kaupallisille kilpailijoilleen. Merkittävimmät lyhyen aikavälin hyödyt avoimen lähdekoodin komponenttien käyttäjälle ovat pienet komponentin hank- kimiskustannukset ja mahdollisuus ottaa komponentti käyttöön nopeasti. Nopean käyttöönoton mahdollistaa se, että komponentti on toteutettu ja testattu valmiiksi ennen oman tuotekehitysprojek
tin alkamista. Pidemmän aikavälin hyötyjä ovat ohjelmistokomponenttien uudet versiot, käyttäjän mahdollisuus tehdä muutoksia ja parannuksia komponentteihin sekä käyttäjän riippumattomuus alkuperäisen ohjelmistokomponentin toimittajan tulevaisuudensuunnitelmista.
Avainsanat
Tietokonepeli, avoin lähdekoodi, ohjelmistokomponentti
HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF MASTER’S THESIS Department of Computer Science and Engineering
Author Date
Vesa Oinonen 17.8.2006
Pages
71
Title of thesis
Game Development Based on Open Source Software Components
Professorship Professorship Code
Software Business and Engineering T3003
Supervisor
Professor Reijo Sulonen
Instructor
Ph.D. Mikko Välimäki
In this Master’s thesis open source software components suitable for computer game development are studied. A computer game of bowling is developed. Open source components are used in the following functionalities: 3D-engine, physics engine and audio library. The goal for the use of software components is to save significantly at the development costs of the product.
Literature part of the work concerns the methods for selecting software components and special properties of open source software. Special properties of open source are license terms and devel
opment communities.
Results of the work are market analysis of open source software components suitable for game de
velopment and a computer game that was developed and published as a free version. The game may be used as a basis for a commercial product at a later stage.
There are several open source 3D-engines that fulfill requirements of commercial computer games, but only a few high quality open source physics engines and audio libraries exist. Development of the game proved that it is possible to reduce significantly in the development costs by using open source software components. However, open source components lose slightly in terms of features to their commercial competitors. The most significant short-term advantages of the use of open source software components are low acquisition costs and a possibility to take the component into use rapidly. Rapid adoption is possible because software components are already implemented and tested before own product development project begins. Long-term benefits are new versions of the software components, user’s right to make modifications to open source software components and user’s independence of the original software component provider.
Keywords
Computer game, open source, software component
Alkusanat
Tämä diplomityö on tehty Teknillisessä korkeakoulussa Tietotekniikan osastolla Ohjelmis- toliiketoiminnan ja -tuotannon laboratorioon.
Kiitos työni valvojalle professori Reijo Suloselle mahdollisuudesta tehdä diplomityöni mielenkiintoisesta aiheesta sekä hänen työtäni kohtaan osoittamasta kiinnostuksesta.
Suuret kiitokset työni ohjaajalle FT Mikko Välimäelle rakentavista neuvoista, kritiikistä ja kannustavasta suhtautumisesta.
Kiitokset Tomi Tukiaiselle pelin kehitykseen osallistumisesta.
Espoo, elokuu 2006
Vesa Oinonen
Sisällysluettelo
Lyhenneluettelo... 4
1 Johdanto... 5
1.1 Ongelman kuvaus...6
1.2 Tuotteen kehittämisen tarkoitus...7
1.3 Pelin aihepiirin kuvaus... 8
2 Komponentteihin pohjautuva ohjelmistokehitys... 9
2.1 Uudelleenkäyttämisen motiivit...9
2.2 OTSO-menetelmä... 10
3 Pelien kehitys...12
3.1 3D-moottori... 12
3.2 3D-grafiikan peruskäsitteet... 13
3.3 Fysiikan mallintaminen...14
4 Avoimen lähdekoodin erityispiirteet... 14
4.1 Avoimen lähdekoodin historia... 14
4.2 Lisenssit... 15
4.2.1 BSD, MIT ja ZLIB lisenssit...17
4.2.2 GNU General Public License... 18
4.2.3 GNU Lesser General Public License... 18
4.3 Lisenssien tarttuvuus ja vaikutus liiketoimintamalleihin... 19
4.4 Avoimen lähdekoodin projektit... ...19
4.5 Komponenttien valintakriteerit... 21
4.6 Versiointi ja ohjelmistojen jakelukanavat...21
4.7 Projektien haarautuminen...22
4.8 Avoimen lähdekoodin riskit... 23
5 Sovelluksen vaatimusmäärittely...24
5.1 Toiminnallisuudet 24
5.2 Kriteerit komponenttien valinnalle... 25
6 Komponenttien markkinakartoitus... 29
6.1 3D-moottorit...30
6.1.1 3D-moottoreiden arviointi... 31
6.1.1.1 Irrlicht... 32
6.1.1.2 OGRE... 34
6.1.1.3 Nebula Device... 35
6.1.2 3D-moottoreiden analysointi ja valinta... 35
6.2 Fysiikkamoottorit...36
6.2.1 Fysiikkamoottoreiden arviointi... 37
6.2.1.1 ODE...37
6.2.1.2 Tokamak Game Physics... 38
6.2.1.3 Newton Game Dynamics...39
6.2.2 Fysiikkamoottoreiden analysointi ja valinta... 40
6.3 Äänikirjastot... 40
6.3.1 Äänikirjastojen analysointi ja valinta... 41
6.4 Yhteenveto komponenttien valitsemisesta... 41
7 Pelin suunnittelu ja toteutus... 42
7.1 Prototyypin rakentaminen...42
7.2 Arkkitehtuurin suunnittelu...46
7.3 Toteutus... 50
7.4 Pelin julkaisu... 54
8 Analyysi...56
8.1 Komponenttien jälkiarviointi... 56
8.2 Komponenttien valitsemisperusteiden arviointi...60
8.3 Johtopäätökset...61 8.4 Yhteenveto... 64 Lähteet... 67
Lyhenneluettelo
3D Kolmiuloitteinen
BSD Berkeley Software Distribution D3D Direct3D, 3D-grafiikkarajapinta DLL Dynamically Loadable Library
DMF Deled Map File, 3D-mallien tallennusformaatti FSF Free Software Foundation
GCC GNU Compiler Collection
GNU GNU’s Not Unix
GPL GNU General Public License HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol
LGPL GNU Lesser General Public License MinGW Minimalist GNU for Windows
MIT Massachusetts Institute of Technology
ODE Open Dynamics Engine
OGRE Object-oriented Graphics Rendering Engine OpenGL Open Graphics Library
OSI Open Source Initiative
OTSO Off-The Shelf Option, ohjelmistokomponenttien arviointi- ja valitse
mismenetelmä
PHP PHP: Hypertext Preprocessor
1 Johdanto
Viimeisten vuosien aikana avoimeen lähdekoodiin perustuvien ohjelmistojen suosio on kasvanut maailmalla, erityisesti palvelinsovelluksissa [Moc2000], Erilaisia aktiivisia avoimen lähdekoodin projekteja on tuhansia ja avoimen lähdekoodin ohjelmistoja kehite
tään sekä loppukäyttäjiä että ohjelmistokehittäjiä varten. Kaupallisessa ohjelmistotuoteke- hityksessä on käytetty ohjelmistokomponentteja nopeuttamaan tuotekehitystä ja paranta
maan tuotteen ominaisuuksia ja laatua [Koni 995]. Valmiiden komponenttien käyttämisellä pyritään pienentämään tuotekehityspanostuksia.
Tässä diplomityössä tarkastellaan avoimen lähdekoodin ohjelmistokomponenttien käyttä
mistä osana tuotekehitystä. Ohjelmistokomponenttien käyttämisellä pyritään pienentämään tuotekehityskustannuksia. Diplomityön kirjallisessa osassa tutkitaan avoimen lähdekoodin erityispiirteitä ja esitetään aikaisemmin tutkittuja komponenttien valitsemismenetelmiä.
Diplomityössä kartoitetaan markkinoilta löytyviä kaupallisen pelin kehitykseen soveltuvia avoimen lähdekoodin ohjelmistokomponentteja. Työn aikana kehitetään kaupalliseen levi
tykseen soveltuva tietokonepeli, jonka kehityksessä hyödynnetään valittuja avoimen läh
dekoodin ohjelmistokomponentteja. Pelin aihepiiri on keilailu.
Diplomityö on tehty diplomityön tekijän oman aiheen pohjalta. Diplomityön tekemisen motiivina on liiketoiminnan harjoittaminen myymällä kehitettyä peliä, mikäli innovatiivi
sella tuotekehityksellä pystytään kilpailemaan muiden toimijoiden kanssa ja tuotteelle löy
tyy riittävästi kysyntää.
1.1 Ongelman kuvaus
Tietokonepelejä on tehty henkilökohtaisten tietokoneiden yleistymisestä lähtien. Pelien ominaisuudet ovat vuosien kuluessa kehittyneet huikeasti. Useimmissa nykyaikaisissa pe
leissä on näyttävä reaaliaikainen 3D-grafiikka, realistinen fysiikanmallinnus ja verkkope
limahdollisuudet. Komponenttipohjainen tuotekehitys on yleistä pelikehityksessä [Bis 1998]. Peliyhtiöt ovat perinteisesti kehittäneet tarvitsemansa komponentit itse tai ovat lisensoineet ne alihankkijoilta tai toisilta peliyhtiöiltä [Rol2003a],
Avoimen lähdekoodin projekteja on syntynyt viimeisten vuosien aika kasvavalla vauhdilla.
Palvelinsovelluksissa avoimeen lähdekoodiin pohjautuvat ratkaisut ovat lisääntyneet 2000- luvulla merkittävästi. Parhaiten menestyneitä avoimen lähdekoodin sovelluksia ovat Apache HTTP-palvelin yli 50 % markkinaosuudellaan [Moc2000] ja Linux käyttöjärjes
telmä yli 200 % vuotuisella kasvulla [Ler2002b], Myös useita pelinkehitykseen soveltuvia ohjelmistokomponentteja on kehitetty avoimen lähdekoodin kehittäjien toimista. Avoimen lähdekoodin sovelluksien takana on joukko avoimen lähdekoodin kehitysyhteisöjä. Avoi
men lähdekoodin kehittämiseen löytyy erilaisia motiiveja kuin kaupallisissa tuotteissa.
Avoimen lähdekoodin ominaispiirteitä ovat lähdekoodin saatavuus, oikeus muokata ohjel
maa sekä oikeus levittää ohjelmaa edelleen [Gac2004], Usein avoimen lähdekoodin sovel
lukset ovat ilmaisia.
Ohjelmistokomponenttien uudelleenkäyttöä ja kaupallisten ohjelmistokomponenttien valit
semismenetelmiä on tutkittu tieteellisissä julkaisuissa. Komponenttien käyttämisellä on pyritty kustannustehokkuuteen ja laadun parantamiseen. Tässä diplomityössä tutkitaan avoimen lähdekoodin erityispiirteiden vaikutusta komponenttien valintakriteereihin, teh
dään markkinakartoitus pelin kehitykseen soveltuvista ohjelmistokomponenteista ja kehite
tään kaupalliseen käyttöön soveltuva keilailuaiheinen tietokonepeli. Komponenttien mark- kinakartoituksen avulla hankitaan tietoa olemassa olevista pelin kehitykseen soveltuvista ohjelmistokomponenteista. Komponenttien valitsemismenetelmää käytetään valittaessa komponenteista tarpeisiin soveltuvin vaihtoehto. Valittuja komponentteja hyödyntäen to
teutetaan kaupalliseen toimintaan soveltuva tietokonepeli.
Käyttö avoimen lähdekoodin lisenssiin
T uotteen kehittäminen
hyödyntäen komponenttia
lähdekoodin kehittävät
Kehittäminen
Käyttää Avoimen
lähdekoodin komponentti
Suljettu ohjelmisto (peli)
Kuva 1. Tuotekehitys hyödyntäen avoimen lähdekoodin komponentteja.
Diplomityössä käsitellään avoimen lähdekoodiin liittyviä ominaispiirteitä käyttäjän näkö
kulmasta. Toteutettavaa peliä ei julkaista avoimena lähdekoodina vaan tuotekehityksen osana käytetään avoimeen lähdekoodiin pohjautuvia komponentteja. Avoimen lähdekoodin komponenttien kehityksestä vastaavat kehittäjäyhteisöt, joihin komponentin käyttäjillä ei ole suoraa vaikutusvaltaa. Tässä työssä käsitellään avointa lähdekoodia yhtenä ohjelmisto
tuotannon menetelmänä pienentää omia kehityskustannuksia. Julkaistava tuote tulee sisäl
tämään useita avoimen lähdekoodin komponentteja, mutta loppukäyttäjälle peli esitetään yhtenäisenä viimeisteltynä tuotteena, ilman että loppukäyttäjän tarvitsee tuntea käytettyjä komponentteja tai kehitysmenetelmiä.
Diplomityössä tutkitaan onko mahdollista kehittää pienillä tuotekehityskustannuksilla ominaisuuksiltaan kilpailukykyinen peli käyttämällä markkinoilta löytyviä tietokonepelien kehitykseen soveltuvia avoimen lähdekoodin komponentteja.
1.2 Tuotteen kehittämisen tarkoitus
Tarkoituksena on kehittää tietokonepeli, jota on mahdollista myydä Internetin välityksellä loppukäyttäjille. Peli on keilailupeli. Pelin ensisijainen kohdekäyttöjärjestelmä on Mic
rosoft Windows. Mahdollisesti myöhemmin tuetaan Mac OS X-käyttöjäijestelmää sekä yleisimpiä Linux-jakeluita. Tarkoituksena on mahdollistaa tuotteen myyminen loppukäyt
täjille, joten kaikkien pelissä käytettävien komponenttien on sallittava jakelu ja kaupallinen käyttäminen. Pelin lähdekoodia ei liiketoiminnallisista syistä haluta julkaista.
Tuotteen kaupallistaminen on jaettu kolmeen vaiheeseen: tuotteen kehittäminen, Internet- sivuston perustaminen, palautteen kerääminen loppukäyttäjiltä sekä tilaus-, toimitus- ja maksuprosessin kehittäminen.
Ensimmäisessä vaiheessa peliä kehitetään suljetussa ympäristössä. Oman tuotekehityksen ensimmäinen prioriteetti on minimoida loppuasiakkaalle hyötyä tuottamaton työ. Tavoit
teen saavuttamiseksi pyritään käyttämään aina kun on mahdollista muiden tekemiä kom
ponentteja ja välttämään omaa ohjelmointityötä. Toinen tavoite on minimoida ylläpitotyön tarve, minkä takia vältetään muutoksien tekemistä komponentteihin. Ensimmäisen tuote- kehitysvaiheen lopputuloksena on tehty toimiva, helposti käytettävä ja asennettava peli, joka pyrkii olemaan kilpailukyinen kaupallisten tuotteiden kanssa. Pelin ensimmäinen ke
hitysversio tulee olemaan yhdellä tietokoneella pelattava peli. Peliin kehitetään monen pe
laajan mahdollisuus, mutta pelaaminen tapahtuu samalla tietokoneella.
Pelistä tehdään ilmainen julkaisu ennen tuotteen kaupallistamista. Ilmaisen version avulla pyritään varmistamaan että tuotteelle löytyy riittävästi kysyntää. Mikäli tuotteelle ei löydy tarpeeksi kysyntää ilmaisena versiona, voidaan päätös tuotteen kaupallistamisen lopettami
sesta tehdä tässä vaiheessa tai kehittää tuotteesta parempi ilmainen versio. Peliä varten täy
tyy kehittää Intemet-sivusto, joka mahdollistaa pelin lataamisen käyttäjän tietokoneelle ja tuotteeseen tutustumisen. Sivustolle laitetaan mahdollisuus antaa palautetta pelistä. Näin pyritään saamaan konkreettista tietoa pelin hyvistä ja huonoista puolista käyttäjien näkö
kulmasta. Samalla pyritään kartoittamaan pelin toimivuutta erilaisilla laitealustoilla.
Pelin seuraava tuotekehitysvaihe on toteuttaa peliin Internetin kautta toimiva pelaajien pis
teytysjärjestelmä, jonne pelaajat pystyvät lähettämään omia pelituloksiaan. Tarkoituksena on luoda kilpailua pelaajien välille ja kilpailuhenkisyyden kautta nostaa pelin kiinnosta
vuutta.
Kolmantena vaiheena on kehittää pelistä maksullinen versio. Kaupallistamisvaiheessa In- temet-sivustolle kehitetään mahdollisuus ostaa peli. Diplomityön aihe rajataan kattamaan vain pelin ensimmäisen ilmaisen version kehittäminen.
1.3 Pelin aihepiirin kuvaus
Kehitettävä tuote on keilailupeli. Keilailu on suosittu urheilulaji Euroopassa ja Yhdysval
loissa. Suomessa rekisteröityneitä pelaajia oli 2005 vuonna 214 000 [Kei2005] ja keilailu on Yhdysvaltojen suosituin urheiluharrastus. Vuoden 2005 aikana 53,1 miljoonaa amerik
kalaista oli käynyt keilaamassa vähintään kerran [Bow 1998]. Peli on aihepiiriltään rajoitet
tu riittävän suppealle alueelle, joten keilailupelin toteuttaminen on mahdollista pienin hen
kilöresurssein.
Keilaus kuuluu urheilupelien lajityyppiin. Lajityyppien käyttäminen on yleisin tapa kuvail
la pelejä [Bjö2003], Urheilupeleille tyypillisiä piirteitä ovat reaalimaailmasta tunnetun ym
päristön simuloiminen ja se että useimmat uudet käyttäjät ovat tietoisia pelin tarkoituksesta ja säännöistä ilman erillistä opetusta [Rol2003b] [Cra2003]. Pelimaailman simulointi vaatii ympäristön ja fysiikan mallinnusta. Fysiikan mallinnuksen avulla voidaan saada aikaiseksi reaktioita pelimaailmaan, joita pelaaja odottaakin tapahtuvan. Kuitenkaan pelin fysiikan mallinnuksen ei tarvitse vastata täysin todellisuutta, sillä pelaajille tärkeämpi ominaisuus on tapahtumasta seuraavien reaktioiden ennustettavuus sekä yhdenmukaisuus [Hec2000], Keilailupelin tulisi olla graafisesti näyttävä ja fysiikanmallinnukselta realistinen, jotta tuote pystyy kilpailemaan menestyksekkäästi olemassa olevia kilpailijoita vastaan. Kilpailevia tuotteita on markkinoilla, mutta suurimmassa osassa ei ole aitoa 3D-grafiikka tai realistista fysiikan mallinnusta.
2 Komponentteihin pohjautuva ohjelmistokehitys
Tässä kappaleessa kuvaillaan komponenttien uudelleenkäyttämisen hyötyjä sekä menetelmiä komponenttien valintaan.
2.1 Uudelleenkäyttämisen motiivit
Ohjelmistojen uudelleenkäyttöä on pidetty tärkeänä ratkaisuna useaan ohjelmistokehityk
sen ongelmaan ja uudelleenkäytön väitetään parantavan ohjelmistokehityksen tuottavuutta ja laatua [Koni995a], Ohjelmistokomponentti on itsenäinen, muista sovelluksen osista riippumaton yksikkö, jonka käyttämiseen on hyvin määritellyt rajapinnat. Komponentti
pohjainen suunnittelu käsittää komponenttien hankkimisen, kehittämisen ja integroimisen siten että uudelleenkäytettävyys paranee [Bud2004],
Komponentteihin pohjautuvan ohjelmoinnin oletettuja hyötyjä ovat kehitysajan lyhentymi
nen, koska erilliset kehittäjäryhmät voivat työskennellä eri komponenttien parissa ilman suurta tarvetta kommunikoida keskenään. Jos komponentin rajapinnat pysyvät muuttumat
tomina, voidaan komponentin sisäiseen toteutukseen tehdä muutoksia ilman, että kompo
nenttia käyttävää koodia täytyy muokata. Kolmas hyöty komponenttien käytöstä on ohjel-
man ymmärrettävyyden parantuminen, sillä ohjelman käyttöä voidaan tutkia komponentti kerrallaan [Par 1972].
Tietokonepelit sisältävät tyypillisesti toiminnallisuuksiltaan samankaltaisia ominaisuuksia, minkä takia pelejä kehittävät yritykset käyttävät uudelleen itse tehtyjä tai muiden tekemiä komponentteja [Rol2003a], Tällöin tuotekehitysajat lyhenevät, useille käyttöjärjestelmille ja alustoille kääntäminen on nopeampaa ja ohjelmakoodista tulee helpommin ylläpidettävä.
2.2 OTSO-menetelmä
OTSO-menetelmässä käsitellään pakattujen, uudelleenkäytettävien valmisohjelmien valit- semisprosessia [Koni995a] [Koni995b] [Koni996]. Menetelmä tukee ohjelmien etsimis
tä, arvioimista ja valitsemista sekä määrittelee tekniikan arviointikriteereiden määrittämi
seen. OTSO-menetelmä on hyvin määritelty, systemaattinen prosessi, joka kattaa koko uu
delleenkäytettävien komponenttien valintaprosessin. Se määrittelee metodin, jolla voi uu- delleenkäyttämistavoitteista johtaa komponenttien arviointikriteerit. Komponenttien valit- semisprosessi on jaettu OTSO-menetelmässä kuuteen eri vaiheeseen: etsiminen, seulonta, arviointi, analysointi, käyttöönotto ja jälkiarviointi. Kuvassa 2 esitetään OTSO- menetelmän mukainen komponenttien valitsemisprosessi.
Vaatimusmäärittely Tekninen suunnitelma P rojektisu u nnitelm a Organisaation ominaisuudet
nuksiin Muutokset vaati
Etsiminen
Palaute
Arviointikriteerin määritys
Seulonta
Kriteereiden määritykset
Arviointikriteeri Arvioitavat
Arviontien tulokset Arviointi
Kustannukset
Päätös Valittu
komponentti Arvon määritys
Kuva 2. OTSO-menetelmän komponenttien valitsemisprosessi [Koni996].
Etsimisvaiheessa etsitään komponenttikandidaatteja ja kirjataan ne ylös. Seulontavaiheessa erotetaan potentiaaliset komponentit muista tarkempaa tutkimista varten. Arviointivaihees
sa tutkitaan kuinka komponentit sopivat ennalta määriteltyihin arviointikriteereihin. Ana
lysointivaiheessa komponenttiarvioiden tuloksia arvioidaan toisiinsa nähden, minkä jäl
keen tehdään päätös käytettävästä komponentista. Käyttöönottovaiheessa valittu kompo
nentti otetaan käyttöön. Jälkiarvioinnissa arvioidaan valitun ja käyttöönotetun komponen
tin hyödyllisyyttä ja dokumentoidaan saadut tulokset mahdollista myöhempää käyttöä var
ten.
OTSO-menetelmässä määritellään komponenttien analysointiin käytettävät arviointikritee
rit ennen komponenttien etsimistä. Arviointikriteerien määrittelemistä varten suositellaan uudelleenkäyttötavoitteiden ja rajoituksien määrittelemistä. Uudelleenkäyttötavoitteissa tulisi määritellä missä kehitettävän sovelluksen osassa halutaan käyttää valmiita kom
ponentteja. Odotettavat säästöt tulisi myös arvioida rahan ja ajankäytön suhteen. Uudel- leenkäyttörajoituksissa voidaan asettaa esimerkiksi hankintojen maksimihinta ja määritellä vaadittavat käyttöjärjestelmä-ja ohjelmointikielivaatimukset.
Arviointikriteeriä määriteltäessä tulisi ottaa huomioon muitakin tekijöitä kuin teknisiä vaa
timuksia. OTSO-menetelmässä suositellaan jakoa funktionaalisiin, laadullisiin, arkkiteh
tuurisiin ja strategisiin kriteereihin. Funktionaaliset vaatimukset viittaavat tapauskohtaisesti määriteltäviin toiminnallisiin vaatimuksiin. Laadulliset vaatimukset ovat yleisemmin mää
riteltäviä vaatimuksia, joiden arvoja voidaan vaihdella tapauskohtaisesti. Laadullisia vaa
timuksia ovat esimerkiksi sallittu virheiden määrä ja dokumentoinnin laadukkuus. Arkki
tehtuuriset vaatimukset sisältävät teknisen toteutuksen vaatimuksia, esimerkiksi vaatimus tietylle ohjelmointikielelle tai vaatimus reaaliaikaiselle laskennalle. Strategiset vaatimukset vaikuttavat komponenttien valitaan ja ne voivat käsitellä esimerkiksi hankintakustannuksia tai toimittajaorganisaatiota itse tuotteen lisäksi. Esimerkkinä toimii toimittajan tulevaisuu
den suunnitelmien huomioon ottaminen.
Tässä diplomityössä käytetään OTSO-menetelmää komponenttien valitsemisessa. Arvioin
tikriteeriin vaikuttavia tekijöitä ovat pelin vaatimusmäärittely, liiketoiminnalliset vaati
mukset ja avoimen lähdekoodin erityispiirteet.
3 Pelien kehitys
Tässä kappaleessa käsitellään lyhyesti nykyaikaisissa tietokonepeleissä käytettäviä käsittei
tä ja tekniikoita. Näitä tietoja käytetään pelin vaatimusmäärittelyn tekemisessä ja käytettä
vien komponenttien tarpeiden määrittelyssä.
Pelin kehitys on jaettavissa pelin idean suunnitteluun, projektin hallintaan, sovelluksen arkkitehtuurin suunniteluun ja toteutukseen [Rol2003a]. Tässä diplomityössä keskitytään tekniseen suunnitteluun, idean tarkempi suunnittelu ja projektin hallinta jäävät työn aihe
piirin ulkopuolelle.
3.1 3D-moottori
Useimmat nykyaikaiset pelit toimivat reaaliaikaisesti päivitettävässä kolmiulotteisessa maailmassa. 3D-moottori on komponentti, jonka tehtävä on vastata kolmiulotteisten kappa
leiden geometrisen tiedon käsittelystä ja esittämisestä [Che2005]. 3D-moottori on yksi pe
lien ydinkomponenteista, sillä se vastaa pelimaailman esittämisestä käyttäjälle. Pelimootto- reita kehittävän NDL yhtiön tekemän tutkimuksen mukaan keskimääräisen kaupallisen pe
lin kehittämiskustannuksista 40 - 70 % kuluu 3D-moottorin kehittämiseen [Rol2003a].
Pelimoottori on 3D-moottoria laajempi kokonaisuus, jonka avulla on mahdollista tehdä pienellä ohjelmointityöllä tiettyyn kategoriaan kuuluvia pelejä. Pelimoottori on integroitu kokonaisuus moduuleita, jotka tyypillisesti hoitavat 3D-moottorin tehtävät, 2D-grafiikan piirtämisen, äänten käsittelyn ja pelimaailman fysiikan mallintamisen. Pelin kehittäjille jää pelilogiikan toteuttaminen ja pelimaailman mallintaminen [Lew2002].
3.2 3D-grafiikan peruskäsitteet
Tässä kappaleessa kuvataan lyhyesti 3D-grafiikan peruskäsitteitä. Käsitteiden kuvaaminen on tarpeen, jotta 3D-moottorille pystytään asettamaan vaatimusmäärittelyt.
Tekstuurikartoittaminen (texture mapping) on menetelmä, jolla asetetaan 3D-mallin pin
nalle 2-uloitteinen kuva [Heal997]. Tekstuurikartoituksen avulla pystytään lisäämään pin
nalle yksityiskohtia ja tekemään 3D-malleista realistisen näköisiä. Peleissä on käytettävä reaaliaikaista grafiikan piirtämistä, joten kuva on piirrettävä kymmeniä kertoja sekunnissa ruudulle jotta pelitapahtumat päivittyisivät sulavasti [Lam2000]. Valotuksen ja varjojen laskeminen on raskas operaatio. 3D-maailman valotus paikallaan pysyvistä valonlähteistä on mahdollista laskea etukäteen. Tämä on mahdollista valokartoitustekniikan (lightmap- ping) avulla, jossa kappaleen pinnalle vaikuttavat valaistustiedot tallennetaan erilliseen va- lotustekstuuriin [Ion2003]. Valokartoitustekniikkaa soveltuu erityisen hyvin sisätiloihin sijoittuviin peleihin.
3D grafiikan esittämistä eli renderöintiä varten on kehitetty rajapintoja, jotka sijaitsevat loogisesti sovelluskoodin ja 3D-grafiikkakortin ajureiden välissä. Yleisimpiä renderöintira- japintoja ovat Direct 3D ja OpenGL [Rol2003a] [Eck2003], Rajapintojen avulla sovellus- kehittäjät voivat tehdä laitteistoriippumattomia sovelluksia. Direct 3D on Microsoftin ke
hittämä rajapinta. Direct 3D kuuluu Microsoftin DirectX-multimediakirjastoon. DirectX kirjasto on käytettävissä vain Windows käyttöjärjestelmällä. OpenGL (Open Graphics Lib
rary) on alun perin SGI yrityksen kehittämä käyttöjärjestelmä- ja laitteistoriippumaton ren- deröintirajapinta. OpenGL on tuettuna muun muassa Windows, Linux ja Mac OS X käyttö
järjestelmillä. 3D-moottorit tyypillisesti kapseloivat renderöintirajapintojen käyttämisen, joten 3D-moottorin käyttäjän ei välttämättä tarvitse osata käyttää renderöintirajapintoja suoraan [And2005], 3D-moottorit voivat käyttää useita renderöintirajapintoja, mutta niiden käyttö on piilotettu loppukäyttäjältä yhteisen 3D-moottorin tarjoaman rajapinnan taakse.
Tämän seurauksena loppukäyttäjän ei tarvitse tehdä muutoksia koodiinsa kun renderöinti- rajapintaa vaihdetaan.
3.3 Fysiikan mallintaminen
Fysiikan mallintaminen on tapa toteuttaa todentuntuisia reaktioita kappaleiden liikkeisiin pelimaailmassa. Fysiikan mallintaminen liittyy läheisesti 3D-grafiikan esitykseen, mutta fysiikan laskeminen on mahdollista eriyttää omaan komponenttiinsa. Fysiikan mallintami
seen ja simuloimiseen erikoistunutta komponenttia kutsutaan fysiikkamoottoriksi. Tyypilli
sesti fysiikan mallinnus koostuu kappaleiden kosketuksen tunnistamisesta, kontaktitapah- tumien erottelemisesta, voimien laskemista sekä kappaleiden tilojen päivittämisestä [Hec2000], Kappaleille asetetaan fyysisiä ominaisuuksia kuten massa, nopeus, hitausmo
mentti, kitka- ja kimmokertoimet sekä kappaleen geometrinen muoto. Fysiikan mallintami
sen avulla peleistä tulee simuloituja, jolloin kappaleiden liikkeitä ei tarvitse määritellä etu
käteen vaan kappaleiden liikkeet lasketaan reaaliajassa. Kappaleiden törmäyksien tunnis
taminen on realistisen mallinnuksen kannalta erittäin tärkeää [Lug2005], Törmäyksien tun
nistaminen voi olla osa fysiikkamoottoria, mutta törmäyksientunnistusalgoritmit on mah
dollista eriyttää omaan kirjastoon.
4 Avoimen lähdekoodin erityispiirteet
Avoimen lähdekoodin sovelluksen ja projektit eroavat perinteisistä kaupallisista ohjelmis
totuotteista. Tässä kappaleessa käsitellään avoimen lähdekoodin erityispiirteitä käyttäjän näkökulmasta.
4.1 Avoimen lähdekoodin historia
Avoimen lähdekoodin kehittämisen juuret ovat peräisin 1960-luvulta [Ler2002b]. Kehitys
tä tapahtui yliopistoissa kuten MIT ja Berkeley, joissa lähdekoodin jakaminen oli yleistä.
1980-luvulla yritykset alkoivat suojata immateriaalioikeuksiaan ja rajoittamaan ohjelmisto
jen käyttöä. Vuonna 1983 MIT yliopiston tutkija Richard Stallman perusti instituution ni
meltä Free Software Foundation (FSF), jonka tarkoituksena oli kehittää vapaita ohjelmisto
ja. Instituutio kehitti erityisen lisenssin vapaan lähdekoodin kehitystä varten. Lisenssin nimi oli GNU General Public License (GPL). Lisenssi salli käyttäjälle ohjelman lähdekoo
din muokkaamisen ja jakelemisen sillä ehdolla, että muokattu lähdekoodi täytyi julkistaa eikä lisenssiehtoja saanut muuttaa. GNU on rekursiivinen akronyymi, joka tulee sanoista
GNU’s Not UNIX. GNU-projektin tarkoitus on luoda käyttäjälle vapaa ja ilmainen Unix yhteensopiva käyttöjärjestelmä.
Internetin yleistyminen 1990-luvulla mahdollisti vapaan lähdekoodin kehittämisen kiihty
misen [Ler2002b], Useita avoimen lähdekoodin projekteja syntyi 1990-luvulla, joista tun
netuin on Linus Torvaldsin kehittämä Linux-käyttöjärjestelmä. Toinen 1990-luvun ilmiö oli erilaisten avoimen lähdekoodin lisenssien yleistyminen. GPL-lisenssi oli 1980-luvulla hallitseva lisenssi, mutta 1990-luvulla yleistyivät sellaiset avoimen lähdekoodin lisenssit, jotka eivät vaatineet että kaikki ohjelman osat täytyy lisensoida saman lisenssin alaisena.
Vuodesta 2002 lähtien avoimen lähdekoodin projekteja isännöivälle SourceForge.net In- temet-sivustolle on rekisteröity vuosittain noin 20 000 uutta avoimen lähdekoodin projek
tia [Com2005].
Avoimen lähdekoodin kehittäjillä on erilaisia motiiveja kehittää avoimen lähdekoodin so
velluksia. Henkilökohtaisia motiiveja ovat muiden yhteisön jäsenten kunnioitus, oppimi
nen, rahan ansaitseminen, omiin tarpeisiin soveltuvan sovelluksen kehittäminen ja refe- renssityön tekeminen tulevia työpaikkoja varten [Ler2002b] [Fel2002], Avoimen lähde
koodin sovelluksien kehittämiseen osallistuu yrityksiä erilaisia liiketoimintamalleja käyttä
en. Yrityksiä kiinnostavia motiiveja ovat oman tuotteen markkinaosuuksien kasvattaminen, kilpailijoiden aseman heikentäminen, tuotteen kehittäminen olemassa olevan sovelluksen pohjalta, sovelluksen testaaminen käyttäjäyhteisöllä sekä muiden avoimen lähdekoodin kehittäjien tuotekehityspanoksien hyödyntäminen. Liiketoimintamalleja ovat muun muassa ohjelmistojen kehitys omaan käyttöön, sovelluksien paketointi ja myynti sekä sovellusalus
tan kehittäminen kaupallista tai tieteellistä tutkimusta varten [Gac2004] [Ros2005],
4.2 Lisenssit
Avoimen lähdekoodin kehitysmalli perustuu lisensointiin. Lisensointi on riippuvainen teki
jänoikeudesta [Hie2002], Tekijänoikeus kieltää teoksen kopioimisen, levityksen ja muunte
lemisen ilman oikeuden haltijan suostumusta. Tekijänoikeuden haltija voi lisenssillä myön
tää oikeuksia tekijänoikeuden suojaamiin ominaisuuksiin.
Open Source Initiative (OSI) on määritellyt, että avoimen lähdekoodin lisenssin täytyy sal
lia seuraavat oikeudet [Väl2005]:
• oikeus vapaaseen käyttöön
• oikeus kopiointiin ja jakeluun ilman lisenssimaksuja
• oikeus muokkaamiseen ilman lisenssimaksuja
• lähdekoodin on oltava avoin ja helposti saatavilla
Lisenssin täytyy sallia tekijänoikeuteen perustuvien tärkeimpien komponenttien käyttö il
man lisenssimaksuja. Oikeus vapaaseen käyttöön tarkoittaa, että käyttäjiä ei saa syrjiä minkään ominaisuuden mukaan, kuten kaupallisen käytön perusteella. Muokkaamisoikeu- teen voidaan sitoa velvoitteita, kuten velvollisuus julkaista muokattu versio.
OSI on hyväksynyt kymmeniä eri avoimen lähdekoodin lisenssejä. Niitä voidaan jaotella toiminnallisuuden ja historian perusteella. Toiminnallisia eroavaisuuksia ovat tarttuvuus ja sallivuus. Historiallisia jaottelutekijöitä ovat GNU, akateeminen, yhteisöllinen ja yrityksien lisenssit.
Toiminnallisia ominaisuuksia voidaan määritellä sen perusteella, minkälaisia oikeuksia lisenssi sallii lähdekoodin muokkaamiseen [Väl2005]. Tavallisesti tarttuva lisenssi tarkoit
taa sitä, että muokatun lähdekoodin jakeluehtoj a ei saa muuttaa. Jos lähdekoodi yhdistetään toiseen lähdekoodiin, minkä seurauksena syntyy yhdistetty teos, niin tavallisesti tarttuvan lisenssin ehdot eivät koske yhdistettyä teosta. Tämä tarkoittaa sitä, että yhdistettyä teosta saa jaella toisen lisenssin avulla. Voimakkaasti tarttuvat lisenssit ulottavat lisenssin katta
vuuden myös yhdistettyyn teokseen. Tämän seurauksena myös muu lähdekoodi on saman tai toiminnallisuuksiltaan vastaavan lisenssin alaisuudessa.
Toinen toiminnallinen jaottelutekijä on lisenssin sallivuus. Sallivuudella tarkoitetaan käyt
täjän oikeutta jakeluun, kopiointiin ja muokkaamiseen.
Vahvasti tarttuva
Kuva 3. Lisenssien toiminnallisuuksien vaikutukset [Väl2005].
Kuvassa 3 esitetään avoimen lähdekoodin lisenssin toiminnallisuuksien vaikutuksia johdet
tuihin ja yhdistettyihin teoksiin. Tavallisesti tarttuvia ja sallivia lisenssejä on mahdollista käyttää kaupallisissa tuotteissa, sillä tuote muodostaa yhdistetyn teoksen, joka on mahdol
lista lisensoida toisen lisenssin alaisena.
Seuraavaksi käsitellään yleisimpiä avoimen lähdekoodin lisenssejä, erityisesti miten ne vaikuttavat ohjelman käyttämiseen osana toisia tuotteita.
4.2.1 BSD, MIT ja ZLIB lisenssit
MIT [OSI2006a] ja BSD [0812006b] lisenssit ovat ensimmäisiä avoimen lähdekoodin li
senssejä ja ne ovat ominaisuuksiltaan sallivia. Myös ZLIB [OS12006c] lisenssi kuuluu sa
maan kategoriaan. Nämä lisenssit mahdollistavat lisensoidun koodin yhdistämisen kaupal
lisiin tuotteisiin. Muutoksia alkuperäiseen koodiin ei ole pakko julkaista, vaikka ohjelma julkaistaisiin binäärimuodossa [And2004], Sallivuuden takia MIT, BSD ja ZLIB lisenssien alaisia ohjelmistoja on mahdollista kehittää edelleen toisen lisenssi alaisena, mikä mahdol
listaa ohjelmiston siirtymisen avoimen lähdekoodin ohjelmistosta kaupalliseksi suljetuksi ohjelmistoksi. MIT, BSD ja ZLIB lisenssin alaisia ohjelmia voi käyttää helposti muiden avoimen lähdekoodin lisenssien kanssa yhteen. Tutkimuksen [Ler2002a] mukaan kehittä
jille ja järjestelmäylläpitäjille suunnatut menestyneet avoimen lähdekoodin sovellukset on julkaistu useimmiten sallivilla lisensseillä.
MIT lisenssissä annetaan käyttäjälle oikeus käyttää, kopioida, muokata, yhdistellä, julkais
ta, jaella, uudelleen lisensoida ja myydä kopioita ohjelmasta sillä ehdolla, että tekijät eivät ole minkäänlaisessa vastuussa ohjelman toiminnasta.
BSD ja ZLIB lisenssit ovat ehdoiltaan MIT lisenssin kaltaisia, mutta ne asettavat johdetuil
le teoksille ehdoiksi sen, että alkuperäisten tekijänoikeuksien haltijat mainitaan. ZLIB li
senssi vaatii, että alkuperäistä lähdettä ei saa tulkita harhaanjohtavasti ja alkuperäisten teki
jöiden mainitsemista suositellaan, mutta ei vaadita. BSD ja ZLIB lisensseissä ei vaadita, että johdettua teosta ei saisi lisensoida eteenpäin tiukempien lisenssiehtojen alaisina, kun
han lisenssien vaatimukset täytetään.
4.2.2 GNU General Public License
GNU General Public License (GNU GPL) [OSI2006d] on Free Software Foundation (FSF) järjestön kehittämä avoimen lähdekoodin lisenssi, mikä on ollut yleisin avoimen lähdekoo
din lisensseistä 1990-luvulla. GPL lisenssi on ominaisuuksiltaan vahvasti tarttuva, eli li
senssi asettaa rajoituksia johdetuilla ja yhdistetyille teoksille [And2004][Väl2005], Lisens
sin kehittämisen ideana on pitää ohjelmisto vapaana käyttäjän näkökulmasta. Lisenssi sallii käyttäjälle ohjelmiston jakelun ja muokkauksen ilman alkuperäisen lisensoijan lupaa, mut
ta kaikki johdetut työt täytyy lisensoida samojen rajoitusten ja ehtojen mukaisesti kuin al
kuperäinen työ. Lisenssin mukaan ohjelmistolla ei ole mitään takuita. Lisenssistä on jul
kaistu kaksi versiota ja kolmas versio on kehitteillä. Versio 2 on vuonna 2006 yleisimmin käytössä oleva GPL-lisenssi.
4.2.3 GNU Lesser General Public License
GNU Lesser General Public License (LGPL) [OSI2006e] on toinen FSF-järjestön julkai
sema avoimen lähdekoodin lisenssi. Lisenssi on tarkoitettu ohjelmakirjastojen julkaisemi
seen, minkä vuoksi lisenssiä nimitetään usein GNU Library General Public License nimi
seksi [And2004], Lisenssin tarkoitus on sallia LGPL-lisenssillä julkaistun kirjaston käyt
täminen sovelluksesta, jota ei ole julkaista GPL-lisenssin alaisena. LGPL lisensioidusta ohjelmistosta johdetut teokset on julkaistava saman lisenssin alaisena, joten LGPL-lisenssi on luonteeltaan tarttuva. Tämän seurauksena LGPL-lisensoituun kirjastoon tehdyt muutok
set täytyy julkistaa sovellusta jaeltaessa.
LGPL-lisensoituja sovelluksia käytettäessä osana kaupallista tuotetta on kiinnitettävä eri
tyistä huomiota rajapintojen käyttöön, jotta omasta sovelluksesta ei tule LGPL-
lisensoidusta ohjelmasta johdettua teosta. Jos näin osoitetaan tapahtuneen, niin koko sovel
lus on julkaistava LGPL-lisenssin alaisena. LGPL-lisenssi ei määrittele yksiselitteisesti komponentin käyttämisen ehtoja jotta lisenssi ei kattaisi koko yhdistettyä teosta. Ohjelma- kirjastoja on mahdollista käyttää dynaamisen linkityksen välityksellä, jolloin kirjasto eriy
tetään muusta sovelluksesta erilliseen kirjastotiedostoon. Toinen tapa käyttää ohjelmisto- kirjastoja on staattinen linkitys, jossa kirjasto sisällytetään sovelluksen binääritiedoston sisään. Varmempi käyttötapa LGPL-lisensoitujen kirjastojen käyttämiseen on dynaaminen linkitys, sillä staattisen linkityksen käyttäminen saattaa joidenkin tulkintojen ja tekijöiden mukaan tarkoittaa johdettua teosta [And2004], Kirjaston tekijöiden mielipide on syytä sel
vittää ennen kirjaston käyttämistä, mutta tällä asialla ei välttämättä ole laillisia vaikutuksia.
4.3 Lisenssien tarttuvuus ja vaikutus liiketoimintamalleihin
On olemassa erilaisia motiiveja julkaista koodi avoimen lähdekoodin lisenssin alaisena.
Osalle avoimen lähdekoodin kehittämisen motiivina on ideologia vapaista ohjelmista. FSF järjestön tarkoituksena oli kehittää lisenssi, mikä estäisi yrityksiä myymästä binäärimuotoi
sia versioita avoimen lähdekoodin pohjalta rakennettuihin sovelluksiin. GPL-lisenssi kehi
tettiin sitä varten, että ohjelmisto pysyy käyttäjälle vapaana [Dem2002],
GPL on vahvasti tarttuva lisenssi. Kaikki eivät ole halukkaita julkaisemaan omia lähde- koodejaan sen takia, että he käyttävät tuotteessa kolmannen osapuolen ohjelmistoa. Kak- soislisensointi on liiketoimintamalli, jossa samaa tuotetta lisensoidaan sekä kaupallisen li
senssin että avoimen lähdekoodin lisenssin alaisina [Väl2003], Kaupallisella lisenssillä yri
tys voi myydä oikeuksia tuotteeseen, joita vahvasti tarttuva avoimen lähdekoodin lisenssi rajoittaa. Esimerkkejä kaksoislisensointia käyttävistä yrityksistä ovat tietokantoja valmis
tava MySQL AB ja Quake-pelimoottoreita lisensoiva Id Software. Kaksoislisensointiin perustuvan liiketoimintamallin tuntemisesta on hyötyä, jos haluaa käyttää avoimen lähde
koodin ohjelmistokomponentteja osana omaa tuotettaan, sillä muuten voi rajata liian hel
posti esimerkiksi GPL-lisenssiä käyttävät komponentit potentiaalisten vaihtoehtojen jou
kosta.
4.4 Avoimen lähdekoodin projektit
Avoimen lähdekoodin kehitysyhteisöä voidaan kuvata sipulikuvaajan avulla [Ye2003], Mi
tä sisemmällä rooli on kuvaajassa, sitä tärkeämpi rooli on projektille. Rooleissa toimivien henkilöiden lukumäärä kasvaa uloimmille renkaille tultaessa.
¿¡set kehittäjä со je n korjaa Ikojen ilmoitta];
Lukijat Passiiviset käyttäjät
Kuva 4. Avoimen lähdekoodin projektin henkilöiden roolit [Ye2003].
Avoimen lähdekoodin projektiin liittyy usein joukko henkilöitä erilaisissa rooleissa, joilla on yhteinen kiinnostus käyttää tai kehittää sovellusta. Projektin vetäjä on henkilö, joka vas
taa projektin eteenpäin viemisistä. Usein tämä henkilö on projektin perustaja. Ydinjäsenet ovat pitkään projektissa vaikuttaneita henkilöitä, jotka ovat osallistuneet merkittävästi pro
jektin kehittämiseen. Aktiiviset kehittäjät osallistuvat aktiivisesti projektin sovelluksen ke
hittämiseen. Etäiset kehittäjät ovat henkilöitä, jotka satunnaisesti tekevät uusia ominai
suuksia tai vikojen korjauksia. Vikojen korjaajat tekevät pieniä vikojen korjauksia, joita vikojen ilmoittajat ovat ilmoittaneet. Lukijat ovat aktiivisia sovelluksen käyttäjiä, jotka ovat opetelleet sovelluksen lähdekoodia. Passiiviset käyttäjät ovat sovelluksen tavallisia käyttäjiä, jotka eivät vaikuta suoraan sovelluksen kehitykseen. Projektiin osallistuvien henkilöiden roolit voivat vaihtua yleensä käyttäjien itsensä toimesta, riippuen siitä kuinka suuri kiinnostus henkilöllä on kehittää projektia ja yksi henkilö voi toimia useammassa roolissa.
Suurin osa avoimen lähdekoodin ohjelmista on kehitetty pienen kehittäjäjoukon toimesta.
Sourceforge.net sivuston kypsien projektien kehittäjien lukumäärä on keskimäärin neljä [Kri2002],
Tässä diplomityössä ei kehitetä avoimen lähdekoodin ohjelmistoa, vaan pelkästään käyte
tään muiden avoimen lähdekoodin projektien yhteydessä kehitettyjä ohjelmistokomponent- teja. Työssä toimitaan komponenttien kehittäjien näkökulmasta passiivisen käyttäjän roo
lissa, sekä mahdollisesti vikojen ilmoittajan ja korjaajan rooleissa.
4.5 Komponenttien valintakriteerit
Avoimen lähdekoodin ohjelmistokomponentit tarjoavat yrityksille uuden vaihtoehdon komponenttipohjaiseen kehitykseen [Mad2004]. Yritykset voivat olettaa saavansa toistuvia ohjelmistopäivityksiä, kohtuullista laadun varmistusta, virheiden korjauksia ja hyvää tek
nistä tukea, jos komponentin kehittäjäyhteisö on tarpeeksi laaja ja aktiivinen. Aktiivinen kehittäjäyhteisö on tärkein tekijä ohjelmistokomponentin ylläpidettävyyden ja tuen varmis
tamiseksi.
Ohjelmistosuunnittelijat pyrkivät ensimmäisenä etsimään sellaisia ohjelmistokomponentte- ja, jotka sisältävät tarvittavat ominaisuudet ja toiminnallisuudet. Seuraavaksi tärkeimmät kriteerit ovat lisenssiehdot ja komponentin arkkitehtuurin yhteensopivuus kehitettävän so
velluksen kanssa [Mad2004],
Madanhoman ja Rahul [Mad2004] identifioivat kolme menetelmää sopivien komponent
tien etsimiselle: formaalit menetelmät, tekoälyyn perustuvat menetelmät ja ontologiaan pohjautuvat menetelmät. Yleisimmin käytetty tapa etsiä sopivia komponentteja oli kuiten
kin manuaaliset menetelmät eli Internetin hakukoneiden käyttö tai kokoelmasivustojen käyttäminen. Kokoelmasivustoja ovat esimerkiksi Sourceforge.net, tai Freshmeat.net, joi
hin on koottu iso joukko avoimen lähdekoodin projekteja.
Merkittävä komponenttien valintakriteeri on komponentin käyttäjälle tarjoamat rajapinnat.
Jos rajapinnat ovat hyvin määriteltyjä ja pysyvät muuttumattomina, komponenttiin on mahdollista lisätä ominaisuuksia tai tehdä suuria muutoksia ilman, että käyttää ohjelmistoa tarvitsee muokata [Mad2004], Tämä on avoimen lähdekoodin komponenttien käytössä tärkeää, sillä käyttäjällä ei ole itsellään täyttä kontrollia komponentin kehittämiseen.
Rajapintojen muuttumattomuus mahdollistaa komponenttien helpon päivitettävyyden uuteen versioon.
4.6 Versiointi ja ohjelmistojen jakelukanavat
Aktiiviset avoimen lähdekoodin sovellukset kehittyvät ja sovelluksista julkaistaan uusia versioita, jotka sisältävät uusia toiminnallisuuksia, virheiden korjauksia tai rakenteellisia muutoksia [Sca2004], Julkaisujen määrä ja julkaisutiheys voi olla tiheämpi kuin kaupalli
silla sovelluksilla, sillä jakelukanavana toimii yleisimmin Internet, mikä mahdollistaa uu
den jakelu version tekemisen pienillä kustannuksilla. Esimerkiksi Linux-käyttöjärjestelmän ytimen kehitystä tutkinut Eric Raymond [Ray2001] kuvaa versioiden päivitysten strategiaa
lauseella “Julkaise aikaisin, julkaise usein”. Aktiivisen kehitysvaiheen aikana Linuxin yti
mestä voidaan tehdä uusi julkaisu kerran viikossa tai jopa kerran päivässä.
Tiheän julkaisurytmin ja uusien ominaisuuksien lisäämisen takia useissa avoimen lähde
koodin projekteissa julkaistaan erillisiä vakaita versioita ja kehitysversioita. Kehitysversi
oista löytyvät uusimmat ominaisuudet, mutta ohjelmat voivat sisältää enemmän virheitä.
Eri projektit käyttävät erilaisia menetelmiä versioiden erottamiseen toisistaan. Esimerkiksi Linux käyttöjärjestelmän ytimen ja Apache HTTP palvelimen julkaisuissa käytetään kol
miosaista versiointia. Versio koostuu merkittävästä, vähäisestä ja päivitysnumerosta (esi
merkiksi “2.1.16”), joista parillinen vähäinen numero tarkoittaa vakaata versiota ja pariton kehitysversiota [Ehr2003], Avoimen lähdekoodin projektin versiointistrategian tunteminen auttaa soveltuvimman ohjelmaversion valitsemisessa. Jos käyttää vain avoimen lähdekoo
din komponentteja, niin on perusteltua valita vakaa versio, koska vakaita versioita on tes
tattu enemmän isomman käyttäjäjoukon toimesta kuin kehitysversiota. Kehitysversioita tutkimalla on mahdollista tutustua uusiin ominaisuuksiin, jotka myöhemmin todennäköi
sesti päätyvät komponentin vakaaseen versioon.
Avoimen lähdekoodin sovellukset ovat ilmaisia käyttäjälle. Ilmaisuuden takia avoimen lähdekoodin ohjelmiston julkaisija voi jakaa sovellusta pienillä jakelukustannuksilla, koska ohjelmistoa voidaan jakaa Internetin välityksellä. Ilmaisuuden takia ohjelmiston toimitus
prosessi koostuu vain ohjelmiston latauksesta. Avoimen lähdekoodin sovelluksien levittä
mistä varten on olemassa sivustoja kuten SourceForge.net, jotka vastaavat sovelluksen la
tauksista syntyvän verkkoliikenteen tarjoamisesta.
4.7 Projektien haarautuminen
Avoimen lähdekoodin projektit voivat haarautua useiksi projekteiksi, joissa tehdään alun perin samasta sovelluksesta erilaisia versiota [Moe2004], Avoimen lähdekoodin lisenssit sallivat johdettujen teoksien tekemisen kolmansien osapuolien toimesta, mikä mahdollistaa haarautumiset. Lisenssin tarttuvuus asettaa ehtoja haarautumisille. Ominaisuuksiltaan tart
tuvista lisensseitä haarautuneet sovellukset on julkaistava käyttäjille. Sallivat lisenssit mahdollistavat suljettujen haarojen tekemisen, jolloin haarautuneen tuotteen lähdekoodeja ei tarvitse julkaista. Kuvassa 5 esitetään projektin haarautuminen kahdeksi projektiksi, jot
ka tuottavat eri versioita alkuperäisestä sovelluksesta.
Projekti A
Projekti В А 1.0
А 1.2
Kuva 5. Projektin ja sovelluksen haarautuminen.
Haarautumisen syinä voivat olla projektin jäsenten sisäiset ristiriidat, erilaiset tavoitteet tai alkuperäisen projektin loppuminen. Jakautuneet projektit tuottavat lopulta yhteensopimat
tomia versioita sovelluksesta [Ler2002a] [Sca2004], Haarautumisen mahdollisuutta pide
tään kuitenkin hyvänä asiana [Moe2004], Haaraumia syntyy myös silloin, kun projektin ydinkehittäjiin kuulumattomat henkilöt lisäävät uusia ominaisuuksia tuotteeseen. Monet haaraumat ovat kestoltaan lyhytaikaisia, koska tehdyt muutokset ja lisäomaisuudet voidaan yhdistää takaisin alkuperäiseen päähaaraan.
Haarautumien tekemisen mahdollisuus takaa sovelluksen loppukäyttäjälle sen, että yksi osapuoli ei pysty täysin kontrollimaan sovelluksen tulevaisuutta sillä käyttäjät voivat tar
vittaessa muodostaa oman haaran. Esimerkkinä tunnetun avoimen lähdekoodin projektin haarautumisesta on Apache HTTP-palvelin, joka haarautui NCSA HTTPD -sovelluksesta alkuperäisen projektin loputtua [Moe2004],
4.8 Avoimen lähdekoodin riskit
Avoimen lähdekoodin komponenttien käyttämisessä osana omaa tuotetta on riskejä. Riske
jä ovat tekijänoikeusrikkomukset, patentit ja ohjelmistojen laatu.
Ohjelmistopatentit muodostavat riskin avoimen lähdekoodin sovelluksille [Mor2002], Pa
tenttijärjestelmä on kehitetty innovaatioiden edistämiseksi. Nykyään yritykset hakevat pa
tentteja lisensointitulojen takia ja strategisista syistä. Patenttiportfolion avulla yritys voi viestiä sijoittajille, estää uusien kilpailijoiden tulon markkinoille, puolustaa tai hyökätä oi
keudessa tai hyötyä ristiinlisensoinnista [Väl2005], Yksityisillä avoimen lähdekoodin ke
hittäjillä ei ole samanlaisia taloudellisia resursseja hankkia patentteja kuin suurilla yrityk
sillä. Yhteisöpohjaisten avoimen lähdekoodin projektien parhaat mahdollisuudet patentteja
vastaan ovat kunnossa olevat vastuuvapautuslausekkeet ja patentoitujen teknologioiden välttäminen. Osa avoimen lähdekoodin lisensseistä sisältää sisäänrakennetun lisenssin voimassaolon lopetuslausekkeen, minkä mukaan kehittävä sovellus ei saa sisältää mitään lisenssimaksuja kolmannelle osapuolelle. Tällainen lausuma on GNU GPL, LGPL, MPL ja Apache -lisensseissä, mutta se puuttuu BSD-lisenssistä [Väl2005].
Ohjelmiston laatu on riski avoimen lähdekoodin ohjelmistojen käyttäjälle. Avoimen lähde
koodin ohjelmistojen laadusta ei voi tehdä yleistyksiä, sillä useimmat projektit ovat muu
tamien kehittäjien tekemiä. Laatuun vaikuttaa välillisesti projektin ohjelmistokehitysmalli ja laatutavoitteiden asettaminen. Laatutavoitteet voivat vaihdella projekteittain. Projektin ydinkehittäjillä on ratkaiseva rooli siinä, minkä tasoista koodia sovellukseen liitetään ja miten hyviä tehdyt tekniset ratkaisut ovat [Gac2004],
5 Sovelluksen vaatimusmäärittely
Diplomityössä toteutetaan sovellus hyödyntäen avoimen lähdekoodin ohjelmistokom- ponentteja. Käytettävät komponentit tullaan valitsemaan OTSO-menetelmää käyttäen. Va
lintakriteereitä määriteltäessä tullaan ottamaan huomioon avoimen lähdekoodin erityispiir
teet sekä sovelluksen vaatimusmäärittely. Tässä kappaleessa kuvataan toteutettavan sovel
luksen vaatimusmäärittely. Vaatimusmäärittely sisältää sovelluksen toiminnallisuuksien kuvaamisen, tarvittavien ohjelmistokomponenttien kuvauksen sekä kriteerit komponenttien valitsemiselle.
5.1 Toiminnallisuudet
Kehitettävä sovellus on keilailupeli. Keilailun tarkoitus on kaataa keilapallolla keilaradan päässä olevia keiloja. Peliin toteutetaan aito 3D-mallinnuksen avulla ja kappaleiden liikkeet mallinnetaan fysiikan lakien mukaan.
Peliin toteutetaan keilailun pistelaskujärjestelmä [WTB2006]. Yksi peli koostuu kymmenestä ruudusta. Jokaisen ruudun alussa keilaradan päähän asetetaan kymmenen keilaa pystyyn kolmiomuodostelmassa. Pelaaja heittää kaksi keilapalloa ensimmäisten yhdeksän ruudun aikana, jos ensimmäisellä keilapallolla ei kaadeta kaikkia kymmentä keilaa. Kymmenennellä ruudulla pelaaja heittää kolme kertaa, jos pelaaja saa kaadettua kymmenen keilaa kahden ensimmäisen heiton aikana. Pelaaja saa yhden pisteen jokaisesta
kaadetusta keilasta. Jos pelaaja tekee kaadon, eli kaataa kaikki kymmenen keilaa yhdellä heitolla niin pelaaja saa seuraavista kahdesta heitosta kaksinkertaiset pisteet. Jos pelaaja tekee paikon, eli kaataa kymmenen keilaa kahdella heitolla yhden ruudun aikana, niin pelaaja saa seuraavasta heitosta kaksinkertaiset pisteet. Keilailun korkein saavutettavissa oleva pistemäärä on 300.
Sovellus tullaan toteuttamaan 3D-grafiikkaa käyttäen ja kappaleiden liikkeet tullaan mallintamaan fysiikan sääntöjen mukaisesti. Pelaajan toiminnat esitetään keilaajan silmistä kuvattuna ja keilapallon heittämistä ohjataan hiiren avulla. Kamerakulmia on mahdollista vaihtaa heiton tapahduttua. Peliin toteutetaan ominaisuus katsoa pelitapahtumia uusintana.
Sovellukseen toteutetaan äänien toistaminen, jotta pelitapahtumat tuntuisivat todentuntuisilta myös äänien osalta. Peliä on pysyttävä pelaamaan monen pelaajan pelinä käyttäen samaa tietokonetta. Peliin tullaan toteuttamaan mahdollisuus lähettää ja hakea pelituloksia keskuspalvelimelle Internetin välityksellä.
Peliin sisällytetään asennusohjelma, jotta loppukäyttäjien on mahdollisimman helppo ottaa sovellus käyttöön. Sovelluksen jakelukanava toimii Intemet-sivustot, joilta pelin voi ladata ensimmäisissä vaiheissa ilmaiseksi. Peliin toteutetaan selkeä käyttöliittymä ja käyttöohjeet, jotta pelaaja pystyy oppimaan pelaamisen ensimmäisellä pelikerralla.
3D-grafiikan esittämistä varten etsitään sopiva avoimeen lähdekoodiin perustuva 3D- moottori sekä keilojen ja pallon fysiikan mallinnusta varten fysiikkamoottori. Äänien soittamista varten tarvitaan musiikkikirjasto. Äänet ovat tärkeä tekijä pelin tunnelman luomisessa, mutta ohjelmiston kannalta riittää, että äänikirjasto pystyy soittamaan helposti äänitiedostoja. Äänien toistamista varten etsittiin ohjelmistokomponentti, josta löytyi toivotut ominaisuudet ja yksinkertainen rajapinta toiminnallisuuksien käyttämiseen.
Sovelluksen tietokoneelle asentamista varten etsitään valmiita asennusohjelmia.
5.2 Kriteerit komponenttien valinnalle
Komponenttien valintakriteereissä otetaan huomioon OTSO-menetelmän suosittelemat seikat ja huomioin avoimen lähdekoodin erityispiirteet. Ohjelmistokomponenttien valinta
kriteereitä käsiteltäessä täytyy ottaa huomioon liiketoiminnalliset vaatimukset. Ohjelmisto- komponentteja jaetaan tuotteen mukana loppukäyttäjille, joten käytettävän komponentin tulee sallia jakelu lisenssiehdoissa. Loppukäyttäjälle jaettava tuote julkaistaan omien li
senssiehtojen alaisena, joten käytettävien komponenttien lisenssien täytyy sallia kom
ponentin käyttö osana suljettua kaupallista ohjelmistoa. Nämä liiketoiminnalliset vaati
mukset rajaavat vahvasti tarttuvia lisenssejä käyttävät ohjelmistokomponentit pois varteen
otettavien vaihtoehtojen joukosta. Komponentteja arvioitaessa suositaan sallivia lisenssejä, mutta myös ominaisuuksiltaan tavallisesti tarttuvia lisenssejä on mahdollista käyttää.
Ohjelmistokomponenttien ominaisuudet ovat tärkein valintakriteeri. Pelin tarpeet huomioi
den asetetaan jokaiselle komponenttityypille ehdottomat vaatimukset, joita ilman tuotetta ei voi toteuttaa.
Kolmas käytettävä valintakriteeri on komponentin tarjoamat rajapinnat. Ohjelmistokompo
nenttien kehittäjien tarjoamien esimerkkiohjelmien olemassaolo on merkitsevä tekijä valin
takriteereissä. Esimerkkiohjelmien avulla voidaan arvioida komponentin tarjoamia ominai
suuksia. Esimerkkiohjelmien koodia tutkimalla pystytään arvioimaan nopeasti komponen
tin käyttäjälle tarjoamia rajapintoja. Hyvät esimerkkiohjelmat lyhentävät komponentin käytön opetteluun vaadittavaa aikaa.
Kaikkien komponenttien tulee toimia samalla kääntäjällä. Nykyisin suurin osa peleistä teh
dään C++ kielellä [Rol2003a], Ehdoton vaatimus kaikille komponenteille on se, että kom
ponenttia täytyy pystyä käyttämään C++ kielellä. C -ohjelmointikieltä voi käyttää C++ oh
jelmista, joten C-rajapinnan tarjoavat komponentit ovat käytettävissä. Usein C++ kielellä toteutetut ohjelmat tarjoavat C ohjelmia selkeämmät rajapinnat olio-ominaisuuksien ansi
osta. Komponenttien ehdoton vaatimus on, että komponenttia voidaan käyttää GNU GCC kääntäjällä. GNU GCC -kääntäjä toimii Windows, Linux ja Mac OS X käyttöjärjestelmillä.
Komponenttien valitsemisessa käytetään taulukoissa 1 - 4 esitettyjä yleisiä valitsemiskri- teereitä. Valitsemiskriteerit on jaoteltu OTSO-menetelmässä suositeltuihin osiin, joita ovat toiminnalliset kriteerit, laatukriteerit, strategiset kriteerit ja arkkitehtuuriset kriteerit.
Taulukko 1. Komponenttien toiminnalliset kriteerit.
Toiminnallinen kriteeri Mittari
Pakolliset ominaisuudet on löydyttävä hyvin toteu
tettuina.
Onko komponenteittain määritellyt pakolliset omi
naisuudet toteutettu?
Tuetut käyttöjäijestelmät Onko virallista tukea käyttöjärjestelmälle?
Windows 2000 / XP (pakollinen) Mac OS X (suositeltava) Linux (suositeltava)
Aktiivinen kehitys Komponentin kehitysaktiivisuus vuoden sisällä Komponentin suosio Kuinka paljon komponentilla on käyttäjiä Aktiivinen kehitysyhteisö Kuinka usein päivityksiä tehdään?
Komponentin käyttäjät Komponentin käyttäjien lukumäärä.
Tunnetut virheet Onko olemassa tunnettuja virheitä, jotka haittaavat olennaisesti komponentin toimintaa?
Komponentin vakaus Aiheuttaako komponentti ohjelmiston kaatumisia?
Taulukko 2. Komponenttien laadulliset kriteerit.
Laadullinen kriteeri Mittari
Selkeät C tai C++ rajapinnat Arvio rajapintojen selkeydestä.
Dokumentaation laatu Dokumentaation kattavuus ja selkeys.
Esimerkkiohjelmien määrä ja laatu Onko tärkeimmät ominaisuudet esitetty?
Taulukko 3. Komponenttien strategiset kriteerit.
Strateginen kriteeri Mittari
Lisenssi Suositaan sallivia (ZLIB, MIT, BSD) ja tavallisesti
tarttuvia (LGPL) lisenssejä.
Kaupallinen tuki Kyllä / ei
Toimittajan tulevaisuuden suunnitelmat Arvio julkaistuista tulevaisuuden suunnitelmista.
Komponentin kehitysmalli Arvio kehitysmallista.
Käyttäjäyhteisön aktiivisuus Arvio käyttäjien aktiivisuudesta osana kehitystä.
Kehittäjäyhteisön tuki Onko kommunikaatiokanavia kehittäjien ja käyttäji
en välillä?
Taulukko 4. Arkkitehtuurilliset kriteerit.
Arkkitehtuurillinen kriteeri Mittari
Komponenttia pystyttävä käyttämään C tai C++
kielellä
Kyllä/ei
Toimii GNU GCC kääntäjällä Kyllä / ei
3D-moottori on tärkein komponentti pelille, joten tämän komponentin tutkimiseen ja arvi
oimiseen käytetään eniten aikaa. 3D-moottorin on pystyttävä lukemaan mallinnusohjelmil
la toteutettuja 3D-malleja, joten ehdoton vaatimus on omaisuus ladata yleisimpiä 3D- mallinnusformaatteja. Keilauspelin kuvataan sisätiloissa, joten 3D-moottorin täytyy pystyä renderöimään sisätiloja tehokkaasti. Tuki valokartoitustekniikalle on pakollinen ominai
suus. 3D-moottorin täytyy pystyä toimimaan yhdessä fysiikkamoottoreiden kanssa. Laa
dukkaiden referenssipelien merkitys on eduksi 3D-moottorille. Käyttäjäyhteisön aktiivi
suus ja kehittäjien kehitysmalli otetaan huomioon valintakriteereissä.
6 Komponenttien markkinakartoitus
Tässä kappaleessa tutkitaan markkinoilta löytyviä ohjelmistokomponentteja. Kompo
nenttien kartoitus jaetaan seuraaviin alueisiin: 3D-moottorit, fysiikkamoottorit ja äänikir- jastot. Muita merkitykseltään vähäisempiä komponentteja varaudutaan käyttämään myö
hemmässä vaiheessa toteutusta.
Komponenttien valitsemisprosessi jaetaan OTSO-menetelmässä kuvattuihin vaiheisiin, eli etsimiseen, seulontaan, arviointiin, ja analysointiin. Käyttöönottoa ja jälkiarviointi kä
sitellään myöhemmissä kappaleissa.
Komponenttien etsimisessä käytetään hyödyksi yleisimpiä hakukoneita, avoimen lähde
koodin projekteihin erikoistuneita Intemet-sivustoja ja pelien kehitykseen erikoistuneita Intemet-sivustoja. Hakukoneita käyttämällä on mahdollista löytää Internet-sivuja hakusa
nojen perusteella, mutta useat hakukoneet järjestävät löydetyt sivut niiden suosion perus
teella. Hakukoneiden markkinajohtaja Google käyttää PageRank-algoritmia järjestämään sivut siten, että ensimmäiseksi tulee sivu, johon on viittauksia eniten painoarvoltaan mer
kittäviltä sivustoilta [Cho2004], Hakutuloksien järjestystä ja hakuosumien lukumäärää on mahdollista käyttää hyväksi pääteltäessä haettavan komponentin suosiota. Tuloksien mer
kitykseen on suhtauduttava hyvin kriittisesti, sillä hakutuloksien järjestykseen on mahdol
lista vaikuttaa hakukoneoptimoinnin avulla, käytetyt hakuehdot voivat olla huonoja, kom
ponentin Internet-sivut voivat olla huonosti toteutetut tai sovelluksen tyypistä käytetään sivustoilla eri nimityksiä.
SourceForge.net on suurin Intemet-sivusto, joka isännöi avoimen lähdekoodin kehitys
projektien kotisivuja. Sivustoita löytyy yli 100 000 avoimen lähdekoodin projektia ja yli miljoona rekisteröitynyttä käyttäjää [Sou2006]. SourceForge.netm omistaa OSTG (Open Source Technology Group) yritys.
Freshmeat.net on Internet-sivusto, joka sisältää indeksin tuhansiin sovelluksiin, joista suu
rin osa on avoimen lähdekoodin sovelluksia [Fre2006]. Sivusto sisältää metatietoa sovel
luksista, kuten sovelluksen nimen, kuvauksen, sovelluksen kategorian, lisenssin ja tuetut käyttöjärjestelmät. Freshmeat.netm omistaa OSTG yritys.
6.1 3D-moottorit
3D-moottoreiden etsimiseen käytettiin hakukoneita, 3D-peleihin keskittyviä kotisivuja, SourceForge.net:iä ja Freshmeat.net:iä. Taulukkoon 5 on koottu löydetyt 3D-moottorit.
Taulukko 5. 3D-moottoreiden etsimisen tulokset.
Nimi Lisenssi Käyttöjär
jestelmät
Ohjelmointi
kieli
Rajapin
nat
Valo- kartoitus
Irrlicht
http://irrlicht.sourceforge.net
ZLIB Windows,
Linux
C++ D3D,
OpengGL Kyllä
IrrlichtNX
http://www.irrlichtnx.mmdevel.
de
ZLIB Linux,
Windows, Mac
C++ D3D,
OpenGL
Kyllä
OGRE
http://www.ogre3d.org
LGPL Window,
Linux, Mac
C++ D3D,
OpenGL
Kyllä
Crystal Space
http://www.crystalspace3d.org
LGLP Linux, Mac,
Windows
c++ OpenGL Kyllä
OpenSceneGraph
http://www.openscenegraph.org
OSGPL (LGPL joh- dan-nainen)
Windows, Mac, Linux
c++ OpenGL Kyllä
Nebula Device
http://www.radonlabs.de/nebula .html
Oma, salliva Windows, Linux, Mac, XBox
c++ D3D Kyllä
Quake II Engine,
http://www.idsoftware.com/
business/technology/index.php
GPL / kau
pallinen
Windows, Linux
c++ D3D,
OpenGL
Kyllä
Genesis3D
http://www.genesis3d.com
Oma Windows c++ D3D Kyllä
XEngine
http://xengine.sourceforge.net
ZLIB Windows,
Linux
c++ OpenGL,
D3D
Ei
Soya 3D
http://gna.org/projects/soya
GPL Linux Python OpenGL Ei
CryptEngine http://crypt.wetgos.nl
MPL Linux, Win
dows, Mac
Java OpenGL Ei
Lescegra
http://memfrob.de/projects/les- cegra.html
LGPL Linux, Win
dows
C OpenGL Ei
QuakeForge
http://www.quakeforge.net
GPL Windows,
Linux
C++ OpengGL Kyllä
Raydium 3D Engine http://raydium.org
GPL Windows,
Linux
C/PHP OpenGL Ei
3Ddrome
http://www.3ddrome.com/en- gine.php
Oma Linux, Win
dows
c++
OpenGL Ei6.1.1 3D-moottoreiden arviointi
Tässä kappaleessa arvioidaan potentiaalisia 3D-moottoreita. Seulontaehtona on ominaisuus lukea yleisiä 3D-mallinnusformaatteja, valokartoitusominaisuus, salliva lisenssi ja aktiivi
nen kehitys. Avoimen lähdekoodiin perustuvia 3D-moottoreita löytyi etsimisvaiheessa run
saasti, joten komponenttien käyttäjällä on hyvät lähtökohdat analysointiin ja käytettävän komponentin valintaan omien arviointikriteereiden perusteella.
Löydetyistä komponenteista on rajattu pois kaikki komponentit, jotka eivät tue vaadittua valokartoitustekniikkaa. Jäljellä olevista komponenteista rajataan pois komponentit, joiden kehitys ei ole jatkunut vuodesta 2005 lähtien. Tämä rajaa vaihtoehdoista pois QuakeForge ja Genesis 3D komponentit. Jäljellä olevia komponentteja ovat Irrlicht, OGRE, Crystal
Space, OpenSceneGraph, Nebula Device ja Quake II Engine.
Quake II Engine on Id Software yrityksen kehittämä pelimoottori toimintapeleihin. Peli- moottori kehitettiin Quake 2 peliä varten ja yritys tarjoaa kaksoislisensoinnilla pelimootto
ria muille toimijoille. Pelimoottoria voi käyttää GPL-lisensoituihin peleihin ilmaiseksi, mutta muilla lisensseillä lisensoitaviin peleihin täytyy ostaa kaupallinen lisenssi hintaan
