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 metoden:

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, givet vad man vet om världen") 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.

De här stegen är alltså ungefär vad du ska göra i utvärderingsarbetet. Det följs sedan av projektarbetet, där du faktiskt 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 helt OK, så länge du faktiskt har implementerat tekniken korrekt och gjort en bra utvärdering!)

Med andra ord, och mer kortfattat, ska du:

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

• Välja 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älja ut en eller 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

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

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 du ska kunna 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äsning 2, 2021-09-01, läser du An Introduction to Game-Playing Systems and StarCraft II.

Föreläsning 2 (2021-09-01): 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

Efter föreläsningen är det dags att bilda projektgrupper om cirka 5-7 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 (2021-09-03): 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.

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å IKOS. Därför har vi också en fjärde föreläsning som just handlar om hur man skriver rapporter (2021-09-06).

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!

Ta detta moment på allvar: För att bli godkänd på den individuella utredningen måste man ha godkänt på språk och struktur från IKOS!

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 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 kort utredningsplan.

Fram till fredag 2021-09-10 (senast): Planera den egna utredningen

Du funderar, läser på, och skriver en plan för den tänkta utredningen. Dokumentet ska beskriva problemet du tacklar och visa vilka tekniker att utvärdera. 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.

Vi kommer mycket snart att tillhandahålla en mall för dokumentet. Den mallen ska användas! Mallen kommer att tala om vilken information som ska anges.

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.

Fredag 2021-09-10: Inlämning av utredningsplaner

Senast fredag 2021-09-10 lämnar du in din utredningsplan. Den lämnas in i PDF-format och ska döpas till Utredningsplan-TDDD92-2021-liuid123.pdf, där du så klart stoppar in ditt eget LiU-id.

Inlämning sker via en issue i Gitlab, en separat ärendehanterare för just inlämningar. Dessa issues kommer att vara konfidentiella och kan enbart ses av inlämnaren + kursledningen.

Efter inlämningen tittar vi på din utredningsplan för att se om den förklarar tillräckligt väl vad du tänker göra. Det händer till exempel att vi ser att någon har missförstått uppgiften, att några vill satsa på områden som är alltför komplexa eller alltför simpla, och att vissa egentligen inte har klart för sig vad de vill göra. Vi kommenterar och du får en möjlighet att lämna in en eller ett par nya versioner av planen – för din egen skull.

Alla problem kan inte förutsägas från en kort utredningsplan. Vi kan alltså inte lämna några garantier att din utredning kommer att fungera smidigt, även om vi inte har några allvarliga kommentarer att ge.

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 uppfyller utvärderingskriterierna
  • Citera dina 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 i LaTeX-format (mall-rapport-* i mallkatalogen) kommer att finnas tillgänglig och ska användas av samtliga deltagare. Den innehåller de tänkta sektionsrubrikerna, som liknar den standardiserade indelningen av vetenskapliga rapporter men delvis är anpassad till utredningens specifika behov. (Rapportmallen är baserad på den för IJCAI-19 Proceedings, en av de högst rankade AI-konferenserna. Vi har gjort några mindre förändringar, ändrat rapportstrukturen, satt pappersstorleken till A4 och lagt till stöd för svenska.)

Vissa rekommenderar Overleaf för att arbeta med LaTeX på webben.

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! Detta leder till olika avsnitt i utredningsrapporten. Avsnitten finns redan med i mallen, så titta gärna på den parallellt med att du läser här.

