IGB120

Hey guys! Final post for this unit, (exciting but sad)!

We have done some heavy play testing on our last assessment game, "Entropic Collapse"!

From this play testing we have gathered 6 sets of play test data with lots of useful data to modify the game to be more enjoyable and play smoother.

Most players found the game fun and the controls responsive, especially liking the physics-based movement and black hole mechanic. However, some struggled with managing the asteroid and black hole at once, calling it a "split-brain" challenge.

The bomb and shield enemies were consistently marked as the most difficult. A few players felt enemy spawns were unfair (e.g., spawning directly on the player or asteroids).

Most commonly players couldn't figure out when / why upgrades were happening. The current system used in all play tests was a small progress bar at the bottom of the screen which was hard to see and blended into the background. Players didn't see this and took a long time if ever to find the bar and understand it. This is the main thing that was fixed for the final version of the game.

Current progress bar shown below. Note how it blends in.

Upgrade menu shown above, added since last post, beautiful Ui graphics by my team member. Unique upgrades, more than 6 unique upgrades depending on the upgrade tree you pick!

Post Moterm

Postmortem

Our goal with Entropic Collapse was a fun, physics based fast paced game where you destroy enemies and get upgrades. This was completed by our team of 4 to major success, having all mechanics created and mostly polished. Sound effects, music, ui, graphics and coding all created by the team to best of our abilities. Feedback from play testers was utilized in every step of the creation of the game to ensure it was the best it could be.

What Went Right

Core movement felt fun — physics were clean, black hole + asteroid combo hit nice

Sound and visuals were great — menu background movement, particles, lighting all got good feedback

Upgrade system added a cool layer once people figured it out

Players said it was fun and would play again

Play testing gave solid direction, especially around UI and pacing

What Went Wrong

Rubble system + upgrades were confusing at first, not obvious enough

Bomb + shield enemies felt a bit unfair or hard to read

Tutorial was skipped by heaps — bottom text especially got ignored

Some UI bugs with upgrades showing after death

Difficulty ramp was too slow if you just avoided everything

Lessons Learned & Improvements

Tutorial needs better layout — bold important text, icons, maybe split into steps

Rubble needs clearer feedback (bar, upgrades, etc.)

Enemies need indicators — like shield recharge countdowns or bomb timers

Push players to actually engage with mechanics, not just dodge

Save time for polish: menus, transitions, end screens all add heaps of value

Thank you for reading these past 13 weeks, I personally had lots of fun learning GDevelop and expanding my game knowledge and skills, as well as reading the chapters assigned to us of the game design textbook.

Peace and love,

Hey hey! Based on play testing feedback on Entropic Collapse, our game, we have made some changes!

First of all, we set up a Trello to put all the ideas / changes we need to make in one collaborative spot. Very handy!

From the feedback last week it was found that players would like a tutorial screen to teach them the gameplay at the beginning. This was added.

This is interactive and allows users to see how to destroy enemies in a controlled scene. I have been working on music for the main game as well as sound effects. These really add to the overall atmosphere of the game. My group mates have been working on Ui design as well as new art assets. A few attached below. I created the main menu UI which I am happy with, has interactive assets amongst it too.

There is ALOT more to add to the game before its finalised and we will continue to play test throughout this development to ensure we have the best game we can create during the timeframe.

Hey! Its been a busy few weeks but we managed to play test our game, Entropic Collapse, with a few peers!

We set up a time to play test with 3 unbiased students at QUT and recorded their results in google forms. The data revealed that players generally had a very positive experience. Most found the game fun to play (average enjoyment score: 4.67/5) and praised the main character design and controls. The difficulty level was seen as moderately challenging (3.0/5), with some frustration reported, mostly due to enemy spawn behavior—particularly bomb enemies spawning too close or unfairly on top of players or asteroids. The Shield Enemy was consistently identified as the most challenging opponent. Despite the challenge, players with varying gaming backgrounds all seemed to grasp the gameplay quickly and enjoy it, indicating strong accessibility and design clarity. Overall, the game resonates well with experienced players and has a solid foundation, with only minor tweaks needed for enemy behavior and fairness.

It was noted that players would like a tutorial screen at the beginning as they couldn't figure out what to do in the beginning. This will be added next week.

