Onderzoek programmatuur en software ontwikkelmethodieken

Onderzoek  programmatuur  en  software  ontwikkelmethodieken                                                     Auteur:   Datum:   Versie:   Project:   Vak:    

Kevin  Wilmink   2-­12-­2010   1.0   Raindrops   Design  for  Space  

Intro  

In  dit  onderzoek  wordt  er  onderzocht  hoe  het  te  verwezenlijken  project  (Raindrops)   voor  Design  for  space  het  beste  geïmplementeerd  kan  worden.  Er  wordt  gekeken  welk   ontwikkelplatform  het  meest  geschikt  is,  diens  voor-­‐  en  nadelen  in  kaart  gebracht.   Vervolgens  wordt  er  gekeken  naar  de  verschillende  software  ontwikkelmethodieken  en   welke  het  meest  geschikt  is  voor  een  project  van  dit  kaliber.  Omdat  de  speler  zelf  het   belangrijkste  wordt  in  het  spel  en  speelt  met  een  onconventioneel  object   (waterdruppel)  word  er  gekeken  naar  welke  technieken  er  gebruikt  kunnen  worden  om   dit  gevoel  te  kunnen  versterken.  

  De  opdracht  

De  opdracht  van  het  project  van  Design  for  space  is  het  maken  van  een  game  waarin  de   speler  ruimtelijke  uitdagingen  moet  overwinnen.  Het  spel  moet  voorzien  worden  van  3   verschillende  (ruimtelijke)mechanismes.  Het  project  beslaat  een  tijdsperiode  van  4   weken  voor  het  conceptueren  en  5  weken  voor  het  implementeren.    

Welk  ontwikkelplatform  past  het  beste  bij  het  te  ontwikkelen  design  for  space   project?  

Voor  het  maken  van  een  ruimtelijk  spel  (3d  omgeving)  zijn  er  verschillende   programma’s  en  technieken  voorhanden.  Dit  onderzoek  wordt  begrenst  tot  Unity  3d  en   XNA.  De  reden  hiertoe  is  dat  op  school  de  meeste  kennis  van  deze  2  programma’s   voorhanden  is,  in  beiden  les  wordt  gegeven  en  beiden  zich  toespitsen  op  het   ontwikkelen  van  games.   Unity  3d  kenmerken   Unity  3d  is  eenvoudiger  en  een  sneller  ontwikkelplatform  in  verhouding  tot  XNA.  In   unity  3d  zijn  voor  veel  basis  functies  allerlei  libraries  en  technieken  voorhanden.   Bijvoorbeeld  kent  Unity  3d  voor  collisions  (botsingen  tussen  objecten)  een  volledige  set   aan  colliders  (het  gebied  rond  een  3d  model  waarin  het  programma  weet  dat  2  objecten   met  elkaar  boksen).  Daarbij  is  unity  3d  ook  veel  visuele  dan  XNA,  Unity  3d  werkt   doormiddel  van  slepen  en  klikken  waarin  tegen  XNA  alle  functionaliteit  komt  uit  zelf   geschreven  code.  De  visualisatie  in  unity  zorgt  ervoor  dat  de  programmeur  een  beter   (visueel)  beeld  heeft  wat  er  gebeurd  en  kan  hiertoe  ook  indirect  leiden  tot  een  stabielere   code  en  minder/sneller  debuggen  (onverwachte  fouten  oplossen).     Unity  is  ook  een  volledig  medium  voor  het  ontwikkelen  van  een  game,  het  programma   kent  voor  veel  mogelijke  bestandsformaten  functionaliteit.  Omdat  Unity  3d  veel  basis   facetten  van  het  game  ontwikkelen  uit  handen  neemt,  zal  het  ontwikkelen  van  het   project  voor  design  for  space  sneller  gaan  in  vergelijking  bij  XNA.  Dit  zal  ertoe  leiden  dat   er  meer  tijd  over  zal  blijven  om  eventuele  lagere  prioriteit  onderdelen  alsnog  te   implementeren  (shoulds  en  could’s).  In  unity  schrijft  de  programmeur  voornamelijk   scripts  om  de  elementen  aan  te  sturen.  Unity  ondersteund  zowel  C#  (C  sharp)  als  Js   (Java  script).     Een  opvallend  verschil  tussen  Unity  3d  en  XNA  is  dat  objecten  in  Unity  3d  ‘vanuit   zichzelf  werken’  qua  programmeer  denkwijze  (onderwater  zullen  de  programma’s   hetzelfde  werken).  Dat  wil  zeggen  een  object  update  zichzelf  en  doet  een  mutatie  als  er  

