Looking Ahead; Status of the Engine Version Upgrade

Initially we’d planned on talking about the various things planned for the whole year, however, given the long-ish Unreal update below, we’ve decided to split this information into a few parts so we can give you all the information without causing you severe retinal damage or wearing out your mouse wheel…

An Update on the Unreal Engine Upgrade

We’re very excited to speak more openly about this, but there a couple important points to clear before moving forward.

1. What’s being performed is an engine version upgrade – it is not a “new engine”. The team has been spending several months so far upgrading the version of Unreal Engine 3 (UE3) that APB was originally built on (the February 2008 build), and updating it to the 2013 build of Unreal, which is the most recent post-Gears 3 version of UE3 (and in fact it adds another 2 years of enhancements after the last Gears3 release). The engine fixes and improves a lot of systems throughout the game. However, this is a very complex upgrade because the job so far has consisted of stripping out and rebuilding from scratch many of the custom-built APB engine systems with newer Epic implementations of the same, and merging in the massive amount of changes the engine has undergone during the last 5.5 years. But this also has led to some unintended consequences (see below).
2. When the update initially goes live, the game won’t look too different. This is because the first order of business is getting the game up and running again “as is” while using the updated engine in the background. Now, being a more up to date version of the Engine, this means it still has the potential to bring some nice visual enhancements, as well as allowing us to start working on bringing in other new features to APB seamlessly (for example dynamic lighting for car headlights, subsurface scattering for skin and other materials, and other potential future visual enhancements). These will take additional time and will not be present at the very first release, but by completing the Engine update we at least give ourselves to ability to add these later on at pretty rapid clip.
3. Timeline for deployment of the “Engine2013” game to the live game environment is still to be decided. At the moment our end-of-Q1 2014 is actually NOT going to be far off for the first end-to-end QA version, keeping in mind the QA version of the engine doesn’t entail everything that will be included in a live version. So needless to say there will NOT be a public version available next week. But the last 6 months has certainly seen an incredible amount of changes to the entire game engine. As soon as QA has signed off on the insane amount of modifications from the last 6 months, then we will come back with a new time estimate that we can share on the blog.

The Unreal update is progressing at a steady pace, and while we run into a few challenges here and there, nothing so far has proven to be insurmountable. As with any complex project, certain changes has taken much more time than originally anticipated. But still, nothing has come up that looks like it could stop the process from completing successfully.

Pandora’s Box

Ok, with that out of the way, let’s talk about the Unreal update in more detail to give you an idea of the complexity of the undertaking.

As you may be aware from last year’s blog post on the subject, updating the APB engine is a massive undertaking. These problems are exacerbated by the fact that APB took Unreal as a base and then built entirely new, vastly complex systems on top of it to support the game Realtime Worlds wanted to make. This was also done under the assumption that they’d never need to update Unreal again. As you can imagine this means updating the Engine is a veritable Pandora’s Box of potential issues, which is essentially why it is so very difficult to estimate when it will be done.

The inside of Pandora’s box might actually look like this…

This one is less "Pandora's Box" and more "Arc of the Covenant"

Pan’s Labyrinth:

Let’s illustrate the complexity of the update process with a practical example of a recent problem we ran into while converting the character system.

• In order to scale a character in APB, we use a non-uniform scaling system that allows us to change a character’s height and weight without causing strange behaviour in other systems – such as animation. 
• So far so good, except the upgraded unreal engine does not inherently support this behaviour.
• Let’s break this down so we can further illustrate the problem:
• In APB, bones in a character’s skeleton can scale (get larger or smaller), rotate (change angle) and translate (move position).
• In the default Engine, Epic uses a single value for the scale. This means a bone scales in all directions equally; i.e. a square becomes a bigger square.
• In the old UE3, this was combined with the rotation and translation and stored in a matrix.
• In the new UE3, Epic stores the scale, rotation and translation for each bone as separate values.
• We still need to be able to scale a bone in perhaps one direction only; i.e. a square becomes a rectangle (this is non-uniform scale).
• We need to do this as we stretch the character’s spine and arms to make them longer; i.e. we want to lengthen the arms but we don’t want to make the arms thicker.
• We can carry on storing the scale, rotation and translation of each bone separately, but we need to make the scale multiple values rather than a single value.
• However, there are some operations on bones which cause the mathematics to break in such a way that we can’t store the result simply as a scale, rotation and a translation. We need an additional skew value.
• If you store the scale, rotation and translation of a bone altogether in a 4x4 matrix, then the mathematics don’t break. Matrices can handle skew (in the old Epic code, bones were actually stored as matrices in the first place, so we didn’t have this problem).
• So the idea is that if we need to perform an operation which would cause the mathematics to break then we convert from scale, rotation and translation into a matrix.
• Once converted into a matrix, we can no longer perform any operations which work on an individual element of the bone, but we’ll be fine as long as we don’t have to perform such operations.

So that is all well and good as theory but the practical solution can be very complicated as it starts to get into some pretty heavy maths, here is a snippet as an example:

If you're looking at this and thinking "That's easy, fools!" please submit your CV to Reloaded Productions!

There is a Light at the End of the Tunnel

As you can see, updating the Unreal Engine is a very complicated operation (the above example is just a small snapshot of the sort of things we are dealing with). However, the purpose of this information was not to dishearten you - we are still making good progress after all – rather it is to give you some context to help you understand why it is quite difficult for us to say exactly when we’ll be able to deliver it: but we will deliver it and once we do we’ll hopefully be able to expand APB in all sorts of interesting ways.

So at this point we’re planning on proceeding with QA for the current build, fixing the outstanding issues, and forging ahead with what has turned out to be one of the biggest—but potentially most important—projects we’ve taken on since bringing the game back online in 2011. You can look forward to further posts with more milestones as we cross them, and more granularity from us on how that proceeds. As soon as the scope comes into clearer focus we’ll also plan on posting an updated timeline.

The Year Ahead

Please join us next time, when we’ll take some time to talk about some of the other exciting changes we have planned this year - things like: Consumables / Deployables & Mini-Games; Clan Leaderboards; New Contacts and Turf Wars.

-          The Reloaded Team