Blog Archives
« My Second Map CS:S Credits »
Keeping CS Maps Fair (May 7, 2005)
Occassionally I like to download a few amateur CS maps, just to see what people are up to with the game. Most of the time, I'm fairly impressed, but there are always portions of these maps that make me cringe due to some very basic mistakes in very critical areas.
`Mistakes' of course, is possibly too strong a word. It's usually of what's missing than what is `wrong'. These aren't technical errors, merely a lack of understanding about how gameplay will flow around the map.
Fairness is of course vital for any CS map. While it's hard to test (and even harder to achieve), it should always be a top priority. Actively thinking about it is one of the most basic steps that seem to be forgotten, despite how easy it is to make some basic checks and assertions about how a map will play.
For me, this involves picturing an overview of the map in my head, and working out the areas where both teams are likely to conflict first, or make first contact. Typically, if I've got the design right, both teams at this point will be in areas designed specifically for this moment.
The most basic check here is to ensure that any geometry you've placed that could be exploited by a team - for example a crate offering some protection, or a very narrow opening in a wall that a player can hide behind - can always be countered. If one team has an advantage, always ensure the other team has some obvious way of countering it or protecting themselves from it. Try to ensure if one side makes use of their advantage, and the other side makes use of the countering measure you put in, everything is even again. Everything can be cancelled out.
Of course, it's never quite that simple. Countering the advantage of a simple crate is not just a matter of giving the other side a crate as well. The key is to give both teams equal opportunity to succeed. Anything should have an obvious counter-attack, one that can be quickly assumed (typically a few seconds). Every advantage needs a weakness.
As a well-known example, consider the underpass in Dust. In the first version, CT snipers had a clear advantage - Terrorists had no means of avoiding being sniped at. This then changed with the addition of some crates, but it was still hard for Ts to make progress without exposing themselves. The crates were then fiddled some more such that a T could get almost completely through the underpass without a single sniper spotting them, making for a much fairer gameplay element.
Often it's fairly easy to find problem areas. Where two teams meet in a conflict area, I picture what sort of view each side has of the other team and put myself in the shoes of a player. If, given the choice, I could choose which team I could be in at that moment - which would I pick? If the choice is obvious, that area probably needs work.
Generally, it boils down to predictability. If you can predict where your enemy is likely to appear, make sure the enemy could also predict where you are. If they have multiple options, so should you. This can always be easily checked just navigating around with the camera in Hammer, and trying out various positions.
After a while you start to get a feel for what's right, and it should come naturally to check for features like these. Best of all - just a few minutes work can really help locate potential problems and improve gameplay.
« My Second Map CS:S Credits »
user comments
m0nKeY at 18:35 on May 7, 2005
Another well written article, with some more useful insight into mapping. :) It's nice to see you giving more to the community than just your maps, helping other people to progress. A lot of people tend to forget they was once an amateur and required help, thus not helping others to progress as they did.
dave at 18:52 on May 7, 2005
Thanks, glad it helps. I'm planning on writing a lot more like this, just covering stuff that's never mentioned anywhere.
This post would probably have been a lot better with pics. I'll probably update it in a few days with some examples.
smeerkat at 19:28 on May 8, 2005
I'd also like to see a Tutorials section here, advanced stuff not the first-room types.
dave at 23:07 on May 8, 2005
No way am I writing tutorials! They go against the very fabric of level design. Design needs insight and understanding, not instructions.
smeerkat at 02:15 on May 9, 2005
You made Baby Jesus cry.
dave at 09:39 on May 9, 2005
Well, it's the way it should be... Tutorials should teach technical details and design basics.
All I can/want to provide is insight into how I design, because it's by no means the only way to do things. There's a point where things change from being "this is how it's done" to "this is how I would choose to do it", and the latter is the more interesting simply because there is room for opinion.
That's why level design is so fun - it actually lets your own taste and style show through, whether you want it to or not. The exciting bit is the high stakes - if your style doesn't appeal to players, you end up with something that few enjoy playing...
Site designed and maintained by David Johnston. Products mentioned may be registered trademarks of their respective companies and I probably haven't asked to use them.
Powered by UH-Hosting, PHP, MySQL and Smarty.