This is a non-official cite and currently contains information only relevant to my bachelor students.


Allmän info

  • Fackspråks hemsida: http://www.ait.gu.se/facksprak/kandidatarbete/
  • Den skriftliga opponeringen skall vara individuell och bedöms individuellt.
  • Egenutvärdering

  • Ansträng er för att göra en god och rättvis bedömning. En tendens(med flera undantag dock) har varit att de elever som känner att de bidragit mindre till gruppens arbete sätter samma belopp för alla.
  • Inkludera er själva i bedömningen.
  • Överskattar man sin egen insats syns detta tydligt jämfört med kamraternas bedömning av en själv.

    Rapporten

    Krav på vetenskaplighet
    En definition av vetenskaplighet kan vara: "framtagandet av nya fakta med en vetenskaplig metodik som säkerställer resultatens riktighet". Vid forskning används vetenskaplig metodik. Gränsen mellan utredning, utveckling och forskning är emellertid inte skarp. Vissa krav på vetenskaplighet ställs dock på ett examensarbete.


    Allmän Information

    En vetenskaplig skall bidraga med ökad kunskapsmassa till mänskligheten, och rapporten skall vara utformad därefter. Det är viktigt att rapporten inte i första hand blir ett dokument som fokuserar på just vad gruppen gjort,dag för dag, utan blir ett dokument som beskriver projektets frågeställning, tidigare forskning/lösningar, vilka problem som finns, vilka avvägningar/trade-offs som föreligger, vilken metod gruppen valt och varför ni gjort just de val som gjorts, samt vilka slutsatser man kan dra från arbetet (dvs resultaten)
    En vetenskaplig rapport skiljer sig därmed från en teknisk rapport. Tyndpunkten i er vetenskapliga rapport är inte er beskrivning av vad som utförts i projektet utan skall istället vara ett vetenskapligt dokument över vad man kan lära sig från arbetet och ska leda fram till era slutsatser. Slutsatserna är det mest intressanta.

    Disposition

    Förslag på disposition för rapporten. Rapporten skrivs förslagsvis på engelska:
    1.   Title page
    2.   Abstract. Sammanfattningen skall innehålla Frågeställning, eventuellt Metodik samt Resultat
    3.   Table of Contents
    4.   Introduction, med bakgrund, problem, syfte, begränsningar, samt outline över rapporten. Frågeställning och metodik ingår ofta i dessa delar.
      • Background
      • Purpose
      • T ex. The purpose of this thesis work is to create a rally game with focus on graphics effects...
      • Problem
      • Här listar ni alla frågeställningar (=problem statements) och eventuellt subfrågeställningar. Det är ofta naturligt att listan mer eller mindre direkt svarar mot kapitelstrukturen i huvuddelen av rapporten. T ex Graphics -> vilket library/API skall man välja? Vilka algoritmer ska man välja för skuggor, motion blur, reflektioner, partikelsystem etc etc? Vilken trade-off mellan kvalitet och hastighet är lagom? Samma gäller för Audio (vilket lib/API, vilka sorts ljud, 2D/3D), Network (lib, client/server-modell?, latency, consistency), AI, Physics... Det ni skriver under Result i respektive avsnitt skall då representera svaret på den (sub)frågeställning ni har listat här.
        Detta avsnittet skapar alltså den naturliga röda tråden i er rapport. Beroende på hur uppenbar den röda tråden och strukturen här framkommer kan ni välja att ha med outline (nedan) eller ej. Se till att det ni skriver som frågeställningar här och det ni svarar på i Result-avsnitten stämmer överens. Detta är mycket viktigt, då existensberättigandet av varje textrad i er rapport bygger på att de svarar på frågeställningarna eller behövs för att läsaren ska förstå era svar (dvs resultat).
        Som hjälp att formulera frågeställningen kan ni tänka på följande:
        • Vad kommer ni ha för (typ/sorts av) resultat?
        • Vad är ny kunskap som rapporten ger?
        • Vad kan läsaren lära sig?
        • Detta utgör er contribution, vilket skall svara på er frågeställning. D vs från detta kan ni återkonstruera er faktiska frågeställning som er rapport har.
      • Limitations
      • Detta är främst valda begränsningar i er undersökning. Vi har valt att begränsa studien till... (t ex att omfatta grafik men inte game play) och inte undersöka detta...
      • (Method)
      • (Outline)
      • Här är ett utmärkt ställe att förklara strukturen och därmed den röda tråden i er rapport. Läsaren skall hela tiden (om han läser sekventiellt från början till slutet) kunna ha koll på relevansen om det han läser samt den röda tråden om vad som kommer härnäst. Inget (sub)kapitel eller nytt ämne skall komma som en överraskning.
    5. Scientific main part (Theory / System)
      Här kommer huvuddelen av er rapport. Det kan t ex vara uppdelat i subkategorier.
      OBS Det är lämpligt att förklara för läsaren relevansen med varje avsnitt. Därmed förenklar man för läsaren att förstå och hålla reda på den röda tråden i rapporten och bli påmind om den. Ett sätt att åstadkomma detta är i respektive avsnitt göra följande:
      1. Tala om vad ni ska säga (motivera varför), dvs vad avsnittet kommer handla om och hur det har relevans.
      2. Därefter säger ni det ni vill ha sagt.
      3. Avsluta med att säga vad ni har sagt. Dvs upprepa/sammanfatta. Detta får ni använda med förnuft - dvs där det verkar vettigt. T ex kan det vara rimligt i slutet av de flesta större avsnitt - men troligen inte för varje underavsnitt.

      KAPITEL-/SUBKAPITELINLEDNING
      Det måste finnas text mellan ett kapitel och subkapitel. Samma gäller subkapitel och subsubkapitel, etc. Om inte annat, så förklarar man vad kapitlet kommer handla om. Mer specifikt:
      • Förklara vad kapitlet kommer att gå igenom på hög nivå - dvs på en abstraktionsnivå som motsvarar subkapitlens namn.
      • Förklara varför kapitlet är relevant
      • koppla det gärna till frågeställningarna (om möjligt).
      • Ofta vill man övergripande nämna motsvarande resultat.

      Det är ingen som direkt kan ha synpunkter på ert val av innehåll i rapporten. Däremot kan alla ha synpunkter på hur väl ni motiverar innehållet. Det brukar typiskt räcka med lite meningar här och var instoppade i början av kapitel/subkapitel för att ge läsaren den röda tråden och förklara varför ni skriver om det ni skriver (dvs motivera textens relevans i relation till ert ämne och nödvändiga bakgrundskunskaper för att förstå resultaten/svaren på era frågeställningar).

      Här är bra exempel:
      "This section will first cover the most common filters for image analysis, followed by a brief evaluation from which we found the Canny filter to best suit our needs."
      Eller:
      "One of the most fundamental operations in a ray tracer is the intersection tests between rays and geometry. This is used for almost every effect that the ray tracer uses, e.g., reflection or refraction rays, shadow casting, and photon mapping. Thus, this section will describe one of the most common and efficient methods for ray/triangle intersection. "
      Eller:
      In this section, we will first discuss various methods for creating virtual lighting for a 3D scene. We will then describe the implementation of the lighting in our game.
      Eller:
      Multiplayer requires a functioning network that allows for players to receive information about other players and deliver information back to them. This chapter will present common methods, problems and decisions that a game developer will need to take into consideration when implementing a game with multiplayer functionality.


      En vanlig struktur är att t ex använda följande kategorier som kapitel (eller vad som passar ert arbete):
      • Graphics
        • Previous Work. Här skall du kortfattat beskriva och referera till tidigare relevant forskning/kunskap. Detta är ofta den viktigaste delen, där du sätter in ditt arbete i ett kontext. D v s förklarar vad som är nytt resp vad som redan är känt, vad som är otillräckligt med tidigare metoder, Vad som är bättre med er metod, varför er undersökning/algoritm är relevant etc. Du skall få läsaren att förstå vad som är nytt resp vad som redan gjorts samt hur bra din metod/undersökning är jämfört med tidigare. Se även References nedan. Se även framförallt Trattmodellen nedan.
        • Analys, metodbeskrivningar. Detta utgör vanligen huvuddelen av kapitlet.

        • För kandidatarbeten är det vanligt att man slår ihop Previous Work och Analysdelen. Ni beskriver, inkl för- och nackdelar, de olika kända algoritmalternativ man kan välja mellan att använda sig av. Utefter detta motiverar man sitt val av algoritm. I resultatdelen (nedan) utvärderar man resultatet av sin implementation och visar screenshots på slutresultat. Ofta visar man även screenshots som illustrerar trade-offs eller kanske resultatet för alternativa algoritmer (t ex med och utan Bloom-filter, med/utan olika approximationer).

          TRATTMODELLEN
          Ofta används en trattmodell allra först vid mer eller mindre varje subkapitel för att förklara valet av algoritm/metod/ teknik/API som gjorts i projektet och som subkapitlet kommer att handla om. Man börjar med att nämna (helst) alla alternativ som finns, inkl. deras för- resp. nackdelar och landar därigenom i ett logiskt val av en eller ett par alternativ.

          Ofta kan dock vara opraktiskt att gå igenom alla alternativ, då de kan vara väldigt många. Istället nämner man då vilka övergripande klasser som finns - t ex offline-metoder [2-3 referenser] respektive realtidsmetoder [2-3 ref]. Därefter förklarar man vilken/vilka klasser som är relevanta för er och varför. Därefter sållar man på samma sätt mellan de specifika alternativen inom kvarvarande klass(er), genom att förklara för-/nackdelar utifrån vilka parametrar/egenskaper som är viktiga för ert kontext (dvs projekt). Kvarstår ett par likvärdiga alternativ får man helt enkelt berätta detta och säga att "vi valde metod X".


          Här är ett exempel på en kortfattad trattmodel för environment maps, som börjar med vilka reflektionsalgoritmer som finns och landar i det specifika valet av environment mapping:

          The most general and accurate way to compute reflections is to use ray tracing or cone tracing [ref, ref, Real-Time Rendering, 2008]. However, due to being highly computationally intensive, this is typically only feasible for offline rendering [gärna referens till något papper om real-time ray tracing]. For real-time rendering, environment mapping [Blinn&Nevell 1976] is the dominating class of techniques [helst referens som stödjer detta, men hittar man inte det så låt det passera utan referens]. Two such methods are sphere mapping [ref] and cube mapping [Greene 1986]. (Helst skulle man även nämna paraboloid- och tetrahedral mapping för att försöka vara heltäckande.)

          Om man istället skulle skriva "En teknik är denna...", "En annan teknik är denna...", så vet inte läsaren om det finns 3-4 till tekniker som man inte valt att beskriva, eller hur de relaterar till området. Genom trattmodellen ger man läsaren en bättre känsla av att få koll på och överblick över området och alternativen.
        • Results. Här skall ni beskriva era resultat och slutsatser, utifrån den(de) subfrågeställning(ar) ni har kommit fram till. T ex om era valda metoder fungerade bra, för-/nackdelar. Observera att era svar (=resultat) skall matcha mot era frågeställningar.

          Ha mycket bilder. Gör inget om ni har så mycket som en bild per sida. Alla bilder skall vara era egna bilder (undantag kan vara t ex om ni ska visa Mona Lisa el dyl, för det är svårt att replikera själv. Men även screenshots från andra spel skall ni ta själva och inte kopiera). Ha mycket och gärna screenshots. Jag brukar säga att om ett antal år är det endast er rapport som finns kvar av projektet. Och screenshots blir då mycket värdefullt för att få en känsla över hur projektet var. Låt dem illustrera det som ni pratar om i de olika avsnitten. Ni kan göra bilderna små och gruppera ihop dem, om det blir svårt att få plats med dem.
        • Discussion - Här har man tillåtelse att spekulera, diskutera vad som kunde gjorts annorlunda, vad man velat testa i mån av tid etc. Detta är i princip enda avsnitt där alla icke-triviala påståenden inte behöver styrkas med referens eller ur de egna resultaten.
        • (Conclusions)
        • (Future Work)
      • Physics
      • Audio
      • Network
      • AI
        etc.
    6. Results - på en högre abstraktionsnivå än ovan, dvs resultat för hela rapporten
    7. Discussion
    8. Conclusions
      Är en längre sammanfattning av ert arbete än Abstract. "We have performed/presented a study on...". Frågeställning(ar), metodik och övergripande resultat skall framgå.
    9. (Future Work)
    10. Etik - kort stycke. Högskoleverket kräver diskussion kring etiska frågor.
    11. References. Tillsammans med Previous Work är detta sannolikt det viktigaste avsnittet. Det är genom att ha korrekta referenser och sätta sitt arbete i relation till alla de mest relevanta referenserna som man visar läsaren att man har stenkoll på sitt område. Man visar tydligt hur ens arbete kompletterar och utökar tidigare kunskaper. Läsaren kan värdera ens arbete.

      Det är rimligt att ni har någonstans mellan 30-100 referenser. Troligen är 50-60 st lämpligt. Absolut ej mindre än 30 st. Har en rapport få referenser, så indikerar det att man inte gjort sina trattar ordentligt. D vs man har inte givit läsaren en ordentlig överblick och koppling till existerande arbete/metoder el dyl. En enda tratt kan ju lätt skapa 5-10 referenser. Försök främst använda vetenskapliga referenser. Mer än två tredjedelar är mycket bra. Färre än en tredjedel indikerar normalt en svag/dålig koppling till vetenskapligt arbete.
    12. Appendix - valfritt.



    Page updated by: Ulf Assarsson
    Updated 2014-01-14