1. Indledning (Fælles)

Transkript

1 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 1/99 Indholdsfortegnelse 1. Indledning (Fælles) Idéen Problemstilling Problemformulering Afgrænsning Organisation (Heino) Projektforløb Struktur og styring Timeregistrering Referenceramme (Vakis) Produktbeskrivelse Markedet Efterspørgsel Konkurrenter SWOT Konceptet Overblik Gameplay detaljer Hovedperson og story (Kim) Hovedpersonen Baggrundshistorie Historien Principper Gamedesign (Heino) Overordnet gameplay Aktivitetsdia-grammer Styring Udstyr D modellering (Martin) Enginevalg Formater Polycounts Concept til ingame De første fjender Abernes udseende (Jonas) Vagternes udseende Andet 3D i verdenen Teksturering (Jonas) Teksturering i spil Seamlessly Tiling Textures Randomly Tileable Sets Decals Alpha Channels

2 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 2/ UV-based textures Animerede texturer eller sprites Partical Systems Shaders Visuel stil Leveldesign Generelt leveldesign Hvorfor Unreal Tenochtitlan Eksempler på levels Interface (Vakis) Heads up display Farver i HUD Opsumering Afslutning

3 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 3/99 1. Indledning (Fælles) 3

4 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 4/ Idéen 1.2 Problemstilling 1.3 Problemformulering 1.4 Afgrænsning Udgangspunktet for dette projekt var, at lave en prototype til et spil, ud fra vores egen idé og historie. I stedet for at fortsætte produktionen fra vores 2. semester projekt, som var et middelalderspil, har vi valgt en anden historisk reference til dette projekt, nemlig azteker-verdenen. Idéen bag dette projekt er, at lave et spil, som tager udgangspunkt i den klassiske og populære 1st person shooter, men med nogle ekstra udfordringer, så som intuitiv gådeløsning. Spillet tager udgangspunkt i en moderne azteker-verden, hvor man skal kæmpe sig vej gennem diverse opgaver. Vi vil lave en prototype som kan vise det basale gameplay i spillet, samt vise det grafiske udseende vi ønsker. Med udgangspunkt i Unreal 2 Enginen vil vi udvikle et anderledes 1st person shooter spil, som indeholder nogle ekstra elementer, ud over bare at sigte og skyde. Unreal 2 Enginen er som regel associeret med traditionelt shoot'em-up gameplay, men vi ønsker at tilføje elementer til vores prototype, som gør spillet til noget lidt ud over den traditionelle oplevelse, bl.a. i form af en idé om innovativ gådeløsning. Ydermere skal man træffe valg undervejs, som har direkte indflydelse på spillets afvikling. Unreal 2 Enginen er utrolig fleksibel og derfor er den utrolig velegnet til spil som foregår i 1. persons perspektiv. Først og fremmest vil vi lave et level. Dette level skal være spillets introduktionslevel, som placerer spilleren i historien og som giver en introduktion til hvad resten af spillet kommer til at handle om. Derudover vil vi lave våben og udstyr, som passer til den kultur vi definerer og som bliver bedre undervejs i spillet. I projektet ønsker vi også at vise vores nye user interface, og hvordan det vil hjælpe spilleren i spillet. De områder vi vil koncentrere os om i løbet af produktionen er: Storytelling Leveldesign 3D modellering Teksturering Interface design Gamedesign Med udgangspunkt i et klassisk FPS spil, med en historisk referenceramme, vil vi udvikle en prototype af et spil, som vi ønsker skal foregå i en aztekerverden, som vi forestiller os den vil se ud, hvis aztekerne ikke var blevet udryddet. Da det ikke er muligt at lave et helt spil på de 3 ugers produktion (4 uger, hvis man inkluderer en uges workshop i Storytelling ved Ernest Adams) vi har, så er der visse elementer vi ikke kan nå at få med. Derfor vælger vi at afgrænse vores projekt på følgende områder: Scripting og programmering: Der vil kun forekomme et minimum af 4

5 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 5/99 ændring i scripts, som vil bestå af de mest nødvendige ændringer for at få spillet til at fungere. Markedsføring: Vi laver ikke en stor markedsføringskampagne med omfattende analyser, men vi vil beskrive vores målgruppe og se på hvordan vores produkt befinder sig på markedet. Lyd: Vi vil ikke lave lyd og musik selv, men vi vil beskrive og muligvis implementere enkelte lydeffekter for at understøtte gameplayet og temaet. Jura: Vores prototype skal ikke udgives og derfor vil vi ikke koncentrere os om evt. copyrightoverskridelser. User Interface: Vores interface vil ikke blive implementeret i enginen, men kun blive vist og forklaret som et eksternt system. Animation: De modeller der vil komme ind i spillet bliver ikke animeret. 5

