Playtesting Witchfire, or Why Are Playtests Important

You know that saying, „when the players tell you what’s wrong with your game, they’re always right, but when they tell you how to fix it, they’re always wrong”?

There’s definitely some truth to it, but what if the feedback comes not from the players but from fellow game developers?

Last week there was a private – or, to be precise, limited mostly to Polish game developers – event called Game Dev Evening (GDE). For over a decade now, in the middle of the summer about two hundreds of us meet for the weekend and talk shop and drink wine. Nah, I’m kidding, it’s mostly beer and vodka.

Somebody thought it would be cool if we showed Witchfire at the event. We agreed and realized it would also be cool to let some devs play the game and gather their feedback and see what’s good and what’s bad with our own eyes.

We knew the PC was going to be decent, so that wasn’t a worry. Still, we figured we’d cook a safety backup build a day or two earlier, and also record a backup presentation video in case there’s some trouble playing the game.

So …that didn’t happen. I had friends waiting for me in the car when I was still copying the latest cooked build onto a USB stick. No backup build, no video.

Later that day, when we were about to launch the game on the GDE’s PC, I had to make a quick run to the room for the dongle to the Elite II controller. “Go ahead and start testing it without me”, I said.

When I returned to the tent – yes, the presentation took place in a large tent – I saw our guys a bit worried, scared, troubled.

“It’s crashing every minute, or even more often than this.”

Fuuuuuuuuuuuuuuuuuu…

In theory, there was no reason for it. Most of us work from home, and we have quite different PCs. AMD, Intel, nVidia – anything goes. And the game works well on every single one of them. So what was happening here?

After a while we noticed that the game kept crashing less and less often. We could actually play longer sessions without an issue. Phew!

What was the issue? No idea. Creating the shader cache on this particular PC? An aggressive garbage collector on cooked UE4 build? Whatever’s the reason, we’re not sure yet. Obviously, our top men are investigating it as I write these words. But then, at GDE, we just felt relieved we didn’t have to apologize to a hundred or so people that well, there would not be any Witchfire presentation happening.

It did happen, and I think it went well. I talked about the game for an hour while Karol played it, and I still wasn’t done when it was clear it’s time to wrap it up.

But the most important thing was seeing people play the game, listening to their feedback and having our own conclusions and notes. We believe playtesting is a crucial element of game development, obligatory, essential. It’s always a great reality check and maybe even a course correction.

Of course, the conditions were not ideal. People didn’t get the proper onboarding, and Witchfire is full of little idiosyncrasies that maybe be confusing to a first timer. Still, we know what we want our game to be, and it was easy for us to notice where the strong and the weak points were. We did not have to make a scary amount of notes – I think we ended up with maybe 30 in total? – but each was so important that it took us six hours to discuss them all after returning to work.

To give you an example of the feedback we need to address, let’s talk Stamina. Witchfire has Stamina. It’s not an unusual feature, you’ve seen it in Dark Souls or Stalker or many other games. But it is rare for Stamina to exist in a shooter like Witchfire, and it is super rare that it is so incredibly important. In our case, Stamina management is basically as important as health and ammo management.

All right, so there’s Stamina and there’s the Stamina bar. When Stamina level becomes low, the bar gets red. When Stamina gets below zero, you become Tired and you’re seeing a special postprocessing effect on the sides of the screen. When you’re Tired and you try to execute another Stamina-costing move, like Dash, you become Exhausted and basically you start seeing double.

If you’re Tired or Exhausted, you can still do all the things that cost Stamina, but not as effectively. So, your jumps become lower, you dashes shorter.

We thought we had a pretty decent system. Looked like the messaging was there. You can observe you Stamina levels (the bar) but if you don’t, we’re still telling you that you’re out of Stamina (Tired and Exhausted effects).

But almost nobody got it that the combat loop includes Stamina. Nobody got it that you cannot spam movement and abilities without taking Stamina into consideration. So people were exhausting Stamina quickly, that made them slower, and that meant some enemy projectiles that would otherwise missed them, hit them. That meant loss of health and another Stamina hit, ultimately ending in quick but painful death.

There was just one person who actually was playing the game very well. Until we realized he accidentally pressed our debug-cheat button and was playing in god mode.

We like our combat loop a lot and Stamina is here to stay. There’s more than one way to regenerate it and it has many other applications than just protecting the game from movement and ability spam. But the playtest showed us very clearly we need to update our messaging. It’s all good, that’s why we did this playtest in the first place. But it needs to happen.

The other 29 notes differ in scope – from smaller and easier to fix stuff like “the boss fight was too dark” to more demanding issues like how to explain it to the players that weapons have limited range with a very aggressive damage fall off – but we’ve already prepared the solutions and are working on the implementation.

But here’s the weirdest thing… People spent a good few hours with the game, and had many notes for us. But nobody – at least I don’t remember anyone like that – was trying to give us a solution. And for the life of me I have no idea why. I would expect game developers to be even more eager to propose a fix than the players, but that was not the case.

I mean, some feedback is so obvious that there’s no solution to offer. We all know what’s the solution to “the tooltip font is too small”. But then there’s stuff like “people don’t understand that ADS-ing increases range, so they try to play with hipfire only” that begs for “you guys should do this and that”, and yet nothing like this happen. I don’t know, maybe it’s because Witchfire has only two kinds of issues: banal, that require no explanation, or difficult to design for on the spot, requiring a quality design time.

Anyway, once again I was witness to how important playtests are. We did one a year or two ago, and it showed us some things, but the one last week, much closer to release, was even more useful.

Indie devs should use any opportunity they get to playtest their games. Some studios keep their projects such a secret as if it’s the proof that Jesus was an alien. Come on, people, with 99,99% of certainty your game is not the next Knight’s Lore, a game the publisher kept for a year before it went to the stores, afraid – correctly! — that after it premieres no other titles from their portfolio would be able to compete.

No one says you should release your alpha builds on torrents, but you really should playtest your game whenever you can. An industry event, a visit to a friend, whatever works. Forget NDAs, just let people play it – and reap the benefits. Because you will. Unlike some movies gutted after audience testing, your game will always be better once you see it played by someone else.

Because that’s the thing: someone else. It’s not only that this person will do things you never thought of or will not do the things you thought were obvious. It’s also they will point at things that are weak but you got so used to them during the development you’re not even seeing them anymore.

Anyway, big fat thanks to GDE organizers for letting us show the game, and love to everyone who attended the presentation and/or played the game.

Next month, we release.

Early Access, September 20th.