Creating an automated level tester

In our previous post we created a script to generate the base structure of a level.
We now want to create a script that can perform a basic check on our levels so we can know if that level is, at least, winnable.
There are a few ways to achieve this. One way is we can create an artificial inteligence (AI) to actually play the level, tile by tile, picking up mana and stamina, and trying to get to the exit.
As awesome as that would be, AI is extremely difficult to code. Luckily for us there is a much simpler approach we can take.
As we mentioned in previous chapters like this one, working with a grid goes a long way. And once more comes back to aid us immensely.
Always consider using some sort of discrete coordinate system for your games, if possible (square grids, hex grids, etc.).
Back to our stuff. Since we know it costs one mana per tile we want to place, and that each straight tile is 1 world unit (because that’s the size of our grid), we can calculate if we have enough mana potions to reach the exit.
Here’s the general idea of the script that would test our level:

We start at the player spawn position and initialize our mana stash to 10

Calculate the distance to the closest mana potion

If we have enough in our mana stash to get to it, we subtract the amount of mana we should have used to reach that potion, and then we add the amount that potion adds

We repeat from step 2 using the mana potion’s position from step 3

Granted, this does not replace actually playing the level, because of many factors such as:

If you have allies on Spell Run, then the mana pickups provide you with more mana than the basic pickup. We are not taking this into account on this test. This is because we want to make sure the level is winnable without use of any allies or sacrifices.

Also, you can Jump on Spell Run. Yes! You can jump your way through one missing tile if you need to (but jumping takes a bunch of stamina from you). We are not taking that into account.

Straight tiles are one unit in size (cell), but turn tiles (you may have noticed this already) are more than one cell, they have a similar movement like the knight in chess.

So, this will give us a very basic and rudimentary result if the level is winnable.
But the most powerful aspect of this is not if the level is winnable. We are more interested if the level is not winnable.
If that’s the case, we can erase and generate a new level until one is winnable, or tweak it to make it winnable.

The output of a test

Another approach (which we’ll be making in the future) is to create a score for the level. So, instead of the level tester script to return true or false (winnable or not), we can have a score from 0 (not winnable) to 1 (easily winnable), and tweak levels that are above 0.5 or whatever.
Having such score will provide us a couple extra tasty benefits, such as:

We can define the threshold to get 1, 2 and 3 stars on each level by using the score value in al algorithm

We can also define the level difficulty and create some heavy or special levels. For instance, a level with score 0.2 would be winnable, but very, very hard.

If you think the game you are developing does not allow the creation of an automated level tester, think again. Chances are you can create some sort of tester script to help you with a few things.
That’s it, stay tuned for more.
Don’t forget to follow us on twitter for news regarding articles and game development [twitter-follow screen_name=’indelvestudios’]