#gdevelop5

[warilyshinyconstruct]

About Me – Brandon Alchin:

My name is Brandon Alchin, and ever since primary school, I’ve been fascinated by the “magic” found in video games. A big part of my childhood was spent playing games with my younger brother and parents, and there was something truly special about those shared experiences. Rather than growing out of it, I became even more curious—wanting to understand what made games feel so powerful, so immersive, and so emotionally resonant.

I began asking myself: what creates that feeling? Why do games draw us in the way they do? And how can I recreate that same sense of wonder for others? These questions sparked my interest in game development and eventually led me to study a Bachelor of Games and Interactive Environments at QUT.

My goal is to become a game developer who can create experiences that capture that same childhood magic—games that speak to people of all ages, backgrounds, and identities. I’m excited to explore how design, interactivity, and player-centered thinking come together to craft unforgettable experiences.

Platformer Game Elevator Pitch:

Backtrack: Lost in the Wild is a pixel-art survival platformer where a lone camper is stranded deep in a dangerous jungle. Armed with only a knife and his instincts, he must outsmart wild predators, use environmental traps, and uncover lost tools to survive and find his way back to safety. It's a game of action, timing, and tactical creativity where every decision could mean life or death.

Development Post – Backtrack: Lost in the Wild:

This week, I made major progress on my platformer prototype, Backtrack: Lost in the Wild. Set in a dense, dangerous forest, the player’s goal is to survive, adapt, and score by outlasting natural threats and defeating enemies in creative ways.

What I Built:

Created basic enemy AI, including patrolling guards and their defensive block ability, which reduces incoming melee damage by 50%.

Designed early level layouts, focusing on spaciousness and multiple traversal paths.

Midway through, I introduced a vine and boulder mechanic—cutting vines drops boulders, which can crush enemies or open new paths.

Added a score system based on time + enemies defeated. The final score is displayed at the end to encourage replayability.

Lessons Learned:

Implementing the boulder mechanic took longer than expected. I wasn’t fully comfortable with collision logic in GDevelop, especially when dealing with dynamic events (cutting vines triggering multiple interactions). Similarly, using a timer to calculate score was a new challenge for me. After a few failed attempts, I learned how to sync the timer with event triggers to track player performance accurately.

Design Insights:

Reading Fullerton’s Game Design Workshop helped me appreciate the importance of interactivity and consequence. By allowing the boulder to kill both enemies and the player, I added a layer of risk vs reward, which testers found interesting. This aligns with Fullerton’s principle of meaningful choices—players need to decide when and how to use the environment to their advantage.

Postmortem – Backtrack: Lost in the Wild:

With my Backtrack: Lost in the Wild prototype completed, I’ve taken some time to reflect on what went right, what didn’t, and how the project helped me grow as a designer.

What Worked:

The vine and boulder mechanic was a standout. It gave players options: crush enemies, unblock paths, or—if used carelessly—crush themselves. This added both strategy and tension.

The final score system encouraged replayability. Playtesters said they felt motivated to improve their time or get perfect runs, which was exactly the goal.

The forest setting and muted visuals (with 32x32 sprites) helped convey a grounded, survival-themed tone.

What Could Be Improved in Development:

I struggled with the enemy block mechanic. While it technically worked, most testers never used it or didn’t notice its effect. I think better visual feedback (e.g. animation, sound, or flashing block icon) would have helped.

The boulder collision logic was fragile—at times, it crushed unintended elements or wouldn’t fall correctly. I should have isolated it in a test scene first.

What Could Be Improved in Design:

I didn’t include any onboarding/tutorial—players had to figure out climbing, blocking, or boulder usage by trial and error. One said it was fun, but another struggled at first. I’ll include subtle prompts or signs next time.

The enemy health system needed more balance. Many enemies could be one-shotted unless they blocked, which led to some players ignoring the block feature entirely.

Playtest Feedback Highlights:

“I never used the block mechanic—enemies were too easy to kill.” “Loved that I could also crush myself with the boulder. Risky but fun!” “Beating it for the first time and getting a perfect score was super satisfying.”

Final Reflection:

Fullerton’s emphasis on the player-centric approach really resonated during this process. I realised I was designing around cool mechanics instead of for the player experience. When I reframed the game as a risk-and-reward survival challenge, everything clicked. I now understand how important iteration and playtesting are in aligning your design with the feelings you want to create.

Asteroid Game Elevator Pitch:

Void Runners is a fast-paced arcade shooter where players pilot a sleek spacecraft through asteroid fields and alien ambushes. Your mission: survive deep space while racking up a high score by blasting asteroids, dodging debris, and avoiding hostile drones.

The game combines classic Asteroids-style gameplay with modern twists like power-ups, enemy swarms, and combo scoring to encourage precision and speed. Designed with short sessions in mind, Void Runners offers high replay value and escalating challenge, perfect for players who love twitchy, reflex-based gameplay.

Void Runners is a retro-inspired space shooter where you dodge, destroy, and drift your way through asteroid belts and drone strikes. Fast action and risky power-ups keep each run intense. Can you master the void and top the leaderboard?

Development Post – Void Runners:

This week, I began building the core systems of my asteroid shooter prototype, Void Runners, in GDevelop 5. My primary focus was to get the player controls, asteroid spawning, and basic shooting mechanics functional.

What I Worked On:

Created a top-down movement system with rotation, inertia, and thrust.

Implemented asteroid generation at random angles and speeds.

Designed bullet shooting and collision effects, including temporary particle explosions when bullets hit asteroids.

Began experimenting with enemy drones that follow the player.

Design Goals:

My aim was to maintain the snappy feel of retro arcade games while adding small twists, like:

A combo system that rewards quick asteroid hits

Rare power-ups that increase fire rate or slow time

A danger meter that increases difficulty the longer you survive

What I Learned:

Creating smooth space-style controls was trickier than expected. Adding gradual acceleration and drift meant I had to carefully balance speed, rotation, and stop time to avoid the player feeling "floaty" or completely out of control.

According to Fullerton (2018), controls are part of the formal elements of gameplay. In tuning these, I’ve been trying to make the game “feel right” in the hands—even before enemies or scoring are added.

Postmortem – Void Runners:

Now that the prototype for Void Runners is complete, I’ve taken some time to reflect on what worked, what didn’t, and how to move forward with my design.

What Worked:

The core loop of shoot → dodge → repeat was tight and addictive. Players wanted “just one more run,” which is a good sign.

The random asteroid generator created enough variation in each run to avoid repetition.

Adding a combo score multiplier introduced tension: do you take risks for higher points or play it safe?

What Could Be Improved in Development:

I struggled with hitbox accuracy—sometimes bullets visually passed through asteroids without a collision triggering. I learned to adjust object points and collision masks in GDevelop to resolve this.

Implementing a high score system with local saving took more time than expected, especially since I was unfamiliar with variables and storage events in GDevelop.

What Could Be Improved in Design:

There was no onboarding/tutorial to explain controls. Some players didn’t realise they had inertia-based movement and kept trying to “stop” on a dime.

The enemy drones were too aggressive, especially for early levels. I need to pace enemy introduction more carefully or add visual indicators before spawning them.

Playtest Feedback:

“The movement is fun once you get the hang of it, but it took me a few tries.” “I liked the combo system, it made me want to be riskier.” “Maybe start with just asteroids before adding enemies. The first game felt overwhelming.”

Takeaway:

This project helped me better understand player feedback loops and how even simple mechanics can become engaging when balanced with risk and reward. As Fullerton notes, game mechanics should encourage mastery over time—next time, I’ll integrate tutorial moments more naturally and avoid front-loading difficulty too soon.

Racer Game Elevator Pitch:

Turbo Rush: Canyon Drift is a fast-paced, top-down arcade racer where players drift through narrow canyon tracks, dodge hazards, and battle the clock to set record-breaking lap times. Speed is everything—but so is control.

The game focuses on momentum, drift mechanics, and precision turning across visually distinct, obstacle-heavy tracks. Players can collect temporary speed boosts, avoid rockfalls, and chain drifts to maintain top speed while racing to earn gold, silver, or bronze rankings.

Turbo Rush is a time-attack canyon racer with physics-driven drifting and high replayability. Challenge your reflexes, shave seconds off your best laps, and climb the leaderboard—if you can stay on the road.

Development Post – Turbo Rush: Canyon Drift:

This week I began developing the foundational systems for my arcade-style racer, Turbo Rush: Canyon Drift, in GDevelop 5. The focus was on tight control, track collisions, and lap timing.

What I Built:

Created car movement system using acceleration, friction, and rotation for drift-like control.

Designed collision boundaries for canyon edges and off-road penalties.