iets  veranderd  moet  worden.  In  XNA  werkt  dit  andersom  een  object  wordt  elk  frame   opnieuw  getekend  door  een  overkoepelend  object.  In  principe  wordt  er  elk  frame  weer   een  totaal  nieuw  scherm  getekend.  Unity  kent  ook  een  goede  (basis)  ondersteuning  voor   het  creeeren  van  particles  (explosies,  dwarelende  stofwolkjes,  etc)  licht  effecten  en  mist.   In  unity  3d  is  het  creeeren  van  een  sfeervolle  wereld  daarom  sneller  en  eenvoudiger   mogelijk  dan  in  verhouding  tot  XNA.     XNA  kenmerken   XNA  is  een  framework  dat  Microsoft  toegankelijk  heeft  gemaakt  voor  het  ontwikkelen   van  games.  XNA  bied  een  goede  ondersteuning  voor  het  ontwikkelen  van  xbox,  windows   based  pc  en  Zune  games.  XNA  werkt  met  de  programmeer  taal  C#.  XNA  wordt  gezien  als   een  meer  professioneel  medium  dan  Unity  3d.  XNA  wordt  veelal  gebruikt  in  combinatie   met  visual  studios  (code  bewerkingsprogramma),  ook  van  Microsoft.  XNA  wordt   krachtig  ondersteund  door  microsoft  en  kent  een  levendige  community.  XNA  is  echter   een  complexer  medium  als  Unity  3d.  Het  kent  veel  minder  basis  functionaliteit  en  veel   meer  zal  zelf  geschreven  moeten  worden.  Hoewel  dit  meer  tijd  zal  kosten  qua   programmateur  (en  het  verwezenlijken  van  eventuele  shoulds  en  coulds),  is  XNA  wel   flexibeler.  De  basis  functionaliteit  die  zelf  geschreven  moeten  worden  (engine)  kan  meer   naar  de  hand  worden  gezet  van  de  programmeur  en  beter  toegespitst  worden  op  het   project.  XNA  is  dan  ook  een  programmeertaal  die  niet  zou  misstaan  op  het  C.V.  van  een   serieuze  gameontwikkelaar.  In  de  gamebiz  heeft  XNA  dan  ook  een  hoger  aanzien  dan   Unity  3d.   Hoewel  beide  programma’s  zijn  voor-­‐  en  nadelen  hebben  is  Unity  3d  een  betere  keuze   voor  dit  project.  Unity  3d  zijn  grote  kracht  zit  hem  in  het  feit  dat  het  sneller  werkt  als   XNA,  omdat  veel  elementen  al  voor  de  programmeur  gedaan  worden.  Omdat  er  voor  dit   project  geen  complexe  (engine)functies  nodig  zijn  is  het  onnodig  om  veel  elementen  te   herschrijven  in  XNA.  Alsmede  omdat  het  project  van  een  vrij  kort  tijdsbestek  is  (5   weken)  is  het  ook  eerlijker  tegenover  de  andere  teamleden  om  het  snellere   ontwikkelplatform  te  kiezen.  De  reden  hiertoe  is  dat  er  meer  uit  het  concept   geïmplementeerd  kan  worden  en  niet  het  ontwikkelplatform  (programmatuur)  de   bottleneck  van  het  project  wordt.  

  Welke  ontwikkelmethodiek  past  het  beste  bij  dit  project?   Het  project  kent  2  duidelijke  (verplichte)  fases,  de  concept-­‐  en  de  productiefase   (implementatiefase).  In  de  eerste  fase  wordt  er  vooral  gericht  op  het  bedenken,  testen   en  ontwikkelen  van  een  krachtig  concept.  De  tweede  fase  beslaat  het  uitwerken  van  dit   concept.  Het  ontwikkelteam  bestaat  uit  vier  mensen  waarvan  een  enkel  persoon  zich   richt  op  het  programmeren  van  de  game.     Door  deze  verplichte  standaard  kan  er  al  snel  gedacht  worden  naar  de  meer   conventionele  ontwikkelmethodieken.  Om  tot  een  goede  ontwikkelmethodiek  te  komen   is  het  een  goed  idee  om  uit  bestaande  ontwikkelmethodieken  de  punten  te  pakken  die   het  best  aansluiten  bij  het  Design  for  space  project.  Een  ontwikkelmethodiek  die  goed   aansluit  bij  deze  verplichte  eigenschappen  is  het  waterval  model.  In  het  waterval  model   wordt  het  project  in  fasen  opgedeeld  (bijvoorbeeld:  analyse,  concept,  ontwerp,   implementatie,  testen).  De  volgende  fase  pas  gestart  als  de  vorige  volledig  foutloos  en  

