DADIU Produktion. en introduktion til Source for DADIU programmører. Bo Bendtsen Lasse Laursen 23.

Transkript

1 DADIU Produktion en introduktion til Source for DADIU programmører Bo Bendtsen Lasse Laursen 23. august 2006 Vejleder: Jon Sporring

2 Indhold 1 Forord Definition af termer DADIU Dolores Produktions forløb Praktiske forhold Arbejdspladsen og roller Konflikter og problemer Hvad er Source? Kilder til Source Klient-server-design Entiteter Input/Output systemet Hammer Arbejde i Source Partiel eller fuldstændig konvertering Programmering i Source Ungarsk notation Konkrete tips til programmering i Source Entiteter Tilstande og funktioner Entiteter og Data Descriptions Input/Output Source AI Think-funktioner States, schedules, tasks & conditions Interessante funktioner i Sources AI Gennemgang af en entitet QC-Scripting En rekvisitmodel En NPC model Materialer og teksturer Lydsystemet i Source Soundscripts Soundscapes Ambient_generic Response System Source konsollen Optimering af spillet og dets baner

3 4.9.2 Fintuning af forskellige aspekter ved motoren Manipulation af selvdefinerede konsolvariabler Tilgang til banens entiteter Afprøvning og debugging af Source AI Scripts og ressourcer Ressource-mapper Scripts-mapper GCF-filer og decompiling Afsluttende bemærkninger 48 A Nyttigt Software 50 B Kildekode til base NPC klassen 52 C Billeder fra Dolores 55 D Designdokument 58 Litteratur 59 2

4 1 Forord Videnskabelig arbejde forløber i den ideelle verden tilnærmelsesvis med, at man på grundlag af teoretisk viden efterprøver en idé og dokumenterer resultatet. Forløbet, der førte til denne rapport, passer ikke med denne beskrivelse. DADIU er det nye, danske spilakademi. DADIUs mål er at uddanne mennesker på tværs af faggrupper i at producere computerspil. Forfatterne til rapporten, du nu læser, deltog i en DADIU-spilproduktion, der blev afholdt i marts måned Det specielle ved situationen var, at vi som forfattere ikke havde nogen videre teoretisk eller praktisk viden om spilproduktion og slet intet kendskab til den udleverede spilmotor. Denne rapport er paradoksal i den forstand, at vi har skrevet den til os selv - og fremtidige studerende. Den skulle gerne svare på nogle af de spørgsmål, vi havde, før vi gik i gang med spilproduktionen. Source SDK er navnet på værktøjspakken, der i skrivende stund bliver brugt i DADIU-regi. Det er en spilmotor, der er blevet brugt til succesfulde kommercielle spil som f.eks. Half-Life 2. Source SDK et består af en række værktøjer og en delvist åben kildekode. Desværre er den eksisterende dokumentation til Source i bedste fald mangelfuld og lidet pædagogisk. Det er det forhold, der har motiveret os til at skrive en introduktion til Source foruden en beskrivelse af selve spilproduktionen. Vi håber at kunne dokumentere forståelse af stoffet, og formidle nogle af de erfaringer vi gjorde til fremtidige programmører på DADIU produktionerne. Denne rapport er ikke en komplet dokumentation af Source. Da rapporten bygger på vores praktiske erfaringer og tydning af tilgængelige dokumentation, ved vi, at den ikke belyser alle aspekter af motoren. Den svarer heller ikke på alle de spørgsmål, der måtte komme gennem en spilproduktion. Men vi håber, den kan bruges til at skabe overblik over motoren og de opgaver, der kan forekomme i en spilproduktion. En stor del af spilproduktion for programmørerne ligger i at finde ud af, hvordan forskellige spilmekanikker før er blevet implementeret i Source og få hele spillet til at spille, før deadlinen. Det er i langt højere grad en praktisk opgave, end de teoriske opgaver vi er vant til i universitetsverdenen. Rapporten har vi valgt at opdele i tre dele - den første del (kapitel 2) beskriver DADIU-spilproduktionsforløbet. Den anden (kapitel 3) er en overordnet introduktion til Source, opbygningen og organisation. Og den tredie og sidste (kapitel 4) går mere i dybden med udvalgte aspekter. Den sidste del er meget programnær, og bør ikke læses fra ende til anden. Underkapitlerne kan læses efter behov, mens man arbejder med Source. Rapporten bliver som nævnt meget programnær, og forudsætter derfor, at læseren kan bruge C++. Vi har valgt at bruge engelske fagtermer, hvor vi mente, at danske oversættelser ville forvirre mere end gavne. I det efterfølgende afsnit findes en 3

