Day 3 of 4 in our new "rail car" concepts from Cory. Today's picture is a dramatic revisit of Cory's love of lava. This is something he wanted to get into the original NS, though it never quite made it the way he wanted it.
Maybe this image will inspire someone from the mapping community to work it into a map properly?
Cory "Squeal_Like_A_Pig" Strader has been working like crazy on finishing up Lair for the PS3, but has found time to continue his truly awesome concept work for NS2.
This time up, he decided to try some "rail cars" and along the way, created some cool environments, marines and even the first new glimpse of the Kharaa. It got everyone on the team pretty excited, so we thought you guys would like it too.
So without further ado, here is an idea for "rail cars", in Cory's words:
"The idea was a "team experience" kind of prop, which, in this case is a rail car that would be used to carry crates and cargo in the industrial parts of the NS universe, and of course can be used to transport players quickly from point A to point B on a map. Essentially it would be a horizontal elevator, you hop on, press the use key on the control panel, and it follows the track to the end of the line. Nothing overly complex. But it could add an interesting visual and gameplay element."
"Maybe the car on some maps could have some crates on it, that can be used for cover while riding. Maybe you can build structures on top it it. Like the marines build a siege turret, hit the button to make the car start up, jump off, and send it empty except for the turret into an alien base. Maybe a handful of marines head off on the cart, then the thing comes back a few minutes later loaded with aliens. Maybe smaller aliens get squished by it, but an Onos can derail it."
Stay tuned for color concepts coming shortly...
Most of our blog entries so far have been about scripting, sudoku or slime, so we thought we'd put together something a bit more practical - texturing.
Jason Lange is one of the main artists on our NS2 team (also known as JJJ1) and he recorded his entire workflow while he textured a 3D model of a cannister (while listening to Juno Reactor, apparently). View the YouTube video below or download one of the higher-quality versions to get an idea of what goes into a simple prop.
Download highest quality (98 megabytes)
This cannister is one of many props that we need to create in order flesh out the our world, to make them feel detailed and "realistic". Other props include swinging cables, grates, vents and doors.
Along with an array of props, we are also creating a library of materials and sounds which, along with our mapping guidelines, will be bundled together to form the NS2TR - Natural Selection 2 Technology Release. Anyone that was around before NS 1 was released might remember the NSTR, which we released in a similar fashion. It served as a stripped down version of the game that level designers could use to start creating levels before we released the game. It included our custom particle system editor, a basic commander mode and the skulk wall-walking. It turned out that it was used not only by mappers, but by players.
So once we've created a large enough set of base props and materials, we'll be releasing the NS2TR to the public. This gives us some nice press and some early feedback but even more importantly, it means you guys can start creating maps. With Natural Selection, we included the best community maps as "official" and part of the game and we'll be doing the same for Natural Selection 2. Because we are selling NS2 though, that means we'll be buying maps from you guys outright. Many NS1 mappers moved on into the game industry professionally and we think this is an even better opportunity!
When working with assets and code in a complex project it's useful store all of the files in a central repository, called a revision control system. Whenever files are updated in this repository, the revision control system makes a note of the modification and saves the new version. The revision control system also keeps the old version of the file, and later on it's possible to revert back to it or look at the history of all the modifications made to the file.
Our revision control system (Subversion) setup so that every time someone on the team submits a change to the project it sends an e-mail notification to the other team members. These e-mails have the names of the affected files, who changed them, and a short description of the change. Since the Natural Selection 2 team is distributed all over the world – quite literally – we use this mechanism to help update everyone on what's happening day-to-day and minute-by-minute.
These e-mails work well for source code where the description really tells you everything you'd want to know about change. For example, “Fixed bug where resource towers could be placed off of a node” lets you know exactly what that change does and what the effect on the game will be. We use the same system for our art assets, but with image changes, a text description like "Updated ceilingspot02a.vtf" isn't very helpful. Unlike the code change, where the description points to an easily recognizable bug or feature, the in-game effect of this image update is not obvious.
Last week, Charlie suggested a simple improvement to our checkin messages that we thought might be useful for other distributed teams that check out this blog. The screen shot below shows one of our new improved check-in messages in my inbox:
In this check-in, JJJ1 (Jason Lange) updated the self-illumination part of the one of the ceiling textures. Now instead of just telling us which image file has changed, the new check-in message also includes a snapshot of the new texture so we can see the change at a glance. Perfect!
The implementation of this with Subversion was pretty straight forward since Subversion executes a PHP script every time a change is committed. Attaching a preview was just a matter of detecting if any of these files use Valve's texture format (VTF), grabbing them from Subversion and running a VTF to JPEG conversion using a combination of VTFCmd and ImageMagick. The final result is attached to the outgoing e-mail which we send using Blat.
Today is a big day in the progress of Unknown Worlds as an company. I've just completed my move to San Francisco, so now instead of working 3,000 miles and 3 time zones apart, Charlie and I will be working in the same room every day. Well, maybe not weekends.
The past few weeks distracted me a bit; finding an apartment, packing up my stuff, tying up lose ends and flying back and forth across the country really ate up a lot of time, but now that it's finally done it'll be worth it. Working in the same location improves efficiency and productivity substantially, and it's a lot more fun to boot.
We've accumulated a big list of things we wanted to deal with face-to-face -- project management, work flow, legal, business and the website (gasp!) -- so now it's time to start working through those. Right after I unpack my stuff.
As mentioned here previously, we're doing all of the game coding for Natural Selection 2 in the Lua scripting language. While using a scripting language offers lots of advantages, one of the big disadvantages is that the tools are generally not as good as what's available for C++ development. The most important of these tools is a debugger, which programmers use to inspect what's going on as their program runs. This is a valuable tool when trying to find and fix bugs in even relatively simple code, and for something as complex as the code for Natural Selection 2, it's a necessity.
There are a couple of existing debuggers for Lua, but none that I tried worked for debugging our script code. I'm not sure why that was – possibly operator error – but since Lua has some built-in hooks for writing a debugger and I've got quite a bit of experience building UI tools, I figured I could easily create my own. This turned out to be accurate (not something that happens often) and I got a functional Lua debugger working with Natural Selection 2 over the course of a weekend.
What I didn't realize was that my original design for the debugger wasn't very good. I'll spare you the details of how the early version worked, but this is what I discovered once we started using it: for the best work flow the debugger needed to be a separate application from the game and needed to have an integrated code editor -- two things my early version lacked. The concept of an integrated development environment (IDE) like this is something programmers invented decades ago, so I perhaps I'm a bit dense.
Armed with that knowledge I starting programming a new script editor/debugger that we have dubbed Decoda (see screen shot above). Charlie and I both have friends that work at other companies that expressed interest in a Lua debugger, so we've been developing Decoda with an eye towards licensing it to help fund development of Natural Selection 2. Getting it to the point where it could be effectively used as an IDE took quite a bit more work than the initial weekend for the prototype debugger, but we're getting close to an alpha build. We're going to be sending this build to some people for feedback, so if you work for a company that might be interested in Decoda, write us at license@unknownworlds.com.
To keep this blog entry from being too dry here's a cool concept painting done by Christian Oesch. I mentioned in the last blog that the concept images we posted before were of the “biomech”art set; this image belongs to what we call the “drytech” set and as you can see it has a bit of a different look.
The purpose of defining different art sets like this – an art set is a collection of textures and prop models that have a similar theme – is so that we'll have plenty of visual variation between the levels for Natural Selection 2. The level designers for Natural Selection 1 did a great job, but for the sequel we want to give them even more tools to make every level feel unique and memorable.