Making the Game: A Frustrating Puzzle

While developing one of the rooms for Robotrooper: Simulation, I ran into some big trouble - the puzzle I had envisioned for it was simply too frustrating! The room in question appeared in my previous blogpost.


Here it is again, though with one crucial element missing - the moving platform.


The blueprint for the moving platform is fairly uncomplicated. Using a timeline, it lerps between two positions indefinitely - its starting position and a destination. Simple, right?


Well, the point of the room's puzzle is to get the Cube Key across the chasm by first launching it onto the platform, then launching it off the platform to its Slot at the other end of the room. Getting the Cube Key onto the platform proved easy enough. However, getting it off proved... challenging, to the point of being frustrating.

This was due to the shockwave gun's recoil. Pushing the Key off the moving platform requires Robotrooper to also be on the platform. However, because of the recoil, Robotrooper was very prone to falling off into the chasm below. The issue being, of course, that when Robotrooper dies, the puzzle resets, and the Cube Key is on the other side again.

I tried to remedy the issue. At first I thought a longer moving platform could be the solution, but the recoil's power was too great. I was going to create a sort of border around the platform to keep the player from falling, but instead I came up with a different idea. This room could break up the established form of puzzle while introducing a new, completely valid game mechanic - momentum.


Instead of a moving platform, Cube Key and Cube Slot Button, the room will be completely devoid of such elements. There would only be the chasm and the other side. To get across, the player will have to be clever and use the momentum of their own movement to aid the shockwave in getting them across. If the player struggles of course, I will offer them a hint to point them in the right direction, though I do not have a suitable system for that yet.

All in all, I am fairly pleased with my solution. Though coming to the conclusion that momentum is needed may be difficult, I hope it will prove less frustrating than playtesting the room's original puzzle was.

The only thing I regret is now not having a room with a moving platform... Ah well, maybe I'll find some other use for it later. Anyway, those are all of my thoughts for now. Off you go!

P.S.: Happy 7th Birthday, Elder Scrolls V!

Comments

Post a Comment

Popular posts from this blog

Making the Game: A Simple Puzzle

Image
Having created the shockwave gun , I was ready to move on to what would act as the game's primary gameplay puzzle: Getting so-called "Cube keys" to "Cube-activated buttons" in order to open a door. Just as in the previous Robotrooper  instalment, these puzzles will slowly grow in terms of complexity throughout the game. First, I created models for the cube key, button and door by placing a few box brushes in the scene. Brushes are simple geometric shapes which can be used to create models of a limited complexity. After playing with the brushes and their " brush types " (additive or subtractive, i.e. whether they add or remove bits from the overall shape), I applied materials to their surfaces and converted them into static meshes, a process I still remember from my Foundation Year. I also added Simple and Complex collisions on them, which will make them "solid" in the game. Then it was time to create their blueprint equivalents. ...
Read more

How to Keep Blueprints (Mostly) Readable

Image
The Blueprints Visual Scripting system is a great tool for programmers and non-programmers alike. It can be used to prototype or to fully implement features into a game, and its visual style makes it easy to read... Well, most of the time. Blueprints can get pretty complex - connections between events, variables and nodes can often begin to overlap, it can be hard to tell where one event ends and another begins, etc. So it is no wonder that there's a whole blog dedicated to " Blueprints From Hell ". Here are two ways I try to keep my blueprints readable, at least to an extent: 1. Comments  - There are two types of comments in Blueprints - Node Comments and Comment Boxes . Node Comments can be added on top of a node to specify what it's meant to do, while Comment Boxes can denote what a set of nodes do as a group. This can help organise content by its functionality. Above is an example of a comment box from a previous blogpost. 2.   Reroute Nodes - The...
Read more

Making the Game: Final Touches

Image
With the gun complete and the game as well, there are only a few more things left to do in the game project before I put them together. Cleaning Up the Project Having a messy project usually wouldn't matter too much, as long as the person (or people) working on it know where everything is. However, a messy project can be difficult to navigate, especially after long periods of time or if new people are being brought on board a project. That's why I'm going to clean my project up to a more acceptable standard! The World Outliner allows for easy access to all the objects in the scene. However, if they're not categorised properly, accessing them can be a right pain. Thankfully the Outliner does allows for proper categorisation through the use of Folders. I chose to sort my objects by their room and type. So all the floors in Test Chamber 01 will be in Test Chamber 01/Floors . As for my project folders, they are already properly categorised and clean......
Read more