#Assignment3

[ydrhxx-gamedev]

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.

[adisbec]

Week 11 - Assignment 3 Playtesting

This past week our team conducted a round of playtesting for Magbi-tism to gather feedback and identify areas where we could improve the player experience. Overall, the playtests were extremely valuable and they helped us better understand how players were interacting with the game and where adjustments were needed to strengthen both the gameplay and presentation.

We had eight players test the game, each providing individual feedback across a range of categories including:

Audio

Controls

Puzzles

Gameplay

Game World

Visuals

My Character

Level Design

Hazards

Here are some of the biggest takeaways from our playtest session:

The quantity of levels was seen as too low (tagged as Urgent priority). Players wanted more content to explore, which highlighted the need to expand our level set, we’ll be adding up to three new levels moving forward.

Some of the platforming puzzles lacked challenge (High priority). We plan to condense the first two levels and increase the kinetic fidelity and complexity of the platforming in subsequent levels to create a more engaging experience.

Audio balancing was flagged as an issue where several players felt that the sound effects were too loud, especially during level transitions. We’ll be softening these volumes and improving the overall audio balance.

The absence of background music and lower art quality were noted as areas to improve. We’re planning to implement updated assets and add a background track to enhance the atmosphere of the game.

The game currently lacks hazards and a sense of endangerment. Players suggested adding enemies, varied environmental hazards, and even a countdown timer mechanic to add urgency. We’re excited to explore these ideas to expand the gameplay.

There is an opportunity to introduce power-ups to diversify gameplay and give players more problem solving options.

Some feedback also indicated that movement felt unintuitive for players unfamiliar with PC games. We’ll be adding an arrow key control scheme.

[romans120blog]

Assignment 3 – Bit Crash Postmortem

{Week 13}

As development on Bit Crash wraps up, I wanted to reflect on the full process: what worked, what didn’t, and how far the game has come from concept to final submission. Creating a full arcade-style experience in GDevelop pushed my systems thinking, UI design, and debugging skills in ways that felt both challenging and rewarding.

What Worked?

From the start, our goal was clear: build a glitch-themed arcade shooter that feels fast, chaotic, and replayable. The asteroid destruction, knockback mechanic, and respawning hazards created a gameplay rhythm that kept players moving and thinking on their feet. Watching testers dodge enemies, upgrade mid-run, and chase scores was proof the design loop landed. The XP-based upgrade system added real replay value. Players could invest in fire rate or health, making each run feel slightly different. This tied perfectly into the arcade feel we were aiming for and gave players short-term goals. Bit Crash had a visual identity that clicked. The CRT overlays, VHS distortion, glitch FX, and chiptune audio helped sell the simulation-gone-wrong vibe.

What Didn’t Work?

While the DataFragments were effective hazards, they didn’t evolve much over time. In a longer development cycle, I’d introduce enemy types with different behaviors; some that shoot, others that orbit the player, etc. That variety would help the game scale in complexity and keep the player learning. The game was too easy. Enemies didn’t spawn fast enough to pressure the player, and bullets were slow. Through playtesting, we increased difficulty and fixed pacing; but it reminded me how important regular feedback is.

What I Learned

Playcentric Design Works: Getting feedback early helped shape the final product more than any single mechanic I added. As Fullerton says, “You aren’t designing unless you’re testing.”

Modular Logic is Powerful: Breaking up systems (enemy respawn timers, score tracking, upgrades) into small parts helped me debug and iterate faster.

Polish Comes Last, But Matters: Little touches like sound cues, UI transitions, and knockback had an outsized impact on the feel of the game.

Bit Crash started as a weird glitch-core spin on Asteroids, and turned into one of the most complete games I’ve made to date. I’m proud of what the team produced and what I contributed. If I had more time, I’d expand the progression and enemy types, maybe even explore online leaderboards or an endless survival mode.

Let me know what you thought! E: roman.rosson@connect.qut.edu.au

[estallion]

Assignment 3 Postmortem

After completing most of our playtesting document for assignment 3 I now have the time to reflect on the development and playtesting process.