6 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 6/99 2. Organisation (Heino) 6

7 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 7/ Projektforløb 2.2 Struktur og styring Organisationen af denne projektperiode har været bygget op af en researchperiode og en egentlig produktions-/projektperiode. Hele semesteret startede efter sommerferien med undervisning, som også var en del af den research der skulle gøres inden vi gik i gang med projektet, men herudover skulle vi også sætte os ind i enginen og hvad der ellers skulle bruges af teknologi for at lave hvad vi ønskede. Forrige semester arbejdede vi i en anden engine og det betød at der var en del ting der skulle genlæres, for at kunne forstå og bruge den nye engine. I research-perioden var vi i en større gruppe end den som producerer dette projekt. Dette skyldes at vi var flere der var interesserede i at arbejde med denne engine (Unreal 2 enginen) og at der derfor var god fornuft i at samle kræfterne på at få researchet. Vi tog som udgangspunkt fat i et projekt som vi alle havde en interesse i på en eller anden måde. Kort fortalt gik dette projekt ud på at skabe et cooperation spil (altså et spil hvor man samarbejder med andre spillere), baseret i rummet, hvor man kæmpede som en lille flok kamptropper. Dette projekt gav gode muligheder for at undersøge mange forskellige dele af enginen og hvad der hertil hørte. Der skulle naturligvis researches i hvordan man laver et level og får det til at virke, både for én spiller og for op til 4 spillere samtidig. Der skulle også laves specielle våben, dvs. de skulle både modelleres og scriptes til at virke efter hensigten. Derudover skulle vi finde ud af hvordan man importerer modeller, teksturer, lyde, animationer osv. På Bilag 2.1 kan man se hvordan vores faseplan for hele perioden så ud og hvornår vi havde planlagt at gøre hvad. Efter efterårsferien kom så en uges undervisning i storytelling ved Ernest Adams, og herefter fulgte den egentlige projektperiode på 3 uger. Her delte vi researchgruppen op i de endelige grupper som skulle producere hver deres koncept og prototype. Herfra kunne vi så begynde at producere ud fra de ting vi havde researchet os frem til. Ud over den overordnede plan for perioden (faseplanen), som kort blev berørt i sidste afsnit, så lavede vi også en mere detaljeret plan, vores detailplan. Hvor man i faseplanen inddeler projektet i nogle faser, som hver udgør deres delmål på vej mod det endelige mål, går man i detailplanlægningen mere ud af at uddelegere opgaverne til de enkelte gruppemedlemmer. Detailplanlægningen består i princippet kun af de opgaver som skal løses. Det er en slags objektorienteret plan over de opgaver som skal løses og i hvilken rækkefølge de skal løses. Man deler alle opgaverne i projektet ind i nogle grupper og i hver af disse grupper finder man så ud af hvilke opgaver der er nødvendige at løse før andre og hvad der altså skal tages hul på først. Det kan skitseres således: 7

8 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 8/99 Illustration 2.1: Eksempel på detailplanlægning. Nogle opgaver er afhængige af at andre opgaver er løst først, andre opgaver er uafhængige. Som man kan se på modellen, så er det altså ikke helt ligegyldigt hvilke opgaver der bliver lavet hvornår. Det er selvfølgelig meget afhængig af opgavens type, men ser man lidt nærmere på figuren, så kan man se at det umiddelbart er muligt at gå i gang med første opgave i gruppe 1, da den ikke er afhængig af andre opgaver. Man kan dog ikke gå i gang med opgave 2 før opgave 1 er færdig, da visse elementer fra opgave 1 skal bruges i opgave 2. Går man helt til bunden af gruppe 1 kan man se, at opgave 4.2 er afhængig af to andre opgaver. Ikke nok med at man skal have opgave 4.1 lavet færdig før man kan gå i gang med denne opgave, så er opgaven også afhængig af at opgave 2.2 er løst. I gruppe 2 kan man også straks gå i gang med opgave 1, men for at løse opgave 2, skal man både have løst opgave 1 fra denne gruppe og opgave 2 fra den røde gruppe 1. På den måde kan opgaverne i de forskellige grupper altså også være afhængige af opgaver fra andre grupper. Gruppe 3 demonstrere at man godt kan udskyde opgaver til sent i processen, hvis ikke andre opgaver er afhængige af denne og at man altså skal sørge for at planlægge de sådan, at de opgaver der skal muliggøre senere opgaver bliver løst hurtigst muligt. Endelig kan man også komme ud for at en gruppes opgaver ikke er 8

