Eg presenterer det nye(gamle) mobilspelet til Hackerspace: Hackeroni! I denne artikkelen vil eg skriva om både historia til prosjektet, samt erfaringane våre av eit svært turbulent prosjekt, og til slutt dei personlege erfaringane eg har gjort som leiar for ei gruppe i Hackerspace.

Historia til Hackeroni:

---

Prosjektet byrja på pitchemøtet, sommaren 2018. Det skulle vera eit «Mafia»-liknande spel med element av Pokemon GO. Ein skulle kunna gå rundt og bruka GPS-signalet til å bevega seg på eit kart saman med andre spelarar. Saman med mafiafamilien sin kunne ein «drepa» andre spelarar, gjera oppdrag og møta nye folk. Ideén var relativt ny og spanande, men det gjekk diverre ikkje som det skulle.

Fyrste semester inn i prosjektet blei brukt til å skriva eit designdokument, samt trena folk opp i bruk av Unity. Unity er ein spelemotor (game engine), altso ei samling av verktøy som ein kan bruka til å laga spel utan å måtta programmera alt frå botn. Unity er praktisk fordi han kan laga program til både iOS og Android frå same kode. I praksis, derimot, viste det seg å ikkje vera så enkelt som ein skulle tru. Dette skal eg snakka meir om seinare.

Etter at det 10 sider lange designdokumentet med diverse ideéar var ferdigskrive og folk var blitt meir kompetente i Unity, byrja programmeringsdelen av prosjektet. Gruppa blei einige om å kjøpa ein pakke frå Unity store som heiter «GO Map». Ein pakke er ei samling av kode og/eller bilete som ein kan bruka i prosjektet sitt, og Unity Store er ein innebygd digital butikk der ein kan kjøpa eller lasta ned pakkar til bruk i prosjektet. «GO Map» er ein pakke som implementerer den same mappestilen som i Pokemon GO der ein beveger seg rundt i spelet ved å bevega seg rundt i verkelegheita. «GO map» eigna seg bra til prosjektet, men det førte også til nokre problem, som eg kjem tilbake til seinare.

Dei som hadde ansvaret for prosjektet før oss valde å bruka Firebase som backend. Firebase er ei Google-basert serverløysing som er gratis for dei som jobbar med små prosjekt. For å bruka Firebase, må ein legga til nokre pakkar som følger med Firebase for å kommunisera med serveren. Firebase i seg sjølv var ein god idé, men pakkane fekk uventa konsekvensar i seinare tid.

Så då var to semester omme, og gruppa hadde klart å laga ein demo som kopla seg opp mot Firebase og plasserte ein raud prikk i Bergbygget på Gløshaugen. Dette var stor framgang og prosjektet såg ut til å vera på rett veg. Men ting kom raskt til å endra seg. No vart nemleg eg med på prosjektet!

Figur 1: Her er korleis prosjektet såg ut i denne tidsperioden. Frå artikkelen i denne tidsperioden: https://www.hackerspace-ntnu.no/news/30/

Då eg blei med på prosjektet, hausten 2019, verka ikkje alt like ideelt som ein skulle tru.

Eg var ein fersk fyrsteklassing, og heilt ny i Hackerspace. Likevel såg eg at det var problem med prosjektet. Ein del av dei var grunna den mangelfulle Linux-klienten til Unity, medan andre var grunna mangelfull dokumentasjon eller dårleg struktur i prosjektet. Då eg nemnte dette for medlemmane i ein raskt laga PowerPoint-presentasjon, førte engasjementet mitt til at eg vart valt til leiar for prosjektet. Dette både på godt og på vondt. Leiarrolla gjorde at eg kunne pusha fram fleire aggresive strukturendringar, mellom anna for å klargjera prosjektet for å verta overført til Github-kontoen til Hackerspace og verta «open source» i framtida.

Her er ei liste over nokre av problema som var sentrale for prosjektet det fyrste semesteret mitt som leiar:

1. Uerfaren leiar, altså meg, med mangelfull erfaring og kunnskap innan speldesign, C#, backend, produktutvikling i grupper og sjølve leiarrolla.
2. Dårleg dokumentasjon på at Git-lfs var nødvendig.
3. Diverse bugs med samhandlinga mellom Firebase og Linux.
4. Det var vanskeleg å oppdatera «GO Map»-pakken, ettersom «GO Map» har lukka kjeldekode, samt at me redigerte filene direkte i «GO Map».
5. Diverse kompileringsproblem.
6. Uryddig kode.
7. Utydleg backend-design. (Dette hadde vore betydeleg betre om eg hadde hatt meir leiarerfaring.)
8. Eldre medlemmar prioriterte studiet over prosjektet.

Det tok heile fyrste semester og halvvegs inn i neste semester å rydda opp i desse problema. Saman med at fleire personar vart mindre aktive i gruppa, førte problema til at engasjementet for prosjektet svært lågt. Likevel heldt me fram med prosjektet, i stor grad fordi eg som leiar ikkje ville gi slepp på det. Det enda med at me måtte minska rekkevidda til prosjektet. Eg hadde lite kompetansen og mangelfull erfaring om korleis ein kunne implementera backend-designet.

Det er takka vera dei fantastiske medlemmane i gruppa at me klarte å halda fram med prosjektet så lenge me gjorde. Me diskuterte løysingar, kva som var kjekt, moglege strukturar på backend, og mykje meir. Under opptaket våren 2020 fekk me endå fleire fantastiske folk i gruppa. Engasjementet gjekk opp, og ting gjekk raskare fram. Diverre var dette ein kortvarig ekstase, ettersom både korona, nye tekniske problem og fleire kutt i omfanget til prosjektet, førte til at engasjementet gradvis vart mindre og mindre. På slutten av semesteret våren 2020, verka MVP-et (Minimum Viable Product) meir som ein tech-demo enn eit faktisk MVP.

Me bestemte oss for at spelet ikkje lenger skulle likna på «Mafia», men kom med ein ny idé. I spelet kunne ein kvar dag velja mellom to lag som deretter konkurrerte i minispel på sokalla «Hackpoints». Hackpoints funka litt som ein «Gym» i Pokemon GO. Ei stor nedgradering frå det me eigentleg hadde planlagt: mafiafamiliar, turf wars, mord, konkurransar og innebygd chattesystem, vart alle sløyfa.

Figur 2: Sånn såg prosjektet ut våren 2020 Frå artikkelen i denne perioden: https://www.hackerspace-ntnu.no/news/41

Derfor gjekk me inn i sommarferien med lite engasjement. Det såg mørkt ut, og det verka som me kom til å måtta avslutta heile prosjektet. Den einaste grunnen til at me jobba på prosjektet, var at me ikkje skulle ha kasta vekk to år på ingenting. I tillegg var eg personleg alt for opphengt i idéen om å ikkje øydelegga målet som folka før oss drøymte om å oppnå. Eg følte eg tråkka over ynskja og trua dei hadde gitt meg.Til slutt måtte eg likevel sjå sanninga i augo; Spelet var ikkje kjekt, verken å designa, eller å spela.

 

Men på det fyrste møtet etter sommarferien fekk éin av medlemmane i gruppa ein genial idé: Kva om me berre fokuserer på minispela? Minispela var det einaste som verka å vera delvis interessant med spelet, så kvifor ikkje retta alt fokuset mot dei? I etterkant verkar idéen openbar. Sjølvsagt burde me fokusera på det som var kjekt med spelet og som var kjekt å jobba med, i staden for å jobba med noko som uansett ikkje har potensiale. Likevel var det som ein brytar blei skrudd på inne i hovudet mitt. Ein så simpel, men likevel så god idé, at eg bestemte meg for å gi slepp på gamle planane og ikkje henga meg opp i alt me ikkje fekk gjort. No hadde me ein ny plan.

