Huu Duc Huy (Charlie) Bui

Student ID: n11680679 Currently a student in Bachelor of Games and Interactive Environment (Game Design major) at QUT (2nd year) Blog for the unit of IGB120 - Introduction to Game Design

[itxhuyyhere]

Introduction

Hi everyone, Charlie's here ^^

Apologise for my late update, i forgot my Tumblr password and tried to get it for the whole March.

I have a big passionate in game design concepts, especially interested in ways game designers imagine and create their own concepts base on realistic things usually happen in daily life. I hope in the future I can inspire my story life and possibly convey lessons, knowledge and various practical life experiences that I have experienced, and convey them through my game projects.

Thanks for reading! I will update more soon. Have a good one!

[itxhuyyhere]

Chapter 1 & 2 of the book of Game Design Workshop - Overall reflection throughout the semester

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:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[itxhuyyhere]

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.

Below are some screenshots of our mutually-agreed upon game setup which are much cleaner, more modular, and so much easier to manage!

[itxhuyyhere]

Week 9 - Assignment 2 OnePage and OneSheet

This week I transitioned from pitch documentation, to initial gameplay prototyping with my game, For Independence - Freedom - Happiness. Following the creation of my pitch, and visuals (my poster and onesheet), I moved on to design and prototype gameplay systems in GDevelop 5. My aim, was to create a 2D platformer gameplay experience, that is hopeful, respectful and emotional, based on an historical event - the Fall of Saigon.

Refined Elevator Pitch

A short 2D platformer, represents the events of April 30, 1975 the day of the reunification of Vietnam. The player, as a lone soldier, is navigating through bombs, ruined cities, and dead comrades on their quest to the independence palace to raise the flag of reunification. The aim of the game is to place emotive tone versus excitement and action. The gameplay provides themes of sacrifice, unity and memory.

Core gameplay:

Move and jump (← → + Space)

Avoid collapses and bombs

HP (health points): (100 max; lose 10 per hit)

Player raises the flag (the end), triggers a historical epilogue

Gameplay Development Progress

Using GDevelop 5, I created the first draft of the games interactive systems:

HP System: a health bar which decreases -10 per collision with a bomb. If health = 0, the player is dead. I built it using global variables, triggers for damage, and a custom UI bar.

Bomb Drop System: bombs are spawned at intervals from the top of the screen at random x coordinates, and continuously fall. Each bomb explosion is triggered by collision with the ground OR player. I experimented with using timers on the objects as I altered velocity to build tension.

Platforming Level Design: The game is comprised of several, short sections (acts), each act is a distinct journey:

jungle → Shawn ruins → Saigon outskirts → independence checkpoint

Each of these segments/acts, provide different obstacle and navigation hazards, including traversable and blockable damages ground, flame hazards, and walls that impose the player to either jump over or push through.

Narrative-integrated Obstacles: In stage 2, While ruined buildings made it tricky: Ruined buildings didn't exist just to occupy space, but as movement flow. My hope was to convey part of the player experience, with the placement of the environment. In that is how the player imagines the emotional weight of the destruction below and all around them.

Iterative Refinement & Challenges

The first round of playtesting provided a few considerations:

Stage 2 was too difficult, the spawn-rate of the bombs was too difficult that the player really didn't have act/react. I slowed down the bomb drop timer, randomized spawn zones, but still allowed a challenge, but way to have a little leeway for success and failure.

Realization of Lack of clarity in the ending: the flag-raised ending just faded to black. I am in the process of developing a voice-over epilogue while I am also going to add a camera pan to the soldiers raised flag shot for a sense of emotional closure.

Missing polish: I will be adding explosion sounds and a more thorough feedback system (flashing screen, vbration) to amplify the key points in the game.

I am also hoping to add a 'collapse', into the animation for the Independence Palace, as a visual representation to conclude the soldiers journey - symbolic victory.

[itxhuyyhere]

Week 10 - Assignment 3 Process - Group 19

In week 11, my job as a gameplay programmer sort of came into focus because we were progressing forward with the level 1 miniboss fight. While most of the team focused on developing the visual, narrative, and even some game design, I remained focused on developing the mechanics to create a challenging and readable encounter for the player. I was ultimately working to make combat feel responsive, fair, and in line with the pacing and stakes in the game.

