TDDD92 AI-projekt

Individuell utredning (2 hp)

Under första kursperioden genomförs inte bara labbar utan även en självständig och individuell teknisk utredning för att utvärdera en eller flera existerande AI-tekniker inom vissa givna ramar.

Grundtanken bakom detta arbete är att den som vill lösa ett komplicerat problem behöver göra detta på ett iterativt sätt där man gradvis kommer fram till en slutlig lösning. Till exempel kan man följa den här mallen:

1. Ta reda på exakt vilket problem det är som du vill lösa. Att hitta en bra teknik är lättare om man inte bara har en vag tanke om vad som ska göras ("spela StarCraft"), utan hittar ett väl avgränsat delproblem ("bestämma vilken enhet som ska konstrueras härnäst") och vet vilka kriterier som är viktiga för att avgöra hur bra eller dålig en lösning är.

2. Man kan så klart hitta på något helt eget, men det är onödigt att återuppfinna hjulet. Leta därför efter existerande tekniker och infallsvinklar som verkar som att de skulle kunna vara användbara. Här kan du ofta filtrera bort många alternativ väldigt snabbt genom att läsa om dem i några minuter ("nej, flow fields verkar inte kunna bidra till att bestämma vilken enhet jag ska bygga härnäst, det löser ju helt andra problem").

3. Det kan fortfarande finnas en hel del olika tekniker som passerar "tiominutersfiltret" i den förra punkten. Dessa kan behöva undersökas närmare, i en djupare utredning. Men då blir inte nästa steg att börja implementera dem och testa själv, för det kan ta väldigt mycket tid. Istället börjar vi med att läsa mer och se om andra redan har gjort en del av arbetet åt oss! Med andra ord, hitta artiklar som ger mer detaljer om hur teknikerna fungerar och/eller hur andra redan har använt dem, och se vad du kan dra för slutsatser från detta. Om 3 tekniker passerade tiominutersfiltret kan denna utredning hjälpa dig att ta reda på vilken av dessa du troligen borde implementera först, även om du inte är helt säker på exakt hur bra det kommer att fungera.

Allt detta ska göras i utvärderingsarbetet. Det följs sedan av projektarbetet, där du implementerar en lösning – kanske en som du utvärderade, eller kanske en annan om ingen utvärderad teknik verkade bra. Den individuella utvärderingen ger dig alltså en vägledning innan du börjar med implementationen, så att du vet vad som är intressant att gå vidare med. I projektarbetet kommer du också att kunna göra en betydligt mer säker utvärdering av hur bra den implementerade tekniken faktiskt fungerade.

(I verkligheten kan det så klart visa sig att det du implementerade inte fungerade så bra, trots att det passerade de tidigare filtren. Det är OK, så länge du faktiskt har implementerat tekniken korrekt och gjort en bra utvärdering!)

Med andra ord, och mer kortfattat:

• Definiera ett problem eller en klass av problem som kan vara relevant att lösa för ditt projektarbete inom StarCraft,

• Välj en uppsättning rimliga kriterier som kan användas för att avgöra hur väl en specifik teknik faktiskt uppfyller behoven hos projektet,

• Välj ut en eller helst flera AI-tekniker som kan tänkas användas för att lösa detta problem,

• Utvärdera de valda teknikerna enligt de valda kriterierna, med vetenskapliga artiklar som den huvudsakliga källan till information om teknikerna, och

• Beskriv dina slutsatser, som kan vara mer eller mindre starka beroende på hur mycket information som faktiskt kunde hittas.

Nu kommer vi att diskutera detta på en mer konkret och detaljerad nivå.

Steg 1: Välj ett lämpligt problem att undersöka.

Du väljer själv vilka problem(klasser) och vilka tekniker du vill studera, men tänk på att det är till stor fördel om du sedan kan utgå från din utredning när du deltar i det gemensamma projektet. Under projektet kommer varje gruppmedlem att behöva ett eget ansvarsområde, med ett tydligt huvudansvar för någon AI-teknik eller något problemområde. Trots att utredningen i sig är en individuell uppgift kommer varje projektgrupp därför att behöva samordna medlemmarnas val av problem(klass), så att det inte blir onödiga överlapp mellan de problem och tekniker som gruppmedlemmarna utreder (mer om detta längre ner).

Förberedelse: Att läsa

Som förberedelse inför föreläsningen 190910 läser du An Introduction to Game-Playing Systems and StarCraft II.

Föreläsning 2 (190910): Inspiration till problem- och teknikområden

Under föreläsning 2 diskuteras ett antal intressanta problem- och teknikområden. Detta ska ge ett första underlag för att du ska kunna se vilka områden som verkar mer eller mindre intressanta för din egen del och för projektet. Sedan behöver du givetvis själv följa upp och undersöka potentiellt intressanta områden närmare så att du kan göra ditt val, till exempel genom att ta en första titt på artiklar och annat material. Du får självklart också väldigt gärna ha egna idéer, som du kan diskutera med en handledare! För en översikt över existerande tekniker, se även kursboken i AI-kursen (TDDC17)!

Bilda projektgrupper / anpassa ansvarsområden

I samband med föreläsningen är det dags att bilda projektgrupper om cirka 5-6 personer (kursledningen meddelar antalet beroende på exakt antal kursdeltagare detta år), för att kunna samordna utredningsområden inom gruppen och undvika överlapp. Börja senast i samband med föreläsning 2!

