With GB Compo 25 commencing soon, those of you competing will have a full three months to complete your entry, meaning you can make a pretty sizable and polished game within the allotted time. Many hands make light work as they say, and this is especially the case for those of you prepared to collaborate with others. Having said that, working effectively as a team can be challenging at times. The drive to make the best possible game under time constraints may push us to forego sleep and work longer hours than we are used to, risking additional strain on relationships as the team works towards a shared vision.

During the inaugural GB Compo 23 jam, I collaborated with Ben Jelter to produce “Unearthed,” the entry that would end up taking 1st place. That was my first ever collaboration, in fact. Since then, I have managed teams of developers to produce commissions such as McDonald’s “Grimace’s Birthday” promotional game (which was also produced under a tight deadline akin to a jam). I am always seeking to find systems that support the teams I work with, and better understand how I can be a more effective team manager. In this article, I’ll be sharing a series of strategies I have used over the last few years to help my teams realize their potential.

To explore the many facets of team management, I’ll be providing some examples from a game of mine that is in development. To provide a brief outline for context, here is a snippet from the design brief of what will be a mashup of chess and the RPG genre.

There are three developers on the team. First there is myself as the game designer and artist. Next is Pearacidic who, with more than twenty years experience as a chess coach, will be creating puzzles, lessons, and other chess related content. Last but certainly not least is Phidias618, who is coding the chess engine aspects of the game. This game is in such an early stage of development that I won’t be working on it in earnest for some time. Instead, Phidias will be relying on how I communicate my ideas to build the chess engine code which will form the foundation on which all other aspects of the game can be built.

The Importance Of Job Delegation

Many indie developers are a jack of all trades. It’s common to find a team member capable of filling multiple roles such as designing, creating art, and producing code all in one. At the same time, we all have strengths and weaknesses. Some of us may be great at solving game design problems, but not as good at solving coding implementation problems. Others might be great at producing fantastic pixel art, but less talented at applying game design principles to that art. With that in mind, here is tip number one:

1. Determine what each team member’s strengths and weaknesses are, then use that information to delegate jobs and responsibilities. Relying on the strengths of others will not only reduce your workload, your team may also reach a better outcome in a shorter amount of time.

As team members will sometimes have similar skill sets, it can be difficult to determine where one team member’s role finishes and another begins. Temptations to take over and “do it better” may arise. There have been many times where I overstepped a boundary with the best intentions, only to cause stress for someone else on the team.

2. When beginning a new collaboration, clearly define and agree upon each team member’s role within the context of the project.

Arguments can become commonplace when one person’s responsibilities begin bleeding into that of another team member, working to erode the morale of a team and wasting energy that could be used elsewhere. This scenario is usually most volatile when a lot of time has already been spent on a job, and stopping to address another team member’s concerns may mean the work needs to be significantly altered or started from scratch. In such a case, the emotional damage can be felt with more intensity.

Having said that, it’s natural that some choices may seem promising but lead the team down the wrong path, and that realization that may come at a time when a lot of work has already been completed. Game development is filled with pivots and revisions. Having to redo work is almost inevitable as the iteration process is so vital to making the best version of any game. To reduce the risk of veering off in a direction that may turn out to be a dead end, we can employ a few strategies to minimize possible stress.

Communicating Ideas Effectively (And Early!)

Even without the added pressures that come with a game jam, communicating complex ideas to others can be a tricky business. Game development is all about details, and there have been many times I attempted to explain an idea to a team member, only to find the words I wrote produced a very different vision in their head compared to what was in mine or vice versa. What seems self-evident to one person may not be to another. A team member may not share the same first language as other team members. Assumptions are made often – and often they are made without us realizing it was an assumption in the first place.

3. Seek clarification by asking questions when there is a shred of doubt in your mind. It is better to spend an extra day making sure the team shares the same vision rather than risk losing a day’s work and dealing with the accompanying emotional stress.

Many ideas may need to be shared in detail just so another person can start work. This is often the case when a designer needs to work with a coder as the implementation of the code must closely reflect the designer’s intentions.

So how can we communicate ideas effectively so team members aren’t working in the dark? Furthermore, how do we communicate complex ideas at the very early stages of development, before many of the assets have been produced? Speaking for myself, I often struggle to communicate complex ideas over Discord. Text is not an ideal medium, especially when it comes to sharing game design ideas that tend to be more visual in nature.

Design Briefs – A Shared Vision To Work From And Build On

Creating a detailed design brief using a combination of text and images helps other team members imagine playing the game in detail. When reading a design brief, team members will naturally begin to discuss and solve problems. This might include working within the Game Boy’s limitations, with UI design problems to overcome, or implementing the code of any number of mechanics. The cyclical process of using your team’s collective imagination, recording information, discussing that information, and then editing the brief in ever increasing detail can translate to huge improvements to your game – and all before the need to touch a keyboard, no less!

The Chess-RPG design brief has been an essential tool for my team in the early phases of developing the game. In fact, much of the broader game design simply can’t be addressed until the puzzle scene’s gameplay is pinned down because its design will directly inform systems such as player progression through a top-down RPG world. For example, what consumables could be added to help the player in their adventure and how they work require the puzzle scene to be explored in great detail. In turn, the consumables design will inform how a shop system might work and so on. In the screenshot below, you can see a “Collectibles” section taken from the design brief. This section was explored and expanded after the mockup puzzle scene’s mechanics started to become more concrete.

How Phidias designs the engine will also impact how time consuming puzzle implementation within the project will be for Pearacidic later in development.

