#gdevelop

Hey! Just showing another lil sneak peak on the video game! I have 6 areas with the complete list of enemies already programmed in. I have 8 areas fully done visually, with 4 more areas that have zero work done so far. Each area has a minimum of 8 maps, and a maximum of like, 18. Some maps are huge, some are small.

I've had a few weeks just to stay home and focus on game dev, and most of that focus has been poured into creating enemies and programming better AI. Some of the enemies are still.... very wonky, but most of them have been smoothed out.

Also I wanted to get some input on the particle effect visuals here! I just finished programming this enemy (Toughest so far) and I wanted to know something. When you hit an enemy and do damage, I have the confetti image, but when you hit an enemy and no damage done, I have the shields. Does that come across okay? (Also I know the shields are brighter when you hit the enemy with a sword, then when you jump on the enemy. I fixed that right after recording this)

HI YALL IM MAKING A GAME

I was drawing these idiots again after forgetting they existed-

ALSO this weird test thingy I made has been in the back burner for a while now so...

have at you🫴

controls:

left and right arrow keys = movement

space = jump

X = interact and comfirm

Z = progress dialogue

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.