Added lap detection system using invisible checkpoints to count progress and prevent cheating.

Implemented timer UI to track player lap time and determine medal thresholds.

Game Feel Goals:

The aim was to make drifting feel challenging but responsive. Inspired by classic top-down racers like Micro Machines, I wanted to reward smooth cornering and risk-taking without being punishing.

To test this, I tuned the car to gain traction slowly, allowing players to “slide” around corners with enough practice.

What I Learned:

Implementing realistic-feeling drift required balancing multiple values in GDevelop’s physics and velocity logic. At first, the car spun too freely—after tweaking deceleration and rotation dampening, I got something that felt playable.

Fullerton’s emphasis on iterative prototyping reminded me not to aim for perfection on the first try. The initial version didn’t feel “right,” but I was able to test and tweak small changes to get closer to the intended experience.

Postmortem - Turbo Rush: Canyon Drift:

Now that the first prototype of Turbo Rush: Canyon Drift is complete, I’ve taken time to reflect on the process and what I learned.

What Worked:

The drift mechanic landed well—after tuning, it felt smooth and gave skilled players an edge.

Players liked the lap-based goal structure, especially the visible time tiers (Gold/Silver/Bronze).

Track layout encouraged replayability, with multiple testers saying they “wanted to beat their last time.”

What Could Be Improved in Development:

I initially set up lap tracking with only a start/finish trigger, which led to players skipping chunks of the track. I later added checkpoints but wish I had planned that earlier.

I also spent too long on visual polish (dust trails, UI transitions) before the core game feel was ready. Next time, I’ll hold off polish until the game loop is locked.

What Could Be Improved in Design:

No tutorial or prompts meant some players didn’t realise drifting was key to faster laps. I should include visual cues (like ghost trails or icons) to guide behavior.

Tracks lacked variation in hazards. I’d like to add falling rocks, oil slicks, or collapsing bridges to mix things up in future versions.

Playtest Feedback:

“Drifting is super fun once you learn how to control it.” “I ignored the bronze/silver/gold system until I saw my friends comparing scores. Would be cool if it had a leaderboard!” “Wish there was more risk—maybe obstacles or destructible shortcuts?”

Final Reflection:

This prototype highlighted the value of iterative tuning. As Fullerton (2018) notes, good games aren’t born—they’re shaped by feedback, testing, and revision. I originally focused too much on how it looked. By the end, I saw how important it is to build around the player experience first. Speed, control, and competition now drive every mechanic.

Assignment 3 – Development Post: Echoes of the Tower:

This week, I made significant progress on my 2D platformer prototype, Echoes of the Tower. Set inside a dark, mysterious ruin, the game revolves around exploration, combat, and environmental navigation. Players must survive a crumbling tower filled with patrolling enemies and hidden vertical routes, using careful movement and strategic timing to reach the exit.

What I Built:

Implemented the core player movement system, including a ledge-latching mechanic that lets the player grab and climb ledges by pressing toward them.

Designed and tested enemy patrol AI, with basic line-of-sight movement and damage upon contact.

Added a respawn and health system, allowing the player to take damage and restart from checkpoints.

Developed a complete playable level that tests traversal, enemy avoidance, and exploration under pressure.

Lessons Learned:

The ledge-latching mechanic was surprisingly complex. I initially underestimated how unclear it might be to players—several testers struggled to discover how to use it. I learned that even well-functioning mechanics can feel “invisible” without feedback or tutorial cues. This taught me the importance of not just building mechanics, but also teaching them through intuitive design.

Design Insight:

Inspired by Fullerton’s Game Design Workshop, I focused on creating meaningful player decisions. The ledge-latching system became more than just a movement option—it represented a choice between risk and safety. Should players attempt a risky climb over a dangerous pit, or find a longer route? This kind of agency is key to keeping players engaged.

Assignment 3 – Playtesting Post: Echoes of the Tower:

This week, I ran a structured playtesting session with six naïve users to evaluate the prototype of Echoes of the Tower. The session focused on usability, player understanding of core mechanics, and overall experience.

Playtesting Setup:

Each participant played the game without prior instruction and was asked to “think aloud” while playing. After the session, they completed a detailed survey and participated in a feedback discussion. Four of the six users were from my game’s core demographic—players familiar with 2D platformers.

Key Observations:

The ledge-latching mechanic caused confusion. Multiple players did not understand how to use it, resulting in them getting stuck or assuming the game was broken. Once explained, most found it enjoyable.

