2.5D Action Puzzle Game
Inside a secret laboratory, scientists are conducting some unspeakable experiments on their humanoid robots. An explosion caused by an accident has freed one of the robots, who gained consciousness and seeks to escape.
On the way out there are traps, obstacles, and enemies. You can help the robot plan ahead by placing down Command Blocks, which will trigger specific actions to potentially clear the path.
Will you change the robot’s fate?
INSPIRATION & CONCPET
Conceptualizing
The idea of an action puzzle game comes from my love of challenging action game franchises like Dark Souls, in which you need to learn enemies’ attack patterns and dodge them to avoid taking damage. For those who shy away from the genre, one main reason they often bring up is that they can’t react to enemy attacks in time.
In Dark Souls III, player rolls toward the right to avoid the incoming axe-swing attack from the boss
While part of that might be true, the game often gives the player ample time to react, by making enemies’ attack wind-up obvious. Combined with players’ anticipation and knowledge about how to counter certain moves, the game can feel challenging but also beatable at the same time.
Targeting players with those concerns but still want to take on a game with Souls-Like difficulty, I decided to come up with an action game in which you have unlimited time to make your decisions so that no reacting is required. Even though doing that might take away part of the fun of Souls-Like games, I still wanted to give my idea an opportunity.
Following this train of thought, I did some research to find references. One of the games that fit in my definition of an “action puzzle game” was FRAMED, a multi-award winning puzzle game in which the player can change how the story progresses by rearranging or even rotating the facing direction of the panels.
The player makes it so that the protagonist (top-left) won’t be seen by the guards
Prototype
The first prototype of Neo can be dated back to 2021 when I made a Demo game called Auto Knight as the final project for one of my game design classes at UCI, which touched upon some of the ideas I mentioned earlier. The knight will perform the according action after colliding with the Action Blocks The player makes progress in the game by solving each level consisting of different enemies and traps. Once the knight starts moving, she won’t stop until she reaches the next level (the door at the right) or is killed. The player has a limited number and types of Action Blocks (Attack, Jump, Dash, etc.) to use and may pause or restart a level at any time to reposition the action blocks.
In Auto Knight, the player takes on the role of a knight venturing through a castle with the goal of defeating the demon lord. However, instead of directly controlling the knight like in other games, the player needs to make use of “Action Blocks” by strategically placing them down at the correct position. The Knight only has 1 HP and will die instantly if gets hit by an attack.
While part of that might be true, the game often gives the player ample time to react, by making enemies’ attack wind-up obvious. Combined with players’ anticipation and knowledge about how to counter certain moves, the game can feel challenging but also beatable at the same time.
Taking inspiration from both games, I wanted to create a level-based puzzle game that incorporates actions such as attacking, jumping, shielding, and dashing. The player needs to plan ahead about what actions they want to perform in order to defeat the enemies, which takes trial and error.
The knight will perform the according action after colliding with the Action Blocks
Level Design Process
1. Teach the player the function of each Action block
(EX: Attack, Jump, Dash, etc.)
2. Help the player familiarize themself with the mechanics/properties of each Action block
(EX: when performing an attack, the player briefly stands still for 0.5 seconds)
3. Teach the player to place their Action blocks smartly
(EX: you don’t have to use an Attack block every time you see a monster)
Lessons Learned
While I had a fun time playtesting Auto Knight with classmates and friends, I started to see the limitations of applying my design concept to a 2D platformer.
Around the same time, I also made an Excel sheet to brainstorm more levels, enemies, and traps, with the mind of turning the demo into a more polished game. One apparent issue I start to realize is that the player is restricted to the 2D space, with their movements limited to one straight line, above, and below in some levels. This not only makes the process of solving the puzzle boring as players quickly run out of options but also adds difficulty in designing more complex levels in the future.
Breaking down one of the levels in Auto Knight
Another idea I tried to explore is to allow players to create new skills by combining existing actions, which can increase the complexity and make the game more challenging. However, the deeper I dig into the mechanics and combinations, the harder it is to come up with new levels due to the restriction of the 2D space.
Start Over - A New Angle
Despite how bad it felt to discard almost all the level designs, I believe it’s necessary to approach my concept in a different way instead of a 2D platformer. What I was looking for is a level template that gives both the player and the designer more space to work with, while keeping the core system of placing down Action Blocks to control the character. When I was looking for references that fit my criteria, a game caught my attention.
In each level of Arknights, the player can deploy troops in a rectangular space divided into grids. From the reference above we can see that some grids have different heights to differentiate between high and low ground. Not only applying the grid approach to my concept will add a new dimension and thus more space to work with, but I really like how Arknights illustrates the grids by using shadows to make them look more 3D-ish.
After making up my mind that this is the direction I am going for, I gathered a team made of a level designer, artist, and programmer (myself). We have a month to make the game in Unity in order to submit it to a long-term game jam. The good news is that I already got the concept down and communicated with my teammates to make sure we were on the same page. The rest is to figure out the theme, the levels, and how to achieve them programming-wise.
The top-down view in Arknights
THEME & ART
To fit the gameplay that the player is not in direct control of the character, we decided to make him a humanoid robot, who gained consciousness in an experiment and seeks to escape from the laboratory. The name “Neo” is a reference to the protagonist of The Matrix (1999), who also awakens from the virtual world. In our game, Neo can run, turn, dash, shield, and attack (once he obtains the weapon) to get past various traps, obstacles, and enemies. After taking into consideration the time limit and our scope, we decided to make the gameplay 3D but the story in pixelated comic form to save time.
Draft —————————————————————> Final
DEVELOPMENT PROCESS
Work Flowchart
The chart above shows the milestones we reached in each category. We also often take over some of each other’s jobs. For example, besides coding, I made multiple adjustments to the level design draft after plenty of discussions and playtesting, as well as implementing all the art assets, music, and sound effects into the game, since my teammates are less familiar with using Unity.
Player GameObject
The player GameObject is in charge of controlling Neo’s movement and triggering actions when colliding with any Command Blocks. It contains multiple different colliders that detect different objects (obstacles, enemies, Command Blocks, etc.)
A script called “Player Actions” is also attached to the player GameObject, which keeps track of attributes such as speed, I-Frame, moving direction, and animations, and contains methods for performing all the actions.
Tile Groups & Tile Commands
To make creating levels and making changes easier in the later stage of the project, I made the tile into prefabs that can be changed to Command Blocks, Traps, Destructables, or Walls.
Each tile has its own collider that can trigger interactions with the player. For example, the Command Blocks are attached to the “TileCommands” script that stores the action type and which direction the action will be performed towards, which will then be passed to the according action methods in the “Player Action” script. Other tile types like Trap, Destructible, and Wall which stop players from advancing, are also child objects that can be easily activated/deactivated in the Hierarchy.
Tile Commands - Melee Attack Command Detection
Player Actions - Player Melee Attack Method
Check if the player death animation is playing, if not, play the Attacking animation.
Disable the start/reset button when this action is performed.
Activate the attack hitbox and play sound effects.
Wait for the animation to end and then disable the hitbox.
Switch the player back to running mode rotate facing direction, and enable the start/reset button.
Tile Groups & Tile Commands
Since the game is made with the goal of playing on the mobile platform, It’s crucial to pass visual cues about the current state of the level and where the Command Blocks are placed. The picture above is what players see after choosing the action “Turn.” The available tile that’s not occupied glows white, while the tiles that are already assigned with actions glow their respective color (Turn = Yellow, Dash = Green, Shield = Blue, etc.) The tile that the player is hovering over will also show a half-transparent icon of the action as well as change the color of the tile so the player knows exactly which tile the action will be placed on.
Picking up the idea that I left behind, having upgraded actions that can be created by combining the basic actions not only adds depth to the gameplay but also gives players room for self-expression. For example, the player can try deflecting enemies’ bullets instead of shielding/dashing through them or attacking them across the room with a Ranged Attack which can hit enemies in two blocks in the front. The combined actions also glow differently so that the player can notice they’re already upgraded to avoid confusion.
The player’s touch position is accessed by the “Tile Adjust Control” script to check if its anchoredPosition lands on any of the color cue objects, which are stored in their own parent object group in “TileManager”.
The code on the right is part of the “Tile Manager” script that checks and determines if a command block can be upgraded based on whether they have an existing command assigned to it. In this case, the code checks if the target tile is already a Shield Action (S) and is applied with Dash (D), if yes it will then become Super Dash (SD)
Trap & Destructable
After placing down an Action, the player may tap it again to pop up the adjust panel, which has a delete button and a changing facing direction button.
There are two types of enemies in the game, melee and ranged. Melee enemies have a Box Collider in the front that triggers an attack when the player passes by, while ranged enemies use Raycast to check if the player has appeared in a straight line and shoot out lasers.
Since each action costs energy (represented by the lightning icon), depending on the scenario, the player doesn’t always have to fight the enemies but should choose an approach that’s more energy efficient. To teach the player this point, we add a variant version of the regular melee enemy, a red one that has very high attack speed and should be avoided as much as possible.
We deliberately hide this information from the player so that they need to figure it out themselves, which not only adds difficulties to the game but also makes the player feel more rewarded when they solve the puzzle in their own ways.
One of the ideas we tried to explore was to have higher ground that the player can access. In the level above, the player can use the portals to teleport between the first and the second floor. While this is an interesting approach to level design and might open up new possibilities, we didn’t have enough time to design more levels that utilize this mechanic.
Extra Content
Another element we tried to implement was to add robot friends that the player can try to save using extra actions. Based on how many robots you saved, a secret ending can be unlocked, which can encourage the player to challenge themselves to find the most optimal strategy to beat each level. However, we ran out of time and couldn’t add it to the game. While there is still a robot in the last level (the one in the orange cage), saving them won’t change the ending.
END NOTE
Neo is probably one of the projects that I devote the most time in. Despite how tiring the process was, seeing my 2-year-old concept evolve into how it looks right now is something very satisfying. In the process, I also got more practice in programming, as well as became more efficient at coordinating with teammates by maintaining close communication, especially when all three of us were in different time zones. Although we don’t have a future plan to update the game, I do want to keep polishing the concept and maybe take it to another level in the future, when I become more skilled in level design and programming.
