Rogue Malfunction
What Is Rogue Malfunction
Rogue Malfunction is an isometric puzzle adventure about a robot trying to escape the Overlord. In some levels, the Overlord changes the controls to make the escape harder.
The game has four puzzle levels built around remapped controls, parkour, moving boxes, pressure plates, and route-finding.
I came up with the control-remapping idea because I wanted the Going Rogue game jam theme to affect the gameplay, not just the story.
Project Details
- Role
- Programmer and Game Designer
- Team
- Four people
- Development
- 5 days
- Engine
- Unity 6
- Language
- C#
- Status
- Released
What I worked on
Programming and UI
- Built the control-remapping manager
- Built the timed door-puzzle system
- Adapted the player controller for the Sequencer level
- Added moving obstacles and falling hazards
- Built the main menu, level-selection screen, settings, credits, pause menu, and controls page
- Added volume controls and saved volume settings
Game design
- Created the control-remapping and Overlord concept
- Designed the Sequencer level
- Designed the three timed door puzzles
- Designed the parkour route
- Revised the level three times after playtesting
- Added the Extremely Hard label after players found the level harder than expected
The artist created the UI artwork. I integrated it into Unity and built the menus, navigation, and functionality.
How the four levels differ
The final build has four puzzle levels. I created Sequencer. Other developers created The 3 B's, Sokoban, and Tiles.
- Sequencer uses timed door puzzles, control changes, parkour, moving obstacles, and falling hazards.
- The 3 B's uses movable objects, buttons, doors, and control inversions.
- Sokoban asks the player to move boxes onto four pressure plates.
- Tiles asks the player to cross 25 tiles without stepping on the same tile twice. Repeating a tile resets the puzzle and returns the player to the checkpoint.
Robot character
An artist created and rigged the robot model after the game jam. We had trouble getting the animations and player controller working together, so we used the robot as a non-playable character in the Sequencer and Tiles scenes instead of delaying the release again.
Why we split the player controller
We began with one player controller that all three programmers would use. Since we were building different levels at the same time, that meant multiple people would be editing the same script.
We made separate copies of the controller so each programmer could work on their own level without constant merge conflicts. It worked for the game jam, but it also left the project with duplicate movement code across several scripts.
Control remapping in Sequencer
I built the Sequencer level around three timed door puzzles. Each door gives the player a WASD sequence to enter before the timer runs out.
The first door swaps W and S. The second swaps A and D. By the final door, both swaps are active.
Three timed door puzzles
I built a control manager that tracks what each movement key currently does. Before moving the robot, the player controller checks that manager for the active mapping.
I also built the door system, including the sequence prompt, timer, input feedback, failure state, control change, and exit.
Each door uses a fixed control change rather than a random one. For Sequencer, I updated the controller to read the current key mapping while keeping smoothed movement, full air control, grounded jumping, wall anti-stick logic, and input locking while a door puzzle is open.
- Door 1Three inputsThree seconds
- Door 2Six inputsFive seconds
- Door 3Nine inputsEight seconds
Adjusting Sequencer after playtesting
Playtesters found the Sequencer level too difficult. I changed the parkour route three times and moved several jumping sections closer together.
I still wanted Sequencer to be the hardest level, so I added an Extremely Hard label to the level-selection screen. Players could see what they were getting into before entering.
Playtesting also exposed progression bugs and edge cases that we fixed after the game jam. During that work, I completed the remaining menus and improved navigation between them.
Results
Rogue Malfunction is available in the browser and as Windows and Linux downloads. After the game jam, we combined the four levels into one release and fixed issues found during post-jam testing.
What I would change
Player controller setup
Separate controllers solved a short-term game jam problem, but I would not structure the system that way again. It left the project with the same movement code in several scripts.
If I rebuilt the game, I would keep one player controller for physics, jumping, and interaction. A separate system would handle control remapping, while each level would define the control setup it needs.
GitHub workflow
I would set up main, development, and feature branches from the start. I would also define ownership for shared scripts, scenes, and prefabs so multiple people are not changing the same files.
Connecting the levels
Each developer built their level mostly on their own, so the four levels feel separate. If I rebuilt the game, I would plan the full level order and story before production.
I would also use the environments to show more about the robot, the Overlord, and why the robot is trying to escape.
Play Rogue Malfunction
Play in a browser or download the Windows and Linux versions through itch.io.