Min bugg hanterings process! (Fortsättning på förra posten)

Att ta hand om buggar kräver information för att kunna härleda vart det oönskade beteendet uppstår.

I dagsläget finns det ett par källor till informationen som behövs för att påbörja processen.

En observation av ett oönskat beteende under skapelseprocessen.

Detta leder oftast till att sättet som beteendet är uppbyggt måste utvärderas för att se om det kan finnas ett bättre sätt att framkalla beteendet. Då hinner inte en bugg i ett så här tidigt skede inte lämna mitt skrivbord.

En observation under ett internt speltest. Vid våra interna speltest går vi igenom och provar spelets funktionalitet och ser så att de önskade beteendena uppstår, om så inte är fallet så kommer buggen skrivas ned.

Några utav buggarna som uppstår uppkommer inte under de ofta ganska ytliga kontrollerna vi utför under våra interna speltest dessa brukar dock dyka upp under våra externa speltest och antingen förmedlas muntligt utav speltestarna eller skrivas ned som en post på spelets community forum.

En ganska vanlig utgångspunkt för att fixa en bugg är något linkande:

community

Utifrån den informationen som ges utav antingen en av mina team medlemmar eller någon extern så måste jag först lokalisera vart det är troligast att felet ligger. I exemplet ovan är det ganska troligt att problemet ligger i funktionen som tar hand om att kasta bollen för att det handlar om passningar.

Efter att jag hittat vart det troligaste felet befinner sig tillämpar jag en lösning som jag tror kommer att fixa till problemet.

Efter detta måste jag försäkra mig om att problemet är löst genom att prova alla olika sätt att framkalla buggen för att sedan om buggen inte är löst se över andra faktorer som kan framkalla felet och försöka åtgärda dom och jag får göra om detta tills problemet är löst.

Vad är det jag gör?

När jag som programmerare arbetar med en spelproduktion så är en utav sakerna jag spenderar mycket tid med att hitta tekniska problem. Ett av de tekniska problem jag arbetar med är ofta bara ett logiskt missförstånd eller en miss i tänkandet.

Andra missförstånd mellan programmeraren och själva ramverket (alltså de hjälp funktioner som spelmotorer är byggda utav) framkallar också buggar.

Ett exempel på ett logiskt missförstånd är följande:

Det önskade beteendet när man trycker på hopp knappen är att spelaren hoppar om spelaren har tillräckligt med energi.

logikförklaring

Diagrammet ovan demonstrerar ett felaktigt beteende där spelaren inte kan hoppa om spelaren har energi.

Det har skett ett logiskt missförstånd!

För att lösa det här problemet behöver jag byta plats på de två gula handlingarna.

Ett problem i sammanhanget är alltså när ett önskat beteende inte sker. Problem kan då alltså appliceras på både design och grafik.

Ett grafiskt exempel av ett problem skulle kunna vara att ett objekt ska se ut på ett sätt som får spelaren att uppmärksamma det men spelaren uppmärksammar det inte, då har ett problem uppdagats.

Problem är alltså en mycket generell benämning och därför har jag valt att begränsa mig till ”tekniska problem” eller så kallade ”buggar”.

I den här fördjupningen är tanken att jag ska se på hur processen jag använder i dags läget för att hantera buggar kan förändras vid användningen utav ett verktyg för att samla ininformation.

För att kunna göra denna jämförelse så måste jag beskriva min aktuella process vilket kommer ske i nästa post.

Rubrik.

Det händer mycket här på kontoret alla är i full gång med arbetet på Epigenesis. Buggarna hamnar på hög när man sitter och programmerar gameplay. Jag jobbar ju inte enbart med att fixa buggar så saker måste ju ordnas upp och sättas i någon form utav bugg kö. För tillfället så koncentrerar jag mig på att fixa alla buggar som har med det jag jobbar med för tillfället och väljer alltså att i stort sätt ignorera alla andra gameplay skavanker som blir rapporterade på vårt forum. Självklart så måste jag fixa de mest seriösa problemen som blir upphittade men annars så jobbar jag endast till exempel med vår Trench planta som ska ge spelaren en sköld vilket den tyvärr gör lite önskade saker.

Skölden är alltid där, den sitter 90 grader fel och den absorberar inte kraften ifrån ett skott utan den bara förmedlar den vidare så att spelaren flyger all världens väg om man träffar skölden. Det lila på sidan är skölden.
fail

Externa Speltestare

I min förra post så beskrev jag hur problemletnings arbetet går till fram tills det att det iallafall lämnar vårt kontor.

Så jag tänkte fortsätta ett steg till. För inte så länge sedan så slutade problemletandet där jag lämnade det i den sista posten.

När vi började släppa ut kopior utav spelet till folk som vi inte har någon direkt kontakt med så utnyttjade vi inte alls den potential som en extern speltestare har att hjälpa utvecklingen så något behövde göras ganska omedelbart. Det effektivaste sättet att få information om problem och fel är igenom en community.

En community är en grupp människor som har ett gemensamt intresse som tycker om att diskutera och prata om detta.

Det är också iallafall i stora communitys ett bra filter för att hitta saker som är viktiga att åtgärda i och med att man kan se ett intresse och en diskussion i communityn som handlar om att man bör fixa ett någon specifik sak som då drar mer uppmärksamhet.

Vi behövde alltså en plats där en community kunde växa fram så jag skapade Epigenesis forumet och den viktigaste biten för mig som problem fixaren är bugg rapporterings delen utav forumet.