1. Problemställning. I de flesta fall kan man använda problemställningen från utredningsplanen som grund för detta avsnitt -- men man behöver dels ta hänsyn till de kommentarer man kan ha fått i granskningen av planen, dels arbeta vidare med en tydligare och mer formell beskrivning av problemställningen.

   Var noggrann och tydlig. Definiera dina begrepp. "Jag vill veta vart jag ska gå" – när, i vilken situation, ...? Vad menar du med "arbetare", "jobb", "plats", och så vidare (om du använder dessa begrepp)? Vad är "kostnad" i din problemställning? Tänk dig att någon annan ska lösa problemet utifrån din beskrivning -- problemställningen är då en kravspecifikation som måste vara extremt tydlig. Här ser vi ofta problem som gör det svårt att utvärdera din utvärdering (!), och det leder ofta till komplettering.

   Samtidigt får du gärna koppla 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 ...".

   Var också mycket noggrann och tydlig med exakt vilken information du tänker dig ska finnas tillgänglig ("indata", allt det som lösningsmetoden får använda sig av för att lösa problemet) och hur den definieras, samt exakt vad du tänker dig att en lösning skulle åstadkomma (form på utdata alternativt vilka ``styrsignaler'' lösningen ger).

   Motivera också din problemställning: Tala om tydligt varför man vill kunna lösa det här problemet. Det övergripande målet är samma för alla -- ungefär att maximera möjligheterna att vinna i spel mot andra agenter eller människor -- så det behöver inte diskuteras här, utan problemställningen ska fokusera på hur man tänker sig att det "X" ska kunna bidra till detta. Varför är det överhuvudtaget relevant för StarCraft-agenten} att klara"X"?

   Vi rekommenderar mycket starkt att man baserar sina argument på en eller flera specifika situationer i en spelomgång, helst med en eller flera skärmbilder: "Nu är spelet i detta läge, vi är i läge A och motståndaren i läge B, här försöker vi göra C och motståndaren vill göra D, i det läget är det viktigt att vi klarar av uppgift X, eftersom / för annars...". 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 kommer du själv att ha mycket nytta av i resten av utredningen!

2. Utvärderingskriterier. Målet med utredningen är att hitta en eller flera lösningar som uppfyller vissa kriterier. Dessa kriterier måste man då komma fram till i förväg, innan man letar efter lösningar; annars vet man inte vad man ska utreda, och det kan hända att man börjar utvärdera utefter vad som är enkelt istället för vad som egentligen är viktigt. Kriterierna har inget att göra med vilka lösningstekniker man har hittat, så fortfarande hålls diskussionen fokuserad på problemet. Man ska t.ex. inte nämna något om inlärning, sökning, potentialfält, eller liknande.

   Eftersom det inte är så lätt att välja rimliga kriterier, och lätt att missa något viktigt, ger vi redan på förhand 4 kriterier som \emph{alla} ska använda. Man får sedan gärna lägga till flera kriterier på egen hand.

   1. Hur väl verkar det gå att förstå den tänkta lösningsmetoden och att applicera den under implementationsfasen? Här ingår att läsa på hur lösningsmetoden fungerar och vilka krav som finns för att den ska kunna användas. Det kan till exempel vara mer eller mindre svårt att förstå hur metoden ska implementeras i Python-kod, mer eller mindre svårt att förstå vilka indata som krävs och hur man ska använda resultatet av metoden (utdata) i en agent, mer eller mindre svårt att få fram indata givet den ofullständiga information man har tillgänglig, med mera.

   2. Hur väl verkar lösningsmetoden kunna lösa exakt det problem som ställdes upp? Med andra ord, om man förutsätter att man faktiskt kan förstå och implementera metoden, hur bra tror du att lösningen på problemet blir? Det kan hända att en metod du har valt visar sig lösa ett helt annat problem, och då framkommer det i den här delen av utvärderingen. Det kan hända att metoden löser problemet men ger mer eller mindre bra kvalitet på lösningen. Det kan hända att du inte kan få tag på indata med bra kvalitet och att du därför tror att metoden i praktiken inte kan lösa ditt problem i StarCraft. Och så vidare...

   3. Hur väl verkar lösningsmetoden kunna bidra till att agenten blir bättre på att spela StarCraft? Detta är ganska nära kopplat till den förra punkten, och i vissa fall kan man tänkas hänvisa direkt till svaret på den punkten. I andra fall kan det hända att man visserligen löser problemet som det var uppställt, men att olika lösningar ändå bidrar olika mycket till spelkvaliteten.

   4. Hur "säkert" verkar det vara att välja den tänkta lösningsmetoden? Det vi är ute efter här är en bedömning av sannolikheten att det leder till ett bra resultat för kursen, med en rimlig arbetsinsats: Även en väldigt bra lösning kan vara olämplig om den inte passar in i kursarbetet. Förståelsen (punkt 1) är en del av detta, men det finns också andra aspekter som är viktiga. Exempelvis kan det finnas metoder där det ser ut att vara lätt att komma fram till en punkt där allt fungerar, varefter man kan förbättra och finputsa till tiden tar slut, vilket gör att man kan anpassa sig till oväntade bakslag eller framsteg. Andra metoder kan se ut att ha en hög första tröskel att komma över, vilket är mer riskabelt. Det kan också vara mer eller mindre säkert att man lyckas få tag på de indata man behöver för att faktiskt använda metoden, speciellt om det är någon annan i gruppen som ska ta fram dessa indata. Metoder kan också ha andra beroenden på sådant som är svårare att förutsäga, t.ex. maskininlärning.

   Kriterierna är numrerade och ska vara det även i rapporten, så du på ett tydligt sätt kan hänvisa till dem i utvärderingen.

   I utredningsrapporten ska lösningar utvärderas efter de här kriterierna utan att man har provat att implementera lösningen eller applicera den på StarCraft. Det är främst därför vi skriver ``verkar'' i kriterierna ovan: Den rena teoretiska utredningen kommer inte att ge definitiva svar om hur bra lösningen är, utan är till för att du ska välja bland tänkbara metoder och hitta en som verkar rimlig att implementera för en djupare utvärdering.

