#Asteroids Development

[szewanleung2024]

Asteroids Development Post

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)

Thoughts on readings and how they apply to your game: Readings emphasized the importance of iteration and testing, which directly influenced the changes made after identifying issues

[donnatang]

Asteroids Development

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:

[wenqi-wang]

Asteroids Development - Initial Prototype

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.

[tetley1173-igb220-blog]

Meteor Miner Development

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:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[lilymakesgames]

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.

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.

End of post.

[sun-e-chips]

I offer you a y/n for our beloved Dino Attendants

Hello fellow dinosaur lovers!!!!!!

Reading all the tags and seeing there’s quite a few of us in the dca community made me so giddy YES let’s take robots and dinosaurs and push them together absolutely fantastic!

[heliosphere-underthesky]

Heliosphere: Under the Sky

Meet the dwarf planet, Ceres! Unlike most dwarf planets, she lives in the Asteroid Belt.

Ceres was discovered back in 1 January 1801. She was designated as an asteroid back then, until she was promoted to dwarf planet status back in 2006 along with the discoveries of other objects in the Kuiper Belt with similar characteristics as her.

Ceres (NASA page)

[meangan-thee-lesbian]

Ain't it funny how the ♀ symbol looks like a person with a large head and the ♂ symbol looks like a dick on a head, was this intentional, were early astronomers misandrist, were we once a matriarchal society that recognised the truth of female superiority and that truth was lost to time after the fall of the greatest civilisation to ever exist

[devsniff]

Asteroid Game Devlog #1

Just a tiny tiny tiny progress update on the asteroid game. It really only took five minutes, but I now have sideways movement. Furthermore, moving sideways adds continuous rotation to the sprite.

Below is a video that showcases this as well as a better example of my 'gravity acceleration' system.

[theleafling]

MARGO WALKED SO MARS COULD RUN!!! I say, with false enthusiasm knowing she is going to jail for the rest of her life and we will probably not see her in future seasons

[alex-game-design]

Asteroids Devlog

For the tank's movement, I made it rotate towards the mouse position and added a force at the faced angle, so that the tank would move towards the mouse. I had to rotate the sprite to face right as that is registered as the front.

I created a point on the sprite where the missiles would spawn. They would spawn at the same angle the tank was facing and a force would move them permanently in that direction. When the missile came in contact with the tree, I deleted both objects, spawned a patch of virus and played an explosion animation and sound.

I came into an issue where loading the shop scene and then returning to the game level would reset lives, bucks, and infection to their base values. This was easily fixed by removing the 'set variable to' actions at the beginning of the level scene and instead resetting them during the game over scene. This did not impact the first instance of gameplay when booting up the game, as I had already set the default values in the variable editor.

The infection actions that I have programmed seem to exponentially subtract lives instead of slowly depleting them. I may have to scrap the mechanic of having to buy an antidote and instead have the infection stop after a certain amount of time. I may also instead change what the infection does and have it make players unable to buy more lives until they cure themselves. This option seems both the easiest and the one that makes sense for the idea of the game.

[good-fwiend-in-wome]

game dev update! my idea is to turn the little ship i made earlier into something of a full space combat thingy but for now i made a little asteroids clone to get more comfortable with the engine

pictured: me being terrible at asteroids

[alanshee-keeper-of-realms]

Longest Lived Toons in Off the Animation Table A Who Framed Roger Rabbit Modern Au

Bugs Bunny- 689 Years

Daffy Duck- 692 Years

Minnie Mouse- 1,500 years

Mickey Mouse- 2000 Years

Henri Warner-Goof son of Max and Yakko- 1.5 Billion years sees the end of Earth as we know it because curiosity kept him going

[katherine-ellen-mellors]

Mini-Game Dev Break:

Creating a small Asteroid inspired game... WITH CATS

Elevator Pitch:

I would love to create a fun small asteroids game where the ship is a cat, and the asteroids are fish. For this I will be using GDevelop and Free sprite Assets to create this game.

There's no motive, no story, just laser shooting cats... :3

READY

SET

GOOOO!

Pretty colour background!

And our main star...

Making it move to the position of the mouse,

LASERS

FISH!

COLLISION!

IT'S FUN RIGHT??!! BUT WHAT IF WE ADDED MORE INTENSE SETTINGS?

PRESENTING....

A HEALTH BAR!!!

AAANNNDD DONE!!!!

Spinny Cat is finished, and it is a beautiful work of art!

Post-Mortem

I wanted to make this game as silly as possible as a fun little side game that was different to a platformer. I feel like I've hit the nail on the head with this one.

What I struggled With

Adding the health bar and the variables to diminish the health bar was the most confusing for me. I am still very much learning the basics of variables in G-Develop and so creating a smoother way to reflect cat life in heart bar was challenging.

I managed to figure out a roundabout way using If cat health = [number], delete Lives[x]

I made three separate Live sprites to distinguish between what health equals what:

Cat Health: 1 = Lives2

Cat Health: 2 = Lives3

Cat Health: 3 = Lives4

Cat Health: 0 = GAME OVER scene plays.

There is a way to be able to add a number value to these hearts to be able to subtract a heart when the cat collides with the fish. This would neaten up the Events page significantly.

The method I am using will suffice for now until I reach a better understanding of these variables - in which I can update both Spinny Cat and my platformer.

What Can I Improve?

If I make the laser and animations smoother and more refined it would have great potential to create better death animations for the fish (think explosions) and a better Cat death (Think Spinning while getting smaller and smaller).

Creating a restart button is also a good future addition as it enables re-playability instead of continuously closing and starting the game again

Improving the health bar layout, as well as adding a fish kill count will help with the immersion of the game, including adding laser upgrades after defeating a certain number of fish.

General Take Away

I designed this game for fun and to expand my GDevelop experience. I do not take this game seriously and don't believe the audience should either. You're a cat shooting laser while spinning around a void, have fun, relax and explode some fish :)

[possomheo]

Fighter Flight

Elevator Pitch - Asteroids Fighter Flight is an asteroid game that takes away the shooting mechanic and instead replaces it with a defence mechanic. In the game, you destroy asteroids by hardening your ship thus obliterating the asteroids that come your way. Your objective is to defend against as many asteroids as you can.

Movement = Arrow keys to move (top-down movement) Defence = Space (when pressed) Menu = esc

After developing Portal Home, I wanted to experiment more on 'melee damage'. At first, I implemented a hitbox similar to Portal Home. The problem with this was the player is constantly moving and the hitbox does not follow the player. In order to fixed it, I instead made the hitbox into an animation.

^ Defence animation for the player. I expanded the outer layer to indicate a tough shell around the player and implemented a flashing red light to it. This gets the player's attention and lets them know the defence is wearing out.

Referencing Fullerton, T. (2019). Game design workshop : a playcentric approach to creating innovative games (Fourth edition), I considered the following elements for my game: Objective - to destroy as many asteroids as possible/ get the highest score Rules - avoid the asteroids and obliterate as many asteroids as you can Conflict - destroying and dodging the asteroids Boundaries - the player is bounded to the play area, going outside will kill the player Outcome - lose (the game is over once the player dies) Challenge - staying alive for as long as possible Play - player must work with their cooldown abilities and avoid randomly generated asteroids Premise - NA

[curlytrek1701]

Oh removing the asteroid is sooooooo violating the prime directive lol