Functional Requirements gaming industrie

[Verwijderd]

Ik ben laatste een kijkje wezen nemen bij een gameontwikkelaar in Rotterdam (coded-illusions), ze werken momenteel aan een Xbox titel, waarover ik verder niks mag zeggen in verband met een NDA.

Nu is het zo dat je veelal voor je begint aan een project je, onder andere, de requirements op papier zet. Duidelijk, je specificeert je business requirements (het moet mogelijk zijn een tegenstander dood te maken door middel van de IWIN button), je user requirements (de gebruiker dient 3x links te klikken binnen dit vlak en de IWIN button wordt ingedrukt) en je quality of service requirements (de IWIN button dient binnen 1 seconde te reageren).

Dan blijven de functional requirements over, je 'hoe' requirements.
Hoe worden deze binnen een game gedefineerd?
Ik zal als voorbeeld even een webapplicatie pakken waarmee je eenvoudig kunt stellen dat deze pagina 4 input velden moet hebben met een validatie op die en een validatie zus.
Een game lijkt me iets moeilijker uit te drukken in termen van functional requirements.
Hoe gaan ze hier mee om in de gaming industry, gebruiken ze deze gewoon niet? Wat doen ze wel?

[.oisyn]

In principe staat alles in het Game Design Document, maar ik snap niet helemaal waar je heen wilt en welke analogie je met het webvoorbeeld bedoelt. Kun je iets noemen waaraan je zit te denken binnen de scope van een game?

Veel dingen die niet in het GDD opgenomen zijn worden naar eigen inzicht geïmplementeerd. Als dat niet goed of niet lekker blijkt te werken, dan moet het natuurlijk anders. Meestal wordt daar pas op het moment zelf over gepraat en wordt dat niet van tevoren helemaal uitgedacht. Dat is denk ik wat je sowieso ziet bij bedrijven die gewoon hun eigen software schrijven ipv maatwerk voor derden afleveren. Je bepaalt immers zelf hoe je dingen wilt hebben en er is geen klant die inspraak heeft (een publisher zou je natuurlijk kunnen zien als klant, en die hebben ook wel inspraak, maar dat is over het algemeen niet zo gedetailleerd).

[Verwijderd]