Migur 3: Fyrste utkast av "Game launcher" idéen

e laga eit nytt Github-arkiv og tok til å jobba igjen. Planen no var å laga ein enkel startmeny for fleire mindre spel der ein kunne samla poengsummar. Me droppa både «GO Map» og Firebase, sidan dei hadde skapt så mange problem. Folk kom med idéar om kosmetiske lekam og ein butikk inne i spelet der ein kunne kjøpa lekama. Denne gongen hadde me gode erfaringar med å avgrensa omfanget til prosjektet, så me valde å berre ha med det som verka nødvendige og kjekke å laga, og å fjerna resten. Om me ynskja eller fekk tid til å laga meir likevel, kunne me jobba med det seinare i staden.

Det tok ikkje lang tid før me alle systema me trengte var på plass. Spelet var laga på ein modulær måte, sånn at det vart enkelt å legga til nye minispel som Unity-scenar til prosjektet. Koden var ryddig, fleksibel og simpel. Me hadde framleis nokre diskusjonar om korleis ting skulle implementerast og korleis me skulle legga til nye element, men me enda opp med eit godt system som kunne gjera alt me trengte det til.

Anna enn dette, var det ikkje mykje spennande som skjedde dei neste to semestera. Me hadde nokre problem med lisensen, compiling, og ikkje minst gyroskopet (huff!). Men me jobba oss gjennom det, og enda til slutt opp med noko halvvegs brukbart som me kan kalla eit MVP.

Til slutt fekk me publisert spelet på Google Play Store, med eit ynskje om å publisera det til iOS i framtida. Men no som me var ferdige med prosjektet, var det mange som sukka letta ut og ville jobba vidare på andre prosjekt i staden. Eg må seia at eg kjenner på det same. Dette er årsaka til at dette erfaringsskrivet kom så seint ut, og årsaka til at ingen av bugsa (eller som somme ville ha kalla dei: «Features») ikkje har vorte fiksa på enno. Men no som eg sit igjen med ekstra fritid, kjem eg kanskje til å ta ein kikk på prosjektet igjen og rydda litt her og der, og eventuelt få publisert det til iOS. Me får sjå kva som skjer i framtida.

---

Her er ei liste over erfaringane me gjorde som ei gruppe desse 2 åra me har jobba med spelet:

1. Det er lurt å skriva systemdesignet inn i designdokumentet. Korleis ein skal implementera ting dannar eit grunnlag som alle kan ta utgangspunkt i når dei kodar, utan å måtta venta på at andre vert ferdige med sine oppgåver.
2. Om ein vil laga eit program med open kjeldekode, bør ein ta omsyn til det frå byrjinga av. Ikkje bruk lukka kjeldekode eller andre ferdiglaga pakkar!
3. Ein må halda styr på omfanget til prosjektet, og ikkje ver redde for å minska det. Det er vårt prosjekt om det er me som jobbar med det, og me må ikkje henga oss opp i gamle planar.
4. Det er lurt å skriva naudsynt programvare, brukte pakkar og grunnleggande git instruksar for å utvikla koden, i README.
5. Ein bør ikkje koda direkte i importerte pakkar.
6. Lær Git, og bruk det!
7. Unity funkar greit nok, sjølv om det ikkje er særleg optimert.
8. Firebase er vanskeleg å kompilera til iOS
9. Ikkje bruk «Squash and merge» når ein drar inn endringar frå pull requests i Github. Det er knotete å vaska om det trengs i etterkant.
10. Alle pakkar på Unity Asset Store har lukka kjeldekode.

---

Her er ei liste over råd eg vil gi vidare etter å ha fått leiarerfaring frå 2 år i eit Hackerspace-prosjekt:

1. Skaff deg naudsynte eigenskapar før du byrjar på prosjektet, som:

   1. brukande git

   2. grunnleggande Unity

   3. korleis Github funkar

   4. korleis ein brukar Slack

