Bull in a China Shop or How to Stick to Schedule in Times of Change

Learn how to organize work within the team and how the Pixonic team changed their approach when they were beginning to work on the War Robots remaster.

Introduction

In gamedev, remastering is the name of the game. We have been exploring the topic for quite some time now with our War Robots case: from various aspects of pre-production to external tests and new map development pipelines. It’s logical to assume that changes in the technology stack would require improving internal processes.

This is what I will be talking about today: organizing work within the team, and how we changed our approach when we were beginning to work on the remaster while simultaneously switching to WFH. Since I am a 3D environment artist, I will be mostly talking about what was happening with level design in our company.

For clarity, before we begin, let’s introduce three terms:

  • Legacy – maps in their original technical and visual state
  • Refresh – a transitional state where maps are partially redone to improve their visuals without remastering their fundamentals
  • Remaster – a broader scope of work than a refresh, which includes all iterations of graphical and technical changes to come.

Urban zone on Springfield map in legacy quality

Urban zone on Springfield map, remaster in progress

Now that we’ve got that out of the way, let’s move on.

The Processes

Historically, when it comes to developing legacy maps, the spotlight is on the senior 3D environment artist, while the team could number from one to three people depending on the task and the situation within the department.

Below you will find a timeline for team member numbers broken down by month per each map, under the assertion that each legacy map takes four months to complete.

Previously, the process of interaction between the team was much simpler than it is right now. The pipeline was simple, too, as was the entry point in the process of expanding the team: at any moment, new tasks could be set for any artist in the department, employing them for urgent local tasks or on a more permanent basis.

As soon as the remaster’s technical rails were laid, we had the task of making a new map called the Abyss. This is when we understood that technical changes are inevitably bringing organizational changes, too. The production of one map by one artist now demanded 6-7 months instead of the previous 4. We needed a new mindful approach to production organization, and to level up our teamwork: we needed to move away from lengthier production cycles towards streamlining processes and their optimization. 

One of the key decisions we made was to have one person do all the map building. Previously, we had every artist working on a project make their own changes to it, which could potentially add bugs or errors. Now, this process became a bottleneck in scene building: this became a deliberate narrow point of interaction between the asset-generating team and the lead who is doing the scene building, and it led to a reduction in incoming error numbers and in conflicts between build versions. 

Every map means having a huge number of various objects with each having collisions, LODs, decals, and additional masks. Checking every single one of them when reviewing work would mean all work on the scene grinds to a complete standstill. This is why we have introduced cross-reviewing content into our processes.

What does that mean? Cross-reviewing means the team inspects assets pre-emptively to eliminate glaring mistakes that the artist becomes unwillingly ‘blind’ to after working too long on the same draft. This is something that can happen even to the best of us as it is purely mental: our visual assessment declines the longer we spend working on the same object or sets of identical objects, hence we become unable to focus on details.

Setting a special cross-review date at least once every other week yields positive results through recalibrating focus and rebooting emotionally. This practice enables the lead and peers to engage in passive analysis of others’ work. And this is not just about spotting mistakes – it also generates an opportunity and precedent to exchange experience in modeling, texturing, and using internal tools. 

Exceptionally successful models and their elements can be reused later, because why would a new artist on the project need to model a unique door or wheel unless it’s the task at hand? Your best windows and ventilation shafts can be shared with the rest of the team via kits. Needless to say, ready-made objects usually come tested and immune to local errors. This is how our base models or their elements become homogenized. 

Using objects from a game asset kit

Range of elements in a game asset kit

Texture space in use for a game asset kit

A huge bonus when cross-reviewing is the opportunity to analyze your colleagues’ strong and weak sides: this provides great support when planning further work and, as a result, more accurate risk forecasting when setting deadlines for major tasks.

Teamwork and Artboard

The remaster wasn’t the only factor at play for initiating change. Momentarily, we found ourselves in need of more than just technical changes – the general work paradigm changed as we needed to move to work from home. 

Our priorities on updating maps changed as well. Getting a remaster going is a more complex process, technically, as it requires integrating asset bundles and splitting scenes. Not only did the pipeline become more complex and demand change – it launched a production chain reaction with a cascade of inseparable tasks along the way.

