In-Game^2
Click here or the image below to travel to the game's download portal
.png)
In-Game^2 (read: In-game squared) is a 3D platformer made in Unity that I completed working on in April 2020. This was an old project that I decided to revisit using the game design and programming experience I had gathered in the time between now and my last attempt (Fall 2016).
I revised the level layout, did a relative overhaul of the mechanics (especially the portals) to make, and a TON of playtesting. The end result was a project I am very proud of creating.
The story of the game is that you play as a designer who was working on his level until you (the player) pressed the "Play" button. This caused him to get sucked into the level that he was making and now you need to guide him to the end so that he can return to his reality and continue working.
I had a lot of fun coming up with the level design for a blockmesh level that had "bugs" and "loopholes" in it (example, the path to progress is clear but the obstacles are horribly balanced making it near impossible... so the player has to find a more "cheaty" way around it using the game's mechanics requiring a bit of lateral thinking).
I also decided to have voice acting in the game so the designer can communicate to the player about the things he's happy with in his level and comment on the player's "cheaty" ways. The latter was especially important so that the players recognize that the game isn't actually full of loopholes... it's designed that way.
Directing the voice talent (Michael Babcock) was something I'd never done before and being able to convey what I wanted from the lines was a challenge because I quickly realized that even though I may have a version of the line in my head... I should trust the voice actor and let there be some fluidity so that the lines come out more naturally and not robotic.
Once the game was in a playable state, I immediately started playtesting with a wide variety of people and I found a lot of level readability issues, control scheme unintuitiveness, and a couple actual bugs.
I am really happy with how this game came out. It really was the most ambitious project I had worked on. Not only did I learn a lot during development, it also helped me realize how much I had learned in the years before I picked it up again.
Design Breakdown
1) Designing a puzzle with a "loophole" solution
a) the first iteration
Since the premise of the game is that it is a level under development, there had to be puzzles that could be solved via a "loophole" that the designer hadn't found yet. This was one of those puzzles.
My thinking was that there'd be an intended solution to the puzzle (seen in the video) but there'd also be a second method (via backtracking) to solve it.
In the video from an early build, you can see that the solution is pretty straightforward, throw a portal across and then wall run into the other. However, whenever anyone did the backtracking method (seen in the video below), they said that they found a bug. When I told them it was intended, the feedback was that it felt cheap.
b) the release version
In the final game, there is only one solution - the backtracking one.
When the player enters this area, the character makes note that the area is incomplete and that there might be no solution.
The player can throw a portal on the opposite wall but there's nowhere else in this room to throw the second portal that the player can enter through.
This forces the player to backtrack, instantly seeing a white surface they can place a portal on and thus, figuring out the solution.
When they solve the puzzle, the character comments on that validating their solution and adding to the fantasy of, "This is a level in development."
Upon further playtests, players found this to be a great puzzle as opposed to thinking it was lazy design that they broke
2) How to get the player to look up
a) the first iteration
In this section, the goal was to teach the player how to use the portals and the aim was for the player to get to the other side and then use a combination of wall running, jumping, and portals to get into the opening above.
There were two main issues with this -
a) it was not clear to the players that the main path continued upwards simply because they just didn't look up
b) Even when they realized what they had to do, combining all three mechanics (the third of which they just learned) was too much
This led to a frustrating experience.
b) the release version
I realized that the main purpose of this section was to familiarize the player with portals. So, using the three mechanics in combination was not the way to do so. Making the section easier was okay here.
This made me add the black blocks which formed a stair like structure. This gave me two benefits -
a) It guided the player's eyes to the path above
b) The player could easily use portals to climb upwards without having to rely on other mechanics reinforcing the controls of the mechanic
This led to a better section which didn't include the frustration of the prior iteration
3) Get the player to go around the obstacles instead of through them
Goal:
Have the player go around the obstacle in front of them by wall jumping instead of through the obstacle
Design Decisions:
a) The sides are in wall jump distance and the player enters this area by wall jumping in so the mechanic is fresh in their mind
b) It is quickly apparent that going through the obstacle course is nearly impossible and most players didn't even attempt to
c) There is a coin near the ceiling and there is also a light on the far end that moves upwards signalling to the player that maybe going upwards is the way
d) Voice line is present when the player goes around to validate that that was the intended solution
Playtest Observations:
a) Most players quickly got that they had to circumvent the obstacle course and were glad to hear the voiceline because it validated their actions.
b) For players who did not, they realized it after dying a couple times, going up to collect the coin, and seeing that they are above all the obstacles
UI Breakdown
1) Hint Text
The hint text displays whenever a player enters an invisible region and removes as soon as the player leaves. It's placed to the left so that it's not intrusive but also catches the player's eye when it comes on screen
2) Wall Run Timer
The timer is placed a little above the center. It starts depleting as the player starts wall running to show how much longer they will be allowed to wall run.
The player isn't taught that that's the wall run timer but after running playtests, all players knew what that UI component did. When the player first wall runs, they notice the bar deplete (since it is in the center) and connect the dots on what it is.
The player character also starts to drop near the end of the run so it's intuitive in letting the player know that they don't have too long before they completely drop off
3) Portal Reticle
A portal spawns where the reticle is aimed. The reticle's left side is red and the right is blue to let the player know which mouse click corresponds to which colour.
4) Fall To Death Timer
Similar to the Wall Run Timer where this one starts depleting as soon as the player is in air but not touching a surface.
5) Coin Counter
Counter that goes up by one for every coin you collect in the level