9 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 9/99 umiddelbart afhængige af hinanden, så man altså kan løse opgaverne fuldstændigt uafhængigt af hinanden. Med opgavestrukturen på plads kan man så gå i gang med at løse opgaverne. Det gjorde vi ved hjælp af vores PULS (Planlægning, Udvikling og Ledelses Skema), hvor de enkelte opgaver fra detailplanlægningen bliver skrevet ned på sedler, som de ansvarlige gruppemedlemmer så sætter ind i PULS'en og på den måde kan man altid se hvad der bliver arbejdet på og hvad der ikke er lavet endnu. Når en opgave er løst skrives det på kortet og kortet sættes tilbage i detailplanen og så ved man at det er muligt at forsætte med de andre opgaver der er afhængige af den netop løste opgave. For at forklare princippet bag vores PULS kan vi kigge på denne lille tabel: Person Concept artist (A) 3D artist (B) Texture artist (C) Opg A.1 Opg A.2 Opg A.3 Opg A.4 Opg A.4 Opg B.1 Opg B.2 Opg B.3 Opg B.3 Opg B.3 Opg C.1 Opg C.1 Opg C.2 Dato Level designer (D) Opg D.1 Opg D.1 9

10 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 10/99 Opg D.2 Opg D.2 Tabellen er et eksempel på hvordan et simpelt objekt kommer fra tegnebrættet og ind i enginen og hvordan det planlægges. Vores objekt kan følges via de orange bokse i tabellen. I dette, 100% tænkte eksempel, får vores concept artist (angivet som person A) til opgave at tegne en concept tegning til det ønskede objekt og det er altså hans første opgave i dette lille projektforløb. I mellemtiden har de andre personer i gruppen fået hver deres første opgave, som de løser imens. F.eks. kan vores 3D artist (person B) være i gang med at undersøge hvad kravene til hans modeller er og hvilke tekniske specifaktioner de skal overholde. Dagen efter får han overdraget concept tegningen fra A og kan så gå i gang med sin næste opgave, nemlig at modellere objektet. Den 16. kan B så give modellen videre til vores texture artist (person C), som så kan gå i gang med tekstureringen og dagen efter give objektet videre til level designeren, som kan implementere det i vores level. Her ses også fordelen ved detailplanlægningen. Så snart opgave A.1 er løst, hænger A kortet med denne opgave tilbage i detailplanlægningen, med en tydelig markering af at opgaven er løst, og så ved B at han kan gå i gang med opgave B.2, som er afhængig af A.1. Det fortæller også noget om vigtigheden ved at få opgaverne klar til tiden. Hvis vi kigger på et andet forløb gennem tabellen kan vi se, at vores concept artist den tegner et nyt concept færdigt til modellering og dagen efter går vores 3D artist i gang med at skabe modellen. Desværre opstår der problemer af den ene eller anden art og modellen bliver først færdig den 18. Det betyder at vores texture artist lige pludselig er arbejdsløs, da hans opgaver afhænger af de opgaver som vores 3D artist udfører. Det er altså vigtigt at få klaret de øverste opgaver i detailplanlægningen hurtigst muligt, så andre opgaver længere nede i hierarkiet ikke kommer til at stå på standby for længe. 10

