BUILD | TECH ADVICE
Time and Motion
by David Jefferies Black Rock Studio
NETDOG TECHNOLOGY NetDog v1.5 CLIENTS Available on request HOST PLATFORMS iPhone, PC (Linux/Mac/Windows), consoles TBA INTEGRATION WITH Vision Engine PRICE available on request CONTACT +01 415 341 6796 Designed specifically for handling massively multiple online games, NetDog is an out-of-the-box networking solution. It uses a patent pending network architecture to load balance clients and servers to ensure cost effective operation.
The NetDog code is now integrated with the Vision game engine
www.pxinteractive.com There are four main components: a world builder; networking infrastructure; performance optimisers; and developer tools such as object and event managers, debuggers and system monitoring tools.
REPLICANET TECHNOLOGY ReplicaNet v6 CLIENTS DAS, Freeverse, Rocksteady HOST PLATFORMS PC (Linux/Windows) INTEGRATION WITH None PRICE From $6,500 CONTACT info@replicanet.com
One of the first games to use ReplicaNet was Urban Chaos
www.replicanet.com Using a distributed object model of computing, ReplicaNet is an object oriented C++ networking library that enables high performance online games, an approach that makes load balancing easier to carry out and typically 48 | OCTOBER 2008
results in lower bandwidth requirements. It also contains a scripting language – the Replica Object Language – a simple class definition system to highlight the areas in a class that should be accessed.
A COUPLE OF WEEKS ago, just as our sister project Pure went gold; we produced the build for our First Playable milestone. The team has recently expanded to over 60 people and for three mornings in a row I walked into the office to find the nightly build had failed meaning we had to delay our morning review of the build for a couple of hours while it was fixed. Our build system consists of a rack of build servers that perform rolling builds throughout the day and a clean build at midnight. When a build is complete it goes through an automated testing procedure which loads each level and records metrics such as texture usage and framerate. It publishes these metrics along with a screenshot of each level on an internal website. If the test was successful then the build gets published in a ‘verified’ folder. Each of us has a GUI called Moses running on our desktop which we use to get the builds. We can choose between getting the very latest data and getting the verified data, which is a bit older because it’s been tested but is guaranteed to work. Along with the game data comes all the tools and exporters that were used to build that version so you are guaranteed to have a fully working build environment. And just for good measure we have a little light next to the clock on our desktop that goes red when the build fails so someone can quickly take a look. When an artist is ready to check in an asset they look in Moses to make sure they have the latest verified build. They build the asset using the verified build environment and check that it works in game. If it does then they are free to check the asset into the repository. We’ve invested a lot of time and energy in this system and in general it works well, but when the pressure was ratcheted up on the week of First Playable it failed us. Each day it had failed in exactly the same way; an artist or designer in our ever expanding team had created a new asset and forgotten to add one of its files to the repository, this meant it worked fine on their local machine but failed on the build servers. Now we’ve improved our tools so there is a visual indication for the artist or designer when they’ve forgotten to add a file to the repository. We’ve been improving our build system incrementally like this for years because as the team grows there are always new ways to break the build. The only sure way to avoid that failing feeling is to monitor every breakage and make it a priority to address the root cause. www.blackrockstudio.com