Development - GDO710 - Week 5
Second development log! Did I make some progress? Kinda? Did the project go as planned? Not really.
Brink. After my rapid prototyping, that was the main game idea I wanted to run with. I had spent some time last week figuring out the mechanics, fleshing them out in more detail. I find that one of the best tests of mechanics is by creating a simple level.
Thus, many doodles were born.
Figure 2 - This was a later attempt at some more detailed mechanics and level design. The heart which is sliced into 2 segments is the playable character, the character starts the game at 1 segment filled and should aim to keep it that way. On the far right of the room, there are 3 circles. In my crude sketch, they represent keys/skulls (fiction subject to change). If the player collects the designated amount, they can exit.
The idea here is that you must kill/absorb health to solve mini puzzles. Similar to the likes of Hotline Miami. IE: you might have 3 health which would traditionally heal the player. In this game, that is bad. However, the key requires the player to be on 1 and 1/2 health to pick up the first key. Therefore the player must do a small balancing act. In another room, there might be an enemy and the player will have to sacrifice 1/2 of health to send a damaging projectile.
One major finding that keeps coming up as I create this game is that:
Designing for health to be a negative effect is counterintiutive.
Coming up with mechanics that would make the player understand that "healing" was not a good idea was tough. There were multiple different ways I could have done this but I ended up with the following:
The more health the player has, the slower their movement speed. This stacks exponentially to the point where the player can have too much health and stop moving.
If the player's health >= 5, the player's heart will be too slow and shut down. Aka, game over.
Certain mechanics (like doors) will require the player to lose health: IE: The player can only enter through a certain door with Half a heart (this also would make game balance significantly easier.)
Over time, Half hearts will fade away.
The players slowing down their movement speed should be enough incentive* to not gain as much health, However, making it so that the player can gain hearts and then sacrifice health to use special skills defeats the purpose of wanting the player to be at half health most of the game. I need to brainstorm another idea on how I can implement skills, but alas, that is future Anna's problem.
* That being said, we won't know until we playtest!
Figure 4 - One of my later attempts at a basic tutorial level which can help demonstrate mechanics further. The player is the white, half-heart in the top left corner. In this example, the player learns basic movement and interacts with their first gate, this gate will only let the player through if they have half a heart. The player starts on their base health so they are able to pass. There will be other circumstances which help the player learn this skill, but this is the first glimpse of what to expect.
To the east of the door, the path is closed. The player cannot progress east and can only progress south. The red squiggles are timed spikes. Spikes that will jump up after X amount of seconds and then hide for X amount of seconds. This is the first hazard they will get introduced to. Once the player navigates this initial hazard they will find a lever which will open the east door. This teaches the player that they will have to complete puzzles as the game progresses and this will progressively be reinforced as the player continues.
After passing through the initial east door, the player will be presented with a door that has a similar design as the first door they went through. However, this door has a full heart meaning that the player needs to find a way to gain health in other to proceed. The passage facing north is free, proceeding this way will bring the player through some more timed spike puzzles and some imagery about the weighing scale.
The intention behind the imagery is to push the idea of balance. How you shouldn't take what doesnt belong to you.
Once the players progress through the puzzle then they will be "Rewarded" with health. The player's movement will slow down and there will be a shorter path to reach the previous door. The player now has enough health to pass through the door and can continue.
In that room the player will gain half a heart, this is shown to the player by:
A smaller version of the player on half a heart, happily bouncing behind the player.
The player's speed has slowed down exponentially.
Once the player stands on the pressure plate, the door will open. However, when the player walks off the plate the door will close. This area teaches the player that they can sacrifice surplus life where they stand. This surplus life will stay in place for 10 seconds until it will fade away. The player can then proceed through the door. The door will lock behind the player and they will be faced with their first enemy of the game.
After this tutorial mockup, I believe I have enough to start creating a demonstration / physical prototype. The first method I wanted to try was creating a paper prototype. I have created paper prototypes before when working on a 2D platformer game and thought that it would be easy.
Before jumping into the paper prototype, updated my basic kanban board. At this point, I had finished the basic iteration phase and was jumping into the paper prototyping phase. I decided to add "reflection notes" (notes in orange) which talk about how things are going/ any important notes I needed to remember.
I quickly discovered that making a paper prototype for this game was going to be difficult. I made a couple of different iterations but was not happy with the outcome in the slightest. There were multiple elements I wanted to showcase for this game, however, it would be very difficult to implement this in a paper format.
After *attempting* to create the paper prototype, I decided to jump into Unity and create a grey box instead. Creating multiple different scenes which could showcase gameplay would be more useful and more representative. I don't believe I will have enough time to make a full tutorial due to other commitments outside of the master's degree.
Jumping forward to the dar before the submission:
Time is running out.
I have all the concepts for the game however, I do not have a physical, playable demo of the game. I don't believe I will have a build in time for the deadline, but if the second rapid prototype allows us to further work on this, then that would, be great. Let's see how it goes.
I feel like creating the game is unity was a better idea, yes, it will take much longer to create the demo but it will be more representative of the demo I want to create.
Once I complete a playable section, I will upload the link below:
Task review: XXXXXXXXXXXXXXX XXXX
Tasks to be done this last week: XXXXXXXXXXXXXXXXXXX
Review the theme.
Brainstorm concept for the demo.
Think about scope and feasibility within the time frame.
Decide on a format for the demo (IE: Paper prototype / Unity build).
Set up project management & create task breakdown.
FLESH OUT THE IDEA!
Tasks to be done THIS week: XXXXXXXXXXXXXXXXXXX
Think about scope and feasibility within the time frame.
Decide on a format for the demo (IE: Paper prototype / Unity build).
Set up project management & create task breakdown.
FLESH OUT THE IDEA!
Set up Unity project.
Get the main character moving about the scene.
Plan out which skills I want to show in the game build.
Finish health & damage system level
Finish sacrifice health system
Finish door system
References: XXXXXXXXXXXXXXX XXXX
A, Tookey. (2022) Authors own. Mindmap for rapid ideation 1. [Image]
T, Bramwell (2015) Hotline Miami review. https://www.eurogamer.net/hotline-miami-review