5 oversigt over termer og forkortelser. 4

6 1.1 Definition af termer Følgende er en liste af termer som vi benytter løbende i denne rapport: AI - Forkortelse af Artificial Intelligence. Kunstlig Intelligens. Brush - Et geometrisk objekt i verdenen. Der skelnes mellem to forskellige typer brushes i Hammer. World brushes som er et solidt objekt der ikke kan flyttes eller tilintetgøres i selve spillet. Brush-entiteter som er entiteter knyttet til volumen, som brushen udspænder. Bumpmapping - En teknik der giver en tekstur yderligere detaljer uden at gøre formen på overfladen den ligger på mere kompleks. Teknikken giver en plan overflade en slags dybde. Klient-entitet - En entitet der bliver afviklet på klientsiden af Source motoren. NPC - Forkortelse af non-player character. En figur i spillet der ikke bliver kontrolleret af spilleren. Path-finding - Direkte oversat betyder dette sti-søgning. Udtrykket bruges ofte i en algoritmisk forbindelse, hvor formålet er at finde fra et punkt frem til et andet i f.eks en virtuel verden. SDK - Forkortelse for Software Development Kit. Server-entitet - En entitet der bliver afviklet på serversiden af Source motoren. Spekular refleksion - En del af Phongs lysmodel, der benyttes til visuelt at efterligne lys. Trigger - Udløser. Bliver brugt i sammenhæng med entiteter, til at informere om tilstandsændringer. Wiki - En wiki et internetværktøj til i fællesskab at se og vedligeholde en hjemmeside. 5

7 2 DADIU DADIU[2] - Det Danske Akademi for Digital Interaktiv Underholdning - er et samarbejde mellem ni kandidatuddannelser og tre kunstskoler spredt ud over hele danmark. Formålet er at uddanne mange forskellige faggrupper i at lave computerspil. En grov opdeling af faggrupperne ville være de organisatoriske, de kreative og de tekniske. DADIU-forløbet består dels af fagspecifik undervisning på de deltagende uddannelser, en gennemgang af fællespensum i DADIU-regi og to fællesproduktioner. Fællespensum foregår som 3 ugers fællesundervisning på tværs af faggrupperne. Målet er at give deltagerne en basal indsigt i de andre faggruppers arbejde og skabe et fælles sprog. De to produktioner bliver løst i hold sammensat af folk fra de forskellige uddannelsessteder. Alle faggrupper, der befinder sig i en kommerciel produktion, er tilstede i dette forløb. Dette skal sikre, at det færdige projekt er en afrundet og realistisk produktion, dog i mindre størrelsesforhold. Der skal laves en spilbar prototype. Det har hvert deltagende hold fire ugers præproduktion og fire ugers reel produktion til. Først og fremmest er det de tværfaglige udfordringer og kulturforskellene mellem uddannelserne, der gør DADIU-produktioner mere realistiske end de opgaver, folk ellers løser på deres respektive uddannelser. Der er også rigelig udfordring til de forskellige faggrupper, dog er fokus væsentlig mere praktisk end teoretisk. Opgaverne, som nogle deltagere, især også datalogerne, vil blive stillet overfor i sådan en produktion, vil i visse tilfælde være mindre fagligt relevante end andre. DIKU er ny deltager i DADIU, så det var første gang, der var DIKUstuderende med i en DADIU-produktion i marts Som DIKU-studerende betød det, at vi ikke havde fået direkte spilorienteret undervisning eller deltaget i mere end en trediedel af fællespensumet. Fællesproduktionen marts 2006 var DADIUs første årgangs anden og afsluttende produktion. Til den første produktion blev der brugt et udviklingsværktøj, der hed Virtools[9], men det var der ikke stor tilfredshed med og de færdige produktioner kunne ikke frit distribueres. Så værktøjspakken blev skiftet ud med Valves Source, der ikke lider under den samme restriktive distributions aftale. Dog skal man eje Valve Softwares spil, Half-Life 2 - som Source oprindeligt er udviklet til - for at kunne spille DADIU-produktionerne. Half-Life 2 er et populært og anmelderrost første-persons-skydespil. Det har et delvist åbent SDK og bliver i forvejen brugt til mange hobbyproduktioner i form af modifikationer til originalspillet (se afsnit 4.1). 6