In other news, I have recently finished reading chapter 11 of Game Design Workshop, fourth edition. A standout idea is the concept of "living out fantasies" through gameplay. Fullerton points out that great games let players explore identities or experiences they might never have in real life, like being a space pilot, a rogue hacker, or even a villain. Games like GTA V thrive on this. It’s a reminder that games are a safe space to explore “what if?” questions, fantasies, fears, and alternate lives. It stuck with me as something to think about for the future in my game design journey.

Wow, week 10 already! How time flies.

This week we started Assignment 3. I have formed a group with Bowen, Kaitlyn and Lachlan!

Whats the assessment about you may ask? We have to pick one of the games we made during classes to develop into a fuller more polished game as a group.

As a group we viewed each member's one sheet and made pros and cons lists for each one. In the end we decided on Lachlans game about a black hole controlling an asteroid to destroy other asteroids. It had fluid and fun mechanics which we decided would be fun to develop.

We needed to pick a game name. This took an hour of our meeting in the Library and eventually Bowen suggested Gravity Giggler as a joke. Pretty funny name which we ended up using as the group name. Finally the game name was decided as "Entropic Collapse"

We allocated tasks and started work.

My job in the group is to make the music / sound effects, UI and be the play testing communicator. I was excited to be in charge of music as I've never made any before and am keen to learn. I jumped straight into garage band, my DAW of choice as it's free and already on my mac. I wanted to make a spacey kind of sound and started playing around with chord progressions and different samples. After a few hours I ended up with this song which we will probably use in the main menu. I will need to create a few more tracks for in game and during boss fights.

While I was working on that, Bowen made amazing progress finishing the one sheet and one page. Looks amazing!

Hey! Been a busy week trying to work on the racing game as well as the assessment. We got some player feedback to go through as well as a post mortem. Lets go! I had 2 peers play my racing game and give feedback. The main points were as follows: 1. Too hard (pink car is too fast)

2. Not visually appealing

3. Needs more obstacles

I have taken this feedback and modified the game in the time that I had. Whilst I would have liked to do more, I had to focus on Assessment 2 which I will show you soon!

As you can see, the assets have been updated to have better looking trees, a green background and more smooth camera visuals. I have added a "Oil Puddle" obstacle which makes your car hard to control and shakes the camera. I have also moved the car back so that you have more time to react to the pink car, as the feedback requested.

Sadly, this brings the development of the racing game to an end. While I had high hopes for this game I was unable to bring my vision to life in the time I had. This brings us to the post mortem.

Postmortem

My goal with Highway Hustle was to create a fast-paced endless racer where players would need tight reflexes to dodge cars, hit boosts, and collect gears to push for a higher score. This was my first time building a racing-style game in GDevelop, so a lot of the project was focused on learning how to handle movement, obstacles, and polish within the engine.

The idea was to make it feel intense but replayable—something short and satisfying that challenges players to beat their best score.

What Went Right

Core movement feels satisfying and responsive. The car has good acceleration and turning.

Implemented a working score system based on time survived and obstacles dodged.

Added obstacles like oil puddles that made the game more chaotic and fun.

Visual updates (like smoother camera movement and tree assets) made it feel more complete.

Peer feedback helped quickly highlight key issues with difficulty and visuals.

What Went Wrong

Ran out of time to add more varied obstacles or power-ups.

Original art assets looked too generic and didn’t match the game's intended retro aesthetic.

No proper ending or scoring screen, so the game didn’t feel "finished" or loopable.

Background and UI felt a bit bland despite improvements.

Lessons Learned & Improvements

Visual style matters a lot, especially in fast-paced games where things flash by quickly.

Always leave room for polish time—UI, end screens, and transitions matter.

Future games should start with a strong reference board to guide the look and feel from day one.

Onto talking about my assessment!

I have finished the one sheet and one page. Here is the final design, I'm quite proud of it.

Hey! Just thought id hop on here and update you to my Assessment 2 One Sheet design. I completely scraped the old design and decided to go for a retro design inspired by games like Rampage.

I got a free model of a monster that matched the vibe of my game and textured it in blender with old 80's shiny basic textures. Rendered it with simple lighting and chucked it into photoshop. Added some title text, a background and then worked on the foreground elements.

This was the first design that i sent to the IGB discord server to get feedback on. It was clear by the feedback that the layout could use work, the top text was too small and the info needed a background. I went back to photoshop and edited it again, this is my final result for now.