compleet  is.  Hierdoor  is  het  niet  nodig  terug  te  koppelen.  Andere  kenmerken  aan  het   watervalmodel  is  dat  alle  besluiten  worden  vast  gelegd  in  documentatie.  Dit  zorgt   ervoor  dat  wanneer  er  nieuwe  mensen  in  het  project  komen  deze  snel  kunnen  worden   ingelezen  in  het  project.    Omdat  het  project  maar  een  kort  tijdsbestek  beslaat  en  de  kans   nihil  is  dat  er  nieuwe  projectleden  worden  opgenomen  in  het  bestaande  project  zijn  de   tijdskosten  van  het  maken  van  deze  extra  documentatie  groter  dan  de  baten  die  het   oplevert.  Het  is  dan  ook  verstandig  om  van  dit  onderdeel  van  het  waterval  model  af  te   zien.   Omdat  speelbaarheid  en  ‘gevoel’  een  erg  belangrijk  onderdeel  zijn  bij  games  is  het   belangrijk  veel  te  playtesten  (mensen  het  spel  laten  spelen  en  hun  bevindingen   meenemen).  In  de  ontwikkelmethodiek  van  Rapid  Prototyping  wordt  er  in  korte  tijd  snel   een  speelbaar  geheel  neergezet,  waar  vervolgens  aanpassingen  aangedaan  worden  aan   de  hand  van  de  feedback  van  het  playtesten.  Hoewel  dit  een  snelle  ontwikkelmethodiek   is  om  snel  tot  een  product  te  komen  zorgt  dit  veelal  voor  cowboy  code.  Code  die  niet   efficiënt,  ongestructureerd  is,  maar  enkel  met  de  focus  op  werking.     Een  derde  ontwikkelmethodiek  is  incrementele  ontwikkelmethodiek.  Kort  gezegd  komt   dit  neer  op  het  waterval  model  maar  in  plaats  van  een  x  aantal  hoofdfasen  te  doorlopen.   Wordt  op  elk  onderdeel  het  waterval  model  toegepast.  Op  elk  onderdeel  wordt  apart   een  analyse,  concept,  ontwerp,  implementatie  en  test  fase  toe  gepast.   Een  vierde  ontwikkelmethode  kan  die  van  XP  (extreem  programming)  zijn.  XP  is  nog  erg   jong  en  dient  zichzelf  nog  te  bewijzen  in  de  wereld  van  software  ontwikkeling.  XP  kent   echter  een  aantal  unieke  elementen  die  wellicht  ten  positieve  van  het  project  gebruikt   kunnen  worden.  Kenmerkend  aan  XP  is  dat  het  slagen  van  het  project  uiteindelijk  draait   om  het  schrijven  van  code  en  niet  om  randzaken  (documentatie).  Ook  XP  kent  snelle   productieve  sprints  (zoals  rapid  prototyping  dit  kent).  XP  is  een  agile  ontwikkelmethode   wat  inhoud  dat  het  zeer  flexibel  is  en  er  snel  kan  worden  bijgesteld  mochten  er   (onverwacht)  veranderingen  optreden.  Deze  flexibele  aard  past  goed  bij  het  vele   playtesten  en  diens  eventuele  aanpassingen.   In  XP  wordt  de  te  schrijven  code  verdeeld  over  de  programmeurs,  elke  progammeur   kent  alles  en  zit  overal  in.  Code  wordt  gerievewed  door  elkaar  en  wordt  aan  elkaar   uitgelegd.  Een  ander  kenmerk  is  dat  code  wordt  geschreven  in  paren.  Twee   programmeurs  zitten  samen  achter  één  computer  om  tot  een  hogere  kwaliteit  code  te   komen  en  beiden  bekent  te  worden  met  bepaalde  delen  van  de  code.  De  kwaliteit  wordt   ook  gewaarborgt  door  het  veel  refactoren  van  code  (code  herschrijven  om  het   efficienter,  netter  te  maken  zonder  nieuwe  functionaliteit  toe  te  voegen).  Het  refactoren   van  code  en  het  snel  neerzetten  van  nette  code  is  een  krachtig  element  van  XP  dat  past   binnen  het  design  for  space  project.  Echter  het  paar  programmeren  gaat  moeilijk  worden   omdat  het  team  uit  4  man  beslaat  en  we  ook  mankracht  nodig  zijn  op  andere   kwaliteiten.  De  extra  werkdruk  die  hierdoor  komt  te  liggen  op  de  enkele  programmeur   is  gedeeltelijk  in  te  dammen  door  documentatie  werk  weg  te  laten  (er  is  maar  een   enkele  programmeur  aan  het  werk).   Waarschijnlijk  ligt  de  gouden  weg  in  het  combineren  van  de  meest  aansluitende   elementen  van  deze  4  ontwikkelmethodieken.  Het  is  een  goed  idee  om  in  hoofdfasen  te   werken  (analyse,  onderzoek,  concept,  ontwerp,  implementatie,etc.).  Terugkoppeling   tussen  afgesloten  hoofdfasen  moet  minimaal  worden(waterval  model),  alsmede  door  de   verplichting  van  de  twee  verplichte  fasen  van  school.    Het  project  met  diens  levels,  

