Bro, Can you Work?!
Developed by: Harvey Yeo, Evan Puah, Sean Ng, Aidan Hunter, Cameron Bowes,
Wokring (alias), Dan Tran-Cong
Project Roles: Game Designer, Level Designer, Music Direction assistance, Sound sourcing
Bro, Can You Work?!
The theme of the game jam was "Broken". To meet this mechanic, our game is a 2D platformer controlled by an in-game arcade machine.
The arcade machine game is filled with "Jank", depicting a game with mechanics that functions inconsistently. The player can encounter glitches and titled platforms within the arcade game and will have to use real world objects and hit the machine to overcome those obstacles.
The game title is a word play on "broken" while capturing the frustration of using a machine that malfunctions from time to time.
This game was made in 1 week during the QUT Game Development Club 2026 Winter Game Jam. It also won the people's choice awards, with a score rating of 4.5.
Details of contributions
With experience from all my university projects, I was able to put together documentation detailing the mechanics after the group discussed the direction and general mechanics of the game. This document was referred to repeatedly throughout development.
As the mechanics were being implemented by the programmers, I created a spreadsheet to track our sound assets and set up a sound infrastructure for our UI programmer to refer to later.
After the Mechanics were completed, I shifted to creating prefabs and eventually level design, playing and testing the mechanics to find the right feeling for Level 2.
Towards the last few days of development, I coordinated with programmers and edited their scripts to add and change some game mechanics that would contribute to a better player experience.
Development Process
Although this was my First game jam, my experience during my University Projects gave me and my team members a good understanding of scope. After assessing our team availability and skill set, we decided on a platformer with unique mechanics.
Theme - "Broken"
Working around the theme of "broken" meant a lot of possibilities. It could be a broken object, breaking something, broken in the sense of being unbalanced and many more. In our case, we ended up deciding to work with having to deal with a broken, malfunctioning object. The idea was to have the player operate an arcade machine game that is broken and riddled with bugs.
We decided to have 3 broken interactions and developed it further, these base ideas were:
-
The arcade machine could be tilted, affecting gravity in the game. The player could hammer the arcade machine to change the orientation of the arcade and affecting gravity.
-
Glitches would appear in the arcade game. The player could bat the arcade machine to change the glitch locations. Touching the glitch will kill the player character.
-
The player could jump really high after hitting a big red button and performing a jump.
The entire game including the real world and the arcade world is ran within one 3D scene. The platformer was 2D and was inside the arcade world, shown through another camera and projected on the "monitor" of the arcade cabinet model. It was a pseudo-inception having players play an arcade game within a game.
Documentation
Ideas were documented on google docs, and were used as a reference for programmers when implementing the stated mechanics. For ease of reference, I phrased the mechanic details short and to the point, while highlighting keywords in bold or placing them in bullet points or tables for clarity.
Throughout the early implementation, I made myself highly available to liaise with programmers to clarify on how I want the mechanic to work. If there were any confusions or if the mechanic didn't feel good in practice, I updated the document after discussing a change.
Music resource spreadsheet
As mechanics were being implemented by the programmers, I began to source the sound effects and Music we would use in our game. As the first step, I created a spreadsheet listing all the Sound Effects that we might need and they would be also used as a reference for attribution later.
I sourced all the sound and music on multiple royalty free websites looking for 2 categories of sounds. The first category was practical sound effects for the Real World, and the second was 8/16 bit sound effects to match the theme our Arcade World.
I sourced multiple variants of sound effects for the mechanic it was related to, and narrowing down to one for implementation after A/B Testing with some group members. Due to the wide applications of sound I decided to source, such as the "player yelling when swinging an object" to add layers of immersion to our sound. In the end after testing, it felt like there was no correct timing for those sounds, and as a result some SFX were omitted.
We initially wanted to have the level structure and visuals similar to 'Water boy and Fire Girl', but after testing the implemented mechanics of a player-following camera and our artist made Arcade Cabinet model's screen space would make that kind of level structure feel awkward.
In addition to assessing our general availability, I opted to change our level structure to a left to right structure like 'Super Mario'.
Testing the Mechanics (before level design)
As mechanics were being implemented by the programmers, I was tested them by setting up test environments with those implemented objects. Through testing, I was able to catch a few bugs, liaise with programmers to confirm the bug and continue with testing.
The platforms were originally sticky and restricted gravity design
Testing Gravity at an obscure angle
The platforms were originally sticky and restricted gravity design
One of the issues we struggled in the beginning was the clunky feeling that the platformer physics gave. I tested repeatedly such as adjusting the tilt angle values to make it 'feel right' but to no avail. I followed by reaching out to the rest of the group to affirm this issue.
After this was brought to the programmer team's attention, they were able to resolve the issue by the end of the day. Fortunately, my previous testing of the gravity values were able to be used following the "fix", This process would save us time as us game designers only had to design around the designated value.
Level asset creation
Our artist produced 2D sprite sheets for our the tiles in our level. These sprites would be used for the platforms traversed by the player character in the arcade world. Based on the structure of our game, there were 2 possible ways the game could have been implemented.
-
Use the Unity tile map function to paint the levels after the platform structures were put in their respective locations
-
Place 2d sprites as children of the 3D platform and save the object as a prefab
=
Due to time constraints, option 2 was the more efficient choice as Sean, the other level designer did not have much availability. I created several sets of prefabs including platforms of various sizes, and also created prefabs for moving platforms and tilted platforms. As a result, these prefabs allowed us to create our level quickly and leave some time for testing and polishing.
I was also responsible for attaching and implementing our other art assets into their respective game objects.
Platform prefabs
Comparison of the options. Option 1 (right), Option 2 (left)
Platform prefabs
Creating the level
We determined that we would be creating 3 levels for this game jam. Each level will follow the following structure:
-
Level 1 will be a basic platformer with no special mechanics
-
Level 2 will introduce the arcade cabinet mechanics at an isolated instance
-
Level 3 will be a test to players combining arcade cabinet mechanics
I was in charge of designing level 2, I designed the level to make sections achievable by placing checkpoints slightly before a new mechanic is taught. I also placed real world space text as the tutorial to guide players past those obstacles. In practice and watching others play the level, level 2 had the best player friendly experience and was the least frustrating. However, the final sections presented trouble to a few players.
The final version of the level
Prototype of level2
The final version of the level
Platform tilt
Originally, to walk on the tilted platform, the player had to tilt the arcade machine in the same orientation as the platform. Testing with this, we discovered that the player could not see things in the level clearly due to angle of the camera after the tilt. Hence to resolve this, the rule was inverted and the player had to tilt the arcade machine in the opposite orientation.
Midway through the week, the tilting mechanic was slightly bugged and did not feel right, even after rigorous testing. As the more experienced programmers were fixing it. As at the platform and gravity interactions were incomplete at the time, I suggested if we could not find the right "feel" we could always adjust it to the machine periodically tilting and the player having to hammer it to return it to the normal orientation.
Tilting the gravity through hitting the machine
Tilting the gravity through hitting the machine
Placing the glitches
Glitches were originally "an area of space" that the platformer player character can walk through, ignoring walls. After changing the level structure to a left to right structure, we shifted the purpose of glitches from more of a puzzle to more of a challenge. Glitches became a killzone that will kill the player character upon contact.
Since the glitches alternate between locations after hitting the arcade machine with a bat, I placed the glitches in level 2 as obstacles. They are placed in very safe and obvious places to minimise repeated failure as the goal was to teach them the mechanics of the glitches.
Glitches blocking the player's path
Changing location after the arcade machine is hit
Glitches blocking the player's path
As we were designing the levels, I implemented a few basic features such as adding vertical movement option to moving platforms and changing sprite colour for flag checkpoints as indication of reaching that checkpoint
Reflection
This was my first game jam and I was satisfied with the product we were able to make with the given time constraints. By being on discord calls as we were working, I found that it was convenient to clarify with programmers on "how" I intended certain mechanics listed in the Design Doc to be implemented. After discussion with them and gathering my thoughts I was also able to create a clearer description of the section. I would consider both my documentation and communication skills improved and can perform these at a higher level given the next opportunity.
Due to the time limitations, the levels could not be rigorously tested and eventually we felt we unintentionally created a platformer meant to induce rage (rage game), due to the frustrating inconsistent checkpoints. By committing to the rage game shtick, the clunkiness acted as a 'double-down' on the theme of 'broken' as it poses as a poorly put together arcade machine.
Another issue was a few background text in the level used to guide players were also not updated and displayed irrelevant text. This resulted in a slight confusion when people tested our game during the closing ceremony, fortunately, the issue did not result in a roadblock and did not hold the players back.
Overall, this experience the game jam brought was extremely valuable and displayed the importance of the benefits of SCRUM Cycles and long-term development, as these Sprints will be able to detect and correct issues that would hinder the player's experience.