3. Tekniker och algoritmer. När man har satt upp de kriterierna går man vidare och letar efter tekniker som kanske uppfyller dem. I detta avsnitt av utvärderingsrapporten ska du:

   • Beskriva samtliga dessa tekniker på en sådan nivå att läsaren kan förstå dem från beskrivningen, utan att 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. 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.

   • I normalfallet beskriva algoritmer i pseudokod! Beskriver man dem helt och hållet på svenska blir det luddigt och svårförstått; detta passar mycket bättre som komplement till pseudokod, för att förklara vad den egentligen gör (på en hög nivå), varför den gör det, och hur det hela hänger ihop. Om en algoritm är beskriven i pseudokod i en artikel är det fullt tillåtet (och rekommenderat) att citera denna pseudokod exakt som den såg ut och helt enkelt lägga till en citering \cite{...} och en egen förklaring av pseudokoden.

     (Pseudokod är bästa lösningen när man går genom en algoritm steg för steg, men om man inte orkar, kan nästa alternativ vara punktlistor som kan vara nästlade i upp till två nivåer. Nej, det blir inte samma "flyt" som i en löpande text... men detta är inte heller en roman, och det är väldigt viktigt att läsaren får en översikt. Det är mycket lättare att hålla reda på var man är i en punktlista än i ett stycke på 40 rader.)

   • Du behöver alltså också vara noga med att beskriva de olika delarna av pseudokod, formler med mera i texten – vi behöver som sagt beskrivningar på ren svenska som komplement.

     Det inkluderar att förklara den terminologi och notation som används, och att koppla förklaringar av själva algoritmerna och teknikerna till t.ex. radnummer i pseudokod så att det går lätt att följa med i beskrivningarna.

   Tänk på: 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.

   Kom också ihåg att t.ex. supervised learning och reinforced learning snarare är metatekniker än tekniker -- de är generella idéer som sedan kaninstansieras till specifika tekniker och algoritmer såsom Q-learning. Det räcker alltså inte att ange "supervised learning" utan man behöver ange en faktisk konkret teknik.

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.

   Om en algoritm/teknik använder värdena ω eller <N,E> eller c_ij, hur har du tänkt dig att få fram sådana värden så algoritmen/tekniken kan appliceras? Hur modelleras ursprungsproblemet från StarCraft så att algoritmen/tekniken kan lösa det?

   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. Slutsats. 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 i universitetets "NoPlagiat"-självstudie, som biblioteket numera har flyttat till Lisam under "Test". Ä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!

• 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.

Hjälp under utredningens gång

Som vi har diskuterat tidigare kan man få den snabbaste och mest detaljerade hjälpen genom att skicka in en issue i vår ärendehantering, så att flera olika experter kan titta på frågorna när det finns ledig tid till detta.

Under utredningsarbetet har vi också bokat in stödseminarier där man får en möjlighet att ställa frågor och diskutera det pågående individuella arbetet. Här kan man också höra frågor från andra som arbetar med liknande utredningsområde men deltar i andra projektgrupper.

Var medveten om att vi inte kommer att kunna ha experter inom alla AI-områden närvarande under seminarierna. Skicka gärna in en issue i god tid innan seminariet för att förbereda oss på era frågor, även om ni sedan vill diskutera det på själva seminariet. Det kan också hända att vi i kursledningen behöver flytta en fråga från seminariet till "offline" (svara senare).

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å.

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.

