Byg egne moduler og værktøjer - det betaler sig
En spilproduktion indeholder mange roller i et udviklingshold. I vores produktioner har vi programmører, grafikere, spildesignere, lyddesignere og projektledere med hver deres tekniske baggrund. For eksempel er det bl.a. en gamedesigners opgave under produktionen at optimere spiloplevelsen ved at justere på spillets parametre. Det er derfor vigtigt, at programmøren giver designeren de værktøjer han skal bruge for at løse sin opgave bedst muligt. I vores produktioner finder vi tidligt frem til de værktøjer som bør udvikles specielt til denne produktion, og størrelsen kan være meget varierende. Dette kan være alt fra en større level editor til mindre image scripts som vores grafikere kan benytte. Hos os arbejder alle i udviklingsholdet med Unity teknologien, som giver os den mulighed at udvide dens editor med vores egne skræddersyede moduler og værktøjer.
Et eksempel på et værktøj er en level editor fra vores første iOS spil, Space Squad. Der var mange fordele ved at bruge tiden på at udvikle sådan et værktøj. Værktøjet blev lavet som noget af det første til projektet, hvilket betød at vores gamedesigner tidligt kunne gå i gang med at teste gameplay elementer og level design. Værktøjet blev udvidet løbende gennem projektet, men ved at have et godt værktøj sparede det vores programmører en masse tid, og gav en ro til at kode andre elementer på spillet mens banerne blev bygget.

Det ovenstående er et eksempel på et værktøj specielt udviklet til et projekt. De næste to eksempler jeg vil give, er værktøjer som vi har benyttet gennem flere produktioner og har sparet vores programmører rigtig meget tid. Det første er en udvidelse til Unity’s log viewer. Værktøjet lytter på Unity’s log system, men giver mulighed for at skrive meget mere information ud i konsollen. Blandt andet er det muligt at se tidspunktet på beskederne, definere kategorier, sortere og sammenligne log beskeder i værktøjet. Det har vist sig at være et godt værktøj, som har gjort det betydeligt nemmere at debugge ens kode.

Det andet eksempel er et værktøj til at analysere vores Unity builds. Den viser grafer og en liste over filer i et build, hvilket giver et hurtigt overblik over hvor man bør optimere i sit projekt. Dette værktøj har specielt vist sig nyttigt til vores iOS projekter, hvor hukommelsesforbrug specielt er et sted hvor man bør optimere.

Dette er blot nogle eksempler på værktøjer vi har udviklet til vores produktioner, enten for at spare tid eller som har været helt nødvendige for at f.eks. en game designer har kunnet løse sin opgave.
Hvilke moduler og værktøjer har I udviklet og benyttet I jeres produktioner og har det gavnet jeres projekt?
Anders er teknisk forretningsudvikler hos virksomheden Unity Studios, som udvikler spil og 3D applikationer. Han blogger om de tekniske udfordringer man møder i en spilproduktion, samt kommentere på nyheder og nye teknikker der mødes i den unge branche.
Follow @atholmKommentarer (4)
Velkommen til V2's blogosfære.
Jeg synes, at det er et rigtigt interessant emne, du har taget op. Jeg har ikke selv været med til spilproduktion, men jeg har lavet og vejledt studenterprojekter om værktøjer og lignende, der potentielt kan bruges til spil. Eksempler:
Programmer til procedurel generering af indhold (landkort, bykort, mv).
Sprog til beskrivelse af elementer af spil (f.eks. regler) for at gøre programmering og analyse af disse elementer nemmere.
Optimering af spil-AI med genetiske algoritmer.
Det primære formål med sådanne værktøjer er forøget produktivitet: Når først værktøjerne er lavet, er udvikling og verifikation af de ting, som værktøjerne omfatter, blevet enten lettere eller helt automatiseret.
Hvis man ikke arbejder med stærkt specialiserede værktøjer, bliver rå kodning og afprøvning en væsentlig udgift, og så taber man konkurrencen til lande, hvor kodere får 25 kr i timen eller mindre.
Jeg kom til at tænke på Bret Victor's præsentation om samme emne, da jeg læste indlægget[1]. Jeg er helt enig i at brug og udvikling af værktøjer er væsentlige. Jeg bruger selv meget energi på f.eks. at få mine værktøjer til at skrive kode for mig. Det giver en anden slags bugs, men problemerne er meget mere interessante :)
Tak for velkomst og jeres kommentarer.
Det er nogle rigtig gode og forskellige eksempler i kommer med og kunne ikke være mere enig med jer. Det kan dog være vanskeligt, specielt som kontraktudvikler, at bedømme om det kan betale sig at bruge ressourcerne på at lave det specialiserede værktøj. Det er derfor vigtigt at dette bliver vurderet tidligt og allerede i estimeringsfasen af projektet.
Bret Victor's præsentation lyder rigtig spændende, så den vil jeg se igennem.
Jeg arbejder hos CEGO som står bag komogvind.dk og spilnu.dk og jeg kan ikke være mere enig.
At have gode værktøjer ér bare alfa og omega, så vi bruger en god portion tid på at lave level editors, bygge systemer, debugging og visualisering og meget andet, og det gør det bare så meget nemmere at fejlfinde og optimere.
Jeg glæder mig til at læse mere fra din side.

