Kunst, fakta og tanker ved spilldesign

[Era_InnleggNO]

Skrev dette til mine "kollegaer" til et spillprosjekt vi holder på med, og tenkte kanskje andre kunne dra nytte av det. Det hele er skrevet etter å ha lest litt tanker og meninger om spill/leveldesign på nettet. Jeg vurderer selv sterkt å ta en utdannelse innen spilldesign, og prøver å lære meg mest mulig innen feltet.

Innledning

 

Det er mange designteknikker for enten en single player orientert tittel, eller multiplayer. Hver teknikk er basert på et overall "Gameflow" konsept. Det er den mystiske "livskraften" som gjør et bra spill underholdene, og det er et "belønnings" system som utfordrer spilleren og forsyner han/hun med en "belønning" for å fullføre oppgaver.

 

"Gulrot på enden av pinnen" - Oppmuntringen fra spilldesignerne til spilleren om å fortsette videre; mange av disse "gulrotene" er bygd og plantet av designeren, fordi disse fører gameflow. Hva er vel ett spill uten å ha noe å gjøre, uten noe mål?

 

Gameflowen i en Single Player tittel er drevet av dette. Vi må lage oppgavene og plasere gulroten rett foran spilleren, og oppfordre han til å fullføre oppgaven. Lage ett problem, og så oppfordre spilleren til å løse det. Dette er også hvorfor så mange spill bruker voldelige elementer som deres fokus, fordi det er den enkleste, og den mest basiske form for konflikt.

 

Kontrollert Frihet

 

La spilleren tro han har et valg i fks hvor han skal gå og hva han skal gjøre, men samtidig forsiktig guide han til hans mål.

 

Hvis spilleren har friheten til å gå hvor som helst, å gjøre hva han vil (som mange spillere sier de vil), roter man seg fort bort og blir frustrert. Det man da må gjøre er å gi spilleren en illusjon av at det er flere veier å gå, da har man friheten til å velge. På denne måten får man det beste av to verdener; spilleren får gulroten på enden av pinnen, og det føles som om han tok de riktige avgjørelsene for å komme dit han skulle.

 

Dette kan ta litt mer tid å få til, men blir til gjengjeld en mye bedre opplevelse for spilleren. Det er dog fullt mulig og lage et spill hvor man kan "gå overalt, gjøre hva man vil", men dette blir enda vanskeligere. Gjør man det vil veldig mange spillere spørre seg selv, "hva gjør jeg nå da?". Det kan gjøres, men ville da appellert til de mer hardcore brukerne.

 

Scene komposisjon og kontrast

 

Relative enkle objekter arrangert på en interessant metode kan resultere i et mye mer tilfredstillende syn. Det er slik med kunst, arkitektur og selvfølgelig level design. Det er hvertfall relevant hvis man må holde noe low-poly og på strenge detalje budsjetter.

 

Pacing

 

Konstant action blir fort kjedelig.

 

De skumleste skrekkfilmene er de som setter seeren i en falsk form for sikkerhet, og så plutselig skjer det noe skummelt - og et bra spill er ikke noe forskjellig. Hvis monstrene konstant er i spillerens nærvær vil spillet miste mye. Men hvis man lar spilleren glemme, for en liten stund, for så å la han slippe "guarden", vil han igjen bli skremt og kanskje drept av det neste skumle monsteret.

 

Risk incentive

 

I spilldesign er det mye en spilldesigner kan gjøre for å la spilleren gjøre egne valg. Hvor mye trøbbel skal han gå gjennom for å få noe han vil ha?

 

Det er det vakre med risk incentive (risiko oppfordring). Spilleren vurderer risken; ser utfordringen, og gjør et valg. Han føler han har kontroll, og designeren gir han et valg.

 

For eksempel; Designeren kan sette en skattekiste ved siden av et spesielt sterkt monster, eller fler monstre samlet. Spilleren må da overveie situasjonen, og gjøre opp for seg om han skal prøve seg eller ikke. Klarer han det ikke vil han klandre seg selv - og ikke spilldesignerne.

 

Aldri undervurder denne teknikken.

 

Lyd

 

"Når lyser går, og døra åpnes, ser du et 5 meter høyt insekt stående der. En del av deg sukker og tenker "Phew, jeg trodde det skulle være et 10 meter høyt insekt."

 

