LINKÖPINGS UNIVERSITETINSTITUTIONEN FÖR

TEKNIK OCH NATURVETENSKAP

Medietekniskt kandidatprojekt

CREATURE EVOLUTION

Gabriel BARAVDISH

Kalle BLADIN

Kristofer JANUKIEWICZ

Viktor KRAFT

Fredrik LINDNER

Linnéa MELLBLOM

Aron TORNBERG

gabba873kalbl330krija286

vikan661freli358

linme882aroto019

3 juni 2014

HandledareKarljohan Lundin Palmerius

Sammanfattning

Denna rapport tar upp teorier kring systemutvecklingsmetodik för projektarbetet Creature Evolutionsom utvecklades i kursen Medietekniskt kandidatprojekt på Linköpings Universitet.

Rapporten tar upp de arbetssätt och verktyg som står till grund för hur utvecklingen av mjukvarangenomförts. En inledning med bakgrund till virtuell evolution tas upp tillsammans med de avgräns-ningar som har lett till skillnader mellan detta och liknande projekt.

En grundläggande beskrivning av systemets olika delar, och hur de sammarbetar, tas upp; tillsam-mans med mer ingående beskrivningar av de algoritmer och strukturer som beskriver evolution avvirtuella varelser och visualisering av dessa. I redogörelsen beskrivs hur genetiska algoritmer tilläm-pats och anpassats efter de olika beskrivningarna av varelser och hjärnor som framförs.

En redogörelse över hur det grafiska användargränssnittet interagerar med användaren och ger envisualisering av hur evolutionsprocessen går till, och därmed hur en varelse lär sig utföra de mål somanvändaren definierat, följs av analyser av systemet och diskussioner kring vidareutveckling och valav avgränsningar.

i

Innehåll

Sammanfattning i

Figurer iv

Tabeller v

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte & frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Typografiska konventioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Arbetssätt 42.1 Projekthantering och projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Arbetsmetod och scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Kundkontakt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Redogörelse för systemet 83.1 Systemarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Varelsebeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Kropp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Hjärna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Simulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.1 Beräkning av fitness-värden . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Genetiska algoritmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4.1 Interaktion med evolutionen . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.2 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.3 Parning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Grafik 174.1 Visualisering & rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Grafiskt användargränsnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Fitness-egenskaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2.2 Simuleringsegenskaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.3 Implementering med Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Analys 205.1 Evolutionsprocessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Tidskomplexitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

ii

INNEHÅLL INNEHÅLL

6 Resultat 226.1 Resultat av evolutionsanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2 Resultat av tidskomplexitetsanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7 Diskussion och framtida arbete 247.1 Arbetsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.1.2 Kundkontakt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.1.3 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.1.4 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.2 Systemarktiektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.2.1 Trådning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.3 Varelsebeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.3.1 Komplicerad utveckling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.3.2 Val av hjärna - beteende . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.3.3 Utveckling av kropp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.4 Simulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.5 Meta-evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.6 Tidiga visioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8 Slutsatser 30

A Statistik ifrån GitHub 32

B Ordlista 33

C Kroppsuppbyggnaden för varelsebeskrivningar 34

D Personer involverade i projektet 35

iii

Figurer

2.1 Agil systemutvecklingsprocess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Utvecklingsprocessen i scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Ganttschema över projektettiden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Övergipande kommunikation mellan systemets olika delar. . . . . . . . . . . . . . . 83.2 Aktivitetsdiagram över evolutionsprocessen. . . . . . . . . . . . . . . . . . . . . . . 93.3 Illustration över hur kroppen, i detta fall hos en ponny, beskrivs med en trädstruktur.

Siffrorna anger djupet för motsvarande nod. . . . . . . . . . . . . . . . . . . . . . . 103.4 Illustration av enkelt neuralt nätverk, varje cirkelskiva representerar en nod och varje

pil representerar en insignal till den nod mot vilken pilen pekar. . . . . . . . . . . . 113.5 Illustration av stelkroppar och leder i den fysiska simuleringen. . . . . . . . . . . . . 123.6 Illustration av hur populationen sorteras med avseende på varelsernas fitness-värden. 133.7 Detaljerat aktivitetsdiagram över evolutionsprocessen. . . . . . . . . . . . . . . . . 143.8 Tournament selection för en population. . . . . . . . . . . . . . . . . . . . . . . . . 153.9 Parning av varelser genom kombination av genkoder via one point crossover. . . . . 16

4.1 En simulerad Ponny i scenen som försöker ta sig mot målet som representeras av densvävande grå kuben. I figuren representeras hela det grafiska gränssnittet på Mac OSX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1 Evolutionsprocessen medför en anpassning i form av minskat ackumulerat avståndtill målet för den evolverade ponnyn. Då värdet når ett lokalt minimum avstannarprocessen och varelsen är fullärd. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2 Samband mellan parametervärden och processortid. Y-axeln visar processortiden. X-axeln anger parametervärden från 1 till 300 med övriga parametrar låsta till 1. . . . 23

7.1 Illustration av ett funktionsträd med tre rötter (utsignaler) och tre löv (insignaler) ochåterkommande noder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

C.1 kroppsuppbyggnaden för de olika varelser; mask, ponny, krypare, människa, bord ochgroda, som används i programmet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

iv

Tabeller

1.1 Typografiska konventioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

6.1 Resultat av evolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

A.1 Antal commits på ’develop’ vid 3 juni 2014 . . . . . . . . . . . . . . . . . . . . . . 32

v

Kapitel 1

Inledning

Forskning kring evolutionsteorin har kommit en lång väg och blivit en brett accepterad teori somlockar ingenjörer att utforska områdets tekniska tillämpningar. De tekniska tillämpningarna kan ex-empelvis vara självlärande system och biologiska simuleringar, i syfte att evolvera fram ett optimeratbeteende istället för att manuellt programmera det gång på gång.

Creature Evolution är en programvara utvecklad för att simulera fördefinierade virtuella varelsersamt ge användaren möjligheten att tillämpa evolutionsalgoritmer och parametrar för att ändra hurvarelserna utvecklar sina beteenden. Projektet skapades med inriktning och tyngd på agil systemut-vecklingsmetodik.

1.1 BakgrundA multi-facited project where a model (creature) is evolved from simple into complicatedforms in a simulation (environment) based on fitness criteria (survival) using geneticalgorithms.

Denna beskrivning var utgångspunkten för utvecklingen av Creature Evolution tillsammans med in-spiration från tidigare forskningsprojekt inom området. En viktig milstolpe inom evolution av virtuellavarelser lades av Karl Sims - "Evolving Virtual Creatures"[1]. Med inspiration från detta, samt flerliknande projekt, lades grunden till arbetet. En viktig aspekt, utöver att lära virtuella varelser att utföraspecifika uppgifter, var att få med en igenkänningsfaktor i utseendet av dessa, vilket var något somofta saknades i tidigare arbeten.

Eftersom projektet genomfördes i kursen Medietekniskt Kandidatprojekt låg fokus på agil system-utveckling. En viktig aspekt i intresset för ämnet är bredden i kombination med dess medietekniskarelevans. Sammansättningen av algoritmer, signalbehandling och visualisering ger, tillsammans medsystemutvecklingsaspekten, en intressant och bred begreppsklass i vilken Creature Evolution grundarsig.

Kunden bidrog med initiella grundläggande krav. Dessa listas nedan.

• Att utveckla en snabb och interaktiv programvara för att simulera virtuell varelseevolution.

• Att varelsernas beteende och utseende ska ändras i evolutionen.

• Att användaren ska kunna visa olika generationer på skärmen och jämföra dem.

1

1.2. SYFTE & FRÅGESTÄLLNINGAR KAPITEL 1. INLEDNING

1.2 Syfte & frågeställningarMålet var att skapa ett system för en digital varelseutveckling där användaren har möjligheten attpåverka och interagera med utvecklingsprocessen för varelserna och evolutionen. Varelserna skallkunna evolveras på olika sätt beroende på användarens val i användargränssnittet och därmed skapaunika resultat för varje simulering.

Syftet är att få användaren att förstå och reflektera över hur evolution av virtuella varelser kanefterlikna hur varelser lär och beter sig i verkligheten.

Utifrån syftena grundar sig de mer konkreta frågeställningar som rapporten ämnar att svara på.

• Är det möjligt att skapa ett system för interaktiv, snabbt återkopplande, virtuell evolution?

– Vilka begränsningar sätter evolutionsprocessen och fysiksimuleringen på hur lång tid dettar att utveckla varelser?

– Vilka metoder kan användas för ett effektivisera tiden det tar att utveckla varelser?

• Är det möjligt att inom ovanstående begränsningar skapa ett system med evolution som ärintressant för en användare?

– Kommer systemets simuleringar resultera i oväntade lösningar?

– Kommer lösningarna att vara realistiska?

En del av syftet var även att studera hur den agila systemutvecklingsmetodiken kan vara till fördelför utvecklingen av större projekt.

1.3 AvgränsningarUnder hela projektets gång genomfördes många avgränsningar för att säkerställa att en fungerandeprodukt kunde slutföras inom projektets utsatta tid. Detta för att uppfylla projektets egna krav ochsamtidigt främja den agila utvecklingsprocessen.

De viktigaste avgränsningarna som gruppen beslutade om var följande:

• Utveckling av varelsens utseende beroende på miljö- eller överlevnadsvilkor. Avgränsningenblev att Creature Evolution inriktade sig på beteendeutvecklingen i varelsen istället för dessutseende. Exempelvis, istället för att varelsen utvecklade en ny kroppsdel för att röra sig fortareså fick den i uppgift att lära sig effektivisera rörelsemönstret med sin fördefinierade form.

