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?
I wanted to mock up a new NS2 promotional website today. I started doing it on paper first but soon found myself scribbling things out whenever I wanted to resize or change text. Small edits are OK to erase and re-draw, but this becomes tedious when taking feedback or trying a few different approaches.
I downloaded Balsamic Mockups because I read about it on someone's blog. This software is very simple - it lets you quickly make user interfaces that look like they have been sketched out with a marker. You can resize, edit, copy, group, etc. components very quickly. Within 10 minutes I had my basic UI on screen and I was able to tweak it. Here's a shot of it (sorry about the blurred out stuff, you'll know more about this soon enough):
You can put in all the standard Windows controls, as well as web controls and fields and even iPhone-style controls if you're mocking up an iPhone app. It's all very quick and works exactly as advertised. I think the real genius behind this software is that because it looks hand-written and informal, it encourages change, iteration and feedback.
I showed what I was working on to Cory and Max, and 15 minutes later had their suggestions taken into account, and as far as I'm concerned, we have a good enough prototype we can start implementing in HTML. It will still change some, but we were able to iterate a lot faster than even paper. I wish the performance was better (it became sluggish to edit my UIs rather quickly) and that you could click a button in full-screen/demo mode and have it switch to another screen, but those are small shortcomings.
I'd like to try to mock up in-game interfaces like the player UI and Commander UI as well. I've already done these in Photoshop, but this might be the way to go if we want to see what change might look like.
Unknown Worlds is in business today because we received two rounds of angel investment. We recently closed our second round of funding which was quite challenging due to the recent economic downturn. We were very close to running out of cash and came close to not raising money at all.
If you want to learn how to pitch to investors, whether your business will be appealing to investors and how the state of the investing has changed due to current economic conditions, you'll want to listen to this talk, given by one of our own investors, Matthew Le Merle. He gave this talk at the Game Developer's Conference this year:
If you make it all the way through the talk, you'll hear a little information about Unknown Worlds as well (we are a case study).
Oh, and if you end up pitching your company to Matthew, please let him know you loved Natural Selection...