Warhammer The End Times Vermintide

Effektiva arbetsmetoder – kan en automations-programmerare lära av en spelprogrammerare?

2020-08-25

En automationsingenjör jobbar vanligtvis själv med en lösning, är ofta den enda som ser koden, jobbar mestadels lokalt i en kopia, sällan med versionshantering och testar först när det är idriftsättning. Detta gäller inte alla automationsingenjörer men denna typ av arbetsmetod är inte ovanlig och förekommer kanske särskilt på mindre bolag inom diskret tillverkningsindustri. Kraven på att det ska bli rätt och gå snabbt att få fram en lösning ökar men frågan är om arbetsmetoderna har hunnit med för att stödja de allt hårdare kraven från industrin. 

 

För Simon Lundmark, vd och programmerare på spelutvecklingsbolaget Pixeldiet Entertainment, låter detta vansinnigt. Spelbranschen är ganska många snäpp bättre på att nyttja system för samarbete och versionshantering och att använda effektiva arbetsmetoder för att hantera risker och testa kod.

Automationsingenjörer är inte ovana vid tidspress och att axla ansvar. De kommer ofta sist i utvecklingen av en ny produktion och har stort ansvar på individnivå för att få saker att fungera. Ofta sitter automationsingenjören själv med sin kod utan någon annan som granskar den. 

 

Samtidigt ställs mer och mer krav på att produktionen ska kunna ställas om oftare, och snabbare. Detta ställer stora krav på automationsingenjören och dennes arbetsmetoder. Det kanske är dags att börja snegla på hur man har åstadkommit den snabba mjukvaruutveckling man ser i andra programmerande yrkesgrupper? Idag finns det mängder av projekt som programmeras av hundratals programmerare runtom i världen. De har dessutom ofta krav på omedelbara resultat; snabbhet i att lansera en ny lösning kan vara skillnaden i att vara marknadsledare eller bli utkonkurrerad helt. När kraven är så stora på lösningen är kraven på arbetsmetoderna lika stora.  

 

 

Lösningar för att samarbeta

Nyckeln till framgång är ofta att nyttja system för samarbete, versionshantering och testning. De lösningar som finns för samarbete handlar delvis om att hantera uppgifter och distribuera dessa men även om att kunna dela kod mellan olika personer, även på helt olika geografiska platser.  

 

I vissa projekt har vem som helst möjlighet att ladda ned kod från en kod-delningssajt, som GitHub, utveckla nya funktioner och be ägaren att implementera dessa i programmet. Just ett sådant projekt är kärnan i alla så kallade Linuxbaserade operativsystem, Linux Kerneln, där vem som helst kan bidra och be om att få denna funktion eller ändring in i kerneln. Om Linus Torvalds tillåter förstås. Denna koddelning möjliggör alltså att flera olika programmerare kan jobba samtidigt och alltid få tag på den senast testade versionen.  

 

GitHub ses främst som ett versionshanteringsprogram, precis som Subversion eller Microsoft Team Foundation Server. Varje gång en ändring görs skapas ett bibliotek av tidigare versioner, som gör att man kan ”rulla tillbaka” en uppdatering om programmet skulle få en bugg. Ändringar dokumenteras flitigt så det är lätt att hitta ändringar och även att kunna se tillbaka på gamla lösningar för att återanvända i senare projekt. Man ser vem som har skrivit varje rad kod och man har samtlig historik över alla förändringar som har skett i kodbasen.  

 

Dessa system (GitHub, Subversion eller Microsoft Team Foundation Server) kan även användas för TIA Portal-projekt, så versionshantering och samarbete finns det även här möjligheter till. Andra lösningar som Multiuser Engineering kan också göra att man uppnår versionshantering. Mellan ingenjörsdiscipliner kan man även använda lösningar som Teamcenter, där man kan koppla ett visst TIA Portal-projekt till dess elschema och CAD-ritning och hela tiden få tag på den senaste uppdateringen när ändringar sker. Detta möjliggör ju ännu mer samarbete.  

Riskhantering och kodtestning

