NS2 mapping guidelines
Flayra
Game Director, Unknown Worlds EntertainmentSan Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
Game Director, Unknown Worlds EntertainmentSan Francisco Join Date: 2002-01-22 Member: 3Super Administrators, NS2 Developer, Subnautica Developer
<div class="IPBDescription">Suggestions?</div>I'm writing up the NS2 mapping guidelines which will be released with the content tools in the near future. I'm wondering if anyone has any thoughts about what makes mapping guidelines useful, or ways that the NS1 guidelines ( <a href="http://www.unknownworlds.com/uwe/static/portfolio/web/Mapping_Guidelines.html" target="_blank">http://www.unknownworlds.com/uwe/static/po...Guidelines.html</a> ) could be improved.
Right now I'm keeping it super-simple and not trying to convey theme as much (I'll rely on the game to do that). I'll also try to make it a bit more visual instead of text-heavy.
Any other thoughts?
Right now I'm keeping it super-simple and not trying to convey theme as much (I'll rely on the game to do that). I'll also try to make it a bit more visual instead of text-heavy.
Any other thoughts?
Comments
I've mapped HL1-engine maps before, but not sure whats the best approach for this.
I like how you have a tree outline here, but they're all opened. A closed tree / search based help file would be ideal for me. (.chm file)
Good luck!
Just being clear, precise, and very descriptive about what each function / control does (referring to entities) that are specific to NS really helps a lot. Too many tutorials out there are way too vague, and leave it up to you to guess what it does, and how to master it.
I am interested in hearing others thoughts myself.
Right now I'm keeping it super-simple and not trying to convey theme as much (I'll rely on the game to do that). I'll also try to make it a bit more visual instead of text-heavy.
Any other thoughts?<!--QuoteEnd--></div><!--QuoteEEnd-->
Wow. Never actually read that before. I think I knew it existed, just never saw a link I guess.
I might be talking out my ass here, but won't it be kind of hard for us as community members to provide feedback on NS2 mapping guidelines without actually having seen even a rough version of the game?
As an example, from the NS1 Guidelines: "Avoid Level-Over-Level" Is that still applicable in NS2? While maps often changed their elevation, are we still avoiding actual 3D layouts?
Or what about the new dynamic with the Resource Model and buildable structures? Limitations? Distances (enforced by engine?) between buildings? And therefore size of room>
From what I understand the basic concept of Weld Points will carry over to NS2, but it functions differently. How does that translate into the guidelines now?
Alot of what I've read in the NS1 guidelines seems like it would translate well into NS2, but specifics we (rightly) don't know yet.
Or maybe I'm just not understanding on what your asking?
But I can understand you want to make it simple for anyone who wants to make a map for NS2 to know how to make one, so I'd say maybe split the guidelines into two sections: the first for basic general stuff (with pics), everything you need to make a map work in NS, and then a more technical part for advanced mappers that focuses on layout, spiffy lighting, non-essential entities, vital statistics (see next paragraph).
I would like to have a mention of where to find the stats or just a table of the full stats for things like weapon ranges, unit class speeds, structure deployment ranges, unit bounding boxes, etc. - this was about the only major thing I felt was missing from the NS OMGs.
Also, if you make it a Wiki (and lock the 'essential' section for editing only by official team members) we can tend to it and create additional articles on the deeper stuff. If it were a Wiki you could make certain pages (such as the vital stats) open for public editing so you wouldn't have to keep it updated yourself.
Finally, not necessarily part of the OMGs, but if you have a throwaway level that you can do this with, making a source of a map available would probably be very useful to new mappers, even if it were just a tutorial level. Giving a reference for how to set up certain entities and tie them together using your tech would be helpful for most people.
I usually aim for 3 main things:
A set of instructions to build a basic and fully functional map, enough to get someone familiar with the editor to make a trial map with all the game-specific elements in place that are required to run
A detailed list of game-specific objects and their properties, giving as much depth and specificity to them as possible to give mappers ideas on how they can use game elements, how flexible those elements are, and what properties do
A set of hints, be it tips on balancing a map, known issues with things, unconventional ways of doing things a map or even suggestions on how to make neat effects - some addition which may not be obvious from stock maps but which is intended to be used
From those elements, a mapper will have a working knowledge of the editor (or could need it if NS2 uses your own editor), access to examples in the form of stock maps, and their own experience on how the game playes to make a lot of judgment calls. In the end, this is documentation for the ins and outs of the game mechanics more than it is a tutorial. It is important to offer the basics, but if you want to make a map like a stock map, there are plenty of examples. Such a document should be focused on the people who want to maximize the flexibility and configuration available with your code, but should not require knowledge of the language or access to the actual code.
As for the pictures vs. text debate, some pictures are entirely appropriate, especially in the 'make a basic map' section. But since most of the depth of the document will be within configuring text properties, it may actually be clearer to describe how the code deals with it, instead of using examples.
But I would suggest a Wiki if that's not possible!
Definitely. I had to constantly re-check the boxes and ranges to make sure my hallways let Oni and HAs through or to ensure that a crouched Fade could make it through the vents.
Something to mention is not only the minimum required (An Onos won't fit) but some recommendations. For example, My first major noob mistake was to only make the hallways big enough, with some leverage, for an Onos. However, players need the room to spread out side-by-side and vertically so huge sections had to be re-done once I started putting multiple players inside the map.
Make it VERY clear how DI will change things. We have to accommodate this organic thing, so good guidelines for this is a must. Will it create obstruction? Are there certain kinds of features its reacts uniquely to? Will nooks and crannies slow down its growth or will it fill these in (i.e. does it only follow the wall line or can it detect other close walls and bridge the gap)?
Explicitly mention unique entities. If there's an entity that speeds up or slows down DI growth, tell us. If there's a trigger based on the pressense of DI, tell us! Maybe not in the guide, but documented somewhere obviously close by.
My personal favorite parts of the original NS1 guide was explaining tips on atmosphere. While some people naturally get this from experience, as a new mapper it really helped to understand the subtle things I had access to. Changes in elevation, color of the lighting, etc. Technical stuff is nice and useful, but general guidelines to ease mappers in are also really nice and appreciated greatly.
First we need a "technical mapping guide" wich includes a list of all the entities/funtions/etc, what they do in general and what the parameters affect. The "Tech-Guide" should also include small tutorial-ish sections that describe how to setup supply lines, how to define wich lights are switched on/off depending on RT-status and small scripting things. Nothing too complicated. Keep it simple. The Tech-Guide should also include a list of console commands that can be used while testing the map. Oh, and one more important thing: Start with a detailed step-by-step tutorial on how to setup the editor correctly so mappers don't have the problems like they often do in Hammer.
Completely agree with Crispy on the stats-table btw.
The technical mapping guide shold have provided mappers with enough knowledge to understand how the can "make things happen" in the editor. Now we need a "gameplay mapping guide". The NS1 Guide does a pretty good job in that way IMHO. Basically we'd need a nice little list of DOs and DON'Ts. For exaple: "DO put at least 5 Tech-Nodes into the map. DON'T create locations where a MASC could reach two Tech-Nodes at the same time.".
NS2 introduces a couple of new game machanics mappers have to keep in mind. Please give mappers a short summary on how those elements are intended to fit into the gameplay from your point of view. For example: What purpose does welding doors have (Marines use it to fortify a location? to trap Aliens?) and how/when can it be used? It could read like: "in NS2 Marines have the abiliy to weld doors shut. Using a welder (available in early game) Marines can prevent closed door from opening until it taked a certain amount of damage or is blasted by an Onos (available in late game). The main purpose of weldable doors is to surpress Alien movement and to create choke points making it easier for Marines to defend their strategic locations."
I think mappers will try to use those elements in other creative ways, but it can't hurt to know what the basic idea was when the element was introduced in the first place.
Throw in some style-related things like "Thing you should do to create an infested look in hive rooms" and "Things the infestation will take care of in hive rooms"...
As said before, the NS1 Mapping Guideles do quite a good job in general. I can understand you want to keep things as easy as possible, but I don't think simplifying the "fact's and figures"-stuff would be a wise choice.
Can't wait to get my hands on the editor
/Oliver
looking forward to map tools being released, keep up the good work :)
I myself would avoid asking for any specific type of room, region, lighting, texturing, or even place type. Anything can work for an NS map so long as we can fathom (within reason) why the location is wired with a command network, why there are Kharaa here, and how they got\are getting a foothold. I would go for guidelines that focus on giving the mapper a good idea of the type of gameplay the map is supposed to support and how his mapping decisions will affect that gameplay. In the absence of such technical background information, a mapper often works off simple aesthetics and creates a beautiful map that won't play well--a disaster to fix or work around which often results in a half-assed looking map that isn't very fun. Game design to maximize enjoyable game play must be the foundation, it can't be tacked on afterward! So give the mapper a very simple, open-ended explanation of how to make a good NS2 map, teach him how to make it function with the tech, and give a bulleted list of tips that will make a map more likely to make the cut, and have it be written by whoever's making that cut. :)
I think there are several broad areas you'll want to cover, some which should be doable now and others will be really hard to state until you know how the game really plays:
<u>Technical Limitations</u> - aka don't do the following or the client will turn into a slideshow and the server will curl up and die. Examples from NS1 would be the wpoly and entity limits. These should be really clear, preferably with a recommended threshold and an absolute max. Giving explanations as to why they are set where they are will save you a lot of time typing them in individual PMs, threads, and chat sessions later on.
<u>Gameplay Rules</u> - Stuff that is set by the world and engine you've built, for example the fact that Aliens can't climb ladders. In NS1 this would have included the sizes of the clipping hulls, how steep slopes could be for Alien or Marine structures, the fact that Marines can't build in water, etc.
<u>Entity Listings</u> - what toys exist, what they do, and any special steps need to get them working. Pretty straightforward.
<u>Style Guide</u> - You don't need or want to go really indepth here. In NS1 the Textures really defined a lot of this, and I would guess the same will be true about the NS2 Models and Materials. But its good to have little hints that generally describe how things might look. (These are examples from NS1, cause its what I know.) Stuff like: Marine areas are likely Blue or White, Alien locations are more Green; Alien are more likely to be near exposed water or are in spots that are a little darker.
<u>Gameplay Considerations</u> - The hardest area to cover, and its likely to be constantly evolving as you get into Alpha/Beta testing, and then even post-release. In NS1 it was stuff like "don't let the marines siege two hives from one location", or "long hallways favor the marines, be sure to give vents and cover to the Aliens". And then getting into bigger things like "make sure the hive areas are balanced in terms of Nodes and travel distances, you don't want Aliens quitting cause they started in the bad hive." This is nasty chicken and egg stuff though, cause I don't think you'll know this until you actually see the game in action. But without maps there is no game to see being played.
For example, one or two maps designed by your hired, official leveldesigners could be documented from beginning to end.
What was the idea? What did the concepts look like? What is the levels 'niche'? And so on.
Also let the players get a hold of the level itself so they can look at it and see how things work on a real level.
More people would of course be able to add their own levels as time goes, and it would work as their own 'project' site for that level (or prop/model) and also include a commenting section. Any additions to this list on the Wiki itself could need approval from an admin too, so things doesn't get too cluttered if that's the case.
My two cents.
Seriously, tell me what an entity is, what the requirements are, and it's intended purpose is, because the community can run with it. Perhaps include a download for example maps on entity use for reference.
I have to say that, since this is your own proprietary engine, you might want separate documentation for the engine and mapping reference itself, and keep NS2 specific content to keep things simple and clear.
For instance, Doom 3 was pretty consistent with locked doors having a red light or glow around them and a green light for open. It hurts to watch a new player run around ns_nancy in NS1 and try to walk through door textures because the behavior of walls with door textures was inconsistent. Some doors opened and closed without switches, some required switches, and some weren't doors. The hud improvements in 2.0 helped with the minimap, but most people will learn which paths are possible quicker when they have visual cues.
A consistent UI or rules for how welding is allowed to affect things is probably necessary too. This was one of the things that didn't get used too often in the old NS maps and was inconsistent in the case of what welding did to the map. Welding on ns_bast, for instance, could block a vent in marine spawn or trigger an explosion in the room just north of feedwater's hive. Strangely, the explosion occurs right next to vents, so you get confused. It also dealt friendly fire damage, which sucks to find out when you're in the middle of a match.
-Little updates of the guidelines regarding the finer details, limits or in case something doesn't work well, especially since KFS and dux are getting more and more experience with the engine and editor.
I'd include perhaps a few tips on preventing player frustration. For example...
- Go easy on the noclip brushes. Invisible walls tend to annoy the heck out of a lot of people and get in the way of immersion.
- Don't make maps that damage players too much. That's what the other team is for. Having a "furnace room," for example, that slowly damages all players inside, can anger a lot of people.
Of course, you will need to add some info in the layout section regarding the res node-linking goodness. Tips on how mappers can "channel" infestation would probably be nice, too. Mappers will also apparently need to pay a lot of attention to ladder placement, as well, since they will now give marines an advantage over onoses (or so it seems... )
Oh, and Crispy's recommendation of stats would be very useful. DPM of weapons, jumping height, jumping distance, onos awkwardness (blech), burritos per second, etc..
Level design and game design naturally influence each other, and for a mapper who has not yet seen the game in action, it is all but impossible to divine the envisioned gameflow (This, I think, is KFS' genius: Veil's layout hit on what makes a NS map that plays well from day one.). Setting up an example layout with explanations of what to look out for ("starting locations <i>this</i> many chokepoints apart", "<i>this</i> ratio of resource nodes to rooms", etc.) will allow mappers to build to the design spec, as opposed to the development team having to design around the assumptions of the maps that prove the most popular, which was always the danger of the traditional route.
Sure, some mappers will just copy that base layout, but seeing Star Craft's tournament-grade maps, I'm not even certain whether that's a downside.
For the guidelines:
Gameplay-Information (how many technodes, how far apart from each other, required entities, necessary specialities (readyroom?))
technical documentation (entities)
and the other necessities enough people already mentioned.
Also I would really appreciate if you would describe your internal way of mapping: What's the start for a new map? How to build that into a greybox-level. Why a greybox-level?
A little step-by-step description of your internal process.
This could help the creation of balanced, gameplay-oriented maps because more people would start planning their map befor decorating it.
for great level designer but beginer in the NS gameplay concept you can add a point about diffrent concept of the game and
common/prefered map's structure
The important unit and size. Like jump distance, onos height, one unit in the editor = x inch/x meter, maybe the time needed for some important actions.
Some LUA scripting examples for gameplay modification in an advanced part of the guidline, you may have to put some restriction in this part
of the guidline: "how to keep NS feelings in your maps when you made LUA scripts"
Engine limit and restrictions. Some optimisation rules in your engine.
Explain in details the most important entities
Lighting specific attributs to let us know what kind of ambiant effect we can do
What type of sound we can put in the game, can we had mp3 or ogg, it's a mono/surround if it's need naming convention, CUE/label, Hz limit/bit rate...
How to make texture (format/size limite) animat it can it be transparent, how? If you use shader, how to use them etc...
How to debug
How to made a model from <common 3D Soft tools> into the game ( how to export, what we have to do if it's an animated one, where we put the texture...)
A wiki can be a good idea and a forum for let everyone talking about what they do and what they can do (or ask for some helps)
Hope you can release a guid for plugins/mods I pretty sure modns.org community want it :D
A search bar and putting the table of content down the side of the page would be cool, so you can always get to it.
JUST STUFF THAT IS LIKE THE SOURCE SDK WIKI. <a href="http://developer.valvesoftware.com/wiki/SDK_Docs" target="_blank">http://developer.valvesoftware.com/wiki/SDK_Docs</a>
But don’t include external links, because they just end up getting lost and then future new mappers will have lost loads of tutorials and useful information.
Make it so that anyone can pick it up, without knowing anything about mapping. At least then you will get new blood in and with that some interesting (not always good :S ) new maps.
I know you are only asking about the guidelines, but since you are releasing a load of new tools, I’m assuming you will have to include some tutorials with them and I think the Source SDK wiki is a pretty good example of making the learning curve for new mappers a hell of a lot easier. So that’s why I am suggesting that you include something like that.
Keep up the good work! I’m very excited now! :)
QFT. Would be nice if there was a mix between the Valve wiki and the old NS mapping guidelines.
<!--quoteo(post=1714215:date=Jun 26 2009, 04:17 PM:name=Crispy)--><div class='quotetop'>QUOTE (Crispy @ Jun 26 2009, 04:17 PM) <a href="index.php?act=findpost&pid=1714215"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Finally, not necessarily part of the OMGs, but if you have a throwaway level that you can do this with, making a source of a map available would probably be very useful to new mappers, even if it were just a tutorial level. Giving a reference for how to set up certain entities and tie them together using your tech would be helpful for most people.<!--QuoteEnd--></div><!--QuoteEEnd-->
I repeat this for the 50 millionth time, but yes, source = happy Chocolate.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Oh, and one more important thing: Start with a detailed step-by-step tutorial on how to setup the editor correctly so mappers don't have the problems like they often do in Hammer.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Basically we'd need a nice little list of DOs and DON'Ts. For exaple: "DO put at least 5 Tech-Nodes into the map. DON'T create locations where a MASC could reach two Tech-Nodes at the same time.".<!--QuoteEnd--></div><!--QuoteEEnd-->
The entirety of Jazz X's post here: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=106780&st=0&p=1714243&#entry1714243" target="_blank">http://www.unknownworlds.com/ns2/forums/in...p;#entry1714243</a> (yet to figure out how to add hyperlinks)
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I think the hardest thing about getting past the mapping learning curve was just figuring out the tricks - this is why I highly advocate even a few basic video captures of some of the basic but innovative processes. There are a lot of little things a person can pick up just watching the process of another mapper.<!--QuoteEnd--></div><!--QuoteEEnd-->
Perhaps this can be an alternative to adding pics and stuff to the guidelines - keeping the simplicity of the old guide while helping the n00bs to = a pro mapper?
These are my thoughts, from other mouths =).