Hello everyone!
The most important problem with The Fall of Avalon, one we’ve labeled as a critical issue to fix as soon as possible, was that the game’s performance wasn’t exactly… great.
Unfortunately, this isn’t a thing that can be easily fixed and improved, so we needed time… and so, for the past few months, we’ve been hard at work to make the game run better on low-end and high-end machines.
In our previous updates, we’ve been saying things like “the performance is X% better”, but since we’re pretty much done with performance improvements (FOR NOW! We’re constantly tweaking stuff!), we thought it’d be valuable to share what was actually done in the past few months in the technical department.
So, our next patch – scheduled for the end of September – should bring a lot of improvements in terms of the game’s performance, and here’s a very brief overview of the major changes we’ve implemented.
Performance Improvements
First of all –
The biggest “cost” in terms of performance in this type of game is rendering (in short: graphics). In the release version – the one you can play now on Steam – this was the main issue that kicked us in the ass. Rendering was very expensive both for the CPU and GPU.
We’ve implemented several systems to get rid of this problem, mostly on the side of the CPU – but we’ve also seen a significant improvement on the side of the GPU.
Why were we focusing on the CPU, some of you may ask, when the game was running at *only 80 fps* on your RTX 4080? Well, the problem wasn’t your GPU – the problem was that the CPU was a bottleneck that didn’t allow the game to run any better. We’ve managed to clear that bottleneck, so the high-end machines should see a big spike in performance now.
But people playing on low-end machines should see a performance improvement, too, because some of the new systems gave us an immediate boost, AND all of those improvements we’ve been implementing were also forcing us to handle various things in the game differently – in a much more efficient and cost-effective way.
Here’s what was happening – in more detail:
[h3]New Engine Version[/h3]
Even though Unity doesn’t exactly recommend this for big projects, we’re always switching to the newest available versions of the Unity Engine. We’re trying to stay as “current” as possible and utilize everything that we’re given as fast as possible. We couldn’t do it just before launch, but we did immediately after we were done with hotfixes.
This switch gave us a nice boost to the game’s performance pretty much out of the box, but it also allowed us to improve or implement several other game systems. Such as:
[h3]ECS[/h3]
We’ve been waiting to implement this for a while – and we finally did. We needed the new version of Unity Engine and a couple of months to make sure it works properly – and so now a significant part of our game runs on a system called ECS or DOTS.
The ECS, or Entity Component System, allows us to fully utilize multiple cores in a processor. A very common problem with processors is that a lot of their power is wasted on fetching data – ECS helps with that by storing a minimum amount of data for a given job in a very optimal collection so the processor can do real work instead of fetching new data (and data is separated in a way that allows “jobs” to be spread to different cores).
So, to explain this in a less technical matter, ECS keeps only the important information, and it keeps it in a special place so the processor doesn’t waste time looking for it. Also, the cores can work together better because they can share their tasks or work on different things at the same time.
This ECS technology also spreads to rendering – so now we have something that’s called a BatchRendererGroup, which keeps similar objects in a single buffer. This means that it puts similar things together in one group, so the computer can draw them all at once, which is much faster.
Also, thanks to that, culling (a system that makes the computer only look at the things you can see on the screen so that it doesn't waste time and power trying to draw things that are hiding behind walls or far away where you can't see them) can be done in a more performance-friendly way, and drawing objects requires less work (for both CPU and GPU).
[h3]Additional Renderers[/h3]
And on top of that, we’ve implemented Medusa Renderer and Drake Renderer. The first one uses the ECS rendering and BatchRendererGroup to render static geometry, which is "always" visible. That makes it the fastest way of rendering in our toolkit. Drake is very similar, but it manages dynamic assets (they can be dynamically removed or added) – this makes it a bit slower (because we cannot always ensure the best data alignment) but thanks to Drake, people with high-end machines should see a performance improvement.
[h3]HLODS[/h3]
So, most of you probably know what a “LOD” is – and for those who don’t, it stands for “Level of Detail”. Whenever you see things in games that pop into a better quality version of themselves, you’re witnessing a LOD change. This means that objects that aren’t important at the moment aren’t shown in their full quality all the time but are “loaded” when they’re actually needed. We’ve been using that, and everyone else in the industry does, but we’ve improved our approach and implemented a system called “HLOD”.
This stands for "Hierarchical Level of Detail." It is an extension of LOD that takes optimization further. Instead of just having different versions of individual objects, HLOD groups multiple objects together into clusters or hierarchies. When far away, these clusters are replaced with simpler versions, reducing the number of individual objects that need to be rendered. This results in even greater performance improvement, especially in large and complex scenes with many objects.
In our case, they now use ECS and persistent colliders. This means that collisions are stable, and there is no need to recalculate physics when HLOD switches itself. This means that rendering stuff around the player is almost as fast as rendering simplified models from afar.
[h3]Vegetation Streaming[/h3]
It isn’t probably very intuitive, but all that grass and trees that you see in the game are pretty costly in terms of performance. So, last but not least, we’ve managed to find a way to stream vegetation.
Previously, our vegetation was placed in the game world at runtime (so there was the possibility to change it at runtime), but we traded that possibility for better memory usage and lower processing power requirement. It means that vegetation is baked and streamed from your SSD (and we hope you’ve installed The Fall on Avalon on your SSD drive!).
So these are the MAJOR improvements we’ve implemented into the game in the past few months. Overall, we hope that the new patch will make the game run way, way, way better on your PCs!
Dual Wielding
One of our design goals with The Fall of Avalon is to do our best to let you play the game the way you want – this means that all playstyles you can think of should be viable. One of the core fantasies that we need to accommodate for this to work is obviously dual wielding – I bet some of you would like to play the game carrying two swords or two axes. But I’m also sure that at least a couple of you are going to create joke characters in order to test the limits of the game – playing, for example, with two shields, right?
So, good news: it’s going to be possible. We’ve implemented proper dual wielding. There ARE certain limitations regarding your movesets and we’re sure that some of you will want even more flexibility… but well, we had to stop somewhere, and we hope you’re going to like the compromise we’ve arrived at :)
https://youtu.be/CFO-UNUtLIk
https://youtu.be/3xZ4QxHMVLQ
Combat AI
We weren’t happy with the way our AI behaved in combat, and we’ve heard a lot of your complaints, so we’ve spent quite a while trying to figure out what can be done in order to improve the feeling of combat – in terms of how our enemies behave.
There are a trillion issues when you start delving into this topic – you can’t do [this], you can’t do [that], and if you do [this] then [that] will break when you move from an exterior space to the interior… and so on. The solution we’ve found is to create something we call a “combat director” and enhance various systems related to how the game handles combat situations.
So, the way it worked in TFOA on launch was that every AI was an autonomous entity. It made its own decisions – this, combined with the system of “combat slots” which decided where AI positions itself, was a pretty okay implementation and served its function. However, it didn’t make the AI very “smart” or fun to fight with.
We decided to add another brain on top of it all – a combat director – and improve the system of combat slots so that now there’s another “brain” that controls all enemies present in combat and decides which one of them should take action at any given moment (and where it should position itself in order to do whatever it intends to do).
In short, in our upcoming patch, the overall combat experience should be much more fun, and AIs shouldn’t be as dumb as they were :D
https://youtu.be/jqQ-4abr8sM
Some gameplay-related additions
After launching the game in Early Access our team grew – and among our new hires are folks who are currently in charge of making the whole map play better and making sure all dungeons are actually fun to play through.
I think we’ve improved every single dungeon in the game – but I wouldn’t want to spoil the surprises that await you! One thing I can say is that – if something isn’t dictated by context or story – we made sure that our dungeons will support various playstyles (for example stealth).
We’re also coming up with various ideas on how to differentiate some “magical” areas of the game, so here’s a sneak-peak of what you can expect in one of those places:
https://youtu.be/WNLsbbsImnw
We’re also constantly improving the game in various aspects and adding stuff that we feel needs to be included (because the game’s based on “player fantasies” more than anything else).
For example, we always knew it was going to be possible to go fishing in the game (it was one of the first minigames we implemented in the game’s prototype stage). So here’s a video of it actually working (disregard the camera movements, it’s still a work in progress):
https://youtu.be/f61lTmUcFTQ
We also knew that we were going to eventually add the possibility of buying and furnishing a house. Here’s a screenshot of a planned UI and a video of a very rough prototype of this system at work :)
https://youtu.be/lAnGmddvptA
These features may or may not make it to the next patch, depending on the time and effort required to make them feel good, but they’ll definitely make it into the game *eventually*.
Oh, and one thing that is going to make it into the next patch is a permanent wood source ;)
https://youtu.be/rd7JL363sVE
That’s it for today!
There’s a lot of stuff that we still didn’t tell you about, but let’s leave it for next month ;)