Den andra delen i att effektivisera arbetsmetoder handlar om hur man hanterar risker och testar sin kod. Det finns sedan en tid tillbaka faktiskt arbetsmetoder som går ut på att man skapar tester innan man skapar lösningen. Det gör att man måste ha en bra analys och fundering på vad systemet måste klara, alla möjliga fel, alla möjliga kombinationer av fel och även besluta hur dessa bör testas. Inte sällan är ingenjören som skriver testerna inte samma ingenjör som gör lösningen, detta för att kunna säkerställa att inga genvägar tas eller kanske ännu mer, att den mänskliga faktorn spelar in, och något missas. 

 

Hur man testar ett program är oerhört beroende av hur detta program ska nyttjas men generellt ska ett program både kunna uppfylla ett mål med applikationen men även kunna hantera när systemen runtomkring inte beter sig som väntat och kunna ge bra felmeddelanden när detta händer. Systemet ska alltså genomgå både positiv och negativ testning. 

 

Idag finns det enkla system för testning. Simatic S7-PLCSim, PLCSim Advanced och Simit gör att man enkelt kan kolla att kodblocken fungerar och testa systemet på signalnivå. För att även kunna gå vidare i testningen kan man nyttja virtuell idriftsättning, där man även kopplar in en visualisering. Detta möjliggör att man även ser själva produkten som åker igenom produktionen, verifierar att saker händer i rätt ordning med mera. 

En spelprogrammerares vardag

Simon Lundmark är medgrundare och vd för Pixeldiet Entertainment som sysslar med programmering inom spelutveckling för dator- och konsolspel. Pixeldiet har funnits i nio år och har medverkat till att utveckla spel som Magicka: Wizard Worlds (Paradox North) och Warhammer: Vermintide (Fatshark). 

 

