Post Mortem för Get The Treasure!

Post Mortem för Get The Treasure! Av: Emil Lindberg - Grupp 15 Vi skulle göra ett action multiplayerspel som spelades över nätverket. Vilket vi nästan lyckades göra. Tiden tog slut och programmerarna han inte göra klart gameplayet. Vi var fyra grafiker, två programmerare och en som var hybrid av båda. Jag var Lead Programmer för projektet. Största utmaningen var att få Get The Treasure! att fungera över nätverk vilket tog den mesta av tiden för oss programmerare. Vi gjorde en del missar tidigt i stadiet som påverkade projektet i slutet av utvecklingen. Detta postmortem kommer fokusera på vad som gick fel med programmeringen/ skriptningen men också vad som gick bra. Den kommer även ta upp annat som påverkade programmeringen. Vad gick Bra Skippa SmartFoxServer DSV har en serverdator som kör SmartFoxServer (SFS) vilket studenter kan använda. Vi blev intresserade av detta och satte oss in för att lära oss SFS. Jag fick igång ett enkelt spel där man spelade Tic Tac Toe i Unity över nätverk med hjälp av SFS utan några problem alls. Med

SFS måste man koda gameplayet som extensions till SFS, alltså utanför Unity. Detta gör att man inte direkt kan använda sig av Unitys API. Att göra Tic Tac Toe var inga problem då jag inte behövde något från Unity. Allt som behövdes var en matris och ett par if -satser. Det som fick oss att slänga SFS var huvudsakligen tre saker, Fysiken, Dokumentationen och Debug. Vi insåg att fysiken för GTT skulle bli för tidskrävande då alla kollisioner måste detekteras på server sidan (i exstensionet) och allt annat som fysiken innebar (Visserligen skulle vi kunna låta unity simulera fysiken på klientsidan men vi ville göra det server side för att motverka eventuell fusk). Alternativt så hade vi gjort två olika typer av Unitybuilds, en som agerar server och en som agerar klient. Detta kändes dock för onödigt. Dokumentationen och kommunityt för Unity med SFS var för litet. Fanns en enkel tutorial och en enkel dokumentation som beskrev hur man sätter upp en server för unity. Inga exempel på hur man skulle gå till väga när man kodade i unity vilket gjorde oss väldigt osäkra. Fanns inte heller något större kommunity där man kunde fråga om hjälp. Debugen var inte heller så bra. När SFS används så kringgår man Unitys stöd för Nätverk vilket betyder att vi inte kunde ta del av Unitys debuginformation för nätverk. Man vart även tvungen att koda i två olika miljöer vilket gjorde allt jobbigare och mer komplicerat. Vi beslöt oss för att slänga SFS och istället använda Unitys inbyggda Nätverk. Vilket gjorde det mycket enklare för oss. Fler exempel, starkare kommunity, starkare dokumentation, mycket guider kring hur man skulle gå till väga o.s.v. Plugga Unity Nätverk När vi bytte till Unity Nätverk så la vi ner ett par dagar att lära oss det. Vi köpte en Unity nätverks tutorial från det nederlänska företaget M2H Game Studio. Tutorialen bestod av en grundkurs i Unity Nätverk samt flera spelbara projekt som användes av Unitys Nätverk varav ett bar var rätt avancerade. Jag la ner ett par dagar på att gå igenom projekten och lärde mig en hel del och kunde förbereda för nätverksproblem som jag visste skulle kunna uppstå. Byta från JavaScript till C# Vi skriptade till en början i JavaScript. Mest för att vi har tidigare gjort spel i Unity och då använt oss av JavaScript. 20% in i projektet upptäckte jag att kommunityt ofta rekommenderade C# framför JavaScript. C# skulle vara mer optimerat och snabbare att utveckla i. Jag hade ingen erfarenhet av C# men gjorde ett försökt att skapa en klass i C#. Det var lite meckigt i början men efter någon dag fick jag mer flyt i C#. Däremot såg jag fördelarna direkt. Istället för att använda Notepad++ kunde vi byta till Visual Studio, man fick tillgång till intelisense vilket gjorde att det gick minst 3x snabbare att skriva en klass i C# än i JavaScript. Man kunde även enkelt testkompilera koden direkt i Visual Studio istället för att behöva kompilera i Unity. C# är mer kontrollerat än JavaScript, flera gånger kändes det som att kod skiven i JavaScript verkligen inte

