Feature: Dev Story: Obelus
Door GekooktEi op 03-01-2014 om 15:56
|
Bron: Gamed
|
Op de opleiding Communicatie-systemen, richting Game Design & Development, is veel van de stof een voorproefje op hoe het er na de opleiding uit zal zien. In onze vrije ruimte kozen drie klasgenoten en ik ervoor om onze dagen samen door te brengen op een kamer van zeventien vierkante meter, werkende aan een retro platformer/shooter. Eerlijk gezegd zou ik het zo erg niet vinden als het er na de opleiding zo uitziet voor een tijdje.
Nadat we duidelijk hadden wat voor spel we wilden maken, hebben we een werkwijze vastgesteld. Besloten werd om vier dagen in de week op de kamer van één van de teamleden bezig te gaan, zodat we altijd direct contact kunnen hebben. Dit is een verbeterpunt ten opzichte van het eerder besproken project, waar communicatie een grote valkuil was doordat we niet bij elkaar zaten. We gebruikten toen wel de service Trello, wat als Scrum-board diende, maar dit was geen volledige vervanging voor mond-tot-mondcommunicatie. Het feit dat we met zijn vieren aan dezelfde tafel zitten, zorgt er wel voor dat we elkaar motiveren en we ook bezig blijven. Ik denk dat dat één van de beste beslissingen is geweest, want we maken nu met zijn vieren meer voortgang dan we aan Adamant met zijn twaalven deden.
Naast het motiveren, is een belangrijk aspect van in één ruimte zitten dat je dezelfde visie houdt van wat het spel moet gaan worden. Als er een stukje art klaar is, wordt er direct feedback op gegeven, daarom is het ook essentieel om te beginnen met een schets en pas later in detail te gaan werken. Voor de vorm van David, het hoofdpersonage, hebben we bijvoorbeeld eerst uit zes silhouetten gekozen wat we het meest 'lenig' vonden lijken, zodat hij niet te lomp zou worden of niet likeable genoeg. Daarna is het silhouet pas ingevuld, en toen dat mooi was is het geanimeerd. Dat deed ik, hoewel ik niet de artist van mijn team ben, wat me op het volgende punt brengt.
De Quarry: van concept gericht op level design naar uiteindelijke art
De rolverdeling was niet zo strict, gezien rollen in een klein team toch meestal overlopen. Het team bestaat uit Thomas Jager (ik), Tony Fial, Freek Verheijde en Harm-Jan Wiechers. In essentie is er een traditionele rolverdeling (Programming, Design, Art, Sound) maar we hebben de grenzen van die verdeling niet te strict gemaakt, waardoor ik als designer ook art-assets maak als daar meer werk te doen is, en eigenlijk iedereen wel een zegje heeft in het design.
Testen
Op dit moment zijn we over de helft van de ontwikkeling van het spel, en zijn twee van de drie levels speelklaar en ook redelijk opgepoetst. Het grootste deel van het ontwikkelingswerk zit erop, en daarom leek dit me een goed punt om te beginnen met het testen van het spel bij het publiek.
Om deze reden zou ik het heel tof vinden als jullie het spel zouden willen spelen en jullie mening erover willen geven. Dat mag via de reacties hieronder, maar het liefst via de daarvoor opgezette questionnaire, die anoniem is en ongeveer vijf minuten duurt om in te vullen.
De questionnaire is hier te vinden en bevat ook een link naar de downloadpagina. Bedankt voor het testen van het spel. Vragen over het artikel beantwoord ik graag in de reacties.
|
|
Pagina:
1
|
2
|
|
|
|
 16:48 GTA V entertainmentproduct van 2013
 15:00 Geen mods voor Titanfall launch
|
| Reacties (4) |
|
|
Pagina:
1
|
|
Redneckerz
(Redacteur)
op 03-01-2014 om 16:09
[Niv: 227 / Exp: 11336]
|
|
Ik zou graag weten welke tools jullie gebruiken bij de ontwikkeling van deze game. Gebruiken jullie tools die nog van Adamant afkomen? Of gebruiken jullie meer een kant en klare omgeving zoals Unity?
Met welke developeromgeving wordt de game gecompileerd?
Zal er ondersteuning voor andere platformen aanwezig zijn?
|
|
|
GekooktEi
op 03-01-2014 om 16:25
[Niv: 483 / Exp: 24134]
|
Bij Adamant gebruikten we juist Unity, dit is gemaakt in Game Maker Studio. Beide zijn 'kant en klare omgevingen', als in, game engines waar we verder niet aan hebben hoeven sleutelen. Compilatie gaat ook via GMS.
Op dit moment maken we het spel voor een custom-built arcadekast, en het doel is eerst om het spel daarvoor af te maken. Mocht er nu bijvoorbeeld door 9/10 testers gezegd worden dat er interesse is in een release voor bijvoorbeeld PC, dan staat die mogelijkheid natuurlijk open. 
Gewijzigd door GekooktEi op 03-01-2014 om 16:25
|
|
|
Redneckerz
(Redacteur)
op 03-01-2014 om 22:44
[Niv: 227 / Exp: 11336]
|
|
Merk je veel verschil betreft gebruikersgemak tussen Unity en GMS?
Waar bestaat de hardware van de arcadekast uit? Is dat via een FPGA of is het gebaseerd op een PC (meeste arcadehardware is oftewel PC gebaseerd, of op een console gebaseerd)?
|
|
|
Gast (82.95.84.xxx)
op 04-01-2014 om 10:30
|
|
Ik, als programmer, maak de keuze altijd op basis van het concept. 2D games maak ik liever in GMS en 3D in Unity (Ik heb nog niet naar de nieuwe 2D mogelijkheden van Unity gekeken...) dus de keuze ligt voor mij niet in het gebruiksgemak.
GM staat bekend om zijn lage drempel; Ik heb het als jochie zelf onder de knie kunnen krijgen. Unity is wat dat betreft wat ingewikkelder, maar als je eenmaal weet hoe het werkt zijn beide erg makkelijk in gebruik.
Om ons meer op het spel te kunnen richten hebben we gewoon een PC gepakt :)
Freek
|
|
|
Pagina:
1
|
|
|
|
