Overall, it is quite evident that our game GrappleMania! received a number of positive comments, however, it also received various beneficial feedback that we could use to improve the game in the future. We can conclude from the playtest findings that our game is heading on the right track as currently, all the playtest participants found our game addicting, fun, and engaging.
If we were to fully complete the game, a number of aspects need to be included. These are as followed:
A fully fleshed out campaign mode (20+ levels). A feature to save their progress.
Several more power ups
- Score multiplier: when this is active, each gem collected will be multiplied by a value.
- Invulnerability: when this is active, players aren’t able to be harmed by obstacles such as missiles. Players will also bounce off the rock walls.
- Mini-plane: when this is active, players will shrink in size, making it harder to get hit by missiles but also harder to collect gems.
- Maxi-plane: when this is active, players will grow in size, making it easier to get hit by missiles and to collect gems.
- Massive speed up: when this is active, players are going insanely fast, making it hard to control.
More audio
- Game background music
- Grapple noises
- Incoming missile sounds
- Menu music and sounds
- Noises and Music depending on whether the user achieved a high score or not (endless game mode)
UI
- A more obvious health bar (playtesters didn't notice it at first)
- Improved Gem Counter
- Pause Menu
- Improved "How to Play" menu
Settings System
A High Score system for the endless game mode
A proper tutorial system: playtesters found it confusing and overwhelming when they first started playing.
Adjustments to the grapple mechanic - it can be a bit buggy sometimes.
Ultimately, I am happy with how the final prototype turned out and the praise that it received. Adding all of these aspects shown above and most likely even more would improve the game and player experience greatly.
Another change that was made to GrappleMania! was implementing audio. Having audio for when the player dies, and collisions such as missile impact, health packs, and gem collecting were all very
essential. Consequently, this allows effective player feedback which will improve the player's experience. Ultimately, this will let the game to effectively immerse the player in a greater environment.
Based off the results from our playtest participants, a number of adjustments and additions were implemented within our game. We decided to implement health packs to the endless game mode. The way these health packs work is simple; once the player collects 5 gems, a health pack will spawn in a random location. If the player chooses to collect this item, it will grant them health. Additionally, this item provides an extra layer of difficulty as it can be seen as a risk for the player to try collect it if they are not in dire need.
Another Interesting Mechanic/Book Chapter/Game Discussion
Quoted from Fullerton:
"Balancing a game is the process of making sure the game meets the goals you have set for the player experience: that the system is of the scope and complexity you envisioned and that the elements of that system are working together without undesired results."
When reading this chapter, this particular section stood out to me. Since I'm a programmer, I've never balanced a game as the Game Designers usually do it. Resulting in why I was interested in this chapter of Balancing.
References:
Fullerton, T. (2018). Page 321. Game Design Workshop: A Playcentric Approach To Creating Innovative Games (Fourth Edition). AK Peters/CRC Press.
After conducting the playtest session with each of our participants, we would ask them to fill out a survey in order to receive more data. This is the link to the Playtest Survey: https://forms.office.com/Pages/ResponsePage.aspx?id=o1IL3MVo90SIHZOD2IULllQAGaY_bTFAhL3GBVhihmZUN1RRUTlPQVRERTNSVjFUMVhJQVdaTThaWC4u
Following that, we would collate and analyse all of the data provided. We would attempt to find patterns, anomalies, or anything that was interesting to conclude relationships.
We first asked users to complete this Demographics Survey (https://forms.office.com/Pages/ResponsePage.aspx?id=o1IL3MVo90SIHZOD2IULllQAGaY_bTFAhL3GBVhihmZUOUEyV0lNSEpOQ1QyRlNOWDRaOUFLQ1hJUS4u)
According to Fullerton, a "script will keep you on track and remind you of your role as an observer". This lead us to creating and following a script that I created in order to keep everything consistent. During the session, we would note down all the player's thoughts as we told them to say it aloud. Additionally, we would note down all of the series of events that would happen during the gameplay.
Shown below, are all the raw notes taken from each playtest session:
Raw Notes:
ID No. 1: Tristan
“Like a slingshot game, kinda fun”
very jittery game - improved slightly by f11
“I'm so good at this”
Gem count:
- 14
- 3
- 8
- 5
ID No. 2: Charlie
“Trick shot”
Quick to understand mechanics
Poor handle of game
Poor FPS too
Wants to include a UI to show speed and rotation direction
Change missile spawning immediately
Wants to make gems spawn after some time
FPS performance issues with the particle emitters, could change the cursor at least
“Went from can I not hit the wall - can I aim at the Gems - can I avoid the missiles”
Cursor colour should be consistent with plane
The speedometer UI suggests more than there is
Suggested spinning fast will grant missile deflection
If I were to change something about how I developed this racing game prototype, it would be to be more organised regarding ideating and conceptualising the game art and controls. The roads can potentially cause visibility problems as the colour of the car is dark. Additionally, I didn't design any curved roads for the corners of the racing track, causing it to be more confusing and difficult for the player to see and understand.
A major problem that my playtester found was that the car controls were very difficult to use. Players were drifting and swerving around the entire track, making it very difficult to stay on the road. They also tended to spin out and do 180s quite often. Furthermore, there were no barriers or any win condition that were implemented in the game, resulting in the main goal to resort to just free driving.
Ultimately, there were many improvements and reworking of mechanics and design that could be done in my racing prototype. As always, playtesting is a great influence on how the game gets improved and designed as people may think of ideas and concepts that you've never thought of.
As Fullerton said "Prototyping lies at the heart of good game design." I do believe that when developing my racing game, I might have not done the prototyping correctly, causing many issues and problems along the way,
References:
Fullerton, T. (2018). Page 203. Game Design Workshop: A Playcentric Approach To Creating Innovative Games (Fourth Edition). AK Peters/CRC Press.
This is my progress on the Poster for my game, The Last Dragon.
Once again, I'm going to stick with the layout and the colour palette to match the Game Design Document. I've repeated my process of designing by creating text boxes of stuff I need to talk about before actually filling it with content. Since the poster looks a bit empty at the moment, I will attempt to design some exciting dragon and plane stickers to fill in the gaps.
This is my progress for the game design document of my game The Last Dragon.
Personally, I think that I will stick to this design as I feel like that it looks appealing to the eye. I've got a layout of how it might look like at the end, however I haven't had the time yet to implement and explain how the Player and Enemies work.
I currently only have the description of the game and what the user interface displays.
I've implemented some basic car controls. After testing this driving system, it seems like the sensitivity and speed are too fast and will be hard to control as a new player.
Furthermore, the way it drives does not look smooth as it turns the entire car, rather than the wheels.