Hey! I have continued development on the racing game. Currently I have implemented the main movement, one obstacle and the score. I had a fun time configuring everything to my liking and still need to swap out the default assets with my own. Below is a short gameplay clip of the current state.

As you can see, there is still alot of work to do in order to get the game up to my standard and to match the pitch. I will be continuing to work on the game in the coming days.

As for my Assessment 2 in IGB120, I have begun work on the one page. Below is the current state of my one page, still needs lots of work as in my opinion the main title fonts do not match the style of the rest of the page. I may change to a more pixelated font similar to the subtitles. I have created this one page in Adobe Photoshop.

This week I wrapped up my asteroids game in GDevelop—before moving on, here’s a quick postmortem for “Asteroid Tycoon.”

Pic of me developing asteroids :)

Postmortem My goal with Asteroid Tycoon was to blend a classic top‑down shooter with light tycoon mechanics: blast incoming space rocks, grab coins, and funnel earnings into turrets and idle money‑makers. I wanted it to feel like an action game you could walk away from and still see progress.

What Went Right

Core shooting & pickups: Player can now shoot asteroids, pick up coins, and see cash instantly add up on the HUD.

Upgrade basics: Bullet cooldown and ship speed upgrades are in place, giving a real sense of progression.

Clean UI: Health, money, and upgrade panels are clear—everyone knew where to look.

Early playtesting: Ran sessions with two classmates; their feedback pointed out key issues fast.

What Went Wrong

Difficulty balance: Players could park and let turrets clear everything. It felt way too easy.

No loss state: The game never ended on death—no stakes, no tension.

Upgrade impact: Some upgrades barely changed gameplay. Cooldown tweaks weren’t obvious.

Visual polish: Temporary art looked inconsistent across screen resolutions, and there were no track boundaries.

Lessons Learned & Improvements

Balance from the start: Tweak enemy speed and turret damage so players can’t cheese the waves.

Implement failure: Always build in a clear “game over” and map limits—players need consequences.

Meaningful upgrades: Design each upgrade to noticeably alter play (e.g. explosive rounds, shield bursts).

Art consistency: Lock down resolution and style guidelines early to avoid last‑minute fixes.

RACER GAME

Next week i will be developing a racer style game. Here is my elevator pitch.

This week i worked on my asteroids game in GDevelop.

To recap, my game's concept is a take on the popular asteroids game but with some significant changes including:

Collect coins on things you destroy

Upgrade your gun / player

Place objects to destroy more things

The asteroids changed to mobs / zombies

I have made some development on this so far, even play testing with 2 people at the end of this development week.

As you can see, I have basic temporary artwork and UI that functions. The only current upgrades are bullet cooldown and player speed. I got 2 people to play test and the feedback is summarized as follows:

Gameplay:

Controls were intuitive (4/5).

Gameplay was enjoyable (4/5), but too easy (1/5 difficulty). Players could easily remain stationary and win.

Upgrade System:

Moderately rewarding (3/5). Upgrades weren't impactful and felt slightly distracting. Suggests adding shortcuts.

Clear explanations but could use more specificity (4/5).

Visuals and UI:

Visual style moderately matched gameplay (3/5); background inconsistent across devices.

Excellent clarity in UI (5/5), especially health, money, and upgrades.

General Feedback:

Liked the movement and turning mechanics most.

Suggested adding more enemy variety, boss fights with health bars, and special item drops.

Noted bugs: game doesn't end on player death; map lacks boundaries.

Enjoyable but room for improvement.

I will improve on all this feedback before finalizing the game.

Book Reading

This week I read chapter 10 of the Game Design Workshop book and have found an interesting mechanic i'd like to discuss, called Upkeep. This is found in the game Warcraft III. Basically, the more units you had, the less gold you earned. It was Blizzard’s way of stopping players from just maxing out their army and sitting on a pile of resources.

They wanted smaller, more tactical fights where your hero actually felt important—not just another unit in a giant blob. Upkeep forced players to make decisions: do I go all-in with a big army and risk going broke, or keep it lean and rich?

Funny part is they originally called it “Tax” and players hated it. Just changing the name to “Upkeep” made it easier to swallow. Small detail, but it shows how wording alone can shift how people feel about a mechanic.

This week we moved on from the platformer game and started planning the "Asteroids". Before planning the asteroids game, it is important to do a postmortem for my platformer "Cannon Dash"

