Solving Problems

Sometimes, life just doesn’t go to plan. When you’re on a road trip, your car may randomly break down. When you play or create levels In Geometry Dash, you may encounter bugs, glitches, or just aspects that you don’t like. These are all problems – unwanted situations you want to overcome – but solving them can be difficult.

There are many frameworks you can use to solve your problems and continue your creating journey. This guide will uncover some of the most important ones.

This guide’s topics boil down to identifying your problem, finding a solution, and then executing that solution. Most of this is based on critical thinking, so we’ll spend most of our time describing how to think through problems more effectively.

The Productive Thinking framework is a good starting point for most problems. It goes something like this:

1. Find out what’s going on

2. Set standards for successful solutions

3. Form questions to address your issue

4. Develop answers for your questions

5. Choose the best solutions

6. Plan to execute solutions

Some of these steps may seem confusing, so let me break them down a bit more.

As obvious as it seems, you can’t try to solve a problem which you don’t understand well. You’ll waste time on improper solutions, look for answers in the wrong places, and come to conclusions which won’t work. Additionally, you may obsess over problems that may not be problems at all.

Furthermore, some problems will be more critical than others. If you need to eat while driving, you can wait until you’re at a rest stop to get food. On the other hand, a flat tire needs to be addressed immediately, as it poses a safety risk to you and other drivers.

So to fully understand your issue, you need to know what exactly is occurring, assess its impact, and understand what components are involved. It helps to list all your known information on paper or in a document, as to not miss anything.

Here’s how one server member in our discord server described their problem. I’ve shortened their description here, but the essential details still remain.

“I’m using a Static Camera trigger to lock the camera to an object’s position infinitely, but the trigger stops working after a certain point in the gameplay. This is undesirable as I need the gameplay to remain readable for this segment, and moving the camera without the Static trigger would make it less enjoyable.

This system uses a Static Camera trigger locked to one object, and a Move trigger to move that object over time. I know this works normally, so the issue must lie in the other triggers: Arrow triggers to change the channel of the player, Teleport triggers to move the player up, and a Speed portal at the very start.”

With your info sorted like this, you’re ready to address the next step.

In this step, you define what a solution must do. Many problems will have tons of solutions, but not all of them are relevant or useful. It’s important to define what your needs are so you can work towards a better solution.

A good way to set standards is to define what your ideal solution should do, what it should not do, the resources you’re able to use, and the outcomes you want from the solution. Just like when making a vision for your level, you should define a goal for your problem solving as well.

Revisiting our earlier example, here’s one way to set standards for our bug fixes there.

“I need the camera to be static on the X axis for this entire part. However, I don’t want to change the gameplay, so the player must move up at the end of each segment and the speed portal must remain. I can use as many groups or triggers as necessary here, and I also need the camera to move vertically as well.”

Here’s where you explore the specific factors in your vision. It’s best to do this through questions, like “How can I…?”, as it promotes making an answer in the next section.

With our example, a good question is “How can I find which object is stopping the Static camera?”. We already know the base system works from testing it on its own, so one of the other objects here must be the culprit.

Another question is “How can I remake this system without using Static triggers?”. If you can’t find a solution by keeping the existing system, you can remake it with different objects to accomplish the same goal: moving the camera vertically while keeping it still on the X axis.

As stated before, you’ll spend this section answering the questions you posed before. Due diligence is a good step here – leave no stone unturned when generating answers. Just like when you’re getting ideas, you can use tools like brainstorming to create more answers. Don’t judge the solutions yet either; after all, anything might fix your issue as it stands.

For our example, here are some answers to the prior questions:

“How can I find which object is stopping the Static camera?”

• Check Trigger Order and Channels, and ensure the Arrow trigger doesn’t interfere with this

• Remove individual objects to see if the system keeps breaking

• Make sure our object is compatible with the Static trigger (portals won’t work, neither will objects that are toggled off)

• Double-check each group – our camera object must be in a unique group, or our static cam trigger may be getting stopped by a Stop trigger or another Static trigger

