Kunst, fakta og tanker ved spilldesign

[Suram]

Tenkte jeg skulle slenge inn en liten kommentar her til de som ser på å gå spill studier på NITH. Hvis du har spørsmål om studie, miljø, eller generelt bare vil vite om skolen, send meg gjerne en melding. Sitter for øyeblikket i studentrådstyret der og bruker mesteparten av min tid på studier, så kan svare på det meste

[OlavHelland]

Har ikke lest boken, så jeg vet ikke hva den sier om dette, men sitatet over høres litt skummelt ut. Setter spilldesigneren i en bås over spillerne. Det er ikke designerens jobb å være lærer, det er hans jobb å sørge for at spillerne underholdes. Du kan ikke overtale spillerne til å bli underholdt av det du lager. I stedet må du lære av hva spillerne ønsker, og bygge spillet rundt dette konseptet.

 

A theory of fun er egentlig den minst skumle boken i verden, halvparten er till og med tegninger.

[Era_InnleggNO]

A theory of fun er egentlig den minst skumle boken i verden, halvparten er till og med tegninger.

 

Helt riktig. Men er enig med TiLT at mitt første utsagn angående boka kunne være litt skremmende, for spilldesigneren skal ikke settes i en bås over spillerne ;D

[havchr]

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.

 

 

Tja tjo, ja..

 

Er utrolig viktig å ha en god dokumentstruktur om man skal stappe ALT av detaljer i et game-design-dokument.

Si at man skriver om en game-design-mekanikk, en spesifikasjon på hvordan den delen av spillet skal påvirke andre objekter etc.. Dersom man blander inn all idiotiske detaljer, story, etc. Så vil det være utrolig vanskelig for folk som jobber med dokumentet å få en oversikt over hva mekanikken går ut på.

 

Anbefaler å lese hvordan Bioware organiserer designdokumentet sine. De deler ting opp slik at deler av dokumentet lett kan deles med de som trenger oversikt over funksjonalitet og hva som må lages av assets (kode, lyd, grafikk, etc) for å prototype/teste mekanikken. De deler all funksjonalitet inn i fem faser etter hva som må gjøres for å få testet hovedfunksjonaliteten , andre fase på mekanikken er hva som må være ferdig til beta, tredje, må være i det ferdige spillet, fjerde er hva som hadde vært bra å få inn om man har tid, og femte er "dette hadde vært kult om vi hadde uendelig med tid/penger"

 

Hadde en link til dette foredraget før, men husker ikke hvor jeg gjorde av den.