The lack of onboarding or tutorial significantly impacted early gameplay. Without any visual cues or prompts, even experienced players were unsure how to proceed.

The visuals and atmosphere received positive feedback. Players praised the moody aesthetic and sense of isolation the environment created.

One of the most frequent requests was for better feedback systems—when something changes (e.g. a door opens, a checkpoint is reached), there needs to be a sound, animation, or camera cue to reinforce it.

Memorable Quotes:

“The movement feels great—but I had no idea I could climb that ledge.” “I got lost after beating the enemies. Wasn’t sure what I’d triggered.” “Loved the mood. It really felt like I was exploring something ancient and dangerous.”

These sessions were incredibly helpful in identifying gaps in player understanding. I now see how critical it is to test not just if a mechanic works, but how players discover and use it naturally.

Assignment 3 – Postmortem: Echoes of the Tower:

With the prototype for Echoes of the Tower now complete, I’ve taken time to reflect on the project’s highs, lows, and everything in between. This postmortem captures the most valuable lessons from this phase of development.

What Worked:

The ledge-latching mechanic, once understood, was a standout feature. It gave platforming a unique vertical rhythm and added challenge without needing complex level design.

The overall game atmosphere was praised by nearly all testers. The visual tone and ambient audio created a strong sense of place and tension.

The core gameplay loop (explore, survive, reach the exit) was simple but effective. Most players found the experience satisfying once they figured out the mechanics.

What Could Be Improved in Development:

I underestimated how confusing core mechanics would be without onboarding. A simple tutorial section would have saved many players from frustration.

There was little to no visual feedback when progress was made. Players needed clearer confirmation when things happened (e.g., unlocking a door).

The enemy AI was functional but basic. Adding attack tells or reaction animations could make encounters more dynamic.

What Could Be Improved in Design:

The prototype lacked context or narrative framing. Players wanted to know who they were, why they were in the tower, and what their goal was beyond survival.

The ledge-latching mechanic needs clearer visual indicators—perhaps a hand reach animation or glow when a ledge is grabbable.

There were no optional paths or secrets. Adding rewards for exploration would increase replay value.

Feedback Highlights:

“I loved the idea of the ledge grab—once I figured it out, it felt really smooth.” “It’s cool that you don’t explain everything, but I got stuck early on and thought it was a bug.” “I'd like to see more variety—maybe different enemy types or hidden rooms.”

Final Reflection:

Fullerton’s principle that “games are built through iteration” became a central theme throughout this project. I began designing around what I thought was cool. Through playtesting, I shifted focus to what players needed to understand and enjoy. That shift—from developer-centric to player-centric—was the most important lesson of all.

Next steps? Add a short tutorial section, improve visual clarity, and expand on the tower’s world. The foundation is strong—now it’s time to build something even better.

[eyvindm]

Highway Racer Post Mortem

I have really enjoyed developing "Highway Racer". I've used a few new elements in GDevelop that I have not used previously. I feel like my code is getting cleaner for every new game i make.

I had to make separate groups for the cars going in the same direction and the ones in the opposite direction to make them spawn on in the correct lanes. Late on I had to make a new group with all of the cars to be able to easier count the score. The score mechanic was a bit tricky to implement, but I eventually got it working. To count the highscores I had to use both scene and global variables.

Overall I've learned a lot. I'm getting better at using the tricks from previous projects to faster implement features in this new game. Can't wait for the next project!

After you crash, you get a 5second screen before it restarts. If you got a new highscore it will tell you, and update the highscore top left. When the countdown reaches 0, the game starts over.

[eddieripps]

is it going to be a literal genuine game that we could play as well?

in like 5 years unless i suddenly become an entire indie studio. i got a laptop and a dream homie...

but the gifs / videos are in fact from me playtesting. its playable just Very badly and rough as rocks and only nat's route works atm lmao

but if i ever do get it to a point that it's actually engaging and fun to play i'll throw it online somewhere for yall to go wild. would never capitalize on joy my friend

[marmaduke7755]

been a while since I've used this wacky website (scratch)! this is the first thing I made.

(music: omega by infugue)

[danaclement26]

Platformer 1: Development Part 1

This is my first time using GDevelop5 to develop a game, so initial development was largely learning how to navigate and utilise the engine. Default character sprites, platform, and environment textures were used at this stage of development, with focus on creating the basic level structure and interaction between sprites.

