TransGaming Transmission: A Closer Look Inside the EVE Online Mac Client

o/ Capsuleers!

I'm Gavriel State, Founder and Chief Technology Officer at TransGaming, guest-blogging for CCP to tell you a bit more about the process that we use to enable EVE on the Mac, and to outline some of the challenges we face and overcome every day, to bring you the best EVE Mac experience we can.

As most of you know, EVE on the Mac runs with the support of TransGaming's Cider technology. Cider provides the Win32 and DirectX APIs that the game is built with, which allows EVE to be easily released on both Windows and MacOS X simultaneously. While this is simple to say, it belies both the enormous complexity of the technology itself as well as the close cooperation between CCP and TransGaming that makes the process work.

Typically, when we at TransGaming begin to look at a game, it goes through three major phases: Evaluation, Production, and Maintenance:

Evaluation

At the evaluation stage, we get our first look at a game, and start to analyze it for compatibility with Cider and MacOS X. This analysis usually takes the form of actually getting the game running in a prototype state, looking at the graphics calls the game is making, doing performance testing, etc.

Production

Once an evaluation is complete, TransGaming's Production process begins. The Production team creates a build environment for wrapping a title, so that Quality Assurance teams at both TransGaming as well as the game's developer can begin getting game builds to start identifying problems that must be fixed. The Production team also handles issues that are outside the scope of the Cider portability engine, such as installers, patchers, and integration tasks that are specific to a particular game.

When an issue is found by one of the QA teams it is then tested to determine whether it is a general game problem, or something that is somehow specific to the Mac version. This is critical, because bugs that are on both platforms can only be solved by the game developer themselves. It's also a difficult job, especially with bugs that only happen sometimes. As you might imagine, having a series of concrete steps that can reliably reproduce a bug makes it much easier to solve.

When an issue has been identified that is specific to the Mac, TransGaming's R&D team becomes responsible for tracking things down and fixing the problem. This is no easy task, and requires developers who have broad knowledge of Windows and MacOS, DirectX and OpenGL, and who really really enjoy debugging complex problems - if you think that describes you, please let us know! 8-). Every change that the R&D team does to the core code for Cider is rigorously examined with a two-level code review process, one review by peers on the team, and another by a lead developer who is intimately familiar with the code in question.

In some cases, the problem turns out to be not within Cider, but with code at the Operating System or driver layer. At that point, we file bug reports with Apple's 'Radar' system, and try to provide as much information as possible to them so that they can reproduce a bug. To help with this process, we often use an internal tool which we call 'Snap', which records all D3D graphics commands used within a frame of a game into a file that can be played back later, separately from the game itself. This is especially useful for us when complicated steps are required to get to a point in the game where the problem occurs, so that the driver developers don't have to actually play things through to reproduce a bug!

We communicate with Apple, NVidia, and AMD about radar bugs affecting Cider based games on a regular basis. Once they understand what's happening, they will sometimes provide feedback letting us know how we can avoid an issue, pending a proper fix in an upcoming OS release. Sometimes, the workaround for a bug is not something that is appropriate in the general case, but instead makes sense only for that particular game. When that happens, we create game-specific code changes that we maintain separately for the life of the game.

Occasionally, we come across functionality that a game requires that is not available in the OpenGL APIs used by MacOS X. To alleviate this problem, TransGaming is heavily involved in Khronos, the organization that defines the OpenGL standard, where we work alongside companies such as Apple, Intel, NVidia, ATI, and Blizzard to extend the standard with new functionality. We're very proud of our efforts within Khronos, where half a dozen significant updates to the OpenGL specification have been made since we joined in early 2008. Many of the features in the updated GL standard are already available in MacOS 10.6, and more appear with each OS update from Apple. The presence or absence of a given OpenGL feature are often what drives the minimum OS requirements for a given game.

Maintenance & Branching

Once a game is ready to be shipped, it enters a lock-down phase, where the Cider engine code is branched so that changes being made for other games being worked on simultaneously don't affect it. From this stage forward, only changes specifically targeted for that particular game are made, and a third level of code review is put in place for any such changes.

After a game ships, if problems are found by users, developers will often want to issue patches to the game. TransGaming's Production team provides developers with the tools required to create and deploy these patches. If changes are needed on the Cider side for this process, they still only come from the locked-down code branch.

EVE Online and Rebasing

Unlike most games, even most Massive Multiplayer Games, EVE Online has a tradition of continuous technology updates. Over the past 4 years that we've worked with CCP, their team has made dozens of significant changes such as the Trinity graphics update, switching compiler versions, stackless IO, planetery interaction, and much more. These "scale up" updates are significant in scope and they can't be handled in a normal maintenance patch for Cider.

Instead, every time there has been a major technological update to EVE, the game has essentially gone through TransGaming's entire cycle above, using the very latest and greatest version of the Cider engine available at the time. We call this process 'rebasing', and we try to keep the process as smooth and invisible as possible, even though under the hood major changes have happened.

One such rebasing took place with the release of the Trinity graphics engine on the Mac. This was very complex work for the TransGaming R&D team to support, requiring an extensive update to support the Shader Model 3.0 graphics used by EVE, and the D3DX binary shader effect format that encodes those effects.

Another rebasing occurred with the support of the in-game browser component. This was an area where TransGaming's Production team took the lead in integrating the Mac version of the Chromium/Awesomium with EVE, allowing the Win32 side of the game to call through directly to the Cocoa-based Mac code. When you run the in-game browser in EVE on the Mac, everything that happens on the browser side happens entirely in Cocoa code, which is why the scroll bars and other UI elements in the Mac version of the game look properly Mac-like. After this initial integration, we provided CCP with all the tools required for them to continue to maintain and update the Mac browser component in the future.

A third, more invisible rebasing took place this past August, including graphics and other updates that will be necessary for support of upcoming features of new EVE updates that are still under development.

Beyond these major updates, we continually work with CCP on other issues that come in through both CCP's testing as well as your bug reports.

That's all for this post. Stay tuned for an upcoming post with more information about the Mac client, including a deep technical dive into performance analysis and optimization using Apple's Shark and GL profiler tools.

 -Gav