Som nämndes ovan behöver varje gruppmedlem ett eget ansvarsområde under själva projektet. Även om det går att ha ett projektansvar som skiljer sig från det man gjorde i utredningen, leder det till mycket extraarbete. Vi rekommenderar därför starkt att man redan inför det individuella arbetet samordnar utredningarna inom gruppen. Det betyder att man kan behöva anpassa och förhandla kring sitt val av ansvarsområde och utredningsområde för att det ska passa in i gruppen, eller anpassa grupperna så att de som väldigt gärna vill arbeta med samma område hamnar i olika grupper.

Vad menas med "eget" ansvarsområde? Här är några punkter som kan ge en viss vägledning. Diskutera gärna med handledarna!

• Två personer i samma grupp kan inte tilldelas ansvarsområdet hitta en bra byggnadsordning givet vad vi redan har och vad vi vet om fienden. Detta är en problemställning.

• Däremot skulle en person kunna ha hand om att uppskatta vilken strategi fienden troligen använder just nu medan en annan person kan ta hand om att hitta en bra byggnadsordning givet vilken strategi vi tror fienden använder just nu. Detta är två tydligt separerade problemställningar, även om lösningen på den ena ger information som behövs för att kunna applicera den andra.

• Två personer i samma grupp kan möjligen ha ansvar för olika ansvarsområden där lösningarna överlappar till viss del. De kan t.ex. arbeta med två helt olika problemställningar där det visar sig att båda de valda lösningarna applicerar flow fields, fast på olika sätt. Man kan då samarbeta om implementationen av grundläggande flow fields, men behöver fortfarande ha en signifikant "egen" funktionalitet att implementera och utvärdera ovanpå detta. Den delen av implementationen ska då vara separerad så att det gemensamma, t.ex. "flow fields", är en tydligt avgränsad del av koden.

  Detta gäller alltså projektdelen. Den individuella utredningen är alltid individuell: Skriv inte gemensamma avsnitt om t.ex. flow fields, utan gör din egen utredning.

Föreläsning 3 (190913): Mer om den individuella uppgiften

Under föreläsning 3 kommer vi att fortsätta diskutera utredningsuppgiften, bl.a. vad det betyder att utvärdera och utreda ett teknikval, och vilka kriterier som kan vara rimliga.

Vi kommer också att ge möjlighet till en studentdriven diskussion av problemklasser och teknikområden med inriktning på det individuella arbetet. Här har du chansen att diskutera frågor som har uppkommit medan du planerar din utredning, och få ett bättre underlag för det fortsatta arbetet.

Sidosteg: Hur skriver man en rapport?

Denna kurs innehåller också ett integrerat moment i rapportskrivning, vilket kommer att granskas separat av personal på IKK. Därför har vi också en fjärde föreläsning som just handlar om hur man skriver rapporter (190918).

Vänta inte på den föreläsningen innan ni börjar skriva utredningsplanen – den handlar enbart om saker att tänka på i den slutliga rapporten!

Steg 2: Bestäm exakt vad du tänker undersöka, och hur.

Det räcker inte med att veta vilket problemområde man vill undersöka. Du behöver också fundera på t.ex. vilka kriterier du vill använda för att utvärdera lösningarna, vilka potentiella lösningar du vill utvärdera, och var du ska få den information du behöver. För att vi ska kunna ge återkoppling på detta skrivs först en utredningsplan.

1. Anledningen till att det är viktigt att lösa det givna problemet inom gruppens projekt (syfte).
2. Vilka specifika tekniker, algoritmer eller liknande som du tänker utvärdera (inklusive referenser till de vetenskapliga artiklar du tänker utgå ifrån).

Före seminariet 190923-24: Planera den egna utredningen

Du funderar, läser på, och skriver en plan för den tänkta utredningen. Dokumentet ska beskriva mål, syfte, tekniker att utvärdera, och utvärderingskriterier enligt ovan. Planen är helt enkelt till för att du inte ska komma på fel väg från början: Du behöver dels verifiera att det faktiskt finns material att utgå från, dels konkretisera dina egna tankar så långt att det går att förstå hur detta kan passa in i ett gemensamt projekt – eller upptäcka eventuella problem så tidigt som möjligt.

Under planeringen diskuterar du mål och syfte med övriga gruppmedlemmar för att förankra detta i gruppen och underlätta det senare projektarbetet. Läs också genom hela denna sida redan under planeringen. Informationen om steg 3 innehåller en hel del matnyttig information som du behöver tänka på redan nu!

En riktlinje är att dokumentet blir ungefär en A4-sida. Detta är en fingervisning om hur mycket information som brukar behövas för att du själv ska få bästa möjliga återkoppling från gruppen och handledarna.

Döp dokumentet till Utredningsplan TDDD92 - liuid123, där du så klart stoppar in ditt eget LiU-id.

• Namn, LiU-id, gruppnummer.

• Problemställning. Allra först beskrivs ett tydligt och välmotiverat problem man vill lösa. Då vet man inte nödvändigtvis något om lösningstekniker, så sådant beskrivs inte i det avsnittet. Istället kommer en ren problemuppställning: Jag vill se till att vår StarCraft-agent kan göra/åstadkomma/bestämma/... "X"!

  Man behöver också tala om tydligt varför man vill kunna göra/åstadkomma/... "X". Man behöver då ett övergripande mål, t.ex. att maximera möjligheterna att vinna i spel mot andra AI-agenter, och behöver också ange hur man tänker sig att "X" ska kunna bidra till detta. Varför är det överhuvudtaget relevant för StarCraft-agenten att klara "X"?

  Här får man mycket gärna diskutera en eller flera specifika situationer i en spelomgång, och det är starkt rekommenderat att inkludera en eller flera skärmbilder: "Nu är spelet i detta läge, här försöker vi göra X och motståndaren vill göra Y, i det läget är det viktigt att vi klarar av Z...". Att börja med detta kan också göra uppgiften och dess avgränsningar och krav mycket mer konkreta för dig själv och det kan du ha mycket nytta av i resten av utredningen!

