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?

Payload level with Fixed Camera

Payload level with Fixed Camera
Payload level with Rotating Camera at Checkpoints
Payload level with Rotating Camera at 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?

Button Mashing mini game

Button Mashing mini game

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?

Payload with higher speed

Payload with higher speed

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.

Attack with health subtraction; multiple player support

Attack with health subtraction; multiple player support

Payload with knockback attack

Payload with knockback attack

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

Leave a comment

Log in with itch.io to leave a comment.