• Bayesian networks - Bayesianska nätverk (uppkallat efter Thomas Bayes)
• Hidden Markov Model - dold markovmodell
• Hungarian method - ungerska metoden
• Q-learning - Q-inlärning eller Q-learning i kursiv stil
• action - handling (inte aktion!)
• back propagation - bakåtpropagering
• barracks - kasern (en barack är något annat)
• branch-and-bound -- översätts inte, skrivs i kursiv stil. "Branch" är att förgrena ut sökningen i ett sökträd, "bound" är att begränsa längden på grenarna då man ser att man inte kommer att kunna hitta bättre lösningar i den gren man arbetar med.
• breadth first - bredden först (bredden-först-sökning)
• build order - byggordning
• choke point - finns ingen perfekt översättning; kan skriva flaskhals ("choke point")första gången det används, och sedan använda flaskhals, så har man kopplat det tydligt till ursprungsbegreppet och det blir varken missförstånd eller svengelska.
• concept - begrepp (oftast -- "koncept" kan ha en något annorlunda betydelse!)
• constant - konstant
• depth first - djupet först (djupet-först-sökning)
• determine - t.ex. bestämma (inte determinera)
• deterministic - deterministisk
• discretization - diskretisering
• edge - båge
• entries - poster
• flow fields - flödesfält
• fuzzy set - suddig mängd, oskarp mängd (motsatsen kan kallas "skarp mängd")
• gradient descent - gradientsökning
• graph - graf
• greedy - girig
• grid - rutnät
• grid cell, cell - ruta
• harvest - skörd, skörda
• hidden layer - gömt/gömda lager
• layer - lager
• make a decision - ta (ett) beslut (inte "göra")
• map editor - karteditor
• marine - marinsoldat
• node - nod
• ordered pair - ordnat par (som har en ordning)
• potential fields - potentialfält (inte "potentiella"!)
• potetential flow - potentialflöde
• range - räckvidd (om det handlar om att nå fienden med vapen)
• ratio - kvot
• reinforcement learning - förstärkningsinlärning (inte "förstärkt inlärning")
• reward - belöning
• scouting - utforskning, patrullering, rekognosering
• simplify - förenkla (inte simplifiera!)
• space - rymd (state space = tillståndsrymd)
• state - tillstånd
• state variable - tillståndsvariabel
• supervised learning - övervakad inlärning
• supply depot - depå, förråd, lager
• temporal - temporal
• temporary - temporär
• time step - tidssteg
• unit - enhet
• unit collision - att man kolliderar med en annan enhet
• utility function - nyttofunktion
• variable elimination - variabeleliminering
• weighted - viktad
• 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
• ...

Rapporten: Tänkbara problem

Här är 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: Granskningsrunda.

När man skriver en rapport är det ofta svårt att få med all den nödvändiga informationen och de nödvändiga resonemangen. Man vet ju själv så väl hur allt hänger ihop att det inte går att se att en del av informationen bara finns i det egna huvudet, och man förstår sina egna resonemang så väl att man inte inser att viktiga steg faktiskt inte står i rapporten. Det kan leda till komplettering.

Därför har vi en granskningsrunda där alla i en projektgrupp ska lämna över sin rapport till någon av de andra gruppmedlemmarna, som då ska granska den. Detta är inte tänkt att ta tid från utredningen. Tvärtom kan det spara tid eftersom man enklare kan se potentiella problem i någon annans rapport än i sin egen.

2021-10-04: Sätt upp en granskningsordning

Det kan hända att någon hoppar av eller inte går vidare med kursen, eller inte känner sig klar med rapporten i tid. Därför behöver varje grupp se efter i veckan som börjar 2021-10-04 vilka som fortfarande är kvar och tänker genomföra granskningsrundan. De som är med i granskningsrundan förbinder sig då att lämna över sin rapport till någon annan för granskning i slutet av veckan.

Samtidigt bestämmer man vem var och en ska skicka sin rapport till. Vi rekommenderar att man granskar rapporter "cirkulärt" inom var och en av grupperna: A granskar B, B granskar C, C granskar D, och så vidare. Då blir ingen ofrivilligt ensam. Det är gruppen i sin helhet som ska se till att alla som har skrivit en (tillräckligt fullständig) rapport får en granskare.

De som eventuellt inte är med i denna granskning kan inte heller lämna in till oss under oktober, utan kan tidigast lämna in till nästa deadline i januari!

2021-10-10: Överlämning av rapporter för granskning inom gruppen