• Utvärderingskriterier: Hur ska du utvärdera en potentiell lösning? När är något bra, när är det dåligt? Detta diskuteras mer under en föreläsning. Du behöver en uppsättning av flera tydligt numrerade kriterier som du tänker använda.

• Tekniker och algoritmer: Vilka specifika tekniker, algoritmer, ... vill du undersöka och utvärdera? Här kan det i vissa fall fungera att göra en djupdykning i en teknik, men det finns fördelar med att jämföra flera. Som vi kommer att diskutera på en föreläsning påverkar det också hur bra det går att utvärdera kriterierna. Se även "..." nedan.

• Referenser: Du måste inkludera referenser till ett antal, typiskt 3-5, vetenskapliga artiklar som du utgår från. Någon bok kan också användas, men majoriteten av referenserna ska vara artiklar. Se även Rapporten: Referenser nedan.

• Övrigt: Eventuellt annat som du tror kan vara intressant för att andra ska förstå vad du tänker utreda.

Att använda artiklar som baseras på StarCraft II

I litteraturen finns redan en hel del artiklar som applicerar olika AI-tekniker på just StarCraft II, och som utvärderar resultatet av detta.

Om en individuell utredning enbart baserar sig på en teknik av denna typ, försvinner mycket av det tänkta utredningsarbetet. Rapporten säger då i princip att:

Jag vill tackla problemet X inom StarCraft II och vill reda ut om teknik Y skulle vara användbar enligt kriterierna Z1, Z2 och Z3. John Doe [7] har applicerat teknik Y på problemet X inom StarCraft II och kommit fram till att kriterierna Z1 och Z2 uppfylls bra medan Z3 uppfylls mindre bra. Slut på utredningen.

Ovanstående är så klart något överdrivet, men det är ändå lätt att hamna i denna fälla och att därmed inte komma fram till något rimligt djup i den egna utredningen. Om du baserar din utredning på existerande vetenskapliga artiklar i StarCraft-miljö behöver du därför:

1. Utvärdera flera olika tekniker och göra en egen slutlig jämförelse mellan dem (t.ex. använda flera tekniker som redan applicerats på StarCraft, eller en som redan applicerats och en som inte har gjort det), eller

2. Utvärdera en teknik som redan har applicerats på StarCraft, men komma fram till egna djupare slutsatser som inte framgår i ursprungsartikeln/artiklarna (vilket kan vara svårt att nå upp till). Diskutera i så fall detta med en handledare i förväg, med grund i dina tänkta val av specifika artiklar.

190923-24: Seminarium, presentation av egna utredningsplaner

När utredningsplanerna är klara vill vi få en chans att ge feedback på hur väl dessa passar ihop inom gruppen, så att vi inte ser några uppenbara problem med att använda de individuella utredningarna som bas för ett gemensamt projekt. Vi vill även ge er en chans att se vad andra har funderat på inför sina utredningar.

Därför har vi seminarier 190923-24 där samtliga projektgrupper presenterar gruppen och de enskilda utredningsplanerna. Detta sker uppdelat i storgrupper: Varje enskild grupp går till ett seminarium (2 timmar), enligt storgruppsindelningen. Se schemat.

Varje projektgrupp på 5-6 personer ger en gemensam presentation, och har upp till 20 minuter att ge:

• En introduktion till gruppen, inklusive en kort översikt över de problemområden medlemmarna tänker utreda – typiskt 1-3 bilder och 4-5 minuter. I detta avsnitt är det bra att visa ungefär hur de valda ämnena kommer att kunna bidra till projektets helhet.

• En kort beskrivning av varje individuell utredningsplan (cirka 1-2 bilder per person, 2.0 minuter). Tänk på att ta med samma information som i den skriftliga beskrivningen: Mål, syfte, vilket problem och vilka tekniker du tänker studera, samt hur du tänker utvärdera det hela.

Sätt ihop allt till en gemensam presentation per grupp – det tar för lång tid att byta presentationer eller datorer inom gruppen! Vi kommer också att ta tiden och måste avbryta om någon tar för mycket tid, så att ingen tappar sin tid. Detta är inget att oroa sig alltför mycket över – men repetera lite i förväg, försök utnyttja tiden bra (utan att dra ner på presentationen till 1 minut...), och använd detta som en övning på att presentera med ett hårt schema.

Återkopplingen under seminariet kommer främst att fokusera på att det ser ut att fungera bra inom gruppen. Individuella kommentarer kommer att ges efter att planerna är inlämnade, eftersom detta kräver betydligt mer tid än vi har vid ett gemensamt seminarium.

Deadline 190924: Inlämning av utredningsplan

190924 lämnas utredningsplanen även in via epost till Jonas Kvarnström, Fredrik Präntare och Mattias Tiger (se kontaktsidan). Om vi ser uppenbara problem, potentiella eller definitiva, ger vi återkoppling på detta inom några dagar. I så fall behöver även en reviderad version lämnas in.

Återkopplingen kan t.ex. handla om att en utredning verkar för svår/avancerad för kursens omfattning, att två personer inom en grupp har valt alltför lika områden för att båda ska kunna fortsätta med dem under projektet, att frågeställningen inte är tillräckligt tydlig (vanligt!), att kriterierna inte är tillräckliga eller kommer att vara svåra att utvärdera, eller annat som vår erfarenhet säger oss kan leda till problem under den egna utredningen eller under projektdelen.