11 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 11/ Timeregistrering For at holde styr på at opgaverne blev løst til tiden og i den nødvendige rækkefølge, blev der lavet et timeregistreringssystem. Her kunne vi planlægge hvornår der skulle arbejdes på hvilke områder og hvem der gjorde det. Udover timeregisteringssystemet havde vi også vores detailplan, hvor folk kunne se hvad der var lavet og hvad der manglede at blive lavet, men med timeregistreringssystemet var det også muligt at se hvornår og hvor lang tid folk brugte på de forskellige opgaver. Det betød også, at hvis en bestemt type opgave tog længere tid end planlagt, så vidste man, at hvis en sådan opgave skulle løses igen på et senere tidspunkt, skulle der afsættes mere tid til opgaven og på den måde har man hele tiden et overblik over hvad der nogenlunde kan nås i løbet af de 3 ugers projektperiode. Det betød også, at planlægningen på timeregistreringssystemet ændredes fra dag til dag, da man ved slutningen af hver dag kunne se hvad der var blevet nået og hvad der ikke var nået og hvis nogen var gået over til at løse andre opgaver, som var blevet mere presserende i løbet af dagen. For at forklare hvordan timeregistreringssystemet virker, vil vi her kigge på et tænkt eksempel af, hvordan systemet kunne se ud (vores egentlige timeregistreringssystem er vedlagt som bilag): Opgave P: 4 B: 4 P: 8 B: 8 P: 4 B: 2 P: 4 B: 4 Opgave 2 P: 4 B: 4 P: 4 B: 4 P: 4 B: 4 Opgave 3 11

12 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 12/99 Total B: 2 B: 1 P: 8 B: 7 P: 8 B: 4 P: 8 B: 8 P: 8 B: 8 P: 8 B: 9 P: 8 B: 7 Eksemplet ovenfor viser, hvordan vores egentlige timeregistreringssystem er opbygget. Øverst ses datoerne for hele projektperioden og ned langs venstre står de opgaver som personen skal løse. P betyder Planlagt og B betyder brugt. Alle tal er i timer. Så hvis personen er planlagt til at bruge 4 timer på opgave 1, så noterer han i slutningen af dagen, hvor lang tid han har brugt på opgaven. Timerne er planlagt efter ca. timer for en dags arbejde. Pauser og andet er altså inkluderet i planlægningen, men planen viser hvor mange timer en person har været afsat til den pågældende opgave. Nederst kan man så se hvor mange timer der har været planlagt i alt for dagen og hvor mange timer der er brugt i alt. 12

13 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 13/99 3. Referenceramme (Vakis) 13

14 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 14/ Produktbeskrivelse Når man laver en produktion kan der være tale om et produkt, en serviceydelse, eller en kombination af disse. Et produkt er håndgribeligt og det er et fysisk produkt du får stukket hinanden. En service er immaterielt og inkluderer ofte modtageren, som f.eks. en flyrejse, hvor servicen tilpasses kundens behov. Vi laver et produkt i vores produktion. Vi ønsker ikke at tilbyde kunderne nogen service som man ser Blizzard gøre med deres World of Warcraft hvor de udbyder servere til online spil, eller når man køber et webhotel til sin hjemmeside. Vi vil lave et produkt, som før eller siden skal på markedet og som skal sælges. Derfor skal man overveje ens position på markedet og vurdere hvor man skal sætte kræfterne ind for at få mest muligt ud af sit produkt. For at få et overblik kan man i første omgang kigge på den såkaldte PLC (Product Life Cyclus) kurve. Illustration 3.1: Denne PLC kurve viser hvordan computerspil generelt stadig er i stor vækst De udvides stadig til nye og større områder Hvis man ser på PLC kurven for computerspil generelt, så befinder det sig stadig forholdsvis lavt på vækstkurven. Computerspil udvider sig stadig til flere og flere målgrupper og til flere og flere anvendelsesområder, så der er stadig et stort potentiale indenfor computerstil. Det skyldes også at teknologien stadig er i rivende udvikling, så hver gang der kommer nye spil, har de nye USP'er (Unique Selling Points), som differentierer de nye spil fra dem der allerede er på markedet. Det kan derfor også være svært at sige hvornår toppen er nået og hvornår markedet er mættet og man finder på noget andet og bedre. Spørgsmålet er om det overhovedet sker? Ser man på andet underholdning, som f.eks. film, så har man jo produceret film i mere end 100 år og man bruger stadig mange millioner på at producere film. Der er måske nok sket en ændring i de medier som filmene udgives på, men film generelt er der stadig salg i. 14