8 2.1 Dolores Dolores[3] er titlen på vores holds spilproduktion. Vi vil igennem rapporten hovedsageligt tage udgangspunkt i de erfaringer, vi gjorde os på vores hold. Vi vil dels prøve at give et indblik i, hvordan vi oplevede produktionen og bruge det som enkelte eksempler i vores tekniske introduktion til Source. Holdet bestod af: 1 instruktør, Jan Rahbek 1 spildesigner, Henrik Bennetsen 1 projektleder, Hans von Knut Skovfoged 2 grafikere/designere, Rune Hauberg Brimer (Lead Artist) og Susanne Møller Nielsen 1 lyddesigner, Frans Galschiøt Quaade 2 animatorer, Karsten Madsen og Jeppe Sandholt 3 programmører, Anders Thaulow og denne rapports forfattere; Bo Bendtsen og Lasse Laursen. Vi vil i afsnit 2.4 komme mere ind på, hvad de enkelte roller dækker over. 2.2 Produktions forløb Præproduktionen startede som nævnt fire uger før selve produktionen. Her var det instruktøren, spildesigneren, projektlederen og Lead Artist ens opgave at få på plads, hvilket spil de ville lave, hvordan historien og rammen skulle være, hvordan det skulle se ud og desuden lave en produktionsplan for at sikre et afrundet og spilbart slutprodukt. Designdokument, manuskript, concept art og produktionsplan blev udarbejdet i februar. Som programmører forberedte vi os ved at se på de praktiske forhold (se afsnit 2.3) og sætte os ind i Source. Det sidstnævnte gjorde vi ved at søge efter dokumentation og tutorials (se litteraturlisten og f.eks. My First Mod på Valves wiki[6]). Vi havde også en række møder med projektlederen, spil- og lyddesignerne så vi kunne få en overordnet idé om, hvilke udfordringer vi kunne forvente i marts. Produktionen løb igennem hele marts. Vi havde aftalt en almindelig arbejdsuge fra ni til sytten, mandag til fredag. Hver dag blev indledt med et morgenmøde. Morgenmødet blev brugt til at fortælle hinanden, hvad man lavede, og hvor langt man var med sine opgaver. Det var især projektlederen, der styrede mødet og sikrede sig, at folks opgaver overholdt produktionsplanen. Udover at møderne opfyldte et praktisk behov for kontrol med produktionsplanen, var de også meget motiverende, fordi man kunne høre, 7

9 at det gik i den rigtige retning på alle fronter. Selve arbejdsgangen foregik meget selvstændigt. Vi sad i det samme lokale, så hvis man havde brug for at snakke med nogen fra de andre faggrupper, spurgte man bare. Den flade stuktur vi havde på holdet, i modsætningen til en hierarkisk struktur, førte til et meget naturligt samarbejde. Vi spiste frokost i fællesskab og brugte også spisepausen til hyggelige, uformelle møder. Ikke alle faggrupper var med i hele produktionen. Vores animatorer deltog kun i de to midterste uger. Derfor var meget af planlægningen og pipeline en tilrettelagt efter hvornår, de var tilgængelige. Det var ikke de store dramaer, der prægede hverdagen. Vi arbejdede fremad mod deadlinen og da vi nærmede os den, arbejdede vi endnu mere. Ellers var den daglige rutine kun afbrudt af spiltest og besøg af DADIU og branchefolk. Mod slutningen af forløbet blev visse ressourcer, der ikke kunne deles, flaskehalse. Det krævede mere koordination og ledelse. Projektlederen sørgede for at optimere udnyttelsen af de kritiske ressourcer. Der var dog mod afleveringsfristen konflikter, der blussede op, som ikke blev bilagt. Det førte heldigvis ikke til nedbrud i selve produktionen, men lagde lidt en dæmper på det gode humør. Under projektforløbet blev der udarbejdet et designdokument (bilag D). Projektlederen stod hovedsageligt for dette dokument, men det var tanken, at de forskellige faggrupper hver skulle lave et afsnit. Da designdokumentet skulle færdiggøres var programmørernes arbejde med spillet langt fra slut. Vi vurderede, at hvis vi skulle skrive et afsnit til designdokumentet, ville vi ikke kunne nå at få spillet færdig i den tilstand, vi ønskede. Vi står ved vores prioritering af selve produktet, i retrospekt må vi sande, at det var en fejl udelukkende at lade vores projektleder skrive vores afsnit. Hvis vi havde prioriteret programmørnotaterne i designdokumentet minimalt, ville det have gjort en verden til forskel. Det var heldigvis ikke dårligt humør og konflikter, der prægede produktionen, tværtimod var det god stemning og engagement, der bedst beskrev vores produktionshold. Det færdige spil var et, vi alle var glade for. I bilag C er der billeder fra spillet, der i øvrigt kan hentes fra hjemmesiden: [3]. 2.3 Praktiske forhold Formålet med dette afsnit er at videregive nogle gode råd om de praktiske forhold, der er ved en DADIU-produktion. Som programmør på et DADIUprojekt forventes det, at du supporterer og vedligeholder de maskiner, holdet arbejder på. Eller i det mindste at stå for kontakten med det personale, der har ansvaret. Der er flere ting, man bør gøre for at forberede sig på projektarbejdet: Man kan sikre sig, at der er fungerende maskiner, og at de har installeret det software produktionsholdet har brug for. Man kan se en liste 8

