Prototyp koncept.

För att kunna utvärdera och reflektera över hur vidare det är möjligt att skapa plats baserade spel som inte nödvändigtvis behöver GPS kommunikations möjligheter så behöver jag testa distans bedömning med hjälp utav trådlös signalstyrka.

För att snudda lite vid ett par punkter ifrån boken ”A Theory of Fun”, att använda lite pussel för att göra spelet mer intressant utnyttja lite kryptografi i form utav Enkla krypteringar och lösenords hashnings metoder.

Tanken med prototypen är att den ska använda sig utav Mobilteknologi och operativsystemet Android.

Det jag tänkt mig är att man ska gömma en beskrivning in ut i en access punkt (trådlös nätverks sändare) där spelaren ska få komma tillräckligt nära accesspunkten och sedan använda accesspunktens MAC adress för att dekryptera ledtråden som leder spelaren på en liten skattjakt för att hitta det gömda lösenordet som behövs för att knäcka det hemliga krypterade meddelandet.

Principen är väldigt lik Geocashing där man letar reda på ledtrådar som leder en på en liten skattjakt . Men vi kan utnyttja access punkter som checkpoints och sedan några kryptografiska pussel för att få fram det hemliga meddelandet.

A theory of fun, en bok

Efter att ha listat ut vad en Android kan hjälpa till med vad det gäller trådlösa nätverk så har jag hoppat på Speldesigns tåget och läser boken ”A Theory Of Fun In Game Design”, denna bok fick jag rekommenderad ifrån mina designer kollegor. Den tar upp vad ett spel är för något och vad som faktiskt gör ett spel roligt, intressant och fängslande. Med den kunskap som boken delar med sig av hoppas jag kunna skapa roligare och intressantare spel/spelprototyper.

En mycket intressant sak som Koster (2005) säger är “To make games more long-lasting, they need to integrate more variables (and less predictable ones) such as human psychology, physics, and so on.” (p. 34.).

Det här citatet är väldigt relevant för det jag arbetar med för tillfället, bakgrunden till citatet handlar om pussel och mönster som man som människa gärna vill reda ut och lösa och för att göra ett spel “djupare” och ge det mer speltid och roligare pussel så måste man ta in fler variabler i sitt spel alltså fler data som spelar roll i hur spelet utspelar sig.  Jag använder mig utav variabler ifrån verkligheten i mitt prototyp arbete  för plats baserade spel och om jag kan använda mig utav mer data än vara nätverks information skulle det kunna förbättra upplevelsen avsevärt.

Koster, R. (2005). A theory of fun for game design. Scottsdale, AZ: Paraglyph Press.

Informations teknologi I omgivningen

På ett kontor kan man förvänta sig att finna ett par trådlösa nätverk en bunt med datorer skrivare och troligtvis lika många mobiltelefoner som datorer.

Det jag vill försöka gör är att komma på ett par intressanta sätt att använda dessa i ett plants baserat spel.

De flesta plats baserade spel är mobil spel huvudsakligen för att de flesta platsbaserade spel kräver att man vandrar runt i ett område, mobila plattformar är också ofta utrustade med GPS vilket är den informations källa som många väljer att bygga sina platsbaserade spel på.

Jag tänker försöka mig på att inte göra spelmekanikerna beroende utav GPS koordinater utan att istället basera interaktionen med omgivningen baserat på bland annat trådlös nätverks kommunikation.

Den information om trådlösa nätverk man får tillgång ifrån Androids SDK är

-Namn

-Identifierings tag (mac adress)

-Signalstyrka i dB

-Funktions lista (Vilka krypteringar och anslutnings funktioner som finns tillgängliga)

Det är inte så mycket som jag hade hoppats på men det räcker för att få igång en liten test plattform.

Till en början behöver jag kunna bestämma en ungefärlig distans till det trådlösa nätverket och detta är nog en ganska klurig uträkning i och med att fysik inte är mitt starkaste ämne så har jag fått gräva lite i mina matte böcker och söka efter info online.

Efter att jag skrivit en liten app som försöker räkna ut en ungefärlig distans till en wifi-sändare i meter upptäckte jag att det är ett väldigt opålitligt sätt att mäta ut en exakt distans på.

Problemet ligger i att formeln man använder räknar på signalstyrkans avtagande i luft och så fort det kommer en vägg i vägen så kommer distans uträkningen bli mycket opålitlig. Även då inget förutom luften är i vägen så är det svårt att få exakt data då mottagarens orientering också spelar stor roll. Mätningen är dock användbar på avstånd mellan 0-10 meter igenom luft då distansen inte är fel med mer än ca en meter. Vilket är en felmarginal på 10%.
Mätningsproblem

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.

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.