Map of dreams: how our player community became game content co-authors

Map creation process — with a twist.

It’s hard to argue — games are made to be played. At the same time, players usually have minimal participation in the development process; this is limited to external playtests for testing ready-made features and content.

Still, at Pixonic, from time to time, we practice creating content with direct participation from the community. What does that entail? At certain stages of development, we ask questions about content, the players answer them, and the most popular answers form the basis of the content unit design. This injects a sense of fun, and liveliness, and it gets the players involved in the process — a win-win for all parties.

I’m Denis Kozin, Senior Level Designer at Pixonic, MY.GAMES. And today I’ll tell you how we designed the Abyss map in War Robots.

First, a few words about the game: War Robots is a multiplayer shooter where players pilot huge robots and fight each other on teams of 6. Each battle takes place on a random map, and the main mode involves capturing and holding beacons.

Planning

Before we talk about what actually happened when our community became a map co-author, let’s lay out the plan we developed. We initially discussed the kind of questions to ask the players with community managers and artists. It was necessary to take into account some logical restrictions:

• To reduce the likelihood of gameplay problems, we decided to keep the layout — the “skeleton” of the level — at our discretion.
• The visual elements had to stay within the framework of the game style and the project’s technical requirements.
• It’s better to ask players only about aspects that really give a feeling of development involvement when changed.

We also needed to think about when to ask players questions to avoid extending the already protracted development process too much. That usually looks like this:

• Concept: a level designer generates concepts for the map and, together with the art department, chooses the most suitable one.
• Prototype: based on the concept, we create a gameplay prototype from primitive geometry, then send it for play testing.
• The visuals: the approved prototype is then sent to the art department, where the artists use it as a basis to create assets and adjust the map’s appearance.
• Release: the map is implemented in the game, and we continue to monitor its metrics and player reactions.

We were also allocated resources to create new mechanics specifically for this map. Map mechanics are interactive elements; for example, on some maps there are areas that instantly kill player robots or cause continuing damage to them — this can be water, lava, or something else. We don’t often add mechanics for maps, so, since there is an opportunity to do so, it’s worth taking advantage of it, because we can use it to build interesting gameplay.

Taking all this into account, we planned the player interaction as follows:

• During the concept stage, we ask questions about the setting and mechanics of the map, and based on that, we choose a concept for further development.
• In the prototype stage, we ask players about the appearance of the map as it relates to the concept.
• By the visual stage, we should already have an idea about the appearance of the map and its gameplay. Full-fledged production begins, and the period of direct player influence comes to a close.
• At the release stage, we collect player opinions about the new map and compare them with our expectations.

Now that we have a rough plan, we can move on to its first point, and start working on the concept itself.

The concept

A concept document is a description and justification of map parameters, such as the setting, mechanics, size, and so on. This is needed to create a prototype with suitable gameplay.

To develop a new map, we decided to take the game’s most popular parameters (and at the same time the least commonly occurring): we wanted to make a map not only with interesting gameplay, but also to maintain its diversity within the selection of all the other maps — which, come to think of it, already counted 12.

To determine the most popular parameters, we conducted a player survey about all the maps in the game: the most popular, in which modes, and so on. Here are the results:

• The most popular setting is space. Nature, cities, and post-apocalyptic environments fall behind that just a bit.
• The most popular map is the base on the moon. We took note of some of its features for the new layout, for example, the close proximity of the beacons and how the battle has a quick start.
• For favorite map size there was no answer: the majority decided that the main thing they appreciate is variety. So, nothing prevents us from making a map of an “unusual” size.
• There was a positive attitude towards unique map mechanics — more proof that crafting new mechanics is a good idea.

At the same time, we analyzed the maps in the game to determine the “rarest” parameters:

• The rarest setting is space, post-apocalyptic and within snowy environments, which largely coincides with popular settings.
• It was rarest for maps to have a large size.
• A rare combination of combat distance was long distance mixed with close combat, with no emphasis on the middle-range battle.

Having combined the results of our survey with map analysis, we came up with our ideal parameters: a large map for long-range and melee combat with a quick start to the battle proceedings along with new mechanics, and for the setting: space, nature, or post-apocalyptic.

So, we’ve already received some settings that are both popular and rare:

• Space
• Nature
• Post-apocalyptic

Things were somewhat simpler with the mechanics — we already had some thoughts on this. Let’s look at some of the things we considered.

Teleportation. The instantaneous movement of robots between given points. These mechanics could advantageously increase the dynamics of the battle, not only on the new map, but also on some older levels.

A dynamic damage zone. This is the next stage in developing a mechanic that already kills players on some of our maps, only now, this zone could be switched on and off during the battle.

Atypical beacon placement. The classic number of beacons on our maps is five, which are located according to a couple of standard schemes. An unusual arrangement (or even quantity) could greatly re-energize gameplay.

