Hey everyone,
We've been so busy coding, Facebooking and Tweeting that we haven't posted here in awhile. Well it may not look any different, unknownworlds.com is now running on a very fast new linux machine so we can scale with demand. We saw a bit of downtime with the release of our teaser a month ago and we don't want that to happen again. We've definitely outgrown our old machine and with help from the NS community and some local friends, this new server is up and running and faster than over! I hope we're ready to handle tons of traffic.
We are hard at work getting our content tools (level editor, cinematic editor, model viewer and builder) shippable so we can give them out to everyone that pre-ordered Natural Selection 2. We want to give you guys an early peek at our technology so you can get up to speed with the tools and so you're ready to mod the heck out of NS2 when it's released. We're also hoping to get lots of feedback so we can make sure the tools are useful, intuitive and pleasant to use.
Along with these tools, we're planning on releasing our environment artwork (textures and models) and NS2 mapping guidelines so the community can start making maps. We did this a looong time ago with the NS Technology Release and it worked out fantastically. Of the 20 maps that ended up in NS1, well over half were from the community! Right now we're only giving out this stuff to those that pre-ordered (the NSTR was free for everyone) but we hope to give out the NS2 tools for free to everyone in the future.
If you see any problems with the new site please let us know (charlie@unknownworlds.com)! Over and out.
ModDB just posted an interview with Andrew "KungFuSquirrel" Weldon (personal website here), the lead level designer for NS2. Andrew created the two most popular maps for Natural Selection (ns_eclipse and ns_veil) and has been taking the reins for all that is level design in Natural Selection 2.
The interview talks about how he got into level design, his involvement with Unknown Worlds, how he works off-site, how NS2 maps will compare to NS1 maps and the proverbial more.
I wanted to explain and get feedback on the idea of the marine "power grid" in Natural Selection 2. This idea came from discussions about Company of Heroes and supply lines (featured in many board games) and whose main goal is to give the combat a dynamic feel. As the game progresses, different regions of the map should have shifting values and different rewards for building or destroying there.
One more thing - in NS2 there are no hive rooms per se and the marines can't build their Command Stations anywhere. Both teams must build their Hives or Command Stations at special points on the map called "tech points". Building here lets the team have the ability to have another commander, and also is needed for "teching up" to tier 2 or tier 3.
Here's the current idea, let me know what you think.
Power Grid
The power grid is like the concept of "territory" in Company of Heroes. It keeps marine structures functional. It means that structures are only powered if they connect back to a built, active Command Station. The purpose of the power grid is to cause different areas of the map to have different strategic value at different times, to enable comebacks and to give the aliens an ability to win even when the situation looks hopeless.
On the left is the map layout with the tech points (hive and command station points) represented by red squares and resource nozzles by purple circles. The arrows represent the routes players can travel but don't affect the power grid. The right picture shows the power grid - each room is treated a a unit on the grid (power region). Command Stations provide power to all adjacent rooms that have a built resource tower in them.
The resource tower pumps resources into the Command Station, and the Command Station powers the resource tower. When the resource tower is active, the entire room sparks to life and "powers on". If a resource tower is then built in an adjacent room, that room powers up and other structures in that room can function. Structures will not function if the room they are in are not powered up.
When resource towers or command stations take damage, lights and computers in rooms that are powered by that node will start flickering. Destroying a resource tower in the middle of a chain, or destroying the command station at the end of the chain will power all dependent rooms down. Damaging a tower or command station will cause lights and monitors in affected rooms to flicker, hinting at what might occur. When the power goes out, infantry portals stop spawning in players, armories can't be used to buy or resupply, sentries power down, etc. These power regions will be drawn for the Commander, and will blink red when unpowered.
For clarification, alien structures aren't affected by the power grid (although they have their own system that relates to dynamic infestation).
Thoughts? Feedback?
04/16 Update: Check out this post where KungFuSquirrel (our lead mapper) answers more questions.
One of the difficulties with having such a small team is finding enough time to do everything that needs to be done. As the only engine and tools programmer, this can become a problem, since often my work can hold up other people's ability to make progress. While almost every other tool or system has been developed far enough that people can be productive, special effects is one area that hasn't gotten any of my attention thus far. This week I decided to rectify this and create the effect editor that we'll use to create all the special effects for the game.
Tools often fall into a "level of effort" category, where the amount of time they can take is unbounded; there's always one more feature you can add to make it easier to use or more powerful. Since there are lots of other tasks to be done before shipping, I decided that 5 days was the most I could afford to spend creating the effect editor. I think most people (including myself) would consider this a ridiculously aggressive schedule, but nobody said independent game development was easy!
Since this was such a short task, I decided to document the major stages of development as I progressed. I started working on the editor on Friday morning and it's now Monday afternoon. A power outage on Friday put an abrupt stop to development, but things are progressing smoothly otherwise.
The first step to building anything is creating a design. For tools, I always like to borrow ideas from other similar applications, synthesizing the best ideas from each into something even better. My hope is that by drawing on established user interface conventions, my tools will feel very familiar and immediately usable. This also speeds up the design progress by transforming it into more of an editing progress.
As a first step, I grabbed screen shots of the features I like from 3D Studio MAX and Photoshop – two tools that most artists are intimately familiar with. Normally I would have also grabbed shots from the effect editors that come with other game engines, but I didn't find anything I thought would be helpful in the ones I looked at. Typically at this stage I'd also talk to effect artists who had experience with making effects for other games, but I felt like I already had a general concept of the high level advice they'd give (e.g. make everything animatable) and I could solicit the detailed ideas later.
Like our level editor and viewer, I'm building the effect editor using our engine and the wxWidgets user-interface library. To get the basic framework of the effect editor up and running, I put together existing components with a little bit of copy and paste from our existing tools.
A solid undo feature is one of the most important components of a usable tool, and in order to make sure it worked great I started on this right away. Undo can be a little tricky, but fortunately I'd already built a good system for the level editor. I took the existing system, generalized it a bit and incorporated it into our engine library. Now the level editor, the effect editor and any tools I build in the future will all use the same system.
The next step was to start building the concept of time into the tool. Every effect editor I've seen is based around the concept of emitters which release particles into the world. The properties of the emitter and particles can be varied over their lifetimes to create all types of different effects, ranging from smoke to fire to unearthly magic Most effect editors use time varying graphs to represent and edit these properties.
While I wanted to incorporate this type of editing into my effect editor, I also wanted "key frame" based editing like you'd find in a tool like 3D Studio MAX or Maya. Since I'm still developing the tool, I don't know how well this will pan out, but my expectation is that this will make editing certain types of effects much faster and more natural. The video shows this type of key framing for the position of an emitter with a slider for scrubbing through the frames of the animation.
From this point I had a lot of details to fill in for the big functions I'd put in place. This included creating a UI for typing in values for properties, displaying the key frames on the time bar, and (optionally) rendering the trajectory of the emitter over time.
The next task was putting in the traditional curve editing user interface. In this UI you can see a graph showing the value of a parameter over time. The levels tool in Photoshop has a great graph editor that allows you to easily move, create and delete points with just the left mouse button, so I implemented a very similar mechanism in my curve window.
This final video shows the current state of the effect editor, with key framing, graph editing and manually typing in the values for emitter properties. I haven't implemented very many emitter properties yet, but with the underly framework I've built it's quite easy to add new ones.
Also noticeably missing are any actual particles. Because I have a very clear idea in my head of how this tool will work, most of my time has been spent building the infrastructure rather than trying to get something fully usable as quickly as possible. Particles will be going in very soon though! I think I'm still on track to hit my 5 day schedule.
What effect tools have you used and found useful? What would you change about them?