Witchfire GGU Diary: Prologue

In the episode zero of the diary about our first big update, I want share some light on why we stopped patching the current version, and what are the three pillars of the GGU (the codename for our first big update as described in the roadmap).

Not a game exists that is bug-free. If we kept fixing the bugs, we’d never be able to move on to the new content. So last Friday we have delivered the last patch for the Early Access launch version of Witchfire, then kept the ear to the ground throughout the weekend to hear if we missed something big or if we created a game blocker. After we made sure the game is in good shape, we’ve started working on the new stuff.

But time and resources and focus on the new stuff is not the only reason why we stopped patching the current build. We just didn’t want to work on two games at the same time.

Let me explain. When you have a “live” game, and Witchfire, being an Early Access game, is kind of like this, you often work on two projects at once. And both are the same game!

Let’s call one of these projects Current Witchfire. Current Witchfire is the game that is available in the store and this is what people buy and play. Some of the team work on that version, fixing bugs, and maybe adding some small Quality of Life updates.

Let’s call the other project Future Witchfire. It’s a separate version of Witchfire to which we add new features, like new enemies, new locations, new weapons, etc. Obviously, this is not what we want our players to see, because this is work-in-progress, unfinished and extremely buggy and unbalanced. You would hear the word tempshit thrown a lot at the studio. “Don’t worry about the sound for it, it’s tempshit” or “I put a tempshit texture on it, will fix soon”.

With those two versions in existence, this is how things are supposed to work:

1. Current Witchfire is being updated with bugfixes and such, and released to the public every few days.
   
2. Meanwhile, Future Witchfire gets new stuff, and is basically developed in parallel to Current Witchfire.
   
3. If all is good, bugfixes and other updates from Current Witchfire are copied to Future Witchfire.
   
4. When Future Witchfire is solid, it becomes the new Current Witchfire, rinse, repeat.

Sounds good, right?

No. It’s the stuff the nightmares are made of.

Here’s an example. Imagine there’s a bug that made an enemy forget how to melee. The team maintaining Current Witchfire fixes the bug. Meanwhile, the team behind Future Witchfire partially rewrites the entire melee code because of a certain new feature. And …now what? When it’s time to copy the bugfix to Future Witchfire, how do you go about merging it with the rewritten code? Is the bug still even there? This needs manual work and new investigation, so you’re basically working on the same bug …twice.

The fixes from Current Witchfire can even break Future Witchfire because these two versions are obviously no longer 100% compatible.

There’s so much work involved with maintaining the fixes between the two versions that even the biggest studios often fail at it. Have you ever had a bug re-introduced to your favorite online game with a new season or big update? It’s because someone forgot to merge the fix from the Current Version with the Future Version that became the new Current Version… And this happens way too often for comfort.

So what’s the alternative?

Well, there are some advanced techniques allowing for an easier time with multiple versions solution, but again, none is perfect, as the experience with live games shows.

A better options for us is to simply work on just one version of the game.

Of course, this has its own issues. Between the big updates with the new content you just cannot release the game to the public anymore. What if someone discovered a particularly nasty bug today, one that ruins the fun for a small but sizeable portion of the user base? We would not be able to do anything about it until the GGU releases…

Anyway, this is the road we’ve chosen, copying bigger and better known indie studios. Basically, the loop is like this:

1. Release the game
2. Patch, patch, patch until most bugs are fixed (this usually takes two weeks)
3. Stop releasing the patches, work on the new content (1-3 months usually)
4. Loop to the first point

Now, when working on the new content, obviously we can and are fixing bugs as well. It’s just that these fixes will only see the light of day when a big update drops. An update like the GGU.

GGU?

Not even close, to be honest.

Anyway, we’re going through a quiet phase now. When you work hard for months towards the release and then patch like a maniac for three weeks after the premiere, that energy needs to be recharged. I can clearly see the team mentally and physically rebooting and trying to get back into the normal work cycle. It’s normal, you’ve seen that need for a recharge in, uhm, more private sections of life.

But at the same time, we’re slowly trying to grow and hire more people, especially in the level art department. Andrew and Adam made a shortlist of candidates and are actually having the virtual meetings today.

Fingers crossed. It’s not easy for us to find a new Astronaut because we are looking not only for talent and love of video games, but also a certain personality type. I personally call the Valve Light approach. Valve has been known to expect the ability to self-organize and not be a one trick pony, and we’re following that philosophy. It did wonders for us before the pandemic, but now that lots of developers prefer working from home, it’s even more important they can take initiative.

Other than this, the GGU plan is gaining a concrete structure. The three pillars of design are:

• The update needs to offer many hours of fresh gameplay for returning players. These are the people who trusted us with the release version, and with each big update expect us to deliver something they can enjoy and spend quality time with.
  
• The update needs to be a great pretext for new players to join in the fun. Many people postpone the purchase until 1.0. They may not realize there’s a lot of content in the game already, and it’s all very much playable and stable. But it’s kind of hard to run a studio with no income, so we need to keep having Witchfire as an attractive proposition for the entire duration of the Early Access. Big updates are a great reason to start playing.
  
• The update needs to be attractive thematically and visually and offer enough new content for the media to pick up the news about it. I mentioned it in one of the latest posts how and why our release marketing was so …light, to use a euphemism. Hopefully this changes with the GGU.

With these three pillars in mind, we’re working on details this week. Some of the planning work is already done, and hopefully will be finished by Friday. Next week, I will be able to share some examples of what we’re working on – avoiding heavy spoilers, of course.

Till then!

---

Question of the Week

31 weapons!? That's A LOT! But then some weapons will be very much alike, won't they?

— Dirk (@DirkVanDagger) October 21, 2023

Absolutely not.

The design paradigm for guns is never to repeat the functionality. You will never see “the same gun just with slightly changed stats” in Witchfire.

To be clear, there’s nothing wrong with the stat approach. In some games, even a small difference can matter a lot. But we’re not these games, and in our case, we want all our weapons to feel unique.