Counter-Strike 2: The mapmaker playtesting guide (counterstrike focused)

On the most fundamental level playtests are a way to confirm your ideas work with the gameplay of Counter-Strike and your level is fun to play!

…And on a deeper, more…murky level it’s to ensure that players will keep wanting to come back to your map. Players will quickly get bored or annoyed if your map has a design flaw like an area feeling unfair or one strategy having much more success than any other. This can be the death of a map so we try our best to help each other iron out problems. Normally the best way to find these issues is throwing players at the map.

While it’s great to playtest your maps sometimes it’s not really a great use of your (or the playtester’s) time. Learning when it is best to arrange a formal playtest is a skill within itself.

If it is your first playtest of a map ask yourself if it is ‘complete’ enough to play – For example: would a normal player find things to abuse, is it properly clipped with all objectives and areas added as you intend them to be? Will players be able to navigate the map or will they get lost? One thing I’ve noticed is that players really like some level of navigation around the map; colour coded areas in greybox, bombsite arrows and markers etc.

Make sure to follow Exodus’s brilliant guide on the dos and don’ts of CS level design to find stuff you may have missed that should be fixed before a test!

The dos and don’ts of Counter-Strike level design: https://steamcommunity.com/sharedfiles/filedetails/?id=1110438811

If it is NOT the first playtest of your map but you’d like to test again you should ask yourself if you dealt with the biggest parts of feedback from the last playtest well enough (don’t worry we’ll go over implementing feedback later in the guide) to warrant another test. You should be considering if the test is a good use of everyone’s time.

Playtests can be a stressful experience for new and experienced mapmakers alike, suddenly having a lot of eyes on your map at once can be quite overwhelming. Don’t be dismayed though, just focus on how people interact with your level and what they say about it. When booking your first test make sure you can attend the test personally! It’s a vital part of the process to interact with playtesters after the test and not all playtesting services offer demo files afterwards.

Remember that the first playtests of a new map will never go completely smoothly; flaws will almost definitely be found so you should keep something to hand for writing down observations and notes to give yourself a working list of problems to fix after the test.

Simply observing how players Interact with your map can lead to very useful non-verbal feedback as you can see how new players understand your layout. For example: do players try to open doors that are just scenery? Do players miss important paths or not use the designed cover as expected? Noting these issues and redesigning as applicable will make your map more welcoming to newcomers.

It’s heavily recommended that you do not start pushing back against feedback during the playtest. You may not agree with everything said by players but publicly arguing back against it can cause players to be less likely to share feelings with you or amend their feedback to avoid contention.

A lot of playtesting services will then offer the chance for players to share their feedback directly to you after a match or two on your map. Try to capture all feedback as it’s given in a way you understand and if you don’t fully understand something you should ask questions until it makes sense in your head.

Again it’s important you don’t argue with feedback during any sessions like this. Even if you completely disagree with what is being said then keep to yourself. Sometimes it turns out a player is correct and it takes a mapmaker a lot longer to understand where they are coming from. Feedback will always be colored by the players’ personal experience during the test and often players express their feelings and experiences as problems with the map design. A player might say “This map is really poorly balanced, CTs are way too strong” because there was an imbalance in the map or because there was an imbalance in the teams during the test.

If possible you should spectate whoever is giving feedback to see what they are seeing, the visual element can often help mapmakers understand the points being made. Following on from this if you don’t understand the reasoning and improvements behind a suggestion a player made, ask them why they feel that way, this – again – should improve your understanding around the problem even if you don’t agree with the fix proposed. During a feedback session it’s best to take in everything said rather than try to start mentally fixing issues there and then.

Sometimes two players will also give you conflicting feedback on your map too. If possible you should watch the playtest demo back from both perspectives to try to understand where both players are coming from and work out what the ‘truth’ is behind the statements made. Players sometimes say one thing with conviction but are missing the larger context of what happened elsewhere in the game; for example A bombsite only being too easy to take due to a weak player constantly losing mid. The A player may not be aware of this from their position.

Now you have collected all your feedback from your playtest you can attempt to use the information to improve your map. This can be very, very hard to do or very easy depending on the kind of feedback given and your ability as a level designer.