What Went Well

Prototype: We successfully developed our playable prototype and made several key iterations to improve the design and enjoyment of the game.

Playtesting: We followed a structured and consistent playtesting process which allowed us to gather valid insights from various naïve players.

Team Coordination: We successfully worked collaboratively on tasks in order to complete each stage of the assignment efficiently.

Challenges

Time Constraints: The Balance between prototype development and playtesting was a considerable hurdle as not all play testers were available when needed. This made it clear that scheduling in the future should take priority.

Data Interpretation: While all feedback was valuable interpreting subjective responses was difficult and meant carefully considering which core changes should be made to the future game.

Overall, this project highlighted the importance of both iteration in game design and user feedback. These insights will be useful for future prototypes such as refining Cosmos Custodian or new creative designs.

[practice1developingskills]

Assignment3-Nostalgia and Memory-3

After picking the characters, I started thinking of all kinds of things that happened to me when I was a kid. I made a list of the four things I remembered most and wanted to put them into a Keyframe.

When I was little, I wanted to perm my hair, but my hairdresser made me look like a poodle.

When I was little, I couldn't win an argument with my sister, so I bit him on the arm.

It was very hot in Taiwan, so I would sit in front of an electric fan and open my mouth when I was little.

When I was young, I hated a specific cartoon character, so I used a red crayon to draw a fork on the TV.

My biggest challenge in drawing these keyframes was recalling scenes from my memories, much like how Turning Red resonated with its audience.

One reason why Turning Red connects so well is that viewers can easily recognize objects or scenes from the characters’ lives that mirror their own childhoods. I aimed to achieve a similar effect by collecting photos resembling my memories. However, I feel the results still leave plenty of room for improvement.

For the drawings, I aimed for a more comic book-style approach. This included making sound effects larger to better convey the characters' emotions. Additionally, I thickened the character outlines to enhance the comic book aesthetic.

Despite these efforts, I’m unsatisfied with how these keyframes turned out. I plan to revisit and refine them in the future.

[pinkeshf]

week 11: Playtesting

On 16/05/2024 we did our first playtesting

The player selected the left square and began driving it. The player may easily go left and right, drive a car using the arrow keys, and travel around the cars.The player was hit by a high-speed car in the far-right lane, losing one life point. The player reacted to the accident by attempting to avoid, but smashed into an incoming automobile on the left, with life points incorrectly removed. The player collided three times, losing one life point. The player was travelling in the far-right lane and was hit by a high-speed vehicle; she just crashed her car and as she hit the automobile, she could see it exploding, and the game was ended. And in the first attempt, she clicks the right button and exits the game.

And on her second attempt, she realises that there is a timer in the game that is counting down, and she notices that she has one minute and nothing in time, and she notices that some cars are going fast and some cars are going slow, and the player was driving in the left lane before moving back to the far-right lane, colliding with vehicles twice and losing two life points. The gamer kept moving left and right, colliding with automobiles. The player successfully evaded a high-speed car, but then realised that all vehicles in the right lane were also high-speed. When they tried to return to the left lane, they collided with another car in the lane, exhausting all life points. And it ends the game.

[ln-mrbean]

Assignment 3 Postmortem

Overall player experience immersion through the integral of programming, design and the use of sound effects/ background music. With any production of a game, playtesting is important as it provides necessary biases from potential future game consumers of any genre of games. Specifically for team 27, without the playtesting sessions and further playtesting conducted outside of those times the team would be slow to implement the necessary changes to make 'Asteroid Escape' a fun, exciting and complete game. With any game constant gameplay and time permitted can always be improved like for our game we can add more different sounds into the game for player inclusion and response, adding in other potential mechanics like for example more powerups like shields. Furthermore this assessment adds importance in the power of group work because simply one cannot juggle the workload within the approximate 2 months of game development.

[cjk-uni]

Submission & GG

And that's it for IGB220! I really enjoyed giving my design muscles a flex and implementing them in GDevelop. I found the lecture content to be really stimulating and enjoyed the theory of game design as it was presented in the content. Shout out to Chris for all of his help in the Thursday tutorials and cheers for the good unit.