Working on maps was split into two streams: there was the remaster, and then there was the refresh of legacy maps. It was impossible to redo all the maps straight away, but it was vital to switch them all to new shaders. This became a real challenge for developers, as they needed to overhaul the full production chain, from concepts to technical reviews.

We’re getting close to the topic at hand. Creative teams rely heavily on visual communication, especially in our times of WFH. So, what we found mega useful apart from task managers and reference boards was the artboard.

How are they different from refboards? A refboard shows multiple reference images to illustrate concept and idea, while an artboard wraps up the refboard and the whole development process combined.

We used Miro as our main tool: on one hand, it’s simple and intuitive, and on the other, it brings together the whole team refboard while allowing you to systemize it, form and decompose tasks, and boost teamwork.

Refboard. Space for ideas and concept-related solutions.

Artboard. Space for micro-management for the whole team.

With artboards like these, devs are more actively involved in discussing and analyzing information, while the process in general and everyone’s input become transparent for the whole team. It’s also truly convenient, so I wouldn’t be surprised if some time down the road we will see ‘board manager’ or something similar appear as a new staff role.

Sensible micro-management with the use of artboards is an effective element of planning and boosts teamwork. It helped cut down the time required for one map’s remaster to 5 months from the previously expected 6-7. 

Above you see an example of such an artboard. Let me illustrate it better now. Here are the blocks it is composed of:

Our daily team meeting is also inseparable from working on the artboard. This is an important step in organizing the team’s cooperation. These meetings are held the following way, usually:

  • Opening words and agenda
  • Analysis of new content on the artboard
  • Acknowledgement of completed work
  • Objective evaluation of risks and task priorities
  • Compiling a follow-up on what we have agreed upon
  • Informal communication (if there’s time)

These meetings can happen in various formats. We can have a host, for instance, or just take our turns talking. The host or moderator is needed when our meetings start running too long or become excessively emotional.

The meeting itself becomes a marker of what is happening, helps understand the workload of your colleagues, and, ideally, should aid in distributing tasks equally and to the best people for the job, if it is moderated by a lead. These meetings also enable spotting things that are not evident as they provide the opportunity for in-depth analysis. If we are seeing informal communication dominate over discussions on key tasks, that means the team is rather relaxed and is probably having less work to do than they should be doing. The opposite is evident if there’s no time for informal talk while the meeting carries into its second hour. These meetings also rarely give room to overly emotional behavior, but if they do, then you should start identifying conflicts within the team and analyzing all internal processes. Quite often, you will find it is worth reconsidering priorities and timeframes, and maybe it is time for decision optimization. 

So, in the end, we have the following interaction map:

  • The artboard and the single communication space for the team
  • Daily team meeting and artboard analysis, resource sharing
  • Fundamental analysis of team microclimate and 1-on-1 meetings
  • Cross-reviewing and inter-team sharing of experience and tools
  • Work evaluation following the results of cross-reviewing

It’s important to note that the processes above do not exclude but rather complement traditional management models and interaction with project leads – we have all the necessary integration tools for that, like Jira or Slack.

Here are charts showing our pipelines, the previous one (legacy) and the current one (remaster):

  • In the first case, the array of tasks was far simpler, and external management plus weekly meetings were enough. 
  • With the remaster, we have initiated a perpetual inter-team micro-management process with the artboard at its core. External control has been reduced to current progress updates every two weeks.

Both charts share the same starting point – having a scene prototype.

Scene prototype for Springfield based on geometrical sketch

The scene prototype is usually a draft collision model of the level to provide an idea of what the landscape is like, key points of player interest, available cover, and main objects. The level design department is in charge of making these models, and the end result becomes the basis for future location design requests. When you are remastering maps, the legacy map becomes your scene prototype. 

The next step would be to create ambient concepts and drafts. In the new production system for map remastering, we have found it necessary to work through every detail thoroughly when it comes to the concept. The previous system required us only to combine the multitude of textures into one atlas, giving lots of leeways, but the texture quality was inferior.

The new system is based on texture batches which include trim sheets and tiling textures linked to texels:

  • Trims – seamless textures in a single axis
  • Tiles – textures that do not have seams on every side

