New Angles: Keeping Production Deadlines in Times of Change
This article covers the remaster of War Robots from the perspective of a 3D environment artist — how can a project stay optimized and work effectively when massive project, work, and life changes are hovering all around? Read and find out!
We changed our approach to processes; we started work on a remaster of our flagship game, War Robots; we shifted to a remote mode of work — all at the same time. My name is Dmitry Aleksandrov, Senior 3D Environment Artist at Pixonic, MY.GAMES. In this post, I’ll discuss successfully maintaining production deadlines in times of change.
But first, let’s back up: it seems that remasters are all anyone in gamedev talks about these days, and it’s not different for us at Pixonic: in 2020, our flagship game, War Robots, received a major remaster. This involved a lot: from pre-production to external testing and a new map development pipeline. It’d be logical to assume that changing the tech stack would require improvement of internal processes, too.
We’ll talk about the organization of the workflow within our team, specifically, how we changed our approach to processes at the same time we started working on the War Robots remaster, which just happened to coincide with a necessary shift to remote work. And since I’m a 3D Environment Artist, we’ll primarily discuss what was happening at that time in our company with regards to level design.
And before we start, for ease of understanding, let me introduce three terms:
- Legacy refers to the original technical and visual state of maps
- Refresh refers to a transient, partial rework of the maps; in this case, only their appearance is improved, this would be considered a full remaster
- Remaster is a wider term, compared to Refresh, which combines all further iterations of graphic and technical changes
On processes
Historically, the Senior 3D Environment artist has been the main contributor to the development of legacy maps. And the team size, depending on the situation in the department and the priority of tasks, fluctuates from one to two, or sometimes even three people. Below is a graph of the team size over time, and the monthly breakdown of work on each new map, assuming that, on average, it took four months to produce one legacy map.
Previously, team interaction was much less complex compared to now. The pipeline was simple, as was the entry point to a work process whenever the team expanded: at any time, we could start tasks for any artist in the department, and they could be involved both in short-term and long-term tasks.
By the time the technical tracks of the remaster were established, we faced the need to make a new map: Abyss. It then became obvious our technical changes inevitably entailed organizational ones as well. Taking into account the new requirements, the production of a map took one artist 6–7 months, instead of 4. Thus, we needed a new approach to production organization and more professional teamwork: instead of an increase in development time, we needed a clear structuring of processes and their optimization.
One of the key decisions was to concentrate the building of maps into one person’s hands. Whereas earlier, each artist independently added changes to the project (and potentially generated errors), now this process served as a filter on the way to assembling the scene. This intentional interaction filter between the team generating assets and the lead building the game scene helped reduce the number of bugs and version control conflicts.
Each map contains a large volume of different objects with collisions, lods, decals and additional masks. Checking each piece of content would mean completely stopping work at that stage. Therefore, we decided to introduce regular cross-checking of content into our processes.
What does this cross-checking entail? This process involves independent checking of assets by the team and has a proactive nature: by doing this, we can prevent all kinds of mistakes due to tunnel vision — which no one is immune to experiencing. This phenomenon is rooted in psychology and the peculiarities of how the brain works. When we continue to work with the same type of objects and entities, we get a sort-of tunnel vision that blurs the focus on details.
We found that a special day dedicated to cross-checking within the team (at least once every two weeks) creates a positive result by way of switching attention and emotional release. Everyone can conduct a passive analysis of their colleagues’ work, and in addition, along with the process of searching for errors, team members exchange experience regarding modeling, texturing, and the use of internal tools.
Particularly successful models and their elements can be reused later — after all, why should each new artist need to model a unique door or wheel if a task doesn’t require it? The most successful “version” of a window or ventilation hatch can be shared with the whole team as part of a kit set. Needless to say, ready-made elements, as a rule, are already insured against errors. This is how we unify the basic parts of the models, and increase production speed.
A great advantage of incorporating a cross-checking process is the ability to analyze the strengths and weaknesses of your colleagues: this analysis helps plan further work, and, as a result, allows for more accurate risk prediction when setting deadlines for large tasks.
Teamwork and artboards
Generally speaking, the remaster wasn’t the only factor leading to changes. We needed not only technical changes, but changes in the overall work paradigm due to the new remote mode of work.
The priorities regarding updating maps also changed. A remaster is a technically complex process, associated with the need to introduce asset bundles and divide scenes into quality presets. Our pipeline didn’t just become more complex, it also launched a production flywheel and a chain of interrelated tasks.
Work on maps was divided into two streams: the remaster, and the refresh of legacy maps. It was impossible to rework all the maps at once, but it was vital to transfer everything to new shaders. This became a serious challenge for the developers: they needed to revise the entire production chain, from concept to technical review.
This is where we get to the point: for a team of creative people, visual communication and exchange of experience is vital, especially in the current realities of remote work. So, along with task managers and reference boards, the artboard has become one of the most successful micromanagement tools for us.
How does an artboard differ from reference boards? If the latter is a variety of reference images that describe the main idea, then the artboard is a tool for summarizing both the reference board and the actual development process.
We chose Miro as our main tool: besides being simple and intuitive, it also allows you to unite and streamline a single team reference board, formalize and decompose tasks, while also strengthening team interaction.
Artboards help team members become actively involved in the discussion and analysis of information, and the overall process and workload of each individual team member becomes transparent to everyone. (Further this is so convenient, I think that a profession like “board manager” is going to emerge in the near future.)
Smart micromanagement, with the help of artboards, is effective for planning and enhances teamwork. Production time for a map remaster decreased, by an average of one month, to five months — as opposed to previous forecasts of 6–7 months.
Above you saw an example of such an artboard; to make that clearer, below is a diagram explaining its components:
The daily team meeting, an essential part of our work with the artboard, is another important step in organizing team interaction. These meetings usually go like this:
- A greeting and description of the meeting agenda
- Analysis of the new additions to the artboard
- Description of the work done
- An objective risk assessment and task prioritization
- A follow-up and documenting decisions made during the meeting
- Informal communication, if there is time
These meetings have several possible scenarios, for example, there could be a moderator or on a first-come, first-served basis. (The first team member who “raised a hand”, presented a topic, and so on.) This moderator may help when meetings start exceeding the allotted time or people become too emotional on these meetings.
The meeting highlights all ongoing processes, helps assess the workload of colleagues and, ideally, helps distribute tasks evenly, if it’s conducted by a lead. And the nature of the meetings can help keep track of some internal and non-obvious things, acting as a kind of tool for psychological analysis. If informal communication outweighs the discussion of key tasks, it means that employees aren’t very busy and feel relaxed. If there is no time left for chatting, and the meeting lasts more than one hour, it rather speaks of the opposite. At such meetings, as a rule, there is no place for excessive emotional outbursts. If it still happens, then it might indicate that there are conflicts within the team and a fundamental analysis of ongoing processes needs to be done. This is often a reason for revising priorities, timing and optimizing decisions.
As a result, we have the following interaction scheme:
- Artboard and single space for team communication
- Daily team meeting and artboard analysis, resource sharing
- Fundamental analysis of the microclimate within the team and 1-on-1 meetings
- Cross-checking and intra-team exchange of experience and tools
- Signing off on the team’s work based on the results of cross-checking
It’s important to note that the described processes don’t undo the usual models of management and interaction with project managers, they complement them — we have all the necessary integration tools for that, like Jira or Slack.
For comparison, here are the schemes of our old legacy and current remaster pipelines:
- With legacy, the range of tasks was much simpler, and external management and weekly meetings were enough for us.
- With the remaster, there was a constant process of intra-team micromanagement, the core of which was the artboard. External control was done in the form of the status recording from the development team every two weeks.
Both schemes have one thing in common — a scene prototype that marks the start of the work process.
As a rule, the collision model sketch of a level gives an understanding of the nature of its terrain, as well as its key game points (beacons), shelters, and main objects. This model is created by the level design department, and the final result acts as the basis for ordering the production work of a new game location. When reworking old maps, the entire legacy map acts as a scene prototype.
Further steps involve the creation of atmospheric concepts and sketches. The new system for the production of remaster cards calls for a more detailed work at the conceptual level. In the old system, texture diversity was reduced to arranging a common texture atlas; this gave room for maneuvering, but the quality of the textures was worse.
The new system is based on texture arrays, including trims and tiles linked to texel:
- Trims are seamless textures on one axis of the coordinates
- Tiles are textures that are seamless in all directions
On one hand, this increases the visual quality, but on the other hand, restrictions appear on the number of textures that can be used. In this situation, we can operate with a limited color palette even when creating conceptual solutions. I won’t delve into the technical features that have already been described earlier, I will only note that such a link to the palette simplifies further work and reduces production time. Preparation of the final set of textures can, and should, start proactively.
It’s ideal when the tasks of clean model production for a level are based on a finished texture palette. On average, two different tile textures need one universal trim texture. When designing such textures, we rely on the assumption that everything that has a random length and is more than 3–4 meters in height is called a tile. The earlier and more accurately we define this palette, the less we’ll have to correct the models in the process. It’s important to understand these issues at the stages of preparing the concept.
Thus, work on the level concept has ceased to be a separate preparation stage of development and is now done proactively, but with the active participation of the team. The concept now relies on technical and artistic limitations, and the final models become closer to the concepts.
In the examples above, you can see a noticeable difference in artistic value, the importance of the concept and its in-depth development:
- The general atmospheric concept perfectly conveys the main idea and mood of the map
- The second example shows a deeper approach in the form of clarifying concepts that carry actual technical requirements for the performer. With this approach, there are no longer any questions about where to use concrete and where metal, there is no need to waste time analyzing incoming information — the artist can focus on more important technical issues
The shift of the decision-making point from the production process to the preparation stage allowed us to better structure the work and open up the possibility of attracting outsourced staff. When developing legacy maps, this was more difficult to do: the sudden need for changes in the production process was much more expensive, and there was simply no need to delegate anything.
The new pipeline implies the presence of a texture palette and texel, which ensures the independent operation of the palette and geometry. As a result, at any time you can make changes to textures without blocking or making modifications on the part of the geometry. At the same time, the geometry itself is quite simply and quickly textured with trims and tiles, allowing overlaps of layouts. The exception is the channel for using additional masks and lighting.
More precise and stringent requirements for models allow to generate clearer technical specifications. With the obvious complication of the technical part, at the same time, we see a window of opportunity for distributing tasks both within the team and delegating them to the outsourced staff.
Check-lists and guides
The cornerstone of the new process implementation is always the technical documentation. Without a simple and understandable knowledge base, the process of scaling a team and delegating tasks gets greatly complicated. At the moment, we have all the necessary technical knowledge base on the project, but we’re working to create guides and checklists.
In my opinion, no matter how detailed and well the documentation is written, as a rule, it’s always a “chrestomathy”. This is not bad of course, but even if such a document has an impeccable structure, it often lacks the necessary mobility.
As for the topic of this part, it’s largely tied to the processes described earlier. Checklists are a very important part of cross-checking. This mechanism should be simple in operation and most convenient for practical application in a compressed form. Moreover, a checklist developed over time will be most useful. You should focus on the most common mistakes and weaknesses within the team.
Unlike project documentation and checklists, guides are of a different nature: I would say, they’re a separate entity that is also a necessary addition.
The main task of the guides is to share successful and rational cases that offer the best ways to solve problems with the help of the project toolkit. It’s good to have this information at hand. It’s even better when it’s backed up by visuals. And if the text and illustrations are accompanied with audio files, this is the best. The idea is in the availability of information and the use of different channels of perception. But we are currently working on it ourselves. Here I’m just sharing my experience, which is constantly changing and evolving.
Final perspectives
Change is inevitable in work, goals, and habitual patterns. Life doesn’t stand still; it’s constantly changing. The War Robots project is no exception, and, like a living organism, it responds to external challenges.
A couple of years ago, map development was a fairly systematic and easy process that didn’t require special attention. But one day, the project needed to mature and rebuild following the industry.
The conditions for the team’s functioning have also changed. Not without the participation of new leaders of course, but the team coped with the situation and adapted to the new conditions of remote work through streamlined processes. They may not be ideal at this stage, but this is a certain point of growth and a vector of moving forward.
