Het wordt belangrijk dat Tom in de vakantie een XNA voorbeeld kan geven in samenwerking met de level designers. Dit is omdat wij optijd moeten weten wat wel en niet mogelijk is. Stel je eens voor: Joeri en Martijn maken een design terwij Nicky en ik artstyles maken. Ineens komt Tom in week 3 tot de conclusie wanneer hij een heel level heeft gemaakt dat hij niet verder kan om technische design redenen. Namelijk, het blijkt dat je water niet heen en weer kan switchen en witte met blauwe textures geven niet goed weer in XNA. (Heel hypothetisch allemaal) Dan gebeurt het volgende:
- Joeri en Martijn moeten een nieuw design maken omdat XNA niet kan maken wat hij heeft bedacht.
- Nicky en ik moeten een nieuwe art style gaan bedenken omdat onze textures en stijl niet werkt.
- Tom moet opnieuw een nieuw concept in XNA gaan uitwerken.
- Wij hebben dan ineens in week 7 nog 2 weken om een nieuwe game te maken!
2) Proof of concept woensdag.
Zoals besproken, Nicky maakt een simpel leveltje met een grof voorbeeld van kamers die niet toegankelijk zijn totdat de speler deze 'vol of leeg laat lopen met water'. Dit hoeft niet eens grafisch afgebeeld te worden. Het kan zijn dat de door 'locked' is en dat we het boodschapje "This door currently cannot open, because it is flooded" krijgen te zien. Twee of drie kamers is dan ook echt voldoende als het maar de feeling van het spel weergeeft.
3) Taken verdelen naar UBSA werkdruk.
Zowel ik (en ik geloof ook) Tom en Joeri hebben UBSA shit te doen. Laten we de werkdruk zo verdelen dat de mensen met het meeste UBSA werk even het minste druk krijgen. D.w.z.: Laat even weten wat je voor de UBSA nog moet doen! :)
4) Research.
Als research heb ik voornamelijk onderzoek gedaan naar realisme in toepassing van games. Denk bijvoorbeeld aan space, simulatie etc. Ik heb daarbij gekeken naar wat er allemaal van toepassing is in (ter voorbeeld) een space environment en hoe simulatie en spel (lees: fun) gecombineerd kunnen worden. Daarbij komt in space kijken hoe er met graviteit kan worden gespeeld. Ik zal dat deel research op mij nemen. Laat kort weten wat jouw research is. Ik neem aan dat Tom research doet naar een technisch deel?
Dan mijn feedback op het hele spel concept:
Lees eerst mijn feedback op Joeri's post van maandag!
Verder:
- Opbouw van moeilijkheid. De tech demo kan een tutorial zijn (of een deel hiervan). Waar level 2 een nieuw element introduceert (bijvoorbeeld timers die het moeilijker maken) en waar level 3 nog een nieuw element aanbied (bijvoorbeeld vies water dat eerst schoon gemaakt moet worden of de kamers bewegen onderling, of vanzelf of op bevel).
- Challenge. Een uitdaging door de puzzel op te lossen, eventueel met timers. Niet zo zeer een high-score maar voldoening wanneer het spel af is. De 'reward' is hier het einde halen, geen 'bragging rights'.
- Game-over. Ik ben zelf van mening dat 'quicksaves' en 'checkpoints' niet passen in een puzzel game. Ik ben voor: als de speler een fout maakt, moet een deel van de puzzel opnieuw gedaan worden. Kort om, stel je portal voor als voorbeeld, met god-mode. Je gaat niet dood maar als je verkeerd springt moet je een portal naar de ingang of halverwege de puzzel maken om opnieuw te spelen. De portal turrets schieten dan ook geen kogels, maar houden bijvoorbeeld alleen de speler tegen. Zo gaat de speler niet dood maar bestaat er een vloeiende trial-en-error. Alleen omdat wij dit niet gewend zijn, betekend dit niet dat het daarom fout is.
Maar goed, dit zijn slechts suggesties, voor onze leet lead designer, Joeri.
Geen opmerkingen:
Een reactie posten