Mechanismes,  etc  is  goed  op  te  delen  in  aparte  subfasen  (incrementele  ontwikkeling).   Deze  subfase  moet  vervolgens  gelijk  begonnen  kunnen  worden  met  een  korte  sprint  (XP,   Rapid  prototyping).  De  ontwerp/concept  elementen  van  deze  subfase  moeten  al  gedaan   zijn  in  de  grote  globale  ontwerp/concept  hoofdfase.  Binnen  elke  fase  moet  er  veel   geplaytest  worden  (Rapid  prototyping)  omdat  ‘gevoel’  niet  te  ontwerpen  is.    Elke   subfase  starten  en  afsluiten  zoals  dit  werkt  in  het  waterval  model  maar  binnen  elke  fase   de  rapid  prototyping  toe  te  passen.  Wanneer  nieuwe  elementen  voortborduren  op   bestaande  delen  code  is  het  belangrijk  dat  deze  code  goed  werkt  en  duidelijk  is.  Op  deze   onderdelen  is  het  verstandig  om  refactoring  toe  te  passen  (XP)  om  geheel  duidelijk  te   maken.  Bij  refactoring  moet  voortdurend  de  berekening  gedaan  worden:  de  tijd  die  de   refactor  kost  +  de  eventuele  performance  winst  is  deze  hoger  als  de  kosten  van  het   opnieuw  inlezen  van  (oude  code)  her  te  gebruiken  code  +  eventueel  risico  op  fouten  en   het  debuggen  hiervan.  Refactoring  moet  enkel  toegepast  worden  als  het  winst  oplevert   en  niet  omdat  de  code  er  ‘netter’  van  wordt.  

  Welke  mogelijkheden  en  technieken  kunnen  het  beste  gebruikt  worden  om  de   speler  (waterdruppel)  zo  krachtig  mogelijk  in  beeld  te  brengen?   Het  concept  van  het  spel  voor  design  for  space  heet  Raindrops  (Spawn  studios)  Het  spel   speelt  zich  af  in  een  grote  boom  waar  de  speler  zich  doorheen  navigeert  als  een   waterdruppel.  De  speler  wil  de  boom  laten  groeien  en  leven  door  knopjes  en  blaadjes   aan  te  raken  en  water  te  geven.  De  kracht  en  geloofwaardigheid  van  dit  spel  moet   voortkomen  uit  de  waterdruppel  die  de  speler  bedient.  In  deze  subvraag  wordt  er   ingegaan  op  de  verschillende  mogelijkheden  en  technieken  die  toegepast  kunnen   worden  om  dit  doel  te  bereiken.   Groeien  en  verkleinen   De  speler  zal  gedurende  het  spel  water  oppakken  en  afgeven.  De  speler  wordt  hierdoor   groter  en  kleiner.  Er  zijn  drie  mogelijkheden  hiervoor.  De  eerste  is  om  van  de  speler   verschillende    3d  modellen  te  maken  en  de  juiste  in  te  laden  aan  de  hand  van  het   verzamelde  water.  Hoewel  er  hierdoor  veel  variëteit  tussen  de  stadia’s  van  de  speler  is   (het  aantal  verzameld  water  bepaald  de  grote  van  de  spelerdruppel).  Is  het   overschakelen  tussen  verschillende  stadia’s  minder  flexibel  (het  is  stadia  A  of  B).     Een  tweede  mogelijkheid  is  een  enkel  model  te  gebruiken  en  deze  te  animeren  in   verschillende  stadia’s.  Hoewel  het  overschakelen  tussen  stadia’s  op  deze  wijze  goed   geanimeerd  kan  worden,  wordt  het  resultaat  minder  prettig  als  er  een  stadia   overgeslagen  moet  worden.  Ook  wordt  het  probleem  van  stadia  A  of  B  behouden  (geen   tussen  waarden).     Een  derde  mogelijkheid  die  vooral  de  nadruk  legt  op  de  programmeur  is  de   waterdruppel  doormiddel  code  te  vergroten  of  verkleinen.  Hoewel  animaties  op  deze   wijze  meer  werk  vereisen  is  deze  manier  erg  flexibel  met  tussenwaarden  tussen  de   verschillende  stadia’s.     Ook  hier  zal  de  meest  ideale  weg  liggen  tussen  verschillende  technieken.  De  druppel   moet  doormiddel  van  code  een  goede  flexibele  overgang  kennen  tussen  de  verschillende   stadia’s,  maar  om  druk  bij  de  programmeur  weg  te  halen  is  ervoor  te  kiezen  om  enkele   geprogrammeerde  animaties  te  versterken/laten  overnemen  door  geanimeerde   modellen.  