borde fungera, men det gjorde det ändå. Skapade oftast förvirring. Det slutade med att alla bytta till C# och vi fick skriva om all gamla JavaScript-filer till C# vilket helt klart var värt. Större exempelprojekt var även skrivna i C# vilket gjorde det enklare för oss att analysera dessa. Designmöten När vi skrev vårt GDD hade vi ett par designmöten. Vi brainstormade och kom på flera idéer och vi skrotade flera idéer med. Vi gick från ett fps-skräckspel till GetTheTreasure!. Alla fick leka designer under alla möten och ingen fick komma med negativ kritik under brainstormingen. Vi fick rätt flummiga, roliga och bra idéer tack vare detta som vi annars troligt inte skulle ha fått. Vad gick Dåligt Kodade bara client side Vi visste att en client-server lösning skulle vara det optimalaste för att hindra spelare från fuska. Dock tänkte vi att detta skulle ta för lång tid. Istället valde vi att det mesta skulle ligga på klienterna. Att varje klient hade koll på sina egna liv och vart de befanns sig på leveln etc. Vi trodde att det skulle gå snabbare att koda så här än att lagra allt på servern. Vi hade delvis rätt, den första månaden gick allt bra men efter det blev snabbt rörigt och bökigt. Ju mer jag använde nätverket och läste på om det ju mer tänkte jag i server-client anda. Men eftersom vi hade allt på client så blev allt väldigt mycket bökigare. Den dum miss, något vi trodde skulle bli enklare blev svårare. Vi bytta aldrig heller till client-server utan fortsatte på spelet. Skulle jag fortsätta idag skulle jag nog skriva om allt till client-server vilket skulle ta ett bra tag, men det skulle annars vara omöjligt att fortsätta enligt mig. Kodade för singleplayer Samtidigt som vi tittade på SmartFoxServer och innan vi började studera Unitys inbyggda nätverk så tänkte jag att jag kunde programmera vissa klasser innan jag lärde mig nätverk. Tänkte att kodningen inte skulle skilja sig så mycket från singleplayer och jag trodde att jag skulle kunna lista ut vilka extra variabler som behövdes för nätverk. Visade sig senare efter jag gått igenom Unitys nätverk att jag hade fel. Fick skriva om de flesta klasser jag redan gjort vilket tog onödigt med tid. Skulle istället bara ha skissat klasserna eller ritat uml diagram tills jag visste hur nätverket fungerade. För flexibel kod Jag försökte skripta så att man enkelt skulle kunna utöka skripten och enkelt skulle kunna använda skriptet till andra scenarion som inte hade bestämt än. T.ex. gjorde jag en enorm

parentclass till fällorna som hade ett flertal inställningsbara variabler som inte användes till en början. Nu han vi inte göra fler fällor än en så detta kom aldrig till användning. Man skulle kunna säga att detta var ett dåligt beslut för ett litet projekt då det tog så mycket tid att skapa flexibel kod men det hade garanterat varit bra om vi hade haft mer tid på oss. Istället skulle jag struntat i att göra koden så flexibel och bara göra det som behövdes. Hade sparat mycket tid på detta. SVN Vi skaffade en SVN nästan direkt som var placerad skolans server. Jag använde SVN hela tiden till en början. Vi visste att SVN inte var så oplimalt för Unity. Vi var själva tvugna att zippa ner olika filer innan vi checkde in projektet vilket var rätt jobbigt, men bättre än inget. Slutade dock med att vi aldrig orkade checka in projektet och folk kunde ringa runt till varandra och fråga vad man har gjort sen senaste projektet, vilket fungerade rätt bra ändå. Vi mergade ihop projekten någong gång per vecka som vi sedan checkade ut på SVN. Dock gjorde detta att vi aldrig hade någon backup. Vid en mergning av mitt projekt och en annans projekt blev jag av med en classfil. Hade inte gjort någon egen backup av detta och jag förlorade ett par dagar.

SCRUM Till en början hade vi sprintar och sprintmöten, tror vi kom upp till ca 4 sprintar. Dock hann vi aldrig ta en sprint innan deadline utan vi arbetade på den förra sprinten under nästa sprint med. Vi kom längre och längre bort från deadlinen ju fler sprintar vi gjorde och de sista veckorna struntade vi helt i sprintar. Det blev lite mer oorganiserat, b.la. så glömde jag bort att göra vissa viktiga saker för att vi skulle få ett bra gameplay till slutdeadlinen (Komplett meleesystem samt respawnsystem). Inga Designers Vi hade ingen som var dedikerad designer. Istället var samtliga designers. Det gick hyfsat bra i början när vi tog fram vår grundläggande idé. Men när det gällde småsaker så hade vi oftast olika tankar vilket gjorde att man var tvungen att fråga alla i gruppen om vi kunde ta bort liten del av designen. Hade vi haft en designer eller två designers som bestämde allt hade det varit mycket enklare. Slutsats Vårt projekt gick hyfsat bra ändå. Det föll på skriptningen/programmeringen men gick framåt med grafiken. Undantag mocapanimationenerna som gick åt skogen, men det fixade vår animatör snyggt under en helg med att göra om alla animationer från scratch. Vi hade behövt bättre disciplin på att följa SCRUM. Samtliga var mest anti scrum och folk glömde uppdatera sina scrumloggar. Hade vi tagit varje sprint-deadline seriöst så hade vi hunnit mycket mer än vad vi gjorde.

Att nätverket ställde till mycket var rätt givet. Vi visste innan att nätverk gör allt svårare och jag hade fått varningar från flera personer som tyckte att vi skulle skippa nätverk. Men vi ville göra nätverkspel och jag ville ha en ny utmaning. Hade vi skippat nätverk hade vi nog garanterat hunnit bli klart med ett spel men jag hade lärt mig betydligt mindre. Jag har lärt mig otroligt mycket. Mest på att använda Unity samt att skripta generellt gameplay. Jag hittar oftare lösningar för olika problem nu än vad jag gjorde förr. Blivit bättre på att dokumentera kod och har lärt mig att vara mer konsekvent när jag kodar. Har lärt mig otroligt mycket om nätverksprogrammering för spel. Har även lärt mig att arbeta i grupp mer, även om 90% av gruppen var personer jag hade träffat sen innan. Vi hade lite drama i gruppen i början av projektet som resulterade att två lämnade vår grupp. Har också lärt mig mer om grafik och animering. Jag vet nu vad som fungerar i spelmotorer och vad som inte fungerar, vad man måste tänka på innan man importera meshar till Unity. Av: Emil Linderg - Grupp 15-2011 VT