#asteroids development

What have you been trying to achieve in GDevelop? Add a scoring system to reward players for hitting different asteroid sizes

Implement a game timer to track play duration

Create win and loss conditions based on score and lives

Add end-of-game screens: “You Win!!!” and “Game Over”

Improve player control using mouse movement and spacebar shooting

Conduct game testing to find bugs and improve game balance

What have you learned? How to use GDevelop's event system for score and game state management

How to display and control the score, time and lives

How to trigger different scenes based on score or lives

How to use timers effectively to show time updates

How to debug player movement and object tracking

How to modify object sizes and collision areas for better gameplay feel

Game Testing & Fixes Identified Issues:

The dot (player tracker) was not following the mouse click

The timer display was updating too slowly or showing incorrect time

The player spaceship appeared too small on the screen

Fixes Applied:

Updated the dot’s position settings so it accurately follows the mouse

Used a GDevelop timer to add 1 second to the display only after each second passes (instead of continuous updates), and stop when the screen changes

Increased the player size to make it more visible and easier to control

Showcasing design ideas and concepts from/inspired by readings: Inspired by class

Implemented player feedback systems through visual and numeric updates (score, time, lives)

For this week's workshop, I followed the guided tutorial to recreate a functional Asteroids-style space shooter using GDevelop. The process involved implementing core gameplay mechanics, customising object interactions, and polishing the user experience.

Gameplay Scene Setup:

Event Sheet Logic:

Live Game with Asteroids and Life Display:

Game Over:

Eventually the workable prototype came out. Though it looks simple, you will be shocked as many mechanics are demonstrated under this blog.

Adding Target System and Dynamic Respawn Zones to Asteroids

This mechanic allows asteroids to threaten players with collisions destroying player ships, while larger asteroids fragment into smaller pieces that respawn dynamically across the play area.

Adding Firing System

Players can shoot bullets by left clicking the mouse, eliminating the approaching asteroids which is the core mechanic of the entire prototype.

Adding Scoring System

Score stacks once any asteroid is destroyed, resulting in a recorded progression.

Adding Pop-up Outcome

An instant scene indicates your success when you eliminate all of the asteroids by shooting them.

By Shannon Tetley

Continuing with my development of Meteor Miner, I've been able to add some fidelity to it that I wasn't able to with my platformer project. The game at the beginning of the week included a ship that sits in the middle of the screen that can shoot in the direction of the mouse, and some asteroids that randomly spawn on the screen. My goal is to make the ship able to move around as it shoots and to make the asteroids move around to make them more interesting.

My game looked similar to this at the beginning of the week:

I was able to get a lot more done than in previous weeks, I'm pretty happy that I've been able to add a few things that go beyond what I was asked to do in the uni tutorial. I added movement to the asteroids and made it so they are destroyed when shot. At first the game wasn't very challenging because the asteroids would fly off screen if not interacted with. This would reduce the number of objects on screen making them easy to avoid. Thinking back to my readings I recalled that altering the formal elements of a complex system, like a game, can have a wide reaching impact on that system (Fullerton). Knowing this I came up with the idea of creating a new rule for the game where if an asteroid makes contact with the edge of the screen it will then bounce off the screen in a random direction. I predicted that this would make the game more interesting and challenging as it would not only keep more asteroids on screen, but it would also make them move in interesting ways. This was achieved by adding walls just off the edge of the screen, when the asteroids make contact with them it activates an event that makes them move in a new random direction.

As I suspected this made the play area much more chaotic. Now when the game is run asteroids are moving in random directions and in far greater numbers than if I had simply increased the spawn rate. To make the asteroid movement more interesting I also made them move at a random speed capped based on the size of the asteroids. On average they move slower if they are bigger asteroids. To tie things together and to give the payer a basic goal when playing the game I added a health count at the top left of the screen. I also added points to the top right. More points are added for killing bigger asteroids with the laser but you also lose more health points when being hit by them.

This week I also learned how to create and transition to new scenes. I was able to use this knowledge to be able to create a death screen that pops up if the player runs out of lives. This way the player has a reason to shoot the asteroids as they not only get points for doing so, but they also are less likely to be hit by them ending their game.

The end result looks like this:

The results are much better than with previous games I made. This one is much more like what you would describe as a game, something that has rules, challenge and an objective for the player to work towards.

References:

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.

Main Objectives

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 Goal

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.

Implementation Goals

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.

PX Goals

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.

Key Ideas + Learnings

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...

Bubble entity: Ducks

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.

3. Obstacle: Whirlpools

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…

Playtesting

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!

References

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.

As usual, my first steps to making this prototype began with grabbing some free assets from Itch.io. I do this because it helps me set the scene, and I find it easier to develop when I know the visuals I am working with.

I got three space packs:

background: https://screamingbrainstudios.itch.io/seamless-space-backgrounds

Ships: https://foozlecc.itch.io/void-fleet-pack-2

Environment: https://foozlecc.itch.io/void-environment-pack

I already had a good idea as to how to set up the scene so I quickly imported the sprites and their behaviors and placed them in the scene.

The first thing I wanted to do was fire the projectile as it's the main mechanic of the game. This was fairly easy to do by spawning the object at the players' position and giving it a constant force.

Next, I wanted to spawn the enemies. I wasn't sure how to approach this in Gdevelop so I did some research and came across an extension created by VictrisGames called 'ObjectSpawner'. This extension is added to an object and another object will be created from that position within the spawning period. This extension also makes sure there are no more objects in the scene than the maximum quantity set. I placed two spawners with a max quantity of 5 and a spawn period of 3 seconds. All it needed now was to be called in the events.

Now that I had enemies, I moved on to the main objective of the game; defending the planet. First, this meant adding a 'health' variable to the planet which I called 'Defense', and set it to ten. Collison was then added for the enemies and the planet that would subtract 1 from the defense variable. At first, there was a bug with this where when an enemy collided with the planet, the defense would go straight to 0. I figured out that it was because the event was being called constantly as they collided, so this was an easy fix by adding a 'Trigger Once' to the condition.

Lastly, I made the enemys be destroyed when colliding with projectiles and made a 'game over' scene when the player failed to defend the planet.

Side scrolling shooters at their core are a simple game, I knew I would need to have something to make it more unique and stand out.  Games like Ikaruga with the light and dark mechanic to absorb and be vulnerable to certain enemy attacks is something I loved experiencing as a player.  I knew I would struggle getting something that implemented so I instead focused on getting the core of the game done and then working on effects and sound to give more visual and audio feedback to the player.