Som alltid har du ändå kvar huvudansvaret för inriktningen: Avsaknad av återkoppling är ingen definitiv garanti för att utredningen kommer att gå smidigt.

Steg 3: Genomför undersökningen och skriv din rapport.

Genomför undersökningen med stöd av dina inledande undersökningar från skrivandet av utredningsplanen. Du kommer också att få möjlighet att ställa frågor under ett par seminarier enligt nedan.

Här ska du alltså läsa litteratur för att reda ut vad som är mest intressant att implementera och testa i praktiken.

• Läs vetenskapliga artiklar, (kursböcker)
  • Utgå från utvärderingar som redan har gjorts (se t.ex. kursens wikisidor)
  • Jämför systematiskt vad som sägs om olika tekniker och utvärdera hur de passar era specifika kriterier
  • Citera era källor – viktigt!

• Sök vidare – leta gärna efter mer information om teknikerna. Använd primärt vetenskapliga artiklar, sekundärt kursböcker. Google Scholar kan hitta relaterade artiklar som citerar det ni läser!

Rapporten: Omfattning och format

Du måste skriva på svenska eftersom rapporten även ska språkgranskas.

En lagom längd på rapporten kan vara 4-6 sidor text i ett typiskt konferensartikelformat med dubbla kolumner. En mall kommer att göras tillgänglig här (i LaTeX- och Word-format) och ska användas av samtliga deltagare. Den kommer också att innehålla de tänkta sektionsrubrikerna, som liknar den standardiserade indelningen av vetenskapliga rapporter men delvis är anpassad till utredningens specifika behov.

Bilder är mycket välkomna. Dock ersätter de inte det skrivna ordet, så en rapport med många stora bilder behöver fortfarande normalt omkring 4-6 sidor text. Även referenslistan, eventuell innehållsförteckning med mera ligger utanför de 4-6 sidorna.

Skulle du känna att du har så mycket att säga att du vill ha någon sida till kan det vara OK, speciellt om det gör att hela rapporten blir mer lättläst eller att du får bättre underlag för de slutsatser du drar. Men då behöver du först se till att du skriver på ett "lagom kortfattat och koncist" sätt, så att rapporten inte blir längre på grund av överflödigt material.

Försök inte att anpassa formatet eller texten för att få en alltför rapport att se större ut eller tvärtom. Det minskar bara läsbarheten.

Rapporten: innehåll och övergripande struktur – viktigt för utredningsarbetet!

Det finns ett förväntat flöde i en utredning, och man behöver tänka på att följa detta flöde i rapporten och att tydligt separera olika aspekter av utredningen!

1. Problemställning. Detta har redan diskuterats för utredningsplanen och samma villkor gäller även här, förutom att det finns lite mer plats att utveckla texten.

   Om din problembeskrivning inte är mycket tydlig ("jag vill veta vart jag ska gå" – när, i vilken situation, ...?) blir det svårt att utvärdera din analys och utvärdering, och detta leder ofta till komplettering.

   Men koppla gärna det specifika problemet till en generell (men väldefinierad) problemtyp – "Detta kan ses som ett planeringsproblem", "detta är en form av path finding", "detta är ...".

2. Utvärderingskriterier. Man vill att lösningen ska uppfylla vissa kriterier. Dessa kriterier kommer man fram till i förväg, innan man letar efter lösningar. De har inget att göra med vilka lösningstekniker man har hittat, så fortfarande hålls diskussionen fokuserad på problemet.

   Numrera dina kriterier så att du kan hänvisa till dem i utvärderingen.

3. Tekniker och algoritmer. När man har satt upp de kriterierna går man vidare och letar efter tekniker som kanske uppfyller dem. De teknikerna behöver beskrivas på en rimlig nivå så att läsaren inte behöver gå till en källartikel för att förstå dem. En sådan beskrivning kan givetvis inte vara precis lika detaljerad som källartikeln, för då skulle man lika gärna kunna hänvisa dit. Istället ska man hitta en lämplig detaljnivå som ger en tillräcklig bas för läsaren att (a) förstå hur tekniken kan appliceras på det givna problemet, (b) förstå den kommande utvärderingen och varför du som skriver utvärderingen har dragit dina slutsatser.

   Men vi har fortfarande inte kommit till utvärderingssteget! Blanda alltså inte in några egna värderingar av teknikerna ännu, utan håll dig helt och hållet till en objektiv beskrivning av valda tekniker utan att explicit koppla det till StarCraft II.

   Exempel: Anta att ett av dina kriterier är att en teknik måste fungera bra i en värld där kartan dynamiskt ändras under tidens gång. När du i detta avsnitt beskriver en teknik kan du tala om att den appliceras på en statisk karta, eller att den har vissa specifika dynamiska egenskaper. Detta är en objektiv egenskap som inte har med StarCraft II att göra. I nästa avsnitt blir det dags att diskutera om och hur tekniken kan appliceras i StarCraft II ("teknik A appliceras på en statisk karta och om vi då ska använda denna i StarCraft II måste vi göra så här") och konsekvenserna av detta. I utvärderingsavsnittet blir det sedan dags att diskutera konsekvensernas koppling till kriterierna.

