Sammanfattning och resultat – Block 1

Inledning

Tanken med min fördjupning under block ett var att se hur ett informationsinsamlings verktyg förändrar arbetet med att hantera buggar i ett Unreal Engine 3 Multiplayer Spel.

Metoden jag har valt att använda mig av för att svara på frågan är komparativ, alltså att jag ser hur processen med bugghantering fungerade innan och sedan jämför och ser vilka delar som har underlättats eller försvårats med hjälp utav verktyget som jag själv skulle utforma och testa.

Min motivation till att försöka utforma ett verktyg och beskriva dess inverkan på mitt arbete kommer sig utav att jag spenderar mycket tid med den här delen utav spelutveckling och vill förbättra processen och kunna hjälpa någon annan att göra det samma.

Min frågeställning lyder:

Hur kommer ett informationsinsamlingsverktyg förändra arbetet med att hantera tekniska problem i ett Unreal Engine 3 Online Multiplayer spel?

Bugghanterings processen

Under arbetets gång har jag beskrivit processen jag använder för att ta hand om tekniska problem och buggar under utvecklingen utav ett spelprojekt jag är involverad i.

Processen kan beskrivas som följande.

Jag utformar programkod för att utföra en speciell funktion som ska framkalla ett önskat beteende.

Om det önskade beteendet inte uppstår så här tidigt i processen så brukar det vara en bra idé att se över lösningen som utformats och se vad som kan ha gått fel. Eller att börja om och hitta en annan lösning.

Efter att det önskade beteendet kan påvisas måste det testas i sin helhet med andra funktioner som kan påverka det önskade beteendet för att se så att beteendet förändras på rätt sätt och inte framkallar oönskade beteenden.

Efter att funktionaliteten har blivit testad utav mig så kan den delas med resten utav utvecklingsteamet som också testar funktionens beteende under interna speltest för att antingen konfirmera att funktionen framkallar det önskade beteendet eller att något har gått fel och då måste felet beskrivas så hoppas utförligt att jag kan få en ledtråd om var felet befinner sig i funktionaliteten och vad som kan behöva åtgärdas.

Efter att en funktion har blivit testad av oss kan vi låta vår spelarbas testa och rapportera problem med funktionens beteende.

Om ett oönskat beteende uppvisas i det här steget är det tydligt att funktionen kan behöva testas utav större mängder människor för att kunna lösa felet.

Efter att jag försökt åtgärda felet måste funktionen testas igen för att se så att ett önskat beteende uppstår, detta kan ta lång tid med vissa typer utav buggar som behöver testas utav många användare under en längre tid och det kan vara svårt att veta om felet faktiskt är åtgärdat eller om det bara uppstår väldigt sällan.

Verktygets utformning

Min första tanke med verktyget var att det skulle kunna hitta buggar automatiskt och kunna komplettera communityns input. Den tanken förändrades ganska snabbt då jag skulle se över verktygets funktionalitet. Att bygga ett bugg letnings program som utför en människas jobb skulle behöva en massa artificiell intelligens som skulle ta mer tid att skriva än vad att bara fixa alla buggar utan det skulle ta. Jag vet inte ens hur jag kom på den första tanken men jag gick tillbaka till att kolla vart i bugghanterings processen man kunde göra arbetet lättare.

Det sista steget i att faktiskt se om en bugg har blivit löst är ett ypperligt steg att applicera en informations insamlare av anledningen att eftersom jag redan försökt lösa felet vet jag hur felet uttrycker sig och då kan jag detektera det och skicka information om att problemet fortfarande uppstår och få statistik på hur ofta problemet uppstår.

Det var vid detta tillfälle jag började kunna utforma en hypotes om hur verktyget kommer kunna hjälpa mig.

Jag har beskrivit de mer tekniska hindren i min text nedanför men här är en bild utav hur verktyget slutligen fungerade.

verktyg

Resultat

Verktyget sattes i bruk fredagen 09-27 och började där sin informations insamling. Under dess nu ca en väckas långa användning har den samlat in statistik på en rad olika saker men det mest intressanta är de ganska stora siffrorna som beskriver hur spelare misslyckas med att gå in på spelservrar och inte får fram några resultat i server listan.

rawinfo

Den första spalten är Flaggans namn, den andra är datumet då det sist inträffade och den tredje är antalet gånger problemet inträffat.

Dessa två rödmarkerade buggarna hade jag inte förväntat mig vara ett så stort problem och är bevisligen inte åtgärdade och behöver åtgärdas fortast möjligt.

