Text
Week 13 - Assignment 3 Postmortem
Working on Storm The Core has been one of the most challenging but rewarding parts of the semester. At the beginning, I knew I’d be in charge of UI and gameplay mechanics, but I didn’t expect I’d end up learning so much about system design and problem-solving too. I spent hours watching YouTube tutorials on GDevelop, especially to figure out how the event system, linking logic, and inventory menus actually work. It took a while, but it really helped me understand how everything fits together.
The inventory and shop systems were the hardest for me. Trying to get them to interact properly with variables and game progression took longer than I planned. I wanted the system to be simple but feel meaningful to players, and it was frustrating at times when it didn’t work the way I expected. But eventually, after testing and adjusting, it started coming together.
Along the way, I naturally fell into more of a project manager role. I kept checking in with my groupmates about how different systems were working, what features we still needed to finish, and how the whole thing was feeling from a player’s perspective. These team discussions helped us stay focused and shape the direction of the game.
We still have things to fix based on playtesting. Right now, bullets push enemies in strange ways, XP isn’t being tracked clearly, and the UI could definitely look more polished. I also think adding damage numbers when enemies get hit would make combat feel more satisfying. There’s still work to do, but honestly, I’m proud of what we’ve made so far and how much I’ve learned from it.
0 notes
Text
Week 12 - Assignment 3 Development Progress
I’ve been watching a lot of YouTube tutorials to understand how inventory systems work in GDevelop, and it helped a lot. I rebuilt my system with external layouts and variables so it's cleaner and easier to manage. Instead of hardcoding item logic, I now use dynamic text fields for slot data, which gives me more flexibility later on. Setting up the drag-and-drop and dynamic naming took longer than expected, but it’s finally starting to work properly.
I also realised I was doing my pause menu buttons the hard way, so I went back and rebuilt the button layout in a simpler way that uses less code and looks more polished. I’ll still tweak the fonts and sizing later, but I’m happy with the structure now.
he next step will be working on the item drop system when defeating enemies. I want to make sure enemies can drop items that get added to the inventory properly, and that the visuals and logic behind the drop feel rewarding. Once that’s working smoothly, I’ll start refining how the inventory reacts when new items are picked up or dragged around.
0 notes
Text
Week 12 Game Discussion
This week, I spent some time reflecting on the usability concepts covered in Lecture 9 and Chapter 9 of Game Design Workshop. One point that stood out was how important it is to give players instant and clear feedback. Even small design elements like showing damage numbers when hitting an enemy can completely change how responsive a game feels. These pop-ups might seem minor, but they reinforce player actions and help communicate progress in the heat of battle.
In our own game Storm The Core, we realized during playtesting that players often had no idea if they were damaging enemies or making progress. Adding floating damage numbers is now on our to-do list, it creates better feedback, adds clarity, and makes the combat feel more satisfying. This aligns closely with what the book says about feedback loops being a key part of making a game feels right.
I also found it interesting how Game Design Workshop encourages iterative design. It made me think about how our team can improve through constant testing and adjusting. Even in a top-down shooter like ours, clear signals like enemy flinching, damage indicators, and consistent audio cues help reinforce player expectations.
Going forward, I’ll keep usability and feedback in mind as I continue working on enemy mechanics. Making sure players always know what's happening on screen, and why, is what keeps gameplay engaging and intuitive.
0 notes
Text
Week 11 Assignment 3 Playtesting
I. Gameplay Feedback We reviewed core gameplay elements during internal playtesting and identified the following issues and improvements:
No Health or XP Feedback There’s no clear display of player health or experience. This made it hard for players to understand progression and survivability. We plan to implement proper HUD elements including a health bar, XP tracker, and credit counter.
No Damage Pop-Up Feedback Damage numbers don’t appear when enemies are hit. We’ll add floating damage pop-ups to give players better feedback and make combat feel more satisfying.
Shop UI Needs Work The shop is working but feels unfinished. There’s no visual clarity on what each item or upgrade does. We’ll redesign the shop interface to make it more user-friendly and visually engaging.
II. UI and Visual Fixes
Add HUD: health, XP, credit display
Improve shop layout and iconography
Make the pause menu and skill buttons clearer
Refresh the UI design to feel more sci-fi and polished
III. Combat Mechanics and Physics
Bullets currently push enemies back due to physics force, which looks unnatural
Plan to remove or reduce enemy knockback for cleaner hit responses
Next Steps
Finalize turret and projectile visuals
Add HUD with player status indicators
Implement floating damage numbers
Polish UI for shop, skills, and pause menu
Adjust physics to fix bullet knockback
We’ll be focusing on these fixes in the next development sprint to improve gameplay feel, player understanding, and the game’s visual impact.
0 notes
Text
Week 11 Group Formation and Assignment 3 Team Discussion
This week we discussed how we would design and present the game’s UI, including how the HUD and shop menus should look. We also finalised what upgrades and skills would be available in the shop, and how players could interact with them during checkpoints. Our MVP will focus on smooth space combat, enemy wave progression, and strategic upgrades, with simple but clear UI that supports the core gameplay loop.
0 notes
Text
Week 10 Assignment 3 Development Progress
DESIGN
Over the past few days, our team discussed how to shape the moment-to-moment gameplay of Storm The Core. We agreed early on that the game needed to feel responsive and satisfying in both movement and combat, while still being readable and not visually overwhelming. I focused on a few key systems to keep interactions fun but not too complicated for the player:
Simple UI, Clear Feedback One of my biggest goals was building a clean interface that shows health, XP, energy, and ability status without cluttering the screen. I implemented a pause menu that uses a layered overlay and variable tracking to animate the UI elements. Players can use arrows to navigate and Return to select, and I made sure it feels snappy to match the game’s fast pacing.
Modular Player/Enemy Logic To make our game systems more manageable, I separated out all player and enemy logic into different event sheets using GDevelop’s event linking. This lets us keep things readable while still giving flexibility to update combat, movement, and AI wave spawning. We want each wave to feel distinct, and the later waves will ramp up with stronger or faster enemy types.
Player Movement & Combat Core The movement is drift-based, with friction so the player can still stop and control easily. Shooting is done via mouse aim, and we’ve designed the controls so players can boost, aim, and fire at the same time without awkward key binds. We’re aiming for a combat system that rewards mobility and smart positioning instead of just spamming fire.
DEVELOPMENT
So far, I’ve completed the pause menu system and UI logic. This includes the overlay visuals, input handling, animation switching, and variable-based state control. It took some iteration to get the menu navigation working smoothly, especially the part where pressing escape pauses the game and brings up a clean UI that can be interacted with.
Although I haven’t built the combat or wave mechanics myself, I contributed by helping set up the structure for both the player and enemy systems alongside my team. We’ve laid the foundation so the next steps like wave escalation, ability upgrades, or enemy pathing can be built without cluttering the core logic.
Next, I’ll focus on linking more UI feedback to in-game variables, like displaying health, XP, and energy. I’ll also start preparing for how the shop menu might work during checkpoint sectors.
Right now, we’re on track with our planned features. The game loop is shaping up, and the structure we’ve built so far is solid for layering more complexity over time.
0 notes
Text
Week 9 Postmortem – Brisbane Drift
Working on Brisbane Drift taught me a lot about how much small mechanics can impact player experience. Most of my time went into tweaking the car controls, especially making the drift feel smooth and the turbo boost rewarding without breaking the balance. I learned how subtle changes in rotation speed or slowdown during drift could completely change how responsive the car feels. Once those mechanics were in place, the game became much more satisfying to play.
One area I struggled with was onboarding. Players were thrown straight into the race without any explanation of what the keys do or when to use drift or boost. I saw during playtesting that some players just held down the arrow keys and never touched the drift button. That made me realise I had not explained the core mechanics well enough. This ties directly into one of the most important lessons from the textbook and lectures. If players do not understand the rules or goals, they will not be able to enjoy the game, even if the mechanics are solid.
I think the gameplay loop worked well overall. The player enters a track, drifts around corners, collects boosts, and tries to improve their time. The slight track variation added replayability without needing lots of content. But I did not design a proper feedback loop around improvement or make it clear what the player was trying to master. There was no lap timer or star rating system, so players were missing that extra motivation to keep going. Looking back, I can see how adding just a bit of progression or performance feedback would have helped a lot.
If I had more time, I would focus on building a better onboarding experience and improving the way I explain goals through the environment. This could be done with signs on the road, a tutorial lap, or visual effects that highlight when a player drifts correctly. I would also spend more time playtesting with new players, not just people who already understand racing games. That kind of feedback is the most valuable when it comes to making a game feel intuitive.
Overall, I am happy with what I created. The game is simple but fun, and it does what I set out to achieve. It has taught me to pay more attention to how players learn and how important it is to show them not just how to play, but why the mechanics matter. In the future, onboarding will be one of my top priorities from the start.
0 notes
Text
Week 8 - Assignment 2 Progress
This week, I focused on finalising the one-page and one-sheet for Fantasy World. After refining my game’s elevator pitch and gameplay breakdown in previous weeks, I spent time cleaning up the layout, visuals, and structure to clearly communicate the design.
The biggest part of the update was reworking the Game Overview to better reflect the story and feel of the world. I also made sure the key features highlighted the actual gameplay mechanics like skill tree progression, spell-based combat, and story-driven zones. I paid attention to keeping the style consistent and pixel-art themed to match the vibe of the game.
It was fun translating my rough dev blog ideas into something that looks like a real design document. This version feels more professional and something I can actually use to pitch the game. I also cleaned up the keyboard layout and rewrote some of the UI labels to keep everything more readable and polished.
0 notes
Text
Week 8 Dev Blog: Gameplay Ideas and New Mechanics
This week, I worked on adding new gameplay mechanics to make my racing game more exciting and skill-based. I introduced a drift function and a turbo boost ability for the player’s car.
When players hold down the Spacebar, the car now rotates faster and moves slightly slower, simulating a drift around corners. It makes turning feel much smoother and lets players take tight corners without crashing. I learned that small adjustments to rotation speed and movement force can completely change how a car feels to control.
I also added a Shift key turbo boost. When players press Shift, their car gets a short burst of speed, making it possible to overtake obstacles or recover from a bad drift. I added a simple cooldown timer to prevent players from boosting non-stop, which helps balance the gameplay.
Overall, these changes make the driving feel much more dynamic and fun. Adding just a few simple mechanics made a huge difference in making the racing experience more challenging and rewarding. I’m excited to keep testing and polishing the controls even more in the next steps!
0 notes
Text
Week 7 Blog Post: Racing Game Progress
This week, I worked on building the systems for my racing game, Brisbane Drift. I set up the basic player movement, added rotation for steering left and right, and created traffic cars that spawn randomly to block the player’s path. Trees were also added to the sides of the road to make the scene feel more alive.
One thing I learned this week is how important timers are for controlling when objects appear. I used different timers for spawning traffic and trees, and it made a big difference in making the game feel more dynamic instead of empty or overwhelming.
I also worked on setting up collision detection. When the player’s car crashes into a traffic car, it now triggers an explosion animation and deletes both objects. Getting this part working made the game feel a lot more complete, even though the visuals are still pretty simple.
Overall, it was a fun experience watching the game slowly come together piece by piece. If I had more time, I would like to add a score system based on distance traveled and maybe even different car types with different speeds.
0 notes
Text
Racing Elevator Pitch - Brisbane Drift
Brisbane Drift is a fast-paced 2D street racing game where players drift through the nighttime roads of Brisbane, avoiding obstacles and hitting boost pads to finish races faster. The gameplay focuses on smooth drifting, quick decision-making, and mastering tight turns to beat personal bests and opponents.
Game Controls:
Arrow Keys or WASD for steering
Spacebar to drift around corners
Shift to activate a turbo boost
Unique Selling Points:
Simple Drift Racing: Easy to pick up, rewarding to master with satisfying drift mechanics and fast races.
Turbo Pads: Speed boosts placed along the track reward bold racing lines and risk-taking players.
Random Track Variations: Slightly changing track layouts make every race different and keep players on their toes.
Target Audience:
Ages 7+, aimed at players who enjoy fast racing games, simple drift mechanics, and casual arcade-style competition.
Setting:
Set in a neon-lit version of Brisbane at night, players race through stylized city streets, sliding around tight corners and zooming past iconic urban landmarks.
Player Motivation:
Players are motivated by mastering their drift skills, hitting perfect racing lines, chaining speed boosts, and setting new personal best times across unpredictable tracks.
0 notes
Text
Week 7 - Star Defender Postmortem
This project taught me a lot about how to get the core mechanics of a game up and running, especially when working with arcade-style gameplay. Setting up the asteroid spawning system was probably the most satisfying part because I was able to make something feel random and dynamic without losing control of the game flow. I used timers to space out the spawns and shooting mechanics, which really helped make the pace feel balanced. At first, everything either felt way too slow or way too chaotic, but after some trial and error, I got it to a point where the game feels pretty fair and fun.
I also worked a lot on the collision logic between the player bullets and the asteroids. It’s one of those things that seems simple at first but can get tricky once multiple objects are flying around at once. I spent time figuring out how to manage object deletion and random movement patterns without breaking the gameplay.
One of the biggest takeaways from this was realizing how much small tweaks matter. Just changing the speed of an object or the angle it moves at can completely change how it feels to play. If I had more time, I’d add more content like asteroid splitting, enemy drones with different behavior, or a more fleshed-out upgrade system. But overall, I think this is a strong start and I feel confident about improving it further in future iterations.
0 notes
Text
Week 6 Blog Post: Asteroid Game Progress
This week, I worked on building the basic systems for my Asteroid-style game. I set up player movement, shooting mechanics, and random asteroid spawning. The player ship now moves smoothly toward the mouse position, fires bullets on click, and asteroids appear at random spots with random movement directions.
One thing I learned is how important timers are for controlling the flow of gameplay. Not just for firing bullets, but also for spawning enemies at good intervals. It took a bit of tweaking to get the asteroid spawning and bullet firing to feel right without overwhelming the player too quickly.
I also had to think about object behavior more carefully. Giving the asteroids random angles and different sizes helped make the gameplay less predictable and more fun. I realized small changes like adding randomness or different speeds can make a simple game much more dynamic.
Overall, I'm happy with how much I learned about managing object creation, collision logic, and using timers effectively. If I had more time, I would love to add more features like asteroid splitting or player upgrades. For now, I feel like I have a solid foundation to keep improving on.
0 notes
Text
Asteroids Elevator pitch – Star Defender
Star Defender is a fast-paced 2D space shooter where players pilot a small spaceship through endless waves of asteroids and alien drones. Players must dodge obstacles, destroy enemies, and survive for as long as possible. The gameplay focuses on tight controls, quick reflexes, and unpredictable challenges that keep each run feeling fresh and exciting.
Game Controls:
Arrow Keys or WASD for movement and rotation
Spacebar to shoot
Shift to activate a temporary shield ability
Unique Selling Points:
Simple Arcade Feel: Easy to learn and fast to play, offering an authentic arcade experience perfect for short and intense gaming sessions.
Dynamic Power-Ups: Shields, triple-shot upgrades, and speed boosts drop randomly to help players survive longer and add new layers to gameplay.
Endless Random Waves: Obstacles and enemies are randomly generated, making every session unpredictable and challenging.
Target Audience:
Ages 5+, aimed at players who enjoy arcade shooters, fast reflex games, and retro-inspired experiences.
Setting:
Set deep in a distant galaxy, players take on the role of an elite pilot defending the last remnants of civilization from roaming asteroids and alien threats in the void of space.
Player Motivation:
Players are motivated by surviving longer against overwhelming odds, collecting power-ups to improve their ship, and beating their own high scores as they face increasingly difficult waves of enemies.
0 notes
Text
Week 5 - Platformer Postmortem
Looking back at the development of Fantasy World, I can definitely say it was a big learning experience. I spent a lot of time building the inventory system, which turned out to be way more complicated than I first thought. It took ages to figure out how to set it up properly, from tracking the items to getting everything to display in the UI and making sure the interactions worked smoothly. It was frustrating at times, but I learned a lot about variables, events, and how GDevelop manages object behavior.
Throughout this project, I ended up watching tons of YouTube tutorials. Some helped directly, while others gave me new ideas or helped me look at things differently. Every time I fixed a bug or finally got a feature to work, it felt really rewarding. I never thought I’d enjoy problem-solving this much, but honestly, it was one of the best parts of the whole process.
Talking with my teammates helped me understand more about how to approach design problems. We had lots of back and forth about things like what kind of skills we wanted in the game and how the enemy patterns should work. Even though I wasn’t leading the project, I still felt like my input made a difference in how the game turned out.
There’s still stuff I want to improve like polishing animations and expanding enemy behaviors but overall, I’m really proud of what we created. It feels great to see all the pieces finally come together
0 notes
Text
Week 5 Dev Blog: Bug Fixes, Attack Effects, Animations & Hit Logic
This week has been all about fixing bugs, finalizing game mechanics, and pushing forward with animations and effects.
Bug Fixes & Logic Refinement I’ve finally squashed the bugs that were preventing the monster attack effect from appearing at the right place. After some tweaking, the attack now spawns exactly where I want it to, no more weird positioning or misplaced effects! The attack logic for both the player and the monster is working smoothly, and the game is feeling more responsive.
Attack Effects & Animations I focused a lot on the visual effects this week. The player’s magic attack now has a clean animation, and its projectile effect is firing smoothly, thanks to the bullet behavior. I also finalized the monster attack animations, making sure they sync up properly with the attack timing. The game feels much more dynamic now, with the visuals aligning with the actions.
Hit Logic I’ve also implemented hit detection for both the player and the monsters, so damage is dealt when the projectile or attacks land on the target. The logic works well, but it’s still something I’ll be fine-tuning to make sure the experience feels balanced.
0 notes
Text
Week 4 Dev Blog: Early Gameplay, Monster Attack Bugs & Player Projectile Progress
This week, I started piecing everything together and I’m finally seeing my game come to actual gameplay!
Gameplay Development I’ve implemented basic character movement, jumping, and enemy patrol behavior. It’s been really exciting to test things in action and watch the hero and monsters interact in the world I’ve been designing. There’s still a long way to go, but the core elements are slowly coming together.
Monster Attack (Bug Troubles) This week came with some challenges to be honest. I worked on the monster's attack logic, and while the animation triggers correctly, the attack effect is not appearing where I expect it to. Sometimes it spawns behind the monster, or at a weird angle so I’ve been tweaking the spawn position and direction logic. It’s been a bit frustrating, but I’m slowly narrowing down the problem.
Player Attack Effect For the player’s attack, I’ve decided to use GDevelop’s bullet behavior to simplify projectile movement. I’m replacing my old fireball code with a custom magical effect, and so far it’s making things easier to control and tweak. I’m also working on syncing the firing with the hero’s animation so it feels responsive and polished.
Next Steps
Fix the monster's attack effect positioning
Finalize player projectile visuals and hit logic
Add sound effects to attacks and impacts (could do)
Even though I ran into a few bugs this week, I feel like I did make a good progress and learned a lot about debugging and how positioning works in GDevelop.
0 notes