My favorite project that I've worked on thus far is another 2D Unity game. I would contend the execution of the game is far more intricate than any of my other projects. It was the first time I really faced coding challenges that I couldn't solve with a Google search. The needs of the game were so specific that the code had to be of my own design; there weren't any libraries or packages that could have offered what I needed. I'm sure I'm not the first one to have problems like the ones I faced, but for what I created, finding anything useful probably would have taken longer than actually solving the problem.
The game was originally called "Cutesy Dimensional Drifter", but that was inspired by the artwork, much like many other characteristics of the game, including player equipment, enemy behavior, and sound effects. The title screen offers several options for the player to jump into a level, leave the game, or change the settings of the game.
The above snapshot shows the game in the Unity editor. The window in the top-left reveals the entirety of a level in the game. It may look strange that there are certain overlayed enemies and objects, as well as red and green tiles in certain places. This is because these two worlds do not exist simultaneously in the game. The core feature of World Hopper's game play is the player's ability to "hop" between two to four different worlds in order to solve puzzles.
This multi-dimensional feature is shown in the above screen screenshots. The photo on the left depicts the player in the first world, while the photo in the middle shows the player in the second world. They are in the same spot, though, and for the player to reach the platform above them in the first world, they must use a platform in the second world. The game is heavily centered around this feature, as it is what I believe to be truly novel about the game. The game isn't so cruel as to force the player to swap worlds without a little warning, though. On the right, both the first world and the second world are displayed. However, the second world is intangible, and does not reveal enemy locations. It is just for the player to use to know where the platforms are in other worlds prior to making the jump. Once the player jumps from one world to another, the sprites are swapped out and the collision layer of the player is changed to interact with colliders in the second world. This method of simply switching the player's layermask allows for all of the colliders in the game for all worlds to be active simultaneously, but does not calculate collisions between the world and the player since their layermasks do not match.
The player must also deal with harmful enemies, deadly traps, and the danger of swapping into a world where an object already exists in the player's position. On contact with an enemy or a trap, the player loses half of a heart, displayed in the upper left hand corner of the screen. However, if the player swaps into another world and they swap into an existing object, be it a wall or an obstacle, they die immediately. In either case, the above screen appears, letting the player know they have indeed died. They can then click "Retry!" to restart the current level, or "Exit" to return to the main screen. There is also a Pause screen, which is the same as the one above, except instead of "You Died!!!" it says "Paused!".
The enemies in this game run on three basic movements: scheduled routes, dynamically generated routes, and random movement in a limited vicinity. The first type of movement, scheduled routes, are exactly what they sound like; the enemy runs a specific route at specific intervals. Some of these behaviors can be swapped out on the fly, like with the weird mound-enemy. It always either emerges or recedes into the ground, but whether that motion is timed or based on the player's position can be adjusted, allowing the game to dynamically change according to scripted events. The second type of movement, the dynamically generated routes, is a sort of 2D platform-traversal algorithm that uses raycasting to determine whether or not an enemy can traverse a certain area. Based on the results of the raycasts, the enemy will continue to hug the ground and move around a set of connected platforms until it is either killed or until it hits an area that it cannot traverse. The last type of movement is randomly determined within a defined area. Flying enemies, such as the bee, use raycasting to determine the bounds of the local area up to a certain point defined in the instance, and then randomly move from one spot to another at random intervals, making them rather difficult to predict.
To check out my repository for this project, follow this link:
Comentarios