• Ett enkelt och presentabelt användargränssnitt. Avgränsningen i det här fallet blev fokus påfunktionalitet framför elegans. Anledningen till detta beslut var att det främjade projektet merdå det gav frihet åt projektgruppen i utvecklingssyfte. Värt att nämna är att systemet är byggtför att en senare implementering av en prydligare och mer användbar design inte ska vara pro-blematisk.

2

1.4. TYPOGRAFISKA KONVENTIONER KAPITEL 1. INLEDNING

1.4 Typografiska konventioner

Tabell 1.1: Typografiska konventionerTeckensnitt eller symbol Innebörd Exempel

AaBbCc123 Engelska ord (först förekommande) Utvecklingsmetoden scrum tillämpades.AaBbCc123 Klasser och funktioner Klassen EvolutionManager har det övergripande ansvaret.AaBbCc123 Verktyg och programvaror Versionshantering sköttes med verktyget git.AaBbCc123 Bibliotek och API:er Systemet består av ett grafiskt användargränssnitt implementerat med Qt.

3

Kapitel 2

Arbetssätt

Systemutveckling, kallas den process för att ta emot en beställning från kund, skriva kravspecifikationoch från denna komma fram till en produkt. Arbetet sker enligt olika programvaruutvecklingsmeto-diker. En programutvecklingsmetodik är en metod som är vald för att genomföra programutveckling,med andra ord; vilken struktur som antas för en utvecklingsprocess. Processen består av en sekvensaktiviteter som är en samling av de organiserade tillvägagångssätten. Det är denna samling som göratt målet nås. Processen ska innehålla riktlinjer och restriktioner angående hur, när och vad som skagöras. Milstolpar och leverabler såsom prototyper och dokument ska även ingå i processen. En ge-mensam förståelse måste uppnås bland alla utvecklare för att alla ska kunna jobba på samma sätt.Inget arbete är det andra likt och därför måste alla metoder anpassas till det specifika projektet. Attha en gemensam metod gör det enklare att kommunicera med kunden och på så sätt få kunden insatti utvecklingsprocessen. I Figur 2.1 illustreras den agila utvecklingsprocessen som tillämpats i dettaprojekt.

Figur 2.1: Agil systemutvecklingsprocess.

4

2.1. PROJEKTHANTERING OCH PROJEKTPLAN KAPITEL 2. ARBETSSÄTT

2.1 Projekthantering och projektplanProjekthantering handlar om hur arbetet läggs upp mot ett specifikt mål. Det finns en början och ettslut där resurserna är begränsade. Som ett första steg för projekthanteringen utfördes en projektplan.Projektplanen står som grund för hur projektet ska hanteras och hur de olika arbetsmetoderna börgenomföras. Den skall hålla tydliga riktlinjer för vad som gäller inom projektets ramar samt dessrutiner.

2.2 Arbetsmetod och scrumInom agil utveckling finns utvecklingsmetodiken scrum. Utvecklingen sker iterativt i sprints, vilka ärkorta tidsintervall på cirka två till fyra veckor, se figur 2.2. Under varje sprint finns så kallade stories.En story definieras genom att svara på de fem frågorna: vem, vad, när, var och varför? [2]. På så sättbeskrivs tydligt att en viss person vill uppnå något specifikt och på så sätt blir det lättare att hittauppgifter för att uppfylla dessa stories. Några specifika stories väljs ut till varje sprint från en backlog,där alla stories finns listade utifrån utsatta krav och är rangordnade utifrån prioritet. Backlog är encentral del i scrum. Den grundar sig i kravspecifikationen och innehåller alla stories som beskrivervad en tänkt person, exempelvis användare eller utvecklare, vill få ut av programvaran för att uppnåspecifika ändamål.

En mer väldefinierad story kan i efterhand delas upp i mindre delar kallade tasks. En task beskriverhur en story ska lösas och bör ta ungefär en dag att genomföra för maximal produktivitet.

Figur 2.2: Utvecklingsprocessen i scrum.

De grundläggande mötena som hölls under projekttiden var så kallade Sprintplaneringsmöten ochdagliga scrum-möten. Sprintplaneringsmötet är planeringsmötet inför varje ny sprint. Här definierasmålen och tidsestimering för denna. Det dagliga scrum-mötet är ett kortare möte på cirka 15 minu-ter där utvecklarna får dela med sig av vad som har utförts, vad som planeras att utföras och vilkaförhinder eller problem som uppkommit. Dessa möten fungerade som utvärderingsmöten då varjegruppmedlem fick en helhetsbild över vad de övriga gruppmedlemmarna hade gjort.

Tidsintervallet för varje sprint valdes till två veckor, vilket motsvarade ungefär sex arbetsdagar,och sprint-mötena bestämdes att vara samma dag som en ny sprint började.

Kravhantering innebär fastställandet av intressenternas produktmål samt att specificera dessa. In-tressenter kan vara kunder men även användare, utvecklare och testare. Dessa varierar beroende påprojektet och vad som utvecklas.

Kravhantering är till stor del grunden i ett agilt projekt. Här specificeras kundens och gruppensegna krav på produkten. Att ha ett dokument med alla krav, en så kallad kravspecifikation, är enviktig del. Kraven ska vara mätbara och därmed innefatta kriterium som ska kunna gå att testa ochuppfylla. Kravspecifikationen består oftast av en punktlista, där varje punkt motsvarar ett krav. I en

5

2.3. DOKUMENTATION KAPITEL 2. ARBETSSÄTT

kravspecifikation beskrivs följande: systemets externa gränssnitt, funktionella krav samt kvalitetskravoch designbegränsningar. Kraven i detta projekt baserades främst på kundens och användarens villkor.

Kravspecifikationen fylls på av produktägaren, vilken är den som har kontakt med kunden, närnya krav eller mål kommer in.

De roller som användes i projektet var: scrum-master, produktägare och ett utvecklingsteam.Scrum-master hade ett övergripande ansvar för att de riktlinjer som bestämts inom den agila arbets-metoden efterföljdes. Produktägaren såg till att de krav, som kunden hade ställt, uppfylldes. Utveck-lingsteamet bestod av alla gruppmedlemmar och hade som syfte att arbeta för att utveckla en produktsom uppfyllde kraven.

2.3 DokumentationDokumentation finns inom ett antal olika områden, exempelvis koddokumentationen, levande ochstatiska dokument.

Inom koddokumentation finns extern och intern dokumenation. Intern dokumentation är för käll-koden och kan exempelvis vara för klasser och funktioner. Extern dokumentation däremot, är utifrånsystemets perspektiv och systemets arkitektur och moduldesign.

Andra dokument som ska skrivas inom ett projekt är exempelvis projektplan, ganttschema ochmötesprotokoll. Levande dokument är ett dokument som ständigt uppdateras och redigeras. Ett ex-empel på ett levande dokument är projektplanen. Statiska dokument dokumenterar en händelse somhar skett i en specifik tidsinstans och förändras inte, exempelvis mötesprotokoll eller ganttschema, se2.3.

Figur 2.3: Ganttschema över projektettiden.

2.4 VerktygFör gruppkommunikation användes Facebook. Tjänsten användes främst till att meddela tid och platsför möten, diskutera lösningsförslag kring en arbetsuppgift samt allmänna funderingar kring projektet.Versionshantering sköttes med verktyget git tillsammans med internettjänsten github. Dokumentationav kod planerades att hanteras med verktyget Doxygen som har funktionen att kunna generera kom-mentarerna i koden till HTML-format. För dokumentation av tidsschema användes Google Calendar,där gruppen på ett överskådligt sätt kunde hantera arbetsschemat med tid och plats.

6

2.5. KUNDKONTAKT KAPITEL 2. ARBETSSÄTT

Fillagring och filhantering för dokument och bilder sköttes med hjälp av Google Drive som harstöd för gemensam organisering av mappar, synkronisering och backup.

Trello är en webbapplikation som gör det möjligt för användaren att på ett smidigt sätt skötaprojekthantering. Användaren skapar så kallade boards som för detta projekt motsvarade sprints. Ivarje board kan användaren lägga till kort, som då motsvarar gruppens stories och tasks.

För att kunna utveckla på Windows, OS X och Linux så användes CMake. CMake kan genere-ra bygg- och projektfiler för olika utvecklingsmiljöer som exempelvis Visual Studio och förenklarprocessen med att länka tredjepartsbibliotek och övriga filer.

2.5 KundkontaktKommunikationen mellan produktägare och kunden hanterades via e-post eller under ett tidigare bo-kat möte. Vid projektets start gav kunden sina grundkrav; vissa av kraven visades efter undersökningdock vara ogenomförbara på grund av tekniska begränsningar, se 1.3. Kunden blev informerad omdetta och nya krav diskuterades fram.

7

Kapitel 3

Redogörelse för systemet

3.1 SystemarkitekturCreature Evolution är ett system som består av ett flertal moduler som samspelar i realtid. I börjanav projektet utvecklades ett flertal separata prototyper för att testa vilka olika aspekter som behövdes.En av de prototyper som gav mycket till hur systemet såg ut vid projektets slut var ett simpelt “Hello,World”-program som implementerades som en prototyp för genetiska algoritmer [5]. Det fungeradeså att programmet genererade strängen “Hello, world!” genom att först skapa slumpmässiga strängaroch evolvera dem tills målet “Hello, world!” nåddes. Detta lade grunden till hur genkoden senareskulle evolveras i de virtuella varelserna. Andra prototyper utvecklades för att testa funktionalitet ifysiksimulering, 3D-rendering och gränssnitt. I figur 3.1 visas en övergripande bild på hur systemetfungerar.