I succeeded in developing character movement using arrow keys, animations, and player-enemy collisions making the enemy die when the player jumps on it, or the player die if the enemy touches them – however there were no level restart upon player death nor any menus at this stage of development.

This prompted me to next work on developing a death field, for if the player falls off the platform they die, as well as trigger the level to restart if the player does die. I also created checkpoints along the level, so that if the player dies they do not start from the beginning and can continue from the last checkpoint they reached. [Gif – death ]

Although the coins at this stage would disappear when the player touched them, there was no coin counter – yet. I next implemented a UI that included the ‘score’, which counted how many coins the player collected through the level.

[Gif – score]

[castlesconundrum]

-[Game story]- (Pizza tower clone)

The story (so far) is as follows:

You are a guy named "Mike"

Mike has anger issues, but is overall a cool guy. (he also loves hamsters and cats.)

One day, mikes village is taken over by this evil dictator (I don't have a concept of him drawn digitally yet.)

Mike didn't give too rats asses about this guy until mikes best friend was kidnapped and taken to the top of the tower. (Note: This isn't exactly a medieval tower, the tower its self is actually magical.)

Eventually, Mikes neighbor (mistakenly) gets a letter from the castle, saying that Mikes friend had been kidnapped, the letter was from the dictators personal jester.

(picture of the jester) Mikes neighbor (his name is Jerry.) gives the letter to mike, and they head off to the tower to get Mikes friend back.

On the way (or before) Mike drinks this potion, and it gives him the power of speed (and some other things, i mean this is a PT clone after all lol.) Ex: when he gets mad his arm(s) turn really buff.

Running animation if you where curious.

That's all for the story at the moment, there's some other characters ill talk about in some future posts. (Also the game is being made using Gdevelop5.)

[layzlee]

Assignment 3 Development Progress

In this post, I will be taking about my assignment 3's development progress with my group members and I. The team only consist of 3 people including myself.

Our Elevator Pitch

"Space Narwhal is a single-player roguelike asteroids-like game set in space but comes with a unique twist. Earth has discovered an otherworldly material which is capable of annihilating invading aliens. However, its scarcity makes the use of ammunition an unfeasible method of attack, so instead of shooting bullets, astronauts integrated the material onto the spaceship itself! Use your hypersonic thrusters to dash around, dodge space hazards, and charge through your enemies. The target demographic for this game is people who want a thrilling, action-packed, fast-paced game that is hard to master, filled with precise gameplay and formidable boss fights."

What we are doing

As mentions in our pitch above, our game is an asteroids-like game where you will be piloting a ship and dashing through enemies in your way. After much discussion within the team, we had decided to have 3 stages within our game, 2 consisting of basic enemies and the final stage consisting of a boss enemy. We came up with multiple variants of basic enemies, such as the ghost, golem, cultist and eye. We have also designed 3 variants of bosses.

Our game will have dashing as its main method of movement and attack. After every stage, there will be shop where the player could buy upgrades. The upgrades will range from stat upgrades to powerups that can cause explosions.

What we have done

We have set up github and are using git to share the GDevelop 5 Project. We are using git for version control and made sure that we enabled multiple files in GDevelop5, enabling us to separate parts of the project. This enables us to work on the project separately and eventually bring it all together into a working game.

We have found and added all the enemy sprites into the assets folder of our project with names that makes sense and animations that we need. Since this game was chosen from one of the three games that we made for assignment 2, we do have the initial implementation of the game, which has the movement of the player.

What to do now

We now need to develop the movement/basic AI of the basic enemies and bosses. Implement the powerups and upgrades and then add the shop feature to the game. Implement and gradual increase in difficulty after every loop of the game.

Closing Statement

It is nearing the end of the semester and there are many assignments from every unit that all three of us are taking. I hope that we are able

[carena-gamedesign-120]

Racing Development

I followed the tutorial guide document to create my racing game. This was my first racing game. It was exciting and also quite a challenge. However, some instructions weren't in order, so I struggled. To solve this problem, I researched on Google and I found an official guide link: https://wiki.gdevelop.io/gdevelop5/tutorials/roadrider/#road-rider-endless-car-game-tutorial This helps me to create the whole game. in addition to this, I still had some challenges, such as the tree not being in the right place, the cars did not display, and the score did not add. After my continuous testing, I solved them. After that, I add a "GAME OVER" scene to finish the game.

