arhamh

[arhamh]

One page and One Sheet

[arhamh]

Week 13 Post 13 Final Postmortem, Submission & Reflection

It’s finally the end of the semester and Hoard.io v2.0 is finished! Looking back, I’m really proud of how far the game has come and how much I’ve learned.

Final Postmortem:

What worked: The upgrade menu and weapon swap systems got the best feedback in our last playtests. The new enemy types and ability system made each round feel different. Playtesters said the game finally felt fair and fun.

What I’d change: I’d start working on the visual polish and player onboarding (like tutorials) much earlier—players still had a few moments where they were confused at the start.

Teamwork: Our group communication and willingness to iterate were the real keys to success. Using Discord made it easy to keep track of tasks, and everyone stepped up to help with bugs and last-minute features.

Reflection: I feel way more confident not just in using GDevelop, but also in working with a team, giving and receiving feedback, and turning rough ideas into a playable project. I’m excited to use what I’ve learned here in future units.

Thank you to my group and our playtesters!

[arhamh]

Week 12 Post 12

This week, we focused on refining Hoard.io v2.0 based on all the feedback from previous playtesting sessions. Our main priority was to address the confusion around upgrades and add even more polish to the visual and gameplay experience.

Key Changes:

Upgrade Selection: We implemented a new end-of-round upgrade menu so players can now choose between health, damage, or range, inspired by suggestions from both playtesters and reading Fullerton (2018, Ch. 12) on meaningful player choice.

Weapon Swapping: The new prompt for weapon swapping feels much more natural, and playtesters reported that picking up new weapons is now satisfying rather than frustrating.

Balancing: We reduced the chance of health and shield packs spawning, which made rounds more challenging and strategic.

Visual Tweaks: Damage indicators and the death screen now match the cartoon style of the rest of the game. I also finally got to show off the shotgun and minigun sprites I made earlier—people loved them!

Bug Fixes: Rounded player health, fixed the UI overlay, and improved enemy variety.

Reflection: Every play test seems to bring up a new detail to fix or improve, but seeing how much the game has grown from version 1.0 is motivating. Fullerton’s emphasis on iteration and responding to player feedback has really shaped our process. I also learned a lot about working in a team, especially how much smoother things go when everyone is open to trying out new ideas and making quick changes.

Here are the weapons i designed using procreate.

[arhamh]

Week 11 Post 11

This week, our team kept iterating on Hoard.io v2.0. After last week’s big playtest, we made several changes: we aligned the damage indicator with the camera, tweaked the shield/health drop rates, and tried out a prototype for dropping and swapping weapons. We also started brainstorming how a melee attack could work in our current control scheme.

Further Playtesting: We brought the revised build back to the lab and had a new round of players try it. Right away, people noticed the visual fixes (“the damage ring doesn’t look broken anymore!”). The new weapon drop prompt also got good feedback—people felt less frustrated about missing out on new gear. There’s still some confusion around upgrades after each round, so that’s our next big priority.

Mechanic/Book Chapter Discussion: One thing that keeps coming up is how rewarding it feels for players to choose their own upgrade path. After reading Fullerton (2018, Ch. 12), I realised that giving players meaningful decisions—even just between health, damage, or range—makes every run unique. We’re planning to redesign the end-of-round upgrade system so that players can select from three categories: survivability, aggression, and tactics, inspired by games like Dead Cells.

[arhamh]

Week 10 Post 10 Play testing

This week was all about getting real feedback on Hoard.io v2.0. We ran formal playtesting sessions, using the script and surveys we set up last week, and watched as a mix of classmates and new players tried our game for the first time.

Playtesting & Feedback: We had eight users play Hoard.io, with a good mix of ages and gaming experience. It was honestly eye-opening to see how people played—some picked up the controls right away, while others struggled with mechanics like weapon swapping and close-range targeting. One of the most consistent pieces of feedback was about the visual style: players found the red damage indicator distracting, and the death screen didn’t match the cartoon theme. Mechanics-wise, people wanted to be able to drop weapons and deal with close enemies more easily. Several suggested adding a melee attack, which we hadn’t even considered at first.