10 i appendiks A over noget af det software, vi gjorde brug af til vores produktion. Vi fandt det uundværligt at have et versioneringsystem. Vores valg faldt på Subversion (SVN) der stort set gnidningsfrit kan integreres i Microsoft Windows Explorer med TortoiseSVN. Det er ikke nok at programmørerne kan bruge SVN, de bliver nødt til at sætte sig nok ind i systemet til at kunne lære resten af holdet at bruge det. Der findes et par gode manualer på nettet: [16] og [7]. Husk Murphys lov! Sørg for at der dagligt bliver lavet backup af serveren med versioneringssystemet. Husk at fortælle resten af holdet at det er kun er de ting, der er committed til versioneringssystemet, der bliver taget backup af. Under forløbet brugte hele holdet en wiki til at samle alle informationer om projektet. Og vi brugte siden til at koordinere og dokumentere vores arbejdsindsats og til at oprette en vidensdatabase. Det er værktøj, der skal være oppe at køre allerede fra dag et i præproduktionen. (I vores gruppe havde spildesigneren allerede sat en wiki op til holdet.) Alle fire punkter ligger udenfor programmørernes opgaver til selve spilproduktionen, men de er kritiske og skal løses. Og programmører er dem, der er bedst kvalificerede til at løse de opgaver på et DADIU-hold. 2.4 Arbejdspladsen og roller I det forrige afsnit (2.2) skitserede vi produktionsforløbet og den flade struktur vi havde i vores gruppe. Formelt set var spildesigneren, instruktøren og projektlederen den øverste ledelse i gruppen. Så længe det gik, som det skulle, havde folk selv lov til at bestemme over, hvordan de arbejdede. Det var kun de få gange, planen var ved at skride, at folk påtog sig deres lederroller og gav deciderede ordrer. Det førte til enkelte konflikter. Nogle handlede grundlæggende om forskellig prioritering, men de overskyggede ikke den fælles vilje til at lave et færdigt og afrundet produkt. Andre bundede i kreativ uenighed, for det meste pga. miskommunikation. Den sidste type konflikter, vi vil se lidt mere på, er nogle af de tværfaglige konflikter, vi oplevede. Næsten alle de delelementer af spillet, der blev lavet, krydsede ind over programmørernes fagområde. Når de færdige ressourcer - lyd, grafik, animation, baner osv. - skulle ind i selve spillet, var det programmørerne, der for det meste lavede den sidste efterbehandling. I vores produktion var programmørerne den højeste autoritet, omkring hvad der var teknisk muligt, og hvor meget arbejde, det ville kræve. Et konkret eksempel var lydsystemet. Lyddesigneren havde skitseret et avanceret system, der bl.a. skulle kunne væsentligt mere end Sources eksisterende system. Det ville bestemt være 9

11 muligt at implementere, men vi vurderede, at det ville tage alle de programmørressourcer, vi havde, hvis ikke mere. Men så ville vi ikke have kunnet lave noget andet. Dette er også et godt eksempel på, hvor smidig vores flade stuktur var: Lyddesigneren og programmørerne tog diskussionen direkte med hinanden og fandt frem til praktisk mulige løsningsforslag. På vores hold var vi meget heldige med, at alle faggrupperne var fleksible nok til at krydse indover hinandens faggrænser. Det betød f.eks., at vores spildesigner stod for det meste af bane-implementationen, at vores lead artist selv fandt ud af de fleste tekniske krav for modeller til Source og at vores projektleder og instruktør lavede nogle af de trivielle teksturer og banedesign. Denne fleksibilitet gjorde, at alle folk hele tiden hjalp til, også selvom alle opgaverne ikke altid lå i deres ansvarsområde. De tværfaglige udfordringer var dem, der gav os allermest i DADIUforløbet, og det bør betrages som et af de vigtigste aspekter for at deltage i et sådan projekt. 2.5 Konflikter og problemer Vores hold oplevede en række problemer under selve spilproduktionen (se afsnit 2.2 og 2.4). Fra forfatternes perspektiv var vores problemer minimale i forhold til nogle af problemerne de andre DADIU-hold oplevede. I dette kapitel vil vi nævne nogle af problemerne, som andre grupper oplevede i deres produktionsforløb for at fremhæve, at det mere er reglen end undtagelsen, at der opstår problemer. De er kun medtaget for at skabe et mere alsidigt billede af, hvilke udfordringer et DADIU-forløb kan indeholde. I en enkelt gruppe var der folk i ledelsen, der faldt fra mellem præproduktionen og selve produktionen. Det kan give stor turbulens og uro i en gruppe, når der pludselig skal hyres en ny person til jobbet udefra. Der kan nemlig være forskel på motivationen til et betalt job og et uddannelsesprojekt. Der var også grupper der havde problemer med faglig fleksibilitet og kommunikation. Det er meget vigtigt, at kommunikation ikke kun går fra ledelse og ned til fodfolket. Man bliver nødt til at være villig til at lytte til hinanden og stole på hinandens faglighed, hvis der ikke skal opstå uløselige problemer. Fordomme om, at kunstnere er nogle følsomme gemytter, der ikke vil gå på kompromis med deres kunstneriske ambitioner, gik også i opfyldelse i visse grupper. Det er en balancegang mellem, hvornår man skal stå ved sine ambitioner, eller hvornår man skal kill your darlings. Designvalg, kreative og tekniske kan også vise sig at være beskæmmende for det færdige produkt. Der er ikke andet at sige til det, end 10