In the future, I would like to add the background sound and different cars must have their engine sound. I also want to design more graphics maps to make more game levels.

[walker-dev]

RollWorld Development #1

Working on the game mechanics

To create something interesting and different to the puzzle platformer genre I've decided to make a game centered around a physics-based game engine. This mechanic will hopefully be very focused on gravity and could create some very interesting puzzles and situations for the player.

So, I've started working on the mechanics of the game, specifically the world rotation part and how gravity will work.

World rotation + gravity vector

Camera mechanic (zoom in/out)

Level design with puzzles + objectives (key & door)

Gravity Vector + World Rotation Implementation

In order for the player to move the ball along the map, the player needs to control the world so that the ball can "roll down" a slope. As mentioned in the previous post this game focuses heavily on physics and momentum.

There were two ways of implementing this; either I have the entire world and it's objects rotate, or I rotate the camera. The latter seemed like a better and easier approach.

Implementing the world rotation was quite easy: Player press LEFT/RIGHT = World rotates clockwise/counter-clockwise.

However, trying to implement a changing and dynamic gravity vector was not as simple.

I had to figure out how GDevelop's Physics 2.0 Engine parsed in values for the gravity vector. Initially I thought using sin() and cos() methods required x in sin(x) and cos(x) to be an integer. Normally you'd expect sin(90) = 1 and sin(30) = 0.5, except it seems like GDevelop requires a unique type specifier of radians in order to make sin(90) = 1.

For example:

Let x = 45.

sin(x) = 0.8509

sin(ToDeg(x)) = 0.806

sin(ToRad(x)) = 0.7071

Seems like sin(x) in GDevelop assumes x is radians then calculates sin(45 rad).

ToDeg() converts radians to degrees with x*180/pi then calculates sin(45°).

ToRad() converst degrees to radians with x*pi/180  correctly returns 0.7071 as expected.

This confused the hell outta me but I get it now. I've also been working on a simple level to try the simple world rotation mechanic. Seems pretty good so far and the ball is behaving as expected.

Angle conversions can be found here: https://wiki.gdevelop.io/gdevelop5/all-features/common-conversions/

[owlzer]

your original game should be functional, internally complete, and balanced. - Fullerton (ch10, pg342)

Chapter 10 was especially useful to help me move forward with the experienced I gained from my platformer. I want to improve my prototypes to a level where I can get the most out of the playtesting experience. I want to be able to use all the four basic steps of game design (foundation, structure, formal details and refinement) for my first playtest of my asteroids game. Therefore I plan to start by focusing on making the core gameplay functional and engaging before adding enough structure to build out the rules and procedures. As I struggled with my time limit last time, I want to ensure all of my components are purposeful so I may refine my game to the best possible.

Week 6 - Asteroids Development 1 Progress

Modifying What I Had

By then end of the week 4 tutorial, I had a basic asteroids set up with a player character moving in the direction of the mouse that could shoot with left click. Asteroids were also spawning in various sizes and I had lives. When an asteroid of any size collides with the player they lose 1 health point. I immediately changed the player's movement as I wanted this game to be local PVP, to turning with 'a' and 'd' with thrust being applied with 'w' . I also added player 2 with the same movement using the arrow keys. To create the low gravity effect I wanted, I used the physics 2.0 behaviour on the players using the tutorial here: https://wiki.gdevelop.io/gdevelop5/tutorials/asteroids/ship_and_movement_controls/#moving-forward

I also used the tutorial to change the 'Game Over' screen to a Player 1 and Player 2 wins screen each that would be displayed when either player lost all of their lives.

Creating New Mechanics

To make the Kirby suction effect I had to get a bit creative. I started by creating new sprites which are hitboxes attached to the Players to detect if an asteroid is in their range. When the asteroids collide with this hitbox, if the players holds 's' if they're Player 1 or the down arrow if they are Player 2, the asteroid will be pulled towards them and become a bullet that they can shoot. To shoot the bullets Player 1 presses 'e' and Player 2 presses 'm'. Like the tutorial, the bullet can destroy asteroids but they can also deal 1 damage to the enemy player. Using this suction mechanic I also added food that floats around with the asteroids that the player can suck up using the mechanic from before. Each piece of food heals 1 health point. However, to ensure that the player could not exceed the maximum amount of lives they started with, I used min values instead of simply adding to my lives variable.

References:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[blog10856609]

Week7 Simple Shooting Post-Mortem

