A Question of Teamwork

Welcome to another post of Gratuitous JRPG.Last post, we finished up the concerns of skillsets, developing the majority of the innate character skillsets and covering the issues of stalling in preproduction.This time, however, we will be covering an aspect of development that isn't directly related, but comes up more than often enough that it is worth mentioning.Typically, a RPG Maker project will be assumed to be a one-man effort.However, there are cases where multiple people will team up to work on a game.These production teams are the subject of today's post.



To start, a well-coordinated team with members in roles they are each strong in can create a far superior game to one person in the same amount of time.Two people-say, a writer and a developer-can possibly more than double the production rate of a single person.To clarify, the simple act of asking somebody not directly involved in your project for feedback does not count as teamwork.By teamwork, I mean two or more people in dedicated roles in the development of a game.So while asking a friend for feedback would not be teamwork, having a member dedicated to giving feedback and an outside look, or to be more precise, "quality assurance," would.And when one looks at the number of roles in the development of a game, it clearly becomes evident how much work can be split up.




Assuming one is using RPG Maker VX Ace, one can expect the following roles to show up in a team situation.The director or team lead generally organizes the project and keeps everyone working.Writers have already been discussed, and can be specialized to writers for the large-scale plot (the "scenario writer", if I am not mistaken in terminology) and small-scale matters such as narration and dialogue.Similarly, mechanical development can be split up into core mechanics, conceptual mechanics, and hard mechanics.On top of that, event handling is its own concern, and fine-tuning the numbers for battles another.If the team is unwilling to use custom scripting, art, or music assets that are freely available, they will have to find the programmers, artists, and musicians to create those.(As a sidenote, I have nothing but disdain for those who use assets without permission.Respect the people who put out resources for use, credit them, and do not break their terms of use.)Mappers are important, responsible not only for the effective use of art assets but the flow within a game.Testers and general Quality Assurance are another important part of a team, and it is ideal that they are not in a position that they are giving feedback on.And lastly, if you have enough members working on one aspect, such as writing, there may be a lead to manage that team so the director may delegate and manage work more efficiently.All in all, this is a large number of available roles, so creating a team to divide the labor may very well be beneficial.



Just as a team may help in game development, it may also come with its own problems.The first of these problems may come into play when attempting to create one's own team-getting people to join to begin with.One is not going to get a team together from people you don't know if one cannot prove they cannot complete a project on their own.As such, one will need networking, willing friends, or at least one good completed game on their record to recruit a good group.This leads to the opposite problem-acquiring people who are unwilling to follow through.Going through an interview process to get to know people who are interested in joining should help filter out the people who may not be committed or not fit the sort of game you were intending.



Nothing kills a project faster than poor communication within a large team of people.And tire swings.



Other issues with group formation may come up if one is joining a group another person is forming.To be precise, this occurs when the person setting themselves up as director does so in an attempt to get other people to make a game for them.The solution, thankfully, is comparably simple: leave.There is nothing good that can come from working under a leader who has no intent to get involved in a game beyond being credited for it, and they deserve exactly zero people under them.To digress once more, I would have an image.ready for this, but the site that had it no longer exists.It was a comic making fun of this sort of would-be leader.But sadly, no image.Rest in peace, RPG Maker Rage Comics.



While in a group, there is one additional task that is equally important to all of the direct game-development tasks one may already have: communication.In fact, it may very well be more important.Friction between members of a group who are normally friends outside of said team are frequently a result of a breakdown in communication or tastes at some point.Open, clear, and honest communication is the most valuable resource in a development team, lest you have cases of one team member disliking and resenting a decision made by another, or team members not knowing a vital part of an intended design for months on end.Once more, the importance of communication cannot be overstated.A team that communicates poorly will be a team that breaks up in no short amount of time, possibly with damaged friendships in the process.



On the subject of communication, one matter that must be addressed early and often is cross-division creative influence.While it is typically understood that the director has the last word on matters, sometimes a writer has an idea that they want to tie the gameplay into their story concept, or one of the mechanical developers wants to introduce a character or boss that utilizes a certain mechanic.The question of how much cross-role input is given should be answered decisively and early by the person in charge-often the team lead.This ties back in with the previously stated rule of clear communication.If this must be changed for some reason, it is vastly recommended that this change (or any sudden change in policy, for that matter) be extremely well-explained.Simply put, the less explanation and empathy used on the side of directors, the worse everyone else will take it.



As mentioned before, it is ideal to pick people who fit the kind of game you want to make.If you want horror, pick people who have a good idea of how to write and design horror, et cetera.And as is typical, you do not want the person who finds the difficulty level of the Shin Megami Tensei games to be ideal if you are aiming for something more on par with SNES-era Final Fantasy games.This is common sense.What you want to avoid, however, is the phenomenon known as groupthink.



How dare he have a different opinion!Burn him!



Groupthink is a phenomenon that happens more frequently than one would assume.This is because it is difficult to notice groupthink until one is attempting to fight it from the outside, more often than not.In a typical case of groupthink, the majority of a team will come to an almost unanimous decision, with the few members on the outside having their ideas fall flat in a scene reminiscient of most 1980s saturday morning cartoons.This leads to two problems.The first resultant issue is that the minority party may feel alienated, especially if these sort of decisions have recently occurred in rapid succession.The second problem is that groupthink will often lead to the group possibly neglecting extremely important factors, which can turn into problems well down the line if the original decision was enforced early and not examined for a long period of time.The best remedy for groupthink I can think of from a director's end, working alone aside, is to take any legitimate divergent opinion into notable consideration.



Another major issue for working in groups is one that is hopefully amazingly rare, is intra-group hostility, or in simple terms, "people not liking each other."This can come from one of many reasons, so listing the reasons would take up more time than necessary.The solutions are all around the same from a director's standpoint anyway: either find and resolve the issue causing hostility to begin with, pull rank if you absolutely must and force them to work together as much as they need to, or as an absolute last resort in this situation, eject the more troublesome of the parties from the team.This last one is not recommended under most circumstances due to the fact that unless the team is large enough to have more than one of position X, you will have to find a new person to fit position X.



The last major problem that may arise in a team project is one that is familiar to people with experience in software development: version control.There are version control programs out there, but in honesty I am not certain if it is advisable to use them with RPG Maker.In such a case, it is more than worth it to keep a master document and master version of the program, clearly marked for easy reference in the light of multiple current builds.Otherwise you will end up spending your time trying to remember what was done in what last, only to realize that your last edit mistakenly caused a specific bug and now you are trying to figure out the listed order of formulas in a custom script.Ultimately, consistent version control is vastly beneficial for time management of the project and the sanity of everybody involved.



I could go on for days about unique problems that assembling a team gives, but the point is simply that once you get on a team the added challenge of interpersonal logistics will more than make up for the diffusion of workload.It is most definitely enough for many to answer when asked for advice on working on teams with "don't."This is not to say that groups cannot work, but they require far more work than anybody would expect otherwise.With that, this is Epic Alphonse, signing out until next time.
Full Post