One of the biggest pieces of knowledge that I have gained over the process of building Duped is the value of play testing. I already knew this, theoretically. Play testing is great for catching bugs and seeing what features work / don’t work. But, until I started doing weekly playtesting nights with external folk as part of my dev cycle, I didn’t really understand how important this was. To illustrate that, I’m going to talk about the changes that one level in the game went through — the third level in the game.
1–3 is an important level; it’s the first level where you see a clone of yourself — which obviously introduces the main mechanic of the game. As you see in the gif to the left, this level is also designed to impart one of the key themes of Duped: you are weak by yourself, and strong together. In this instance, the player is meant to learn that they can only jump a small amount by themselves, but with clones they can add to their momentum to jump higher. In an ideal world the player does what you see above.
The level then shows this concept again, but with three Dupes in the stack. Easy peasy, right? It’s not even designed to be a puzzle — levels 1–1 through to 1–4 are basically just glorified tutorials. So, what went wrong?
When I first started having people play this level, this was what happened about 80% of the time. The problem is that the momentum added when you jump was a fixed amount. When you jumped with two dupes in a stack, you were able to jump a LOT higher if you jumped twice quickly, as opposed to jumping and then jumping again with a small delay.
This was not what people expected. Users were getting stuck on this level almost every single time. 1–3 frustrated my players so much, because they knew they were doing something wrong, but they didn’t know what.
I agonised over how to fix this for a long time — I tried adjusting the heights of the platforms to make it easier, but that just led to some users being able to skip the dupe jumping entirely — not learning the mechanic at all. I tried teaching the fact that you had to jump quickly, but it was almost impossible.
In the end, the solution I came up with wasn’t one that came from my head, but one that came from the players. As a game designer, I don’t necessarily need to come up with a solution. The best way to fix a problem like the one I had with 1–3 was just observe what the players tried to naturally do, and make it work. Players didn’t want to have to carefully time their double jumps to get the correct height. They wanted to be able to double jump at their pace and get the required height. So — that’s what I allowed them to do.
If you look at the gif above, you’ll notice that the jumps are all timed differently, but all get around the same height. My solution was a simple one — give the player a bonus to their jump based on how long they wait. If they jump twice quickly, they don’t need a boost. If they delay before pressing jump again, they get a large boost to their jump. This has the effect of evening out their jump no matter how long they wait before jumping again (to a point).
This is a simple solution, and the reason I bring up 1–3 as an example isn’t because I think this code is particularly clever or inventive. The reason I bring it up is because it’s an example of a time where players found an issue, and I tried to solve it without thinking about the natural interactions the players were trying to have. The solution to problems like these is almost always to observe. What is your player doing, and how do you turn that into the solution? By doing this, your players will feel like they already know what to do.
We hope you enjoyed reading this! Have a question or want to chat more about game development? Reach out to us!
Other places you can find us:
- Our other game development resources
- Join our Discord server