First of all, I thought that the game could be more playable. I wanted to make players' hearts dance with the game more. To do this, I needed to make the power-up items and the enemy bosses attack in a different way.

The first improvement I made this week was the use of coins to use power-up items. By obtaining these coins, the bullets fired by the player were enhanced, increasing from one to three shots. I also changed the bosses' attacks so that they behave in a visually interesting way, rather than monotonously as in the previous version. There is room for other improvements to this as well, such as increasing the strength of the bosses and moving them around.

However, there is still a weakness in my game development. That is the player's behavior off-screen. Players get an advantage even if they get an off-screen power-up item. Further game enhancements are needed to eliminate this kind of cheating.

The development of this shooting game in GDevelop5 has had a significant impact on my knowledge of game development. The easy-to-use specifications and the use of extensions made it an interesting and good class for me to learn from, and I will be able to use it to a great extent in my future game design construction.

[n11279907]

Week 2 Elevator Pitch & Development

This week we started working on a platforming game in GDevelop5. I had asked my friends if they had any idea on what they wanted me to make for a platformer, and once of them suggested Barbie. Finding the concept interesting, I decided I would make a Barbie themed platformer.

Title of Game

Barbie Mountain

Elevator Pitch

Barbie has been invited to a party with all the other Barbies at the top of Barbieland mountain. Her journey ahead is dangerous, with scissors, markers, storage containers, and paint in between her and the party. Using her range of clothing to help her navigate, she is determined to make it on time to dance the night away!

Image Inspiration

Control Diagram

Barbie has to slowly move upwards through the level, with her being able to equip different outfits when she is stationary on a safe platform. These outfits have different power ups, such as a double jump, dash, a stronger attack, or slow fall. The player must decide which is best to progress through the level, as they cannot access all abilities at the same time.

Selling Points

The game will have a cutesy pink artstyle, and, if music were to be added, it would be upbeat. Being able to swap in and out of costumes allows players to remember what they have equipped and use different abilities to solve problems The key audience for the game is 8-18 year old girls and anyone with nostalgia for Barbie

Development

After a few days working with the concept, I have created a few things First, I made a platform for the game. It is meant to resemble plastic. Slow fire rate

By having the left and right be distinct, it allows for rounded platform edges I have also implemented two of the powerups. The player can choose between less gravity or a faster firerate, with the player having to stand on the ground to change between them. There is no visual update yet, but I plan to implement it. To create a better scope for the short time frame given, I have decided to use only the two powers instead of four, and implementing the others will take time and later will take a lot of level planning for one power up to not be better than others.

Fast fire rate

Slow fire rate

Low gravity

High gravity

[momentstum]

The new GDevelop 5 updates 104 & 105 is available for use.

Highlights:

104 has new tiled map, shape painter, support for isometry in top-down movement behavior features with improvements to AdMob & Firebase, yarn editor, procedural generation etc and bug fixes.

105 has improvements to GDevelop games showcase added to tab of new project window, normalized expression, map a value between min and max, condition to check if key is released and help link for Admob actions and conditions.

Visit GDevelop github for more info: https://github.com/4ian/GDevelop/releases

[zosister-blog]

Week 8 is about working on the racing game & creating a one-page and a one-sheet!

This week I’ve been working on trying to implement an AI driver you can race against in GDevelop. There were several ways to implement this but I chose to use pathfinding as the easiest way. As described on the GDevelop Wiki it says,

“Pathfinding behavior allows us to move objects to a selected destination as well as to flag items as obstacles. Objects that are flagged as obstacles will be avoided by the moving objects.”

All I needed to do is map out the course for the pathfinding behaviour to use to get around the map using coordinates and inputs of where to go.

As I didn’t get it ready for playtesting I decided to use an exercise from Fullerton;

“Describe in detail what goes through your head as you play the game. Start a playtesting notebook in which you record all of the feedback you get from yourself and other testers.”

It was fun to drive around the track and see the AI driver driving beside me. I didn’t get the boost working and so I couldn’t beat the AI driver but I could drive around the track.

The game I chose to do the One-Sheet and One-Page on was my asteroids game “Rock Hunt Rocket”.

I made a note board to figure out what I needed on each page,

Sell-Sheet:

One-Page:

Another exercise from Fullerton helped me figure out how to write my razor statement and slogan.