4. Användning i StarCraft II. För att använda de tekniker som just beskrevs behöver man applicera dem på just StarCraft II. Det räcker ju inte att säga "jag har beskrivit A* och nu kör jag A*". Alla implementerade tekniker behöver någon form av input, och de ger någon form av output, antingen data/information eller "styrsignaler" som kontrollerar spelet.

   I de allra flesta rapporter behöver man därför beskriva hur en vald teknik skulle kunna tänkas appliceras. Använder man A* för att hitta vägar behöver man t.ex. ange hur man i så fall skulle generera en graf att söka i, vad som är start- och målnoder, och hur man kommer fram till detta utifrån det API som man använder i StarCraft II. Man behöver också tala om vad det är som ska röra sig enligt den väg som genereras. Använder man potentialfält kan läsaren fråga sig var potentialen kommer ifrån och exakt vad det är som sedan styrs av den uträknade potentialen i varje punkt... och så vidare.

   Tänk på att det kan vara viktigt att veta vilken information som faktiskt finns tillgänglig från StarCraft. Vad kan en agent veta, och vad kan den inte veta? Om en algoritm kräver en viss sorts information, kan du få tag på den, och i så fall hur? Är informationen pålitlig?

   I utredningsrapporten behöver detta avsnitt så klart inte gå ner på den allra mest detaljerade nivån ("ända till kod"), men man behöver definitivt få en god bild av vad du som utredare har tänkt dig. Annars kan tekniken och slutsatserna "hänga löst".

   Om du försöker applicera en vald teknik men kommer fram till att den inte alls är applicerbar (inte bara att den bryter mot dina utvärderingskriterier utan att den överhuvudtaget inte gör det du vill, eller kräver information du inte har):

   • Upptäcks detta "tillräckligt" tidigt bör du välja att ta bort tekniken helt och införa en annan teknik som alternativ.
   • Upptäcks det när du har arbetat en hel del på beskrivningen och att försöka applicera tekniken, kan det vara orimligt att börja om med en annan teknik. Då kan detta utredningsarbete finnas kvar i rapporten. Du måste då ändå ha tillräckligt mycket material i rapporten i sin helhet. Kanske du även har en annan teknik att utreda. Diskutera gärna med handledarna.

5. Utvärdering. Man utvärderar de valda teknikerna, så som de är tänkta att appliceras på StarCraft II, efter de kriterier som man redan tidigare satte upp. Utvärderingen ska alltså ange hur väl varje vald teknik uppfyller varje angivet kriterium enligt det sätt man har tänkt att applicera tekniken. Övriga slutsatser får vänta till senare.

   Gå genom alla de numrerade kriterierna du satte upp, och se till att samtliga kriterier faktiskt utvärderas i tur och ordning, för samtliga tekniker / lösningar som ingår i din studie.

   Du får lägga till nya kriterier, om du upptäcker något som missades i planeringen och som verkar vara viktigt att utvärdera efter. Du får däremot inte ignorera något av de kriterier som du ställde upp i din utvärderingsplan. Om de visar sig svåra att utvärdera, ska du istället motivera detta.

   I de flesta fall är det givetvis omöjligt att vara helt säker på hur bra en viss teknik fungerar i StarCraft II utan att faktiskt implementera den och testa (ett undantag kan vara när man upptäcker att tekniken faktiskt inte alls var applicerbar för att den löser ett helt annat problem). Arbeta då för att komma fram till så bra slutsatser du kan, och sök gärna efter mer underlag om detta är möjligt – ge inte direkt upp och säg "vet inte" – men gör inte utvärderingen "för stark" bara för att du vill kunna säga något definitivt!

   Skriv till exempel inte "X är definitivt bra på kriterium Y" om du bara har underlag för "X kan nog vara ganska bra på kriterium Y, men det finns en del osäkerheter av dessa anledningar". Om det inte finns mer evidens än så, är det ju detta som är den korrekta utvärderingen.

   Var också försiktig med att jämföra två tekniker utifrån vad olika författare har skrivit om dem, eller utifrån deras resultat i olika världar och situationer. Om en författare beskrev teknik A som ganska effektiv, och en annan beskrev teknik B som lite långsam, är då A bättre än B eller hade författarna olika mätstickor? Om teknik A fungerade bra (i schack) och teknik B var dålig (i Fia med knuff), måste teknik A då vara bättre i StarCraft II?

   Att komma fram till uttalanden av rimlig styrka, varken alldeles för starka eller alldeles för svaga, är viktigt i rapporten. Försök hitta en lagom nivå, och argumentera sedan för dina uttalanden så att läsaren övertygas om att det du faktiskt säger verkar korrekt. Om du säger att en algoritm definitivt är bra, behöver du övertyga läsaren om detta. Om du säger att en algoritm verkar bra men att det inte är helt säkert, behöver du övertyga läsaren om att det finns goda egenskaper ("verkar bra") men också motivera varför artiklarna inte kunde ge tillräckligt underlag för att vara säker ("har bara utvärderats i situation X och den situationen är liknande min situation, men eftersom situationerna skiljer sig på punkt Y och Z är det möjligt att det inte fungerar lika bra här"). Man kan alltså inte komma undan med att helt enkelt säga "kanske bra, vet inte riktigt" på alla kriterier; både säkerhet och osäkerhet behöver motiveras på något sätt!

   Tänk på att inte komma med ny information om hur teknikerna och algoritmerna fungerar. Detta hör hemma i den tidigare beskrivningen av teknikerna och algoritmerna. Lägg inte heller till information om hur du har tänkt applicera dem här, utan uppdatera i så fall de tidigare avsnitten. Varje avsnitt har sitt eget ämne, och här handlar det om just utvärdering.