The main challenge of the week was tuning the skeleton AI and combat logic for the miniboss. In early play testing the miniboss was spamming attacks in an unmanageable way, abruptly increasing difficulty for the player with no corresponding degree of player skill. The hitboxes did not match the animation whatsoever, which didn't contribute to clear damage-on-hit messages and made it unclear to the player what they were expected to do. Using Fullerton's (2018) principles related to meaningful choice and player feedback, I redesigned the miniboss to have clearly telegraphed attack patterns that have cooldown windows and wind-up animations (both in animation and design) to allow players more time to react.

I also rewrote how melee hitboxes are handled altogether, timing them, as closely as possible, with the frames in animation to provide a responsive feel with predictable input. This alone addressed a large body of negative feedback in playtest sessions and resulted in a more fluid combat loop.

Along with improving the feel and adjusting the polish from the feedback we received, I also added subtle mechanics to give players some tools in terms of countering the boss attack. For instance, providing several frames of invincibility immediately after taking damage allowed a player to not be stunned continuously, and improved recovery animations helped re-establish player agency in and around combat. While these observations might seem like game bugs to address, they focused on the player overcoming skill-based challenges in lieu of randomization or luck.

Full ownership over the miniboss logic, AI, etc allowed me to actively explore how player emotion is intricately related to gameplay systems. Even seemingly benign bugs in timing or movement can result in unexpected player frustration, or lack of intent. However, after many iterations, I feel I am getting closer to a fight that rewards strategic positioning, timing, and acceptable levels of risk—all values we wanted our protagonist to confront on their journey.

Reference:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[itxhuyyhere]

Week 12 - Assignment 3 Iteration and Changes

Taking into consideration feedback from the playtesters and Fullerton (2018), we made some big changes to implemented in the next build.

Core Fixes:

Synchronization of Melee Animation: Players felt as through their attacks were visually incorrect or not hitting at all. We will be arranging our hitboxes this time, in time with the timing of their animations, visually confirming the hits.

Boss Behaviour: The miniboss currently has attacks that are spammable, and ultimately, no way to prepare or reasonably predict the attacks. In this build, we will implement a wind-up delay and a cooldown system between attacks, making it more readable and fair; Fullerton refers to this as clarity of interaction.

Player Feedback: There was no visual effect to indicate players taking damage. Next we intend to add a red flash to the character, in addition to a sound effect, to make hits distinguishable.

New Features (Planned):

Spell Casting System: Spells were visible in the players HUD that players controlled, and in this build were not usable. The next build will advance options for alternative playstyle by incorporating mana-based ranged attacks.

Intro Scene / Tutorial: Players were lost after being dropped in for the boss battle, mid-fight. We will create a simple training area before entering the boss level that will orient players on movement and attack.

Enemy Variation: Currently, the level has only one type of enemy. We are trying to add smaller enemies or traps - just to lay a framework for variance, and make the level feel a little less static prior to the minisboss fight.

These changes will make the game feel more fair, rewarding the player in a much more understandable manner. Hopefully these surprises at the end will give us more test data as to whether the players preferred melee or ranged builds under time pressure.

[itxhuyyhere]

Asteroids Post Mortem

The Asteroids Tutorial asked me to implement new control schemes and add shooting, all while also handling object spawning randomly and what I considered Minecraft "gameflow". To be honest, this was the first time I used mouse angle rotation and manual bullet spawning inside of GDevelop- which forced me to consider the timing of events and the location of objects differently.

A core success was getting the ship rotation and shooting to feel immediate and responsive. One of the key points Fullerton (2018) notes is a responsive control/input style leads players to immerse in a game easier. The other important change, was creating a point where the cannon was and syncing bullet spawning with that point. After I created the bullets to actually come from the ship's nose (instead of the top-left corner) it felt like Asteroids.

That said, I was having difficulty balancing the enemy and who was doing the spawning. In the beginning, asteroids were spawning too quickly and sometimes right on top of you. I used timers and added random distance so they were not colliding directly on spawn, and it also introduced me to debugging complex event chains. I also added a basic health and lives system, so I had a functional loss condition and Game Over screen. I ran out of time and wasn't able to implement win states, different types of asteroids, or a scoring system.

