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 ->