Team Project: The Survival Guide #1

Hello! The first thing I'm just going to cover is the fact that this article has been written from a lecture for students starting their team projects. This will apply primarily to them and other students at other educational establishments doing the same, but will likely hold some equally relevant information for games developers, in particular those working with new people on a new project (E.g. Game jams). There may be some sections from the lecture that might be slightly harder for me to translate into written form, but I've done my best to remember most of what I talked about! Any comments, suggestions, feedback or additional points would be greatly appreciated, as I'm always looking for new areas to investigate. Enjoy! 

This article is going to be covering some of the main killers of collaborative projects I've seen in the past. Before we start, who am I to be talking to you about this? Here's a rough summary of my experience of working in team structures. 

Here is some of my advice to you based on those experiences and the knowledge I've gathered around developing my own games over the last year. Without further delay, lets get started!

Take what is Achievable and Halve it

Sitting down in your teams, ideas will likely be flying front right and center. These will vary is scope, and what is important to remember is whatever you plan to build, if you're taking the prospect of releasing your game seriously, at least half of the time developing the game should be dedicated to testing and refinement based on feedback. 

I remember from my final year, a game was pitched but there was the concern that we'd have it done in weeks due to its simplicity. Instead we settled on working another game with a finite but still large narrative. Because of the decision, despite mine and the teams' best efforts, we bit off more than we could chew. By the end of the year, we had built up to the halfway point of the game, with the major boss battle and final level yet to be added.

I guarantee one team member will bring up an idea that is immediately shot down because it appears too simple. If the team believes this to be the case, pursue it and see if this is actually true! 

Artwork will be iterated, code will be refined and the gameplay mechanics will expand, but for that to happen you must first get the first build of the game finished! These are the first games that many of you will be working on and the most important thing is to finish something so that you know that the end of a project is a tangible thing.

Gameplay Mechanics - Get the Foundation Right 

Though less relevant with the introduction of game engines into the course curriculum, the slow killer of many projects is development without the initial testing of gameplay mechanics. An idea is formed, narrative expanded, artwork drawn up and the programmers set to work on building the project based on what has been discussed/written down in the Games Design Document. As time ticks on, the engine finally gets done and the mechanics are tested - only to find out they weren't as fun as originally perceived. In particular with team projects, this revelation often happens nail bitingly close to the end of the year and is usually way past the point of anything except minor alterations (to roll a turd in glitter so to speak). The investment of months and months of development understandably is horrifying for the programmers to realise their work is redundant. 

Weakness in gameplay mechanics was a common trend that I saw often in University team projects, particularly in many of the teams working within the Unreal Engine. The produced games had a strong focus on visuals, but struggled with integrated narrative and gameplay mechanics outside of basic interaction with the environment. Now this can very quickly ignite discussions like the pointlessly subjective "What is a game" topic, but in order to remove a keystone as essential as gameplay, the quality of other areas must compensate.

A good example of this from industry is Chinese Room's "Dear Esther". The game has stunning visuals, a strong narrative and has the quality of sound design to deliver it. The strength that it holds in the areas above means that it can afford to have less prominent gameplay mechanics. Restricting gameplay to walking within "Dear Esther" was a conscious design decision, rather than using the default settings out of laziness or by lack of consideration. 

Fortunately, this should be less of a problem in future projects, as the new Unreal visual scripting interface, Blueprint should increase gameplay and interaction in future team projects.

Even if you plan to build the engine from the ground up, test the mechanics first with an already existent game engine to see if it stands up to scrutiny - does it actually provide the experience you wanted? Whenever I get involved in Game Jams, I usually flesh out the mechanics of what we're planning to work on before the programmers get started. Doesn't feel right? Tweak the variables and add or remove parts. Doesn't work at all? Scrap it and nothing but the prototype is lost.

Working in the Same Space

Many of you I imagine have high-end computers at home that you prefer to work on. Great! But what are also at home are your Games Console (debatable of course if you have a high spec PC), your TV, and most importantly, not your team. We live in a wonderful age where communication is immediate, but yet working in the same space still holds it's merits over apart:

Now the problem that comes with this is availability of people, but I know for a fact that there are times that teams could work in, but don't. In my final year at University, I had some very lonely nights working there purely by the fact that nobody uses the rooms past 5pm (despite the facilities being available till 9pm) Just one evening of the team in the same space for 4 hours a week would get so much done. Also, it means that the entire team meets their "Quota" for the week in one night (though in my opinion you should still continue to work on stuff as there's still so much to do!)

Not only that, but working at each other's houses also works - buy in pizza or cook an industrial batch of pasta and invite the team around. As a last ditch effort on my part to get the team to produce something in first year (after months of team members fobbing the work off), we sat down in one of our flat kitchens and I cooked pasta bake. Despite not finishing the game, we got more done in that afternoon than the entire academic year. 

The existence of Game jams also appear to support this - the events that I've run in Huddersfield are 12 hours and the amount of work completed in that window is utterly insane. Set yourselves a certain number of hours to reach a certain checkpoint, invite the team around and get cracking!

Communications - Visuals Beat Words

One of the biggest dividers of teams is one of the simplest to address: visualising discussions to unify the thought processes of the team.

I'll explain: Whilst talking to the students, I picked one of the freshly formed teams and asked each member to name a space shooter. We went around the circle and all but two had different answers. With a team deciding on an idea for a game, if even one of these team members was to perceive the description differently, they could derail the project further down the line as the project formed into something they didn't expect. To address this, drawing out thoughts on paper, producing concept art and building prototypes can build mental bridges between team members.

At first whilst working on CHIGUN, me and Tyler would regularly argue for ages about aspects of the game. The composition of the level "Yolkyo" was a good example of this, as we couldn't visualise what the other person had in their head, meaning we kept making things that weren't relevant or different to what the other visualised. It was only when we sat down and drew things down on a huge sheet of paper (along with plenty of scribbling parts out) that the level structure formed and we were able to get started. Since this worked for resolving arguments, we used this as a tool for the remainder of the summer. Whenever an argument began to brew we'd sit down and start doodling out what was in our brains and sure enough, conflicts ceased for the remainder of the summer.

Designers + Programming = Facemelt

Continuing the last point, the biggest void in perception is that between the minds of artists and programmers. To bridge this gap, artists can use prototypes to get their ideas and plans across to programmers.

The main problem with this is outside of paper based prototypes, it's not easy for designers and artists as many don't know how to code! 

Visual scripting has sprung up massively over the years, and taking advantage of easy to understand plug-ins and software will give you a basic understanding of the syntax of programming. With this knowledge, it will empower you to build the skeleton of the project for programmers to flesh out the full game from. These are some examples of software to get you on that first rung of the programming ladder:

Standalone Visual Scripting Engines: 

Stencyl - http://www.stencyl.com

Construct - https://www.scirra.com

Gamesalad - http://gamesalad.com

Plugins for Existent Engines:

Blueprints for UDK - https://www.unrealengine.com/blog/introduction-to-blueprints

PlayMaker for Unity - http://www.hutonggames.com

The primary thing that building prototypes using visual scripting saves the team is time, as there's nothing we understand better than games, thus the perfect method of communication. If necessary, the programmers can even go to the lengths of using the basic scripts as a template to get started from.

Thanks for taking the time to read this! As I said at the top, this is the first in a line of different articles that I'm planning to write around the subject. If there's any counter-arguments, experiences, suggestions or useful links for me to look into further, please let me know!