Förutom att vara vd är Simon Lundmark själv senior programmerare. Programmeringen sker främst i C och C++ beroende på prestandakrav, där en spelmotor, som kan delas, hanterar det som är maskinnära. Gamekoden kan vara i annat språk (Lua, C#).

 

– Ett större spel tar tre till fem år att utveckla och kan ha en budget på 200 miljoner upp till 2,5 miljarder kronor. Det största projekt jag har jobbat i involverade 800 personer varav 200 programmerare.

 

De involverade i ett projekt behöver inte sitta på samma kontor eller ens i samma land. Ubisoft Entertainment, ett av världens största spelbolag, har kontor över hela världen. Vissa utvecklingsbolag har inte ens kontor utan arbetar bara online. 

 

De senaste fyra åren har han arbetat i ett projekt för Arrowhead Game Studios, som gör spel för Playstation och dess underkonsoler. 65 personer jobbar i det projektet, varav 12 programmerare.

 

– Tusentals system interagerar med varandra vilket gör att helheten blir komplex och små förändringar får stora följder. Jag har programmerat i över 20 år och är det något jag har lärt mig är det att det är viktigt att göra koden så enkel som möjlig att ändra och att testa så ofta som möjligt. Det ger resultat.

 

Simon Lundmark arbetar mest i Visual Studio men också i Slack för kommunikation, Jira för buggar och uppgifter och HG och GitHub för versionshantering.

 

Utmaningen är att det inte går att göra ett spel enligt vattenfallsmodell, den systemutvecklingsprocess som följer ett logiskt flöde genom olika faser. I spelvärlden måste koden kunna anpassas jättesnabbt efter kravbeställarnas behov.

 

– Här pratar vi verkligen om en agil utvecklingsmetod. Vår projektmetod kan ändras snabbt och iterationstiden blir väldigt viktig. Spelutvecklarna och programmerarna måste kunna göra ändringar snabbt i spelen och ägarna måste snabbt kunna se ändringarna realiserade. Vi talar om timmar eller maximalt dagar. Om det skulle ta tre månader att testa om fienden exploderar på rätt sätt skulle det vara alldeles för lång tid.

Vikten av versionshantering

Källkodsversionshantering är självklar inom spelvärlden. På programmerarnas arbetsdatorer laddas de senaste förändringarna ned.

 

– När jag laddar ned förändringarna är det bara förändringarna som kompileras. Versionshantering kör jag alltid med från dag ett. Skulle jag inte ha en server skulle jag ta en Raspberry Pi så att jag inte har all kod på ett ställe. Om man inte har källkodsversionshanteringssystem är det helt bedrövligt. Får du krångliga buggar i koden måste du kunna se var det buggade. Jag kan hitta exakt vilken filändring det var som orsakade en krasch. I systemet skriver jag också ned vad jag har gjort och varför. När jag sedan tittar på kod som jag inte förstår kan jag läsa vad jag höll på med när jag gjorde den ändringen och förstå hur jag tänkte. Källkodsversionshantering innebär att alltid ha koll på historiken och kommentarerna i versionshanteringen hjälper till att förstå koden.

Lärande och stödjande kultur

Simon Lundmark lyfter fram vikten av att ha en kultur där man lär av varandra och driver varandra att bli bättre.

 

– Jag kollar varje morgon i vår versionshantering och kan se fel som de andra har gjort och berätta hur de ska göra istället. Det blir en kvalitetssäkring och ett sätt för kollegor att granska och hjälpa varandra. Det blir också ett sätt för seniora programmerare att hjälpa unga programmerare att utvecklas. Det blir en positiv kultur för alla: när man ser ett problem kontaktar man den person som jobbade med det och löser uppgiften tillsammans.

 

Vad säger han då om att programmera som en automationsingenjör? 

 

– Att sitta själv med sin dator utan testmiljö? Jisses. Hade jag inte haft en skulle jag ha börjat med att sätta upp någon form av testmiljö. Programmering handlar om att ta input, göra något magiskt och få en output. Om jag inte kan testa outputen kan jag inte göra något magiskt. 

 

Automationsprogrammering behöver förvisso inte ändras lika ofta och koden heller inte testas lika ofta. Då kan man göra unit-tester, som i automationsvärlden innebär att kompilera koden. Men att inte få visuell feedback direkt, hela tiden, ter sig märkligt för Simon Lundmark.

 

– Det skulle vara konstigt att sitta och jobba på något som jag tror och hoppas är en optimal version utan att veta.

 

Att jobba ensam ser han väldigt få fördelar med.

 

– Du har ingen annan som granskar koden!

 

Och att jobba utan versionshantering:

 

– Bedrövligt! Det blir mycket svårare att hitta problem. 

 

Visst är förhållandena i spelvärlden kanske annorlunda men eftersom det blir alltmer komplext även i automationsvärlden ökar behovet av snabb och kontinuerlig feedback, korta idriftsättningar och kort time-to-market. Vi kan ha en del att lära.

En scrummodell nyttjas ofta då samarbete är essentiellt

1. Spelprogrammeraren får en uppgift via Jira – dokumenterar vad man ska göra.

    Innan man börjar ges feedback på uppgiften – kommer överens om uppgiften.

2. Source versioning control tools GitHub, Subversion.  

    Synkar motorn från GitHub. 

    Synkar gamekod från HG Mercurial. 

3. Bygger motorn.   

    Kompilerar content. 

    Startar spelet. 

4. Börjar koda och lösa uppgiften. 

    Sparar och kompilera om den delen. 

    Laddar om och ser den delen (iterativt). 

5. Checkar in saker (motor, i gamekoden). 

6. Synkar med kvalitetssäkringsgrupp (testar spelet dagligen). 

7. TeamCity kompilerar till alla plattformar. 

Pixeldiet Entertainment AB är ett spelutvecklingsbolag med kontor i Stockholm. Företaget startades 2011 av Simon Lundmark och Fredrik Engkvist.  
pixeldiet.se

 

Smarta verktyg som underlättar din arbetsmetodik när du jobbar i TIA Portal 
Nyttja Multiuser Engineering i TIA Portal för att enkelt samarbeta i ett projekt och även hålla koll på versioner: support.industry.siemens.com/cs/se/en/view/109740141

 

Nyttja TIA Portal Openness för att spara dina projekt på GitHub, Subversion eller Microsoft Team Foundation Server: support.industry.siemens.com/cs/se/en/view/109770552

 

Standardisera med hjälp av bibliotek: support.industry.siemens.com/cs/document/109747503

 

Utför testning och Virtual Commissioning med hjälp av Simatic Machine Simulator och samarbeta med andra ingenjörsdiscipliner: siemens.com/virtual-commissioning

 

Utbildningar 
Få utbildning inom hur du kan jobba med standardisering (DI-STAND), hur du kan generera istället för programmera/konfigurera (DI-AUTOEN & DI-OPEN2) samt hur du kan arbeta med testning (DI-SIMITFA & DI-VIRTCOM): 

sitrain-learning.siemens.com/SE/sv/rw59772/Digital-Enterprise

 

Vad är GitHub? 
youtube.com/watch?v=w3jLJU7DT5E

 

siemens.se/industri