CAGD 370 - Blog Post 3
- Els Fouche
- Apr 12, 2025
- 3 min read
A Hop, Skip, and a Jump
A Hop, Skip, and a Jump is a 3D platformer that utilizes player-placeable gravity spheres that bend space allowing for slingshot maneuvers to get through levels. The player is also able to dash forward based on their current velocity. This movement is dependent on the player's current movement vector such that a player who jumps while running forward will launch diagonally upwards when activating the dash.
Playtest Feedback
Our first playtest for the game was successful and provided actionable feedback in several areas. Our playtest group consisted of 19 of our peers.
Primary Action Items
Level Mesh Glitch
A consistent bug was encountered when using the dash ability towards a volume mesh.
Players that encountered this bug would become trapped inside the walls of the mesh.
My thought is that the volume mesh (normally used for rapid level prototyping in Unreal) is not as robust as a standard mesh when checking for high-speed collisions.
Solution: replace volume meshes with standard static meshes.
Result: Bug eliminated.
Double Jump
Players did not realize that a consequence of the ability to dash at any point in a jump meant they could double-tap space rapidly for an extra high vertical leap.
This meant few players were able to successfully reach the end of the play test.
Solution A: Floating tutorial text has been added to the game making it explicit that players can double jump.
Solution B: The start area of the level forces the player into a narrow space where a diagonal dash is not as viable, prompting them to learn the ability diegetically.
Result: To be determined. Both solutions have been implemented as of now. If solution B proves successful on its own following playtest observation, solution A will be removed.
Information Conveyance
The game designer had added text to the player's HUD in order to show them the controls for the playtest. Eliminating this was a primary concern of mine moving into this sprint. In general I attempt to avoid using text to convey instructions for gameplay whenever possible. Allowing players to discover the different ways to play on their own creates significantly more impactful experiences.
However, until I'm able to devote more development time to creating levels that inherently convey the game's mechanics I've resorted to using floating text to at least alleviate the cluttered HUD we had for the playtest. Overall, despite my distaste for text-based tutorials, this is a significant improvement.
Environment Design - Ruined Space Station Aesthetics
During this revision process I also extended the length of the level slightly and included an interior section that highlights the rest of the level visually by framing it with a window. A very basic technique but highly effective. I'm currently dissatisfied with the position of the large planetoid but due to the way the atmosphere is set up it's going to take a bit of time to correct that issue.
Immediately after the double jump tutorial the player is faced with a view of the starting area. I love this technique; prompting the player to see how far they've come can evoke strong feelings of accomplishment and nostalgia. In this case I implemented the technique a little too soon! Given time I would love to extend the introductory section even more to create a greater build up to this point.
Scripting - Objective Tracking & Door Code
The above video demonstrates the basic door code I implemented to control player flow through a level. It also showcases the objective-tracking actor component I created that keeps track of the number of objectives that the player has collected. The door code relies on the objective tracking component to determine if it's able to open or not. Currently it simply checks to see if the player has the required number of objectives rather than distinguishing one from another.
I intend to remove the somewhat tight coupling I've created between doors and the objective tracker by implementing an interactable interface. Additional improvements to the code include specific objective checking capabilities for the door code, if it becomes necessary (e.g. we need a key & lock system).
Final Thoughts
I'm fairly proud of the work I did this past sprint. I am not, however, proud of the quantity of that work. While technically my output has been sufficient I feel I should have been able to do more. Friends have told me I don't know the difference between 140% and 93%; their meaning being that I should try less hard on any given task so that I can complete more in the allotted time. Something to reflect on for the future, I suppose.
Comments