12 at man skal være dygtig og heldig til at træffe de rigtige valg. Det er ikke tid til ombestemme sig mange gange. Der skal sættes realistiske mål. Vores gruppe havde planlagt en minimumsløsning for alle spillets aspekter. Så blev der bygget ovenpå den plan med yderligere indhold og funktioner. På den måde var det lettere at skære fra, når ressourcerne blev knappe. Hvis man ikke følger en lignende fremgangsmåde, kan man risikere at ende med et spil, der helt mangler visse aspekter. I sidste ende afhænger meget af forløbet, og hvor mange problemer man får undervejs, af kemien mellem holdets medlemmer. Det er ikke nok, at folk er fagligt kompetente. DADIU-produktionsforløbet er meget intenst og tidskrævende, så det afhænger af, hvor heldig man er med sin gruppe. Hvis man ikke fungerer godt sammen, bliver det en meget hård opgave at komme igennem. Man skal ikke undervurdere, hvor meget det betyder for projektforløbet, at holdets deltagere lægger vægt på de sociale aspekter. 11

13 3 Hvad er Source? Source er en spilmotor udviklet af Valve Software[8]. Motoren blev udviklet til spillet Half-Life 2 og er siden blevet brugt i andre spil og til et utal af modifikationer af spillene (se afsnit 4.1). Source følger mange af de traditioner, som Quake[10] grundlagde. De har spilstilen tilfælles - første-personsskydespil. Udover det har de også en åbenhed overfor at ændre på spillet tilfælles, bl.a at ændre på reglerne eller spillets design. Source er en ekstrem skalerbar motor med mange kraftfulde komponenter som f.eks. animationssystemer, GUI, kunstig intelligens, netværkskode og fysikmotor. For at få et overblik over hvad spilmotoren Source kan, er det en meget god idé at spille Half-Life 2 igennem. Det giver et rigtig godt indblik i, hvad motorens muligheder er. Når man så ønsker at implementere noget nyt, der i større eller mindre grad ligner noget, man har set i Half-Life 2, har man muligheden for at kigge på ressourcerne (f.eks. kode, såvel som bane - se afsnit ) for at lære, hvordan det er gjort før. Valve har frigivet et SDK til Source. SDK et indeholder en delvist åben kildekode og en samling af værktøjer. En stor del af værktøjet er konverteringsværktøjer, der skal gøre det muligt at importere ressourcer til spilmotorens format. De mest interessante dele af SDK et er kildekoden og leveleditoren Hammer, der gør det muligt at ændre spillet fundamentalt. Source er en meget kraftfuld motor, men det er som tidligere nævnt ikke al kildekoden, der er frigivet i SDK et. Du får ikke lov til at lave din egen eksekverbare main-fil eller til at kigge under motorhjelmen på de grundlæggende grafik- eller fysikmotorer. Source burger den kommercielle Havok[4] pakke til simulering af fysik. Dvs. til at udregne de fysiske objekters opførsel i spilverdenen, når de kastes rundt, eller når modstanderne falder sammen som kludedukker. I resten rapporten vil vi kort komme ind på nogle af de værktøjer, vi brugte i produktionsforløbet, men hovedsageligt vil vi dykke ned i kildekoden og dennes opbygning og design. 3.1 Kilder til Source På trods af at Source ikke er en veldokumenteret spilmotor, findes der en stor brugerbase og et stort fællesskab omkring den. Der er en god chance for, at andre mennesker har forsøgt at implementere et eller andet, som man selv sidder og kæmper med. Vi brugte selv en del tid på at undersøge andre modifikationer, der allerede fandtes og var dokumenterede: [17] og [15]. Selvom det ikke nødvendigvis giver indsigt i de problemer, man selv skal løse, er det stadig meget fornuftigt at få indblik i, hvad andre har forsøgt, og lære af deres erfaringer i Source. 12