Senast midnatt 2021-10-10 (mellan söndag och måndag) ska alla som är med i granskningsrundan skicka över sin rapport till sin egen granskare. Ni ska inte skicka in denna version av rapporten till oss, utan bara till varandra.

2021-10-11, 2021-10-12: Kamratgranskning

Granskning och kommentering kan ske under måndag 2021-10-11 och tisdag 2021-10-12. Dokumentet ska så småningom lämnas över i .txt- eller .pdf-format, men vi har ingen särskild mall att använda. Du kan t.ex. skriva i Emacs eller Word eller Google Docs och skapa en PDF från den, eller skicka i textformat, eller använda verktyg där man skriver annoteringar i den ursprungliga PDF:en om du föredrar det.

Fokus är på det som fortfarande går att ändra/justera, främst presentationen / beskrivningen. Vid granskningsrundan är det för sent för att ändra något i det man väljer att utreda, att byta tekniker, och så vidare, så detta behöver inte diskuteras i granskningen. I stället ska man fokusera på hur resultatet beskrivs. Är det tydligt vad problemet är, vad som har gjorts, varför man drar vissa slutsatser, och så vidare? Detta kan fortfarande justeras. Mer om detta i en punktlista längre ner.

Undvik inte kommentarer för att vara "snälla" i er granskning! Det är inte ni som sätter betyg, och vi kan lova att vi själva kan se allt det som ni kan peka ut. Varje kommentar är istället en hjälp som låter projektkamraten fixa problem innan rapporten lämnas in, för att minska risken för komplettering.

Men ge konstruktiv kritik! Försök fokusera på möjligheten till förbättring, inte att något är "dåligt". Man kan t.ex. skriva att "jag förstår inte helt och hållet vad du menar i mening X" istället för att "mening X är oförståelig".

Kommentera även sådant som ni är lite osäkra på. Det är rapportförfattarens uppgift att sålla i kommentarerna och att välja vad man vill fokusera på. Granskaren kan alltså mycket väl inkludera kommentarer som att "här kanske det skulle vara bra att byta plats på A och B", även om man tycker att det är en åsiktsfråga. Man får gärna fråga "har du tänkt på att...".

Granskningen blir en del av betygsunderlaget. Det är inte den viktigaste delen, men den ingår. Här bedömer vi hur väl du har granskat någon annans rapport! Det är varken negativt eller positivt att du själv har fått många granskningskommentarer, utan där tittar vi helt och hållet på hur den slutliga rapporten ser ut.

Om någon skulle hoppa av efter att ha accepterat att granska din rapport tappar du en "förbättringsomgång", men du har fortfarande kvar möjligheten att förbättra rapporten efter vår granskning.

Några mer eller mindre vanliga problem i rapporter:

• Allt som diskuteras ovan under "Rapporten: Tänkbara problem".

• Svengelska; se "Rapporten: Svengelska" ovan.

• Referensproblem; se "Rapporten: Referenser" ovan.

• Syftningsfel, vaga syftningar (oklart exakt vad som menas), stavfel, allmän "luddighet", andra problem med språket rent generellt. Detta kan vara känsligt att diskutera, men man kan gärna peka ut specifika meningar eller områden och ge förbättringsförslag.

• Formatfel, inte använt mallen, felaktiga citeringar, problem med figurer och figurtexter, \ldots

• Sammanblandning av olika avsnitt, t.ex. att börja diskutera resultat under "användning i StarCraft II" eller att delar av problemställningen inte förtydligas förrän under "tekniker och algoritmer".

• Problemställning: Svårt att förstå exakt vilket problem som ska lösas. Målet för problemställningen är att någon som inte har pratat med författaren tidigare ska förstå vilket problem man vill lösa / vad man vill uppnå. Helst ska det vara så tydligt att någon annan skulle kunna ta över arbetet med hjälp av enbart problemställningen och åstadkomma en lösning som varken missar någon viktig del eller inkluderar något som man egentligen inte hade behövt göra. Du bör också koppla till ett konkret exempelscenario där problemet behöver kunna lösas, med inkluderad skärmbild.

• Problemställning: Otydliga indata / utdata. Vilken information förutsätter man att man ska få från andra delar av systemet? Vilken information eller styrning har man tänkt att problemets lösning ska åstadkomma/skapa?

• Utvärderingskriterier: De 4 standardkriterierna måste vara med och måste vara numrerade 1 till 4. Enbart den korta beskrivningen (som var kursiverad i utredningsplanens mall) ska finnas med.