GG!

[ayeon0307]

Prototype Final

20th October Fri

Context and Action

The worst has come to the worst. As I mentioned in week 9, the final prototype product is still on shipping. Therefore, I had to make a decision. The elements that are currently lacking are the acrylic magnets and acrylic clips, which were made using acrylic. For this reason, I decided to work similarly in the design fab lab, cutting the acrylic and colouring it myself.

Laser cutting: 3/5 - Creating the laser cutting file took less time since I had previously created the size and design, but the laser cutting required a lot of time, and the colouring after the laser cutting required extra work.

-> Laser cutting files and new design print files

-> The process of laser cutting and the final product of laser cutting

It was very mentally exhausting, and I had to work hard every day. I tried different ways to create the package details, especially for the new acrylic size. I considered using paper, felt, boxes and cork. I experienced more than 10 failures in this process.

Nevertheless, in the end, I was able to complete the final prototype in time. The use of cork created a sense of unity throughout, and the precise laser-cutting technology allowed me to produce a higher-quality final prototype.

-> Final prototype high-quality photo shots

Result

In conclusion, I am satisfied. I am also grateful to the people around me who helped me mentally and physically because this week's efforts resulted in a final prototype that I am satisfied with. In particular, I was able to complete the final prototype within Week 12 so that I could focus on other documentation schedules.

I have learnt from this experience how to deal with emergencies and the importance of having a BACK-UP PLAN. I have learnt that even though I have considered enough time to complete the project, I need to have a 2nd plan in the future in case something unexpected happens due to external issues like this situation.

Learning

This situation was an important lesson and education for me. However, if I were to work on a similar project, I would challenge my original plan again. I will plan a new back-up plan as I proceed with my original plan so that I can complete the perfect project on time. In addition, I will change the way I plan my backup plan to plan ahead when there may be external influences to avoid a similar experience next time. I will also consider the worst-case scenario every time and consider and analyse as many different directions as I can plan for myself.

[ydrhxx-gamedev]

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.

[adisbec]

Week 10 - Assignment 3 Development and Group Formation

Our team, Ctrl + Alt + Elite, is now fully formed and we’ve started collaborating well, consisting of Charlie, Phelix, Ryan, Pavani and I. One of the first things we did was set up a Discord server with dedicated channels which has already made it much easier to coordinate tasks and share ideas in real time.

The most important milestone so far is that we’ve completed Part A of the assignment. This outlines our game concept, team roles, and our planned playtest timeline.

Our game, Magbi-tism, is a puzzle platformer based around the concept of magnetism, with a twist: the player character can’t jump. Instead, players will need to rely on magnetic forces to move through the environment and solve puzzles, aiming to reach a goalpost represented by a battery at the end of each level.

As a team, we’ve defined our minimum viable product:

Basic player movement

Core magnetism-based puzzle mechanics

A clear goalpost mechanic for each level

Once these key components are working, we’ll look to expand the gameplay experience with moving platforms, a stamina bar, and more advanced puzzle elements.

In addition to completing Part A, we’ve also started very roughly sketching out some level designs to give us an early sense of how the game might flow. While these initial sketches are very rough, they’ve already helped spark some great discussion about level pacing and player experience.

We also have a well-structured playtest timeline, with key dates and clear roles assigned for testing each major feature, this will help ensure we’re getting frequent feedback and iterating on the core gameplay loop.

Overall, I’m really happy with our progress so far. The team has gelled well, communication is strong, and we’ve got a clear plan to guide us through the coming weeks.

[romans120blog]

Assignment 3 – Bit Crash Playtesting

{Week 11}

This week we conducted our first round of structured playtesting for Bit Crash, gathering direct feedback through surveys and observation. Our goal was to evaluate core mechanics like movement, shooting, and enemy behavior, while also identifying any usability issues or balance concerns before final polish.

Testers & Demographics

We had two participants:

Alex – Regular arcade/puzzle player, 20+ hours of gaming per week

Jamie – Action RPG / roguelike fan, 25+ hours of gaming per week

Both fit our core audience: experienced players who enjoy reflex-based and score-driven arcade games.

Key Findings

Controls & Gameplay Both testers agreed the controls were intuitive and the game was easy to pick up. Shooting, movement, and feedback were all clear. However, Alex suggested increasing bullet speed to improve responsiveness.

“I felt like I was sometimes faster than my bullets. Faster projectiles would make the combat more snappy.”

Challenge Balance Neither player found the game frustratingly difficult or boringly easy — a good sign for current balance. Jamie did mention that more enemies would add to the intensity:

“There weren’t enough enemies for it to feel like a real challenge yet. I’d like to see a denser wave pattern.”

Visuals & Feedback Visual style and atmosphere were well received. CRT effects, sound design, and UI were all praised for reinforcing the glitch-core aesthetic. Players ranked visuals and audio as top aspects.

Replayability & Progression Both players said they would play the game again and were curious to see how the upgrade system evolves. This validates our decision to make upgrades a mid-run mechanic for replay value.

What We’ll Improve Next

🔺 Increase bullet speed slightly for better combat flow

🔁 Increase enemy spawn rate to create more tension

⚠️ Consider adding a “warning” flash or indicator for respawning DataFragments

📈 Explore scaling enemy difficulty over time or based on score

Playtest Report Progress

We’ve now compiled our results into the official Playtesting Report and are planning a second round of testing next week to validate our changes.

Let me know what you think! E: roman.rosson@connect.qut.edu.au

[estallion]

Week 12: Assignment 3 Iteration and Changes

Over the course of our development for Assignment 3 we have made several iterations upon our game project. In order to maximize the enjoyment of the game at this stage we have focused on key areas. For instance, we have increased the difficulty by adding enemy attacks on wave 3 and above while remaining aware that the difficulty naturally increases each progressive wave. Furthermore, to improve the overall artistic design and appeal of the game we have changed the key sprite models and background of the game. Furthermore, we have modified the projects animations notably the player ship thus adding to the polish of the final build.

[practice1developingskills]

Assignment3-Nostalgia and Memory-2

After checking out all kinds of artwork, I'm taking on the challenge of cartoonizing my childhood self again! First, I had to find pictures of myself when I was little. Luckily, I was able to find some pictures of my childhood after asking my grandma!

After looking at my childhood photos, I came up with a few features that I wanted to express:

single eyelid and small eyes

small eyes with single eyelids

wearing glasses

short hair

chubby

big feet

After that, I tried to draw according to these five characteristics, but maybe because I already had a cartoonized image of me as a child in my mind, I didn't try too much at the silhouette stage and just started drawing the details!

I was initially puzzled by how to depict single eyelids and small eyes, which are defining features of my youth. I wanted to reflect the lively and mischievous personality I had back then, avoiding a look that felt cold or introverted. So, I experimented with various approaches to drawing single eyelids and small eyes, aiming to capture that playful energy.

After focusing on the shape of the eyes, I discussed the design with my teacher. The teacher pointed out that the overall character shape looked confusing and suggested a valuable method to improve consistency: organizing the silhouettes of the character's parts.

The suggestion involved tracing the outline of large character parts and rearranging them to check how well they fit together. I decided to try it out, and it worked like a charm!

I particularly liked this method because:

It allowed me to quickly identify which body parts affected the character's overall look.

I could pinpoint proportions that needed adjustment to create a more cohesive design.

This approach has been a game-changer in ensuring the character feels visually consistent and expressive.

This is the final version of the character after incorporating the teacher's feedback.

By adjusting the shapes of the large blocks, the character now looks more coordinated and has a better sense of rhythm in the lines of the frame.

Once the character's appearance was finalized, I began working on emotional expressions that I remembered from my childhood. Drawing emotional expressions for a character was particularly challenging because it required maintaining the character's appearance while capturing the essence of each specific emotion.