Spilldesignere må jobbe tett med lydteknikkere, for å sikre en god og spennende lyd opplevelse. Uansett hvor godt talentet er, så er monsteret i spillerens hode alltid skumlere enn hva som er på skjermen. Hvis spillet skal inneholde skumle saker, la lyden gjøre mye av jobben!

 

Gjenbesøk

 

Gjenbesøk konseptet går ut på at spilleren ser et utilgjengelig område i et område og lurer, "Hvordan kommer jeg meg dit?" Spilleren prøver så å fullføre noen oppgaver for å føre spillet/storyen med seg (og seg selv) hvor han kommer fram og skjønner det; "Åh! Jeg er der oppe jeg nå!"

 

Gjenbesøk av områder fra en annen vinkel er en god ting. Det holder spilleren motivert i det han farer gjennom spillet, og sparer designeren tid og penger.

 

Supply and Demand

 

La spilleren løpe rundt, engstelig for å gå tom for ammo, HP (Health) eller lignende, men aldri til det punktet at han løper rundt uten ammo, lite HP, og dør hele tiden; da er det spilldesignerens skyld. Dette er enda en "gulrot på enden av pinnen", som gjør spillet mer tilfredstillende. Da lærer spillerne ressursbehandling, og gjør det å finne health/ammo til en bedre opplevelse. Bra Supply and Demand gjør disse tingene verdt mer.

 

Designeren og programmeremå jobbe tett sammen

 

Man kommer ikke langt om man ikke er på lik linje under utviklingen. Programmereren kan ikke lage en fiende med fulkommen AI (Artificial Intelligence) uten å vite hvordan område denne fienden skal være i, og vice versa.

 

De 6 bud!

 

Søk kritikk

- Ikke vær redd for å søke kritikk hos andre, eller fra utvikler teamet. Det hjelper ganske mye, selv fra folk du ser på som "dårligere enn deg"

 

Frameraten skal ikke være dårlig

- Hvis designeren jobber på et prosjekt som kan yte opp til 100 millioner polygoner, skal man gjøre så det ser ut som det kan kjøre 3 ganger mer enn det. Men, mye av framerate problemene faller på programmererne, med optimisasjon og LOD (Level og detail) teknologi er det ekstremt viktig at designerne vet akkurat hva man kan gjøre, og hva man ikke kan gjøre.

 

Rivaler er bra

- Sunn konkurranse er bra for teamet, men kan også føre til negative sider.

 

Gjør hjemmeleksene dine

- Research er viktig. En kombinasjon av improvisasjon og research er det ideelle før noe gjøres

 

Designer, Evaluer deg selv

- Når du lager noe, evaluer ditt arbeid. Aldri vær redd for å finpusse på noe, og hvertfall ikke vær redd for å gjøre noe om igjen.

 

Ikke vær redd for å jukse

- Vis ingen oppmerksomhet til mannen bak gardinene. Hvis en designer kan simulere en nyere teknologi med noen smarte triks, så for all del, gjør dette. Denne måten å tenke kan utføres i alle aspekter av utviklingen. Programmerere kan finne kreative måter å "fake" nye effekter. En sneaky artist kan gjøre en character se mer detaljer ut enn han egentlig er med god texture mapping eller smart bruk av polygoner. Gjøres dette bra er det bare de mest hardcore av de hardcore som kan se forskjell!

[OlavHelland]

fin artikkel. Mange fornuftige punkter.

 

har du foresten lest A theory of fun. det er en veldig god og lettlest bok om temaet, som jeg anbefaler på det sterkeste.

[Era_InnleggNO]

fin artikkel. Mange fornuftige punkter.

 

har du foresten lest A theory of fun. det er en veldig god og lettlest bok om temaet, som jeg anbefaler på det sterkeste.

 

Takk. Den skal jeg ta en kikk på, ser interessant ut

[Suram]

Det med å ikke være redd for for å jukse er noe vi hele tiden får høre av både designer og programmeringslærerene våre. Mesteparten av alt man ser i spill er bare juks, men spilleren ønsker å bli imponert. Derfor vil han godta det som skjer, hvis AIen roter seg bort, vil han tro den er laget for å slite med å fiinne fram i skogen.