Teamwork & Iteration: Our group met right after each playtest session to discuss what we observed and how to act on it. I contributed ideas for how to design the weapons and i supported the idea of adding a weapon drop mechanic. We split up the fixes, with everyone tackling different improvements (UI, mechanics, balance, and more). It really drove home how much faster and better you can iterate with a group versus working solo.

Reflection: Fullerton (2018, Ch. 11) talks about the importance of “listening to your game,” and this week proved how much you learn just by watching others play. There were issues that seemed small to us but were major annoyances for new players. We’re now planning another round of tweaks, especially to the upgrade and health systems, so the next prototype feels smoother and more intuitive.

[arhamh]

Week 9 Post 9

Night Drive Postmortem

This week, I wrapped up my Night Drive prototype and did some serious playtesting with friends and classmates. Here’s what I learned:

What worked:

The headlight/limited vision mechanic made the game way more intense and fun than I expected! Everyone said it felt tense not knowing what was coming next on the track.

The basic car controls felt smooth after tweaking the turn speed, and the neon track edges helped players stay oriented in the dark.

People really liked the synthwave soundtrack I found online and added as a background loop—it set the right mood.

What I’d change:

Random track generation is still too unpredictable; sometimes it makes impossible layouts. Next time, I’d script track pieces to ensure all layouts are actually finished.

I wish I’d added more visual feedback for collisions or going off-track. Sometimes, it wasn’t clear when you messed up.

I would add checkpoints or laps to encourage replaying and tracking best times.

Hoard.IO Development & Playtesting Prep

This week was a big step forward for our group project, Hoard.io v2.0. We finished our core prototype and started preparing for in-depth playtesting.

Development Progress: Our team pushed through the last major development hurdles and added new features for the prototype. I worked mainly on summarising the prototype and helping polish the core gameplay. Some big additions this week included updating weapon sprites, adding a player shield bar, implementing three new enemy types (swordsman, ranger, heavy), and introducing two new weapons (shotgun and minigun). The new player abilities—Dash, Shockwave, Glue, Bomb, Fast Fire, and Strong Bullets—add a lot of variety and depth. We also implemented a death/restart screen so playtesters could easily give the game another go

It was interesting to see how every new feature or fix made a big difference in gameplay. Fullerton (2018, Ch. 9) talks about how prototyping and playtesting are crucial for identifying problems that you wouldn’t notice just by looking at the code or playing yourself. Working in a team also made me appreciate how important clear communication is—everyone contributed a piece, and the game would not have come together without regular check-ins and honest feedback.

Preparing for Playtesting: We designed a detailed playtest script and feedback survey, making sure to get input from both regular gamers and people unfamiliar with roguelikes. We wanted to collect both quantitative ratings (like “how easy was the game to learn?”) and open-ended comments about mechanics, graphics, and theme.

Next week, I’m looking forward to seeing how real players interact with Hoard.io v2.0 and what surprising feedback we get!

[arhamh]

Week 8 Post 8

This week I focused on developing the core mechanics for my racing game, Night Drive, while also starting to work more closely with my group on Assignment 2.

Night Drive Development: I managed to get the basic top-down car controls working in GDevelop, which was surprisingly tricky at first. It took a few tries to get the car to feel “right”—balancing turning speed and acceleration is a lot harder than it looks! I also started working on the headlight effect. I used a transparent cone-shaped sprite to mimic the field of vision and layered it over the car. It actually makes a big difference; driving with limited visibility makes every corner feel risky.

I played around with random track layouts by using a few different tilemaps. Some track sections end up impossible to finish, so I’ll need to refine the randomisation logic next week. Playtesting with friends, I noticed that the limited vision mechanic was a hit—people got nervous and laughed every time the track twisted unexpectedly into darkness.

Assignment 2 Progress: My group for Assignment 2 finally settled on our game concept. We decided to split tasks according to our strengths; I’m working on level design and testing. In my group there is me ,Samir, Bryn,David and Hudson. We’ve started a shared doc for brainstorming and meeting notes, which really helps keep us organised. We also discussed some of the teamwork tips from last week’s lecture (especially about regular communication), and so far, our Discord group chat is working well. I feel a lot more confident about our workflow than in the first group project.

[arhamh]

Week 7 Post 7

Cosmic Debris Postmortem

I wrapped up the main prototype for Cosmic Debris this week. Overall, I’m happy with how the ricochet mechanic turned out, even if it made playtesting a little more chaotic than I expected!

What worked:

The bouncing bullets made the game way more tense and forced me (and playtesters) to think before shooting.

Ship movement felt smooth once I tweaked the speed settings in GDevelop.

Adding basic sound effects for shooting and collisions made the game more satisfying and gave better feedback.

What I’d change:

The ricochet mechanic was fun, but sometimes it made the screen too hectic. I would probably limit the number of bullets on screen or have a cooldown.

Asteroid spawning could use more variety—right now, it gets repetitive after a while.

I want to add a visual warning when a bullet is about to bounce near the player, so it feels more fair.

Reflection: Fullerton (2018, Ch. 7) talks about the importance of clear player feedback and iterative testing. I really saw that with this prototype—the more I tweaked, the more playable and fair it became. Playtesting with others was essential; they found problems I wouldn’t have noticed alone.

Elevator Pitch: “Night Drive”

For the next project, I’m starting a top-down racing game called Night Drive.

Genre: Top-down Racing

Mechanic: Players race on randomly generated tracks at night. The twist is that you can only see what’s in your headlights—everything else is hidden in darkness, so quick reactions matter!

Visual Style: Neon colours, synthwave music, and glowing tracks to match the night theme.

Target Audience: Racing fans who like arcade-style games with a bit of challenge.

Why this concept? I wanted to try something that focuses on visibility and fast reflexes rather than just pure speed. I think the limited vision will add tension and force players to learn the tracks as they go.

Next week, I’ll start building out the basic controls and experimenting with random track layouts in GDevelop.

[arhamh]

Week 6 Post 6

This week I started building the prototype for my arcade shooter, Cosmic Debris, inspired by Asteroids but with a twist—bullets ricochet off the screen edges, so you have to be careful not to accidentally hit yourself!

What I Did:

Used GDevelop to set up the basic ship movement and shooting mechanics. Making the ship rotate and thrust took a bit of getting used to, but the built-in behaviors helped.

The hardest part was getting bullets to bounce off the sides. I had to experiment with collision events and “flip” the direction when a bullet hits the edge. At first, they just got stuck, but after checking some GDevelop forum posts and re-reading the workshop notes, I got it working.

Added a few simple asteroids to test dodging and shooting. It’s already a bit chaotic (in a fun way)!

Mechanic/Book Chapter Discussion: The ricochet mechanic completely changes the way the game plays. You can’t just spam shots or you risk getting hit by your own bullets. I was thinking that every action needs to have clear feedback and real consequences. I’m trying to make sure that players immediately see when a shot bounces back, so it feels fair and not random.

I also noticed some games like “Geometry Wars” use crazy projectile patterns, which makes me wonder if I could add power-ups or different shot types later on.

Reflection: Building a game from a classic template but changing just one rule makes a massive difference to the feel. Next week I want to polish the visuals a bit, add sound effects, and maybe try having the asteroids split in two when shot.

[arhamh]

Week 5 Post 5

Platformer Postmortem: “Skybound”

Now that the first version of Skybound is done, I wanted to reflect on what worked, what didn’t, and what I’d do differently next time. Creating this prototype from scratch was way harder than I expected, but also more rewarding.

What went well:

I’m proud of the core disappearing platform mechanic and how it forces you to keep moving.

Adding the collectible star above the last platform gave players a clear short-term goal and made reaching the end feel more rewarding.

Playtesting with friends helped me see problems I missed (like how brutal some jumps were at first).

What I’d change:

If I did it again, I’d spend more time on level design and introduce mechanics more gradually. I realised after playtesting that my first level didn’t give players enough time to learn.

I’d also add more visual feedback (maybe an animation or sound effect) when platforms disappear or when you collect the star, to help make things clearer and more satisfying.

Reflection: Reading Fullerton (2018, Ch. 4) really reinforced how important it is to iterate quickly and to get feedback early. I learned more from watching my friends play than I did from hours of tweaking the code alone.

Elevator Pitch: “Cosmic Debris”

For the next project, I’m working on an Asteroids-style arcade shooter called Cosmic Debris.

Genre: Arcade Shooter

