RACI Analysis of Unicorn Piñata

Introduction

An otherwise successful project can be severely limited if roles and responsibilities are not clearly defined early in the project’s lifecycle. Unicorn Piñata is an example of one such team who at times struggled to develop a game for reasons largely resulting from poorly defined roles and responsibilities within the team. The RACI responsibility assignment matrix provides an excellent context within which to analyze the causes and symptoms of problems caused by poor responsibility allocation.

The RACI responsibility assignment matrix categorizes each member of a group by the role they take in a given decision. There are four possible roles in RACI: Responsible, Accountable, Consult and Inform. The person who is Responsible is the person who completes the task and is responsible for implementation. Accountable individuals are those who are held answerable for a decision and who have the ability to assign the degree of responsibility and to approve/veto ideas. The Consult role consists of individuals with expertise who are to be consulted before a final decision is made. Finally, Informed individuals are those who are informed after a decision is made as they may need to take action as a result of the outcome. By placing team members in these roles, the RACI chart can clarify responsibilities and point out gaps or areas of overload. Through analysis, a team may find that nobody is responsible for a given decision, too many people are accountable, or any other number of problems.

From the start of group formation, Unicorn Piñata failed to take the time to define many roles within the group; the team felt too rushed to complete their POCT (Proof of Concept Tech) milestone to do more than a cursory delegation of responsibilities. Almost as soon as the team formed, they participated in a “flash hack” where they were given a list of requirements and asked to make a game focused around those requirements within the period of a couple hours. The members of Unicorn Piñata had high standards for themselves, and the asset quality that they attempted to achieve prevented them from completing the majority of the requirements in the allotted time. This exercise hurt the team’s sense of self-efficacy, and soon after they received requirements for a POCT that was due two weeks later and which required final-quality character and weapon assets (the team would later find out that “final-quality” was a misnomer). Unicorn Piñata saw the ambitious POCT requirements as a challenge and a chance to prove their ability to succeed; this resulted in the team ignoring many typical pre-production activities in a dash to complete the requirements for the deadline. Because of this rush, the team never firmly established many roles and responsibilities, leading to a number of issues as the project progressed.

By the end of POCG (Proof of Concept Gameplay), the team realized how disparate their disciplines had become and took steps to resolve the situation. The measures taken to resolve these issues had an effect in every area of the project and included processes ranging from team meetings to e-mails between members who did not interact often. By the time that RTM was reached, a fair majority of difficulties had been dealt with. The following is an analysis of how responsibility assignment was handled in several areas: Game Mode, Art Style, Weapon Design, Level Layout, Menu Creation, and Heads-Up-Display Design.

Analysis

Game Mode

Many members of Unicorn Piñata should have had input into the conception of the game mode, since they were going to be working on it for the following several months. The team’s artists were not involved in many of these discussions during POCT, due to concerns about getting “final quality” art assets completed in time. Because of not consulting with art, the game mode and art style felt very disjointed at this point in the project.

Unicorn Piñata also had a major issue with assigning responsibility for the design of the game structure. Ideally, one or two people with responsibility would have consulted with the entire team when designing the structure of the game, but instead nobody assumed responsibility. The producer thought the lead game designer and lead programmer were responsible, and the leads assigned responsibility back to the producer. Nobody saw themselves as responsible, and so nobody took action. In an attempt to remedy the situation, the producer expressed to the entire team that the game mode would be the responsibility of the lead level designer who would consult the lead programmer and the level design team. What happened because of this action was that the level design team took up responsibility and the programming team fell back into an “informed” role. The design of the game progressed for a while without consulting other disciplines outside of level design, which resulted in them falling out of the loop and being left to work in the dark, uninformed of the decisions that level design was making until the decision was final.

Ideally, the producer would have placed the lead level designer and lead programmer in a responsible role from the start. Putting the lead level designer and programmer in charge of the decision would have encouraged them to collaborate, giving equal weight to each discipline’s desires and concerns. Each lead would then consult with the members of their discipline and with the lead artist to reach a decision that the group could agree upon in a timely manner.