15 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 15/99 Ser man så på vores spil specifikt, befinder vi os nok lidt længere op af PLC kurven. Vi bevæger os i en engine som trods alt er et par år gammel, men grundet den store fleksibilitet og de store udviklingsmuligheder kommer der stadig mange spil mods til denne engine, som har mange gode idéer. Det skal dog tages med i betragtningen, at en ny version af enginen udkommer i løbet af denne projektperiode og at man derfor nok vil se en tendens til at produktionen af mods og dermed spillernes foretrukne valg vil blive i den nye engine. Derfor har vi også valgt at placere vores spil således: Illustration 3.2: Denne PLC kurve viser hvor vores spil befinder sig i markedet. Placeringens skyldes at der er en ny udgave på vej af vores engine, men samtidig har vores spil alligevel nogle nye elementer Vi må nok indse at denne version af Unreal Enginen er på vej mod toppen, men spillet er stadig populært, både i sin originale udgave (Unreal Tournament) og via de mods som udgives. Ser man på siden som er en side der indeholder stort set alle mods til stort set alle spil, er der i alt 141 mods til Unreal Tournament 2004, hvoraf 48 er udgivet. Et af disse, kaldet Red Orchestra, et mod lavet af privatpersoner, er blevet et helt seperat spil og sælges nu gennem nettjenesten Steam. Det er lavet i Unreal Engine 2, men foregår under 2. verdenskrig og her er enginen blevet ændret så meget, at alt fremtidsstemning er væk, og erstattet af en gennemgående 2. verdenskrigs-stemning, der viser, hvor meget man kan med Unreal Engine 2. På trods af at enginen er på vej over toppen, så mener vi at vores spil trods alt bidrager med så megen nytænkning, at det stadig befinder sig i den positive vækstfase, som computerspil generelt befinder sig i. Det vi stiler efter at opnå med produktet er at lave en komplementering til markedet for computerspil. Vi ønsker at tilføre vores del af nytænkning til genren, men dog med det mål for øje, at overtage markedsandele fra andre 15

16 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 16/99 lignende spil. Vi ønsker ikke at henvende vores spil til en endnu ikke anvendt målgruppe inden for computerspil, men vi ønsker at vores produkt kan substituere andre FPS og/eller adventure spil på markedet, samtidig med at vi tilføjer noget nyt og attraktivt for spillerne. 16

17 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 17/ Markedet 3.3 Efterspørgsel Vores spil er et Buisness to Consumer produkt, med kort levetid. Vi leverer et produkt til en bruger, på et stort marked. Computerspil er et typisk Band Waggon produkt, hvilket man også kan se ud fra dets placering på PLC kurven. Typisk er det sådan, at et produkt i intro-fasen vil være et snob/veblen produkt. Et snob produkt er et produkt, som brugerne ønsker, alene for at være anderledes. Det passer også meget godt med intro-fasen, da der netop i starten af et produkts livscyklus vil være få der kender produktet og dem der er interesseret i produktet er folk som ser en mulighed i produktet, og som ønsker at anskaffe produktet for at være anderledes end andre. Et veblen produkt er et produkt som køberne køber alene fordi det er dyrt. Veblen-effekten indtræder som regel lige efter intro-facen, i starten af vækstfasen, hvor produktet bliver udbredt, men stadig er dyrt. I den største del af vækstfasen indtræder så Band Waggon effekten. Det er her produktet bliver købt fordi man gerne vil være som de andre og have de samme ting. Det er flere gange set hvordan et computerspil tiltrækker flere og flere kunder, fordi de hører fra andre at det er et godt spil og at de ikke vil være udenfor. Vi befinder os altså på et marked hvor kunderne køber vores produkt hvis andre køber det. Næsten halvdelen af Danmarks befolkning er Band Waggon forbrugere, så vores produkt befinder sig i hvert fald på et område hvor der er et stort markedsgrundlag. I og med at vi som sagt stadig vil fokusere på de spillere som allerede spiller FPS computerspil og lign., så vil vi kunne få fat i den samme Band Waggon effekt som allerede kører på fuld tryk inden for dette område. De fleste single player action spil lever typisk ikke meget længere end det tager at gennemføre spillet. Man skal altså finde måder at få brugeren til at blive ved med at vælge vores produkt. Det man typisk gør ved software med kort levetid, som altså f.eks. computerspil, er at udgive line extensions, eller nye versioner af spillet. På den måde kan man med jævne mellemrum bringe nye ting på markedet, som får brugerne til at bruge penge på vores produkt. Vores spil giver også gode muligheder for netop at udgive nye versioner, pga. hovedpersonens historie. Han er arkæolog og i denne udgave af spillet opdager han en moderne aztekerverden, men mulighederne er store for, at han i fremtidige versioner kan opdage nye områder og civilisationer. En anden mulighed man har i branchen for computerspil og andre produkter med kort levetid er, at skabe sig et god navn. Udgiver man et godt og nyskabende spil, så vil spillerne huske producentnavnet og næste gang man udgiver noget, så vil folk genkende navnet og være interesseret i det nye produkt også, alene ud fra producentnavnet. Hvis man vil vurdere hvordan man vil prissætte og producere sit produkt, kan det være en god idé at se på en Udbud/Efterspørgsels kurve. Det gælder om at finde et prisleje for ens produkt, som afspejler den efterspørgsel og det udbud der er på produktet. Vi befinder os heldigvis et sted hvor markedet er forholdsvis afbalanceret hvad angår dette. Band Wagon produkter er 17