”JoinGameFailed” uppstod när en klient fick fel information ifrån spelservrarna om vilken adress spelaren skulle skickas till detta kunde åtgärdas igenom att om spelservrarna skickade felaktig data och misslyckades så kopplades spelaren direkt in på en spelserver istället för att gå igenom master servrarna och nu inväntar jag mer statistik som förhoppningsvis kan konfirmera att problemet är löst.

Jag upptäckte också en intressant bugg i informations flödet där flaggan ”GameStarted” egentligen är hur många gånger användarna varit i menyn vilket ger en missvisande bild utav hur många som spelar spelet.

Slutsats

Verktyget förbättrade slutsteget i vilket information om felets fortsatta existens kunde levereras direkt till mitt skrivbord och klargöra i vilken utsträckning felet fortfarande uppstår.

För att sedan underlätta bedömningen av felets utsträckning och bestämma om felet måste åtgärdas direkt eller om det kan ingå i en prioriterings process.

Något negativt med det hela är att informationen ifrån verktyget kräver ett visst underhåll för att kunna presentera relevant information vilket kräver markant mer tid.

På det hela taget skulle jag säga att verktyget höjer kvalitén på spelet och kan göra det tydligt så fort en större mängd användare upplever oönskade beteenden och har analytiska fördelar.

Block 2

Jag återkommer.

Advertisements

Utformningen utav mitt verktyg

Vad är tanken med verktyget?

I början tänkte jag att det skulle kunna komplettera den input som vår community ger oss gällande buggar i from utav att detektera saker som inte är riktigt som man förväntar sig eller uppenbara beteenden som avviker i gameplayn.

Det uppdagades ganska snabbt att för att man skulle få ut någon vettig information ur systemet skulle jag behöva skriva någon form av programvara som ska kunna alla spelets regler utantill, inse och rapportera problemet.

Det är ett alldeles för stort åtagande och skulle troligtvis ta längre tid att bygga än det skulle ta att hitta alla buggarna för hand.

picard-facepalm

Jag ville fortfarande att verktyget skulle kunna hjälpa till med min bugg hanterings process men det var uppenbart att den skulle få utföra någon simplare handling än att artificiellt läsa av spelet och rapportera avvikelser.

Jag började fundera på vilken del utav processen som jag skulle kunna förbättra. Och kom fram till att vissa buggar är svåra att bestämma om det verkligen är lösta utan att få relativt stora mängder test data.

Så om informations insamlings programmet kunde skicka iväg information om buggar med hjälp av förutbestämda händelser så skulle det kunna förbättra sättet som jag kontrollerar att fel är lösta.

Eftersom jag redan försökt åtgärda buggen en gång i processen så vet jag i det här slutsteget i processen hur felet uttrycker sig och kan då relativt enkelt skriva en funktion som kollar om buggen uppstått och då rapportera problemet.

Efter att jag bestämt mig vilken uppgift verktyget skulle utföra så kunde jag sätta igång med att planera hur programmet skulle fungera.

Eftersom jag har jobbat med C# och .Net mycket så valde jag att skriva verktyget med hjälp av dessa.

Två utav de största problemen var Hur ska jag få ut informationen ur Unreal Engine 3 för att ge den till verktyget som är ett externt program och det andra problemet var hur ska informationen komma ifrån användarens dator till mig?

Som jag såg det hade jag två val när det kom till att skicka informationen ifrån Unreal till mitt verktyg och den ena involverade att skriva all data igenom en TCP anslutning till mitt verktyg och den andra var att låta verktyget gå igenom logfilen efter att spelet stängts ned. Båda metoderna hade nog fungerat men jag valde att använda loggfil läsar metoden för att på ett så smidigt sätt kunna skriva ut meddelanden till verktyget och ta så lite prestanda som möjligt under spelets körning.

Jag kollade också upp vilka olika metoder som kan vara bra att använda för att skicka data över nätverk för att få informationen ifrån användarens dator till min.

Och kom fram till att skicka informationen över webben var det smidigaste och stöds utav alla internet leverantörer.

Metoden att använda ”WebRequest” och ”WebResponse” för att skicka webb information i C# beskrevs som mångsidig utav Griffiths och Adams et al. (2010) och borde fungera bra med en simpel php backend.

Efter att allt var klart och testat så såg verktygets funktionalitet ut på det här sättet:

verktyg

Min hypotes

Det jag förväntar mig förändras i min bugg hanterings process i och med användningen utav verktyget är det steg jag måste kontrollera att felet är löst. Jag tror att det kommer underlätta processen med att se så att problemet är åtgärdat.

Referencer:

Griffiths, I., Adams, M., & Liberty, J. (2010). Networking. Programming C# 4.0: building Windows, Web, and RIA applications for .NET with C# 4.0 (6. ed., p. 516). Beijing [u.a.: O’Reilly.

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