Asteroids Development + Insights
Please note that this is a completely different GDevelop project with different code and different design decisions to the Rubber Duckie Hero prototype developed by my group in Assessment 3.
I had a few objectives I wanted to achieve with Rubber Duckie Hero. These objectives could be split into design goals and implementation goals, the latter relating more to developing the actual prototype in GDevelop. I think a better description for the implementation goals might be player stories. PX goals have also been included as their importance has been rightfully advocated in the platformer posts (and in the textbook).
Design a shooter game that provides an active and energetic experience. The style should be cute and the main gameplay should be simple yet engaging with the target audience of younger, casual gamers in mind. Everyone should be able to learn + understand the game easily but their effectiveness/skill may vary greatly.
Other implementation goals: player has 3 lives, freed ducks disappear after 2 seconds, freed sharks chase player, freed sharks disappear after attacking player...
Ideally this list would include challenges for the player such as the IHW event (all bubbles popping) and obstacles like whirlpools but they’ve been omitted due to feasibility constraints or other issues. Their design and justification; however, is still explained and reflected on later.
In the indented section below, I’ll detail my thought processes a bit more and elucidate how I decided on these particular goals in respect to some learnings from the textbook.
My overall design goal was very straightforward and while some would call it boring, I think it’s a noble goal for a game designer.
Fullerton (2018) defines games as a form of entertainment and an important facet of their quality is the ability to engage players both intellectually and emotionally. There are many ways to mobilize this and so for Rubber Duckie Hero, I asked myself two questions:
I decided I wanted to accomplish this by keeping players constantly active and occupied. From this, I also started to think about the PX goals, an energetic and potentially frenzied player experience. Most of this contemplation actually started from reflecting on my personal thoughts on asteroids and “simple” shooter games. I didn’t like the idea of a game where players can just stay in one place and aimlessly shoot without any motivations or consequences. It’s stagnant and boring gameplay that is neither intellectually nor emotionally moving.
Of course, this is just a generalization based on what I've read so far + my own personal experiences but the sentiment remains.
Moreover, in chapter 1 Fullerton (2018) briefly introduces the notion of challenge in games. Conflict challenges players in games and is often attached to subsequent feelings of frustration and rising tension (Fullerton, 2018). Fullerton (2018) further highlights the importance of “balancing these emotional responses to the amount of challenge in games” to maintain player engagement. Frustration may motivate players but everyone has their limit and my intended PX for RDH is not to induce dramatic rage quits. Instead, I chose to add formal elements such as obstacles to regulate challenge in the game as well as rules that prevent players from statically spam shooting from a stationary position.
My “favourite” learning from this cycle was the predictability of games (specifically their outcomes) and why it’s important for gameplay. I’ve always associated predictability in games with narratives and storylines so when Fullerton (2018) introduced the concept of predictability in the context of games as dynamic systems, I was very intrigued. Fullerton (2018) goes on to explain how the elements of a game system influence each other, hence the idea that the system is dynamic. Moreover, she attributes this dynamism to each game element having its own attributes and behaviours which create the relationships of the system as game elements influence each other and thus impact the predictability of that game’s outcomes (Fullerton, 2018). Of course, the challenges and limitations of this is also addressed: “a greater complexity of gameplay does not always equate to a more enjoyable experience for the player…the addition of more potential behaviours tends to add choice and lessen the predictability of the outcome in a game” (Fullerton, 2018).
And in respect to RDH, I decided to introduce specific game entities to increase the potential behaviours and hopefully make RDH a more engaging experience. Only two outcomes exist in RDH: player survives (win, claim RP) player does not survive (lose, do not claim RP). Adding different entities; however, should hopefully make the outcomes a little less predictable…will the player survive or not? If they do survive, how many RP will they collect?
Below I’ll be showcasing some more key ideas as well as reflecting on how the predictability of games influenced design and development of RDH overall.
PX Goals and M2M Gameplay
For the most part, my PX goals guided the development of the M2M gameplay. There was still mutual influence, but influence was skewed towards the PX goals. That is, I designed my M2M to facilitate the PX goals but in some cases, new PX goals were introduced based on gameplay (prime example would be the first PX goal evolving to the last PX goal).
RDH's M2M gameplay is shooting and moving for the primary objective of rescuing ducks (gaining rescue points, RP)
How and why the player will move and shoot were important design considerations for me, I designed these mechanics to facilitate the PX goals. I never wanted the player to be still or to randomly shoot without thinking so I decided that players should shoot to burst bubbles and then move to either reap the rewards (ducks) or face the consequences (sharks and octopi).
ALSO, at this point I decided to diverge from the workshop tutorial by changing the controls. Movement is a critical part of RDH's gameplay; players should spend 90% of their time at least moving and it's the only way of achieving the game objective of rescuing ducks. That's why I had to change to WASD movement because the mouse motion behind asteroids movement felt very wrong for the fast-paced, movement-based design.
So, after establishing the PX goals and M2M gameplay, I set off to design and implement features that are complementary to the M2M.
Below I'll highlight 3 key ideas that I designed and/or implemented.
Bubbles and Bubble Entities
Bubbles themselves are the main “obstacle” for players in RDH. They operate as a barrier between the player and rewards / consequences. The barrier is broken when the bullet collides with the bubble sprite, freeing the entity inside. I allowed bubbles to spawn anywhere on the screen and allowed them to overlap as well.
So the bubbles exist as the premise for the shooting mechanic. Shoot to pop bubbles, but don’t shoot carelessly. Basically I didn’t want players to just shoot and get points so instead I’ve forced them to shoot to break a barrier and then move to get points :D
Without the intelligence and unpredictable actions of other players, I had to introduce some kind of simple obstacle mechanic. Simple, because I had plans for more complex and interesting obstacles later on...
Duck behaviors should force the players to be active and a little strategic. After the bullet collides with the bubble, the duck is “freed” and can now be collected by the player (through duck-player collision). However, players have 3 seconds to collect the duck before the sprite disappears. All of this was done through events, very simple work with sprites but deciding on the timing was difficult. The duration needed to be sufficient for players to reasonably reach the duck before it disappears but not so long that players don’t feel a sense of urgency to move and collect. Gotta be strategic, shoot too early/too far away and the duck will vanish.
Bubble entities: Sharks and Octopi
To implement sharks and octopi, I adapted processes from this tutorial (BTurtle, 2022). The functionality for sharks and octopi is very similar with the targets being the main difference. Sharks attack the player and octopi steal ducks. Most of the code was reusable there, I just had to make tweaks so upon collision, sharks would damage the player then disappear. Conversely, octopi behavior differs as they’ll only chase ducks within a certain radius from the octopus’s spawn location.
Also, the spawn frequency for the bubble entities was balanced based on challenge. Sharks spawn somewhat frequently, and octopi spawn rarely to avoid stunting player progress too much. All of these behaviors were designed with the intention of keeping players active and to influence the predictability of the outcomes. Sharks influence the player’s ability to survive, octopi influence how many RP you might collect.
As an aside: Nets
Just want to quickly speak on the net mechanic here…
Nets are just a different application of the shooting mechanic; the implementation was largely the same. Nets launch at a fixed distance from the player and will despawn after 3 seconds so players should be strategic with timing, don’t deploy too early… I considered nets to be resources, but I wasn’t sure if they should be a limited yet renewable resource (i.e., player can only store 3 nets at a time) or an infinite resource with a cooldown (i.e., player never has to collect more nets but can only launch nets once every x seconds). Both options raised the challenge considerably since players could no longer spam nets to kill sharks.
Also, Fullerton’s (2018) words on the utility and scarcity of resources were very useful here as I designed the functionality and limitations of the net mechanic. I inferred that resources are a great way of regulating challenge in games. By limiting how players can use the resource (without compromising the utility), I can elevate the challenge level.
2. Abstract "boss" event: In Hot Water!
In Hot Water! was a challenge I devised as means of “compensating” for the simple + relatively low-level challenge presented by the normal gameplay mode. The player should aim to collect as many RP as possible during regular gameplay (45 seconds) before IHW starts. The player then has to survive for the remaining 15 seconds. The behaviour of the bubble entities while in IHW influences the predictability of the outcomes. First, all the existing bubbles pop so all the ducks, sharks, and octopi will be released. The player now has to decide if they want to run away from the sharks, collect the ducks before they’re stolen by octopi, defeat all the sharks, etc. With all these different behaviours, it’s harder to predict if you’ll survive and if you do survive, how many RP points did you collect.
Also, IHW was created as a pun/play on words of sorts that contributes to the otherwise shallow narrative + premise of the game. You’re sailing around in a bathtub rescuing rubber ducks when someone turns the hot water on. In Hot Water is a phrase associated with increasing danger/pressure or getting into trouble—this is exactly what the abstract “boss” event is also supposed to reflect. These feelings of pressure and tension—which are important for engaging players (Fullerton, 2018)—are enhanced by the blue water background changing to a bright red.
Additionally, I’m fully aware that IHW might be very frustrating for players if they keep failing to survive. Fullerton (2018) highlights the importance of balancing these emotional reactions to keep players from losing motivation; if playtesting reveals that players do indeed become too frustrated to continue playing then I’ll have to iterate design and find that balance.
I removed whirlpools from the prototype because it was too hard to survive. Whirlpools stun and temporarily paralyze players upon collision, and if you were being pursued by multiple sharks then it would almost guarantee death since you can’t launch nets when stunned. The function of whirlpools was to increase the threat posed by sharks since the player could otherwise outswim or just net the sharks if necessary. It wasn't exactly fun to avoid the whirlpools and crashing into them was more annoying than challenging, so they were removed (for now).
Here’s what it would’ve looked like though…
I did some informal playtesting with 3 friends, mainly to gauge if I was beginning to facilitate the intended PX goals but also to see if the game was fun to play. All 3 friends said they had fun playing. RDH was a simple yet engaging experience because it forced them to be active. In saying that, I made a very interesting observation regarding player activeness and also their use of strategy/tactics.
Before I get into that, I want to highlight the design decision I made that players must survive the whole 1 minute to claim points. That is, they must survive through IHW mode. Why? Because if you can claim points without surviving then there isn’t a tangible victory or defeat anymore—what does it matter if you win or lose? The outcome is the same, you get points either way. There were no consequences to losing which subsequently nullifies the victory.
So, with that rule in place, I noticed players started employing different strategies based on their current situation. Factors such as experience with game, accumulated RP, number of lives, time left before IHW, etc. influenced how the players would play. For example, most players for the first 1-3 tries were very active for the whole time, constantly shooting and moving. During later plays though, some players started doing things like intentionally staying still and not shooting anything. This would happen often if players had accumulated enough RP and had low health so they would save their lives and wait for IHW to start. This was very, very interesting to note and gave birth to the final PX goal: Players will employ different strategies and play styes to achieve their goals. And of course, this PX goal will shape the direction of iterations for future development.
Potential things to add to the game to complicate things for the player, make them apply a bit more skill and thought to their strategies. Another solution could be introducing feedback loops to account for player skill gaps. Maybe the IHW duration should be dependent on the accumulated RP during the regular mode. E.g., if player accumulates <50RP, IHW is decreased as this would suggest they aren’t as skilled at the game whereas if RP >50RP then IHW should be increased so the player is challenged for longer. This becomes complicated when considering the aforementioned tactics of intentionally waiting for IHW to start, so that’ll be the end of development for RDH in this cycle.
Thanks for reading this very long post!
BTurtle. (2022, January 03). How to make a enemy follow the player | Gdevelop 5 tutorial [Video]. YouTube. https://www.youtube.com/watch?v=DyEf4E_myUk
Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.