6. Slutsatser. Till slut drar man slutsatser. Medan utvärderingen i det förra avsnittet redan har fokuserat på hur bra olika lösningstekniker verkar kunna uppfylla de uppsatta kriterierna, ska slutsatserna handla om hur utvärderingen påverkar det du tänker göra i det fortsatta arbetet i projektet. Exempel: Väljer du att implementera någon av de utvärderade teknikerna, och vilka aspekter av utvärderingen är det i så fall som gör att du väljer just denna teknik?

Denna ordning och detta flöde ska följas i rapporten. Sedan kan det i praktiken vara så att ni egentligen har varit intresserade av en viss teknik eller algoritm och först därefter letat problem som den kan lösa, men vid rapportskrivandet får man se det som ett förstadium till den verkliga studien. Rapporten ska alltså starta med problem och kriterier och sedan gå vidare till teknikerna, och så vidare.

Rapporten: Om bakgrundsmaterial

• Utgå från att läsaren redan känner till StarCraft II i allmänhet och kanske har spelat spelet i någon timme. Du behöver alltså inte beskriva de mer grundläggande tankarna bakom spelet eller tala om vad en Terran är, men räkna inte med att läsaren känner till en Ultralisk eller Unit Dancing.

• Utgå från att läsaren redan vet i vilken kontext du skriver rapporten: Du är medlem i en projektgrupp som bygger en agent som ska spela StarCraft II. Detta behöver inte beskrivas på nytt i rapporten. Om det ändå beskrivs, räknas det inte med i rapportens omfattning.

• Utgå från att läsaren har gått ett par år på U-programmet (och alltså är programmeringskunnig och allmänt "tekniskt kunnig"), och att läsaren redan känner till AI-begrepp motsvarande kursen TDDC17. Det finns alltså en hel del grundläggande AI-kunskap som normalt inte behöver repeteras i rapporten, inklusive grundläggande begrepp som agenter, sökning, planering, vägplanering med mera.

  Undantaget är att de problem och tekniker som du utvärderar i rapporten måste beskrivas tydligt i teknikavsnittet även om teknikerna ingår i TDDC17.

  Exempel: Om A* är en av teknikerna du utvärderar för användning i projektet behöver du alltså beskriva algoritmen, men om du bara vill nämna den i en kort jämförelse ("min utvärderade teknik X är bättre än A*, eftersom ...") kan du hänvisa till att A* ingår i TDDC17. Däremot skulle du behöva beskriva Focused D* till en högre grad även om den bara ingick i en kort jämförelse, eftersom den inte diskuteras i TDDC17.

Rapporten: Referenser

Utredningen ska baseras på vetenskapliga artiklar. Alltså behöver man hitta sådana artiklar och även referera till dem på lämpliga ställen i texten.

Vi skriver "artiklar" i plural, eftersom en utredning av den här typen normalt inte kan baseras bara på en enda artikel. Ett normalt antal kan vara 3-5 olika referenser (varav någon kan vara en bok), i vilka man t.ex. kan hitta olika information om samma lösningstekniker, eller mer information om flera olika tekniker.

• Läs på om att referera, citera och parafrasera! Även om du inte genomgår hela NoPlagiat-studierna behöver du veta hur man ska använda citeringar. Det räcker t.ex. inte bara att en artikel refereras till någonstans i texten, utan man behöver veta vad som kommer från just den artikeln, genom hela rapporten!

• Var noga med att skilja på vad som är ditt material (dina egna åsikter och slutsatser) och vad som är taget mer eller mindre direkt från artiklarna. I vetenskapliga artiklar som bygger på andras material är det ofta tätt mellan referenserna. Med andra ord, om du plockar information från samma artikel på 20 olika ställen är det rätt att referera till artikeln på alla dessa 20 ställen, så det blir tydligt var informationen kommer från! För att detta inte ska upplevas som att det bryter flödet alltför mycket kan man gärna citera numeriskt [2,3].

• När det gäller att hitta rätt artiklar: Det viktigaste är inte att man hittar den allra bästa, nyaste artikeln att referera till. Kursen är inte tillräckligt stor för att vi ska kunna lägga ner ett enormt arbete på det (skulle lätt kunna ta en termin att göra en rejäl undersökning). Istället är det viktigaste att de man kan utvärdera på ett bra sätt efter de relevanta referenser och studier man faktiskt har tillgång till.

• Om du märker att information som du är intresserad av saknas i litteraturen, eller att underlaget inte räcker till, får du gärna (kortfattat) nämna vad du inte har kunnat ta reda på. Det visar att du inte bara missade viktiga aspekter, utan att informationen saknades.

• Egna undersökningar kan finnas med till viss del, men tyngdpunkten ska vara på att undersöka vilka slutsatser man kan dra från publicerade artiklar och böcker.

Rapporten: Svengelska

När man skriver en rapport av detta slag är det lätt hänt att man kommer får med en del svengelska. Här samlar vi en del förslag och exempel runt detta ämne. Om du undrar över översättningen av något ord som inte finns med här: Sök gärna på nätet och fråga oss annars.

Om ett ord inte kommer genom din stavningskontroll (för en sådan gör du väl?) kan det bero på att det är svengelska.

Listan nedan är delvis uppdaterad efter inlämningen, när vi har sett vilka ord som ger problem.

