Speltävling Instruktioner

Speltävling Instruktioner

Section 1: Överblick av utveckling Det här dokumentet är till för er som vill delta i speltävlingen. Dokumentet är uppdelat i två olika delar där den första delen beskriver hur de flesta svenska spelbolag arbetar idag. Den andra delen beskriver vad ni förväntas göra och lite i detalj vad det innebär. 1.1 Process Vilken typ av process man använder sig av när man tar fram och utvecklar spel skiljer sig åt från bolag till bolag. Faktorer som påverkar utvecklingsprocessen kan vara Kontraktsmodell Bolagets nisch Likviditet & ekonomisk styrka Om man tar ett bolag som Blizzard så jobbar de på sina produkter tills de anser att man har nått en nivå på spelet som är superbt. Detta kan leda till att man tvingas jobba väldigt länge och utnyttja en mycket stor mängd resurser. Detta är en lyx som vanliga utvecklare oftast inte har råd med. Därför är man tvingad att begränsa sig betydligt mer och hålla på både budget, tidsramar och storlek av projektet. Tittar man på de svenska spelutvecklarna så kan man se ett mönster på hur man utvecklar spel. Givetvis finns det bolag som jobbar på helt andra sätt, men det ingenjörsmässiga sättet som beskrivs nedan är helt klart vanligast bland de större utvecklarna. Man kan dela upp utvecklingsprocessen i ett antal steg. Modellen nedan visar på ett ungefär hur dessa steg ser ut och vad de heter. Frågar man de stora utvecklarna i Sverige vilka steg som ingår i deras utvecklingsprocess kommer man säkert att få olika många steg varav all med olika namn. Oavsätt vokabulär och vilken detaljnivå man ligger stegmässigt brukar de kunna sammanfattas med figuren nedan. Koncept Design Implementation Test Efterarbete Beta Release Koncept Det är i den första fasen man ser till att få ner en spelidé på papper. Tanken är att när man skall gå vidare till nästa fas skall det finnas ett konceptdokument. Dokumentet behöver inte vara så många sidor men skall ändå återspegla ideen, känslan och unique selling points för spelet. Design I denna fas handlar det om att omvandla konceptet till ett fullskaligt spel på papper. Det innebär att man går in i detalj inom samtliga områden som rör spelet och dokumenterar detta i ett antal designdokument. För att kunna gå vidare till nästa fas skall det finnas designdokument för gamedesign, teknik samt media. Dessutom bör samtliga projektstyrningsdokument finnas på plats.

Implementation När samtliga designdokumenten är klara så börjar man jobba konkret på spelet dvs. man börjar programmera, designa samt göra grafik och dyl. För att gå vidare till nästa fas måste spelet vara klart och nått betastatus men behöver dock inte bugfritt. Test Testfasen är till för att säkra spelet kvalité och balansering. Ofta låter man folk som inte jobbar på bolaget komma och provspela. Anledningen är att man skall försäkra sig om att hela spelet är kul och håller rätt svårighetsgrad. Även betatestning online förekommer ganska ofta då man utvecklar PC-spel. För att gå vidare till nästa fas måste spelet uppfylla de kvalitetskrav man har innan det kan släppas ut på marknaden. Efterarbete Denna fas är den mest abstrakta av alla faser då det ibland kan vara oklart vad som faktiskt är projektrelaterat eller inte. Men vad man kan säga är att patchar är väldefinierad aktivitet som förekommer i denna fas om man gör ett PC-spel. Även lokalisering till andra språk eller portning till annan spelplattform kan räknas in i denna fas. 1.2 Projektuppbyggnad En projekthierarki och uppbyggnad varierar från projekt till projekt och från bolag till bolag. Dock kan man ge en generell bild av hur ett projektteam oftast är uppbyggt. Figuren nedan visar en hierarki för ett godtyckligt projekt. Project manager /Producer External Producer Artist Designer Programmer QA Art team Design team Programmer team QA team Project manager/ Producer Projektledaren ansvarar för hela teamet och för projektet. Hans övergripande ansvar brukar vara att hålla ordning på tid, budet samt kvalitén. Det innebär i praktiken att projektledaren måste hålla ordning på planering, leveranser, milstolpar, resurshantering samt allt annat som påverkar något av de tre övergripande ansvarsbitarna (vilket i teorin är allt som rör projektet).