Het punt is als volgt, we zijn het afgelopen jaar bezig geweest met het programmeren van een RTS (C# & Irrlicht), het is overigens geen technisch wonder een het is helaas niet zo uitgepakt als we van te voren in gedachten hadden (toch een vorm van studentiekoze luiheid ).

Het is de bedoeling dat school hier een beoordeling aan vast gaat knopen middels een assessement.
Helaas is onze vorige assessor opgestapt in verband met een nieuwe baan en hebben we er een UML- en requirementsgeile dude van de afdeling webtechnologie (vandaar dat ik het verband met een webapplicatie leg) er voor in de plaats gekregen.

Dit betekent dat we een hoop moeten veranderen in onze, toch wel enigszins, fluffy omschreven requirements, maar ik vraag me af hoe we echt harde requirements moeten opstellen.

Om maar een voorbeeld te noemen, onze 'map' is in feite niets anders dan een xml bestand. Dit xml bestand wordt gegenereerd door onze map editor en ziet er ongeveer als volgt uit:

XML:

 <Tile ID="1022" GroundType="0" HeightMap="1" /> 
  <Tile ID="1023" GroundType="0" HeightMap="1" /> 
  </Tiles>
- <MapOptions Forced="false" Override="false">
- <BuildList>
  <BuildItem Type="1" Enabled="true" Researched="true" Researchable="true" /> 
- <BuildItem Type="2" Enabled="true" Researched="true" Researchable="true">
  <BuildingGroupRestriction PGID="2" Enabled="false" Researched="false" Researchable="false" /> 
  </BuildItem>
  <BuildItem Type="102" Enabled="true" Researched="true" Researchable="true" /> 
  <BuildItem Type="104" Enabled="true" Researched="true" Researchable="true" /> 
  </BuildList>
  </MapOptions>
- <PlayersInformation>
- <Players>
- <Player ID="1" AIAggression="0">
- <InGroups>
  <MemberOf inGroup="1" /> 
  </InGroups>
- <Units>
  <Unit Tile="1" Type="1" Health="20" /> 
  <Unit Tile="2" Type="1" Health="20" /> 
  <Unit Tile="3" Type="1" Health="20" /> 
  </Units>
- <Buildings>
  <Building Tile="0" Type="104" Health="20" /> 
  <Building Tile="5" Type="102" Health="20" /> 
  </Buildings>
  </Player>
- <Player ID="2" AIAggression="0">
- <InGroups>
  <MemberOf inGroup="2" /> 
  </InGroups>
- <Units>
  <Unit Tile="1022" Type="1" Health="20" /> 
  <Unit Tile="1021" Type="1" Health="20" /> 
  <Unit Tile="1020" Type="1" Health="20" /> 
  </Units>
- <Buildings>
  <Building Tile="1023" Type="104" Health="20" /> 
  <Building Tile="1017" Type="102" Health="20" /> 
  </Buildings>
  </Player>
  </Players>
- <Groups>
  <Group GID="0" /> 
  <Group GID="1" /> 
  <Group GID="2" /> 
  </Groups>
  </PlayersInformation>
- <World>
- <Trees>
  <Tree ID="0" Tile="237" Model="tree5.3ds" /> 

  </Trees>
  </World>
  </Map>

Of het 'good practice' is om de zaken zo aan te pakken laat ik graag even buiten beschouwing (hoewel tips altijd welkom zijn ). Maar dit is gewoon een gevolg van een stukje evolutie, toen we begonnen hadden we dit niet direct voor ogen, wel iets soortgelijks, maar niet wat het nu is geworden. Dankzij de map hebben we A* makkelijk kunnen implementeren etc etc.

Hoe neem je zoiets in godsnaam dergelijke zaken op in een functionele requirement?
Is het uberhaupt wel nuttig zulke zaken ver uit te specificeren?!
Hoe maak je zulke specificaties in godsnaam meetbaar, specifiek etc (SMART)?

Nog wat anders, we hebben natuurlijk ook een (primitieve) AI. Nu is het natuurlijk leuk als deze ook nog wat doet, zoals het bouwen van huisjes en het zoeken van resources.
Goed, daar kun je dus de business requirement aan verbinden dat: de vijandelijke unit automagisch opzoek gaat naar resources [hout] wanneer het aantal resources [hout] gelijk is of lager is dan 100.

Lijkt me, an sich, een goede requirement. Maar je specificeert alleen nog je 'wat' je moet doen, maar niet het 'hoe'. Nu kan ik natuurlijk vanaf het laden van de map tot het punt dat de tegenstander merkt dat zijn hout bijna op is technisch beschrijven, maar dat lijkt me niet echt wenselijk.

Hoe zou je zelf die requirements opstellen? Hoe ziet zo'n GDD eruit, wij hebben een soort van vision document gebruikt, met daarin storyline, units, gebouwen, resources en interactie beschreven, is dat dan in principe genoeg?

[ Voor 12% gewijzigd door Verwijderd op 21-01-2008 18:13 ]

[.oisyn]

Ik denk niet dat iemand binnen de games industrie ooit de moeite zal nemen om zoiets technisch in een functionele requirement doc te documenteren . Sowieso is een game engine enorm aan evolutie onderhevig. Wij werken ook op een 10+ jaar oude codebase (als je goed zoekt zul je nog Soul Reaver spul tegenkomen), maar er is nog vrij weinig van over. Features komen en gaan, en je requirements worden effectief dus ook continu aangepast. Dingen die nu handig zijn zijn over een paar jaar wellicht niet meer handig, omdat hardware en content ook met de tijd meegaat.

Over de GDD kun je zat vinden op het internet: [google=game design document]

[ Voor 7% gewijzigd door .oisyn op 21-01-2008 18:25 ]

[YopY]

Bij het schrijven van een functioneel ontwerp van welk soort dan ook is een eenvoudige stelregel: hoe groter het project, hoe minder je op details in moet gaan. Op school zijn er mensen die graag je hele programma opnieuw zouden kunnen maken aan de hand van je UML diagrammen en dergelijke, maar in de praktijk wordt dit niet gebruikt.

In de praktijk ben je beter af met een document dat eerst de globale werking beschrijft van het programma, om vervolgens die werking in kleinere modules op te delen en te beschrijven. In jouw geval zou je dan een module 'AI' krijgen, een module 'maps', enzovoorts. Deze ga je vervolgens ook uitleggen (de globale werking daarvan), waarbij je niet veel dieper gaat dan 'een map bestaat uit een aantal tiles (blablablabla) elke tile heeft een aantal eigenschappen (blablabla)' enzovoort. In principe wil je proberen de globale werking van zo'n module uit te leggen aan iemand die er geen verstand van heeft.

Je wilt deze specificatie van die module zodanig maken dat je uiteindelijk een beschrijving krijgt van wat erin moet en wat eruit moet komen. Verder wil je eigenlijk niet gaan - de uiteindelijke implementatie van die module wordt uitbesteed aan een programmeur. Je wilt de modules zodanig beschrijven dat eigenlijk alle mogelijke implementaties zullen werken, zolang ze maar voldoen aan de input en output die je in je document beschrijft.

Op school zullen ze wel om UML-diagrammen vragen enzo, maar daar kun je eenvoudigweg verkeerd-om mee werken. Er zijn UML tools die diagrammen genereren aan de hand van bestaande code. Dat, of je moet goed kunnen beargumenteren waarom je geen UML-diagrammen of vaststaande functionele ontwerpen gebruikt (o.a. door snel veranderend ontwerp, zeker wanneer je nog in een leerproces zit).

Er zijn nog verdraaid weinig bedrijven die vantevoren een volledig functioneel ontwerp maken (inclusief gedetailleerde UML diagrammen e.d.) en zich daar aan houden. Het kost simpelweg teveel tijd voor te weinig baten. Je zou het eventueel kunnen gebruiken om overzicht te krijgen in je programmastructuur wanneer je het kwijt bent, maar dan is het ook al een indicatie dat je ontwerp te ingewikkeld is, of je module te groot.

[MicroWhale]

Verwijderd schreef op maandag 21 januari 2008 @ 17:22:
[..]

Dan blijven de functional requirements over, je 'hoe' requirements.
Hoe worden deze binnen een game gedefineerd?
[..]

Bij softwareontwikkeling wordt bij het opstellen van requirements (business, functional- en non-functional) alleen het "wat" beschreven. Hierbij ga je als requirements engineer voor volledige software, os en hardware onafhankelijkheid. Zelfs als je weet wat het platform wordt waarop het gaat draaien.

Het "hoe" hoort thuis in het (functioneel) ontwerp. Dit wordt ontworpen uit alle requirements- en architectuur-documenten die op het project van toepassing zijn.

Bij uitzondering en slechts als deze voortkomen uit wensen/eisen van de opdrachtgever kan een "hoe" beschreven worden in de requirements. Dit dient echter zoveel mogelijk vermeden te worden om zo de portabiliteit van je requirements te kunnen blijven garanderen.

[ Voor 5% gewijzigd door MicroWhale op 06-02-2008 12:20 ]

[Verwijderd]

Ja, weet ik wel, maar game ontwikkeling werkt weer net even anders dan webontwikkeling (bijvoorbeedl).

[ Voor 3% gewijzigd door Verwijderd op 06-02-2008 15:34 ]

[MSalters]

MrWilliams schreef op woensdag 06 februari 2008 @ 12:14:
[...]
Bij softwareontwikkeling wordt bij het opstellen van requirements (business, functional- en non-functional) alleen het "wat" beschreven. Hierbij ga je als requirements engineer voor volledige software, os en hardware onafhankelijkheid. Zelfs als je weet wat het platform wordt waarop het gaat draaien.

Gaan we weer. Niet dus. Je dacht toch niet dat als je voor de Wii ontwikkelt, dat je je game dan hardware onafhankelijk maakt? Voor zover requirements engineers enige invloed hebben, hebben ze dat soort lessen al geleerd.

Als Requirements Engineering echt serieus genomen wordt, dan vallen eisen aan de hardware ook onder de requirements. Echt ingewikkeld wordt het wanneer de eisen aan hard- en software interfereren, maar dat is voor de Nederlandse gamingindustrie niet zo relevant (geen HW gaming bedrijven)

[MicroWhale]

MSalters schreef op woensdag 06 februari 2008 @ 20:46:
[...]

Gaan we weer. Niet dus. Je dacht toch niet dat als je voor de Wii ontwikkelt, dat je je game dan hardware onafhankelijk maakt? Voor zover requirements engineers enige invloed hebben, hebben ze dat soort lessen al geleerd.

Er staat nergens in mijn reply dat de requirements software/os/hardware onafhankelijk moeten zijn. Laat staan je game. "ervoor gaan" betekent niet "==", dat betekent "erop uit proberen te komen". Dat dat vrijwel nooit lukt is een ander verhaal.

Als Requirements Engineering echt serieus genomen wordt, dan vallen eisen aan de hardware ook onder de requirements. Echt ingewikkeld wordt het wanneer de eisen aan hard- en software interfereren, maar dat is voor de Nederlandse gamingindustrie niet zo relevant (geen HW gaming bedrijven)

Voor een goede portabiliteit van je requirements probeer je je requirements zoveel mogelijk software, os en hardware onafhankelijk te maken.

Eisen aan hardware, os of software staan inderdaad meestal onder de constraints van je requirements document.

[ Voor 5% gewijzigd door MicroWhale op 07-02-2008 11:00 ]

[MSalters]

Ik snapte je verhaal de eerste keer ook al. Dat is het probleem niet. Laat ik het over een andere boeg gooien. Jij introduceert de "Requirements Engineer" en de "opdrachtgever". De opdrachtgever heeft blijkbaar een belang bij het geven van een opdracht, en meest waarschijnlijk is dat een indirect financieel belang. Hoe helpt de Requirements Engineer de opdrachtgever?

Ik heb genoeg ervaring in B2B omgevingen om te zien dat een dergelijke flexibiliteit handig is. Als ik een set requirements heb die duidelijk HW onafhankelijk zijn, maar wel laten zien dat ik pak'm beet 200 servers nodig heb, dan heb ik een goede basis om met Sun, HP, IBM, etc te gaan onderhandelen over een scherpe prijs. Dat was niet de context van de TS.

[MicroWhale]

De requirements engineer helpt de opdrachtgever zijn vraag (in de breedste zin van het woord) inzichtelijk te maken. In het requirements traject zal dus ook naar voren komen dat bepaalde (set) wensen/eisen ervoor zorgt dat er 200 servers nodig gaan zijn.
De opdrachtgever kan inderdaad flexibel zijn door zijn wens/eis in het requirements document aan te passen voordat men aan de onderhandelingstafel gaat zitten.

Nu vat ik alleen nog steeds niet wat je punt is. t.a.v. mijn opmerking en de post van TS. Ik haalde enkel aan dat meneer het "wat" en het "hoe" door elkaar haalt en dat "hoe" zoveel mogelijk vermeden moet worden in een requirements document.

Waarschijnlijk zijn we het met elkaar eens en zeggen het allebei op een andere manier.