Both objective (factual information) and subjective (opinion based) feedback exist for level design and will be given to you in playtests. It’s important you can tell the difference when you are sorting through your feedback; objective feedback should always be implemented and is thankfully normally easy wins – stuff like fixing collisions, clipping and reducing the chance of exploits. Reviewing and fixing issues based on subjective feedback is where your skills as a level designer are much more likely to shine; everything from balancing issues to areas ‘feeling bad’ will need to be qualified and addressed.

It’s also important to note that you do not need to address all feedback after every test. Sometimes problems can take a while (or multiple tests) to fully understand what the problems are, this can also shake possible solutions free so you shouldn’t feel ashamed to leave issues to the side while you work on other areas and aspects of your level. Not everything is instantly fixable but that is okay!

For subjective issues I suggest not focusing too much on the literal feedback. Instead, look at which feeling or experience is being expressed and then try to figure out the reason the player experienced this. Also when it comes to fixing more subjective issues try to avoid messy fixes; for example making snaking paths as an attempt to fix bad timings to engagements isn’t going to help the gameplay feeling on your map, if your design is going to work it will be possible to make it work cleanly and without hack fixes.

If your map is heading in a good direction then you will be most likely having more and more refined feedback with every test. Often it’s found that at the start of development you are likely to get feedback that require large changes: things like structural changes to the map, new paths and rethinking bombsites. With time and the correct iteration smaller changes should be needed: maybe moving cover slightly or changing wall textures so players stand out better. The truth of the matter is that there will always be feedback and things you COULD improve; Valve are still updating their maps 20 years after first release…as a mapmaker you need to know when a map is complete in your eyes and when you can move on to your next project.

Once you have implemented your first wave of feedback you should arrange another test to confirm you have fixed the issues presented to you in your first test. You’re likely to get new feedback you weren’t expecting too but don’t be dismayed by this!; map-making is a marathon, not a sprint! Lots of feedback just shows that players are engaged with your level.

No one, not even yourself, is ever going to be perfectly happy with your map. Every design has flaws, every player has their own tastes and polishing a map means finding a balance of those things that you think is good. Try to recognize this point and move on to the art stage. Don’t get stuck aiming for perfection, it just does not exist; as I mentioned in the previous section not all players will ever be 100% happy so you could easily end up on a never ending treadmill to nowhere if you try to appease everyone.

Don’t base all of your map balancing and design off of one test. Team balance can massively impact the feeling of a level so try to play with different groups of players and communities. Remember that you are trying to make a map that will be accepted and liked by thousands of people and not just 10!

Hopefully with time you will feel less and less need to playtest your map further with dedicated sessions. Your map then may now be ready for something on a wider scale like the Mapcore hubs for hundreds of games with only small tweaks to layout and bug fixes. This amount of games can start to show wider trends in statistics that would not be apparent from single games.

You may get the chance to playtest on a big platform like Mapcore’s FACEIT hubs. If your map gets featured on a big platform like that your map will usually be played by a bigger, independent playerbase with “normal” players (non mapmakers) – so the feedback might be vastly different from the first playtests.
These large scale playtests usually entail that players discover bugs or other issues that were previously not exposed in the smaller batch testing. Due to the very many games that a map might get, there are many opportunities for feedback.

To get the best amount of feedback possible, there’s a few things we recommend to do and to avoid.
Do:

• Many small updates
• Have good radar (!!!!) and player navigation (e.g. callouts written to walls)
• Talking with players
• Use social media/discord
• Post change logs where players actually see them
• Mention players who reported issues in change logs

Don’t:

• Push big but infrequent updates
• Change workshop submission
• Expect players to contact you about the map on their own (the ones that do are usually not the kind ones)

While looking at demos and watching games is a good way to gather issues to fix, many things can only be found by looking at the bigger picture. The easiest way to get a more broad overview about how a map is being played is by looking at data from multiple games.

This data can show tendencies on how players generally like to play your map and expose areas or bomb sites that are not working as intended.
It is for example possible to see which bomb site Ts are more likely to plant on, or on which bomb site defuses are typically more successful. If these statistics are vastly unbalanced, players are usually not having a great time.

Heatmaps can also help to discover spots where unusually many players on either side die, which can be caused by overpowered angles or broken sightlines.

One way to get this data is by using CS Demo Manager to analyze matches and a BI software (or even excel) to display the data from the analyzed matches.
While that as a solution is not quite elegant, it enables you to look at whatever match data is available through the demos and can help identify why players might not love your map (yet). A tutorial how to do that with a Power BI report can be found Here [docs.google.com]