“How can I remake this system without using Static triggers?”

• Use Camera Edge triggers to restrict the horizontal camera movement

• Use Move triggers to simulate the camera moving around

Here, you can choose the best solution for your needs. Weigh each potential solution against the success criteria you defined earlier, and select a few which can work well. If necessary, you can refine these solutions to improve their quality before actually building them.

For our example, I’d prefer to keep our existing system before recreating it without static triggers, so I’ll look through the existing system to find out what’s going on. I’d also prefer to not comb through multiple trigger interfaces, so I’ll start by removing objects to see when the system stops breaking.

Finally, you can plan how you’ll execute the solution. This isn’t always necessary as some solutions are so low-level that you can just do them immediately, but it’s crucial for more complex problems. Like with your level plan, it’s best to explain this in detail so you have clear action items.

Our example is fairly low-level, so I’ll proceed with the main solutions from earlier. By doing so, I found that the teleport triggers were breaking the static camera. The same issue happened with teleport portals, so I ended up replacing them with moving platforms to take the player upwards through the gameplay.

I mentioned low-level solutions earlier but what does that mean? This is part of an important concept known as abstraction laddering. Some problems are highly technical but others are more abstract, so it’s important to identify what level of abstraction you need to solve your problem. Sometimes, stepping back to look at the big picture helps more than focusing on one or two specific objects, and vice versa. Think of this as a more refined strategy for steps 1 and 2 of productive thinking.

When you’re first framing your problem, it helps to define it as high-level or low-level. Low-level problems concern the most basic actions you do as a creator: placing objects, modifying them, making them interact with each other, and so on. High-level problems focus on the big picture: your goals and ideas.

When you play Geometry Dash, your individual taps are a low-level task, while learning the game’s mechanics and the level’s gameplay is a high-level task. When driving your car, your individual actions like steering and braking are a higher level than the individual valves and pumps inside the engine, but also lower-level than directing the car from one location to another. Even these guides have abstraction levels where you learn low-level actions in the editor section, and high level actions here in the main skills section.

To better frame your questions, you can start with a medium-level question. Then use “why” questions to get more abstract and move up the ladder to high-level questions, and “how” questions to move down to lower-level ones. You can then re-evaluate your problem with a new perspective.

For example, let’s say you’re trying to make a trigger setup that figures out the player’s speed and stores that value in an Item ID. However, the system isn’t working for some reason. You can divide this system into three major levels:

• High level: What the system will do

• Medium level: What triggers & objects are involved, and how they’ll interact

• Low level: The exact settings each trigger & object uses

From here, a good medium-level question would be “Can these objects interact with each other in the right ways?”. There are multiple ways to detect the player’s speed, such as collision blocks or area triggers, but not all of these can be used practically.

If there isn’t a medium-level problem, you could then ask a low-level question, like “How should these objects be set up?”. You can then double-check how everything is configured to see if you made a mistake with the setup.

If figuring out the player’s speed is truly impossible, you can climb up to the highest level, ask yourself “Why do I need the player’s speed?”, and find a solution accordingly.

As with Issue Trees and First Principles, complex problems which involve many factors may also have a variety of potential solutions. However, this also means you must choose a good solution once you get to Step 5 of Productive Thinking. Sometimes, the best way to do this is through inversion - finding the worst solutions and removing them from your list.

This is similar to answering a multiple choice question: rather than finding the capital T right answer, you discard the wrong answers first. As you eliminate these possibilities, whatever remains, no matter how improbable or ridiculous, must be the right solution. If you can’t find a singular “best solution”, you can examine the principles which make other solutions bad, and use these factors to avoid making the same mistakes with the option you choose.

Referring back to the diagram above, many solutions are provided to improve in creating, but whether or not they work for you depends on your situation at the moment. Maybe you have been working hard in the editor but got burnt out along the way. If so, forcing yourself to work extra hours in the editor wouldn’t make much sense. Meanwhile, taking a break would be a more viable option to give yourself some time away from the editor and do other tasks.