Spiludvikling.dk

Hej

Vi er tre drenge som er i gang med et skoleprojekt om spiludvikling.
Vi vil høre om der er nogen af jer har erfaring indenfor spiludvikling evt. i et firma.

Det ville være dejligt hvis nogen ville besvare vores spørgsmål:

1. Hvordan foregår samarbejdet mellem designere, programmører osv.?
2. Hvad er programmørens rolle, når der bliver lavet et spil?
3. Hvad er jeres reaktion, hvis der kommer forsinkelser, og hvad gør i?
4. Hvor vigtig er samarbejdet mellem de involverede personer, når i laver et spil?
5. Har i nogensinde oplevet i ikke kunne udgive eller få solgt et spil?
Evt. eks.
6. Hvilke redskaber bruger i til at lave jeres spil? Og hvorfor har i valgt lige
præcis de redskaber?
7. Er arbejdsdagene meget ens for en programmør, eller får de nye udfordringer hver
dag? Evt. eks.

Hvis i ikke vil svare her, kan i sende en privat besked eller mail på skoleprojekt@hagebjerg.dk

MvH Kasper, Rasmus og Erik

Hej i tre!

Udover at spørge herinde, vil jeg også anbefale jer at ringe/skrive til DADIU. De har arbejdet utroligt meget med udviklingsprocesser blandt de "fiktive" spilvirksomheder i DADIU forløbet, og har i den forbindelse en del erfaring med de processer i spørger ind til, på tværs af rigtig mange forskellige produktioner og hold.
De kan i hvert fald svare på spørgsmål 1-4 og 6-7.

Måske er det også interessant for jer at splitte undersøgelsen op i flere kategorier:
- En for små prototype produktioner til f.eks. gamejams
- En til studieprojekter på f.eks. ITU og DADIU
- En til spilvirksomheder der gør det for at leve af det

Og så se om der er forskel på arbejdsmetoderne i sidste ende.
Husk at komme tilbage når i er færdige med projektet og del jeres resultater!

Jeg kan kun bidrage i forhold til studie-spilproduktioner og gamejams - ikke så meget firma-delen, men hvis den er relevant deler jeg da gerne.

Mit svar, som gamejammer:

1. Til et gamejam er der ikke tid til at bruge en masse tid på at diskutere alting i detaljer, så som oftest kaster man sig bare ud i det. Enten har én person en fantastisk idé som alle er med på, eller også prøver man sig bare lidt frem uden meget andet end en fornemmelse for den grundlæggende spilmekanik.

2. Til de jams jeg har deltaget i har de fungeret som spildesignere på lige fod med resten af holdet. Derudover er de dine bedste venner når det handler om at få grafik og lyd ind i spillet, noget der tit sker i de sidste dele af produktionen. Man skal være meget opmærksom på at få en grundlæggende pipeline op at køre, så de kedelige ting som grafik og lyd fylder så lidt som muligt, så programmørerne også kan koncentrere sig om spil-logikken. Det er dem der forvandler tegninger, lyd og idé til noget der kan spilles på skærmen!

3. I studieprojekter: Arbejder hårdere for at kunne følge med igen. Hvis det fejler nedjusteres forventningerne. Til gamejams er det hele så kompakt og hurtigt at forsinkelser ikke rigtig findes.

4. Jams: Det er super vigtigt - det er ligesom at bygge et hus - hvis tømrere, murere og arkitekter ikke kan tale sammen kommer der sikkert et hus, men det bliver skævt, ser grimt ud, og står på et elendigt fundament. Det er vigtigt at tale sammen undervejs, og mindst lige så vigtigt at der er en god pipeline for at tingene kører så smooth som muligt.

6. Det der får en i gang hurtigst muligt - men det er nok især gældende for de mindre prototype spil der laves til gamejams. Der handler det bare om at få skudt noget afsted, så man kan teste det i en fart! De sidste 3 år har Unity3D været favorit engine for mig til gamejams og studieprojekter.

Erik wrote:1. Hvordan foregår samarbejdet mellem designere, programmører osv.?

Dette er meget, meget forskelligt afhængigt af de givne omstændigheder, og som du/I sikkert har luret fra svaret ovenfor, så er der få generelle svar på, hvordan spiludvikling foregår. Det afhænger meget af typen af spil man laver, holdets størrelse, budgettets størrelse osv.

Desuden er spørgsmålet meget åbent og svært at besvare. Overordnet set kan man dog sige der er "to skoler":
1. Den ene som er mere silo-orienteret, hvor kompetencer arbejder mere adskilt, f.eks. programmører for sig og designere for sig. Her vil designere så levere specifikationer til programmørerne, som så implementerer det beskrevne, og bagefter verificeres af designerne. Dette er ofte en del af vandfalds-udviklingsmodellen.
2. Den anden er mere hold-orienteret, hvor hold bestående af folk med forskellige kompetencer arbejder sammen om at udvikle en feature, fra tidligt design til færdiggørelse. Her er der mere tæt kommunikation mellem f.eks. programmør og designer, hvor bolden hurtigere og mere ofte spilles frem og tilbage. Dette er ofte en del af den agile udviklingsmetode.

Erik wrote:2. Hvad er programmørens rolle, når der bliver lavet et spil?

At skrive koden. Det er det primære ansvar. Nu findes der dog mange forskellige programmør-roller, fra en mere styrende og administrativ Technical Producer/Lead Programmer til specialister som Engine Programmer, Shader Programmer osv. På mindre hold er rollen ofte mere versatil, ofte med en masse design-input og test ligeledes, mens man på større hold ofte har en mere dedikeret rolle.

Erik wrote:3. Hvad er jeres reaktion, hvis der kommer forsinkelser, og hvad gør i?

Ift. min nuværende situation, så prøver vi altid at fange forsinkelser hurtigst mulige og justere. Er der ting som kan pilles ud for at nå vores deadline, som måske ikke er kritiske at have med? Kan vi tillade os at skubbe vores deadline en anelse (det er sjældent fornuftigt at skubbe den for meget, da det bliver en glidebane)? Kan vi frigive nogle resourcer andetsteds? Kan vi finde på nogle smarte løsninger for at komme hurtigere i mål?

Erik wrote:4. Hvor vigtig er samarbejdet mellem de involverede personer, når i laver et spil?

Det er om noget det vigtigste. Samarbejde er alfa omega. Dårlig kommunikation og samarbejde vil ofte, hvis ikke altid, resultere i, at tingene bliver lavet forkert, på den forkerte måde og meget mindre effektivt.

Erik wrote:5. Har i nogensinde oplevet i ikke kunne udgive eller få solgt et spil?
Evt. eks.

Det er ikke noget jeg har personlige erfaringer med, men det er en ganske normal udfordring at finde "funding" til et spilprojekt, hvilket jo også er en form for "salg". Når det først er udgivet - hvilket er en mindre udfordring i dag, når det først er produceret, grundet platforme som eks. App Store - vil det så også altid være en udfordring at sælge, eller rettere få opnået et godt salg (men dette er jo relativt. Hvad er et godt salg? Break even? 20%, 50%, måske 100% eller mere i profit?)

Erik wrote:6. Hvilke redskaber bruger i til at lave jeres spil? Og hvorfor har i valgt lige
præcis de redskaber?

Ift. min nuværende situation, så er spillet udvikler i Flash. Jeg kender ikke præcis den original forklaring, men det skyldes sandsynligvis det der ofte er grunden til at bruge Flash; det er relativt hurtigt og nemt at udvikle i, og det kan køres på langt de fleste web-browsere/computere verden over (i dag er udfordringen med Flash primært, at dette ikke køres på mange mobile enheder).

Flash er stadig et meget populært værktøj, men har også fået udfordring fra danske Unity 3D. Et mere "traditionelt" spiludviklingsværktøj/spilmotor er Unreal Engine/UDK.

Men der bruges altid et hav af værktøjer i spiludvikling, da du både skal have noget til at skrive koden i (f.eks. Microsoft Visual Studio), noget til at lave grafikken i (f.eks. 3DS Max, Maya, Flash Professional, Photoshop), noget til at lave lyden og musikken med, dokumenter der skal skrives, fil-managemet og versionerings software (f.eks. Perforce, SVN), osv. osv.

Erik wrote:7. Er arbejdsdagene meget ens for en programmør, eller får de nye udfordringer hver
dag? Evt. eks.

Det afhænger meget af arbejdspladsen og mit ovenstående svar ift. holdstørrelse og hvor specialiseret man som programmør er. Standardsvaret er dog, at hverdagen er relativt varieret; der er i hvert fald nok med udfordringen at komme efter. Som de fleste plejer at sige: hvis man vil have høj løn og kedeligt job, får man arbejde i en bank. Hvis man vil have en lavere løn og et mere spændende job, bliver man spilprogrammør

Håber det kunne hjælpe... dog vil I nok kunne få endnu bedre svar, hvis I præciserer nærmere, hvad jeres skoleprojekt skal forsøge at afklare/finde svar på. En mere konkret problemformulering.

Jeg er spilprogrammør og har arbejdet ved tre forskellige spilfirmaer. Arbejdsprocedurerne varierer meget afhængig af hvilken type spil, der udvikles. Jeg vil groft dele det op i to typer. Der er de traditionelle spil, som man typisk kan købe i en butik. Til de spil er der en omhyggelig fastlagt og planlagt proces med en endelig afslutning. Når projektet er slut, bliver spillet udgivet, og så går man i gang med næste projekt. Den anden type er internet baserede spil, som altid er i løbende udvikling - det giver en helt anden og mere løs arbejdsgang.

Erik wrote: 1. Hvordan foregår samarbejdet mellem designere, programmører osv.?

"Designere" er et meget vidt begreb, og deres opgaver varierer fra sted til sted. Nogle steder har man dedikerede designere, andre steder er det en opgave som falder ind under andre ansvar. Nogle steder er der det Jesper kalder silo-modellen, hvor designere afleverer en kravspecifikation. Andre steder udvikler programmørerne værktøjer, som designerne (f.eks. level designere) efterfølgende bruger til at fylde indhold spillet.

Erik wrote: 2. Hvad er programmørens rolle, når der bliver lavet et spil?

Som Jesper skrev, at skrive koden. D.v.s. at lave selve kernen i spillet - at få det hele til at fungere og hænge sammen. Alle mekanikkerne og reglerne i spillet. Jo større firma, jo mere specialiserede roller har programmører. Eksempelvis kan man have en programmør, der udelukkende arbejder med at få de rette lyde til at spille på de rette tidpunkter, eller en der kun laver fysik-systemet.

Erik wrote: 3. Hvad er jeres reaktion, hvis der kommer forsinkelser, og hvad gør i?

Det er normalt producerens valg. Enten kan man sætte en ny deadline eller man kan skære ting fra, som ikke kommer med - i internetbaserede spil, er de to muligheder ofte det samme, og valget er mere, hvilke features, der kommer til at vente. Jeg har aldrig oplevet, at man prøver at presse ting igennem hurtigere, når forsinkelser truer - det ville resultere i katastrofale fejl.

Erik wrote: 4. Hvor vigtig er samarbejdet mellem de involverede personer, når i laver et spil?

Alfa og omega.

Erik wrote: 5. Har i nogensinde oplevet i ikke kunne udgive eller få solgt et spil?

Hvis et spil ikke kan udgives kommer det normalt aldrig videre end koncept-fasen. Det sker MEGET tit, og langt de fleste spil bliver aldrig til noget. Det sker dog forhåbentlig aldrig at et hold når hele vejen gennem en spilproduktion, står med et færdig produkt, og så kommer i tanke om "hov, vi skal da også have fundet en udgiver... Nå, øv. Der er ingen, der vil udgive vores spil."
Det sker også MEGET tit, at spil ikke sælger som forventet. Spiludvikling er en ekstremt risikabel branche. Det hænder at man rammer en guldåre, men for det meste tjener spil ikke sig selv hjem. Listen over spilfirmaer, der har måttet lukke er lang.

Erik wrote: 6. Hvilke redskaber bruger i til at lave jeres spil? Og hvorfor har i valgt lige
præcis de redskaber?

Det ene sted brugte vi en egenudviklet 3D game engine. Det andet sted brugte vi Unity 3D. Det tredje, Flash. Valget mellem redskaber, bliver typisk truffet tidligt i firmaets levetid, så jeg skal ikke udtale mig om, hvilke overvejelser, der har ligget til grund.

Erik wrote: 7. Er arbejdsdagene meget ens for en programmør, eller får de nye udfordringer hver
dag? Evt. eks.

I de store firmaer, er programmører meget specialiserede, så arbejdsopgaverne er meget ens. I mindre firmaer er programmørerne nok de, der har de mest varierede udfordringer. I en spilproduktion er der rigtig mange forskellige ting, der skal programmeres.
Her får I lige en hurtig liste over typiske programmør opgaver: Implementering af gameplay, 3D rendering, shading (lys og skygge), kunstig intelligens, audio, animation, input og kontroller, kamera, grafisk brugergrænseflade (GUI), optimering, udvikling af værktøjer til andre faggrupper, netværkskommunikation, database, konvertering mellem platforme (PC, browser, konsol, mobil, tablet), sikring mod hacking, fysik, partikeleffekter og meget andet...