Vad är då skillnaden mellan en projektledare och producent? Jo, tittar man på hur spelindustrin ser ut så kan man se att oftast har en producent designansvar vilket inte en projektledare har. Annars har de precis samma ans var och befogenheter. Art team I detta team ingår alla artister, De ansvarar oftast för samtliga grafiska objekt, texturer, animationer samt filmsekvenser. Även den eller de personer som jobbar med ljud/musik brukar ingå i detta team. Teamet leds av en Le ad Artist. Hans uppgift är att planera, följa upp samt stödja samtliga medlemmar i teamet. Han är också ansvarig för att det finns ett uppdaterat och komplett Media Design Document (MDD). Oftast brukar man sätta den duktigaste och mest erfarna grafikern som lead. Programmer team (Code team) I detta team ingår samtliga programmerare. De ansvarar för den rent tekniska implementeringen av spelet. Det innefattar bla server, klient, AI, grafikmotor och verktyg. Teamet leds av en Programmer. Hans uppgift är att planera, följa upp samt stödja samtliga medlemmar i teamet. Han är också ansvarig för att det finns ett uppdaterat och komplett Technical Design Document (TDD). Oftast brukar man sätta den duktigaste och mest erfarna programmeraren som lead. I många fall kan det vara bra om den som är lead har ganska djupa kunskaper i 3D (om spelet baseras på en 3D-motor) då just denna del av systemet påverkar resten av produkten. Design team I detta team ingår alla designers. De ansvarar för att ta fram game-play, story, levlar, manualer samt interaktionen mellan spel och användare. Teamet leds av en Game Designer. Hans uppgift är att planera, följa upp samt stödja samtliga medlemmar i teamet. Han är också ansvarig för att det finns ett uppdaterat och komplett Game Design Document (GDD). Oftast brukar man sätta den duktigaste och mest erfarna designern som lead. QA team Detta team är lite speciellt. Väldigt ofta så är QA (Quality Assurance) teamet inte ett fullvärdigt team i projektet under den första delen av projektet. Detta beror på att man ofta inte kan/vill ha den typen av testning i den omfattningen under så tidigt stadium av produktionen då det kan ställa till med mer besvär än nytta. QA teamet brukar i allmänhet kallas in någon gång innan man når beta och går då in och kör stenhårt under en kortare period för att sedan hoppa vidare till nästa spel. QA teamet leds av en QA. Hans uppgift är att planera, följa upp samt stödja teamet och alla delar av testverksamheten som rör spelet som helhet. External Producer Denna filur representerar beställaren. Det innebär i praktiken att det är det interfacet man har mot förläggaren och den person som är kravställare. Oftast är de externa producenterna mycket duktiga då de har jobbat länge i branschen. De måste ha stor kunskap om allt som rör både utveckling, konkurrerande produkter, slutkundkännedom samt vara ett proffs på att pressa en utvecklare till dennes absolut yttersta förmåga.

Section 2: Uppgift Uppgiften under speltävlingen består av att antingen göra ett mindre projekt i form av ett demo eller en prototyp. Skillnaden mellan demo och prototyp är att ett demos syfte ofta är att visa upp något (t.ex. för kundgruppen eller förläggaren) medan en prototyp ofta görs för att undersöka och testa olika komponenter för ett spel. 2.1 Demo vs prototyp Nedan beskrivs vad vi förväntar oss av respektive val. Oavsätt vad man väljer att göra så gäller det att visa att just ni har ett koncept som är värt att satsa på. Demo Vi vill se ett demo som består av en tutorial dvs. en inledningsband som guidar användaren hur spelet fungerar och där man kan prova spelets alla viktiga delar. Meningen är alltså att man ska lära spelaren att utnyttja funktionaliteten i spelet. I en tutorial så behöver inte alla funktioner fungera samtidigt eller i fullskalig proportion. Ett exempel på en kul tutorial är agentspelet Jims Bond 006. =D. I den tutorialen skulle man kunna tänka sig att man går runt på en bana och blir introducerad till alla balla tekniska prylar som Z har kommit fram till. När man kommer fram till skyttebanan kanske man får testa på att skjuta på pappfigurer. Det som är viktigt med en tutorial är att den är självförklarande och att man inte kan göra några fatala fel som spelare så att man inte kan gå vidare i demot. Ett exempel på detta skulle kunna vara att man i demot skall träffa samtliga pappfigurer med minst ett skott vardera med pistolen. Men missar man alla skott så står man där som ett mähä och kommer inte vidare. Place holders skall inte användas i tutorials. Med place holders menas temporära grafiska figurer, filmer eller röster. I ett icke-komplett bilspel kan dessa vara boxar som ska representera andra bilar som tävlar mot en. Tanken är att tutorialuppdraget skall vara komplett som det ser ut när man tittar på de tutorials som man får med t.ex PC-gamer. Prototyp Vi vill att prototypen är en fullt spelbar bana med de absolut mest grundläggande funktionerna, men ju mer funktioner som finns ju bättre. Vilka dessa funktioner är beror på spelet. Men för ett First Person Shooter spel kan dessa vara att kunna skjuta, hoppa, strafa, ducka m.m. Det är viktigt att det går att både lyckas och misslyckas med det man skall göra på banan. Om man skall rädda den lilla söta blonda flickan från Hajen så måste man kunna göra det också, fast likväl måste Hajen kunna knocka en själv. Banan skall vara begränsad så att man hela tiden har allt inom godtagbart räckhåll. Med det menas att det inte är någon idé att simulera hela Moskva när det bara finns två karaktärer i stan. Det kan liksom bli lite långtråkigt. En prototyp behöver inte vara lika självförklarande som en tutorial. Ibland är prototypen till för att visa POC (Proof Of Concept) och då vill man kanske bara att karaktären man spelar vaknar upp i ett garage och inte vet något. En del av konceptet kan vara att bara skapa stämning och ge spelaren en ledtråd till vad han skall göra. Dock är det ett krav att man kan välja alternativet inställningar i prototypen för att kunna se vilka kontroller som används. Användaren ska alltså inte behöva prova sig fram på tangentbordet. Place holders är acceptabla under förutsättning att det inte är miljön eller känslan som är det primära att visa med prototypen utan t.ex. AI eller fysik.