One of the bigger takeaways I developed was iterating on player punishments. My original perception was that as the player, dying by an asteroid felt unwarranted. They had no time to react. After testing it out, I added delay and random playing distances to give them space, which was another reflection of Fullerton's "games must be fair and winnable" and game like Minecraft is not linear.

If I was to try this project again, I would create a level progress system, maybe increase the asteroid speed as the game progressed, add sound, scoring, and combination bonuses for skilled shots. Even though this was a guided tutorial, it felt good to start to "own" some design decisions.

Reference:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[itxhuyyhere]

Week 11 - Assignment 3 Playtesting

After we put together the first prototype of For the Princess, we ran our official playtests. The current build had a singular floor where a player must defeat a skeleton miniboss using melee combat and complete the goal before the countdown timer runs out. So our aim was to test if this boss-centered gameplay felt fair, fun, and intense.

We followed Fullerton’s (2018) suggestion to try for player-led tests - users play without help while we observe. One important takeaway is that players enjoyed the tension, especially with the ticking countdown timer. However, there were hit detection issues and untelegraphed attacks that left the fight feeling frustrating occasionally. One player said "I kept slashing but I didn't feel like I hit anything," which played into our worry that our melee animation was not perfectly synced with the hitbox logic.

Another tester reported confusion for not having an intro/tutorial. They were essentially just dropped into the fight with no controls or goals and started spamming buttons. As Fullerton points out onboarding is an important element of usability. So it is safe to say we will need an early-game prompt or tutorial scene that teaches players controls before they get thrown into the gauntlet.

All of that being said, players seemed to like the miniboss design, and the spell ui and especially the sense of pressure. The skeletal boss animations helped make the scene feel "alive," and people were curious about spells that were not yet implemented.

Reference:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[itxhuyyhere]

Week 13 - Assignment 3 Post-Mortem Reflection

After creating our first prototype of For the Queen we have had our official playtests. The current build contained a single floor in which players needed to defeat a skeleton miniboss using melee combat in order to beat a time countdown and test if the boss focused play was fair, fun and frantic.

We took Fullerton's (2018) suggestion of conducting user-centric tests and allowed users to play as normal while we observed them, without any assistance. One key insight was that players enjoyed the tension, especially with the timer counting down, although a couple of players had issues with hit detection and didn't have enough cues to signal when they were being attacked which made the fight felt bit frustrating. One player said, "I kept slashing and it didn't feel like I was hitting anything" which matched our concern about having the melee animation not closely tie into the hitbox logic.

In addition, another player felt confused that there was no intro/tutorial where they were just dropped into the fight without knowing the controls or the objective of the game. As Fullerton (2018) mentions onboarding is an important aspect of usability. Clearly, we need an early game prompt or tutorial scene that teaches controls before presenting players with the real challenge.

Aside from the bugs, players liked the miniboss design, spell UI, and sense of pressure. Players also indicated that the skeletal boss animations made the scene feel a bit more "alive" and were interested in spells that had not yet been implemented.

Reference:

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[itxhuyyhere]

Week 6 + 7 Content - Racer Playtesting

So far I have nearly complete the content of Racer in GDevelop 5. I also updated into a new racing car called Rainbow Race - Great Hard Great Price, which is clearly in updating stage.

Key main factor:

Top-Down Car Control + The car uses the TopDownMovement behavior with custom rotation and speed for smooth directional control.

Traffic Spawning System + Enemy cars (Blue, Grey, Pink, Green) are spawned every 3.5 seconds using random lane variables and a timer.

Dynamic Scrolling Environment +Trees and other objects scroll vertically to simulate forward movement, using constant Y-axis force.

Components need to be finished: I am still trying to pinpoint the exact coordinates of the trees shown in the game, and finding a way to make the movement of the cars smoother, and I need to remove the background behind the highway. On the other hand, i need to put more opponents present for various colour, including yellow and orange.

Thanks for reading and feel free to give feedbacks here. I would love to hear that!