This blog will focus on technology’s perspective of our grayworlding process. Before we get going, here is a final screenshot from the game showing what all this work leads to:

For the sake of simplicity, we had decided early on that the player would either be strictly a character in the zone or a starship in the zone. We had space combat (starship) zones and ground combat (character) zones, but never a mixture of the two. We wanted to avoid all of the technical, scale and game balance issues that we would need to face allowing characters and starships together in the same zone. Unfortunately, while each mode was distinctly fun on its own, playing the avatar in separate modes made the game feel like two games. Design had to deal with trying to solve this problem for several milestones and through collaboration with the publisher, we agreed to take an additional milestone to work through all of the issues and create what we called “hybrid” gameplay.

The Forbidden Core was the proof of concept for our hybrid gameplay and represented our first zone that had a mix of both interiors and exteriors. Implementing the design team’s vision for the Forbidden Core and its related gameplay represented two challenges for the technology team. It was our first attempt at pushing an architecture asset entirely through the greyworld process, and it was our initial use case for the PvP “conflict zone system” gameplay.

The idea for the Forbidden Core was a cleft asteroid the size of a playable zone joined by a mining base in the middle that they player can land on.

At the time we decided to tackle greyworld implementation of the Forbidden Core, we were still developing key technologies necessary for supporting large-scale assets. The largest starship zone asset created at the time was a about the size of a small capital ship (destroyer), and the largest character zone asset we had created wasn’t more than about 10 rooms (the interior of the destroyer). After reviewing the initial concept with all of the key disciplines, and giving the green-light in terms of technical feasibility, we now had numerous questions to answer.

What is the size of the largest object that can be supported by the engine? How do we avoid rendering the entire asteroid (or mining base) assuming we can see a small part of it? How do we deal with collision for such a large asset? How do we deal with rendering the exterior when we’re in the interior? How were we planning on dealing with lighting in interiors? Questions like these and many more came up during the greyworld implementation, and we’re happy to say that through this process, we have solid answers that will hopefully influence future zone design.

While one group of programmers was dealing with the asset creation issues, another group was providing the systems required for “conflict” zones. A conflict zone is a non-persisted, short-sessioned PvP arena, complete with auto-grouped teams and goals. Players can sign up for a conflict zone through an NPC, and once the match starting conditions were met (e.g., the number of players) players would continue to play in the conflict zone until a termination condition (e.g., points scored, time expired, etc.). Conflict-zone-specific gameplay (the flag) was accomplished through our abilities system. With programmers adding very small hooks to key systems already in place (such as new system prerequisites and actions), designers were quickly and easily able to iterate and evolve the gameplay to what it is today.

It’s our belief that greyworlding gives the designers and artists the freedom to experiment without dealing with technical limitations. It amazes me how our team can use the tools they have been given to create new and exciting gameplay that the programmers just did not expect. If the gameplay is fun during the greyworlding phase, on the technology side, we will do everything we can to figure out how to make it happen.

And just to wrap up, here is the entire series, from idea to execution:

Gameplay map – the basic rules and layout.

Grayworld playing field – we iterate here where it is cheap.

Concept painting – generates the mood.

Concept painting – finds the silhouette.

Concept painting – adds mass and interest.

Concept painting – creates sense of scale.

Concept painting – adds gameplay elements.

Concept painting – adds final touches.

Final in-game – only built when it is right.

Fun, fast, and pretty!

This entry was posted on Tuesday, March 11th, 2008 at 7:16 pm and is filed under Developer Blogs . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.