2. Set deg inn i korleis eit prosjektet er strukturert:

   1. les designdokumentet, om det finst

      1. Snakk med den førre leiaren om manglande eller uklare detaljar i designdokumentet. Ta notat!

   2. kva må ordnast fyrst, før ein kan ta eit steg vidare

   3. korleis ser eit brukande produkt ut

   4. kva for avgjerder bør ein ta tidleg?

3. Ver streng, sjølv om det er vanskeleg:

   1. minn folk på at det er møte både dagen før møtet og rett før møtet

   2. få folk til å reagera på meldingar for å vera sikker på at dei har lese dei

   3. få beskjed om folk ikkje kan koma på møte

   4. ta kontakt med leiaren av Hackerspace om det er naudsynt

4. Ha eit opent sinn og innsjå om du har gjort noko gale:

   1. ikkje lås deg fast i ein idé eller ein plan

   2. sei «unnskyld» om du har gjort noko gale

5. Ver demokratisk:

   1. alle som jobbar på prosjektet har like mykje dei skulle ha sagt. Leiaren er berre ein person som har ansvar for det administrative.

   2. av og til går ikkje alt din veg, og det er heilt greitt

   3. ha demokratisk røysting før store avgjerder

      1. Følg avgjerdene og ver streng på at det er desse som gjeld!

6. Ver eit aktivt medlem av prosjektet og ha oversikt over kva som skjer:

   1. følg med på kva folk driv med. Fordel arbeid og avtal kva de skal gjera ilag.

   2. følg med på tidsbruk

7. Ikkje stress med at ting går seint:

   1. ting kjem til å gå seint - Det er normalt. Det viktigaste er å ikkje henga seg opp i fortida og sjå framover.

   2. om ting går seint på grunn av noko konkret (som til dømes engasjementet for prosjektet), så ta grep!

8. Ver svært varsam med engasjementet for prosjektet.

   1. prøv å auka engasjementet

      1. Ein kan kome med nye idéar.

      2. Ein kan gjera drastiske endringar om folk ynskjer det.

   2. ikkje berre kan dette vere ein indikasjon på at ein bør gjera radikale endringar, men det kan også tyda at du gjer ein dårleg jobb som leiar

   3. følg med på motivatorane for prosjektet:

      1. Ytre: Kva får folk av å jobba på prosjektet?

      2. Indre: Kva synast folk om å jobba på prosjektet?

9. Gi ros, og ver empatisk:

   1. dette kan hjelpa på motivasjon

   2. hugs at det skal vera kjekt å jobba på eit prosjekt ilag!

---

Om du les dette berre på gøy, eller om du har planar om å starta eit prosjekt, så ynskjer eg at du i det minste tar med deg éin ting frå denne erfaringsoverføringa, og det er: Ver open! Om du er open, er du enklare å snakka med (som er svært viktig som ein leiar), og du kan læra mykje frå andre menneske. I tillegg kan store problem verta enklare om du er open og samarbeider med dei andre på gruppa. Ikkje gi opp med ein gong. Hugs at eit prosjekt er ei samarbeidsoppgåve av store proporsjonar.

---

Eg vil avslutningsvis gi ein stor takk til alle som har delteke i utviklinga av Hackeroni. Og spesielt til dei som stod på heilt til siste slutt. Me hadde aldri vorte ferdig med prosjektet utan den store innsatsen, det positive humøret og den djupe kunnskapen til alle dei fantastiske medlemmane våre. Me har krangla, me har diskutert, me har slitt og me har lidd i frustrasjon, men me klarte det til slutt, og det med mange nye, flotte mem me har produsert i prosessen.

Tusen takk for meg, og takk til Hackerspace som gjorde alt mogleg!

 

-Håvard Skjetne Lilleheie, Tidlegare leiar for Prosjekt: Mobilspel

 

Hjarteleg takk til Kamma Tyse for rettskrivingshjelp!