At the end of proof of concept gameplay, Unicorn Piñata realized that their game mode was not as formalized as it should have been. Due to this, the team met to discuss measures that could be implemented to better define and communicate the core gameplay to the team. The lead level designer was elected to be in charge of designing the primary game mode and consulting with the other disciplines’ leads in an effort to figure out what was best. However, after the meeting the game mode began to fall back under the sole control of level design, as other departments became too busy to consult and even more of the implementation fell on level designers.  If this strategy were to have been successful, there would have needed to be a system in place to ensure that the lead level designer was actively involving the other disciplines in any major discussions. Implementation of the game mode became increasingly convoluted as a result of other disciplines falling out of the loop. A lack of detailed documentation from level-design also meant that many changes were not communicated to the other disciplines that then ended up working blindly part of the time.

In Alpha, the team realized that the communication breakdown between programming and level design was causing a significant amount of rework and had resulted in the round code task being drawn out for over a week. To remedy this, the level design and programming departments were pulled aside to consult with their producer on how to manage the task more efficiently. As a result of this meeting, level design agreed to put a lock on what they were doing with scripting and provide programming with full specs that they could then use to implement the game mode with help from level design. Once that meeting happened everything relating to the game mode flowed smoothly for the rest of the project (apart from the occasional bug).

Art Style

The art style of “BOOM!” did not initially mesh well with the level design team’s vision of the game. The lead level designer was envisioning a 1950’s Area-51 bunker, another level designer was envisioning an inflatable paintball arena, and the art team was delivering sleek 1980’s glam punk aliens. Due to personality conflicts at the start of the project, Unicorn Piñata’s art team did not want to consult with the level design team. Early in the project, the team’s level designer expressed a habit of trying to put a 1950’s spin on everything he worked with; this made it hard for art to work with him when they are their own very strong 1980’s style. Because of this dispute and time-pressure on art, the visual style evolved without a lot of consideration to design. Having art assets created without consideration to design meant that a lot was lost in the conveyance of affordances and assets were designed without consideration for how they would affect gameplay. If art had consulted with level design more heavily and taken the time to do more initial concepts for level design to review then more of the art assets would have been created with functionality in mind.

Due to scheduling pressure, Unicorn Piñata’s artists ended up formulating the character appearance on their own rather than in consultation with the rest of the team. If they had been able to consult with the team they may have been quicker to find out that the character blended in with the environmental assets they were creating and could have adjusted one or the other so that the character would stand out in the environment.

At the end of POCG, it was realized that art and design had grown apart, and so the team met to decide on how to better unify the art style. Unicorn Piñata decided to unify the art style by giving total control to the artists and having them inform level design as needed. Level design was to defer to art in everything regarding the visual style, a move that ultimately hurt the game’s level of polish as it meant that art assets and style choices were made with no consideration for the overall design and usability of the game. This method of interaction between the two disciplines stuck through vertical slice.

As the milestone progressed and deadlines approached, pressure on the artists went up and their workload led to their absence from a lot of group communication. Art was completing 160% of their backlog on average, but was not consulting with any other disciplines unless someone from that discipline came up to them to request something. The lack of communication between art and the other disciplines was permitted for the last two milestones since fixing the issue would have meant a significant hit to art quality. Ideally there would have been enough time for art to communicate with the other departments and still complete the amount of work they did.

Weapons

Unicorn Piñata’s weapons would have benefited greatly from more interaction between the art and level-design departments. Since the requirements for POCT requested “two custom weapon models with final textures/materials and scale”, art began work the appearance of the weapons immediately, even before they had the time to iterate on concepts or to consult with design. This meant that design was conceptualizing the functionality of guns that were already being worked by an uninformed art department. As the level-designers came up with new mechanics, they would consult with programming on feasibility, but failed to consult with art as frequently. The design of “BOOM!” started out with a sniper rifle, an assault rifle and a shotgun at the start of POCT. By the end of POCG, “BOOM!” had a gun that shot goo and another one that spawned decoys in its design. Art was only ever informed of the design at the beginning of POCT when they asked, and at the end when the decision had been finalized by programming and design.

Ideally, the weapons would have been designed as a team with level-designers giving input into the mechanics, programmers giving input into the feasibility and art giving and receiving input on the appearance of each weapon. Each lead would have been responsible for ensuring that the concerns of their discipline got attention, and art would not have started modeling or texturing until a decision had been reached.