2.2 Dokumentation Under utvecklingen av ett projekt tar man fram en hel del viktiga dokument. Några av de viktigaste dokumenten har diskuterats ovan. Dock så gäller det att visa att man inte bara kan hacka kod utan att man även tänker till när man skall göra ett mångmiljonprojekt. Annars riskerar man att måla in sig i ett hörn innan spelet blir klart. Ett bra exempel på detta är ett strategispel som utvecklades av en svensk utvecklare för några år sedan. Man gjorde visserligen några av de grundläggande dokumenten i början av projektet, men under tidens gång så förändrades hela konceptet (och man orkade inte uppdatera dokumenten). Helt plötsligt stod man där med ett strategispel som man inte kunde trycka på save mitt inne i spelet. Den externa producenten krävde att denna funktion skulle in då det är en funktion som slutkunderna kräver. Tyvärr hade man designat mycket on the fly utan att dokumentera och tänka till innan. Så i slutänden blev det omöjligt att implementera funktionen. Därför anser vi att det är av stor vikt att de två viktigaste dokumenten tas fram och används under utvecklingen av demot/prototypen. Game Design Document (GDD) Beskriver allt game-play i spelet. Det inkluderar alla features som t.ex. spelaren kan öppna dörrar genom att trycka på use-knappen. Även storyn, röda tråden av spelet samt all annan interaktion som spelaren kan göra med sin karaktär. Man beskriver dessutom eventuella filmsnuttar. Kort och gått kan man säga att ALLT som finns med i spelet skall finnas beskrivet i GDD. Technical Design Dokument (TDD) Är baserad på GDD och beskriver hur spelet kommer att se ut under huven. Klass och objektdiagram är att rekommendera, samt att alla features har ett motsvarande beskrivande stycke i TDDn. Båda dessa dokument bör vara uppbyggda som kravspecifikationer, dvs. enkla och lättförståeliga beskrivningar av vad man skall göra. Anledningen är att man under utvecklingen kommer att ändra features och dyl. och då vill man på ett enkelt sätt kunna uppdatera de båda dokumenten. En annan fördel är att man minskar kommunikationsproblemen mellan teamets medlemmar.

Section 3: Sammanfattning Vi förväntar oss inte guld och gröna skogar vi förväntar oss inte ett nytt Diablo. Vad vi förväntar oss där emot är att ni visar att ni tänker till, att ni vill samt att ni har något riktigt mysigt på gång. För att uppfylla era åtaganden så bör ni alltså leverera det nedanstående. Om det står och väger mellan två lag vad beträffar deras respektive demo kommer juryn att avgöra på hur strukturerat de arbetat som team genom att titta på deras GDD och TDD. Ett körbart demo alt prototyp (ni väljer själva speltyp samt 2D eller 3D). GDD TDD Källkod (så vi kan bekräfta att ni verkligen har följt TDD) För att få lite tips och hjälp kan ni utnyttja några följande sajter www.gamasutra.com http://msdn.microsoft.com/community/directx.asp