After studying various reference images and doing plenty of practice, I finally got the hang of drawing those childhood emotional expressions!

Reference

Inkcross (2014) 034: A Mexican Story. Available at: https://inkcross.com/2014/08/25/034-a-mexican-story/ (Accessed: [4 January 2025]).

Pinterest (n.d.) Image reference. Available at: https://www.pinterest.com/pin/12384967717643330/ (Accessed: [4 January 2025]).

Behance (n.d.) Short animation film: A Jeju Story - Sohyun Childhood. Available at: https://www.behance.net/gallery/200210341/Short-animation-film-A-Jeju-Story-sohyun-childhood (Accessed: [4 January 2025]).

Pinterest (n.d.) Image reference. Available at: https://uk.pinterest.com/pin/969540626024592179/ (Accessed: [4 January 2025]).

Ninjago Wiki (n.d.) User comment and reference. Available at: https://ninjago.fandom.com/f/p/4400000000000052278/r/4400000000000167381 (Accessed: [4 January 2025]).

Tumblr (n.d.) Image reference. Available at: https://66.media.tumblr.com/4225a7a94c9ef2e9c248a4f4faf1e605/tumblr_o60t3zLNi61qhdiu5o5_1280.jpg (Accessed: [4 January 2025]).

Pinterest (n.d.) Image reference. Available at: https://uk.pinterest.com/pin/766949011567053107/ (Accessed: [4 January 2025]).

[pinkeshf]

Week 10: Assignment 3

One Page and One Sheet of our chosen assignment 3 prototype project (Turbo Thrills).

[ln-mrbean]

Assignment 3 Playtesting Pt 2

Playtesting Summary Continued

Regarding bugs, our first round of playtesting yielded the following list of bugs/quality of life issues:

Fleet Health being 0 doesn’t -> Game Over

The boss asteroid doesn’t kill the fleet.

There is no max fire rate and it gets silly quickly.

Missiles re-lock after each mission.

Some players didn’t know the unlock button for missiles was an unlock button

Some players managed to leave the map

The UI takes up too much space, try replace text with icons.

This led to us forming a list of what we had to work on before our next round of playtesting. During which, I managed to add some of the music/sounds, where Harry and Connor worked on bug fixes and general game balance/difficulty scaling together. Connor was also responsible for adding in more upgrades and the enemy ship mechanic.  Harry also added a Controls screen and fixed the UI to improve the games overall clarity.

Using the scoring system discussed above, our second and final round of playtesting yielded a score of 76.6%. This shows an improvement in the game and is reflected in our playtesting results.

Regarding our demographic, it became apparent that the more experienced gamers found the game to be less engaging or challenging than playtesters who were less experienced at playing games. This was to be expected and we didn’t think it was too noteworthy.

Secondly, there appeared to be no difference between how both categories of playtester (again, experienced and non-experienced) perceived our game in regards to how fun it was to play and how easy the controls were. Counterintuitively,  it seemed that the less experienced playtesters found the controls easier than the experienced playtesters, though this could be resulting from an insufficient sample size as there were significantly fewer playtesters with limited gaming experience. Similarly, there appeared to be no discernable difference in how both camps perceived our original prototype’s lack of game sound/music, which I suppose shows how music caters to everybody, regardless of their demographic.

To conclude, it is hard to find any results that indicate a discernible correlation between the players reaction to the game and their level of gaming  experience. This is most likely due to the extremely limited data in terms of both diversity and sample size.  We think this might be because our game isn’t suited to either style of player.  Early on, Harry envisioned Asteroid Escape as a casual arcade-style game, which can be enjoyed by anybody of any age or interest, as opposed to having made a shooter/RPG (which was one of the most hated genres that came up in our questionnaire). It is possible that with a larger sample size, a noticeable difference in results between the two camps might emerge.

Regarding our second round of playtesting, there was significantly less negative feedback, and the majority of negative feedback reported in round 1 had been fixed. The negative feedback that remained was as follows:

The game was a lot more difficult

The controls could do with tweaking

Some might find the gameplay loop too repetitive.