We often get questions about the technology we're building for Natural Selection 2. With this in mind, I've written up the first of a several part blog post to answer some of the more common and interesting questions. My initial call for questions generated quite a few, which I intend to address in depth, but first I'll start with two of the more general questions.
Andreas asks: What is the Spark engine? Is it the whole game engine or just the graphic part?
This is a great question to start with. Spark is the entire game engine and tool set we're using to build Natural Selection 2. This includes the graphics, sound, networking, physics, scripting, path finding and effects system (probably others too). It also includes tools like the Editor, Builder, Viewer and Cinematic Editor.
When Charlie and I started working on Natural Selection 2, we weren't planning on building an engine. Creating technology is a lot of work and it's also very challenging to build a game - both in terms of gameplay and artwork - when the engine isn't finished. When we ultimately decided that we were going to create our own engine, we wanted to make sure the technology was flexible enough that we wouldn't have to start again from scratch for the next game. We also wanted to make sure that other people could use our engine to make their own games. To this end, the technology is designed to be largely independent of the game. Spark is coded in C++ and provides the core functions of managing a virtual world. But Natural Selection 2, which is entirely programmed in Lua, adds the common elements of first-person shooters (players, weapons, score, etc.) and the Natural Selection-specific pieces like commander mode, tech trees, wall walking, etc.
The division of labor for the coding has always been very straightforward – Charlie writes the Natural Selection 2 code and I write the engine/tools code. A few months ago, Kurt Miller, a great programmer and a good friend of mine, joined Unknown Worlds to work on the engine and tools code as well.
For the past two months we've released weekly patches to the editor. Often people interpret these editor-specific updates to mean that we're not making progress on the game. In fact, even when we were crunching the hardest on the Editor - right before the initial release – Charlie was still devoted full-time to the game code. Now-a-days, Kurt and I spend most of our time enhancing the engine, with Kurt spending a small amount of his time implementing new features and bug fixes in the editor.
Beat Wolf asks: What platforms will be supported? (Linux, OS X, XBox, etc..) The web page still mentions Linux and OS X as target platforms, but there have been many doubts with the inclusion of Steamworks and because the question seems to be avoided for some time now.
Well let the issue be avoided no longer! Currently our engine and tools only work on Windows, and that will be the only platform Natural Selection 2 will be available on at release. However, most of the engine is not platform specific. The largest Windows-specific piece is the low level rendering code which is built on Direct3D. In the interest of having our engine run on Linux and OS X someday, this low level rendering code is wrapped up so that it's mostly separate from the rest of the engine. With a small amount of effort, we can swap out this piece with an OpenGL implementation that will work on Linux and OS X. All of our tools are built using the cross-platform wxWidgets framework, so once we get the engine working on another platform, bringing the tools over won't be too much work.
Now that I've convinced you that we've taken steps to allow us to bring our engine to other platforms, you might be wondering why we don't just go ahead and do it. The answer is simple; we don't have the time right now. As an alternative to doing it ourselves, we've considered "open sourcing" or publishing the low-level APIs for the pieces that are Windows specific and inviting community members to contribute their own implementation. If you like this idea let me know in the comments.
Now the issue of Steamworks. For those of you who don't know, Steamworks is the core technology of Steam, like the friends list, server browser and voice chat. We've integrated Steamworks into Natural Selection 2 because it saves us the effort of implementing these things ourselves, and gets the game into your hands faster. Unfortunately Steamworks (which essentially is the Steam client) only works on Windows. We've setup Natural Selection 2 to work without Steamworks, but you lose the services that it provides. For example, instead of being able to browse for a server you'd have to type in its address in the console to connect to it. For an OS X or Linux client, we'd have to substitute in our own implementation of those missing services. This certainly isn't out of the question for a post-release update to the game, but it's not something we'd delay the initial Windows release to incorporate.
I should add to this discussion, that none of this applies to running dedicated servers on Linux. Dedicated servers don't require graphics, input or any of those other platform specific things. And one of the great things about writing all of the game code in Lua is that it's inherently platform agnostic. Dedicated Linux server support will be in the initial release.
If you have more questions you'd like to see answered, feel free email me at max@unknownworlds.com. The more specific the better!
Two weeks ago we we posted some screen shots of the new marines in Natural Selection 2. We were really happy to hear the overwhelmingly positive response to the new marine design.
There were a lot of comments and questions about the renders we posted, so this week I put together a video to show all of the components that make up the rendering system in our engine.
Here's what you're seeing in the video:
Wireframe – This shows the geometry that make up the objects visible in the scene. Here you see about 100,000 triangles. Each marine has over 13,000 triangles!
Normal Map – In addition to all of the geometric detail in the models, we get even more detail by using a normal map. The normal map causes flat triangles to be lit as if they were actually more complicated surfaces (here's a good explanation from our friends at Wolfire). For our models, we generate the normal maps from incredibly high polygon meshes.
Texture Map – The texture map is a hand painted image that specifies the color of the models.
Specular Map – The specular map is also hand painted and tells the rendering engine how shiny the surface is and what color the reflected light should be. For metals this is typically similar to the surface color. For the skin, we use a blue tint to counteract the warm tones of the texture and give the result cool white highlights. The cloth parts are completely black so that they won't be shiny in the final image.
Gloss Map – The gloss map also helps define the shininess of the surface, but in this case it's how smooth the material is. For a really smooth surface – like a pool ball – the highlights will be very tight, but for rough materials it will be broad. There isn't too much detail in the gloss map because this effect tends to be fairly subtle.
Lighting – To determine how bright each pixel in the final image will be, the rendering engine computes a number of lighting passes. Each pass uses the normal, texture, specular and gloss maps to figure out how much light is reflecting off the surface and entering the camera's lens. Here we're just showing the lighting passes without the influence of the texture map for clarity. Shadow maps are also used to determine which parts of the scene should be in shadow, although not every light casts a shadow for efficiency.
Ambient Occlusion – The rendering engine applies a screen space ambient occlusion technique to add even more shadowing detail. Ambient occlusion is a measure of how much light from the environment is blocked by nearby surfaces. We use a simple approximation to darken the crevasses that aren't handled well by the shadow mapping system. The ambient occlusion is applied as a darkening effect over the final lighting; this isn't physically based, but gives us the results we're after.
Combined – Here the lighting and texture mapping are shown combined. In practice this is actually done during the lighting passes.
Atmosphere – The atmosphere pass simulates the effect of light hitting tiny particles in the air (here's another example). This has become one of the "signature" effects of our rendering and you can see it put to extensive use in our other videos.
Color Grading – Also called color correction, color grading is the process of adjusting the brightness, contrast, color levels, etc. of the final image. This gives a lot of control over the scene that can be difficult or impossible to achieve by tweaking the lighting and texture maps.
We hope you've enjoyed this "under-the-covers" look at our engine. You can also see our rendering engine at work (with motion blur!) in the teaser video we released on the main site.
We have our heads down around the office here, cranking away on some important deadlines, but we wanted to give you guys a little something while you wait. So, here's an environment concept painting put together in wallpaper format. In it you can see the central drilling room, one of the landmark areas in a mining map currently being worked on. This is one of several maps in the overall Refinery themed set.
Enjoy!
We decided we wanted to try motion-capturing the marine animations in NS2 because there are tons of them to make and because they are very time-consuming to create (because the human eye is so familiar with how humans move). Colin Knueppel is one of two animators on NS2 and has done motion-capture before (unlike the rest of us). He wrote up with this set of guidelines to help us get started. We thought this might be helpful for other game developers and interesting for everyone.
Check with the mocap studio
Motion capture most often uses a myriad of cameras to catch reflective balls sticky taped or velcroed to an actor's body. If you bring something similarly reflective.. well, it can cause issues. Discuss what you'd like to bring with you to the studio with the studio. Ask them what you can do to minimize any conflicts your props may cause.
Have some masking tape
Hopefully they'll have it there, but if they don't, have your own tape. Putting down a target from start to finish helps. We animators can dampen or ramp up motion to make a target move X far or turn Y more, but the closer to the mark they get, the less work we animators will need to do.
Send the actor lots of Marine concept work with notes
The better the actor understands what his character is wearing and what restrictions he may have, the better the performance will be.
Bring the material with you
Unfortunately many actors have been disappointingly unwilling to read material sent to them, preferring to "wing it." Setting aside 45 minutes before you're on the mocap clock with the actor to make sure they understand what they'll be doing is preferable to arguing it out while the machines are running. If you can set aside an afternoon to plan through moves with him or her before the mocap, even better. Inside the mocap studio your on an expensive clock. A parking lot with coworkers to get down the gist of motions is a great start. Getting time with the actor to convey what you learned will cost you the actors wages, but the motion capture session will go many times smoother.
Proper weight
A marine tends to carry something akin to 60 lbs of gear, ammo and armor. Weighting the mocaper down correctly will keep him from doing unrealistic motion, give his foot steps proper weight and dampen the slight dancey tendencies that come with mocapers. It's not their fault, usually. It's human nature. When you don't properly weight a character, the actor often hams it up to "act" bigger or more impressive. It may work on film, but the cruel eye of the motion capture cameras will make every odd mannerism twice as goofy. Ask the motion capture studio what you may be able to use to properly weight the character. A belt with some sand bags attached to it, a shoulder straps with some weights, some ankle or wrist weights. Get or make a well-weighted weapon. Find out if there's a color you should use that wont throw off the capture.
With each of these, we don't necessary want to go realistic but light of realistic. Ask the actor what he'd be comfortable with. Test it ahead of time when practicing with the actor, if you can.
Recoil
An innovative approach to motion capture was tested by my lead at Bioware, Shane Welbourn, and it worked fairly well. Gun recoil comes from the gun, not the marine shrugging spasticaly. When the actor is "firing" have someone strike the rifle's end. This makes the motion driven by the gun, not by muscle contractions in the actor.
Make it as realistic as you can
Ultimately the less the actor has to guess, the more realistic the motion will likely be. If you can restrict his spine movement, he'll compensate for the marine's rigid outfit. If you tape a mocap friendly ruler to his forearm, he wont have to guess where the pad will be. If you give him a nicely weighted weapon that's approximately the right size, he'll wield it right.
Experience
Find someone that has "been" what you want to mocap. Finding an actor who was a marine, he'll bring his experience to the session. When you get someone that isn't familiar with appropriate motions, they sometimes bring their other non-related experiences to play. We had a martial artist being dual-booked for our sci-fi game that could not, if his life depended on it, make a kick that didn't go at least a foot and a half off the ground by the time it was finished. That flourish took hours of animation and creative camera work to tone down.
Getting an appropriately experienced actor is not without pitfalls. Sometimes what actual marines do is less interesting then what we think they do, and even a hardened marine can come across with oddly consistent emotional gestures. Meeting the actor is a good way to pick up on problematic gestures, and practicing and discussing the moves ahead of time is a good way to avoid uninteresting motions.
Do what looks right, not what is right
This is a huge, but sadly not well known, rule of animation. The human mind has expectations, some of which are not always true. When confronted with whether to do what looks right or what is right, always go with what looks right, because an audience is not going to have the benefit of an explanation. They will cock their head and say, "that's odd." We want to keep the player in the game focused, not educate them.
We hope you found this interesting and helpful and we're hoping to share with you some footage of our motion-capture session!