Quantum League

I have begun writing this page project as the news have been broken that Nimble Giant will halt any development efforts of the game. Even if the servers are still online at the moment, the game’s design is now static.

Quatum League started as an internal jam project at Nimble Giant (although back then it was still NGD Studios). The situation was pretty dire at the time, the studio having just lost a big client and even considering closure, in addition to mounting economical woes.

Nevertheless, both the studio and the project survived that period - I had blogged about those moments roughly as they were happening:

Even though this project is now complete, I don’t want to stucture this as a post-mortem: all applicable development lessons and takeaways have already been processed.

What were our goals in developing Quantum League? People who are outside of game development often assume the sole reason one makes a game is to sell millions of copies and make tons of money. In reality, if that were the sole motivation, much less projects would ever see the light of day. I’m not saying we didn’t mean to make a profit, obviously, but the principal driving force was in fact proving the Studio’s development capabilities in a genre we were newcomers in and with a game engine we were learning to use.

Development of the project started right as Epic Games switched the licensing on Unreal Engine 4. While the prototype was made in Unity, the project was quickly rebased to Unreal. During the first months of the prototype, we were learning the engine as we were discovering the game we were building as well - it was actually pretty fun! Learning a new engine technique sometimes opened up an opportunity in the prototype - conversely, developing the prototype forced us learn about new areas of the engine.

It was at this stage where I managed to rediscover how fun it was building levels out of BSP volumes - all my early forays into level design made by blindly prodding at the editor shipped with UT99 were coming back!

Another team was also working on a technological framework for multiplayer games on Unreal. In parallel, yet another team was working on a look-dev demo to test the art pipeline - the increased confidence in our skills in that new engine led to us getting a contract for a Battle Royale style shooter prototype. This meant that Quantum League had to be put on hold while almost the entire studio switched over to that project, which unfortunately didn’t pan out in the long run. Who knows, had that project taken off we would probably have forgotten about QL.

But we didn’t, and half a year later we were back on rebooting the prototype, using the newly-developed technological framework. This turned out to be the true beginning of pre-production, and the target was to build a vertical slice.

This is the version that we presented at EGW and that we ultimately demoed in early 2018.

Presenting to a large room full of fellow developers is always fun, and interestingly there were several people in the audience who came to chat afterwards, sharing their stories of having chased a similar concept, but with different results.

This is a thing I encountered many more times during development, as Time Loop mechanics reached a sort of mini-mainstream (at least amongst game developers) - the reveal of 12 minutes and Death Loop and their eventual release will tell if the public shares this interest as well.

I had tried to investigate if there was any common factors in the zeitgeist at a certain point in time which may have influenced so many people in pursuing similar concepts, but as always these things are nebulous. There is no single common reference or starting point that I’ve been able to identify that different games shared - other than the inception of those projects seems to have happened around 2015-2016 in most cases.

After EGW, studio leadership went over all the feedback and reactions we had received from showing the alpha, both on the floor of GDC and in private meetings, and decided to greenlight full development.

The dire conditions in which we had decided to do a prototype jam had improved, and Quantum League was then going to be one of many production lines. Two were dedicated to client projects, and we were the third. This meant that we had to keep the team lean as it was the other teams who were actually making money to keep the lights on. This was an interesting challenge, as it meant that we had to focus on achieving what we could with what we had, without losing sight on the big picture.

Did you ever think of a game idea and wonder why hasn’t someone done it before you? Well obviously the first answer is: you haven’t looked hard enough - of course someone had the same idea before and tried to execute it! However their efforts may have not been fruitful, or maybe they pivoted along the way… We encountered many problems that seemed unsolvable at first glance while working on Quantum League - brain-searing dilemmas that had no right answers no matter where you seemed to look. And nevertheless we managed to move forward.

First big dilemma was technical: How do we ensure that the things that happened once, happen again very precisely in the same way as before? QL is a shooter, and bullets travel big distances very fast. Getting the player orientation when the bullet was fired slightly off even for a fraction of degrees can mean that the entire sequence collapses and loses meaning. And how do you do all this OVER THE INTERNET? We found a general method to solve these problems, that required that we look very hard to specific cases and fine-tune our solutions to fit. By the end of development, we managed to reliably make all sorts of gameplay interactions, and even managed to add special powers to characters that defied these limits.

Then, another large and permanent hurdle was the accessibility and UX of the game. The human brain is not really wired to think about time loops, paradoxes or other related phenomena - at least not untrained ones. We identified early on that in order to make our game approachable by players, we had to nail the experience and expectations of being in a time loop could look like, so that players could visually stitch up the history of what has/will/could happen in their current run.

There were several experience artifacts that resulted from this effort, and I’m pretty proud of how they turned out. One big part of that pride is actually due to the process of how they came to be; The team understood the problem, but we struggled in agreeing into a possible solution. We had solutionS, but they were too hard to imagine or prototype in order to prove them practically. So I set out to organize a series of guided brainstorming / problem-solving meetings that included everyone on the team (one of the benefits of having small teams!). These series of meetings really helped me put my current design philsophy in practice, and were also a positive moment for the whole company: we felt we could solve any problem!

When I think about the solutions, what we went with was not what anyone entering the meetings was rooting for. We really found a new solution collectively, and I think that’s one of the most beautiful outcomes you can hope for as a Game Designer.

Once these experience improvements were selected, designed and implemented, the quality of the overall game grew by an rder of magnitude. It was much easier getting the idea across to new people, and thus we began dreaming bigger: maybe we had a potential hit in our hands! The kooky prototype had grown into an FPS that we really enjoyed playing, and the regular internal tournaments became really intense and spectacular.

We started seriously planning on how to reveal this game to the world…

TBC!