• Utvärderingskriterier: Egna kriterier måste vara så klara och tydliga att det går bra för någon annan att utvärdera enligt kriterierna.

• Tekniker och algoritmer: Otydliga beskrivningar av hur teknikerna fungerar. Kod som parafraseras på svenska (skriv hellre pseudokod, det är mer lättläst).

• Tekniker och algoritmer: Diskussioner kopplade till StarCraft hör inte alls hemma i detta avsnitt. Undantag kan behöva göras om artiklarna helt och hållet beskriver teknikerna i termer av StarCraft-användning, men även i det fallet ska man göra sitt bästa för att dela upp det i generell teknik (här) och StarCraft-applikation (nästa avsnitt).

• Tekniker och algoritmer: Ska finnas numrerad lista med exakt de alternativ man tänker använda (se 3.3 i mallen).

• Tekniker och algoritmer: Se även "Rapporten: innehåll och övergripande struktur".

• Användning i StarCraft II (för det specifika problem man har ställt upp): Otydligt hur man har anpassat/använt de generella teknikerna till det specifika problemet.

• Användning i StarCraft II (för det specifika problem man har ställt upp): Otillräcklig information om modellering. Om man ska söka i en graf, exakt hur ska den grafen i så fall skapas, och var får man den informationen? Om man genererar en väg, exakt vad ska röra sig utefter den vägen? Används en heuristik ska den helst beskrivas med en formel. Körs algoritmen en gång för alla eller upprepas den, kanske flera gånger i sekunden? Varifrån kommer en potential? Och så vidare.

• Användning i StarCraft II: Se även "Rapporten: innehåll och övergripande struktur".

• Utvärdering: Argument där en del av resonemanget saknas; de finns säkert i författarens hjärna, men har inte kommit ut i texten. Avsaknad av motivering. För starka påståenden som underlaget inte motiverar. Ett vanligt problem är att man gärna vill ha en "stark" utvärdering och därför drar alltför starka slutsatser om vilken teknik som är bäst, när detta egentligen inte framgår av den begränsade information man får i underlaget.

• Utvärdering: Alla tekniker måste utvärderas efter alla kriterier. Ibland kan utvärderingen så klart bli att "det går inte att utläsa ur dessa 3 artiklar".

• Utvärdering: Ska inte ge mer information om hur teknikerna och algoritmerna fungerar. Detta ska diskuteras i tidigare avsnitt.

• Utvärdering: Se även "Rapporten: innehåll och övergripande struktur".

• Slutsats: Ska inte utvärdera hur bra en lösning är på något (det ska diskuteras under "utvärdering") utan dra slutsatser om hur detta påverkar det fortsatta arbetet. Se "Rapporten: innehåll och övergripande struktur".

Tisdag 2021-10-12: Överlämning av granskningar inom gruppen

Senast tisdag 2021-10-12 (eller tidigt på morgonen onsdag 2021-10-13) lämnas granskningen över till rapportförfattaren. Därefter kan författaren arbeta vidare med sin rapport.

Du behöver inte lämna granskningen till oss just nu. Den lämnas in tillsammans med din egen rapport (nästa steg).

2021-10-13 till 2021-10-15: Arbete med rapporten

Läsperioden pågår fram till och med fredag 2021-10-15. Det ger lite tid att arbeta vidare med rapporten utifrån kamratgranskningen.

Steg 5: Inlämning, förhandsgranskning

2021-10-17: Första inlämningen av utredningsrapporten

Senast söndag 2021-10-17 lämnar du in din utredningsrapport på (normalt) 4-6 A4-sidor till kursledningen. Rapporten ska vara skriven enligt instruktionerna ovan. Den lämnas in i PDF-format via en issue i Gitlab. Dessa issues kommer att vara konfidentiella och kan enbart ses av inlämnaren + kursledningen. Du ska också göra en separat inlämning till språkgranskning enligt nästa punkt!

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

Du lämnar på samma gång in den granskning som du har skrivit, som en ytterligare bifogad fil, "Granskning-TDDD92-2021-liuid123.???", där liuid123 återigen är ditt LiU-id och där "???" kan vara "pdf" eller "txt" (inga Word-dokument eller liknande). Se till att det syns inuti filen vems dokument du har granskat.

Om du inte är färdig med rapporten går det också att vänta till nästa inlämningsomgång. Då kommer den omgången att bli din förhandsgranskning, och den efterföljande omgången kommer att bli den slutliga granskningen.