För att få fram den information man behöver om ett problem så snabbt som möjligt så satte jag upp en mall som användare helst ska följa när de rapporterar buggar och det fungerade mycket bra skulle jag vilja säga.

Det här är mallen jag satte upp:

BbugMall

 

Och efter ett tag började användare rapportera buggar och det går att se här: http://deadsharktriplepunch.com/forum/viewforum.php?f=5

Att ha folk som hjälper till med att hitta fel förändrade sättet jag jobbar på på ett antal olika sätt.

Innan så kom många problem igenom den interna utgallrings processen som gjorde att jag behövde göra massor utav nöd fixar vilket kan vara väldigt stressande men med hjälp av vår community kan jag lätt planera tid för att ta hand om alla problem som har upptäckts innan de blir till ett stressmoment innan en mässa eller någon annan uppvisning.

Jag fick också ganska snabbt en känsla för vilka typer utav fel som uppkommer och det har gjort mig mer medveten om riskerna med att göra vissa saker programmeringsmässigt i Unreal Engine 3. Till exempel så har många nätverks replikerings buggar  som bara visade sig igenom små estetiska detaljer blivit lättare att förebygga.

Men att ha spelare som hela tiden rapporterar buggar reducerar inte bara stress utan kan bli en aning hektiskt bara för att du vet om att det finns några där ute som räknar med att du fixar saker tills nästa gång de går in och kollar. Som tur är har vi inte så många olika användare som rapporterar buggar så dom ser att jag långsamt betar av berget och är ganska förstående. När 100 personer rapporterar var sin bugg om dagen kommer det nog kännas som man inte riktigt räcker till men så länge man är medveten själv om att det man gör är för spelets bästa så är det nog lätt att undvika att känna sig dålig för att man struntar i att en person av tusen har sitt sikte sittande en millimeter fel.

Replikering går att läsa om här: http://wiki.beyondunreal.com/Replication_overview

Arbetsplan och Problemsöknings nivåer

Idag valde jag att förändra min kursplan en aning, dels utifrån den feedback jag fick men också för att jag ville skifta fokuset ifrån metoder till hur informations insamling skulle förändra mitt arbete.

För att kunna utvärdera hur min arbetsprocess fungerar med hjälp utav ett automatiserat eller ett manuellt problem letnings verktyg så behöver jag veta hur jag arbetar med detta just nu och då passar den här arbetsboken alldeles utmärkt.

Idag har jag stött på en del problem som behövde undersökas men dessa var i någon form ganska traditionella programmerings problem som är en del utav att jag utvecklar något och alltså inte rör teamet eller någon annan än mig.

Madens jag utvecklar något gör jag ju själv en liten egen kvalitets säkring som i och för sig är så ytlig att jag ser att det som ska hända faktiskt händer.

Ett exempel var när kameran blev vänd upp och ner och eftersom jag fortfarande sitter och skriver och ändrar i mattematiken så rättade jag till det direkt och så behövde problemet inte komma ut till resten utav teamet utan kunde fixas direkt utav mig. Alltså en ytlig översikt som ser att det inte finns några uppenbara problem.

Om jag skulle summera vilka tydliga nivåer utav problemsökning vi har internt så skulle det se ut såhär:

  1. Jag skriver programkod och ser att jag får det önskade beteendet.
  2. Jag ser över mina ändringar genom att går in i spelet och testar alla funktioner jag la till
  3. Om de första två kollarna jag gjorde inte innehöll några uppenbara fel laddar jag upp dessa till resten utav teamet.
  4. Teamet utför här en ofrivillig test utav det jag förändrat eller lagt till i och med att de laddar ner mina uppdateringar får jag ganska omgående reda på om jag glömt lägga till filer eller andra saker som får själva spelmotorn att säga ifrån
  5. Om allt är prima med det kommer nästa problem check att bli under vårt nästa interna speltest där teamet är med och spelar och testar alla nya funktioner om något fel skulle upphittas under speltestet får jag snabbt reda på det utav mitt team som diskuterar problemet och om det är något som behövs fixas innan vi fortsätter med att lägga till mer funktionalitet eller låta vår community och utomstående testa det.

Jag skriver ofta ner buggar på papper där de svåraste eller största buggarna blir fixade innan jag fortsätter bygga ny funktionalitet men andra mindre buggar kan komma att bli kvar och glömmas bort vilket är något som jag kanske borde hitta en bra lösning på.

Mellanlagring.

Under vårt arbete med Epigenesis har vi fått mycket muntliga rapporter om problem och buggar.

Att få information muntligt är ett snabbt sätt att ta emot information men kan också vara ganska ostrukturerat och det finns en stor risk att bitar utav meddelandet glöms bort om man till exempel inte har tillgång till antecknings material.

Vi har också internt använt oss utav en hemsida där vi kunde lägga upp buggar och andra problem så som balanserings problem som är en typ utav problem som uppstår när man till exempel måste låta två spelare ha i stort sätt lika stora chanser att vinna även om de använder olika metoder för att ta sig dit.

Hur som helst utav den erfarenhet jag har så fungerade den digitala lösningen en aning bättre för att man fick en snabbare överblick utav alla problem för att allt följde samma mall och hade en automatisk sorterings funktion som plockade ut de största problemen först.

Men det muntliga systemet fungerar väldigt väl när det finns saker som behöver fixas direkt. Bara idag har det hänt ett flertal gånger att jag och någon annan i teamet har behövt ta hand om ett problem som uppstått under vårt arbete och behövt lösa det. Detta gäller också för saker som går väldigt fort att fixa då inte informationen behöver mellanlagras och kan användas direkt.