• Hungarian method - ungerska metoden
• action - handling (inte aktion!)
• back propagation - bakåtpropagering
• barracks - kasern (en barack är något annat)
• build order - byggordning
• constant - konstant
• discretization - diskretisering
• entries - poster
• flow fields - flödesfält
• gradient descent - gradientsökning
• greedy - girig
• grid - rutnät
• grid cell, cell - ruta
• harvesta - skörda
• hidden layer - gömt/gömda lager
• Hidden Markov Model - dold markovmodell
• layer - lager
• marine - marinsoldat
• potential fields - potentialfält
• ratio - kvot
• reward - belöning
• scouting - utforskning, patrullering, rekognosering
• simplifiera - förenkla
• space - rymd (state space = tillståndsrymd)
• state - tillstånd
• state variable - tillståndsvariabel
• supply depot - depå, förråd, lager
• temporal - temporal (men temporary - temporär)
• time step - tidssteg
• unit - enhet
• unit collision - att man kolliderar med en annan enhet
• win/lose - vinna/förlora

Samtidigt finns också en del terminologi där det inte finns någon vedertagen svensk översättning. Där kan det vara minst förvirrande att fortsätta använda de engelska orden. Det kan rekommenderas att sätta dem i kursiv stil, reaper, eller inom citattecken, "reaper", för att markera att man använder specifika termer snarare än att man bara har missat att översätta något.

• Tekniker och algoritmer med "egennamn", som Q-learning, reinforcement learning, supervised learning, ...
• Reaper, marauder, ... -- dessa kan vi också se som egennamn som man inte nödvändigtvis förstår om man översätter dem "direkt". Ett undantag är marine som bör översättas till marinsoldat.
• Kiting
• Utilityfunktioner -- vi kan inte hitta något vedertaget svenskt begrepp för detta, och det normala är att man säger just "utilityfunktion". Se bara till att inte särskriva!
• ...

190930, 191010: Stödseminarier, frågor och feedback

Under utredningsarbetet kommer vi att boka in två 30-minuterspass per projektgrupp för att diskutera det pågående individuella arbetet. Detta är schemalagt som seminarier 190930 och 191010. Alla grupper kommer att få information om vilket 30-minuterspass man ska närvara på, och man ska alltså bara närvara på dessa 2x30 minuter, inte på andra gruppers tider.

Till dessa tillfällen behöver du själv se till att vara förberedd på att kunna diskutera runt din egen pågående utredning, få feedback på detta, och ställa de viktigaste frågorna du själv vill ha svar på angående det du gjort hittills och det du planerar att göra. Det är du som driver diskussionen (cirka 5 minuter per person)! Ta gärna med dator eller utskrift om du vill diskutera mer specifika detaljer.

Gruppmedlemmar som inte har frågor bör också närvara, både för att ge egen feedback och för att se vad som är på gång: Det enskilda arbetet ska ju i slutet vara till hjälp för hela gruppen. Som gruppmedlem är du alltså mycket välkommen att själv svara på frågor från andra gruppkamrater och att ge förslag på vägar framåt.

Vi kan tyvärr inte ge exakta svar på om ett visst arbete "räcker" förrän rapporten är inlämnad, eftersom det tar en hel del tid och kräver att man går genom resultatet i sin helhet. Seminarierna är inte heller till för att ta över ert arbete, så vissa frågor kanske vi inte svarar på.

Närvaro är inte obligatorisk men starkt rekommenderad. Seminarierna är också ett av många sätt som ni kan använda för att övertyga oss om era kunskaper. Ju mindre ni närvarar, desto mer måste ni visa på andra sätt.

Rapporten: Tänkbara problem

Under 2018 såg vi en del vanliga problem i de individuella rapporterna, allt från vanliga skrivfel till missuppfattad terminologi till strukturella problem. Mycket av detta har vi diskuterat ovan, men vi vill ändå ge en kortfattad lista på några fler saker att vara försiktig med.

• Definiera problemet tydligt. "Byggnadsplacering" är i sig ingen tydlig beskrivning. Är problemet (1) jag tänker placera ut någon sorts byggnad och vill veta var den ska vara, (2) jag tänker placera ut en byggnad av typ X och vill veta var den ska vara, (3) jag tänker placera ut n byggnader och vill veta var de ska vara, ...? Tänk dig gärna att du definierar problemet för någon annan som utifrån din beskrivning ska förstå vilket problem som ska lösas. Otydligheter gör att den personer kan spendera veckor på att lösa fel problem!

• Kriterier och deras utvärdering

  • Tydlighet: Man behöver förstå exakt vad kriterierna betyder. Om du diskuterar tidskrav, diskutera då tydligt vad du menar. Ska det köras på 1/60 sekund? Ska det kunna uppdateras på 1 sekund inför att man kör igång spelet? Vad är "snabbt" egentligen? Skilj också t.ex. på att maximera sannolikheten att få information och att maximera mängden information man förväntas få. Tänk dig gärna att du definierar kriterierna för någon annan som ska utvärdera teknikerna. Otydligheter om vad som egentligen ska utvärderas kan göra att fel teknik kommer att väljas för projektet!

  • "Klarar tekniken att lösa problemet"? -- är detta rätt fråga? Ofta är det "Hur bra klarar tekniken att lösa problemet?".

  • Dra inte FÖR starka slutsatser. Man kan komma till slutsatsen att "jag vill testa med Q-Learning" utan att för den skull behöva dra slutsatsen att "Q-learning är definitivt bäst", om det inte går att förankra den senare slutsatsen i underlaget.

  • Om du ser i litteraturen att teknik A är bra på något, men saknar uppgifter om teknik B, har du ingen stark grund för att säga att A är bättre än B på detta.