Since it was impossible to conduct all the surveys and process their results in one day, we decided not to wait. We immediately began to generate ideas for a possible final concept. Every possible combination of setting and mechanics had to be considered, so, by the time we were finished, we had the results of the community’s votes.

The players chose the teleportation mechanics and a natural setting, so we chose the snowy environment as it is the rarest one:

In terms of collection, we needed to gather a large amount of data from many regions across the world, so surveys through social media tools weren’t suitable for us. We first used Google Forms and then switched to surveymonkey.com. This site allowed us to create convenient, multilingual forms with the necessary format, logic, and submission with a single link for all survey participants — all of which meant we could collect reports faster.

Conceptually, the polar cap of Mars and the kimberlite pipe suited the parameters for the map we decided to create. The pipe is a huge funnel in the earth where diamonds are mined. A direct reference is the Mir mine in Yakutia. In the first case, we have a Martian colony at a junction of snow and sand, and in the second, a futuristic mine over a giant abyss.

Of these two concepts, we chose the second option as we considered it the most interesting; it could organically combine, not only the new teleport mechanics, but we could also implement zones that deal damage to players.

So, our future map is an industrial platform installed right above the kimberlite pipe. It contains teleports used to deliver equipment and personnel underground. In the course of gameplay, suddenly, a volcano will erupt near the mine, and lava will flow into a funnel and destroy the platform.

We usually provide a schematic layout right in the concept document.

We see the location of the beacons in the left picture, and the planned player movement in the right one. In our case, it’s designed in the form of a figure eight along the front line from beacon to beacon. Teleports support traversing this figure eight, instantly moving players between different ends of the map. At the intersections of the circles are arenas: one for melee combat, the other for long-range battles.

Prototype

A prototype is a map layout assembled from primitive geometry within the engine. It’s much faster to work with primitives than with well-developed 3D models, and moreover, they accurately convey the gameplay on the map, and this is the most important thing during the early stages of development.

For example, in the first iteration of the prototype, one large flat platform felt rather boring, so we began to tilt it, experimenting with vertical drop. Major layout changes like this can be quickly made on primitive forms.

So, the platform ended up with a slight tilt, and this added dynamics and emphasized the idea of destruction. The elevation changes made it visually more interesting and easier to comprehend.

We run the first iterations of a layout through internal testing by the project team. At this stage, it’s important to evaluate the gameplay; the effectiveness of weapons of various ranges, the usefulness of hiding places, and so on. Based on the results of the playtest, we collect feedback, change the layout, and test everything again. And after we have checked the prototype inside the studio, we can proceed to the next stage, external testing.

In order to test the gameplay on the map in conditions as close as possible to the game on the production, we need 12 people in each battle. And it’s better to repeat this. We can’t afford this at internal playtests, so after running the prototype on the team, we send it to a special test server, where we conduct weekly playtests with players and collect their feedback.

For example, when we ran our tests on a large number of players, it turned out that it was necessary to change the geometry of the blue building in the center: many players simply passed through it in order to quickly get closer to the enemy and the rest of the map was barely used. We changed the building geometry to split players into two groups near the arenas suitable for collision.

In addition to checking the gameplay, external testing also tests the performance of the map. Each player uses their own combination of robots and guns. Everyone plays from different mobile devices, and the map should work without lag and crashes on each of them. If it crashes, this means the layout is technically overloaded and it needs to be simplified.

In external testing, we collect not only player feedback, but also statistics about their behavior on the map: the percentage of victories of different teams, the duration of the battle, and early exits from the match. This data helps evaluate the map in terms of gameplay and can signal technical problems. By analyzing feedback and statistics holistically, we can determine further improvements to the prototype.

In parallel with testing the prototype, we continued to interact with the players, and we decided to hold a contest: the players had to propose a concept for one of the key buildings on the map (it’s marked in green in the picture below). This structure draws a lot of attention to itself, but it’s not directly involved in gameplay.

The contest was organized by community managers: they collected the concepts and made an initial selection, and the level designers and artists would choose the best one.

The concept in the picture below was chosen as the winner since it was the most appropriate in style and scale, not to mention well-designed. But unfortunately, we weren’t able to implement it.

The building is divided into two parts with ramps, bridges, and passages. This idea didn’t fit into the geometry of our prototype in terms of gameplay.

So, the winner was given a well-deserved reward, but the artists used only some elements to design the entire map. They are highlighted in green in the picture below.

In addition to the contest, we asked the players to vote for the visual aspect of the buildings on the map and the teleport platform. The artist depicted three concepts for the players to choose from:

The building represented a set of elements that would be used for all buildings on the map. And we singled out the teleport platform separately as an important object representing the new mechanics:

The following options won: a light building with massive shapes and a round teleport platform.

So, our initial data for creating an atmosphere was formed — a visual concept of the entire map, which captures a general idea of its appearance. The concepts selected by the community, and, of course, the layout of the map itself served as initial data. We presented the final atmosphere to the players along with one last question before the start of production.