Sannheten er at det ikke er mulig å få en datamskin til å gjøre alt "ordentlig" da ville vi sittet fast på 2 fps. I spillprogrammering er det like vitkig å finne smarte måter å lure brukeren på, som å kunne skrive gode simmuleringer.

Endret 8. februar 2009 av Daymare

[Coffey]

Det er FPS du beskriver, right?

[Suram]

Det er FPS du beskriver, right?

Hvis det var meg du mente, så pratet jeg generelt. Selvsagt vil man ikke ha en ai som soser rundt hvis man har et rpg, men det var ment som et eksempel. Juks finner du over alt, veldig mange såkalte "AIer" som man kan spille mot i gamle RTS spill er bare skripta fra a til å, den har bare et sett med strategier som den kjører halveis tilfeldig, så vil det se ut som den finner på noe nytt.

[OlavHelland]

forskjellige ting gjelder for forskjeldige sjangere.Noen av punktene i orginalposten er nok mest gjeldene for FPS/3d action spill. Mens andre er mer almengyldige.

 

spill simulerer noe som ikke fins og er på den måten juks i seg selv

Endret 9. februar 2009 av NordicGamer

[Era_InnleggNO]

forskjellige ting gjelder for forskjeldige sjangere.Noen av punktene i orginalposten er nok mest gjeldene for FPS/3d action spill. Mens andre er mer almengyldige.

 

spill simulerer noe som ikke fins og er på den måten juks i seg selv

 

Heh sant nok

[Gjest Bruker-127711]

Vurderer kanskje programmering, skal ha dette i bakharddriven

[Era_InnleggNO]

Vurderer kanskje programmering, skal ha dette i bakharddriven

 

;D

 

Jeg vurderer sterkt en spilldesign bachelor på NITH, hørt det skal være bra der også(?)

[TiLT42]

Spilldesign er et vanskelig beist. Selv har jeg satt meg mye inn i det som en følge av at jeg har vært spilleder i rollespill i over 15 år, har lagd brettspill, og har vært hovedprogrammerer i et norsk spillfirma i flere år. Det er mange, mange fallgruver å gå i, noe som vises godt ved at de aller fleste spill har større eller mindre problemer i designet sitt. Her er et par av mine erfaringer:

 

Ta GTA4 for eksempel, for å ta et nyere spill. Her er det gjort flere store brølere fordi designerne ikke fokuserte nok på at ting skal være GØY! Feiler man et oppdrag må man kjøre på nytt hele veien fra oppdragsgiver til målpunktet, og i de fleste tilfeller må man også innom en våpensjappe for å skaffe seg skuddsikker vest. Det er helt unødvendig å gjenta slike ting, og det sørger bare for å frustrere brukeren. Det blir enda verre når du får oppdrag med flere trinn som må gjennomføres i rekkefølge, f.eks. "kjør til dette punktet, gå ut av bilen, skyt vaktene i lagerhuset, hopp inn i bilen, jakt ned fyren som flykter". Hvis du feiler i det siste trinnet må du gjennomføre alle disse nivåene igjen, selv om du allerede har lykkes.

 

Grunnen til at jeg nevner akkurat dette er at det er en av de mest normale designproblemene i modene spill: I et forsøk på å trekke ut lengden og lage et kunstig nivå av "vanskelighetsgrad" legger man opp til at innhold må gjentas, ikke fordi du feilet på dette innholdet, men fordi du feilet på det som kommer etterpå. Det er helt unødvendig. Samtidig er det ikke sikkert at designeren i det hele tatt er oppmerksom på problemet. Etterhvert som du jobber med en spilltittel blir du "blendet", dvs. at du ikke klarer å se problemene på den samme måten som en spiller gjør. Du blir vant til uvaner og bugs, og du oppnår et høyt ferdighetsnivå. Som designer er det veldig fristende å lage solide utfordringer for spillerne for å underholde dem, men man lager da gjerne utfordringer for seg selv (og man ligger godt over den jevne bruker når man jobber med et spill hver dag) uten at man kan reflektere over hva dette betyr for den jevne bruker. Dette er grunnen til at man har spilltestere. De MÅ teste så tidlig som mulig og så ofte som mulig, men viktigst av alt er at designeren ikke er for arrogant til å høre på hva de har å komme med av tilbakemeldinger.

 

De fleste spill er av natur ganske repetitive. Et skytespill handler jo stort sett bare om å gå fra en kamp til en annen. Her er det veldig viktig at man igjen unngår repetisjon. Hvis du har tre fiendetyper (A, B og C), og den første kampen er mot AAAA (altså fire fiender av type A), så bør du ikke ha flere kamper med det oppsettet uten at du legger til en annen tvist for å variere. Den neste kampen kan kanskje være AABB eller ABBC. Gir du spilleren et nytt, annerledes våpen mellom disse to kampene så er det greit; du har nettopp lagt til variasjon som vil endre utfordringen og opplevelsen. Kanskje har du endringer i miljøet (f.eks. legger du til områder med farlig lava i den andre kampen) som også kan være tilstrekkelig variasjon. Hvis du glemmer disse små forskjellene vil spilleren fort sitte igjen med følelsen av at han allerede har bevist at han kan klare denne utfordringen, så hvorfor må han gjøre det igjen?

 

En annen viktig ting: God spilldesign er ingen konstant! Hva spillere syns er gøy er stadig under utvikling. Da Mega Man kom ut syns spillere det var gøy å møte en utfordring som krevde at man døde om og om igjen til man lærte seg mønsteret som var påkrevd for å komme seg videre. I dag aksepterer ikke spillere flest slike designelementer. Da Quake 3 kom ut var fokus utelukkende på enkel deathmatch (og noen andre forglemmelige moduser), mens et spill lansert med bare dette i dag ikke hadde blitt noen som helst suksess. Det er derfor viktig å ikke henge seg opp i gårsdagens gode idéer, men å i stedet følge med på hva som oppleves som gode idéer i dag (eller enda bedre: i morgen!). Forvent å måtte forkaste dine favorittfeatures fra et spill hvis det viser seg at de ikke fungerer, uansett hvor mye du måtte elske dem.

 

Til slutt: Ikke heng deg opp i ting som framerate og hvordan man skal jukse for å lure spilleren til å tro at noe skjer mens du egentlig gjør noe annet (noe som du må gjøre i omtrent alle situasjoner). Dette er implementasjon, ikke design. Implementasjon kommer senere, og er trolig noe du må involvere deg i selv når den tid kommer (du finner ikke så mange rene spilldesignere i bransjen i dag. De fleste er også programmerere).

 

Kort oppsummert: Fokuser på moro, ikke heng deg opp i unødvendige detaljer, og hør på testerne! Ikke bruk kunstig oppblåsing av vanskelighetsgraden selv om det kan være fristende.

 

Hvis en spiller kaster kontrolleren i veggen av frustrasjon har du gjort noe feil.

Endret 10. februar 2009 av TiLT

[Era_InnleggNO]

Kjempe fine punkter du tar opp her. Kan ikke si annet enn at jeg er enig! Spilldesign er vel et krevende yrke, og ufattelig kompetetivt. Ser virkelig fram til å studere det.

[Suram]

Må bare kommentere til TiLT her, noe som jeg mener er ekstremt viktig å forstå. Det er greit at du ikke henger deg opp i framerate, og hvordan man kan lure spilleren til å tro noe annet enn det som er. Det er jobben din, men som spillprogrammerer er det jobben min. Jeg leder flere prosjekter og assiterer i andre (som student, ikke som profesjonell, enda) og en jobb jeg veldig ofte må påta meg er å være knutepunkt mellom programmere og designere, fordi man ofte snakker forskjellig språk. Jeg har den fordellen at jeg interesserer meg for begge, og derfor har jeg en god posisjon til å se dette problemet igjen og igjen. Alle i ett spillteam er opptatt av at et spill skal bli så bra som mulig, men problemene oppstår når designeren sier "ikke bry deg om framerate og å finne lure triks for å få det til å gå fortere, så lenge det er morro"

 

Hvor morro blir et spill når det lagger av gårde, og du bare kan ha 10 agenter (ai styrte objekter) på brettet samtidig fordi hvis du ikke gjør det lagger det i filler? Hele poenget her er at man må alltid finne beste løsning for at hardware skal kunne løse det, det er også ekstremt viktig for designere å forstå, og en av grunnene til at steder som NITH lærer de som går spill design linja å programmere; Du får ikke ett godt spill uten å finne gode, finurlige måter å løse store problemer på design problemer på, som tar høyde for hvor mye det faktisk krever av hardwaren som spillet skal kjøres på