Figur 3.1: Övergipande kommunikation mellan systemets olika delar.

Renderingsmodulen sköter utritning av varelser och miljö och innefattar både fysikaliska stelkrop-par och passiva objekt.

Det grafiska användargränssnittet är gjort med biblioteket Qt. För att sköta den fysikaliska si-muleringen av varelserna används fysikbiblioteket Bullet. Detta är ett robust bibliotek med flera årsutveckling som är välanvänt inom många områden, speciellt för olika typer av visualisering. Det ärsärskilt utvecklat för realtidsapplikationer, som till exempel spel, vilket gjorde att det lämpade sig välför Creature Evolution.

Hela evolutionsprocessen behandlas av flera klasser. Klassen EvolutionManager har detövergripande ansvaret för att se till att evolutionen för alla generationer utförs korrekt.EvolutionManager måste kunna kommunicera med användargränssnittet och därför har den vis-sa beroenden av Qt för att kunna utnyttja Signals/Slots (sektion 4.2) samt trådning.

8

3.2. VARELSEBESKRIVNING KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

EvolutionManager utför inga tekniskt tunga processer i sig, utan delegerar det mesta tillandra klasser, nämligen de klasser som hanterar varelser och simulering. Evolutionsprocessen utförspå en separat tråd ifrån uppritning av gränssnittet och 3D-scenen. Detta för att möjliggöra interaktionmed programmet samtidigt som evolutionen simuleras. I figur 3.2 nedan visas ett aktivitetsdiagramför den övergripande evolutionsprocessen.

Figur 3.2: Aktivitetsdiagram över evolutionsprocessen.

3.2 VarelsebeskrivningBeskrivningen av den varelse som ska utvecklas består av två delar. Dels en kropp som bestämmervarelsens fysiska uppbyggnad och dels en hjärna som bestämmer varelsens beteende.

3.2.1 KroppKroppen är definierad via en trädstruktur se figur 3.3. Rotnoden till trädet är definierad som varelsenshuvud. Varje nod i trädet beskriver en kroppsdel som består av ett rätblock med specificerade dimen-sioner, densitet, friktion och en lista med kroppsdelar som förgrenas från noden i fråga. Varje nodinnehåller även definition för en gångjärnsled som bestämmer hur kroppsdelen i fråga är kopplad till

9

3.2. VARELSEBESKRIVNING KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

sin förälder i trädet. Varje led har en styrka, en position för kopplingen, en riktning leden kan röra siglängs samt gränser mellan vilka vinklar leden kan röra sig. Denna trädstruktur används sedan för attdefiniera en lista med leder och kroppar som används i simuleringen.

Figur 3.3: Illustration över hur kroppen, i detta fall hos en ponny, beskrivs med en trädstruktur. Siff-rorna anger djupet för motsvarande nod.

3.2.2 HjärnaHjärnan är designad för att vara oberoende av varelsens fysikaliska beskrivning eller hur varelsensimuleras. Interaktion mellan hjärnan och simuleringen sker via en funktion som tar en lista med flyttalsom insignal och ger en lista med flyttal inom intervallet -1,0 och 1,0 som utsignal. Insignalen hämtasperiodiskt från varelsens “sensorer” i simuleringen och utsignalen skickas till varelsens muskler, detvill säga kopplingarna mellan de stelkroppar som varelsen är uppbyggd av. Vilka insignaler somanvänds samt hur utsignalerna används finns beskrivet under sektion 3.3. Storleken på utsignal- ochinsignallistorna bestäms när hjärnan skapas och de beror på antalet muskler i kroppens beskrivning.Interaktion mellan hjärnan och evolutionsprocessen beskrivs under sektion 3.4. Tre olika övergripandemodeller för hjärnan undersöktes. Två av dessa impementerades och beskrivs nedan.

Sinusoid hjärna

Den första modellen för en hjärna som undersöktes var den så kallade sinusoida hjärnan. Den sinuso-ida hjärnan har enbart simuleringstiden som insignal och varje utsignal bestäms av en sinusfunktionenligt (3.1) där ω1−3 är slumpade vikter definierade i hjärnan och t är simuleringstiden.

utsignal = ω1 sin(ω2t+ ω3) (3.1)

Parametern ω1 bestämmer amplituden för utsignalen och är begränsad till ett värde mellan 0,0och 1,0. Detta för att utsignalen ej ska anta värden med absolutbelopp större än 1,0. Parametern ω2

bestämmer frekvensen för utsignalen och är definierad så att den måste vara delbar med den lägstadefinierade frekvensen. Varelsens beteende blir då periodisk över den lägsta frekvensen. Detta pe-riodiska beteende är önskvärt för att varelsen ska behålla samma rörelsemönster och därmed få ettdefinierat beteende oberoende av simuleringstiden. Parametern ω3 bestämmer fasförskjutningen ochär till en början bestämt till ett värde mellan 0,0 och 2π. Denna modell är enkel och därmed begränsad;då den simulerar en varelse som inte kan reagera på sin omgivning eller på sitt fysiska tillstånd.

Enkelt förstyrt neuralt nätverk (feedforward neural network)

En annan hjärnstruktur som undersöktes var en simplare form av neuralt nätverk. Nätverket består avett lager med insignalnoder, ett eller flera lager med gömda noder och ett lager med utsignalnoder, sefigur 3.4.

10

3.2. VARELSEBESKRIVNING KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

Figur 3.4: Illustration av enkelt neuralt nätverk, varje cirkelskiva representerar en nod och varje pilrepresenterar en insignal till den nod mot vilken pilen pekar.

Samtliga noder, med undantag från de i insignalslagret som enbart skickar ut insignalen, hämtarvärden från samtliga noder i föregående lager och använder dessa som argument i en funktion somger tillbaka en utsignal till nästa lager.

En modell är att insignalerna till noden multipliceras med vikter och summeras för att sedanskickas genom en överföringsfunktion f , se (3.2).

utsignal = f(∑n

(ωn · insignaln)) (3.2)

Ett bra val av överföringsfunktion är en sigmoidfunktion. Överföringsfunktionen har framförallttvå syften, dels att begränsa utsignalen mellan ett maximum- och ett minimumvärde och dels att införaolinjäritet i sambandet mellan insignal och utsignal. Utan överföringsfunktionen skulle antalet gömdanoder vara meningslöst. Utsignalerna skulle alltid bli en viktad summa av insignalerna, medan ettneuralt nätverk med bra överföringsfunktioner kan, beroende på antalet lager och noder, ge en bredvariation av utsignaler.

Förutom de insignaler som valts, adderas även en konstant insignal; en etta, som i övrigt användslikadant som de andra insignalerna. Syftet med denna insignal är att möjliggöra en förskjutning i x-led. Om det antas att en sigmoidfunktion är en approximativ stegfunktion så har funktionen sitt steg inoll. Detta är dock inte nödvändigtvis alltid vad som önskas. Genom att lägga till en konstant som ärlika med ett till summan i (3.2), så erhålls en förskjutning av överföringsfunktionen som är lika medkonstantens vikt negativt [6].

Erfarenhet visar att ett neuralt nätverk med ett gömt lager, där antalet gömda noder är medel-värdet av antalet insignaler och utsignaler med viktad summering, samt en sigmoid-funktion somöverföringsfunktion, är en bra utgångspunkt vid design av neurala nätverk och fullt tillräckligt för deflesta applikationer [7].

Det neurala nätverket kan i teorin ta emot vilka insignaler som helst. I praktiken är det dockinsignalerna som inte rör sig inom bestämda intervall utan växer obegränsat, såsom tid och avståndfrån start blir meningslösa. Stora avstånd och tidsintervall kommer i praktiken ge samma resultat då ensigmoidfunktion går mot ett konstant värde när dess argument går mot oändligheten. Ett sätt att göradenna typ av insignaler meningsfulla skulle vara att skicka dem genom en periodisk funktion för attpå så sätt ge varelsen ett periodiskt beteende över tiden eller över en sträcka. Stora värden bör överlagundvikas som insignal av samma anledning som ovan, även om signalen inte växer obegränsat. Enstor insignal kan visserligen kompenseras genom multiplikation med en liten vikt. Vikterna väljsdock slumpmässigt, och även i det fall att en vikt är i rätt storleksordning, komplicerar det mutationeneftersom mutationen i sådana fall måste vara svagare för denna vikt än för de övriga. Om det är känt

11

3.3. SIMULERING KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

mellan vilka värden en insignal håller sig bör den normaliseras till att hålla sig mellan 0,0 och 1,0eller -1,0 och 1,0. För att undvika för starka signaler initialt, kan vikterna sättas till låga värden; tillexempel mellan -0,1 och 0,1.

Slutgiltig implementation av hjärnan

I den slutgiltiga implementationen används det enkla neurala nätverket. Endast ett lager av gömdanoder används då det visade sig vara tillräckligt för att varelserna skulle kunna lösa uppgiften. Antaletgömda noder sätts till fem gånger medelvärdet av antalet insignaler och utsignaler, då det visade sigatt fler noder gav mjukare och bättre rörelser för varelserna. För många noder blir dock tyngre attberäkna och ger fler vikter att mutera och därmed en långsammare evolutionsprocess. Som överfö-ringsfunktion används hyperbolisk tangens, detta är en sigmoidfunktion som är billig att beräkna, ochbegränsar utsignalen mellan -1,0 och 1,0. Vikterna för genkoden i varelsens hjärna sätts initialt till ettvärde mellan -1,0 och 1,0.