18 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 18/99 produkter hvor der er opnået en balance mellem udbud og efterspørgsel og derfor er prisen ret fast på dette område. Computerspil ligger gerne på et ret fast leje, som ikke stiger ved nye udgivelser. Gamle spil som er ved at blive udfaset af markedet falder gerne i pris, men alle nye spil ligger på stort set samme pris lige meget hvad. Illustration 3.3: En udbuds/efterspørgselskurve viser sammenhængen mellem pris og mængde i forhold til udbud og efterspørgsel for et produkt Det betyder med andre ord, at vi nok ikke skal bekymre os så meget om efterspørgslen, hvis ellers vi får kommunikeret spillet ud i målgruppen. Som sagt ligger målgruppen ret fast omkring de faste spillere af denne genre (FPS). Dvs. at det primært er unge mænd, fra omkring 18 til 35 år, med en hvis interesse i Science Fiction. Der er rigeligt med folk at få fat i i denne målgruppe, både her i landet og uden for landets grænser. Man skal bare sørge for at henvende sig til dem på den rigtige måde og med de rette argumenter. F.eks. kunne grunden til at købe vores spil være, at man får en speciel verden at se, samt at ens beslutninger i spillet har direkte indflydelse på gameplayet. Det vil typisk være et produkts USP (Unique Selling Points) og ESP (Emotional Selling Points), som overbeviser en køber om, at dette produkt er noget for ham/hende. Måden hvorpå de får adgang til vores spil kommer også til at afhænge af den 18

19 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 19/99 endelige udgaves udformning. Bliver det en udbygning af det i forvejen eksisterende UT2004, så vil man ikke gå efter at sælge spillet i butikker som stand-alone vare. I så fald vil det blive lagt op til download forskellige steder på nettet (f.eks. tidligere omtalte Steam), hvor brugerne så betaler for at downloade spillet eller betaler for hver gang de spiller spillet. Dette fungerer dog bedst for multiplayerspil, så for vores vedkommende ville den bedste løsning være, at have et spil der river sig løs fra selve UT2004 og som kan sælges i sig selv, som et stand-alone produkt. Det ville så skulle sælges i butikker eller via online shops, hvor man betaler en gang og får sit spil, som herefter er ens eget til evig tid. Det vil altså sige, at vi grundlæggende mener at efterspørgslen for vores spil vil findes i gruppen af unge mænd mellem 18 og 35, med en interesse i Scince Fiction og single player action adventures. Vi vil tilfredsstille denne efterspørgsel ved at udgive en stand-alone version, som spillerne køber og spiller igennem. 19

