TekTalk - Understanding Engine Updates
RuneNation
Join our Learner PvM Discord
Earlier this week we released our latest update for RuneTek, the engine that powers RuneScape - version 950 to be precise! This update included a lot of great things, from kicking off the Vulkan Open Beta to enabling greater furniture limits for the Player Owned House and even fixing some long-standing pathing and combat bugs.
Over the years you've likely seen one JMod or another acknowledge an issue but state that it will "need an engine update to resolve" and therefore can't be hot- or coldfixed, or perhaps even properly addressed for a little while.
But what exactly is an engine update and how is it different to a regular game update? That's what we wanted to take a deep dive into today while also highlighting the great things that engine version 950 introduced.
As always, we'll be keeping this accessible and be looking to simplify certain explanations without using too many technical terms. Just keep in mind that there is often a lot more complexity hidden behind our explanations than may at first be apparent!
Index:
General:
Let's begin with the basics.
The RuneScape you know is comprised of three separate things:
- The Game Engine (RuneTek)
- The Game Client
- The Game Servers and online components
Each of these can have new releases issued and be updated in their own way - for example, we can release server updates without affecting the game client or engine just as well as we can update the client or engine without modifying anything drastic server-side.
From a development perspective, the RuneTek game engine uses its own separate code repository and therefore has its own separate releases.
Due to the significant impact that issues within the code of an engine can have on the game's stability, engine updates happen less frequently as they spend more time being tested for stability. Game engine updates are "lower level" (see our other blog for more info on this), which means that they can impact players differently based on your hardware.
This naturally also means more extensive compatibility testing is required across various different configurations. Additionally, RuneTek supports both RuneScape and Old School RuneScape so we have to be extra careful that any changes we make do not have an adverse impact in a different game!To help visualise where the engine sits, we're pulled together the below graphic:
On the flip side, we can update the game client more regularly because any issues found within it are generally of a lower severity and can be addressed much quicker. However, it is precisely that low level access we mentioned that the engine provides which is sometimes necessary to address the behaviour of game fundamentals - like how a character moves through the world or the capabilities of a system such as animations.
To recap: An engine determines the fundamental rules of how the game world can behave, while a content change will define how things behave in that system. The engine may define the way in which damage is handled between a player and NPCs, but content defines that a boss' base attack will hit for X damage.
Vulkan Beta
Let's get into the launch of the Vulkan Beta, as this is the one that will affect virtually everything in RuneScape. We explained exactly what Vulkan is in last week's blog, which you can read here.
In case you missed it - we kicked off a Vulkan open beta this Monday, and you can now play RuneScape using Vulkan instead of OpenGL! It being an open beta, this is of course only the first step of a longer journey, but we've been hugely encouraged by the very positive initial reactions and success of the rollout.
We've observed that most players are experiencing improvements beyond our expectations, especially when it comes to in-game streaming performance! Of course, given the complexity of this release, we weren't expecting it to be perfect from the beginning.
This is also why we have opted for the longer open beta approach, but finally having real-world results is a great step in helping us understand how Vulkan is generally shaping up for RuneScape. We're getting great data on crash reports that we are jumping on, while also continuing to monitor and investigate issues raised through our community and support channels; we are carefully evaluating all of this as it comes through. Any issues that are encountered while playing using Vulkan and that are 100% blockers that affect everyone will of course be prioritized for hotfixing or patching.
As mentioned in the section above, however, updates for engines happen less frequently than for associated game clients. With that in mind, our main objective is to establish a stable baseline for Vulkan that works across the board and that is better than OpenGL in every way, rather than focus on adding in new features.
Our current timeline for this project is to release one major update for Vulkan in the coming months that would address the bulk of the problems that we've identified as major and must-fix, though we don't yet have a firm date on when this will be.
Overall though, we would like to very much thank everyone who has already jumped into giving Vulkan a try and has helped make this first open beta stage a success. We can't wait to keep iterating towards a full launch of Vulkan!
Player-Owned Housing
The Player-Owned Housing update was arguably one of our most successful launches this year and overhauled the entire way that player-owned houses in RuneScape are built and engaged with.
Implementing this naturally required its own engine update at the time, but we were keenly aware of one particular limitation with the system: the limit on the amount of furniture items that players can place within their house.
We knew that we and the players would want to increase this, but the underlying technical work to do so was not insignificant.
The crux of the matter was this: As we tested increased furniture limits, the game's performance and stability degraded in equal measure. The more items, the greater the impact.
By way of explanation:
Our new housing system gives players much more freedom to build and decorate their homes compared to previously. By switching to a grid-based placement system we drastically improved the customizability of a house. However, introducing that freedom also presented a technical challenge: the more furniture and wall sections a house contains, the more work the game must do to render it.
Before this week's engine update, every piece of furniture and every individual wall section in a Player-Owned House was added and rendered separately. Each object required its own "draw call", which is a request from the game to the graphics hardware to render that object. Our object batching system that reduces these draw calls to improve performance couldn't be used. While this worked reasonably well for smaller homes, performance could fall significantly at higher view distances where larger homes or multiple houses within a homestead were visible (including the hundreds or even thousands of separate objects in them).
Which was a huge shame, especially as we really loved watching the ambitions of Gielinor's talented architects evolve and grow!
The performance impact became even more noticeable in Homesteads, where multiple players share an island. Given enough draw distance and with several detailed homes and their furnishings potentially visible together, the number of individual draw calls could rise dramatically!
So how could we enable players to build bigger houses with more things in them... without sacrificing performance?
To address this, our most recent update enabled the use of our draw call batching systems for Player-Owned Housing. This change means that walls and furniture that are within each 16×16 section of the grid/plot are grouped into larger models, which allows an entire section to be rendered with a single draw call instead of drawing every object separately!
This is the same "draw call batching" approach (also referred to as "model batch rendering") that we already use across RuneScape's surface world: Nearby pieces of the environment are combined to keep draw calls lower and rendering costs manageable. Applying the same principle to Player-Owned Houses greatly reduced the workload of displaying detailed builds, particularly at longer view distances!
Combining models also opens the door to more optimizations, such as a distance-based visibility system that exists on the RuneScape Surface. Such a pop-in and pop-out lodding (LOD = level-of-detail) system (more insight on that here) reduces the amount of geometry the game needs to process and render at long view distances. It is particularly effective in Homesteads, where several heavily furnished houses may be visible across the island at the same time.
Together, these changes have allowed us to increase the amount of furniture players can place while still delivering a smoother performance in both individual houses and shared Homesteads! You can look forward to us enabling this new limit in the near future!
Pathing and Combat Fixes
We've made some tweaks to our movement abilities in this update, and even have some before-and-after clips to show the results!
There's a small improvement to target cycling to help it feel more reliable during combat. Moving between nearby targets should now behave more consistently, making it easier to stay focused on the enemy you want without the system feeling stagnant or unpredictable.
This change will also allow you to correctly target a newly spawned enemy on the first tick. Previously, players often had to constantly move and spam Target Cycle to successfully tag the NPC on spawn!
We've also tweaked how our player pathing chooses its route from one tile to the next. Based on previous pathing logic, your client and the server could sometimes disagree on which way your character was facing..!
This mismatch often led to players' movement abilities sending them in a direction they did not intend, most notably after completing an L-shaped pattern route. That mismatch has now been reduced, so movement should now appear cleaner and more consistent!
Finally, this week's engine update implemented some changes that will affect Surge and Dive chaining. However, we're still ironing out some NPC targeting issues with this one, so treat the below video more as a preview than anything else! Currently, your character can sometimes end up looking slightly out of sync with the movement itself, which makes chaining abilities such as Surge and Dive feel a little off.
We've looked at addressing this with some work that helps your character face the way you’d naturally expect during and after those fast movement bursts, so the action reads more cleanly on screen.
In the below video, pay special attention to the second click that is between the arches but is not properly acknowledged.
Avatar Animations
Another very significant update that launched earlier this year was the update of the player Avatar. The run-up to this involved, you guessed it, a fair amount of engine work!
This week's engine update doesn't implement anything that is immediately noticeable for you as a player, but it introduces some cool things that improve what is possible when it comes to working on the player avatar.
We're always looking to strike a balance between quick engine iteration and flexible content development, without creating maintenance headaches for content designers when using engine systems. Put differently, if we update the engine too often, it can become cumbersome for the content design teams to keep having to adjust to the changes. But if we don't update the engine often enough, the content design teams may have to deal with hurdles for longer than anyone would want. The timing of these avatar changes falls into that balance.
This week's changes allow our content design teams to more easily run different types of animations through the chat head dialog system and importantly split these between male and female face types. This will allow female face types to have their own animations that are not bound by the male face type, as was previously the case.
Doing this work via an engine update is especially preferred in this case as it will allow the content design teams to make such changes in a more long-term manageable way. This will better bridge the gap between the engine API and the data structures that content designers use to manage the different animation types that NPC and player entities can play.
We can't yet pin a time for when the update that makes use of these changes will launch, but maintaining our engine in this way allows us to be ready for such a delivery and we're aiming for the female chathead animations to be ready sooner than later!
Performance & Tick Rates
One of the biggest impacts that engine changes can have are when it comes to not just how the game performs, but how it feels moment to moment.
Some players have on occasion pointed to RuneScape's tick rate as being a culprit when it comes to feelings of sluggishness or unresponsiveness. While this blog focuses on the RuneTek engine (a local client-side technology) and tick rate is generally server-side concern, we do think it is nevertheless a good opportunity to speak to it as part of wider performance improvements.
As a quick refresher, RuneScape's game tick operates as a 600-millisecond (ms) window where all client inputs are read, the game world is simulated, and the results are sent back to the client to display. Using movement as an example: when you click to move on your client, that request is sent to the server to be processed in the next available tick and you only see the result of that movement once the tick has completed and the server sends back an update.
Especially in this simple example, it's easy to understate how much processing went into that tick. Think of any achievements that you may have triggered progress for, any health and stat regen you may need, any NPCs that may have attacked you on your way, any messages you may have received from friends or in-game, any objects that may have appeared around you, any players who have come into view, and much more. Especially when you consider that may be done for up to 1499 other players.
In short, your game updates every 600ms and each piece of information (as non-exhaustively listed above) can only be updated (the change displayed) when that tick occurs.
Much like the fact that RuneScape is, at its core, a grid-based game and the entire world operates on these grids, all of its content has been built around the principle of 600ms intervals. While we did explore tick rate changes in the past, showcasing some of this explorative work at a previous RuneFest after internal experiments did show some interesting results on a very small scale, the actual implementation across the full breadth of the game simply wasn't feasible because virtually everything would need to be adapted to the new tick rate.
Say, if we reduced the tick rate to 100ms, a boss would start attacking six times quicker. And merely slowing it down would not be sufficient, as it fundamentally would change how the game feels.
Beyond that, to change the tick rate would not just have an enormous technical impact across the entire game (read: initially make a lot of things quite buggy), it would also challenge part of our fundamental identity!
A significant tick rate modification could be a change felt on the scale of the first introduction of the Evolution of Combat (EoC) - that is to say, we expect a lot of our players might not fully appreciate it and it wouldn't necessarily feel like the RuneScape they knew anymore.
Changing the 600ms tick rate would be a hugely significant undertaking not just on a technical level, but also due to the impact of such a change on the identity of RuneScape, and it's not something we're currently exploring.
The good news is that we don't believe that the tick rate is the only lever we can pull in order to change how the game feels from a performance or responsiveness angle. As a very basic comparison, Old School RuneScape runs on the same 600ms tick rate, but players have reported that it does feel different and more responsive.
There are a variety of things we are investigating to make things feel more responsive - as a quick example, we know that some worlds run slower than we'd like, and that increased player populations on certain worlds can inject a level of lag into the player experience.
Investigations into improving how worlds operate technically could offer significant improvements here - internal staff testing is already looking promising! On the engine side, changes like today's Pathing and Combat fixes demonstrate "simple" tweaks that can be made within the engine that make the overall game feel much more responsive and performant.
Of course, we're not going to stick to the simple solutions, but our teams are continuing to push the boundaries of what even we were unsure was possible within the engine.
That's it for today! Thanks, as always for joining us on another deep dive into the nuances of RuneScape and we hope this has been helpful in bringing you close to the underlying technical details that underpin RuneScape. Do join us on our Reddit and Discord threads to chat about this topic!