3.3 SimuleringSimuleringen av varelserna sker i Bullet. En fysikvärld med ett plan och en statisk kropp (målpunkt)bestäms. Utifrån varelsebeskrivning skapas en lista med sammankopplade leder och stelkroppar somläggs till i fysikvärlden. Självkollision mellan varelsens lemmar är avstängt.

Figur 3.5: Illustration av stelkroppar och leder i den fysiska simuleringen.

Världen simuleras med tidssteget 1/30 sekunder. Var sjätte tidssteg skickas en lista med insignalertill hjärnans funktion och utsignalerna används för att, via Bullet-funktionen enableAngularMotor,uppdatera ledernas rörelse. Till enableAngularMotor anges en målhastighet samt en max-impulsför att uppnå den hastigheten. Målhastigheten är konstant men tecknet på den bestäms av utsignalenstecken. Max-impulsen bestäms av storleken på utsignalen multiplicerat med ledens fördefinieradestyrka.

Som insignaler används en konstant etta, ledernas vinklar samt tre värden som anger riktnings-vektorn mellan varelsen och målpunkten relativt varelsens huvuds riktning. Detta gör det möjligt förvarelsen att känna till sitt nuvarande tillstånd samt om rätt kurs hålls mot målpunkten.

Anledningen till att hjärnan endast anropas var sjätte tidssteg är för att ge varelserna längre reak-tionstid. Då varelserna tilläts uppdatera motorerna varje tidssteg lärde de sig ofta att de kunde ta sigframåt genom att vibrera vilket varken är önskvärt eller fysikaliskt möjligt i verkligheten. Då dettaär ett problem relaterat till fysikmotorn vore det bästa om detta gick att lösa på fysiknivån. Det vi-sade sig dock att det enklaste sättet att lösa detta problem på, var att helt enkelt ge varelserna sämrereaktionstid.

12

3.3. SIMULERING KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

3.3.1 Beräkning av fitness-värdenUnder simuleringen samlas data, så kallade fitness-värden, in om hur varelsen betett sig i simulerings-världen.

De fyra mätvärdena som används i programmet är:

• Det för varje tidssteg ackumulerade avståndet till målpunkten som anger hur bra en varelse ärpå att undvika eller följa en definierad punkt i simuleringen.

• En varelsens tyngdpunkts högst nådda position under simuleringen, vilket är tänkt att beskrivahur bra varelsen hoppar.

• Det för varje tidssteg ackumulerade höjdvärdet för tyngdpunkten som anger hur bra en varelseär på att hålla sig upprätt.

• Det för varje tidssteg ackumulerade höjdvärdet för varelsens huvud vilket anger hur bra envarelse är på att hålla huvudet högt.

Det totala fitness-värdet är det som anger hur välanpassad en varelse är utifrån den givna upp-giften. För att bestämma varje varelses totala fitness-värde normaliseras varje mätvärde utefter denvarelse som har högst i respektive fitness-värde. Därefter viktas varje värde utifrån användarens valav vikter; det vill säga vilka värden som har högst prioritet. Mätvärdena summeras slutligen för attge varje varelse sitt totala fitness-värde. Efter att totala fitness-värden är erhållna för varje varelse i enhel generation kan denna sorteras. Processen illustreras i figur 3.6.

Figur 3.6: Illustration av hur populationen sorteras med avseende på varelsernas fitness-värden.

13

3.4. GENETISKA ALGORITMER KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

3.4 Genetiska algoritmerGenetiska algoritmer ska efterlikna processen av naturligt urval och tillhör Evolutionära Algoritmer[8]. Genetiska algoritmer bygger på att, iterativt, få fram en lösning på ett problem, som till exem-pel kan vara att iterera fram bättre och bättre varelser som lär sig att snabbare ta sig till ett mål.För generering av nya varelser krävs metoder såsom parning, där genkoder korsas, eller mutering,där genkoden manipuleras. Därefter finns det krav, eller villkor, som ett mått på när de genetiska al-goritmerna har nått fram till en lösning som stagnerat. I Creature Evolution utgörs dessa vilkor avvarelsernas fitness-värden.

En central del i användandet av genetiska algoritmer är att kunna generera slumpmässiga tal.I Creature Evolution används Mersenne twister [9] för att generera slumpmässiga tal inom olikaintervall. Mersenne twister har goda spridningsegenskaper och lämpar sig därför att användas för attmodellera slumpmässigt beteende.

Evolutionsprocessen startar med att skapa en slumpmässig population av varelser. För varje gene-ration i evolutionsprocessen så skapas en ny population baserat på den föregående generationen. Po-pulationen sorteras utifrån de beräknade fitness-värdena som erhålls under simuleringen. Hela dennaprocess illustreras i aktivitetsdiagrammet i figur 3.7.

Figur 3.7: Detaljerat aktivitetsdiagram över evolutionsprocessen.

14

3.4. GENETISKA ALGORITMER KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

3.4.1 Interaktion med evolutionenBeroende på olika parametrar: elitism ratio, mutation ratio och mutation strength; får evolutionspro-cessen något olika karaktär. Elitism ratio avgör hur stor del av populationen som går direkt vidare tillnästa generation utan att mutera. Detta för att undvika regression; det vill säga att den mest anpas-sade varelsen i nästa generation blir sämre än den i föregående generation. Sedan fylls populationenupp till den storlek som angivits av användaren i början av evolutionsprocessen. Vilka varelser somgår vidare till nästa generation avgörs genom tournament selection [8] som fungerar så att en varel-se slumpmässigt väljs ur populationen. Sedan jämförs, eller tävlar, den med en annan slumpmässigtutvald varelse. Den som har högst fitness-värde vinner och går vidare till nästa rond. Här möter dåvinnaren av föregående rond en ny slumpmässigt utvald varelse och detta upprepas tills en vinnarehar utsetts, se figur 3.8. Tournament selection medför att även svagare varelser har en chans att gåvidare till nästa generation och på så sätt bidra till genetisk mångfald.

Figur 3.8: Tournament selection för en population.

3.4.2 MutationFör att undvika lokala maximum, det vill säga varelser som klarar uppgiften mer eller mindre bramen inte utvecklar sig längre, användes mutation som utförs på alla varelser valda med tournamentselection. Det är mutation ratio- och mutation strength-parametrarna som avgör hur mycket varelsernamuterar. Ju högre värdena på dessa mutationsparamertrar är, desto lättare är det att undvika lokalamaxima. Allt för höga värden kan dock medföra att varelserna inte utvecklas lika snabbt på grund avatt mutationen hämmar evolutionsprocessen.

Mutation av sinusoid hjärna & neurala nätverk

Mutation av den sinusoida hjärnan och det neurala nätverket sker dels genom att antingen slumpmäs-sigt ta fram nya värden för några av parametrarna eller genom att förändra några av de existerandeparametrarnas värde genom att addera eller subtrahera ett mindre slumptal. Tanken med den senaremetoden är att åstadkomma en mindre förändring till utsignalen, istället för att ändra den. För att på såsätt, förhoppningsvis stegvis, komma närmare optimala värden. Det ger även möjlighet för paramet-rarna, eller vikterna, att växa obegränsat mycket om det visar sig vara en fördel, utan att mutationenför den delen har en obegränsad styrka.

Slutgiltig implementation av mutationen

Eftersom den slutgiltiga impelemtationen av hjärnan var ett neuralt nätverk, anpassades mutationenefter denna. Mutationsparametern mutation ratio anger hur stor chansen är att en viss del i hjärnansgenkod, det vill säga en viss vikt för kopplingen mellan två noder, ändras. Om en viss vikt muteras,adderas ett slumptal mellan −N och N där N anges av användaren genom parametern mutationstrength.

15

3.4. GENETISKA ALGORITMER KAPITEL 3. REDOGÖRELSE FÖR SYSTEMET

3.4.3 ParningVanligtvis tillämpas ytterligare en parameter, crossover ratio [8], inom genetiska algoritmer som be-stämmer hur stor del av varelserna som ska paras innan mutationen tillämpas. Parning, eller crossover,sker genom att kombinera genkoderna för varelsernas hjärnor. Till exempel genom one point crosso-ver, där genkoden för två varelser delas itu i en slumpmässigt vald pivotpunkt för att sedan korsas ochdärmed skapa två nya varelser, se figur 3.9.

Figur 3.9: Parning av varelser genom kombination av genkoder via one point crossover.

Parning mellan olika sinusoida hjärnor kan göras med denna metod om genkoden utgörs av para-metrarna till alla sinusfunktioner som styr musklernas rörelser. Det är oklart hur meningsfull dennatyp av parning är då utsignalernas värden i kombination med varandra kan ha större betydelse för hurpass anpassat en varelses beteende är än utsignalerna var för sig.

Parning för neurala nätverk är svårt att definiera på ett meningsfullt sätt. Syftet med parning är attkombinera egenskaper från föräldrarna. Eftersom samtliga noder i ett lager är kopplade till samtliganoder i angränsande lager, går det inte att separera ut egenskaper eller delar av nätverket som kanrepresentera en egenskap. Om en del av nätverket ändras, påverkar det ofta resten av nätverket på ettoförutsägbart sätt. Av denna anledning saknar den slutgiltiga implementationen möjligheten att paravarelser.

16

Kapitel 4

Grafik

4.1 Visualisering & renderingUtgångspunkten för visualiseringen grundade sig i modern grafikprogrammering via OpenGL ver-sion 3.3+ [3]. För att abstrahera och förenkla funktionaliteten i OpenGL krävdes användbara struktu-rer för hur datan skulle hanteras. Rendering med modern OpenGL kräver listor med vertexdata. Dessalagras i instanser av klassen Shape som kan beskriva formerna rätblock och plan. Shape-objektenägs av instanser av klassen Node som har tillgång till den fysikaliska beskrivningen av kroppen somanvänds i simuleringen. På så sätt kan rätt vertexdata byggas för alla former i fysikvärlden. Rent tek-niskt, så utförs detta genom att varje Node har en pekare till ett stelkroppsobjekt. Varje gång en Nodeuppdateras så hämtas transformationsdata från stelkroppen.

För att framställa grafiska effekter för visualisering av 3D-grafiken användes grundläggande sha-derprogram [3]. Creature Evolution innefattar två singeltonklasser: TextureManager ochShaderManager. Singelton är ett design-mönster som medför att det endast får och kan finnas eninstans av vardera klass, och dessa instanser ligger globalt i minnet så att övriga systemet kan kommaåt dem överallt [4]. Denna implementation förenklade hanteringen av shaderprogram och texturer.Användningen av dessa klasser förenklar även eventuell vidareutveckling eftersom de abstraherarfunktionaliteten i OpenGL samt lagrar information om shaderprogram och texturer på ett sätt somgör de åtkomliga över hela programmet.

TextureManager-klassen används för icke-procedurella texturer, det vill säga texturer som laddasin från bildfiler. Mycket simpla procedurella texturer, exempelvis ett chackbrädemönster, implemen-terades för att visa på möjligheten till vidareutveckling samt att undvika överflödig lagring av data.

17

4.2. GRAFISKT ANVÄNDARGRÄNSNITT KAPITEL 4. GRAFIK

4.2 Grafiskt användargränsnitt

Figur 4.1: En simulerad Ponny i scenen som försöker ta sig mot målet som representeras av densvävande grå kuben. I figuren representeras hela det grafiska gränssnittet på Mac OS X.

Creature Evolutions grafiska användargränsnitt figur 4.1 är placerat runt fönstret eller scenen därvarelserna ritas ut och visas som två parameterfönster; ett för fitness-parametrar och ett för simu-leringsegenskaper. Scenen navigeras genom att användaren vänsterklickar och drar musen i scenenoch musens scrollfunktion används för att flytta kameran längs z-axeln. Användaren kan ställa in pa-rametrar för fitness och simulering, visa resultatet med utritade varelser i scenen samt välja vilkengeneration som ska ritas ut. Parametrarna som är justerbara är: Keep distance to target, Jump high,Keep center of mass high, Keep head high, Creature type, Number of generations, Population size,Simulation time, Elitism ratio (%), Mutation ratio (%) och Mutation strength (%).

Alla värden är inställningsbara genom att antingen skriva ett nummer manuellt, genom rull-gardinsmeny eller med reglage. Ovanför varje reglage finns en titel som beskriver vilken parametersom ändras och ett nummer som visar hur mycket reglaget är inställt på för tillfället. Med reglagen ärdet lätt att se hur mycket parametrarnas värden förändras. Parametrarna går mellan två fördefinieradevärden, till exempel mellan −100 och 100 eller anges i procent.

Parameterfönstren för fitness-egenskaper och simuleringsegenskaper är dockningsbara vilket be-tyder att användaren kan frigöra dem från gränssnittet och flytta runt dem med musen och sedan dockatillbaka dem i fönstret. Denna funktionalitet implementerades för att ge användaren möjlighet att semer av scenen under renderingssteget.

4.2.1 Fitness-egenskaperFitness-parametrarna Keep distance to target, Jump high, Keep center of mass high och Keep headhigh är inställningsbara med reglage mellan −100 och 100. Dessa är vikter som används i relationtill varandra. Om till exempel Keep distance to target-parametern är satt till −30 medan Jump high-parametern är satt till 60, är det dubbelt så viktigt för varelsen att lära sig hoppa än att ta sig mot målet.Hur vikterna vägs samman tillsammans med varslens fitness-värden beskrivs under sektion 3.3.1.

18

4.2. GRAFISKT ANVÄNDARGRÄNSNITT KAPITEL 4. GRAFIK

4.2.2 SimuleringsegenskaperCreature type väljs av användaren med en rullgardinsmeny. Number of generations skrivs in manuellti en textruta och bestämmer hur många generationer som ska simuleras. Population size ställs inpå samma sätt som Number of generations och bestämmer hur många varelser som finns i varjepopulation. Simulation time ställs in på samma sätt som Number of genrations och bestämmer hurlång tid data samlas in för de satta parametrarna per varelse. Elitism ratio (%) är inställningsbar medreglage mellan 0 till 100%, verkar på populationen och bestämmer hur många procent av populationensom får gå vidare till nästa generation utan att mutera. Mutation ratio (%) är inställningsbar på sammasätt som Elitism ratio och avgör hur stor del av genkoden som muteras för varje varelse. Mutationstrength-parametern är inställningsbar med reglage mellan 0 och 100%, se sektion 3.4.2.

För att starta och stoppa evolutionssimuleringen används rektangulära knappar märkta Start simu-lation och Cancel. Knapparna är placerade i toppen av fönstret och bredvid finns en en rullgardinsme-ny View generation där användaren väljer vilken generation som skall visas. Det grafiska gränssnittetvisas i figur 4.1.

4.2.3 Implementering med QtFör utvecklingen i Qt användes inbyggda Qt-objekt som QWidget, QSlider, QComboBox ochQButton. Qt har sofistikerade metoder för att olika moduler i ett system skall kunna kommuniceramed varandra och de kallas Signals and Slots. Alla objekt som ärver av basklassen QObject fårstöd för att skicka ut och ta emot signaler till andra objekt av typen QObject. Detta gör det enkeltatt skicka information mellan objekt utan att behöva bygga omfattande gränsnitt mellan varje modul.Signals and Slots har också stöd för att hantera trådning som gör det möjligt att ha QObject på olikatrådar som fortfarande kan kommunicera.

19

Kapitel 5

Analys

Huruvida en specifik varelse lyckas utveckla möjligheten att utföra en specifik uppgift beror på mångaparametrar. Varelsens beskrivning, den uppgift som specificeras och inte minst slumpen spelar en storroll i förmågan att uppnå målet på så kort tid som möjligt. För att få en bättre klarhet i programmetsprestanda utfördes analyser av programmets olika delar.

5.1 EvolutionsprocessenFör att studera hur väl specifika varelsebeskrivningar klarar specifika uppgifter genomfördes en studiemed populationer av storleken 20. Varelserna var av de olika typerna ponny, mask, krypare, ochmänniska och simulerades i 20 generationer under 20 sekunder. Därefter kontrollerades deras fitness-värden i respektive gren: minimera ackumulerat avstånd till mål, hoppa högt samt håll huvud högt.Detta för att visa hur olika varelsebeskrivningar klarar uppgifterna olika bra.

För att studera hur evolutionen medför en ökad anpassning hos varelser valdes ett exempel därvarelsebeskrivningen ponny skulle lära sig att minimera det ackumulerade avståndet till målet. Däref-ter jämfördes de mest anpassade varelserna i de olika generationerna. Under denna evolutionsprocesssattes antalet generationer till 100, populationsstorleken till 30 och simuleringstiden till 30 sekunder.Evolutionsparametrarna var: elitism ratio 20%, mutation ratio 20% och mutation strength 20%.

En jämförelse mellan olika värden på evolutionsparametrarna utfördes för att visa hur de påverkarevolutionsprocessen. Analysen utfördes på samma sätt som föregående, med skillnaden att mutationratio och mutation strength först bestämdes till att vara 5% och sedan 95%.

5.2 TidskomplexitetEftersom en viktig del i systemet var att hålla den totala simuleringstiden så låg som möjligt, utfördesanalyser i algoritmernas tidskomplexitet. Tiden det tar att simulera en evolutionsprocess beror på fleraparametrar. De viktigaste av dessa är:

• Antal varelser i populationen, m.

• Antal generationer, n.

• Antal tidssteg i simuleringen, t.

• Varelsens komplexitet, k.

Varelsens komplexitet är svårare att bedöma men beror främst på antalet stelkroppar som denbyggs upp av. Alla dessa parametrar bidrar med linjära samband mellan parametern i fråga och evo-lutionstiden. Detta inses eftersom tiden för alla nedanstående operationer ökar linjärt med respektiveparameter:

20

5.2. TIDSKOMPLEXITET KAPITEL 5. ANALYS

• Beräkna ett tidssteg i simuleringen: T (k) = O(k).

• Beräkna en simulering av en varelse: T (t) = O(t).

• Simulera en generation: T (m) = O(m).

• Simulera alla generationer: T (n) = O(n).

Detta ger den totala tidskomplexiteten: T (k, t,m, n) = O(k · t ·m · n). För minimering av simu-leringstiden kan alltså dessa parametrar minskas individuellt, linjäritet går dock aldrig att undvika.

En inre struktur som också påverkar simuleringstiden är det neurala nätverket. Eftersom nätverkethar tre lager av noder och varje nod i föregående lager är kopplat till varje nod i nästkommandelager blir tidskomplexiteten för det neurala nätverket O(i · g · u) där i är antalet insignalnoder, g ärantalet gömda noder och u är antalet utsignalnoder. Eftersom förhållandet mellan medelvärdet ochantal noder i det gömda lagret är linjärt, blir den totala komplexiteten O(n3) om n är maxvärdet avantalet noder i insignalslagret och utsignallagret.

För att analysera tidskomplexiteten kördes ett antal evolutionsprocesser vars processortider an-tecknades. Evolutionen kördes för en mask med 1 led (dvs. två segment), 1 sekunds simuleringstid,1 varelse och 1 generation. För att undvika brus i simuleringen låstes vikterna i det neurala nätverkettill 1. Var och en av dessa parametrar ökades därefter stegvis 300 gånger med de andra parametrarnalåsta till 1 och processortiden för var och en av dessa evolutionsprocesser sparades.

21

Kapitel 6

Resultat

6.1 Resultat av evolutionsanalysResultatet för de olika varelsebeskrivningarnas förmågor att utföra specifika uppgifter redovisas itabell 6.1. Varelsen människa saknar värde i förmågan att hoppa högt eftersom den börjar stående ochfaller sedan oftast ihop. Därefter når den aldrig en höjd högre än den hade från början och ger därförinte en rättvis jämförelse i den grenen.

Tabell 6.1: Resultat av evolution.Ponny Mask Krypare Människa

Minimeraavstånd till mål.(ackumuleratavstånd [sm])

6640 10962 7915 9992

Hoppa högt(maxhöjd [m])

0,82 0,30 0,17 -

Håll huvud högt(ackumulerad höjd [sm])

24 14 8 12

Resultatet av evolutionsprocessen med olika mutationsparametrar visas i figur 6.1. Det är tydligtatt låga mutationsparametrar, i detta fall 5%, ger en långsam men stabil evolution. Höga mutations-parametrar, i detta fall 95%, ger en snabbare evolution. Någonstans mittemellan finns de värden somger den snabbaste evolutionen. I detta fall gav mutationsparametrarna 20% en snabbare evolution ände övriga fallen.

22

6.2. RESULTAT AV TIDSKOMPLEXITETSANALYS KAPITEL 6. RESULTAT

Figur 6.1: Evolutionsprocessen medför en anpassning i form av minskat ackumulerat avstånd tillmålet för den evolverade ponnyn. Då värdet når ett lokalt minimum avstannar processen och varelsenär fullärd.

6.2 Resultat av tidskomplexitetsanalysEnligt figur 6.2 verkar processortiden öka linjärt i förhållande till simuleringstiden, antalet varelseroch antalet generationer som väntat men ej för antalet leder.

Figur 6.2: Samband mellan parametervärden och processortid. Y-axeln visar processortiden. X-axelnanger parametervärden från 1 till 300 med övriga parametrar låsta till 1.

Den främsta källan till ledernas tidskomplexitet observeras i skillnaden mellan kurvorna för antaletleder med och utan ett neuralt nätverk kopplat till motorerna. Som tidigare nämnt har det neuralanätverket kubisk tidskomplexitet baserat på antalet insignaler vilket i sin tur beror på antalet leder.

23

Kapitel 7

Diskussion och framtida arbete

Trots projektets namn är det viktigt att förtydliga att det som sker i programmet inte är grundat i bi-ologisk evolution. Evolutionsprocessen är framtagen utifrån egen intuition om vilka delar i förloppetsom gynnar utvecklingen av varelserna på bästa sätt och är därför mer av en datorvetenskaplig op-timeringsprocess än evolution i biologiskt hänseende. Nedan tas diskussioner upp om de delar somförde utvecklingensprocessen framåt.

7.1 ArbetsmetodI början av projektet bestämdes bland annat riktlinjer angående arbetsmetodik, kundkontakt, verktygoch testning. De olika delarna diskuteras nedan.

7.1.1 ScrumDen främsta avvikningen från scrum var tidsestimeringen, där det ska uppskattas hur lång tid varjestory troligtvis kan ta att utföra. I början av projektet bestämdes riktlinjer för detta och det beslutadesatt planning poker [10], som är en metod för att estimera tid, skulle användas. Dock användes dettabara under första sprinten. Detta eftersom många arbetsuppgifter var individuella vilket ledde till attdet blev svårare för gruppens olika medlemmar att bedöma tiden för alla stories. Tidsestimeringenbedömdes slopa mer tid än den skulle medföra.

7.1.2 KundkontaktKommunikation med kunden var god men inte frekvent, då ett önskemål från kunden var att inte hamöten i onödan samt att det mesta kunde skötas över e-post. I överlag så var kraven från kundenväldigt generella och öppna och detta var ett medvetet val från kunden för att medföra fria tyglar.Kunden bör däremot ha blivit underrättad av gruppen mer frekvent än vad som skett och fler leverableri form av enklare demonstrationer av funktionlitet borde ha blivit levererade. Detta för att ge gruppenmer feedback om att utvecklingen gick åt rätt håll.

Vissa av kundens krav visades efter undersökning vara ogenomförbara på grund av tekniska be-gränsningar vilket kunden blev informerad om vartefter nya krav diskuterades fram. I slutändan varkunden nöjd med resultatet.

7.1.3 DokumentationVid projektets start användes Doxygen för dokumentation av kod. Då ett flertal större refaktoreringarutfördes under projektets gång, minskade antalet kommentarer och dokumentationen blev mindre

24

7.2. SYSTEMARKTIEKTUR KAPITEL 7. DISKUSSION OCH FRAMTIDA ARBETE

aktuell. För att göra koden mer läsbar togs dokumentationen upp igen i senare skede då fler delar avsystemets funktionalitet var fastställd.

7.1.4 TestningAtt utföra gynnsamma enhetstester var problematiskt eftersom systemets indata är slumpmässiga vär-den. De större testerna gör då mer skada än nytta då testerna blir tidsödande för projektet. Därförvaldes att inte lägga allt för stor fokus på testdriven utveckling.

Något som skulle kunna utförts under projektets gång är användartester, där en användare fårtesta programvaran och ge respons på vad som är bra och vad som kan förbättras. Detta skulle geutvecklingsteamet en annan bild av projektet samt flera olika aspekter på tekniska lösningar.

7.2 SystemarktiekturKort efter projektets start valdes Qt som preliminärt applikationsramverk för det grafiska användar-gränssnittet.

Ändringar av det grafiska användargränssnittet skedde kontinuerligt under projektets gång pågrund av tekniska komplikationer och därför ändrades kraven på vilka parametrar som skulle varajusterbara och tillgängliga i det grafiska användargränssnittet.

Tanken var att medlemmarna i gruppen skulle bekanta sig med ramverket och göra några enkla-re handledningsexempel medan de som då arbetade med systemarkitekturen sammankopplade Qt,Bullet och de andra modulerna i projektet. Det visade sig inte vara helt trivialt att varken utformaett system som skulle klara av att göra ett flertal saker synkront och med tillfredsställande prestanda.Det fanns mycket problem i att kombinera tre ramverk (OpenGL, Bullet, Qt) och samtidigt skrivaett flexibelt system utifrån kraven som projektet hade. Då ramverket Qt just nu utvecklas mycket såär det krävande att hitta information om vältestade metoder som samtidigt inte är alldeles förlegna.När arbetet fortskred så blev ovissheten kring hur det grafiska gränssnittet skulle hanteras ett stortproblem för projektet. Mycket arbete kring visualiseringen avstannade då det inte var helt tydligt hurdetta skulle lösas med det grafiska gränssnittet.

Det beslutades att kolla på alternativ till Qt och valet föll på SFML i kombination med SFGUI.SFGUI är ett bibliotek för användargränssnitt som är helt skrivet i OpenGL. Förhoppningen var attdet skulle vara lättare att integrera med befintlig kod för visualiseringen. Det visade sig dock att SFMLoch SFGUI inte hade stöd för modern OpenGL(3.3+) och skapade därför en helt annan uppsättningav problem.

Vid denna tidpunkt var det grafiska gränsnittet det enskilt största problemet för gruppen. Ett speci-ellt möte kring hur gruppen skulle handskas med detta hölls och ett gemensamt beslut om att helt en-kelt inte bry sig om ett grafiskt gränsnitt togs. Detta gjorde att gruppen kunde gå tillbaka till att endastanvända de lättare biblioteken GLFW och GLEW för fönsterhantering och OpenGL-funktionalitetför att fortsätta utveckla de viktigare aspekterna av projektet som evolutionsprocessen och visualise-ringen.

De tidigare problemen som gruppen haft med Qt relaterade till kombinationen av Qt och OpenGL.Det visade sig finnas många olika sätt att lösa detta problem, men alla hade sina nackdelar. I slutän-dan valde gruppen att använda Qt med QtWidgets istället för det nyare QtQuick. QtQuick använderförvisso OpenGL för all typ av uppritning, men det tillåter endast användning av OpenGL-kontextsom stödjer GLSL ES, som inte är den fullständiga specifikationen för GLSL. Dessutom är det nästintill omöjligt att använda sig av denna OpenGL-funktionalitet utan att tvingas använda QtQuick-wrappers, vilket inte var önskvärt. QtWidgets är ett väldigt moget ramverk till skillnad från QtQuicksom förvisso är modernt men sämre dokumenterat. QtWidgets tillät gruppen att separera all OpenGLfunktionalitet ifrån Qt. Detta gav ett väldigt mycket mer modulärt system och kombinationen av Qt,OpenGL och Bullet fungerade som väntat.

25

7.3. VARELSEBESKRIVNING KAPITEL 7. DISKUSSION OCH FRAMTIDA ARBETE

När applikationsramverket för det grafiska användargränssnittet var fastställt hade mer än häftenav projektets tid gått vilket var en bidragande faktor till att utvecklingen av det grafiska gränssnittetinte fått den utvecklingstid som behövts. När arbetet med det grafiska gränssnittet väl kom igång gickdock arbetet relativt snabbt då Qt var bekant sedan tidigare.

7.2.1 TrådningFör att utföra flera uppgifter samtidigt så användes trådning. Det visade sig vara enkelt att användabefintlig funktionalitet i Qt för att sköta trådningen. Att skapa trådar var inget problem, dock vardet inte helt trivialt att stänga av en tråd innan den blev klar. Detta löstes genom att skicka speciellasignaler till objekten som utförde processer på olika trådar.

Felaktig implementation av trådning kan leda till problem som är svåra att lösa, tex minne somblir korumpterat på ett väldigt slumpmässigt sätt. Ett alternativ till att utföra parallella uppgifter påolika trådar är att skriva programmet som en state machine. Detta hann aldrig utforskas ordentligt dådet hade medfört stora omskrivningar av koden vid ett sent skede i projektet.

7.3 VarelsebeskrivningUnder utveklingen av Creature Evolution undersöktes många olika metoder och strukturer för devirtuella varelserna. Nedan redogörs några av de beslut som lett fram till vad som finns i den slutgiltigaprodukten.

7.3.1 Komplicerad utvecklingI projektets början diskuterades om varelser skulle ändra utseende och beteende beroende på omgiv-ning. Detta var även i början av projektarbetet ett krav från kunden. Exempelvis att om en varelse ficksom krav att nå högt skulle den utvecklas att bli längre genom att få en längre hals eller längre ben.Hade varelser haft möjligheten att utveckla sitt utseende fritt, hade resultatet förmodligen liknat KarlSims [1] varelser och resulterat i osymmetriska sammansättningar av rätblock eller liknande vilketville undvikas. Det fanns även idéer om att varelser skulle evolveras beroende på omgivning i form avtill exempel kullar, hinder eller vatten. Denna idé följdes inte på grund av tidsbrist och att stora delarav de befintliga evolutionsalgoritmerna skulle behöva skrivas om då detta vore ett mycket teknisktsvårt problem.

7.3.2 Val av hjärna - beteendeFör en enkel uppgift som att röra sig framåt och en enkel fysisk beskrivning som en mask, där ettperiodiskt beteende är önskvärt, fungerar den sinosoida hjärnmodellen bra. Dock visar modellen sinabegränsningar när det gäller mer komplicerade uppgifter som att gå mot ett definierat mål, då varelseni detta fall inte vet var målet är eller när varelsens kropp är för komplicerad för denna typ av peri-odiska beteende. För att möjliggöra att fler olika typer av varelser kan utveckla förmågor att utförafler uppgifter studerades andra hjärnmodeller. Innan den slutgiltiga hjärnmodellen implementerades,studerades modellen funktionsträd.

Funktionsträd

Funktionsträd är en av de mest dynamiska modellerna för en hjärna och användes bland annat i Evol-ved Virtual Creatures [1]. Trädstrukturen består av funktionsnoder som dels har en funktion elleroperation definierad (till exempel addition, division, multiplikation, sin(x), tanh(x), kx, xk, > el-ler <) och dels en referens till andra noder, varifrån de får argumenten till sina funktioner. Förutom

26

7.3. VARELSEBESKRIVNING KAPITEL 7. DISKUSSION OCH FRAMTIDA ARBETE

funktionsnoder finns även utsignalnoder och insignalnoder. Utsignalnoderna innehåller inte någonmatematisk funktion, utan har enbart en referens till en nod från vilken den hämtar sitt värde somutgör trädet. Insignalnoderna innehåller värdena hämtade från hjärnans insignaler och utgör lövenav trädet. Insignalerna kan för denna struktur väljas fritt. Utsignalerna från funktionsträdet bör ävenbegränsas. Detta kan ske till exempel genom att helt enkelt trunkera utsignalerna till värden mellan -1och 1 eller genom en överföringsfunktion såsom hyperbolisk tangens.

Figur 7.1: Illustration av ett funktionsträd med tre rötter (utsignaler) och tre löv (insignaler) ochåterkommande noder.

Något som är viktigt att tänka på för denna typ av struktur är hur cirkulära referenser hanteras.Till exempel att en nod A pekar på en nod B som pekar på en nod C som pekar på A, som kan ses ifigur 7.1. Detta skapar i normalfallet en oändlig slinga men kan lösas genom att organisera trädet i la-ger med utsignalnoderna längst ner och insignalnoderna högst upp och där varje nod enbart får hämtaargument från noder i ett ovanstående lager. Detta är en säker struktur men sätter vissa begränsningarpå dynamiken. En annan metod är att ha en räknare för varje utsignal som inkrementeras för varjefunktionsnod som anropas. När räknaren blir större än ett maxvärde får den ett argument tilldelat tillsig, antingen från en konstant eller en insignalsnod.

Funktionsträdens styrka är att de kan representera i princip vilka samband mellan insignaler ochutsignaler som helst, men detta är även dess svaghet. De flesta möjliga samband som finns mellaninsignaler och utsignaler är inte meningsfulla. Med ett dynamiskt funktionsträd kommer alltså deflesta varelser som genereras att vara värdelösa.

Ett komplext eller stort funktionsträd kommer även att ta lång tid att beräkna, vilket i sin turkommer göra simuleringen långsammare. Ett alternativ för att snabba på simuleringen är att begränsaantalet generationer som får passera innan evolutionen gett resultat. Men för att optimera evolutionenbör begränsningar på funktionsträdets ursprungliga struktur samt mutation och parning göras för attdetta ska ske på ett meningsfullt sätt. Detta är i sin tur ett svårt problem, dels då detta kan göras på såmånga olika sätt och dels då det är ett relativt outforskat område.

Mutation av ett funktionsträd kan ske på många olika sätt:

• Nya funktioner kan slumpas fram för funktionsnoder.

• I de fall funktioner använder konstanter kan dessa ändras.

27

7.4. SIMULERING KAPITEL 7. DISKUSSION OCH FRAMTIDA ARBETE

• Kopplingar mellan noder kan ändras.

• Nya noder kan skapas och gamla noder kan tas bort.

7.3.3 Utveckling av kroppI den nuvarande implementationen av programmet kan inte varelsens kropp (fysiska beskrivning)utvecklas utan endast dess hjärna (beteende) påverkas av evolutionen. Dock finns inte några begräns-ningar för att slumpa värden och kroppsdelar till trädstrukturen som beskriver varelsens kropp. Pro-blemet är dock detsamma som med funktionsträd. Om varelsen enbart sätts ihop på ett slumpmässigtsätt kommer de flesta varelser sakna koppling till deras föregående generation. Detta skulle riskeraen förlängd evolutionstid. Det kan vara önskvärt att sätta begränsningar på vilken typ av varelse somkan genereras och hur de kan utvecklas, inte endast för att öka chansen att få rimliga varelser utanockså av estetiska skäl. Till exempel kan det vara önskvärt att införa begränsningar för symmetri ellerstorlek på leder som kan kopplas till varandra.

Ett problem i den nuvarande strukturen är att det inte finns någon direkt koppling mellan vilkadelar av hjärnan som påverkar specifika leder. Hjärnan tar en lista med insignaler och ger en lista medutsignaler, utan att ta hänsyn till vad som finns i listorna. Om data från lederna används som insignaloch ledernas rörelse bestäms av utsignalerna så kan det uppstå problem om varelsen kan utvecklas påså sätt att leder läggs till eller tas bort. Om en led tidigt i listan skulle tas bort så skulle detta i dennuvarande implementationen orsaka en förskjutning av vilka leder varje efterkommande utsignal ochinsignal är kopplad till. Detta skulle troligtvis leda till en total förändring i varelsens beteende vilketinte är önskvärt. För att lösa detta skulle det vara nödvändigt för insignals- och utsignalnoderna samtlederna att känna till varandra och vilka noder som är kopplade till vilka leder.

7.4 SimuleringSimuleringen sker längst ner i hierarkin av evolutionsprocessen och är alltså den främsta flaskhalsenför systemet. Optimering av simuleringen har alltså stor betydelse för att göra evolutionen snabbare.Bland annat är det möjligt att undersöka sätt att få ett stabilt system med ännu större tidssteg och andrakollisionsformer. Till exempel så kan sfärer vara billigare att simulera än rätblock. En GPU-optimeradversion av bullet är även under utveckling vilket skulle kunna förminska simuleringstiden markant.

Fler insignaler än de som implementerades kan användas för att ge det neurala nätverket ochdärmed varelsen ett mer intressant beteende. Insignaler som kan vara intressanta är hastighet ochacceleration för leder och kroppsdelar samt kontaktsensorer för kroppsdelar. Något som också skullevara av intresse vore att undersöka möjligheter för varelsen att minnas och reagera på sin historik, tillexempel skulle fler utsignaler kunna läggas till. Dessa skulle inte används till något annat än att enbartskickas tillbaka till hjärnan och på så sätt ge varelsen en form av begränsat minne.

7.5 Meta-evolutionI systemets nuvarande form bestäms parametrarna för evolutionen av användaren. Det kan dock varaväldigt svårt att avgöra vilka parmetrar som ger bäst resultat. Detta problem skulle eventuellt kunnalösas genom meta-evolution, en evolution av evolutionsprocessen. Genom att låta evolutionsparamet-rarna utgöra en genkod, och hur snabbt evolutionen tar fram välanpassade varelser utgöra fitness-värdet, är det möjligt att utveckla evolutionen på motsvarande sätt som för varelserna.

Det är dock inte säkert att samma parametrar är optimala genom hela utvecklingsprocessen. Tillexempel kan det till en början krävas en väldigt kort simuleringstid för att särskilja de varelser somfungerar mot de som inte fungerar alls men en längre simuleringstid för att senare i evolutionen

28

7.6. TIDIGA VISIONER KAPITEL 7. DISKUSSION OCH FRAMTIDA ARBETE

särskilja de bästa varelserna från varandra. Det skulle därför även vara av intresse av att utvecklaen smart evolution genom att använda ett neuralt nätverk, funktionsträd eller liknande struktur föratt för varje generation bestämma parametrarna till evolutionen. Exakt vilka insignaler som skulleanvändas till denna struktur skulle behöva undersökas men det skulle till exempel vara av intresseatt undersöka skillnader i fitnessvärde inom en generation och mellan generationer av varelser för attträna evolutionsprocessen att ta sig ur lokala maxima.

7.6 Tidiga visionerTidigt i projektet diskuterades det inom gruppen och med kunden om projektet skulle finnas medunder utställningen på Visualiseringscenter C. Till förmån för detta planerades det grafiska användar-gränssnittet kring att vara användbart även för barn och ungdomar. Det förekom även diskussionerom det skulle finnas en del av gränssnittet med enklare inställningar för yngre och en annan del medmer avancerade inställningar för till exempel studenter på Tekniska högskolan. Idén fullföljdes inte islutändan men dörrarna har lämnats öppna så det finns möjlighet att fullfölja i framtiden.

29

Kapitel 8

Slutsatser

Att ha en programutvecklingsmetod att utgå ifrån är till stor hjälp i ett större projekt. Systemutvecklingär ett stort område som är svårt att behärska och kunna på en gång. Många olika metoder inom agilutveckling finns dokumenterat och att lära sig behärska denna utvecklingsmetodik kan ta tid.

Inget projekt är det andra likt och därför går det aldrig att följa en metod eller utvecklingsprocesstill punkt och pricka. Teorin följs upp med anpassningar till det specifika projekt som drivs.

Virtuell evolution handlar i grunden om att iterativt skapa slumpmässiga system, mäta hur brade fungerar, skapa nya system baserade på de bästa systemen, mäta och skapa nya system baseradepå dessa genom att applicera små slumpmässiga förändringar (mutationer) iterativt. Att hitta någonmetod för att göra detta är inte särskilt svårt. Problemet uppstår när det gäller att få systemet använd-bart. Strukturen för systemet måste tillåta stor variation men samtidigt inte så stor att det blir omöjligtatt hitta meningsfulla lösningar. Om systemet ska vara verklighetstroget är det viktigt att ha en brasimulering. Fitness-parametrarna måste definieras på ett meningsfullt sätt vilket kan bli kompliceratberoende på problemet som ska lösas. Hur systemet förändras mellan varje iteration måste definierasså att små stegvisa förändringar i rätt riktning uppnås istället för helt slumpmässiga varelser; samtidigtsom lokala maxima måste undvikas. Allt detta måste även göras effektivt så att evolutionsprocesseninte tar för lång tid.

Det är möjligt att skapa ett system för interaktiv virtuell evolution och detta har visats i dennarapport. Syftet att användaren ska förstå och reflektera över hur evolution av virituella varelser kanefterlikna hur varelser beter och lär sig i verkligheten visas då systemets varelser kan utveckla engångstil som liknar hur riktiga djur rör sig. Då det är möjligt att visa olika generationer, kan använda-ren få en bild av hur varelserna lär sig. Den grå kuben skulle kunna efterlikna ett jaktbyte och varelsenutvecklas att kunna ta sig till målet så snabbt som möjligt och måste därför evolvera en snabb och ef-fektiv gång eller springstil. Evolutionsprocessen sätter vissa begränsningar, både i hur snabb och hurintressant simuleringen blir. Det neurala nätverket bidrar både med intressanta lösningar och meden långsammare evolutionsprocess, på grund av hög tidskomplexitet samt att fler möjliga lösningarresulterar i en långsammare genetisk algoritm.

Fysiksimuleringen sätter, även den, stora begränsningar; både på tiden det tar att simulera intres-santa varelser, men även vilka olika typer av lösningar som framförs. Fysiksimuleringen, tillsammansmed varelsens beteende, resulterar i lösningar som inte alltid är förväntade. Exempel på detta var devarelser som lyckades ta sig framåt snabbare än att gå, genom att istället vibrera fram. Detta är dockinte en realistisk lösning, varför den undveks. Realistiska lösningar kunde tas fram. Dock inte alltidinom en rimlig tid, beroende på de fitness-parametrar som användaren bestämt.

30

Litteraturförteckning

[1] Sims KA, Evolving Virtual Creatures, Annual Conference Series,(SIGGRAPH ’94 Proceedings), July 1994, pp. 15-22.

[2] Schwaber KE, Sutherland JE, The Scrum Guide - The Definitive Guide to Scrum: The Ru-les of the Game, October 2011, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf 3 juni 2014

[3] Gortler ST, Foundations of 3D Computer Graphics, The MIT Press 2012

[4] Gamma ER, Richard Helm, Ralph Johnson och John Vlissides, Design Patterns: Elements ofReusable Object-Oriented Software, Addison-Wesley Professional 1994

[5] HelloWorld med genetiska algoritmer, https://github.com/fredlb/GAHelloWorld/ 3 juni 2014

[6] ai-junkie: Neural Networks in Plain English, http://www.ai-junkie.com/ann/evolved/nnt1.html 3 juni 2014

[7] Neural Networks, http://www.obgyn.cam.ac.uk/cam-only/statsbook/stneunet.html 3 juni 2014

[8] Mitchell ME, An Introduction to Genetic Algorithms, MIT Press, 1999

[9] Mersenne Twister PRNG, http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ewhat-is-mt.html 3 juni 2014

[10] Grenning JA, Planning Poker, 2002, http://renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf 3 juni 2014

31

Bilaga A

Statistik ifrån GitHub

Statistiken i tabell A.1 visar endast antalet commits och är inte ett direkt mått på individuella med-lemmars bidrag till projektet. Värt att nämna är att parprogrammering tillämpades vid vissa tillfällenvilket gav upphov till ojämn fördelning av statistiken. Uppsättning av projektfiler och bibliotek harutgjort vissa commits.

Tabell A.1: Antal commits på ’develop’ vid 3 juni 2014Fredrik Lindner 149Kalle Bladin 143Linnéa Mellblom 41Aron Tornberg 37Gabriel Baravdish 11Kristofer Janukiewicz 7

32

Bilaga B

Ordlista

Agil utveckling En uppsättning arbetsmetoder för programutveckling som sker iterativt.

Algoritm En metod som beräknar önskad utdata utefter vald indata.

Bullet Ett bibliotek för att utföra fysiska simuleringar i realtid.

Creature/Varelse En fördefinerad varelse bestående av en uppsättning 3D-objekt, rörliga leder ochen hjärna.

Evolution En process varigenom organismer förändras mellan successiva generationer.

Fitness Mått på hur väl en varelse klarar önskade mål.

Genkod De instruktioner som definierar varelsens beteende och/eller utseende.

Git Ett versionshanteringssystem.

Mutation En slumpmässig förändring i en varelses genkod.

Neuralt nätverk En uppsättning synliga och dolda noder i olika lager som får indata, applicerarfunktioner och returnerar utdata.

Nod Knutpunkt.

Parning En algoritm som väljer ut och kombinerar genkoder från två varelser.

Qt Ett krossplattformsramverk för grafiska gränssnitt.

Scrum En agil utvecklingsmetod.

Sigmoid funktion En funktion som ger en “S-formad” funktionskurva.

Sinusoid En kontinuerlig, sinusformad vågrörelse.

Sprint Ett tidsblock inom Scrum.

Trello En webbaserad applikation för att hantera projekt.

Virtuell Evolution Användning av algoritmer för att varelser ska, beroende av valda parametrar,optimera sitt beteende och på så sätt simulera evolution.

33

Bilaga C

Kroppsuppbyggnaden förvarelsebeskrivningar

Figur C.1: kroppsuppbyggnaden för de olika varelser; mask, ponny, krypare, människa, bord ochgroda, som används i programmet.

34

Bilaga D

Personer involverade i projektet

Utveckligsteamet bestod av: Gabriel Baravdish, Kalle Bladin, Kristofer Janukiewicz, Viktor Kraft,Fredrik Lindner, Linnéa Mellblom och Aron Tornberg.

Kunden i detta projekt var Alexander Bock.Nedan följer en beskrivning av vad de enskilda personerna har bidragit med i projektet:

Gabriel Baravdish Scrum-master och GUI.

Kalle Bladin Evolutionsprocessen, varelsebeskrivning, shaders, texturhantering samt allmänn OpenGL-grafik.

Kristofer Janukiewicz GUI, mötessammordnare samt Scrum-master efter halvtid.

Viktor Kraft GUI.

Fredrik Lindner Produktägare, kravhantering, kundkontakt och systemarkitektur. Initial prototypför genetiska algoritmer. Byggsystem (cmake) för win,osx,linux.

Linnéa Mellblom Kravhantering, varelsebeskrivning, evolutionsalgoritmer och genetiska algoritmer.Grundläggande struktur i början för hur evolutionen skulle hanteras.

Aron Tornberg Varelsebeskrivning, neurala nätverk, simulering och evolution. Bullet och även hurvarelser skulle ritas upp genom biblioteket.

35