That question? The name of the map. It’s better to conduct this survey before the start of asset production, because this name will appear in their names and it’s better to decide in advance instead of changing them later.

First, the community managers collected all the names the players were able to generate. Of these, we chose the three most interesting ones and held a vote.

That’s how the map came to be called Abyss — a reference to the huge abyss filled with lava on the map. From this moment began the most time-consuming component of the work — working with the visuals.

The visuals

We freeze the prototype and don’t change anything and the art department works on its geometry. The artists draw clarifying concepts, and modelers create objects based on them. The level designer only has to support the work of the art department, resolve arising issues, and ensure that the geometry doesn’t change too much when assets get added.

As soon as the first versions of object models are ready, we organize another external testing session to check the gameplay. We want to see if it has changed for the worse with the addition of assets, and whether the original wall collision and directions of movement have been preserved.

Beyond gameplay data like the percentage of wins, We simultaneously check performance indicators: these include average FPS and the percentage of crashes on different devices. If something is wrong, we need to optimize the map.

As soon as we see that the map is working fine with the new models, the final stage of production begins:

• Small decorative props are created.
• Visual and sound effects, animations are added.
• Textures and lighting are customized.

The visual stage lasts quite a long time — about six months. For comparison, the concept and prototype stages combined take a couple of months. So, in order to remind the players about the upcoming release of our map, we decided to hold another contest.

According to the lore of the game, the mine is owned by one of the paramilitary corporations, so it would be logical to use its symbols on the buildings. We invited players to design the new faction emblem themselves. The community managers organized a contest, and the players sent in a lot of cool artwork

The artists chose one logo, which eventually began to adorn the buildings of the mine.

At the end, we send the map for final external testing, where we first check how well the users can get everything that’s happening in the frame: whether the robots are visible against the background, whether the range of objects is easily distinguished, and so on. Of course, we also continue to monitor performance indicators.

At the same time, the QA specialists begin the internal testing of the map: they carefully check the scene for all sorts of problems: robots getting stuck, texture artifacts, backlight bleeding, and so on. If something goes wrong, they report bugs, and set tasks to fix the problems.

As soon as we‘ve fixed all the critical bugs and made sure that the visual aspect is good, we can release the map for production.

Release

Finally, the map makes it into the game.

But the process didn’t end there. The community managers and technical support team monitor player feedback and send us any problems they see on the map. At the same time, we monitor the performance of the map through our analytical system. The technical specialists control the performance data, while the level designers control gameplay metrics. This data is more relevant than ever, because the map is no longer testing. If there are anomalous deviations in the percentage of team wins or battle durations, it’s better to work on the map a little longer.

In addition, analysts and technical support specialists conduct a survey after a release, asking players about their impressions of new content. And, if a new map is released in an update, then, of course, we ask about it. We ask a few general questions about the gameplay and visual aspects. The results of this survey can say a lot about how well we chose the setting and designed the layout.

For the Abyss map in particular, the community managers tried a new activity: players were asked to submit successful combat tactics for the map. For them, this was an opportunity to receive in-game prizes and share their ideas, and for us, it was information about the actual behavior of players on the map: how they used the new teleport mechanic, in which zones they fought more, and so on. This helped us understand if the map design was working the way we had intended.

Conclusion

You’ve seen how the process of creating a map on the War Robots project generally goes. We pay a lot of attention to testing, player surveys and data analysis, from concept to post-release support. This helps us evaluate the gameplay on the map and correct it in time if something is wrong with it.

But for the Abyss map, interacting with the players brought a lot of features to the overall development structure. Together, we chose the setting and new mechanics, the appearance of objects and the name of the map. We held contests for the concept of the central building, the logo of the faction, and effective battle tactics.

Concept (~1 month)

• Map parameters
• Layout scheme
• Survey among the players + map analysis
• Questions about the setting and mechanics

Prototype (~1 month)

• Geometry made of primitives in Unity
• Internal and external testing
• Feedback analysis and follow-up work
• Contest for the best concept of the central object
• Questions about the appearance of buildings and teleport
• Map naming contest

Visual part (~6 months)

• Object models
• External model testing
• Props, effects, lighting
• Final external testing
• QA testing
• Contest for the best faction logo

Release

• Monitor player feedback and complaints
• Monitor technical and gameplay metrics
• Contest for the best battle tactics

We’d like to point out the people who participated in the activities for choosing the map parameters: about 7K people took part in surveys, and dozens of people took part in contests.

A great effect was achieved simply by sharing with the players the details about the development of the map from the very first conceptual stage. This fueled their interest in the map, the game in general, and allowed for more positive communication in the community. So, as soon as the development of another map begins, we plan to regularly share news about it: beautiful pictures and shocking details. Maybe we’ll come up with some new parameters to collaborate on — who knows?

You can also watch a video from the community about the creation of the map, which we published before its release: