Sten Huebler

Level Design Challenges in Crysis: The Long Journey to Open Worlds

For me, day two began with Crytek's talk about level design in Crysis. At first, I thought that this session was supposed to hit an audience of game and level designers but then I remembered that: everything about Crysis is of interest. And because of this big name in the session title, I attended this first talk of the day.

Sten's talk dealt with the design process of Crysis. From a gameplay point of view, this is not your average shooter. The whole game takes place on an island, which can be navigated using many vehicles. In order to build a rock-solid game experience, the game design team needed to get a logical understanding of the whole game area. So they decided to abstract the game location (they built numerous graphs to present the game flow and the main scenario) and once they got this done, they began to design the game.

Every location was made using several iterations:

• Idea/concept: bringing material together to build the location.
• Layout, first pass: these are really two phases, but they have the same goal: at the end of the first pass, the major gameplay and graphical elements are here.
• Second pass, alpha: same here (these are two phases). At the end, we get a beautiful playable game.
• Final: the final pass brings additional awesomeness into the game. Graphics that were just good are enhanced to be really good, gameplay is tweaked a bit to be even better and so on.

Sten explained how that worked for the three main design teams in Crytek: the gameplay team, the art team and the technical team.

The gameplay team had to leverage a set of unique challenges, which were introduced gradually in the game because of a unique feature: the nanosuit. The nanosuit introduced new ways to play and new gameplay opportunities. In some cases it required a full redesigned of specific zones, in order to make them more "nanosuit aware".

The vehicle and AI management was a bit easier. However, in some cases, the levels had to be carefully tested in order to discover incorrect vehicle paths (because some rocks were introduced where they should not have been). A full set of AI guidelines where used to ensure that AI would work correctly. The development of Crysis taught a few lessons to the game designers:

• First, prototype really early. The nanosuit proved to be a problem while developing the game because its features were insufficiently developed.
• From the prototype, derive guidelines: they will help you to be more consistent through the whole game design process.
• "Discover the specialists in your teams and utilize them". These are Sten's word. If someone is good at doing something, use him to do it.

Artwork was divided in two phases as well: during the first iteration, art designers and artists worked together to build the world. The first optimization and polish pass is included in phase one. During the second phase, 3 programmers joined the 4 artists to improve the game performance.

The art team was expected to build a photorealistic world. I think we can say that they succeeded. That doesn't mean that the team didn't learn anything in the process:

• Do not start the art pass too early: gameplay comes first, it is better to wait a bit for the definition of everything before starting the polish phase.
• From what I understood, the CryEngine2 has several limitations that could have a tremendous impact on the visual fidelity of the game. It forced the designer to take texturing into account very early in the design process because it would have been difficult to modify later.

The technical imperatives given by the game engine also had an impact on the designers work:

• Assets == hardware resources. The designers had to focus on important stuff; less important stuff offered the possibility to save hardware resources.
• For everything, artists and designers had to follow some rules and obey a set of limits - without exception.

Sten Huebler finished his talk with one slide that listed the key lessons that have been learnt by the game design teams in Crytek.

• Fail early and iterate faster - the earlier you fail, the earlier you can find the correct direction.
• Understand your priorities - it's better to get everything important first than to spend too much time on unimportant details.
• Challenge your favorite ideas - to test whether they're good or not.
• Derive guidelines from your prototypes - your prototypes should give you the opportunity to test ideas and to build a complete set of rules. The designers can then use this set of rules when they build the final iteration of the game.
• Use your team smartly - some guys are better than others when it comes to do a particular task.

Ben Cousins

Keynote: Scenes from the Battlefield: The Present and Future of Core and Casual

Each year during a game-development related conference I learn a new marketing term. This year was not different: I now know more about how marketers categorize me. According to Ben Cousins, I am a "frustrated restricted". Not sure I like it. Okay, enough with the rant (and more about that later).

Maybe you know Ben Cousins because he was some kind of musician when he was younger. But it's probably not the case (unless he's your son, of course). You may know him because he worked on a bunch of famous games (and during that time, as he said, he was playing the different flavor of the "Battlefield" games). Or you may know him because he took over the role of producing the Battlefield product line (no less than 5 (or is it 6? I can't remember) games are currently in production).

If Ben decided to speak of the Battlefield franchise, it's not to tell us how formidable the games are. That's ok, we're pretty sure that the next installement will be great and stunning and so on. Instead of advertising the classical AAA game, Ben Cousins decided to speak about a small casual Battlefield-based game which is currently in closed beta: Battlefield Heroes. This game has many distinctive features:

• First, it's cartoony and fun.
• Second, it targets tha casual game audience - simplified controls, automatic match-making and so on.
• Last but not least, it's a PC game. More important, it's a free to download, free to play PC game.

Did I heard correclty? A free game made by EA? That's sounds like a strange deal... Where's the catch line?

A bit of explaination is probably required at this step. The model of free to download, free to play PC games is not new: a number of titles have already been developed for the American and the European market (Dungeon Runner by NC Soft is one example). But as of today, the main market for this kind of game is Korea - and that's where the head of EA DICE went when they decided to test this business model.

Of course, the game publisher is still interested in making money from these games. To do that, you have to balance the cost and the revenue. According to Ben Cousins, the very specific needs of Battlefield Heroes drove the complete development of the title.

The first thing to get right is to get a large audience - the largest possible. In order to succeed in this area, you'd better not require high end machines: the game has to run smoothly on low end PCs. The development team chose to give the game a cartoonish look-and-feel, which still allows beautiful graphics but at a low cost (low-poly models, simplified textures and so on).

Once you get the audience, you have to keep it. Speaking of that audience, you already know how the marketers call it: the "frustrated restricted". I am one of them, so let me explain: frustrated, because we want to play. Restricted because we don't have the time to play. This sounds a bit less aggressive than without any explaination, doesn't it? To be even more neutral, let's call this audience "casual players".

Since you want these casual players to come, you'd better not require them to have ?berhaxor skillz because they don't have the time to get to that level. Therefore, the game has to be simple - controling the character is to be as easy as it seems - and fun. Since it is still an online game, you must find a way to find the perfect opponent for each player. If you've just started to play the game, there is nothing more frustrating than playing against a 13 y.o. boy who has been collecting frags for years at Counterstrike and who constantly kills you in the first 30 seconds of the match. In order to alleviate this issue, EA DICE developped a specific match-making system that ensures you'll get an opponent who roughly has the same skill level as you. This should guarantee that the game will remain fun whatever your level is.

At some point, you also need to get some money. When the game will be launched, you'll be able to buy a few customization items for your character. More will be added later when the developers have a better understanding of what the players like and dislike. The development team will also be responsible for fixing the game flaws once they are identified (of course, they will also fix problems during development, then during the closed beta and the open beta; but as Ben stated, the real work will only begin once the game is really published).

As I already said, the game is currently in closed beta. This phase will be followed by an open beta, then by the final launch itself. EA DICE decided to not advertise the game aggressively, citing YouTube and a few other major internet websites - who remembers their launch day? Instead, Ben Cousins prefers to rely on some informal internet buzz.

This is where the talk about Battlefield Heroes ends and where the conclusion (which took the form of a rapid market analysis) begins. Ben Cousins explained to us that PC gaming is not a dead market - it's a changing market. He thinks that simple, simple online PC games will eventually dominate that segment because they are cheap and convenient (at this point he did a strange comparison between AAA games vs. PC web games and Cinema vs. Television).

To be honest, I hope that PC web games will spread. I also hope that we'll still get AAA titles.

Now, let's point to the game annoucement video.

Hope you'll like it as much as we did!

Frank Hauselmann

How to Expand your Game Engine: Customization for Everyone

Frank Hauselman works at Ubisoft Quebec, and his role there is to develop a new game pipeline, which is used internally on 30 different projects. There is a good reason for this: Ubisoft is developing many different games, and many of these games are using very similar technologies. Unfortunately, not all games are using the same exact set of technologies, which makes it difficult for code reuse. To alleviate this problem, Ubisoft created a special technology unit that roughly works as a middleware provider for all Ubisoft studios.

Why is it necessary? Frank gave us an example of what could happen without a centralized engine development team. Team A sends the engine to Team B in order to allow them to develop a PS3 game. Team B modifies the engine. Team A begins to work on a new game, and gets the engine back from Team B. They now have an engine that works on XBox360 and PS3, but with different features and interfaces. Woot.

The number of teams that work at Ubisoft, the number of hardware targets to support, and the different game genres are growing fast, and this growth needs to be addressed.

First question to answer: what part of the development is the most expensive? Development of a typical game can be split into 3 phases: pre-production (technology update, SDK upgrade, tools development), game development and game debug. During pre-production, nothing really happens to the game. The ratio investment vs. added fun is 0. During development, fun is added to the game at a good rate - and as time goes on, it is more and more easy to add fun to the game. When the debug phase comes, the ratio investment vs. added fun diminishes abruptly. To summarize: there are two development phases that doesn't add much fun to the game but still cost a lot.

You have understood this by yourself: the idea is to provide up-to-date tools to the development team so that they can add fun to the game as soon as possible, and to limit their debugging time to the minimum. But to handle that properly, the technology team must take many factors into account: the game genres, the number of possible target platforms and so on.

This is done by considering three development axis: modularity (in order to extend it easily), accessibility (the technology shall be easy to use) and working with the development community (ensure that they will use it).

Ubisoft is developing a full game solution that can be used to prototype games as well as to produce real games. Why do they call that a game solution? Because such a solution is not tied to a particular pipeline. Coupling has been extensively researched in order to allow different pipelines to be plugged in. Your game is using a very specific physics engine? No problem. They identified 4 areas where coupling must be taken into account:

• Game objects should be loosely coupled, in order to allow reuse.
• The different editors (the production pipeline) can be coupled a bit more, but flexibility is still very important.
• Engine shall be flexible as well - as pipelines might be removed, added or modified.
• The coupling between the game editor and the engine is less important - the engine is not likely to change, and the editor is supposed to be standard. But that doesn't mean that this cannot happen.

Accessibility - for artist - is done by creating a bridge between the different tools. Click an object in the game editor and it will be opened into 3DS Max. A single button in the modeling package directly exports the engine into the game editor. Source control is done transparently, and without any action from the user. In fact, the user doesn't have to know that assets are stored into a source control database - and this is a good thing, because he shouldn't care.

A useful tool that users really like: automatic discovery of the tools that are needed to configure a property. Reflection and source code level information are used by the different tools to bind properties of game objects to specialized tools (for example, a color is bound to a color picker). This allows fast iterations for both the programmer and the artists.

Even for a programmer, accessibility is very important: if you limit learning, you can save loads of money during the pre-production phase. But that's not the only reason. If you have a technology that is simple enough, you also reduce errors and limit context switch within the programmer's brain.

But it's not enough to have a good solution, because the best solution in the world isn't worth anything without support from the target users. Ubisoft therefore created an internal community of users to support the technology. There are immediate benefits to this: team-centric NIH syndrome is avoided as teams can now share their knowledge and tricks, experts can be called to the rescue more easily, and so on. An interesting part of the community is the Feature Shop, where game programmers implement new features that are added to the game solution as some kind of plugins. Another interesting part: the demo group, whose role is to create game demos to show specific features of the Ubisoft game solution.

In the end, the creation of a specialized technology team allowed Ubisoft to create synergies between different studios all around the world. They cut their development costs and ensured they remain up-to-date with respect to the technology.

Diarmid Campbell

Camera-Based Gaming: How to Do It and Why you Would Want to

Making a game that uses a camera is difficult - not because of the game itself, but because of the treatment you must apply in order to get something interesting from the camera. If you think that understanding an image is easy, think twice. Your brain does many things under the hood, and before you can do anything yourself, you must understand how everything works.

Here is a typical problem with the way our brain works: we automatically identify colors with respect to their environment. The context is important to us, but a computer will have difficulties understanding it. This leads to many problems: for example, color recognition is notoriously difficult to perform.

To identify a player in the capture area, many techniques exist: for example, image subtraction (take a reference image without the player, and bring the player back into the camera: everything different is supposed to be the player; unfortunately, this technique is very fragile). Another algorithm: sequential frame comparison. A motion buffer computes the difference between two frames. Unfortunately, this technique captures every movement, not just the player's movements. UI motion buttons can use this technique. To use it effectively, a good idea is to let the software accumulate motion before the action is triggered. Vector buttons also use this algorithm. The motion is understood by the program and transformed into a motion vector.

Optical flow is based upon interest points that will be easily found in the next image. By computing the difference between their positions in subsequent frames, we can find motion vectors as well. Unfortunately, it's very difficult to differentiate between different movements - a rotational move is a rotation move, no matter what part of the body performs it.

Creature Feature (available on the PSN to download) is a game that implements many of these UI features. The goal of the game is quite similar to the goal of lemmings - except that the movements of your body attract creatures you must save. It uses optical flows to implement scroll bars and motion buttons to implement the traditional UI buttons.

Good input devices feature a unique set of features:

• They are flexible and rich; a camera is very flexible - the number of parameters to take into account is the number of pixels of the device (its resolution).
• They are non-abstract: an action on the controller is directly mapped to an action in the game (swing the wii controller and you'll hit this tennis ball).
• They are robust and responsive: false input shall be avoided, but it's best to respond to input immediately.

Input devices have a tremendous effect on game play depth. If the game is skill-based, the mastery of the controller will improve your game experience.

That led us to the best show I ever seen in a conference. Imagine a talker taking two pompons (a red one and a violet one; these colors can easily be tracked by a camera by using hue correlation) to play a dance game (Pompon Party, to be released on PS2) where the pompons are tracked by an EyeToy camera. And he must sing too. That was priceless. But let's go back to work.

Diarmid gave us many examples of EyeToy-based input devices (polystyrene ball, a simple drawing (call this "sketch technology"), and so on).

Of course, you don't always need a specific help to use the EyeToy. You can try to track the head (which is good; as Diarmid said, "everybody has a head, so we don't need to ship it with the game"). Unfortunately, head tracking is difficult. Sony Japan is currently trying to improve the state of art - but robustness is still to be enhanced.

Using cameras allows you to make augmented reality games. Step one: capture the frame, threshold it, find edges, test for the presence of a marker, calculate orientation, and replace the marker with a 3D object.

According to our host, the EyeToy brought physical gaming to public attention (and the Wii made it mainstream). Camera-based games can bring many things into the game arena because of their ease of use. They also help immersion of the player in the game. And they have a bright future: researchers are already working on the next generation of camera devices: 3D cameras. Some photos courtesy of Connection Events.