Nivå och poängvärde: | C 200 |
---|---|
Kort beskrivning: | Vi skapar ett eget textäventyr. |
Vad vi lär oss: | Självständig planering av ett eget program, samt allting som ni vill lära er eller som ni behöv för att förverkliga ert spel. |
Frihet i implementationen: | Väldigt hög. I princip allting går att ändra på i denna uppgift. |
Realism: | Hög. Här får man både planera, koda och testa. |
Utmaning: | Svår. Det är svårt för en nybörjare att planera och implementera ett eget program, även om kursen erbjuder "stödhjul" för att komma igång. |
Arbetsmängd: | Det här är kursens mest tidskrävande uppgift. Det lönar sig att reservera minst 10h för projektet, och helst 15h. Blir du riktigt inspirerad får du givetvis använda hur mycket tid som helst, bara spelet lämnas in före deadlinen. |
Skapa ett helt eget spel utgående från Adventure-projektet. Glöm alltså allting om skogar, fjärrkontroller, batterier osv. och gör ett helt nytt spel. Spelet kan handla om precis vad som helst, var kreativa! Här är ett par idéer som grund för planerandet, men en egen idé är alldeles lika bra, om inte bättre.
Ni kan använda engelska, svenska eller finska som spelets språk.
Spelet bör innehålla:
forest_map.gif
). Den här kartan bör vara i GIF- eller PDF-format eller (i brist på bättre) som vanlig ASCII-grafik. Namnge filen map.xxx
, där xxx är rätt ändelse beroende på filformatet. Placera filen i projektets mapp.
walkthough.txt
(eller .pdf
eller .gif
). Guiden måste beskriva steg för steg vad spelaren bör göra för att klara spelet. Guiden kan vara på engelska, svenska eller finska. Kursassistenten använder (kanske) guiden för att komma igenom spelet. En mindre frustrerad assistent ger kanske bättre vitsord. :-)
Använd det givna Adventure-projektet som grund för spelet. Ni kommer att vara tvungna att redigera klasserna, speciellt klassen Adventure
behöver en total ombyggnad.
Obs: det är önskvärt att ert spel fungerar tillsammans med båda användargränssnitten. Undvik att ändra på de givna användargränssnittena. (Om det finns en bra orsak att göra ändringar är det tillåtet, men då bör projektet också innehålla en textfil UI_CHANGES.TXT
, där det står vilka ändringar ni gjort och varför.)
Alla sorts tillägg till spelet är välkomna: nya riktningar att gå, nya fortskaffningsmedel, nya spelaregenskaper, en viktbegränsning på hur många föremål man kan bära, kommandon bestående av flera ord mm.
Ha roligt!
Notera att det här är en arbetsdryg uppgift. Det lönar sig alltså att begränsa sin arbetstid till det som kursen förutsätter och jobba så att man implementerar en idé åt gången. På det här sättet får ni ett spel som kan lämnas in lite när som helst utan att kännas halvfärdigt. Förra året hade eleverna anmält att de jobbat ungefär så mycket som rekommenderat, men en del hade använt långt mer än 20h, vilket redan går över till att man kodar på sin egen fritid, av eget intresse.
Det lönar sig att planera lite i förväg vad och hur man gör saker förrän man börjar skriva kod. På det viset sparar man en timme eller mera. Säkerhetskopior eller versionskontroll är också otroligt bra att ha.
I den här uppgiften bör man lämna in hela projektet i Rubyric som ett enda zip-paket.. Instruktioner för hur man gör detta finns i kursens Eclipse-guide.
Klicka på den här lådan för att komma till Rubyric-inlämningssystemet. Välj det högra inloggningsalternativet, som använder samma system som Oodi och Noppa.
Vid inlämningen frågas det om gruppmedlemmar. Ifall du gjorde uppgiften själv, lämna den andra gruppmedlemmens fält tomt.
Rubyric bedömer dock inte den här uppgiften, det gör kursens assistent. Om ert spel i stort sett uppfyller kraven ovan, kan ni anta att ni får åtminstone hälften av uppgiftens poäng. Extra poäng delas ut efter assistentens tycke. Pluspoäng ges för ett bra tekniskt utförande, kvalitet och komplexitet. Dessutom får man poäng för intressanta och/eller roliga detaljer och idéer. Spelet behöver dock inte vara en otrolig underhållningsöverdos för att man ska få fulla poäng. Det räcker med ett program av god kvalitet som uppfyller kraven.
Notera att spelets storlek inte inverkar så mycket på poängen. Även om spelet skulle innehålla tiotals områden, får man inte poäng om det inte gör spelet intressant. På samma sätt kan ett litet men roligt och välfungerande spel få fulla poäng.
Eftersom spelet kommer att spelas av vad som kan kallas för en riktig person, får ni inte glömma help-kommandot eller walkthrough-filen. Var också noga med att spelet fungerar förståeligt. Om spelet innehåller en bugg, som gör att när man skriver "go north" transporteras till andra ända av spelvärlden utan förklaring, blir det jobbigt att spela och bedöma.
Vi strävar till att bedöma projektet senast två veckor efter deadlinen.
;-P
Den här uppgiften är väldigt olik många andra uppgifter på den här kursen, eftersom studerandena har en väldigt stor frihet att implementera saker. Uppgiften är tämligen löst definierad och målet är inte att lära sig någon viss programmeringsteknik. Uppgiften bedöms inte av en maskin utan av en människa.
Av tidigare erfarenhet är det troligt att många kommer att tycka att den här uppgiften är väldigt intressant och inspirerande, en av kursens bästa. En del av er kommer att uppleva de fria tyglarna som befriande och att fantasin får vandra fritt. Dessutom kommer många av er att märka att trots avsaknaden av särskilda pedagogiska mål så är uppgiften mycket tekniskt lärorik eftersom man måste tänka i stora helheter, på samband mellan klasser och på den allmänna planeringen.
Däremot kommer en del antagligen att bli irriterade på uppgiftens diffusa och icke-tekniska natur. Kursen borde ju lära en programmeringsteknik! Jämfört med Goblin är den relativt långsamma bedömningen säkerligen också frustrerande.
Trots avvikande åsikter, tror vi att den här uppgiften erbjuder någonting åt alla som är intresserade av programmeringens grunder. Den fria uppgiftsformen ger en möjlighet att välja vad man själv vill göra och är intresserad av. Det lönar sig att utmana sig själv på ett eller annat sätt. Man kan fokusera på att skapa ett roligt spel (och på samma gång kanske lära sig någonting om programmering). Å andra sidan kan man satsa mera på den tekniska delen och lära sig använda någon viss programmeringsteknik, utan att bry sig så mycket om hur roligt spelet är. (En sidonotering för de kursdeltagare som redan kan programmera: om kursen inte känns tillräckligt utmanande, kan ni i denna uppgift på egen hand läsa om någonting mera avancerat -- t.ex. designmönster (design patterns) -- och försöka använda det i spelet.)