New Witchfire screenshots, plus man plans, God laughs.

The Witchfire development stories I post here follow a certain pattern, usually. We face a problem, we attack it, we solve it, boom, happy ending and we move on to the next step.

Not this time. Get your “F” keys ready.

At the end of the last diary entry I wrote:

So we are moving on to the other big topics for the next quarter: the hero’s murder toolkit and the rewards/unlocks. I mean, we’re already working on these for literally years now, so it’s more about finalizing that design rather than the discovery phase. If all goes well, we’ll add in a third big thing, which is boss fights.

As Derek Landy observed in Mortal Coil, “plans are invitation to disappointment.”

Nearly none of what we wanted to achieve happened. We still have the same murder toolkit, we barely scratched the rewards and unlocks, and we have not touched the boss fights at all.

Here’s why.

We have three programmers. Last autumn, one of them, Piotr, made a gameplay system that competed with another one, made by our designer Karol. Both were excellent but in the end we’ve decided to go with Karol’s system, just updated with some elements of Piotr’s system.

However, Karol’s system needed a clean up and a different internal structure. Piotr took it upon himself to rewrite the whole thing, a curse known in the game development as code refactoring. It’s basically “restructuring existing code without changing its behavior”.

That took two months.

It was needed, it was necessary, and it was executed skillfully, but you can imagine the frustration. We basically have the same thing we already had before, it’s just nicer under the hood.

Same goes with a few other things that Piotr worked on. One example is the optimization of the animation system. Results were impressive, you can see the speed up values in green, in the last column.

Another example is the Fortnite-inspired Significance system, although our version slightly differs. At its core, it’s something that optimizes the animation system ever more, boosting the framerate by spending less CPU cycles on cloth emulation or animation blends on enemies considered “not significant”. The players won’t notice anything, but it’s less strain on the processor.

What about Kacper and Paweł, the other two programmers?

Until now, we’ve been making and playing the game in the UE4 editor. It’s fantastic, you make something, click Play, test it, click Escape and you’re right back to creation… Awesome. But, surprisingly enough, if you cook a build – i.e. if you tell UE4 to spit out the game in its final form, ready to be shipped to online stores – the game might not work. Don’t ask me why, it’s magic.

Because it’s better to test these things early, we’ve decided to finally make a cooked build. And lo and behold, it wasn’t working, like, at all. The game didn’t even start. So Paweł jumped on the issue, and long story short we now have fully functional cooked builds – but the weeks went by and from the content and features point of view, there was no progress.

Kacper focused on optimizing the game. Not that it was slow or the framerate suffered heavily, but there were performance spikes here and there, and some things were just begging to act more efficiently. Whatever issue Kacper found, he or Paweł fixed it. It’s still not the final optimization, but the game clearly runs better and smoother.

Another thing that took Kacper a while was a system that allowed for easy setting of combat areas. Previously, we’ve done all of that manually. Now, we can insert the combat zones on any new level we build much faster and better, with higher precision of area limits.

That’s not all. We also worked on refactoring the combat system itself (spells and their interactions, weapons and their perks, etc.), AI tweaks and bug-fixing, improvements of the path-finding system, and many other things.

But again, while all of the above is nice and dandy, none of it is new features. None of it is “more game”.

It’s so fucking frustrating. You’d launch the September version of the game, and you’d launch the February version of the game, and to the untrained eye it’d be the same game.

Wait, how about the graphics? Surely we’ve build more …world, right?

Mostly, nope.

Here’s what got us stuck for more than two months.

The world of the game exists in two versions. One, it’s a regular day. Two, something we internally call the “witchworld”. It’s whenever you enter a witch-cursed zone, and she throws her minions at you. You can see the original idea in the game’s teaser, when everything changes after awakening the monster, and we go from day to witchworld (worth noting that the final witchworld will be quite different to what’s in the teaser).

During the winter months we’ve decided to focus on the final lightning for the game, even if for a fact that it’s needed for the proper saturation and strength of the particle effects, of which we have many.

Despite the fact that you spend 90% of the game fighting in the witchworld – Witchfire being a shooter and all – we needed to start with the base, the core. Which is the “normal world”, the daytime. And you’d think that’s relatively easy: set up the lights, bake them to lightmaps, voila.

Well, it’s three light years away from being easy, but more importantly, the look of the game and the lighting of the game are two different things.

We wanted our world to look old, ancient almost. Daylight and early autumn, but without any happiness in the world. Mysticism and mystery surrounding your every move but also a certain level of realism.

Now, the “easy” way to achieve this is with color grading. Color grading is, basically, your Instagram filters. You take an image, and you manipulate color, brightness, contrast, level, highlights and shadows in order to achieve a certain look. Here’s an example of what color grading can do to an image.