• Terminologi och tekniska bregrepp

  • Optimal = perfekt. Ibland vill man ha "bra" och kräver inte "optimal".

  • Tidskomplexitet = hur tidsåtgången varierar med storleken på problemet. Sortering kan göras med tidskomplexitet n log n, där n är antalet element. Ibland vill man undersöka ungefärlig uppskattad tidsåtgång snarare än formell tidskomplexitet.

  • Var noga med skillnad mellan olika tekniska begrepp som tillstånd, stokastiska variabler vars värden är tillstånd, med mera. Och om du pratar om tillstånd, vilken sorts information ingår i ett tillstånd?

  • Använd genomgående samma ord för att beskriva samma sak. Kalla inte något ett "område" ibland och en "zon" ibland; i tekniskt skrivande är vi inte ute efter variation, utan vill ha maximal tydlighet.

• Skrivfel och oversittings

  • eftersom att -- "eftersom" eller "för att" eller "på grund av att".

  • "Human" = mänsklig i betydelsen god, barmhärtig, "inte grym".

  • "Flertalet" = "de flesta" -- "ett flertal" = "många"

Steg 4: Redovisning, granskning, betygsättning.

191029: Inlämning av utvärderingsrapport (examination)

Senast söndag 191029 lämnar du in din utvärderingsrapport på (normalt) 4-6 A4-sidor. Rapporten ska vara skriven enligt instruktionerna ovan. Den lämnas in i PDF-format via en issue i Gitlab. Detta kommer bara att vara öppet för kursdeltagarna (specifikt de som har registrerat sig på UPG2-Rapp i Webreg).

Döp filen till "Rapport-TDDD92-liuid123.pdf", där liuid123 är ditt LiU-id.

1911xx: Seminarium, presentera resultat av utredningen (examination)

På seminarierna 1911XX presenterar du resultatet från din rapport. Ursprungligen schemalagt till 191017, men flyttas till början av nästa period.

Seminariernas delas upp per storgrupp och alla är närvarande under ett pass där man även får se några andra gruppers presentationer. Tanken bakom detta är bland annat att man ska få möjlighet att se andra presentationer som helt eller delvis täcker samma ämnen som man själv har utrett, och att detta kan hjälpa till i det kommande arbetet.

Detta är ett examinationsmoment. Om man inte kan närvara kommer det att dröja till januari innan man kan komplettera.

Om presentationen:

• Varje deltagare har cirka 5-6 minuter. Försök att varken gå över tiden eller göra presentationen alltför kort.

• Presentera problemet, utvärderingskriterierna, teknikerna, utvärderingen och slutsatsen.

• Ni behöver inte presentera exakt hur en lösningsteknik fungerar. Så mycket tid finns inte under seminarierna. Sikta på en "intuitiv" bild över vad teknikerna egentligen innebär.

• Huvudfokuset är på utvärderingen: Hur väl uppfyller tekniken de olika kriterierna, punkt för punkt?

Vi har mycket begränsade möjligheter till återkoppling under presentationen. Vi kommer främst att fokusera på eventuella felaktigheter som skulle kunna sätta någon annan student på fel spår. I övrigt kommer vår återkoppling skriftligen, baserat på rapporten.

Granskning och betyg

Betyget (3-4-5 eller komplettering) på detta moment (UPG2, 2 hp) baseras bland annat på hur tydligt och välmotiverat problemet är, hur väl utvärderingen är gjord och hur väl rapporten är skriven. Hur tekniskt avancerade tekniker som valts kan också spela in, på så sätt att mindre komplexa tekniker kan behöva undersökas djupare.

Det som avgör betyget är inte enbart "medelnivån" på rapporten. Det händer också att rapporten har problem som måste rättas till även om nivån i övrigt är hög, vilket då ger en omedelbar komplettering.

Utöver detta måste man även få godkänt från språk- och strukturgranskningen av rapporten (IKK) för att få ett godkänt betyg på UPG2.

Att skriva en sådan här rapport är inte helt trivialt. Det finns mycket att tänka på och vi har full förståelse för att man kan missa något i rapporten. Därför gör vi vårt bästa för inte bara ge en siffra som bedömning, utan även konkreta kommentarer och förklaringar i de fall rapporten inte når upp till högsta betyg. Detta gör att resultatet ibland kan dröja mer än de vanliga 2 veckorna som gäller för tentor. Alternativet skulle vara en betydligt mindre detaljerad återkoppling till er kursdeltagare!

Plussning och komplettering

Plussning och komplettering kommer att vara möjlig vid ett senare inlämningstillfälle efter kursens slut. Satsa ändå på att få rapporten så bra som möjlig vid första inlämningen, och utnyttja seminarietillfällena till frågor och feedback – det sparar vi alla tid på!

Senare inlämningar sker bara vid specifika inlämningstillfällen (varav ett kommer att vara vid jul/nyår), och vi tittar inte på inlämningar mellan dessa tillfällen. De kan också ta längre tid för oss att hantera då vi har många andra kurser och arbetsuppgifter att ta hand om.

Det är omöjligt för oss att säga i förväg exakt vad man behöver ändra för att få godkänt eller ett högre betyg. Betyget måste sättas efter rapporten i sin helhet, och styrkor och svagheter måste vägas mot varandra. En förbättring på 2 av 5 punkter kan vara fullt tillräcklig om den håller mycket hög kvalitet på just dessa punkter, medan man annars kan behöva förbättra alla 5, och så vidare. Att beskriva de villkoren i förväg fungerar inte.

Vid plussning eller komplettering får man alltså jobba vidare i den grad man själv anser vara lagom, och sedan skicka in för en ny bedömning. Det är egentligen inte så stor skillnad mot en tenta, där man kanske får veta ungefär vad man missade i svaren på den förra tentan men inte vet hur tydliga svaren hade behövt vara eller vilka frågor som kommer på nästa tenta.