Because of level design and programming not communicating, the weapon functionality changed a number of times during POCT and POCG making it hard for code to complete anything of use. Art also could not create guns that fit the mechanics when no mechanics were defined. This meant that level design had to lock-down the gun specifications immediately and cease making any changes to the mechanics. This approach worked well for resolving interactions between level-design and programming; the mechanics were locked-down within two days and the code was complete within a week. However, it was too late in the project to resolve the gap between level-design and art; there was not enough time to redo the gun models, so the best thing that could be done was to try to come up with mechanics that fit the models they had.

Level Layout

At the start of the project, level design had significantly more time available to them than the other departments did. Level design used the extra time they had available to create prototype levels called “whiteboxes” until programmers had implemented the basic functionality that level-designers needed to test out their whiteboxes with the weapons they had conceptualized for the final game. The fact that level designers had much more time available to them than other disciplines put them in a situation where they were largely acting as a separate entity when planning the layout. This meant that level architecture was planned without consulting with the artists. As a result, the level was designed without consideration to visual interest or thematic continuity. Until much later in the project, Unicorn Piñata’s levels looked more like Area-51 bunkers rather than the 1980’s alien playfield that art intended for them.

Starting with Vertical Slice, all assets in the game were created by art, which meant that level designers began communicating with artists a lot more as they implemented art assets into the environment. This interaction had an effect on much more than asset placement; it also meant that artists were frequently looking at levels, giving artists a chance to talk with level designers about how assets were to be placed in the level and how the level was to be lit. Level design still frequently went to their producer for approval on changes to lighting layout even though they had the freedom to do as they wished; this resulted in the occasional slowdown throughout the rest of the project, since level designers would often wait to ask their producer before making any changes to the level. On occasion level design would fail to inform programmers regarding changes to the placement of gameplay objects on the level, which would result in difficulties for code, but overall level layout tasks went smoothly from vertical slice onwards.

HUD (Heads-Up-Display)

Ideally, the initial design of the HUD should have come out of discussion between all of the different disciplines, but as with many other tasks communication was lacking at the start. HUD ended up becoming primarily the task of Unicorn Piñata’s lead level designer who was focused on his goal of a 1950’s-style diegetic helmet-HUD complete with reflections and cracking glass. The HUD is where a player gets all of the information in game and should have been carefully planned with regard to usability (from level design), visual-appearance (from art), and implementation (from programming). Instead of resulting from a cross-disciplinary collaboration, the HUD ended up being the project of one level designer who created the HUD, had art mock-up his sketch, and then had programming overlay the mock-HUD on the screen for POCT.

From vertical slice onwards, Unicorn Piñata had a close to ideal discourse regarding HUD design. The lead level designer would often come up with changes to be made, then bring those up with the lead programmer who discuss implementation with him. If implementation seemed viable then the leads from all departments would meet with art to discuss the appearance of the HUD after changes had been made. Art would then create assets that the programmers implemented and designers would test. The only way in which this process could be improved would be to involve non-leads more heavily in the decision-making process as consultants in order to avoid rework.

Menu System

Similar to the HUD, the menu system ended up as the project of one individual (the lead programmer this time) who implemented a very basic menu based off the minimum requirements for the project. Unlike the HUD, tackling the menu with limited cross-disciplinary consultation was appropriate for POCT as it did not need to look final and had no impact on gameplay, the menu only needed to be functional.

As the menu progressed further in vertical slice, programming began consulting other disciplines regarding menu appearance. This went relatively smoothly and there were no major issues with communication as the menu progressed to completion. One minor issue we had resulted from level design becoming more involved in the menu than anticipated, this was the result of a choice to have a level as the main menu background rather than an image from art. In the end it was probably better that level design worked on the menu rather than art; because, despite the occasionally bug resulting from the more complex implementation, the decision resulted in an overall more equitable distribution of work across disciplines.

Conclusion

If we had taken the time to perform a RACI-based analysis of roles and responsibilities in our group from the start then things would have gone much more smoothly for Unicorn Piñata. We would have found that many of our tasks were missing responsible parties and others lacked clear definition of roles, and having learned such, we would have been able to take steps to remedy the situation. Going through the responsibility assignment matrix as a producer has taught me a lot about the mistakes I made and the improvements I can make going forwards; I will always be sure to look at RACI if my teams seem to be having communication issues in the future.