#platformer postmortem

[donnatang]

Platformer Postmortem

🕹️ Platformer Development – Postmortem

This week, I developed a basic platformer game using GDevelop. I implemented keyboard controls, platforms, enemies, and core mechanics like jumping, walking, and collisions. Using the Event Editor, I learned how to trigger animations (Jump, Walk, Idle) and set up enemy movement logic with direction flipping and collision handling.

✅ What Went Well

Built a functioning game loop with player movement and enemy interaction.

Applied conditions and events effectively to manage animations and collisions.

Learned to manipulate game logic visually without coding.

Integrated responsive sprite behaviors such as enemy flipping and animation changes.

⚠️ What Could Be Improved

Enemy movement is too basic—only flipping direction at borders. It could be enhanced with more dynamic behaviour.

Collision consequences feel abrupt; visual/audio feedback would improve the experience.

Platform layout is simple. Adding power-ups, hazards, or moving platforms would make gameplay more engaging.

[karlyhuynh]

Update character (Development)

Hi everyone,

I just draw my character for my boom birds, they look quite dumb and not professional, and i try to let my character (Player) can use gun to shoot the birds, chickens, ducks which i updated. But now I'm fixing the problem that I want these enemies can drop the boms randomly, and "Player" need to avoid all of that. One game will have 10 bullets or more, and 2 lifes, and I try to draw some background to let it not too boring when player play it, such as, clouds grass.

[wenqi-wang]

Platformer Postmortem

In terms of the Inspiration for my prototype, I barely had any idea until I found one line from Fullerton's book telling me that I could design games based on life experience. This reminded me of the old days when I was a little kid jumping on the trampolines. Thus, a hardcore platformer came up, requiring intensive timing to jump.

Fairly saying, I prioritized the prototype before working on my elevator pitch first due to the concern of advertising what I may fail to offer, resulting in the uncertainty of the ultimate demonstration. Although I should have completed the pitch first in order to create my prototype efficiently, as the tutor mentioned, you should prioritize the core gameplay before adding other components.

One thing I wanted to improve was the little gameplay which made my prototype uninteresting. I would like to add more compelling gameplay if possible in case the repetitive mechanics frustrate players a lot and add respective tiers of difficulty what I learned from the class is that we are not supposed to traumatize our audiences being game designers.

[katewrrn]

Platformer Postmortem

I am actually surprised my game turned out pretty okay (mostly glad that it's playable). When i first came up with the prototype idea, i planned for it to be a simple yet enjoyable game that i could expand on in the future once i gained more skills from my uni course, but for a first time making/prototyping a game, it went better than i thought. As i mentioned, i love games that evoke powerful emotions such as happiness, sadness or even excitement. In the future i would love to incorporate that into my game idea, achieving the element of surprise we learnt in our IGB120 lecture 4.

Improvements i would make for the future would definitely be to work on my coding and understanding GDevelop's functions as i believe that hindered my ability to make the game the most. I also feel like i could get more playtesters and different perspectives; comparing the different experiences. Playtesters who have experience/ don't or those with different interests. Fullerton suggests "rules before you playtest" such as 'playtest before you think you are ready'. This suggests to playtest on the prototype in progress rather than a completed work, as this a better way to improve the game.

I'd love to create something more original for my future games. As cute as the free assets were, i believe there were details id like to add that could improve the overall visual design of the prototype, however, i would need to improve on my skills before achieving this. I’d also refine the level design. Even though this is just a prototype, it would be great to have a more polished layout. While the simplicity is intentional, I believe I can make it more engaging while still keeping it accessible.

Overall, i enjoyed the prototyping and playtesting experience of my first game and I can't wait to improve my skills to make better games.

references: Fullerton, T. (2019) Game design workshop: a playcentric approach to creating innovative games. AK Peters/CRC Press/Taylor&Francis Group, LLC. (pg.294)

[jasonigb120]

Platformer Postmortem

Game Introduction This is a 2D game based on platform jumping mechanism. Players can stand on the platform that matches their color by switching colors. By constantly switching colors, players have to jump, solve puzzles, and avoid enemies （such as slimes） in the level. Once they step on the wrong color platform or are hit by an enemy, the game is over.

What Went Well The character switching mechanism is quite interesting The overall feedback of the Game Over interface is good.

The slime can automatically move back and forth, flip direction, and detect collisions, and its behavior is stable.

The style of the background, characters, platforms and other materials is unified, and the visual effect is harmonious.

What Could Be Better

The game lacks voice acting or background music, and there are no special effects when the characters die, which is a bit abrupt.

Lacks complete level design and advanced gameplay and will consider adding more colors and puzzle gameplay later.

Temporary future plans Add background music, sound effects, special effects.

Add more color platforms, more characters and enemy types.

Allow characters to sprint, attack and more operations

Introduce a score system and clearance process to build a complete level.

Add a tutorial for novices to familiarize themselves with the operation.

[tetley1173]

Platformer Postmortem

By Shannon Tetley

In this post I'm going to talk about my thoughts on the platformer game I made now I've moved on from the project for now. It served its purpose which was to teach me how to use Gdevelop but I don't think its very good as a game. People who have play tested it for me have a less harsh opinion but from my point of view its very obvious that it was a rush job. This doesn't mean it was a failure though as I did learn a lot from making it.

What aspects of my required reading did I apply to the project?

Not a lot if I'm honest. Not that the readings didn't inspire me though. I was very focused on the basics so I didn't implement much of what I learned from readings but it did give me plenty of ideas. The readings taught me lots of game design practices that I would apply to the game if I were to work on it some more.

I've had a few ideas of what I would change now that I've read up on the topic of game design:

I would add a title screen to the game to invite the player into the world and to build their interest.

Playtesting revealed that having a linear path through the world helped lessen the mental burden on the player allowing them to better engage with the jumping challenges.

I would pay close attention to the 'feel' of the jumping challenges. I learned that a challenging obstacle isn't the same as a good obstacle. I made some interesting and challenging platforms to navigate but because there was a little jank with the way you jump through them the players didn't like it.

Overall polish the game more. I think some better animations would improve the feel of jumping and dying. Balancing the game more would help as the game is a little trivial as is. Playtesters didn't die once and they missed out on seeing my death animation which I believe would have added to the feel of the game for them.

What's one thing I'd change about my development approach?

I would plan the rules, objectives and challenges that the payer faces in the game before I sat down to make it. To borrow a quote from the creator of the Civilisation series of games Sid Meier, "Games are a series of interesting decisions". As is, my game doesn't present the gamer with many opportunities to make interesting decisions. The way I made the game was to go with the flow and just make whatever I felt like at the time. Having a loose plan may have not only sped up my development time, but also help me to incorporate interesting decisions for the player. It would also be easier to apply other game design concepts I learned into the game, as it would no longer be an afterthought to do so.

[n11456388-adrian-lai]

Platformer Postmortem

After completing my first game in Gdevelop, I have learnt what Gdevelop does and how to make my own game in it.

I have also learnt a lot from the book Game Design Workshop: A Playcentric Approach to Creating Innovative Games by Tracy Fullerton : A Playcentric Approach to Creating Innovative Games, Fourth Edition by Tracy Fullerton. This book has inspired me a lot when I was deisgning Planet X and I will list them out as follow:

First two chapters: I have learnt the importance of playtesting and prototyping for game designers. Therefore, in order to ensure I am able to deliver a smooth and interacting game experience to the players, several playtesting and prototypes have been done.

Chapter 3(Working with Formal Elements): I have learnt to define the player's role in game clearly. For Planet X, the player's role is to help Zyrahn to eat as many alien enemies as possible.

Chapter 4: I have learnt about considering dramatic elements when designing games, such as setting up a story and theme for my games. For Planet X, I have set up the story of Zyrahn and what he encountered in the mysterious planet.

Chapter 5: I have learnt about system dynamics in game design. In Planet X, blocks are placed in random positions around. Players can jump between different blocks , some of them are close/far between each other, while some of them are high/low between each other. The player must stay on the platform to survive.

Chapter 7 & 8: This chapter is about prototypinig. In order to have the ideas on how to design and develop my game, I have done some prototypes for my game. Some refinements were made during prototyping before I came out with the final version of my game.

I sketched out prototype ideas of my gameplay concepts. According to the book, prototypes can be completed by simple sketches physically or digitally. In order to make refinements or move objects easier, I did my prototype on a tablet computer.

According to chapter 7, refinement is the time to add all good ideas for features that have come up while testing. My first version of my prototype is platfroms will be placed on about same level with different heights. I realise the game could be more fun to have platforms all around. This allows the player to reach platfroms at different height and levels; thus enhances the player experience and make it flow.

Book reference: Fullerton, T. (2019). Game design workshop : a playcentric approach to creating innovative games (Fourth edition.). CRC Press.

[smallnim]

Platformer Postmortem

I have now approached the end of my platformer. Although I have achieved less than what I had planned to, reality presents challenges harder than expected but that just means that I have to push for more next time.

Throughout my experience with GDevelop, I have been supporting my development process with understandings from Fullerton's Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition (2019). Segments of the book that I have read so far which have had a huge impact on my design process were chapters 2, 5, 6, and 7. Although everything I have read so far has helped, these chapters especially made it possible to develop what I have so far.

Chapter 2 gave me insight on approaches to make the game more engaging for players which I believe I have achieved (Based on friends and colleagues playtesting and providing feedback). Chapter 5 helped me gain a better understanding on the properties of my game and how their separate complexities add onto the game. Chapter 6 helped me in conceptualising my idea by utilising different methods to help me break apart different game ideas, especially the mind map. As for chapter 7, it further expanded on chapter 6 where it highlighted the importance of visualising core gameplay from my original game concept. This helped especially as I was losing track of myself in the various ideas I had come up with, so without this, I probably would not have a functioning game if I had focused on special features rather than the core gameplay.

Now reflecting on my game, using what I just mentioned about the chapters, if I were to change how I developed the prototype, I would definitely prioritise core gameplay before moving onto aesthetics and other various features of the game as I limited the amount of time I had to actually piece the game together after adding numerous features. As for the design aspects of the prototype, I would have tried to incorporate more of the simple designs and features obtained and learnt from my workshops as those alone were enough to make a decent game.

With all that said, that concludes my platformer postmortem. Thanks for tuning in, I'll be signing off now, see you in the next post!

References:

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

[lilymakesgames]

Platformer Postmortem

Inspiration from Readings

Fullerton's (2018) introduced me to the concept of PX goals and how they can guide design: playtesting results and even playtest planning can be informed by the PX goals as they provide something to measure and evaluate against. This subsequently enables more informed iteration for a better game overall. Fullerton (2018) also asserts that designers should strive to be advocates for the player, and using PX goals is a great way of achieving that. It is the first step to considering the player's perspective and one of the first steps toward to playcentric design.

Changes to Prototype Development

From playtesting, it seemed that the prototype's most pressing issue was its lack of substantial gameplay. A simple issue with a simple solution of adding more levels and implementing that third design idea of environments and narratives to situate the player. The jump itself felt good and I don't think there were any technical complications regarding GDevelop so the issue (and solution) likely lies within the limited emotional and intellectual pull of the game, again likely due to the lack of content. For now, establishing the M2M gameplay and the quality of the jump mechanic is a good starting point.

Changes to Design

As previously stated, the M2M and jump mechanic felt good so I think building on this by designing a double jump could vastly elevate the game. Adding a double jump furthers the player's in game abilities and opens a huge avenue of design possibilities. There are so many new situations for the player to exploit the mechanic but also new challenges to design that will force players to be strategic with it. This has the added benefit of addressing the issue regarding limited intellectual stimulation.

Thanks for reading!

References

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Forth Edition (4th ed.). CRC Press LLC.

End of post.

[maeveuniblog]

Platformer Postmortem

The cycle in which we prototype a platformer is complete!

If I'm being perfectly honest, I didn't develop the platformer as much as I wanted to. The start of this semester has been way way way way way way way way busier than i expected, so I frankly didn't have much time to work on it. (If any uni students are reading this, part time work and full time uni are NOT a good combo)

Working on a game that I've been thinking about for a really long time in a new engine that I don't really enjoy like... at all made me lose a lot of motivation to make more levels, or try to make a functioning game.

All of the fundamental aspects that this platformer would need are there. The primary game mechanics are set in place, with major room for more development in future. Assets and a general vibe for the game had been created, a tutorial system was shown, UI elements, and actual game play were all on display.

To extend the game, different kinds of moving platforms, and hazards would be added. I want to come back to this game at a later date but in something like Unity or Godot; engines I'm familiar with, and with a larger scope of capabilities.

I've uploaded the prototype that I did make to Itch.IO, but frankly, it's not worth playing. In a few years, maybe one day as a solo project I'd want to make it into it's own game. Possibly in a Game Jam, it feels like a Game Jam sort of game.

Anyways, the next cycle is for an Asteroids inspired game, which I better get thinking on.

[wheeledspy55]

Week 5:

Snail Pace - Platformer Postmortem:

[crasypup87]

Post-Mortem - Run, Chicken, RUN!!!

One thing I’d change about how I developed my prototype is to spend more time working on my game. Due to scheduling conflicts with work and other uni assessments, I was unable to work on Run, Chicken, RUN!!! As much as I wanted. This resulted in a very buggy, early version of the game. One thing I’d change about the design of my prototype is to customise the score and health bars. This would provide more life and character for the game and could appeal to more users. I’d also like to try out different powerups. I’d love to try out a sword mechanic, or a dash mechanic and i-frames.

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

[samirabbasgamedev]

Primal Ascension Postmortem: What Went Well and Lessons Learned

Wrapping up Primal Ascension, I've reflected on key successes and areas for improvement.

Successes:

Core Mechanics: The evolution mechanic effectively provided strategic depth and encouraged repeated play.

Rapid Development: Quick iteration cycles allowed for effective incorporation of feedback from playtesting sessions.

Challenges:

Balance Issues: Initially struggled to balance evolution thresholds, leading to gameplay pacing problems.

Visual Feedback: Players needed clearer visual indicators to understand evolutionary progress and combat outcomes.

Lessons Learned:

Constant player feedback and iteration are crucial.

Clear UI design significantly impacts player understanding and enjoyment.

Moving forward, I'll apply these insights to upcoming projects, especially around UI/UX design as emphasized in our textbook (Chapter 5: User Interface Design).

[igb120-tracy]

Week 7

Issues: 

Players found the map quite small as I only had one scene background with moving clouds.

No clear reason to collect items besides “because they’re there”

No such thing as endgame.

Process Changes i need to make: I jumped to working on the aesthetics before securing the gameplay loop, and working on the game mechanics. Next time I’ll focus on loop logic before trying UI. (Ch. 6 – Conceptualization). I only focused on the assets and never really got to fully work on the game logic. If it works it works?

Probably need to broaden the map. However, I will only be focusing on this one map that i've already got for now. Will get a bigger map after figuring out the game logic first.

Changes to make: If the player doesn’t collect the mails quickly, the mail vanishes. Adds urgency without breaking theme.  Deciding if I should change the goal of the game or keep it (boring?) more relaxed gameplay for the player.

[tetley1173]

Platformer Postmortem

By Shannon Tetley

In this post I'm going to talk about my thoughts on the platformer game I made now I've moved on from the project for now. It served its purpose which was to teach me how to use Gdevelop but I don't think its very good as a game. People who have play tested it for me have a less harsh opinion but from my point of view its very obvious that it was a rush job. This doesn't mean it was a failure though as I did learn a lot from making it.

What aspects of my required reading did I apply to the project?

Not a lot if I'm honest. Not that the readings didn't inspire me though. I was very focused on the basics so I didn't implement much of what I learned from readings but it did give me plenty of ideas. The readings taught me lots of game design practices that I would apply to the game if I were to work on it some more.

I've had a few ideas of what I would change now that I've read up on the topic of game design:

I would add a title screen to the game to invite the player into the world and to build their interest.

Playtesting revealed that having a linear path through the world helped lessen the mental burden on the player allowing them to better engage with the jumping challenges.

I would pay close attention to the 'feel' of the jumping challenges. I learned that a challenging obstacle isn't the same as a good obstacle. I made some interesting and challenging platforms to navigate but because there was a little jank with the way you jump through them the players didn't like it.

Overall polish the game more. I think some better animations would improve the feel of jumping and dying. Balancing the game more would help as the game is a little trivial as is. Playtesters didn't die once and they missed out on seeing my death animation which I believe would have added to the feel of the game for them.

What's one thing I'd change about my development approach?

I would plan the rules, objectives and challenges that the payer faces in the game before I sat down to make it. To borrow a quote from the creator of the Civilisation series of games Sid Meier, "Games are a series of interesting decisions". As is, my game doesn't present the gamer with many opportunities to make interesting decisions. The way I made the game was to go with the flow and just make whatever I felt like at the time. Having a loose plan may have not only sped up my development time, but also help me to incorporate interesting decisions for the player. It would also be easier to apply other game design concepts I learned into the game, as it would no longer be an afterthought to do so.