Note how mundane the original is. It’s like you’re looking not at the movie, but rather at the documentary about the movie. See how the color graded version is much more otherworldly, how the light beams became more pronounced, adding to the atmosphere, how the faces catch your eye better than the unedited version. Up, down, it’s the same picture, but color grading makes one magical.

But we can’t use this solution.

The easiest way to explain this… Imagine you want a game that’s entirely in black and white except for the red eyes of the enemies. You tell the color grading to convert every color to grey except for the reds. Simple, right?

Right, but what if a certain element of the environment is red? Say, you have a road sign with red elements on it? Well, in that case, you’d have a game that’s in black and white except for the red eyes of the enemies …and that one road sign.

What you can do is to repaint the sign to be green or blue or whatever. Anything but red. And then the color grading will convert it to grey.

Cool, but what if you want a game that’s in black and white, except for the red eyes of the enemies, yellow spells, green health potions and blue souls of warriors long dead?

You could repaint every asset in the game to be grey …but what if one day you decide that black and white is not the way, and sepia would work better? Time to restore and repaint all assets again?

I hope you get the idea. Color grading affects the entire image and in a way we lose both control over the look of the game – I know, it’s a paradox – and the ability to change things easily. Also, as Adam, our graphic artist, said:

You can do things fast in post-processing but then it’s easy to lose depth in colors. And it won’t be that obvious and visible, you don’t have anything to compare it to and you wouldn’t even know what could be better. But the image will occasionally lack depth and all of its nuances.

So what our graphic artists, Adam and Andrew, had to do, was to emulate the color grading …without nearly zero use of the color grading.

Let me quote Adam again:

So, the light setup sounds like a simple, straightforward task. The only thing you need is to place the lights and set the colors. And that’s indeed the case when it comes to static images.

But in video games, everything is dynamic. Instead of one fixed value you work with a set of ranges that change dynamically. A simple act of turning the camera towards the sun alters the perception of the image. And then things get much more complicated if you have, say, tight rooms overlooking wide vistas, or if a level is vertically diverse.

We have both. And in such a case, compensating for deficiencies in one place always comes at the expense of another.

How to solve this? As always when we talk about solving a complex issue the best solution is to divide it into small chunks. In our case, that meant turning off all fancy postprocessing and render effects, and starting with just one key light and bounces.

It’s the moment when you can feel the skepticism from the rest of the team. But that’s how catching all the basic errors needs to happen, without the world overshadowed by fancy glitter. Going the other way around is fast but can lead to unsolvable problems and a lot of custom solutions, which always end up being a disaster.

In other words, in order to make the final lightning, we had to reset everything and start from scratch. Just another “refactor”. However, this time the light set up we’ve done allows for easy changes in the future, if we ever change our minds about it. And if we do:

Because of this dynamism of games, it’s sometimes hard to define when enough it’s enough. You can always find something to fix and make prettier. This can easily spiral down into a never ending stream of fixes, updates and changes.

We’ve discovered that comparing the old and new light setups can help with this. I asked our programmers to write a code that allows us to easily and quickly switch between the setups. Basically, a comparison on the fly, in real-time. Saves tons of time and discussion.

As it’s always the case with game development, turns out that a good tool might be a step back, but then it’s a hundred steps forward. An incredible time saver.

The graphic team delivered, and you can see the results in this post…

…but holy shit that took time.

And that’s the story. A lot of work done, all necessary, but almost nothing to show for it. I mean, obviously the stuff like cooked builds, better framerate, or tools to speed up the development will benefit us in the future. And the world looks good, although you be the judge. Images are straight from the game, untouched.

But man, I can’t wait to have more of the game.

Well, it’s not all doom and gloom. For two weeks now we’re back into adding new content and features. Can’t wait to show you what exactly the witchworld looks like, our new elite enemy, how the weapons or spells work or that unique gameplay system we have in place.

Not making any promises as I don’t want to jinx it like the last time, but fingers crossed it won’t be three months till the next update.

Question of the Week Quarter

keep at it my dudes , make it ooze atmosphere and proper story and sense of place , please no mindless hollow looter shooter we got enough of that shit , thanks

— knotecdysiast324 (@knotecdysiast31) April 7, 2021

First, all right, so look, whatever your opinion on looter shooters is, it’s kind of a myth that there’s soooo many of them. You got Destiny 2, Outriders, Borderlands 3 and surely a couple of more, but it’s not exactly like there’s an avalanche of high quality looter shooters bleeding your wallet dry.

Second, Witchfire is not a looter shooter. There’s loot. There’s shooting. But it’s not a looter shooter.