Postmortem

My goal with the development of Cannon Dash was to create a fast paced 2D platformer that combines traditional mechanics with shooter elements. This is the first game I ever developed in the game engine, GDevelop, so it was a fun journey creating this while learning the software. In the game, players use a gun controlled by the mouse, aiming to shoot breakable walls and navigate interactive levels. Strategic gameplay revolves around precise shooting, explosive obstacles, and creative traversal.

What Went Right

I made some nice pixel art in Aseprite and got the gun rotation working smoothly.

Added fun features like exploding boxes, bounce mechanics, ladders with gravity, and flying upwards by shooting down.

Created cool puzzles where players needed to think and aim carefully.

Playtesting with my classmates helped spot issues quickly.

What Went Wrong

Bullets bounced weirdly, making it feel unrealistic.

Players kept falling forever without restarting, and some coins couldn't be collected.

Ran out of time to make enough levels.

Lessons Learned & Improvements

Play testing early and often helps catch major issues.

Realistic physics matter a lot to players.

Better time management and planning levels from the start will help future projects.

Asteroids Game

The next project I will be working on is an asteroids style game in GDevelop. Here is the elevator pitch:

"Asteroid Tycoon" is a top-down defense game where you blast incoming asteroids, earn cash, and build your own asteroid-crushing empire. Upgrade your main gun, place automated turrets, and unlock money-making machines as you survive endless waves of space debris. Combine strategy and action in this mix of shooter and idle gameplay.

This week I spent time developing my platformer game "Cannon Dash"

I drew art for the game in a program called aesprite, ensuring to separate the arm / gun from the main body so that i could code it to rotate to the mouse.

Once i had the gun figured out I implemented the platformer movement and started level designing.

I also implemented a few features such as exploding boxes, gravity for the ladder, bounce boxes and firing below you to fly upwards.

The exploding boxes made for an interesting mechanic as you would have to use your gun to progress past them or to get them to make something else happen (such as a ladder fall)

The bouncing boxes also allowed for some interesting placement of coins where you couldn't normally reach them without bouncing the bullet off the box, requiring some aiming skill.

It was then time for play testing. I had 3 peers in my class play test the game and I got some feedback 1. Bullets bounce off the boxes weirdly (not how it would work in real life)

2. Falling into the void doesn't restart the game (fall infinitely)

3. Some coins can't be shot or picked up

4. Not enough level / levels.

This feedback was useful to continue development of my platformer as I can fix these bugs and ensure a better experience for the players. Adding new levels was already on my list but time was a big constraint.

This week I developed an idea and an elevator pitch for my GDevelop platformer game. I wanted to take a traditional platformer and add a new aspect from a different genre. I thought about what could combine well and came up with a mix of a 2D shooter with a platformer. The bullets can be used to break / hit stuff in your path, clearing it for you to keep progressing.

Introducing Cannon Dash: A fast paced platformer that arms you with cannon. Use your mouse to aim and shoot breakable walls to progress further in the level. But beware—strategic shooting is key; destroying the wrong platform could trap you, preventing level completion.

Hey, my name is Alex Roper. I am currently studying Games and Interactive Environments at QUT Brisbane. This blog has been created for the IGB120 Introduction to Games course.

About me

I was born in Darwin and moved to Queensland when I was 8 years old. I attended Caloundra State High School and studied digital solutions, design and chemistry. My hobbies include photography, gym and creative media — particularly graphic design and game development.

My dog (Benson) and I

I have been creating games since primary school, starting in basic programs like Scratch and working my way up to the Unity game engine. I’ve always been passionate about games — playing Minecraft since I was seven and later getting into games like Valorant as I grew up. However, creating games always appealed to me more. In Year 8, I developed and shared my first game with all my friends. My Digital Solutions teacher was both impressed and slightly frustrated, as her students spent class time playing it on the school’s computers instead of doing their work.

My first game

From there, I deepened my knowledge of the Unity game engine, developing multiple games and achieving high placements in game jams on itch.io. I also expanded my skills in 3D modeling and texturing, initially using Blender before transitioning to Substance 3D Painter for more advanced texturing.

I knew when I graduated high school that I wanted to pursue a technology degree at QUT, and I found my current degree to be the perfect fit for all my interests.

I look forward to continuing to blog my adventures in this course and sharing it with you!

Bonus Photos

My cat (Becky)