WildStar: The Engine Interview

We take a closer look at the beating heart of WildStar with Lead Software Engineer Steve Moret.

The game engine is often an unsung hero of modern MMOs. When it works brilliantly we hardly even notice it, focusing instead on the dramatic art style, sublime musical score or excellent narrative. It’s only when problems emerge that we sit up and take notice how our favorite games are presented to us.

But what about the technology that brings it all together? After seeing the upcoming MMO for myself, I wanted to recognize this unsung hero of gaming greatness, and so I asked the folks behind WildStar if they’d shed some light on how their engine works. Whether it’s processing game rules or delivering pixels to our screens, WildStar’s MMO engine is a complex machine that acts as a window into the world of Nexus.

With Carbine’s upcoming MMO entering closed beta, we were eager to take a closer look at this mystical device. Luckily, Lead Software Engineer Steve Moret agreed to give us a rare peek inside the box and explain some of how WildStar’s engine works. From those first lines of code to more recent features, Moret explained what goes into the software that will be sitting on our desktops.

Gareth Harmer: To kick things off, what’s the name of WildStar’s engine? (We’re secretly betting Serenity here).

Steve Moret: Funny you should ask; because, while WildStar is filled with flavorful over-the-top characters, such as the beer-drinking, cigar-smoking, rock-mercenaries the Granok, our code base is filled with generic, easily repurpose-able names like Engine (the name of our engine). With creative names like this it may be a shock to know that all of the WildStar specific code sits in a project called Game. While the executable you use to connect to our servers is called Client. You’ll probably never guess the name of the Server executable (or maybe you just did). 

Now, we didn’t do this because our engineers are boring, flavorless, bit-flingers. Rather, the ideas and code that make up WildStar were/are regularly in flux. Fancy names might have needed to be changed lest they cause confusion. Additionally, colorful names would make it hard to know where a piece of code was; or on what side of an interface boundary something should exist. With clearly defined lines, like Engine and Game, it gets easier to not mistakenly put player spell casting logic into the Network project.

What’s the starting point for something as large as an MMO? Do you begin with something off-the-shelf and build out from there, or do you literally start from scratch?

Step one for us, was to decide what we could use off the shelf, and to see where it would take us. Back in 2005 we knew we had a few years of R&D time, so we evaluated a few off-the-shelf engines and, while these engines would let us show off some fancy graphics in year one, they didn’t look like they’d scale to our needs 5+ years later. We decided to spend a majority of our work home brewing the correct solution for each problem.

Luckily, a majority of our problems were already known. Many of us Carbinites had recently left Blizzard after launching World of Warcraft. To be honest, I had many of our anticipated problems spelled out for me during my interview with Carbine. It was obvious to me from day one that the entire team already knew what we were signing up for. In fact, most were excited and overjoyed to try and start over, this time, not making the same mistakes that might have been made before.

What parts form a modern MMO engine both in terms of what we see as gamers, and what we don’t?

Obviously every game is going to be different; but our technology at Carbine is broken down along 3 boundaries (many of which share components): Clients, Servers and Tools. The clients are things like our patcher, the game client itself and, strangely enough, our UI editor (since the editor is going to be used by players, we treat our UI editor as a Client application and not a Tool). The servers are made up of all the processes necessary to handle the back end of things (David Ray’s informative dev blog covers lots of this), and the tools are all the tools we use to both make the game, and support customers once the game is running (GM tools, log processing, web reporting and game access, etc).

Making up those parts are lots of smaller parts, things like an OS abstraction library, a networking library (for communicating), a graphics library (for drawing pretty things), database libraries for reading / writing data, graph navigation libraries for pathfinding, scripting languages (both server side and client side), physics simulators, input handlers, joystick routines, localization code and more. Most of these aren’t directly recognizable to the end user, certainly they appreciate that their game draws pretty and that their text is in their specific localized language but, for the most part, they’re oblivious to what is happening or why.

Some of the parts I’ve listed above are combined to form even more complex layers. This is where noticeable features begin to emerge. For example our graphics library may handle drawing polygons to the screen but our model system sits atop that and handles animating skinned models, and our costume system sits atop the model system and handles swappable textures and geometry on those models. 

Gluing all those little and medium sized parts together while adding in a lot of game content is what the game layer is filled with. This layer contains all the logic to give you XP when you complete a quest, or to make sure a valid path exists between you and the monster that you wish to do a flying leap toward, or to make sure your avatar is missing a weapon when you get disarmed by your opponents.

These game layer systems exist in forms across each of the three components (clients, servers, tools). Sometimes in slightly different ways (for example a server has no idea what language a player is playing in, nor does it even have access to localized text) but some version of the Quest system exists on both the clients, the servers and the tools.

When building an MMO, what comes first – the client or the server?

In my opinion, it better be both. But in our case we had a simple terrain and model renderer first (about a month or two into development); a couple months later we had a basic server that let us run around and see each other (needless to say this was when we received our first cheater). We then started layering in all of our complexities. At Carbine features are always added to both the client and the servers at the same time, usually by the same programmer. Fun fact: we still maintain our standalone server-less Client; our artists use it to preview their art without having to connect to a server.

Next Up: Tracking Development and Fascinating Features on Page 2 ->

« Previous 1 2 3

Comments

Post Comment
Different and intriguing take
# Apr 29 2013 at 8:33 PM Rating: Decent
Very interesting hearing all these details about the making of the game. We usually don't hear these kind of details. Thanks for doing the interview.
Please pay attention to the man behind the curtain
# Apr 22 2013 at 9:57 AM Rating: Decent
Avatar
***
1,549 posts
I totally agree with you, Anhrez. As players, we rarely appreciate just how much work exists in simply making our game world exist, when the design and content is all we can see. Modern MMOs are a marvel of evolution from Wolfenstein to now. Each generation adding complexity to the generally-accepted core of "what engines do".
____________________________
Super Wiki Ferret Emeritus, obsessive/compulsive wiki editor
Really interesting.
# Apr 22 2013 at 9:16 AM Rating: Decent
Avatar
38 posts
When we are wildly consuming every Bit of information about the latest game and how colourful it is, we often forget that it is still a piece of software with millions of lines of code behind it, this interview perfectly brings those worlds parallel for us to see what bridges the art of the game and the code behind it together. Fantastic Interview Gaz, it felt really natural and Steve done a great job of keeping the code jargon easy to understand.

Edited, Apr 22nd 2013 11:18am by Crainey
Great way to bring the techie talk!
# Apr 22 2013 at 7:14 AM Rating: Decent
6 posts
So rarely do we get to look behind the curtain at the effort being made for the 1's and 0's, this Q and A interested me as a techie and still increase my hype for the game.

Well done!
Post Comment

Free account required to post

You must log in or create an account to post messages.