Greetings, medievalists!
Have you checked out our latest dev playthrough that covers all the important stuff from Updates
13,
14, and
15? It’s an hour-and-a-half deep dive that explains key features, answers some burning (hehe) questions, and even talks a bit about the topic of today’s MMT.
[previewyoutube][/previewyoutube]
If you are a modder, check the
Mod Showcase Call section in the video.
We plan to make a video where we play your mods and showcase them all over our social media platforms. We're looking for some interesting, cool and/or useful mods. Whether it is just code change or a new 3D asset integration, we are open to anything as long as it follows our
Modding Policy.
You can
put your mods on the Steam Workshop and showcase them there,
join our Discord and share them in
⚒modding or
mod-showcase channels. The submission deadline for this is:
July 14th 2025. We'll go through the workshop and do some playing of the stuff that is already there. And don't worry,
this will not be a one time thing - we plan to do this when we can and when we see a bunch of new mods. So take your time - the most important thing is to have fun.
But let's tackle optimization now.
Optimization is a big challenge for our game, especially when it comes to the mid to late game. Once you get many settlers, animals, and add enemies to them... it takes a lot of processing power to handle all of that. So, it is more CPU-bound than it is GPU-bound. This doesn’t mean that a beefier CPU would handle the game better. Due to the ever-growing complexity of Going Medieval’s systems and their constant expansions and interconnections, the way the code was initially written left a lot to be desired.
We wanted to have all the bigger stuff in and functional before we revisited the foundation and untangled the code and, in turn, made playing our game a much faster, smoother, and more enjoyable experience. This, too, will be a bit of techy talk, but we hope that you’ll get some better understanding of game development even if you are not into programming.
Early in development, our focus was on fun: adding features, systems, and content to make Going Medieval the best colony sim we could. But over time, all that growth made things... well... a bit sluggish. It came to the point where loading the game via some of your reports took over 2 minutes. And you send those a lot (and we greatly appreciate it)! But you can also see how a lot of our time would be lost just to loading. The Unity engine wasn’t helping here, either. Starting the game via the Unity Editor to test something would take over 40 seconds just to reach the main menu. In order to even get to the in-game lag and mid to late game performance, we had to fix the loading time first.
[previewyoutube][/previewyoutube]
We used built-in tools (like
Unity’s Profiler) to track down which parts of the game were hogging resources. Think of it like using a map to find the biggest traffic jams in a city.
We also tried out more advanced tools (some
free, some
not), and even built a few custom ones just for this job.
That helped a lot, because we discovered a hidden culprit - Unity was reloading everything from scratch each time we pressed Play. So we changed how that works under the hood and cut that time down to just 5 - 10 seconds.
Another thing that became evident during this process was that the game was creating too much temporary garbage memory, which the system had to clean up constantly. This, in turn, caused hiccups and stutters in-game.
So we rewrote parts of the code to be less wasteful. Fancy but inefficient tools were replaced with simpler ones. We focused on reusing existing objects instead of throwing them away and making new ones for identical purposes. We also optimized how the
strings within the game are called and processed.
It’s pretty obvious that Going Medieval is heavily dependent on
loops when it comes to coding. Basically, loops are how the game says: “for each settler, do this.” But not all loops are equal.
We found ways to make them faster, especially in situations that were being repeated thousands of times per second. In short: simpler code, better speed.
Another thing that clogged our code was events. No,
not those. We are talking about
events in the code. In programming, “events” are a way for parts of the game to talk to each other. Imagine your settlement in the game. When something happens - like a building being constructed or a settler getting injured - there are many systems that need to know about it. For example: the UI wants to show a notification, the audio system might want to play a sound and the AI might need to react in some way.
Now, each of those steps could be checked individually, but that would also be sloooooow. That’s why we group everything together into an event which basically announces that in one function, and anyone who “cares” can listen and respond.
Events are powerful, but they can become a mess if not handled properly. If something is listening to events but never stops listening, it can hang around in memory longer than it should - even after it's no longer needed. This bloats the game’s memory usage and slows things down. We fixed those leaks, cut down on unnecessary messages, and streamlined communication behind the scenes.
Another thing that improved the fps of the game significantly was how humans and animals perceived things in our game. Every time a character in Going Medieval (like a settler, animal, or NPC(internally referenced as agents)) moves, the game has to update what that character can see or sense nearby - things like enemies, items, or other characters.
Previously, we did this by scanning the entire area around the character, like spreading ripples in all directions. This method (called
flood-fill) was simple but slow - imagine walking through a forest and having to inspect every tree, bush and rock, every time you take a single step. Now, imagine all the people around you doing the same thing. That’s how much unnecessary work the old system was doing.
Now, instead of checking everything within the area, we only look at the certain radius of an agent - what's newly entering or exiting their range of vision, but not what is inside or outside of it - just the radius “edge”. Here is an example of this behavior:
[previewyoutube][/previewyoutube]
This small change made a big difference - the game should be much faster, and no one in the game world notices the difference - except your framerate.
All of these things made the game work better and load faster. There are a bunch of tips and tricks we applied that significantly improved performance - you will not notice those changes visually, but you’ll probably feel it. Thanks for your patience. And thanks for reporting the bugs and sending us saves via F10. That helped us a lot. Hopefully you’ll see it in-game soon, as the idea is to push this to experimental some time this week. Let us know how it goes.
Bonus: Yesterday was our early access birthday and because of that we are giving away 5 keys for the game on
Bluesky and
Twitter/X (5 for each platform). If you have a friend that uses those platforms, they might want to give it a chance. Until next time…
Stay medieval!
Foxy VoxelDiscord Reddit X/Twitter Bluesky TikTok Facebook