Han-yang-on-a-minute Liu (Frank's Journey Through Time)

A dynamic platformer game where time manipulation is used to help your past self. You can’t go back in time to change your actions, but the God of Time is here to assist.

Comment 2

Inspiration

When brainstorming possible options for our game, we wanted to emphasize the power of time and the power of the choices that we make. We knew, from the beginning, that we wanted to include the power for our main character to help their past self. This is one of the key themes within life that everyone grapples with: regret. Our game gives us an opportunity to explore regret in a fun and controllable manner.

What it does

The game follows Han-yang-a-minute Liu (Frank Liu), an unfortunate traveler, who isn’t able to see. Since he cannot see, he jumps at random in hopes of making it back to his homeland. However, the God of Time gives him the ability to go back in time and change the world to suit the jumps that he made. He can add things like blocks and jump pads. However, these changes cost time, and Frank wants to make it home as quick as possible. Only by using his resources efficiently can he make it home to his family in a reasonable time.

How we built it

After finishing brainstorming ideas for the design of our game, we started the process of developing the game. First, our team developed a template for a simple platform game. Then, we used this template and made appropriate changes, such as forcing the character to move at a constant speed (removing the user’s ability to control left and right movement). Then, we focused on the aspects of our game that makes our game unique, such as the beginning section where we log the amount of jumps the user does and the ability for the user to change the map based on their previous movements. We then added the special items, such as jump pads (of various strengths), time capsules, blocks, and more, that all cost extra time to add. Throughout this process, we used both Claude AI and ChatGPT to assist with the development of our game.

Challenges we ran into

We ran into challenges with collision detection with blocks and spikes in our project. In some of our previous iterations, the main character “Frank” often got stuck in blocks or even phased through them when he moved to a different y-level while jumping or falling. We fixed this challenge by improving our collision detection such that Frank stops moving forward when it is intersecting with a block from the side. Another challenge we faced was with players “spamming” the jump button at the start of the game. This created an environment that removed some elements of strategy from the initial planning part of the game. We dealt with this challenge by implementing upper bounds and cost restrictions on parts of the game such as the number of jumps and “time costs” of blocks and jump pads.

Another challenge was that players did not understand what the spacebar presses at the beginning were for. They would either hold down the spacebar or not press anything. We added the time bar at the top that displayed the spaces, so the users could better visualize what their actions were for.

Accomplishments that we're proud of

We’re proud of the complexity of the platformer and the unique way time is used within our game. We successfully managed to create a platformer that integrates blocks, jump pads, and preexisting jump patterns to create an environment where the player is offered different challenges every playthrough. We managed to use time as a currency and playtest the game to get accurate values of seconds for each element of the game. Another part we are proud of is our incorporation of the theme, “It’s about time.” We approached the idea of “time” from a very unique perspective of reconciling with regret. We’re also proud of the graphics we used within the project. Although most of the graphics were generated by Claude, we successfully managed to integrate these graphics within a preexisting backend.

What we learned

We learned that a platformer requires checking collisions for the blocks and spikes in cases. For the blocks, we had to deal with different ways of handling whether the player intersected the block from the bottom, the left, or on the top. We learned that we can get accurate collisions by changing the jumping and falling parameters of the player; for example, intersection of the block from the bottom causes the player to lose its jumping speed and immediately fall, thus simulating an accurate collision. We also learned that creating a game that loops to different “types” of gameplay (either running through a simulation or placing blocks and jump pads) requires different “game states.” These “game states” are accessed through different calls to a Javascript function, which then switches the HTML to a different game state with its own iteration loop.

What's next for Han-yang-a-minute Liu

While playtesting our game, one of the issues was that blocks were really cheap. It is easy to spam blocks over all the spikes, and this would prevent the user from running into any difficulties at very little cost. One possible fix would be to make the cost of blocks and the other items exponential. That way, the game becomes much more strategy focused.

Along with this, we could add different difficulty levels to make the game more dynamic and interesting. Harder difficulties would randomly generate more spikes and make the jumps and gaps wider.

We could also add more unique items like portals to give more traversal options.

Finally, it would be fun to make the game multiplayer, where two players can play the same randomly generated map and see which player is more efficient with their time.

Built With

Share this project:

Updates