Gameplay  –  waterdruppel  gevoel   De  speler  moet  het  gevoel  hebben  met  een  waterdruppel  te  spelen  en  diens  gedrag.  Er   moet  daarom  een  goede  middenweg  gevonden  worden  tussen  realisme  en  gameplay.   Aan  de  programmeur  te  taak  om  de  waterdruppel  zo  te  programmeren  dat  het  gedrag   volledig  flexibel  aan  te  passen  is  door  het  wijzigen  van  enkele  variabelen  (zonder  dat  er   wijzigingen  in  de  logica  van  de  code  gedaan  hoeven  worden).  Het  ligt  echter  buiten  het   bereik  van  dit  onderzoek  hoe  een  water  druppel  daadwerkelijk  beweegt.  In  een   vervolgonderzoek  kan  hierop  ingegaan  worden  en  zou  er  vast  gelegd  kunnen  worden   met  welke  facetten  er  rekening  gehouden  moet  worden  om  een  druppel  levensecht  te   laten  lijken.    

Conclusie  

In  dit  document  is  er  onderzoek  gedaan  naar  verschillende  facetten  die  spelen  bij  het   opzetten  van  het  Design  for  space  project  met  betrekking  tot  het  spel  Raindrops.  Er  komt   naar  voren  dat  Unity  3d  het  ontwikkelplatform  is  dat  het  beste  past  dit  project.  Dit  komt   doordat  Unity  3d’s  veel  ondersteund  wordt  op  school,  zich  op  games  richt  en  een  sneller   ontwikkelmedium  is  dan  zijn  alternatief  XNA.  Het  ontwikkelplatform  en  programmatuur   zal  op  deze  wijze  niet  een  bottleneck  vormen  voor  het  project  en  diens  projectleden.  Als   software  ontwikkelmethodiek  komt  een  combinatie  van  verschillende  erkende  software   ontwikkelmethodieken  het  beste  uit  de  bus.  De  afbakening  in  de  verschillende  fases  van   het  waterval  mode.  Het  snelle  testbare  resultaat  uit  het  rapid  prototyping/  XP   ontwikkelmethodiek.  Het  waarborgen  van  code  kwaliteit  doormiddel  van  refactoring  uit   XP  en  het  doorlopen  van  incrementele  cyclussen  op  losse  onderdelen  uit  de   incrementele  ontwikkelmethode.  De  kracht  van  het  spel  komt  voornamelijk  uit  het   gevoel  die  speler  heeft  met  waterdruppel,  de  waterdruppel  moet  daarom  veel  aandacht   krijgen  en  moet  een  perfectie  harmonie  kennen  tussen  realisme  en  gameplay.  Veel  winst   in  dit  gevoel  kan  gevonden  worden  in  het  combineren  van  geanimeerde  modellen  met   geprogrammeerde  modellen  (ideale  overgang).    

Bronnenlijst    

Literatuur:   Lunn,  K  (juni  2004)  “Software  engineering  met  UML”,  Nerderland:  Acemic  Service     Beedle,  Mike  &  Schwaber,  Ken  (oktober  2001)  “Agile  software  Development  With   Scrum,  Engeland