Update - Prototype Sprint 2
This week, we wanted to focus fully on developing new gameplay mechanis and test these with several protopes. We tried to prioritize certain mechanics and game design choices, by asking several question:
1. Camera: Is the entire level visible at the start of the game, or should the camera be fixated on certain checkpoints?
We found that both perspectives offer their own advantages and disadvantages. While a fixed camera offers a more clear and constructive view of the 'battlefield', a lot of character detail is lost and the game feels more distant. The rotating camera on the other hand offers the player a better view of the characters and makes them feel closer, more invested. It is however more difficult to look at the 'bigger picture', as most of the level is obscured
2. Core Mechanic: Is our 'ultimate ability' mini game fun?
As a twist on the typical use of abilities in a games, we wanted to add a small minigame. When a player fills up his meter by attacking, he can unleash an ultimate ability which may grant him an advantage to push the payload. A minigame is started at this point, in which all players participate. If the attacking team pushes the slider fastest to the attacking team, the ultimate gets cancelled. Vice versa, the attacking team gets its advantage. After prototyping, we noticed the mechanic felt quite intuitive and induces the competitiveness between players that we are aiming for. We plan to introduce this technique in our final game.
3. Core Mechanic: How fast-paced should our game be?
As shown above, we prototyped the payload with a higher speed, in contrast with the first gifs shown where the payload was moving considerably slower. We found, although the high-paced gameplay could make for some chaotic fun, it is not what we want in our final game. We want to implement several mechanics like slow and fast attacks, dodging, abilities,... which we want to players to think about. By this we mean, when should I attack, or should I dodge now, perhaps I should save my ultimate for later... This process requires time, not a 'fast-paced randomly pressing attack buttons'- playstyle.
4. Core mechanic: How should our attack be implemented?
We implemented a simple attack pattern where 'press attack' = 'other player loses health'. This was mostly to test the technical functionality (two players interacting with each other). Furthermore, we also prototyped a 'Knockback' attack, where the player gets pushed back from the payload after being attacked, and does not lose health. We found that this offered some interesting posisbilities, as instead of a 'kill your enemy' type of objective with all designated abilities, we could go for a more light hearted 'boop the enemy character away from the payload', and adjust our characters' abilities to this.
Coming up next week:
Before starting with the production phase, we want to make some definitive decisions, then finetune these and add supporting structures: Which camera perspective is best for the final playstyle we have in mind, should we step away from the usage of health bars,... An example for the supporting structures: how should power ups be implemented and how can they change the core mechanics,... These are not absolutely vital for the game, and have thus not been protoyped so far.
Get Night At The Zoo
Night At The Zoo
Status | Released |
Authors | Sam_Vanden_Bosch, Celine.Lauwaert, Kevin.De.Temmerman, arthur.leplae, Tim.De.Jonghe |
More posts
- OFFICIAL RELEASEMay 24, 2020
- Update - Polish Sprint 3.2May 12, 2020
- Update - Polishing Sprint 3.1May 05, 2020
- Update - Production Sprint 2.3Apr 28, 2020
- Update - Production Sprint 2.2Apr 21, 2020
- Update - Production Sprint 2.1Mar 31, 2020
- Update - Production Sprint 1.3Mar 24, 2020
- Update - Production Sprint 1.2Mar 17, 2020
- Update - Production Sprint 1.1Mar 10, 2020
Leave a comment
Log in with itch.io to leave a comment.