If you love developing hard games but aren't a good player yourself, you have a challenge ahead.

Last week, while working on a game, I noticed that I could not beat my own levels anymore. I wanted to reach the final boss, so to speak, and that single thingy took me longer than I'd be happy to admit. It might be the age, or that the game is simply too hard.

So I started looking for different ways to save time. As always, cheating was an option. I also thought of making a special, shorter version of my gameplay to avoid playing through the same hard spots every single time. After all, I just wanted to test the final boss!

As you know, there are many ways of approaching this. But, in my case, I came up with an alternative approach that ended up being surprisingly useful. This strategy helped me shortening the testing times of my games plus cutting the design iteration times.

If you are a programmer or designer, this article will give you insight into a second approach for handling these challenges. If you have any other role, well, share this article with the right person.

To present the use case, I looked for an open-source game on GitHub. And so I found a cute little game called Popcorn that I borrowed from TheAislan (full credits to him!). It's a basic 2d platform game that features simple 2d physics mechanics, perfect for our use case. Check the screenshot above, isn't it adorable?

I'll start off by telling you how I used to deal with testing...

Level 1 Unity Developer: The Grind

A decade ago, grinding was my preferred way of working (oh dear). All the testing I did was manual, and it was all fun.

Then, weeks passed and the game got more and more complex. I started growing frustrated, since now playing every time took me almost 20 minutes. Tweaking the final boss scene transformed from being a pleasant moment to sucking all my mana and burning the entire QA's yearly budget.

Something had to be done, and so I searched for solutions.

One workaround was to split each level in multiple, even finer sub-levels. That way, we could just load the specific sub-level we want to test. This solution might work well for games whose level areas are highly independent of each other, such as platform games. This has some overhead on the programmer when it comes to scene management, but it's quite alright.

Another possibility is to add custom in-game panels or UI inspectors to enabling cheating and special actions. Those could allow the developer to skip certain parts, increase stats or just disable annoying ads. These work just well, but some time has to be spent on preparing and maintaining the front-end.

And here comes the classic: a configuration file to be loaded in run-time. That sneaky file can be used to choose which features or cheats to enable. That may look like below:

{
  "GodMode": true,
  "AllLevelsUnlocked": true,
  "Gold": 500,
  "SkipAds": true,
  "UnlimitedTime": true
}

You can load such a configuration file through a C# script like below:

[Serializable]
public class Cheats
{
    public bool GodMode;
    public bool AllLevelsUnlocked;
    public int Gold;
    public bool UnlimitedTime;
}
var cheats = JsonUtility.FromJson(File.ReadAllText(Path.Combine(Application.persistentDataPath, "cheats.txt")));
player.Gold = cheats.Gold;

Of course, make sure not to enable that feature in release versions 😉

These options have one common problem: we have to pre-define what is possible in advance. We get what we programmed; we don't get what we didn't.

That can quickly become a time sink:

During testing, we decide we need X. Therefore, we stop playing and wait for a programmer to implement X.
We then replay till that point and perform X, only to realize we actually wanted to do Y.

In some situations, we could clearly profit from having more flexibility.

So I asked myself: can we do better?

...Continue reading the article at TheGamedev.Guru