“Try to capture what makes it interesting to you and how the basic gameplay will work. …. For example, the razor for the original Medal of Honor was “GoldenEye set in WWII on a PlayStation.” Entis felt this was a great razor because it allowed the team to decide what features the game absolutely needed. It was not a great slogan, however. The slogan that went on the box was, “Prepare for your finest hour.”

The first razor statement idea I came up with was,

“Asteroids but with upgrades!”

But then it got upgraded too,

“Play as an ace pilot where you shoot meteors, Collect materials & Upgrade your ship!”

The Slogan that I came up with for this game is,

“Try to get the best upgrades and the most materials!”

I’ll show the final design in the next post!

victrisgames. (2021). Pathfinding [GDevelop Wiki]. GDevelop Wiki. http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/pathfinding#pathfinding

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. ProQuest Ebook Central https://ebookcentral.proquest.com

[estallion]

Week 5 Asteroids elevator pitch

Moving into week 5 this is my elevator pitch for a "Asteroids" like game. I will be applying the skills gained from my first pitch in Gdevelop5 to develop this new project.

Title: Cosmos Custodian

Genre: Top down shooter, Asteroids-like

Audience: PG13+

Description:

As a lone star pilot, you must defend the home world against a swarm of enemy pilots and the Mothership. A range of both deadly weapons and support pickups will be available to defend your ship however, the enemy pilots may also gain new upgrades!

Game controls:

Mouse direction for movement

Left click to fire main weapon

F key to fire special weapon

Shift key for dash

Unique selling points:

Variety of weapons and pickups

Progressive difficulty as player survives

unique enemy types

[whughesgamedev]

Week 3 - Platformer Development

Fullerton’s book contains interesting sidebars from professional game designers. In one sidebar, Scott Kim outlines that “to design a good puzzle, first build a good toy.” (2018). What Scott implies from this statement is that players should have fun interacting with a game, even before completing the objective. Mimicking Scott’s mentality I started on the digital prototype by creating the player controller.

GDevelop’s inbuilt platformer behaviour would not be able to incorporate the physics interactions of the grenade’s explosion. Instead, the player’s avatar, grenades, enemies, and the environment are all physics objects. Using Wishforge Games’ tutorial (2020) as a guide, I was able to implement basic movement and jump controls. To prevent double jumps, I attached an object to the player to check if they are grounded. The ground check was also used to adjust the player’s movement in air to account for the lack of friction with the ground.

Once I was happy with the avatar’s basic movement, I went on to create the grenade mechanic. To start, I created a crosshair sprite in Illustrator. The sprite is a large transparent box with the crosshair offset from the centre. I then added an event to the crosshair to update its centre position and rotate it towards the mouse position. The grenade sprite is placeholder sourced from the GDevelop tutorial (“How to make a platform game”, 2020) project that I completed last week. I then added an event which allowed the player to spawn the grenade on left click. When the grenade spawns, it has an initial force applied to it, in the direction of the crosshair. Decreasing the grenade’s density and increasing its gravity force provided a nice projectile motion.

For the grenade jump functionality, I added an event which is triggered when the player right clicks and is within range of the grenade. When triggered, the event applies a force to the player’s avatar causing it to move away from the grenade’s position, whilst also deleting the grenade. For added visibility, I made the grenade change colour when they are within range of the avatar.

I have been experimenting with an Illustrator function known as Image Trace. The process groups an image into its major colour components, which can provide an interesting visual appeal. I wanted to try implement this technique for video game assets. I started by recording my hand doing a simple run and jump animation. I then selected specific frames from the video in which my hand was in key poses. I image traced the keyframe which would represent the avatar’s idle pose. I then removed the background and added an outline to the hand sprite. I was happy with the outcome; however, it was a time-consuming process and as such, I only had time to implement the idle pose.

Whilst implementing the controls for the player I aimed to emulate the principles set out by Fullerton (2018). A successful and immersive control scheme relies on effortlessness and intuitiveness. WASD and Spacebar are common inputs for movement and jumps on PC-based platformers, and inputs for the grenade are all based on mouse clicks and movement. I believe this was the optimal control scheme for effortless and intuitive gameplay, with the current mechanics.

References

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games (4th ed.). CRC Press LLC How to make a platform game. (2020). GDevelop Wiki. Retrieved August 6, 2021, from http://wiki.compilgames.net/doku.php/gdevelop5/tutorials/platform-game/start Wishforge Games. (2020, August 24). How to Make a Physics Engine Platformer Game in GDevelop – Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=96gNCmnQwaE