14 Valves wiki[6] var den kilde, vi brugte mest. I resten af rapporten vil vi mange gange henvise til sider i denne wiki. På trods af dens mangler er det den eneste officielle, online kilde til Source. 3.2 Klient-server-design Source er bygget efter en klient-server-model. Dette designvalg gennemsyrer hele Source og medfører, at også et single-player-spil vil have en klientog en serverdel. Dvs. at et Source spil kører en serverproces og mindst en klientproces. Det er en åbenlys fordel, hvis man skal lave et multi-player-spil, men hvis man står med et klassisk single-player-spildesign kan det være sværere at acceptere, at man skal sætte sig ind i en klient-server-arkitektur. Der er dog et par fordele ved det; helt åbentlyst er der færre omkostninger ved at få tilføjet mulighed for multi-player til sit spil senere, hvis man allerede har designet sin kode til at understøtte et klient-server-design. Derudover opfordrer det også til pænt kodedesign. Man er tvunget til at tænke sig om pga. det klare snit mellem klient og server. Det betyder dog også, man skal tænke kreativt for at gøre ting, der ikke helt passer ind i interfacet mellem klient og server. Da klient-server-kommunikation skal kunne foregå over nettet, er der visse begrænsninger på, hvad man kan sende mellem de to dele. Alene det at synkronisere de to dele er en stor udfordring. Der er en meget traditionel ansvarsfordeling i Source - det er serveren der vedligeholder den virtuelle verdens tilstand, og klienterne der gør den tilgængelig for brugerne. 3.3 Entiteter Den virtuelle verden, som Source simulerer, består af aktive og inaktive elementer. I Source bliver de aktive elementer kaldt for entiteter, og de inaktive for brushes. Fjender, venner, møbler, våben og triggers er alle sammen entiteter. Det er entiteterne, der introducerer liv i en ellers statisk verden kun bestående af ubevægelig geometri. Entiteterne kan betragtes som byggeklodserne for en interaktiv verden, og samtidig tilbyder de også en uafhængig og nem tilgang til at introducere nye funktioner i Source. Der findes tre hovedtyper af entiteter i Source: Logical Entity - En såkaldt logisk entitet. Denne type entitet har ikke nogen position i verdenen eller nogen visuel repræsentation. Praktisk set har entiteten faktisk en position, men denne er for alle intentioner og formål unødvendig. En logisk entitet eksisterer kun for at kunne modtage input, udføre en given funktion og til sidst sende output afhængig af hvad entiteten skal kunne. Et eksempel på denne slags entitet er en tæller, der tæller det antal fjender, man har nedkæmpet. 13

15 Model Entity - En entitet med en tilknyttet model som visuel repræsentation. Den kan bevæge sig igennem verden og er ofte interaktiv. Et godt eksempel på denne slags entitet er en NPC. Brush Entity - Disse entiteter er skabt fra brushes, og udgør et volumen i spilverden. Ofte bruges disse entiteter som triggers, der bliver aktiveret, når brugere bevæger sig ind i entiteten. En anden funktion ville være døre og elevatorer. Bliver en brush brugt som en entitet, går den fra at være et statisk element til et aktivt element. Omvendt kan man lave modeller om til statiske brushes. Hver af disse kan bruges til samme formål, men der vil ofte være en type, der egner sig bedre end de andre. I det udleverede SDK til Source er kildekoden til mange af entiteterne, som blev brugt til Half-Life 2, også tilgænglige. Desværre er dog ikke alle tilgænglige. F.eks. er lydentiteten evn_soundscape (omtalt i kapitel 4.8) ikke direkte at finde i den udleverede kildekode Input/Output systemet Næsten al dynamik, Source kan levere, er resultatet af, at forskellige entiteter kommunikerer sammen og reagerer på kommunikationen. Kommunikationen, der foregår iblandt entiteterne, er ofte stærkt afhængig af den verden, de befinder sig i. På grund af dette bliver kommunikationen tilrettelagt i Valves level-editor - Hammer - ved at bruge et system ved navn Input/output system, eller forkortet IO System. Alle entiteter i Source kan kommunikere vha. et antal input og output. Dvs. en entitet kan sende et output eller modtage et input fra en anden entitet. Ethvert output kan forbindes med ethvert input, hvilket tillader avanceret og kompleks interaktion mellem forskellige entiteter. Et output bliver som regel sendt afsted når en entitetstilstand ændrer sig, f.eks. hvis der bliver trykket på en knap, en dør er blevet lukket, eller et ur har talt ned. Et input sørger for en tilstandsændring ved en entitet. Når et output, som er forbundet med et andet input, sendes afsted, bliver inputtet aktiveret. Et eksempel på dette kunne være, at spilleren bevæger sig ind i et område, hvilket medfører at et output bliver sendt til en lysentitet. Områdets output var forbundet med lysets tænd -input, og dermed tændtes lyset. Teoretisk set er der ingen begrænsning på antallet af reaktioner, som man kan bygge ind i én lang kæde. Vi vil beskrive selve input/output-systemet nærmere i afsnit