On one hand, this improves visual quality, but on the other hand, it adds limitations to the number of used textures. In this scenario, it’s a good idea to use a limited color palette at the conceptual stage. I’m not going to delve deep into technical details that have already been covered, but I will note that linking the process to the palette makes work much simpler and reduces production time. You can and should use pre-emptive steps when preparing the final texture kits!

Assembling the general texture palette before the main stages of geometry creation

In a perfect case scenario, tasks of building the final versions of models for a level are based on the finished texture palette. On average, any two different tiling textures require one universal trim sheet. When designing these textures, we proceed from the assertion that anything of arbitrary length and more than 3-4 meters in height is a tile. The earlier and more precisely this palette is defined, the less reason to adjust the models in the process. It is important to understand these issues as early as at the concept stages.

In this way, working on the level's concept is no longer an isolated preparatory phase of development, but is now proactive, with the close involvement of the team. The concept is now based on technical and artistic constraints, and the final models are closer to concepts.

In the examples above, you can see the difference in artistic value, the importance of the concept, and its details:

  • The overall atmospheric concept perfectly conveys the main idea and mood of the map;
  • The second example shows a more in-depth approach in the form of refined concepts that contain the actual technical specifications for the artist. With this approach, there is no question of where to use concrete and where to use metal, no need to spend time analyzing given information - the artist can concentrate on the more important technical aspects.

Shifting the decision-making point from the production process to the preparatory stage allowed us to better structure our work and open up the possibility of outsourcing. When developing legacy maps, it was more difficult to do this: the sudden need for changes in the production process was much more expensive, and there was simply no urgent need to delegate anything.

The new pipeline assumes a basis in the form of a texture palette and texel, which creates the possibility of independent operation of the palette and geometry. Consequently, it is possible to make changes to the textures at any time without blocking or making modifications to the geometry. The geometry itself is textured quite simply and quickly by trims and tiles, allowing overlap. The exception is the channel for using additional masks and lighting.

More precise and stringent requirements for the models create the opportunity for clearer terms of reference. With the obvious increase in complexity from the technical point of view, there is also a window of opportunity to distribute tasks both within the team and to delegate them to outsourcers.

Checklists and Guides

Technical documentation is always the cornerstone in the implementation of new processes. Without a simple and clear knowledge base, the process of scaling the team and delegating tasks is greatly complicated. At the moment we already have all the necessary technical knowledge base on the project, but we are working systematically to create guidebooks and checklists.

In my opinion, no matter how well or detailed the technical documentation is, normally it is an anthology of sorts. Not that it’s a bad thing, but even if a document like that has impeccable structure, it lacks the required flexibility. 

As for the topic of this block, it is largely tied to the processes described earlier. If we talk about checklists, this is a very important part of cross-reviewing. This mechanism should be easy to operate and the most convenient to use in practice in a concise form. Moreover, a checklist developed over time will be most useful. It should be focused on the most frequent errors and weaknesses within the team.

The main task of the guides is to present successful and rational cases, suggesting optimal ways of solving problems within the project toolkit. It is good when you have this information at your fingertips. It is even better when it is supported by visuals. And if the text and illustrations are combined with audio files - that is the best. Again, the emphasis here is on the availability of information and the use of different perception channels. But we are working on this ourselves at the moment. Here, I am simply sharing my experience, which is constantly changing and evolving.

Conclusion

Life is dynamic, changing constantly – just like everything else around us. Changes are inevitable: in the work processes, in goals, and the templates we are used to. War Robots is no exception – the project reacts to external challenges just like a living organism.

A little over a year ago, developing maps was a gradual and laid-back process, and one which wasn’t overly demanding our attention. But then came the day when the project had to grow up and mature with the rest of the industry.

The way the team functioned changed as well. Props to the management here, too, as with their help the team could adapt to the reality of working from home and succeed in rebuilding the necessary processes. These may not be perfect today, but this is definitely a growth point as well as a vector for future development. 

Keep reading

You may find these articles interesting

Join discussion

Comments 0

    You might also like

    We need your consent

    We use cookies on this website to make your browsing experience better. By using the site you agree to our use of cookies.Learn more