[Gjest Bruker-127711]

Så, hvis me skal beskrive spillprogrammering med eit ord; Avansert ?

[Suram]

Så, hvis me skal beskrive spillprogrammering med eit ord; Avansert ?

 

Det er mange former for spillprogrammering. Jeg vil ikke si at noen av dem er enkle, men jeg kan fortelle litt om noen av dem, og hva det blir lagt vekt på.

 

Du har grafikk programmering, som legger ekstremt mye vekt på at ting går raskt, her kreves det ekstremt mye vektor og matrise regning + mer avanserte algoritmer når man begynner med shadere og lignende. Jeg har så vidt begynt med dette, og stor koser meg, men det er tungt.

 

Du har gameplay programmering, som legger mer vekt på det jeg sa om å skape opplevelser for spilleren som virker ekte, uten å drepe hardware som spillet kjører på. Her snakker vi om å programmere inn ting som hender, type steiner som raser (skal vi modellere dette med fysikk, eller bare lage en animasjon som ser bra ut og spille av den?) gjøre det mulig å slå med ett sverd, plukke opp items osv. Mye av det som ligger her er forhåldsvis enkelt å få til, avhengi av måten en angriper problemet.

 

AI programmering handler om å lage gode løsninger som gjør at AIen gjør ting som ser smarte ut, uten at de nødvendigvis er det. Virker avansert, men her handler det mer om illusjoner og smarte løsninger enn noe annet.

 

For å si det enkelt: Det som ligger som grunnpillarer i ett spill er ekstremt tungt stoff som krever veldig mye erfaring og kunnskap for å gjøre godt. Det som ligger i lagene over er mindre avanserte. På NITH lærer vi litt av hvert, og det går opp for folk ganske kjapt hva de foretrekker Så for å svare på spørsmålet ditt: Noe er avansert, men du kan få mange jobber som ikke krever at du er noe matte geni.

[TiLT42]

Må bare kommentere til TiLT her, noe som jeg mener er ekstremt viktig å forstå. Det er greit at du ikke henger deg opp i framerate, og hvordan man kan lure spilleren til å tro noe annet enn det som er. Det er jobben din, men som spillprogrammerer er det jobben min. Jeg leder flere prosjekter og assiterer i andre (som student, ikke som profesjonell, enda) og en jobb jeg veldig ofte må påta meg er å være knutepunkt mellom programmere og designere, fordi man ofte snakker forskjellig språk. Jeg har den fordellen at jeg interesserer meg for begge, og derfor har jeg en god posisjon til å se dette problemet igjen og igjen. Alle i ett spillteam er opptatt av at et spill skal bli så bra som mulig, men problemene oppstår når designeren sier "ikke bry deg om framerate og å finne lure triks for å få det til å gå fortere, så lenge det er morro"

 

Hvor morro blir et spill når det lagger av gårde, og du bare kan ha 10 agenter (ai styrte objekter) på brettet samtidig fordi hvis du ikke gjør det lagger det i filler? Hele poenget her er at man må alltid finne beste løsning for at hardware skal kunne løse det, det er også ekstremt viktig for designere å forstå, og en av grunnene til at steder som NITH lærer de som går spill design linja å programmere; Du får ikke ett godt spill uten å finne gode, finurlige måter å løse store problemer på design problemer på, som tar høyde for hvor mye det faktisk krever av hardwaren som spillet skal kjøres på

 

Joda, du har naturligvis helt rett. Poenget med posten min var å påpeke hva det rene fokuset til en spilldesigner bør være. Nå har det seg selvfølgelig slik at man sjelden er "bare" designer, i og med at rollen ofte overlapper med andre roller, vanligvis enten i form av daglig drift og PR eller programmering (eller en kombinasjon).

 