4. Be mindful not only of foreseeable game design problems, but also seek out solutions that will help make the process of content creation more efficient – a stage of development that comes much later but is greatly affected by early code implementation.

In any case, Phidias will be working on the chess engine for quite a while before Pearacidic and I can start working on the other aspects of the game. He will need essential details from me as the game designer and Pearacidic as the content creator in order to carry out his own role.

We all know how the game of chess works, but how can I describe how this game of chess works to Phidias? The best solution I have found is to create detailed mockup images that can be placed alongside or into the design brief itself.

Using Mockups To Create A Clear Shared Vision

When I am both the game designer and the artist within a team, I like to create mockup plans that include what will eventually be the assets used in the project. This can save me time, helps me iterate in fine detail, and gives the team an accurate sense of what the game will look like.

Below you can see an example game plan comprising a series of mockups. There is a detailed overview of various mechanics unique to our game, suggestions on how we might implement them, step by step visual representations of mechanics, as well as a short sequence describing the moment to moment breakdown of how the “Puzzle Battle” might begin.

There are many of these game plans comprising many mockups, all of which aim to encourage team discussion and solve problems ahead of time. In this way, we can determine if anything needs to be added, changed or removed, and how best to go about implementing it all before Phidias spends a lot of time working on making it a reality. Of course, not every team is going to have a lead game designer that is also the sole artist on the project. Thankfully, there are alternatives to getting your message across.

Using Anything You Can To Create A Clear Shared Vision

Many pre-existing games will have solved similar problems to what you will face when developing your own project. It’s just as effective to share screenshots or videos of games that you wish to emulate, using examples as a basis for discussion.

One of the very first things I do to prepare the team for a project is provide a catalogue of pre-existing games that I think will inform the direction of our own. I’ll then let the team know why I have shared each game. It may be because the user interface is excellent or it excels at heightening some aspect of game feel, for instance. An example screenshot can really cut through what would otherwise be a hard task to communicate with text alone.

Taking screenshots and sharing them to save time in this way is also true of sharing scripts or engine code when discussing implementation. I find it preferable to screenshot a script of GBS events and paste it into Discord when discussing coding issues rather than attempt to explain what I have done or what we should with written word.

Finally, if you can’t create a mockup and you can’t find a suitable example of something close to what you wish to achieve, you can always rely on the good old pen and paper sketch to get your idea across.

Feedback – A Game Of Give And Take

I welcome feedback at all times. At best it leads to better games for a million reasons. At worst it’s a chance to revisit an idea – even if only for a moment before deciding it’s best to put energy into another facet of your game. Iteration is a fundamental part of game development, and not even the masters get most decisions right the first time. In my view:

5. Ideas are not fully formed when we think of them. There is always a process of massaging something that might be average into good, then into great, over days, weeks, and months through considered thought, discussion, and playtesting.

Even if I strike gold and come up with what I think is the best idea ever, there will always be some detail that is hidden from view until I start the implementation process and I get to literally play the game.

While the benefits of feedback can be immense, there will always be at least a little resistance to the idea of redoing work. I often find that I feel initially defensive when I receive feedback because it means I may have wasted my time, or my ego was damaged because I didn’t think of x, y, or z, or I just don’t have the coding knowledge required to make something better. There can be many reasons why feedback may be difficult to stomach. In the event that someone provides feedback to you and it is upsetting to some degree, remember this:

6. Take all feedback as an opportunity to re-examine something and possibly make it better – not an attack. If emotions run hot – don’t react immediately. Instead, take some time to calm down before explaining why your game design idea, art concepts, or coding implementation is the way it is.

Saying “x can’t be done because of y and z” is usually the first response before an idea is explored once more. If the reasons why a job has been completed in a certain way are solid, then that’s fine too. You will be doubly certain you and your team are on the right track. That takes care of taking feedback in a positive way, but what about the other side of the coin?

7. If you provide feedback, expect to get a defensive reaction rather than a measured response by default… We are all human!

Sometimes we react more emotionally than we otherwise would because we may be tired or stressed for other reasons. What’s more, when we share something that we have created, we are very much opening ourselves up to criticism in addition to the thing that has been created. It’s best to understand that people can get passionate when they are creating something, and to give them the benefit of the doubt. That goes doubly so towards the end of a jam when everyone is running on empty and tensions are high!

Adjusting Team Management Systems

Everyone likes to work in their own unique way and if the team is not managing itself well, people’s frustrations tend to get the better of them. If you find the systems your team employs are not working as well as they should be, try something new. Find a new app such as Google Sheets or Trello to help manage tasks, or some way of communicating your ideas more clearly, whether it be for game design or code implementation. Find out if your team members prefer to think about things more visually or like dot-points alongside an image. Every project is different because every team is different and every game is different. So I always try to adapt my systems of work to suit the team’s preferences.

Working in a team provides more opportunities to imagine better game development solutions across the board. Yes, it can sometimes be harder to manage a team of developers over going the solo route, but the end result can be an immensely better final product when all is said and done. Besides, since the release of GBS v4.1, the project file has been completely restructured and will no-longer hit that 100MB upload limit when using git-hub to manage your team project. There has never been a better time to get a group of friends together and start working on that next big idea.

If you or your team is looking to make a platformer game in the upcoming GBCompo25 game jam, my Let’s Build A Platformer! Course might be just what you’re looking for. I wish all of you the best of luck over the next few months!

okay cheers. If you do end up inserting that final paragraph back in before posting, here is a copy paste for you (with a slight edit to remove the google sheets reference):

In part 2 of this article, I’ll be sharing my team management processes further, offering a system of task management using Trello.