20 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 20/ Konkurrenter Når det kommer det konkurrenter, er der umiddelbart tale om to typer i vores tilfælde: Arkæologspil, så som Tomb Raider og Indiana Jones, Generelle FPS-spil, som Half-Life, Doom og Quake. Mht. Tomb Raider og Indiana Jones, skal man tænke på, at det genremæssigt ikke er en direkte konkurrent, da de to spil er 3. persons action-adventure, mens vores spil er et FPS. Men essensen i arkæologdelen i spillene kan anses som konkurrent til vores spil. Vi har at gøre med en azteker-kultur, hvor man som spiller vil støde på mange interessant bygningsværker, templer, byer og generelt en verden, der vil være appellerende og spændende at gå på opdagelse i. Mht. Traditionelle FPS-spil, tænkes der her på den primære gametype i vores spil, hvilket vil være shooting. Spil som Doom 3 og Quake 4 kan anses som konkurrenter på områder, så som våben; et område, som er et af de bærende i begge spil. Uden effektive, futuristiske våben, fungerer hverken Doom 3 eller Quake 4. Som FPS vil våben ligeledes være et bærende element i vores spil. Og da det foregår i en fremtidig aztekerverden, skal vi også bruge en hvis mængde futuristiske våben. Vi går dog væk fra det højeksplosive tema i Doom og Quake og over i et magnettema til vores spil, da magnetisme vil være en vigtig del af vores aztekerverden. Når vi ydermere nævner Half-Life som konkurrent skydles det flere ting. Det primære vil være vores fokus på historie, der vil gøre Half-Life til en konkurrent. Ting som den dramaturgiske Exposition, hvor de vigtigste karakterer bliver introduceret, samt Komplikation, hvor den overordnede konflikt bliver præsenteret, er til stede i Half-Life og vil ligeledes være det i vores spil. Vi adskiller os dog fra Half-Life, ved at lave et mindre lineær historie. Hvor der mere eller mindre er en lige linje fra start til slut gennem Half-Life, vil vi forsøge os med en forgrenet historielinje; en såkaldt Foldback histore. Dette er en type historie, der vil indeholde forskellige grene at bevæge sig af, men vil indeholde forskellige hændelser og oplevelser, som alle grene går gennem og som er uundgåelige, hvilket f.eks. kunne være Aristoteles' Astonishment eller Anagnorisis. Sidst kan vi nævne Half-Life 2 eller det kommende spil Portal, når vi tænker på gådeløsning. Half-Life 2 præsenterede en Gravity Gun, der kunne flytte objekter så som tønder, og på denne måde skabe innovative løsninger på forhindringer i banen. Portal vil indeholder en Portal Gun, der kan lave en Portal, der, ligesom i Half-Life 2, skal anvendes til innovativ gådeløsning spillet igennem. Vi planlægger at gøre brug af magnetisme som gådeløsning i vores spil. Måske en mere avanceret form for magnetisme end vi kender den i dag, med det vil stadig give mulighed for innovativ gådeløsning, på linje med det vi finder i Half-Life 2 og Portal. 3.5 En SWOT analyse er en analyse af en virksomheds eller et produkts styrker, 20

21 Quetzalcoatl: Heino Jørgensen, Kim Etzerodt, Vakis Rigas 21/99 SWOT svagheder, muligheder og trusler (SWOT = Strengths, Weaknesses, Opportunities, Threats). Når man ser på sin SWOT analyse kan man som oftes se om et produkt er værd at gå i gang med at producere, eller om ens virksomhed har en fremtid på markedet. En SWOT analyse på vores spil er sådan set en samling af alle de informationer som er kommet frem i dette afsnit, angående hvordan vores produkt og markedet omkring det ser ud. Analysen er lavet med udgangspunkt i hvordan vi ønsker spillet kommer til at se ud i sin færdige version. Ser vi først og fremmest på vores produkts styrker kan de sættes op som følger: Vi har en stærk historie, der ikke tidligere er set. Mulighed for forskellige veje gennem historien. Godt og simpelt Interface. Innovativ gådeløsning (Du bestemmer selv hvordan du overkommer tegn). Et helt unikt univers der ikke tidligere er set. Det er muligt for spillerne på længere sigt at kreere deres egne levels. Dette er muligt pga den måde vi har bygget spillet op på. Næste punkt er så at finde svaghederne ved vores produkt. De er som følger: Gammel Engine, dette nedsætter vores muligheder for at lave evolutionær grafik. Der er ingen muligheder for "multiplay", dette nedsætter levetiden på spillet. Herefter følger mulighederne: Vi ligger grundstenen til en masse nye spil i denne genre som kan lede til fortsættelser. Mulighed for en større målgruppe ved at samle udfordringer for både adventurespillere og FPS-spillere i et spil. Og til sidst truslerne: Vi bevæger os i FPS genren, der er en af de mest benyttede genre indenfor game-industrien idag. Dette kan have en effekt der lyder på at vi drukner i mængden. Der er en risiko for at spillerne ikke kan finde ud af spillets nye elementer. Der er en risiko for at FPS spillere vil føle der er for lidt action og for meget gådeløsning eller at spillere der fokuserer på gådeløsning vil føle der er for meget action. Alt i alt mener vi dog at fordelene ved produktet er så mange, at vi kan retfærdiggøre en produktion. Vi har en del nyt at tilbyde og mener trods truslerne på FPS markedet, at vi godt kan trænge igennem. 21