Mechanic: Players control a ship, shoot at asteroids, but with a twist: shots can ricochet off the sides of the screen, bouncing back into play.

Style: Neon space theme, bright colors on a dark background.

Target Audience: Anyone who enjoys classic arcade action, but with a new spin.

I’m hoping the ricochet mechanic will force players to think about their shots and create some chaotic, funny moments. Can’t wait to see what happens in playtesting!

[arhamh]

Week 4 Post 4

This week I focused on refining my “Skybound” platformer prototype based on early feedback and some ideas I got from reading other blogs. I started by tweaking the platform layout to make the early parts of the level more forgiving—my first design was way too hard right at the start! Now, there’s more room to plan jumps before platforms disappear.

What I Did:

Adjusted platform spacing and added a “safe zone” at the start so new players don’t fall instantly.

Added a collectible star object (finally got it working!) that disappears when touched, just to see how adding rewards feels.

Invited a friend to playtest my level for the first time. It was actually hilarious—he kept missing the last platform, but his feedback helped me spot some frustrating sections I hadn’t noticed myself.

Reflection: Watching someone else play my game really changed my perspective. Fullerton (2018, Ch. 2) talks about the importance of playtesting and learning from the player’s experience, not just your own. My friend pointed out that the visuals made it obvious which platforms were “safe” and which ones would fall, which was reassuring. Next, I want to try designing a second level that introduces disappearing platforms more gradually. I’m also going to try using more sound effects and maybe a simple background track to make things feel more complete.

[arhamh]

Week 3 Post 3

This week was a designated catchup week because of the cyclone, so we didn’t have any scheduled workshops or new game development tasks. I used this time to revisit my “Skybound” prototype and review feedback from peers and the Week 2 workshop.

What I Did:

Rewatched some GDevelop tutorials to reinforce my understanding of events and conditions.

Checked out other students’ blogs for inspiration—some of the level designs and visual styles gave me ideas for how I could make my own game more interesting.

Made small tweaks to my own prototype, like adjusting platform distances and experimenting with a collectible star (though it’s not quite working yet).

Reflection: Even without a formal class, it was helpful to step back and think about how far I’ve come with GDevelop in just a couple of weeks. I also realised how valuable it is to document my progress, not just for marking but for tracking my own learning and ideas. Reading Fullerton (2018) reminded me that iteration and feedback are ongoing, and every break is a chance to improve something, even if it’s minor.

[arhamh]

Week 2 Post 2

Elevator Pitch: “Skybound”

This week in class, I started working on my platformer project called Skybound using GDevelop. My concept is a 2D platformer set in the clouds, where the player has to keep moving forward—every time you jump, the platform you leave disappears behind you. The goal is to make players plan their moves and never stand still, adding a sense of urgency.

Genre: Platformer

Mechanic: Platforms vanish after jumping off them

Visuals: Simple and bright, sky background, floating green platforms

Target Audience: Anyone who likes platformers, especially people looking for a bit of challenge

What I Did in GDevelop

This was my first time using GDevelop. It’s a lot more approachable than I thought—making the player sprite jump felt satisfying! Setting up the disappearing platforms took some experimenting with events. At first, I kept accidentally deleting every platform on the screen, but after tweaking the conditions (and checking the workshop files), I figured out how to target just the last platform the player left.

I added a few clouds in the background for atmosphere and tweaked the jump height to make it feel better to play. Next, I want to work on level design so the first level feels fair, not punishing.

Reflection

Reading Fullerton (2018, Ch. 1) and looking at examples from other students, I realised how important it is to keep things simple and test ideas quickly. Playtesting—even if it’s just me right now—helps spot what’s fun and what’s just frustrating.

[arhamh]

Week 1 Post 1

Hello World

Im Arham Hussain, and welcome to my IGB120 Game Dev Journal! I am a Bachelor of IT student who is passionate about games, design, and new tech. My goal in this unit is to learn more about practical game design, teamwork, and how games can go from concept to playable prototype. I’m especially interested in how feedback and iteration improve ideas, and I hope to build confidence in pitching and evaluating my own game concepts.

Outside of uni, I love playing games on my ps5 (especially online multiplayer games such as Siege,The Finals, and Fortnite). I’m looking forward to working with GDevelop and learning from both my peers and the industry perspectives in this unit.