Ingen i et programmeringsteam skal jobbe i fullstendig isolasjon fra resten av teamet. Det er en oppskrift på katastrofe, som du jo illustrerer. Min mening er at designeren skal lage noe han/hun mener vil være morsomt å spille uten å henge seg opp i det tekniske. Deretter skal dette taes opp med teamet (i et større prosjekt tas det opp med prosjektlederne) slik at de kan påpeke potensielle problemer som f.eks. urealistisk avansert AI som vil dra ned ytelsen til hele spillet. Designeren justerer fortløpende designdokumentet ut fra slik feedback. Prosessen fortsetter på denne måten gjennom hele utviklingstiden, oftest helt frem til alpha (feature lock), og gjerne også frem til beta (for MMORPGer kan denne prosessen faktisk fortsette til langt etter lansering).

 

En designer som forsøker å kjøre solo vil enten få ekstremt brutal lærdom veldig fort, eller han stuper på trynet ut av industrien.

[TiLT42]

Så, hvis me skal beskrive spillprogrammering med eit ord; Avansert ?

 

Kort svar: Ja.

 

Langt svar: Kanskje. Det er mange forskjellige roller i forhold til spillprogrammering. Hvis du ønsker å lage et spill helt på egen hånd, så er svaret et ubestridt "JA!". Dette er omfattende saker som krever mye innsats og en høy grad av motivasjon.

 

Dersom du vil jobbe i et spillselskap vil du få tildelt et mer begrenset ansvar. Kompleksiteten til jobben din blir da avhengig av typen oppgave du får. Dersom du blir satt til f.eks. utvikling av interne utviklerverktøy, så kan programmeringen være relativt enkel. Dersom du blir satt til å skrive shadere for 3D-motoren vil jobben straks kreve en del matte og fysikk, samt dyp kjennskap til både software og hardware.

 

Spillprogrammering har altså en kompleksitet som avhenger av hva du gjør og hva du forsøker å oppnå. Felles for alle valgene er ihvertfall det faktum at spillprogrammering er både morsomt og ekstremt tilfredsstillende.

[Era_InnleggNO]

Ja angående designdokumentet, eller, software design document (?), hva pleier noe slikt å inneholde?

[TiLT42]

Ja angående designdokumentet, eller, software design document (?), hva pleier noe slikt å inneholde?

 

Vet ikke om om det er noen fasit på det. Generelt sett skal et spilldesigndokument inneholde detaljerte beskrivelser av spillets funksjonalitet. Man begynner i det store perspektivet og jobber seg gradvis inn til tidvis ekstreme detaljer (hva skjer når du trykker på alle knappene i spillet, f.eks). Det bør også inneholde et fullstendig "script" for historien, samt informasjon som fyller ut dette.

 

Min erfaring med designdokumenter er at de skal gi en fullstendig beskrivelse av ALT som er relevant for produktet. Alt fra den minste lille spillregel til en beskrivelse av installasjonsprosessen. Den viktigste delen er uansett innledningen, som bør oppsummere hele dokumentet på en effektiv måte. Folk flest leser bare innledningen, og er ikke interessen deres vekket etter det, så gidder de ikke lese mer av dokumentet.

 

Et designdokument er noe du aldri blir ferdig med. Det skrives, og redigeres fortløpende gjennom hele utviklingen. Det kan fort utvikle seg til å nærmest bli en heltidsjob.

[Era_InnleggNO]

Vet ikke om om det er noen fasit på det. Generelt sett skal et spilldesigndokument inneholde detaljerte beskrivelser av spillets funksjonalitet. Man begynner i det store perspektivet og jobber seg gradvis inn til tidvis ekstreme detaljer (hva skjer når du trykker på alle knappene i spillet, f.eks). Det bør også inneholde et fullstendig "script" for historien, samt informasjon som fyller ut dette.

 

Min erfaring med designdokumenter er at de skal gi en fullstendig beskrivelse av ALT som er relevant for produktet. Alt fra den minste lille spillregel til en beskrivelse av installasjonsprosessen. Den viktigste delen er uansett innledningen, som bør oppsummere hele dokumentet på en effektiv måte. Folk flest leser bare innledningen, og er ikke interessen deres vekket etter det, så gidder de ikke lese mer av dokumentet.

 

Et designdokument er noe du aldri blir ferdig med. Det skrives, og redigeres fortløpende gjennom hele utviklingen. Det kan fort utvikle seg til å nærmest bli en heltidsjob.

 

Ah i see Takk ;D