16 3.4 Hammer Som tidligere nævnt er Hammer Valves egen level-editor, der følger med Sources SDK. Bemærk at definitionen level-editor ikke er bred nok til at dække alt det, som Hammer reelt kan bruges til. For at give et indblik i hvor omfattende Hammers indflydelse på et Source-baseret spil er, skal man blot se på Half-Life 2. En stor del af indholdet, der findes i Half-Life 2, er blevet sammensat eller konstrueret i Hammer. Hammer bruges til alt fra at bygge spilverdenens struktur til at definere dets indhold, funktioner og reaktioner. Man vil hurtigt finde frem til, at Hammer spiller en stor rolle i et produktionsforløb. På trods af at denne rapport dækker de mere programmelle aspekter af en produktion i Source, er Hammers involvering så stor, at den ikke kan undgås at benævnes. Dog vil vi ikke komme særlig dybt ned i Hammer, da den er godt dokumenteret i forvejen. En uddybende dokumentation til brug af Hammer i forbindelse med Source kan findes på Valves wiki[6]. 15

17 4 Arbejde i Source Formålet med dette kapitel er at dele vores erfaringer i de områder, vi har beskæftiget os med i Source. I kapitel har vi udledt nogle konkrete tips til at programmere i Source. Derefter uddyber vi de specifikke emner vi har beskæftiget os med. Som nævnt i kapitel 3.2, er Source bygget efter en klient-server-model. Størstedelen af koden, som vi skrev i forbindelse med vores spil Dolores[3], blev sat på serversiden, da spillet ikke implementerer nogen form for multiplayer. Konsekvensen er, at informationerne i denne rapport ikke nødvendigvis gælder for funktionaliteten, der skal implementeres på klientsiden af Source. Vi vil gøre læseren opmærksom de steder, hvor vi ved, der er forskel mellem implementationen på klient- og serversiden. 4.1 Partiel eller fuldstændig konvertering Inden man kaster sig ud i et så omfattende projekt som at skabe et spil i Source, er der en beslutning, man skal tage på forhånd. Enten at skabe en partiel eller en komplet konvertering af Half-Life 2. Dvs. hvor meget af Half-Life 2 man har tænkt sig at genbruge i sit eget spil. Beslutningen kan ændres undervejs, dog er det ikke helt uden omkostninger. Forskellen mellem de to er, om Sources SDK stiller alle Half-Life 2 s ressourcer til rådighed. Ved begge valgmuligheder er der fordele og ulemper. Partiel konvertering Den største fordel ved en partiel konvertering er, at alle Half-Life 2 s ressourcer står til rådighed. Hvis det er første forsøg på at skabe et spil i Source, er det helt klart denne variant, der skal vælges. Intet er mere hjælpsomt end at kunne se, hvad andre har gjort, og hvordan det fungerer. Ulempen er, at det kan virke overvældende, da Half-Life 2 har en meget stor mængde indhold i alle former. Det vil tage tid at forstå, hvordan det hele hænger sammen, og hvordan man kan bruge det til sin egen fordel. Fuldstændig konvertering Man kan også vælge kun at bygge på spilmotoren. Ulempen ved den fuldstændige konvertering er at meget skal laves fra bunden. Alle Half-Life 2 s ressourcer, dvs. lyd, grafik, mange entiteter og NPCer, kan ikke genbruges. De er naturligvis stadig til rådighed som reference, men for at spillet kan kaldes for en fuldstændig konvertering, må kun den grundlæggende spilmotor genbruges. Det er det rette valg hvis man vil lave et spil der er grundlæggende forskelligt fra Half-Life 2. 16

