#igb120

Time to actually produce the second GDevelop game. I've learned a few lessons after the last attempt that I want to apply to this one:

1) Reduce scope

The biggest problem that plagued my attempt at creating a platformer was the large scope, trying to incorporate environmental storytelling into a hand-built word. This was not an achievable level of quality in the time allocated for the task, and deviated away from the seeds of gameplay I identified in my first post on ChronoKnight. For this reason, Astro Annihilation will focus on moment to moment gameplay instead of complex level design, and will use things such as enemy spawn tables and duplicated assets to reduce the development time. This relates to the IGB120 Week 5 Lecture on understanding the possibilities and limitations of GDevelop, especially the advice of finding a simple scope that is easy to iterate on.

2) Playtest earlier and more

It will be important for Astro Annihilation to be playtested more than ChronoKnight, especially in the early phases. The reduced scope of the game will aid with this, as having a smaller amount of work for each gameplay moment will allow more to be produced before a reasonable timeframe for playtesting arrives.

3) Take on a more iterative approach

Further on this point, Astro Annihilation would benefit from a more iterative approach - things such as enemies and movement are easier to tweak and adjust than a hard-coded level design, meaning more action can be taken on player feedback.

In the prototype of my Racer game, I'm crafting an engaging experience that blends simplicity with addictiveness, demanding fast thinking and decisive actions from players. Here's an Elevator Pitch outlining all the key aspects of my Racer Game prototype:

Name of Game:

Dash 'n Dodge

Description of Game:

Dash n' Dodge is an exciting top-down racing game where players take control of a speedy car on a mission to zoom ahead while avoiding obstacles. The goal? Race as far as you can while grabbing coins and speed boosters to push your limits and score big!

Genre of Game:

Survival/Racing

Target Audience:

Ages 7+

Mechanics of Game:

Boost: "Space" key

Movement: Arrow keys

Settings of the Game:

In the world of Dash n' Dodge, you're racing along the endless highway, dodging traffic and grabbing power-ups to speed ahead and rack up your score.

Elevator Pitch:

In Dash n' Dodge, you'll navigate an endless highway filled with oncoming traffic, a renowned racers' proving ground for speed demons. How far can you push your limits? How high can you climb the leaderboard? It's a test of skill as you aim for the ultimate glory!

Concept and Reference:

This game draws inspiration from popular mobile titles like "Subway Surfers" and "Temple Run," where players aim to outlast their previous best by running as far as they can on the course provided.

Subway Surfers

Source: https://www.pinterest.com.au/pin/797559415272934153/

Temple Run

Source: https://playtemplerun2online.wordpress.com/2014/08/04/feel-double-thrill-adventure-with-play-temple-run-2-online/

Conclusion:

Last one.

Working on Bloodrush has been uniquely insightful to me as a developer and as a member of a team. I was surprised how closely our team dynamic matched the structure that Fullerton describes in chapter 12 of "Game Design Workshop," where a natural leader emerged among us, despite us making the decision not to designate one. I think the teamwork really is the takeaway from this project for me, the insights gained into how team dynamics form have, I feel, equipped me well to join, work within, and potentially lead teams for other tasks.

If there was to be something that we could work on in that regard it would be task allocation. Tasks often fell to whoever thought of an idea first, which while reducing miscommunications about concepts also delayed development where people would be working on tasks which they were, myself included, less suited for. Despite that, having the structure we did for tasking was immensely helpful. While every part of the design was absolutely collaborative, the tasking allowed us to focus at least somewhat on our areas of interest/expertise, and group moral was significantly impacted because of this - I believe this also increased our effectiveness, and I think these are the kinds of things that IGB120 aims to teach us. Speaking of IGB120, this is it.

The subject has, to me, been immensely helpful in understanding exactly what an actual gamedev environment looks like, and it has reinforced my belief that this is what I want to do.

I'd like to thank Chris K and David C for their engaging and helpful teaching, as well as Riley, Jia, and Tommy for an awesome time making Bloodrush.

I want to continue this blog, but if my Duolingo streaks are anything to go off that may be a false hope.

Regardless of whether I return to this: So long, and thanks for all the fish.

Platformer:

Classic arcade horizontal run'n'gun similar to Metal Slug, Cup Head, etc. It would have set stages (assuming I get that far into development).

Bouncy ball platformer where you can only roll, or "slingshot" yourself but you will continue bouncing after you hit the ground/wall.

Racing:

Racing on the Z-axis similar to Subway Surfer, AB Cop, Outrun, etc. - Sprite based with the player staying in the center while the environment moves toward the camera or left/right for turning.

Combine with a shooter. Possibly a Spy Car race with various classic gadgets (oil slick, machine gun headlights, etc. Could also be based loosely on Wacky Races (1968) by Hanna-Barbera.

Chariot racing including weapons. The rules should be based on the Wikipedia page for chariot racing.

A puzzle racer where you place the road/obstacles down in order to get the fastest time through a number of pre-placed checkpoints (see: trackmania puzzle events). Alternatively, being able to draw the road like Mini Motorways could be another interesting way of doing it but harder to balance.

Asteroids:

Physics based movement (side thrusters + main thruster)

Resource management/ rogue-like where you decide what systems to focus on keeping online while letting others fail so that you can survive until a rescue team can arrive. - Letting things fail may provide other benefits, and repairing/improving other systems may create new problems (i.e. Adding additional shielding my slow your ship down making it harder to dodge, letting life support fail will give you an oxygen resource bar you need to keep up by breaking icy asteroids otherwise you'll faint/die.

Terran Defenders was inspired by key ideas from Tracy Fullerton’s Game Design Workshop, particularly Chapters 2, 3, and 8. These readings helped us develop a strong core mechanic and refine our design through iteration and feedback. Chapter 3 teaches player motivation and feedback loops beyond just functionality, which was crucial for our combat-driven gameplay. We focused on creating a feeling of being overwhelmed but still capable in enemy encounters. Chapter 8’s iterative cycle guided our multiple rounds of testing and refinement.

One thing I would change while developing the prototype is how we interpreted early playtesting feedback and that more serious discussions should of been had to identify the root of player frustration. In hindsight, we misdiagnosed a major usability issue, believing feedback about hit detection and weapon feel was a matter of sound or visual effects. However, in later testing (especially from Users 6, 7, and 8), it became clear that the real issue was player control and movement. Our reliance on click-to-move made moment-to-moment combat feel unresponsive to several testers. Suppose we had more critically applied Fullerton’s idea of playcentric design, building and refining the experience based on real user needs. In that case, we might have transitioned to WASD controls much earlier, which could have reshaped how players engaged with combat entirely. A larger emphasis should have been put on the Core audience.

The design of Terran Defenders was mostly well recieved. Inspired by Chapter 2 of Game Design Workshop, we focused on how the player would feel (constantly under pressure but still able). This influenced choices like making enemies aggressive, especially Cthulhu, who forces the player to stay mobile. Also the visuals which were widely appreciated and widely acknowledged to affect the player experience.

To start up the semester, I went to read Chapters 1 and 2 of Game Design Workshop by Tracy Fullerton (2018). It truly helped put much of what I’ve been working on in the prototype into context. At the beginning of Week 1, playcentric approach was just a catchy term. Now it feels like a tangible process I’ve been going through each week of development. And overall these 2 chapters did help me a lot in helping me the orientation of thinking and mindset in creating a game, especially in real-life gaming industry.

Chapter 1 introduces the notion that games are best designed with the player in mind from beginning to end. The designer has the job of creating experiences, not systems or rules. That was starting to click for me as we were in the playtesting phase and trying to fix bugs for our boss fights, when I realized that early on I was more concerned with mechanics working than making sure what we created was actually fun to play. Playtesting has shown me that the difference between “that was okay” and “that felt good” can sometimes come down to something as small as the responsiveness of our sprites, or an important feedback sound.

Chapter 2 unpacks what a game is, and identifies the component formal and dramatic elements of a game: goals, rules, procedures, player interaction and challenges. After reviewing our own game - For the Queen - I can see how our goals have become clearer (defeat the boss, survive), rules have been refined (HP, chests, timers) and player interaction has increased through intended UI elements such as health bars and casting.

Both of these chapters reaffirmed that iteratively designing, from listen, test, adjust, is crucial, with the player always at the centre. It is not just about creating a game that is working, but rather a game that feels good to play.

It is a great honor to have an opportunity to read an really essential book for my journey becoming a game designer in the future. Thank you to the tutors of IGB120 have given such a great book!

Reference:

Week 8 - Updating status about my original project: For Independence - Freedom - Happiness

This week I did a major overhaul of our game project setup. Up until this week, my project had mostly served as proof of concept, just getting it to work. But this week I really focused on structuring and refining our GDevelop project to ensure smoother development going forward.

I had a fair bit of time cleaning up the event sheets and re-organising scenes so we could properly expand the game. This included separating floors to their own scenes, fixed a couple of minor animation bugs with the miniboss (it would freeze mid attack), and cleaned up the asset folders. I also restructured the way I was handling timers and HP to ensure they supported persisting or resetting correctly when switching levels. It was a bit of a grind, but it was totally worth it, as you can really see how much easier and readable the project is now.

The text by Fullerton (2018) stated that prototypes rely on feedback and iterations to evolve, and I really felt this week to acknowledge that. Our original prototype set up was not scalable, but now it feels like a more substantial base to grow from into the next phase. It is one of those things you don’t really see in the outcomes, but it allows everything else to be possible.

And just like that, the semester is over, and the final version of Crimson Reckoning is complete.

Our team, PaperFrame Studios, combined four distinct skill sets to create a dark fantasy platformer influenced by Soulslike games. We spent the last few weeks designing wave-based combat, creating enemy AI, balancing player mobility, implementing perks, and even adding a full boss battle. It's been tough, challenging, and incredibly rewarding.

Throughout the project, my primary responsibilities were mechanics and narrative integration. I helped develop player mobility, collaborated closely with George on combat systems, and contributed to worldbuilding and narrative, all of which helped form the game's dismal tone. I also assisted in playtesting sessions and helped apply suggestions to improve clarity and tempo.

Looking back, our greatest success was our ability to respond to playtester input. Each session showed difficulties we hadn't considered: unfair adversary spawning, ambiguous UI, and small attack windows. We didn't see this feedback as criticism; instead, we regarded it as motivation to iterate. As Fullerton explains in Game Design Workshop, building games is constantly chasing delight through iterative playtesting and improvement cycles. During that process, our game genuinely evolved.

One of the final important changes was to improve the boss fight with Dwayne the Golem. Originally, it lacked visual feedback and attack cues, but after some tweaking, it now feels like a fitting challenge with weight, pattern recognition, and potential for player creativity. We also improved the perk system, provided audio cues, and ensured that dying didn't seem like a failure, it was simply part of the process.

If we had more time, we'd look at a comprehensive progression system, several venues, and advanced combat systems such as parrying or special attacks. Still, I'm proud of what we managed to create in such a short period of time: a responsive, evocative, and challenging prototype. It taught me not just how to create a game, but also how to operate as part of a team with changing objectives.

Overall, I've learnt that game development requires iteration, communication, and clarity. The best ideas do not necessarily come from a single individual; rather, they develop when everyone participates, tests, and adapts. I've also discovered that even with simple tools like GDevelop, you can express a great deal of creativity if your systems are focused and well-defined.