2021-10-17 2021-11-14: Även en inlämning till språkgranskning!

Språk- och strukturgranskning är ett separat moment som hanteras av IKOS. D-programmet har sitt moment i TDDE30 medan U-programmet har detta i TDDD92.

IKOS använder sig inte av Gitlab utan går istället via Lisam:s inlämningssystem. Du måste göra en separat inlämning där! Du ska bara lämna in själva rapporten och inte den granskning du har gjort av någon annans rapport.

Som vi har sagt ska du döpa filen till "Utredning-TDDD92-2021-liuid123.pdf", där liuid123 är ditt LiU-id.

Språk- och strukturgranskningen brukar vara noggrann. Det är inte ovanligt att man får komplettering och man kan då inte få poäng i Ladok för den individuella rapporten förrän kompletteringen är genomförd, till nästa inlämningsdeadline. Var noggrann själv om du vill ha poäng och CSN-pengar.

Läs till exempel genom informationen om rapportstruktur en gång till. Kör också rapporten genom en stavningskontroll, och om möjligt en grammatikkontroll. Tänk på tydligheten och undvik syftningsfel, svengelska, med mera.

Vill du ha hjälp med språket? Kanske Språkverkstaden kan ge några tips. De hjälper dock inte till med korrekturläsning. Se även studentsidan om språkstöd.

Är du dyslektisk eller har andra läs- och skrivsvårigheter? Informationen vi har fått är att din rapport ändå måste nå upp till rätt nivå rent språkligt, eftersom detta är just ett språkmoment i kursen (detta bestämmer vi alltså inte själva över). Däremot kan du kanske få mer hjälp från Språkverkstaden och kan be om utförligare kommentarer från IKOS när du gör din inlämning.

Vår förhandsgranskning

Efter inlämningen kommer vi att förhandsgranska din utredningsrapport och ge kommentarer om förbättringsmöjligheter för att hjälpa dig höja ditt betyg och minska risken för komplettering.

Vi spenderar ungefär samma tid på varje rapport och kommenterar så långt som tiden räcker. Med andra ord, ju mer du har arbetat med din rapport vid första inlämningen, desto större chans att vi har möjlighet att skriva specifika kommentarer som hjälper dig att verkligen finputsa rapporten. Ju mindre genomarbetad rapporten är när vi får den, desto större risk att du bara kan få mer generella kommentarer innan tiden tar slut.

Vid den här första inlämningen ger vi inga betygsindikationer utan påpekar bara vad som kan förbättras. Inlämningen ska ses som ett inlärningstillfälle – vi förväntar oss inte att ni ska kunna allt om rapportskrivning i förväg, utan att det behövs återkoppling innan examination.

Detta är ett obligatoriskt steg: Alla rapporter måste förhandsgranskas i ett någorlunda färdigt format innan den slutliga inlämningen. Om du t.ex. blir färdig med rapporten till nästa inlämningstillfälle, vid nyår, kommer vi att göra förhandsgranskningen vid det tillfället och betygsbedömningen efter att du har kunnat polera rapporten.

2021-11-01: Förhandsgranskning tillbaka

Senast 2021-11-01 (efter 2 veckor) hoppas vi att vi kan ge dig din förhandsgranskning tillbaka (i värsta fall kan detta fördröjas av sjukdom eller liknande). Då kan du:

• Arbeta med det vi har kommenterat.
• Skriva vidare på den andra delen av rapporten, som beskriver slutresultatet. Detta kommer att diskuteras på en av projektsidorna.

Resultatet från språkgranskningen bör komma från IKOS inom 2 veckor från det senare inlämningsdatumet.

Steg 6: Slutlig inlämning, granskning, betygsättning

2022-01-xx: Slutlig inlämning

I tentamensperioden i januari 2022 lämnas den slutliga rapporten in. Exakt datum samt mer information kommer.

Betygsättning

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 (inklusive tydliga och motiverade resonemang) och hur väl rapporten är skriven.

Hur tekniskt avancerade tekniker som valts påverkar inte betyget direkt, men i och med att teknikerna behöver 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 i vissa fall kan dröja mer än de vanliga 3 veckorna som gäller för tentor, t.ex. om någon granskare blir sjuk. Alternativet skulle vara en betydligt mindre detaljerad återkoppling till er kursdeltagare!

Plussning och komplettering

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

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.