Leveling up the Tech in RIFT

Hi folks! Snedhepl here, reporting to you on the state of the tech union. In this letter I’ll be discussing what’s gone on in the past year, both in terms of features and internal processes, as well as a bit about what’s planned for the coming year. This will also include an in-depth discussion of our most exciting feature: true multicore support for rendering.

In the past year we’ve added a number of new features. Some of these were more visible, like the new intrepid instant adventures and assault mode. Others, such as the auction house optimizations and on-demand guild loading, were less visible. Other engineering battles, such the war on bots, the improvements to leaderboard performance, and the reporting system are only visible indirectly.

Intrepid adventures have been a huge success! There have been a few minor technical issues with them (as there often is with new features), but the improvements have been worth it. The auction house optimizations also went well, significantly improving search time.

It’s also important for us to recognize that not every feature launched smoothly; on-demand guild loading had quite a rocky start! There were a number of server crashes as well as major bugs. Despite the pain, the improvement has had visible results: the memory usage on some of servers has been reduced by approximately 25%, resulting in better server performance.

As for the Dark Arts, our bot hunting continues to bear fruit as well! Each day more bots are detected and removed from the game. While this may seem like a small issue, bots have a negative impact on the economy and removing them improves gameplay balance.

Some other notable accomplishments include the wardrobe system. While our previous system was alright, the upgrade has made it, in my opinion, the best in the business. You are now able to dye your clothing with any of 99 colors. The items you collect no longer need to be kept in your inventory to use, nor are you restricted to armor or weapon types you can equip.

Additionally this year, we accomplished a first for RIFT: the addition of a new class. The Primalist was an impressive feat, though the engineering team can’t take all the credit as the Systems Design team worked through countless iterations, responded to gameplay feedback of players and peers, and spent many nights and weekends to bring the new Calling to life.

Last but not least of the improvements have been the changes to the reporting system. A few months ago we quietly made some improvements to the system. Previously when you reported someone, the person was placed on your Ignore list. Now, Ignore puts a virtual “black mark” on the person. This mark persists cluster-wide on the offending account; switching characters or even shards won’t eliminate the Ignore. If a player accumulates enough black marks, the information gets sent to Customer Support for investigation and action. If they continue to get reported they then become muted by the system until a Customer Support agent takes action.
Before we begin to talk about engineering processes, I’d like to define a term I’m about to use: “technical debt” (or “tech debt”). This is the generic term not just for bugs, but for any technical work that’s done in a way that is hard to maintain or difficult to extend. Maintenance is important: creating a program of any kind is much like building a house… but one that constantly requires remodeling, rewiring, and new additions. It is the unfortunate reality of programming work that occasionally you don’t get to lay a good “foundation” before building a new “room.” Doing that means you just incurred tech debt. It also means there’s more work to be done to ensure that things will work properly in the future.

Every engineering department has certain methods that they use to tackle features, bugs and communication between disciplines. During the past year we’ve been ramping up the war on tech debt. This has always been something that’s important and gets done, but to improve further we’re formalizing the process. For instance, nearly all feature work is now followed by two weeks dedicated to technical debt. The improvement here is that we can focus on improving things in blocks of time. It’s been shown in a variety of studies that people, especially software engineers, suffer significantly from changing tasks mid-stream. By ensuring we have blocks of time reserved we can improve their focus on the problems and make everything even better going forward.

Now, for the most exciting upcoming feature: true multicore support! This is really huge news, and it’s been kept under wraps for more than a year! This is about the biggest change we can make to RIFT. It is, essentially, changing the way the entire game engine renders. Any bigger and we’d basically be re-writing the game from scratch.

Here’s a quick sample of results from a test today:

These shots are taken moments apart, and are a best case scenario, but it does show the potential for improvement from these changes.

Why is it important? RIFT runs in a graphics API called DirectX 9 (DX9). This allows the RIFT client to talk to your computer’s graphics card. The problem is that DX9 is showing its age and was designed with single-core computers in mind, and DX9 places a fairly large burden on the CPU. Technology has since advanced and now multiple core computers are the norm. RIFT will soon have true multicore support, which allows us to use every core on your computer to provide better frame rate and improved response time while ensuring that your CPU speed doesn’t throttle your graphics card.

“Hey, Snedhepl — I don’t understand all this technobabble gobble-dee-gook. Make sense!” Imagine you were designing a vehicle to transport people from CPUville to Graphic Card City. The people are the rendering instructions. To get them to Graphic Card City, you’d make a bus. It’s going to be the most efficient vehicle to get folks from one place to another. Several years later, the road from CPUville has now been upgraded to a four-lane highway. Is a bus still the best choice? Well it takes quite a bit of time to load up a bus until it’s full. It takes a while to accelerate or to change lanes. So we switch to cars. The car usage isn’t perfect. Upon arrival the people still need to line up properly, and it’s a lot of work to dictate how people drive. They might even crash! (Yes, I’ve been dying to make that joke here.) Cars are, however, much better now that you have those additional lanes. You can load the cars up quickly and get them zipping down the road. This is what true multicore support will do for RIFT.

Multicore support is in private Alpha and we hope to have this change out for a public beta in the near future. We’re very excited that we can now talk openly about performance improvement that’s been in the works for about a year and a half! We can’t wait to hear what you think!