18 4.2 Programmering i Source At spille Half-Life 2 igennem giver et godt overblik over og samtidig indsigt i, hvad der kan lade sig gøre i Source. Men at finde ud af hvordan de forskellige spilmekanikker er implementeret, er dog ikke altid så lige til. Heldigvis er der ofte folk, der har forsøgt noget lignende før. Bl.a. denne hjemmeside [5] indeholder en masse information om diverse funktioner, der ligger skjult i Source Ungarsk notation Valve har valgt at benytte sig af ungarsk notation[12] i deres kodestil. Ungarsk notation benyttes til at hjælpe programmører med at gennemskue, hvilke egenskaber forskellige variabler har. Notationen afslører ofte, hvilken type variabel der er tale om (integer, float, double osv.), og om denne tilhører en klasse. Ydermere har Valve vedtaget den konvention, at klasser, der hører til serversiden, hedder CNavn, mens klasser, der hører til på klientsiden, hedder C_Navn. Begge konventioner anbefaler vi, at man følger for lettere at læse Valves kode Konkrete tips til programmering i Source Vejledningerne (tutorials) der ligger på Valves wiki[6] er et godt udgangspunkt for at lære at programmere i Source. Til gengæld er det svært at opnå en dybere forståelse af de enkelte objekter og funktioner ud fra disse vejledninger. Vi brugte meget energi på at gennemskue den eksisterende kode og finde de funktioner, vi havde brug for. De følgende elementer, funktioner såvel som objekter, er desværre ikke beskrevet i den udleverede dokumentation til Source. Situationerne, som elementerne kan blive benyttet i, er dog så mangfoldige, at de ikke burde undlades. Gennemgangen af de følgende elementer kan ikke betragtes som udtømmende forklaringer, da vi ikke selv har forstand på deres fulde funktionalitet. Listen skal betragtes som et vink om, hvilke vigtige elementer der ikke burde overses. gpglobals Dette objekt indholder diverse globale tilstande og informationer, så som den globale tid i spilverdenen. Vi brugte f.eks objektet til at finde det næste tidspunkt hvor forskellige entiteter skulle fortage beslutninger i spilverdenen. g peffects g_peffects bruges til at visualisere forskellige effekter indenfor spilverdenen, som f.eks. støv- eller lyseffekterne ved pistolaffyring. Et 17

19 eksempel kunne være en af fjenderne fra spillet Dolores som opvivler støv, når den kolliderer med gulvet. devmsg() Denne funktion udskriver en besked til skærmen, når spillet afvikles. Det er yderst nyttigt, når man forsøger af afprøve forskellige dele af sit program. ConVar ConVar er en makro, der gør en variabel tilgængelig fra konsollen i Source. I kapitel 4.9 vil vi uddybe brugen af konsollen. Kort sagt giver denne adgang til en stor mængde af kommandoer og informationer under spillets kørsel. Tilgang til disse variabler under spillets afvikling, gør det nemt at teste og fintune dem. 18

20 4.3 Entiteter Som tidligere nævnt findes der tre overordnede entitetstyper i Source: Logical Entity, Model Entity og Brush Entity. Praktisk set er de tre typer kun vejledende. De giver et godt overblik og hjælper med at afgøre, hvilken type entitet man har brug for. Hver især har entiteterne en klasse, de nedarver fra, der tilbyder funktionalitet specifikt for den type entitet. Logiske entiteter nedarver fra CLogicalEntity, modelentiteter fra CBaseAnimating og brush-entiteter fra CBaseToggle. I tilfælde af at den nye entitet ikke falder i en af de kategorier, som de tre typer tilbyder, er det oplagt at lade den nye entitet nedarve fra CBase- Entity. Denne klasse er absolut basis for entiteter, og det er denne klasse, som de tre typer også nedarver fra. Den reelle nedarvning ses i figur 1. Figur 1: Nedarvning af entitetsklasser i Source. For at opnå et hurtigere resultat, når man er i gang med at lave en ny entitet, er det en mulighed at omskrive en af de eksisterende Half-Life 2 entiteter. I det tilfælde er det oplagt at vælge den entitet i Half-Life 2, der på forhånd kan nogle af de ting, man ønsker. Ulempen ved at vælge en eksisterende entitet er, at koden til denne ikke umiddelbart er til at gennemskue. Derfor er det uden tvivl en fordel selv at sammenkæde en entitet fra bunden. En gennemgang af en meget enkel entitet findes i kapitel Tilstande og funktioner Formålet med dette kapitel er at skitsere nogle af de tilstande en entitet kan indtage, samt vigtige funktioner. Entiteters tilstande i Source Udover de tilstande som en entitet er programmeret til at kunne indtage, kan man betragte en entitet som havende nogle overordnede tilstande i spilverdenen: Før den bliver oprettet, mens den eksisterer, og efter den er blevet slettet. 19