A Comprehensive Guide to Successful Group Projects at University

By Luke Haslett

Introduction

Who am I?

At the time of writing this, I’m a Master’s student at Staffordshire University, studying on the ‘MSc 3D Computer Games Design’ course. Prior, I did my Bachelor’s at the same establishment where I earned first-class honours on the ‘BEng Computer Gameplay Design and Production’ curriculum. Then before that, I spent 2 years at The Bournemouth and Poole College doing a ‘Web and Games Development’ programme.

I’ll also point out that I left high school with nothing. No grades, no direction, and no idea what I wanted to do. I spent 7 years working to afford to live and explore my hobbies, then at 24 I knew my next chapter would be the academic system, with a focus on game design.

So, over the last 6 years of education I’ve been involved in a lot of group projects, at least 15, which have been both good and bad, and I’ve come to a point where I’ve refined my approaches to an extent that would have been enormously useful to know from the start.

Who is this for?

Essentially, I want this article to answer the question “How do I succeed at my group project?”.

The core audience in mind for this guide are students of game development that are making a game together, however that’s not to say information can’t be gained or translated into a field more relevant to the reader.

Importance of Collaborative Projects

I also want to open this article by stating my belief that collaborative projects are one of the most beneficial experiences to obtain at university. Working in different groups with unfamiliar members may feel intimidating if you’re not used to it, but the advantages largely outweigh the negatives, and the following list clarifies my reasons why:

Meeting new people means making more connections. You’ll sometimes hear it’s not just what you know, but who you know, and if you’re in the final interview stage of an application with someone whose skillset matches yours, a good recommendation from a connection already at the company can be the boost you need.

With multiple people sharing responsibilities on a project, it can afford you extra time to focus and refine your own skills, and fulfil tasks you are accountable for to a higher standard.

An assignment developed by a group of people will likely have a larger scope and collective effort than one developed alone. This means your portfolio will contain more polished and impressive examples to help you stand out from the crowd.

And most importantly, with the exclusion of solo indie development, the gaming industry is not a solitary effort. It is made up of teams, you will be working in one, and as such you will be expected to perform to an appropriate standard.

Meeting Your Group & Choosing A Leader

Start Early

If you don’t know the people you’re going to be working with, and you have introvert characteristics, it can be easy to put off that initial awkward meeting. However, it’s highly recommended to avoid this and rip the band-aid off.

My experiences have taught me that it’s best to start early and avoid procrastination because there is always more that could have been done if you had more time, whether it’s features or polish.

Introduction

When meeting your team members for the first time, play an ice-breaking game. I know, I know, they’re cheesy and most people hate these. But honestly, you can gain a lot of quick insight about one another and connect with your peers sooner.

Try just going around the room and saying:

That’s just a plain example, but there are plenty more creative forms suited to different team sizes. Check out www.icebreakers.ws for a list of these.

Identify Goals

You should also take the time to listen to what each member of the group wants to get out of the project, especially regarding skills development, as this can help naturally place people into slots and form an intuitive hierarchy.

However, that’s not to say people will only get to do what they want to. It’s still a group effort, and that means doing your part regardless.

This means your true goal on a shared project should be to take pride in your work.

Taking care to make sure your work meets the requirements, and is of a professional standard, makes you stand out. It’s an attractive trait and people will remember it.

Having a ‘bare-minimum’ attitude or expressing that you’ve “done your part” as an excuse not to do more because it matches your teammates’ lack of work, both make you stand out for all the wrong reasons. It makes you look lazy and like you don’t care.

So, I’ll reiterate: take pride in your work!

Select Leaders

Now you need to nominate someone to lead. Usually you will have someone who seeks this role, but if not then you will each have to assess who you believe can confidently carry this responsibility.

The leader needs to be someone that you can trust to listen to the team and make unbiased decisions with the best interests of the project above all else. They also need to be able to communicate effectively, by keeping each member organised and clear what the vision of the project is.

I’ve often seen groups work without leadership because they haven’t been explicitly told they need it, but usually they end up lacking direction, unhappy, and victimised by the situation.

Group Size Differences

Depending on the size of the team, you may find you’ll need to expand on the range of leadership roles.

This should still work in a pyramid-style hierarchy and always have a producer at its peak making the core decisions.

If the group has between 10-20 members, you’ll probably find it easier to appoint leaders by department: Art, Design, and Tech.

Any more members than that, and you’ll want to break it down further, to where leads handle smaller groups within their department, and overall managers deal with each respective department.

To get a better visualisation on this process, refer to the next point.

Management Hierarchy

For clarification on what a typical organisational structure looks like in game development, check the following image.

(Image from www.blitzgamesstudios.com)

Of course, this is not a 100% accurate representation of the scene, as different businesses employ different models and often diversify what types of roles are required on a project. But this does at least provide a good basis for understanding who is responsible for which roles.

Idea Generation

Now everyone’s clear on how the group is going to function, it’s time to get to work, and that begins with finding an approach that the team can get behind.

This should be a group activity where every member gets to feel like they’re contributing. First, the leader needs to make it clear what the project requirements are, then it’s their job to encourage the brainstorm phase, preferably with a whiteboard so everyone can see and think about the concepts being suggested.

Remember, it’s important to never shut down another person’s idea, even if it’s going in an unlikely direction. Every idea should be noted, and no idea is stupid, because the merit behind a bad idea can inspire a good one. Supporting the team’s creative flow in this sense produces a much larger list to draw from.

For ideas, think about things you like and games you can relate your ideas to. Here’s a list of consideration to get you started:

Finally, if the process is moving slowly, use a game idea generator to get the ball rolling. Check out http://orteil.dashnet.org/gamegen as an example.

Approaches to Management

Scope

This is one of the most essential areas you will focus on whilst leading a team, and the success or failure of a project can often boil down to how well you scope it. Remember that as long as you hit your project requirements, it’s better to have a finished product with mediocre functions than an unfinished product with tons of features. But of course, you don’t want mediocre functions.

To start off, you should look at the time frame available until the deadline date, and break down the workload into milestones. For example: first playable, alpha, beta, and gold master.

It’s most important that you regularly analyse the progress of your team’s work and re-evaluate individual and overall objectives.

Weaknesses

Be aware of your group’s limitations, identify them early and plan around them. This isn’t so much about treading lightly around thin-skinned peers, but more about considering how the lack of knowledge amongst the team can affect the project overall.

For example, if you have no audio specialist then you’re going to need to assign someone to research/resource music and sound effects at some point, which will take them away from their trained craft.

Or another example is if there’s a clear absence of an animation expert, make sure the game is designed around that. This happened to a group project where I was producer and lead designer, and I overcame it from the start by designing our main character to be a floating wisp, which was essentially a ball with eyes. This meant we only had to consider very basic movement simulation that could be cleaned up with particle effects and vertical-axis tweens. Then towards the gold master milestone, I managed to outsource an animator to polish up our character.

Communication

As anyone from industry will tell you; this is one of the most important skills in your repertoire, and you will be using it a majority of the time. So, keep it sharp because being able to commune effectively will keep the team clear on their objectives and increase the overall efficiency of the work being done.

A lack of communication leads to misunderstandings and conflict amongst the group, which means mistakes occur and you will have to rescope in order to afford time to rectify these missteps. Because of this, you will have lost precious time for the overall project, and group members will lose confidence in the team.

However, communication is more than about being able to speak up, it’s also about the way you speak to others. Raising your voice and speaking over people isn’t respected, and can feel imposing. Instead, speak at everyone’s level, and have people feel valued by listening to what they’re saying.

Like I mentioned before, shutting people down isn’t healthy for them, or your professional relationship with them. If they raise ideas about direction or features that sound unlikely to be implemented, tell them that it’s something you can revisit if there’s time leftover. This encourages them to keep making suggestions, and you never know if it will lead to an idea that makes a great addition.

Being respectful about other people’s points of view brings up another important aspect of communication; the need to be sensitive to cultural differences. People have different backgrounds, and without correct facilitation of inclusiveness this can negatively impact interactivity amongst the group.

Accessibility

You want to make sure you always have direct lines of contact available between yourself and your team members, so make sure you share your phone number and email with everyone, and get the same details from them.

Additionally, social platforms are a great way for people to quickly start or join a conversation about an aspect of the project. Everybody uses Facebook, and if you don’t then you really need to because the convenience of inclusion on discussion is a professional tool you aren’t using.

So, create a Facebook group, Discord channel, or Reddit forum, and have all the team connected through there to quickly drop ideas or opinions when they have 5 minutes in their free time.

Role Feedback

After each milestone, you might find it useful to get some feedback from the group regarding how they feel about different areas of the project. This will help you identify what you need to work on to improve the process as a whole.

Here’s an example form I’ve produced to give you an idea of what kinds of questions you should ask your team.

An additional point to bring up is whether or not the form should be submitted anonymously. My personal opinion is that anonymous feedback helps to encourage brutal honesty without the fear of repercussions on the individual.

Management Tools

MoSCoW Method

To help you scope the project, use this common approach to discuss with the designers/lead designer about what features need to be considered for hitting the requirements.

If you’re not familiar with the MoSCoW method, it’s a technique to analyse features and prioritise them in a way that allows you to dynamically rescope as the project develops. The letters stand for:

These are features that are critical to the project being successful, and should be obviously non-negotiable.

These are things that are important to the vision, but not quite necessary in order to hit the requirements.

These are desirable features that may simply make for a better user experience, and will probably check the “if we have time leftover” box.

Anything under this grouping will not be included, due to time constraints or scale of the undertaking.

You can use this method to break objectives down for each milestone, and move them around depending on how your timetable progresses.

Here’s an example template.

Product Backlogs

Similar to the MoSCoW method, using a product backlog is a way to prioritise features into a to-do list. There are different versions, and the one I’ve most often used incorporates stating the task, adding necessary details, and assigning a priority. These are also headed with the name of whoever has ownership over these tasks.

Here’s an example product backlog from one of my previously completed projects.

During the project where I used this, I would spend an hour or two a week, during our group’s allocated time together, to discuss each individual’s tasks with them to see what had been completed, and what needed to be done next. I would then upload the updated document to our Facebook group where everyone had access to it.

Interestingly, when I’ve used a product backlog, I’ve found an odd phenomenon in my groups where the team members pursue getting their sections all colour-graded green, and they’ve completed work faster in order to see this. I’m not sure what the psychological effect is happening there, but I think it’s a fascinating form of gamification that influenced people to turn their work into a meta-game, and I definitely feel like I got more efficient results.

SWOT Analysis

Traditionally, a SWOT analysis is a technique that can be used to identify Strengths, Weaknesses, Opportunities, and Threats of the context you’re evaluating. In this case, you can use it to assess a person, team, project, or feature. All instances of use are valuable and I recommend you make your reviews between milestones, or after large feature completions.

Here are some considerations to make when making your analysis, using a feature as an example:

What advantages does this feature have?

What could be improved about the feature?

What trends does this feature match?

What competing features exist?

Approaches to Design

Types of Designer

One of the biggest over-generalisations I’ve seen at university, is the self-proclaimed term “Game Designer”. It’s used so often, and by so many students, that’s it’s become a throwaway term. I even see 3D modellers mislabelling themselves as designers.

When someone tells me they’re a game designer, I want to know what kind and where their specialisations lie. Otherwise I’ll assume it’s everything, and if I give them a task they can’t handle, it’s only going to look bad on them when we’re behind schedule.

So, here’s my overall definition for the role:

A game designer’s role is to solve problems within the construct of a ruleset to improve the experience. They must understand how a game and its systems work, so they can break down where it’s not effective and come up with creative solutions.

With that said, now I’ll go into the general types of game designer in respects of the common specialisations:

Level designers plan how and why the layout of a level is setup in the way it is. This includes asset placement, enemy spawning, lighting, scene unity, balancing, applying suitable scaling & proportions, and general thematic resonance. Level designers often have an artistic eye for detail.

Narrative designers focus on story-building and the pacing of the content. This includes writing the quests, dialogue, overall story, and item descriptions. They can also design collectibles like text or audio logs.

These designers will focus on specific systems within a game. For example, in an RPG this could be talent trees, character skills, enemy abilities, inventories, crafting, and trading.

UI designers devise how the interface looks and feels to convey information about the game to the player. For example, this is anything that represents the player’s health, resource, currency, abilities, and location.

UX design often goes hand-in-hand with UI design because it affects how the player interacts with a system or interface. This includes considerations for comfort and intuition for players to navigate where they need to be, either in gameplay or in a menu.

So now, figure out what kind of designer you are. You’ll more than likely have a baseline understanding of each type, but you should specialise on one.

If you’re one of several designers on your team, knowing this can help you all to slot into place, and distribute tasks accordingly.

Finding the Fun

This is probably the most important challenge for a game designer, and most difficult. Fun is subjective, so something being fun for one person might not be fun for another. In my experience, leaning towards something being chaotic and hectic is what pulls more player’s in.

Don’t just turn around to your team and say “let’s make an RPG” because firstly, that’s a lot of work and scope, secondly an RPG on its own isn’t fun, it’s heavily grindy, and thirdly that’s not an idea, that’s a genre.

Here’s an example from a discussion I had with a designer-friend, where we looked at World of Warcraft’s gameplay:

Is it the constant killing thousands of mobs that’s fun? No, that’s the grind. Is it the character’s spell rotation that’s the fun? I would still say no, that’s just clicking buttons in an order. I would say it’s the resource management of your character.

So, let’s look at Shadow Priest. They have a unique resource called Insanity, which is a bar that fills up as they cast spells. Then once they fill their Insanity bar, they transform into Voidform and gain new abilities. The Insanity bar ticks down and returns their form to normal when their Insanity reaches zero. With each spell cast, the Insanity bar goes back up a little, which effectively makes a minigame of the player quickly trying to use their new spells and stay in this temporary form. The Insanity bar also goes down faster the longer they are in Voidform, keeping the pressure on.

That’s the fun, for me at least. Classes in WoW have different specialisations, and all have different playstyles based around resource management.

Understanding that breakdown is key to finding the fun, and my suggestion is to find a mechanic on its own that you find interesting, and look at how to develop a unique experience around it.

Iterative Design

Iterative design is a key to finding the fun. It’s the process of theorising an idea, refining it, creating it, testing it, deconstructing the feedback, making appropriate changes, and repeating the whole procedure until you reach a suitable outcome.

But always make sure you stay mindful of your designs. Just because an idea is yours, doesn’t mean it’s good. Disconnecting yourself from your pride will help you gain better clarity on the workings of the design.

Additionally, ignoring feedback on the design because you think that person “just doesn’t get it” means you are either explaining the idea wrong, or it just doesn’t sound interesting. All feedback is good, and a lot of the time it can come down to you not communicating the process or action accurately.

Feature Creep

Another point to be aware of during design, is feature creep. You don’t want to get carried away with all the potential and possibilities that your game can offer. Keep it simple, and make sure your higher priority content is of an appropriate standard before rushing to implement the next thing.

Designer Tools

Game Design Documents

Commonly referred to as a GDD, make sure you use a design document when fleshing out the details of your game.

A design document should act like a go to bible for every detail about the game, not only for your benefit, but for anyone on the team who needs to find information. Having this in place allows you to free up some time by not having to answer smaller questions from the group because they can refer straight to the document. This means it’s important to make alterations and additions to the document as the project goes on, otherwise incorrect or outdated information can impact the team negatively.

Besides being for the benefit of the team, I’ve also found that taking an idea and filling out the document’s sections helps me to understand the idea in a lot more depth, allowing me to improve the design as I go.

Another point for a GDD is that it improves management efficiency, as the project leadership is able to distribute tasks appropriately. That’s why I would recommend that a game design document is the first thing your design team put together.

For the structure of your document, there’s a lot of common headers including: Game Overview, Gameplay & Mechanics, Concept Art, Asset Lists, Narrative, Setting & Characters, Levels, Interfaces, Controls, Audio, Artificial Intelligence, Technical Requirements, etc.

Here’s an example of a game design document I created for a group project I was involved with during my first year at university.

Here a list of example design documents for commercially released games:

Bioshock

Doom (1992)

Fallout

Grim Fandango

Grand Theft Auto (Race ‘n’ Chase)

Leisure Suit Larry

Marble Madness

Monaco

Planescape

Tron

Information Architecture

Information Architectures (IA) are a great way to visually represent organised systems. In UI design, forming an IA helps to serve as a wireframe and guide for implementation, as it should include all the key information required to represent navigation between screens.

Here is an information architecture that I built recently for a project, with integrated legend explaining the colours and silhouette values:

Key things to consider when building an IA like this include:

Check out www.draw.io for quick and simple flowchart making.

Reference Documents

This was a useful technique I employed during a large group project where most of the team was comprised of artists.

Create a document that lists all the environmental assets, characters, and UI elements needed for the game, and source imagery that you feel best represents each entry in their design. Then make sure to pass it to whoever in your team oversees the aesthetic vision. In the group I used this for, I passed it to the concept artist and we sat with the lead artist to discuss how exactly the world we were building was going to look.

Here’s an example reference document that I used on that project.

One Sheets

One Sheets are a useful exercise for when you want to convey a quick summary for an idea. All they need to contain are a few points of key information about the idea, and some relative imagery. This makes them great for a design that focuses on developing lots of a similar mechanisms, like characters, weapons, or vehicles.

Here’s some examples of one sheets I’ve thrown together for projects:

Approaches to Tech

Engine Choice

A lot of the time your university will be pushing you towards a game engine to use, and that will likely be Unreal Engine or Unity. However, if this is a decision you are free to make then your team need to consider the circumstances that will influence your choice. These include:

What programming languages is your tech team familiar with?

Are they taking any modules to support an engine choice?

Are there enough techies to provide a crutch if there’s a lack of knowledge and someone needs to spend time learning?

How much work is there to do?

How many features of an engine will you need to take advantage of?

How big is the project predicted to be?

How much time do you have to complete the project?

How much commitment can your team provide?

Is the game art-heavy?

Are you using pixel-based graphics?

After discussing the answers to these considerations, your choice will likely be clear.

Engine Etiquette

If the scripting for your game is likely to be accessed by multiple people, it’s really important to keep a professional approach by applying some organisation protocol. Doing so will increase the efficiency of how the scripts are read and maintained.

For visual scripting, you need to ensure that graphs are consistent, readable, and able to be navigated without confusion. The following image shows a screenshot example of some UE4 blueprint I scripted for a recent project:

From that, here are some things to note:

When using an engine editor, anytime there is a hierarchy of content you should be setting up suitable naming conventions for folders and files. These names should ideally be stylised in one of the following ways:

This is a style that contains no intervening spaces or punctuation in phrases, and instead capitalises the first letter of each word (e.g. RuinsIndoorFoliage).

This is similar to how the C standard library abbreviates commonly used words (e.g. “charloc” for “character location”).

This is like how the C++ standard library highlights word separation with the use of an underscore (e.g. Forest_Ruins_Winter).

The above are just examples of conventions that I’ve adopted and practiced, you may have your own, but the important thing to take away is that your tech team are using the same programming style. If it helps, you can write a style guide to ensure the same principles are adhered to.

Here’s some examples of well-known style guides:

Microsoft’s C# Coding Conventions.

Google’s C++ Style Guide.

Code Ownership

If everyone has access to everyone else’s code, it can quickly descend into a nightmare when different people are making alterations to the same script. So, it’s a good idea to implement an ownership system.

Divide exclusive responsibility of entire scripts to individual members of your tech team, and set a rule that only that person can modify the code. If someone needs access to something in that code, request that it be made available via a public function that returns the information. Then, have a master build that people only overwrite their owned files on.

Also, look at using managers for everything. They’re very useful for listening to relevant scripts, and handling information to be stored and accessed elsewhere.

Alternatively, dedicate a person to be the ‘Code Steward’ and oversee the master build. It can be this person’s responsibility to review replacement files for inconsistencies, and implement them into the live project.

Version Control

Also known as ‘source control’, this is a software management system that handles tracking all changes across a project build. It saves iterative states of the project to protect the assets from being lost due to an error, human or otherwise.

Because of this tracking, using version control allows for multiple copies of the same project to be distributed across the team for everyone to work on their tasks simultaneously. It can then merge selected changes from across multiple versions to create a new build with these changes applied.

Here are some popular source control platforms to further research:

Git.

Perforce.

Subversion (SVN).

Concurrent Versions System (CVS).

Changelogs

If you decide to save time and have an open mind about ownership, where scripts are available for everyone to modify, and/or you choose to merge your team’s project’s manually, then make sure that all the tech team are keeping their changes recorded.

You will definitely want to have a dedicated code steward that handles the merging in this case, and to make their role more efficient you all need to be noting down a list of changes.

Consider tracking the following information:

Giving this changelog to your code steward, with the associated build, will be a much more efficient process as it takes you less time to make your notes than it does for the code steward to trawl through everyone’s code.

Build Often

Once you’ve hit the first milestone deadline for your project, you should have a playable version of your game. Now I recommend that you build often, probably at least once a week. This gives you a good chance to identify and deal with any errors that happen to occur.

I’ve made the mistake of leaving it until the end, complacent with the thoughts that it should be fine because it’s my work. This is wrong. Don’t do it.

Approaches to Art

For this header I want to note that I am not an artist, and am not familiar with the processes that students on the art-side are taught because all my modules were split between design and tech. I do, however, have a talent for observation, and could listen to and communicate with the artists in my projects. Therefore, this section will concentrate more on my opinions on what I saw.

Establishing a Pipeline

You should begin the project by having a discussion in the art team about where you should all slot into during the process of creating and implementing art assets.

The most successful pipeline that I saw in my groups was set out as the following:

As mentioned previously in the design section, a ‘reference document’ would be created as a guide to the aesthetic vision. This would be taken to the concept artist and lead artist to discuss in further detail how it would look to fit our game.

The concept artist would then draw several versions of the design in rough thumbnails and return these to me and the art lead for further discussion. When we’d agreed on the one we liked, the concept artist would go back and draw it up in greater detail from several perspectives.

Next, the concept would be modelled by whomever the task belonged to.

The model was then forwarded to the lead artist, who looked over the asset and sent it back to the modeller if any alterations needed doing. When the model is okay, the lead artist would hand-paint the textures.

Next, it was myself that would bring the asset into engine and setup the materials, collision, scaling and placement within the level.

Finally, the lead artist, concept artist and lighting artist would give the asset a glance over in the scene, and give it the all clear if it met the standards we were reaching for.

This may not be the industry approach, but this method certainly worked best for our project as a small university team. So, I recommend you also look at forming a flow of work that incorporates appropriate decision-making amongst your teammates.

Asset Limitations

Know your constraints, and work closely to those restrictions. The larger the project, the more constricting the budget will be for areas like polycount or texture size.

Make sure you are also creating assets that are suited to the job. For example, if you’re making a mobile game then it’s probably not going to be wise to throw in 4K textures.

Understand that restrictions aren’t a bad thing, appropriate boundaries allow you to improve your craft as an artist by learning to be creative with the space you’ve got.

Likewise, having no limitations can be a bad thing. In a constantly evolving environment like the gaming industry, there simply is no time to be a perfectionist.

Consistency

Once an art style has been confirmed, take some time to practice it, because there’s nothing more jarring than a game with different styles attached to it.

This feeds into the idea that, as an artist, you need to be flexible. I once witnessed another group argue with their concept artist because he refused to work to the art style that had been decided. When they asked him what he’d do in this situation in industry, his response was “I’ll never work for a company that doesn’t match my style”. I never saw him again after that day.

Lighting & Visual Effects

Having someone on the team with a special aptitude towards the art of lighting or particles can take your game from looking like a student project, to looking like the work of an indie studio.

If you can afford it, dedicate someone to a full-time role working on these aspects. Even if the person has a basic knowledge, make sure they are researching and practicing as part of their tasked timetable.

I’m putting weight on this subject because I feel it’s the approach to this aesthetic that can truly make or break a game’s execution. Especially, if you want to mask the team’s lack of design capability.

Animation

Unfortunately, I didn’t have much luck in getting animators in my groups, so I haven’t got much to say about the role and how it fits in. I’m not sure if this is simply my bad luck, or if this is a commentary about a lack of students pursuing animation as a career direction in games. I’ll leave that research to you, but from what I saw in most other groups, a talented animator is hard to find.

Reality Check

An important point I want to make is that in game development, it’s natural for aspects or full features in a project to be cut. This can be due to several reasons; like scope limitations where there’s only so much time to polish x-number of levels, or a change in direction that makes more sense to the tone and feel of the design.

Either way, I’ve found that artists, in general, are prone tobeing more sensitive about their work being cut than others. Probably due to their capability of being more emotionally tuned in. But please do not take it as a personal attack, you’re still valued and have the work to show for your efforts.

Here’s a quote from Dishonored’s Art Director, Sebastien Mitton, when discussing whole levels that were cut from the game:

Approaches to Quality Assurance

Quality Assurance

Quality Assurance (QA) is the process of testing highly complex software, like games, to identify any incorrect behaviours, visuals, or experiences.

Lots of testing means lots of opportunities to discover issues that can be dealt with as early as possible, which then improves the overall experience. This means it’s something you’re going to want to be performing as early as your first playable build milestone.

Testing Methods

Because you are unlikely to have a dedicated testing team, an obvious approach is to just have your entire group test the game. I find it effective to devote half your allocated time together every few weeks to do this. Not only does it help everyone see the progress and results of their work coming together, but the different crafts people bring to the table can help them spot things that others may have missed.

Alternatively, in your communal working space, setup a computer with the game running and instruct everyone to spend at least 10-15 minutes a week testing. This takes less time from their working day, which they’ll probably be happier about if they don’t like having to test, and also has an added benefit of being available to passers-by or members of other teams to come over and playtest.

Bug Reporting

When it comes to getting feedback about the game, you’re going to want an efficient way to communicate the discovered issues. I recommend getting a document together for your testers to fill out as they play through the game.

Here are some points for consideration on this document:

Provide a brief summary of the issue.

What was expected to happen.

What actually happened.

If the issue is a visual one.

How to make the issue occur.

Out of 10, how much does this affect the experience.

I’ll also note that, ideally, if you can have playtesters recording their sessions then you can learn a lot more about the player’s behaviour in your game.

Iteration

Review your feedback often, like as a batch once a week. When you do so, setup another document that breaks down the feedback into relevant categories like art, design, level etc. Log whose responsibility it is to clear the issue, and give each bug an ID so that it’s easier to track once allocated. You won’t need to write the same bug multiple times, but bear it in mind when assigning a priority value.

Here’s an example Feedback Review from a previously completed project.

Software

I wanted to take a header to briefly go over software that, although not all mandatory, should be worth consideration.

Industry Standard

This is a list of software that you should expect to use on a regular basis from university to industry. If you’re not familiar with any of them, then I implore you to do yourself a favour and learn them. You don’t have to be a master at using them, but you do need to be confident in understanding how they work.

I shouldn’t need to mention this one, as it’s obviously well known. But if you’re not familiar, you’re dangerously behind everyone else.

Again, you should know this. It’s used for spreadsheet development, and probably applies to designers more than anyone else.

Presentations are a common procedure, especially in university, and this is the most accessible way to produce them.

A graphics editor used to edit and compose images. Everyone should know how to use this, even designers and technicians, because the ability to quickly throw together an image can accurately convey a better vision than if you were to describe it.

A super simple and quick method of putting together a survey that’s easy to use and share. Additionally, it looks good and organises results into easily absorbable charts and lists.

Online storage provides a convenient way to drop and share files that you can access anywhere. Example services include Google Drive, OneDrive, and Dropbox.

Other

The software in this list isn’t as important, but I still feel they’re worth looking into, in case they offer a solution you prefer.

An online task management tool that allows you to organise information into boards, lists, and cards. Visually similar to using a post-it note system.

A task-tracking and distribution tool that allows a task to openly pass through team-members in a pipeline. This is popular in quality assurance testing.

This is a cloud-based toolset that allows teams to communicate across different channels, similar to Discord.

Research Resources

To be blunt; you need to know how to research. If you’re stuck and can’t figure out how something works, then you have to look for the answers, don’t wait for them to come to you.

I’ve seen so many students not doing the work because they ‘weren’t shown how to do it’. This is, quite frankly, a cop out. If you think you can get away with this in industry, you’re going to be in for a shock.

So, here’s a quick list of go-to places for research:

You’re probably under the belief that Wikipedia is an unreliable source, due to its content being open for editing by anyone. This is true, when it comes to academic writing, but if you scroll to the bottom of the article and start reading through the cited references, you’ll find they’re a good starting point in your research.

YouTube is brimming with more content than you have time to consume, literally, and a lot of this content comes in the form of tutorials. With a few suitable search tags, you can look for channels dedicated to your area of expertise and learn new things, or validate the knowledge you do have.

The Game Developers Conference is the biggest event for professional developers in the games industry, and the website has an archive full of presentations from all aspects of industry. This is a great site to learn what works and what doesn’t from those who have the experience to back it up.

Gamasutra is a site dedicated to hosting user-created content about video games, in the form of: news, essays, blogs, game post-mortems, advertised jobs, and contract work. It’s a rich source of information that’s become a leading platform for enhancing discussion through journalism.

This is another source for tutorials, interviews and articles that focus on providing information on the recent trends of the game industry.

No, seriously. Every university has one, and it’s full of reading materials catered towards your courses. It’s true you can source these materials online, but usually the library is free. You also might find they provide others useful services, like my library has the latest games available to rent.

Motivation

Money

When it comes to working on a group project, the largest difference between university and industry is the average level of dedication you see, and this comes down to one incentive: getting paid.

On average, students tend to lack the sense of urgency when it comes to doing the things they need to, and this primarily comes down to money. In the UK, we have a pretty amazing loan system in place that provides us with plenty of income to cover everyday expenses, and then some. However, I believe this system gives students a crutch to lean on, which relieves the pressure of normal life where we need to be considering affording rent, bills, food, etc. This in turn breeds complacency.

So, if we’re talking about money, let’s rephrase this into promoting a sense of rationalisation. During my bachelors I received roughly £16-17k a year from loans and maintenance grants. Then I probably had around 230 days from the start of my first semester, to the end of my second semester. This means I’m spending at least £70 a day to be in university, every day, including weekends. So, if I decided not to work one day, that can be perceived as though I’m paying £70 to take a day off. If you have trouble finding motivation, apply this logic to your situation and ask yourself if you can afford to pay £70 to take a day off, because I find it really hard to justify.

Mental Health

Another factor at play is mental health. In the game industry, it’s sadly all too common to find people suffering from disorders like anxiety or depression, and these can contribute to not feeling able to find the motivation to do anything. But I’m nowhere near qualified to talk about this.

What I can suggest though is that you try to communicate your issues to your lecturers and team, whilst also seeking out your support system. Your university should have services and advisors available for students to benefit from if they’re experiencing difficulties. If you feel problems are growing, you’re overwhelmed, and struggling to cope, don’t stick your head in the sand, contact your wellbeing advisors.

Personal Philosophies & Other Points

I’ve added this header to serve as a collection of points and personal philosophies that I wanted to make but didn’t feel like they fit anywhere above.

Have fun

This is honestly the key, and it’s so simple. You’re making games and exercising the talents you’ve chosen to hone, so have fun doing it because if you’re seriously not enjoying your work, you should think about whether or not this is the right direction for you. Moreover, if it’s no longer your passion, it’s okay to quit. Don’t waste time not doing the fun thing. Find your fun. Even if in 10 years’ time you realise that you do enjoy making games, but you didn’t when you dropped out, you can still go back to it and you’ll probably do better at it because you’ll be going in with the right attitude.

Friendly Competition

I’m not a naturally competitive person, but when it comes to academia I’ve always gravitated towards having a close friend that excels at being among the best. This helped me because I began to see their attitude and abilities as a goal for me to match and do better. Now I have the mindset of always looking to improve, because if there’s someone better than me then I’m not working hard enough.

Be a “Yes Man”

Why don’t you try saying yes more? See a local game jam event being hosted? Say yes. Notice someone reaching out to collaborate on a project? Say yes. Your team want you to focus on an area you have little experience in? Say yes.

Breaking out of your comfort zone and challenging yourself to do more is great for your personal development. You’ll build communication skills and in turn build more networking connections. It’ll also strengthen your portfolio and give you more talking points in an interview.

Personally, I love to collaborate on personal projects with friends from different skill backgrounds. Especially artists, because we both bring something completely different to the table that feeds into each other to create a better-quality result.

Crunch-time

The idea of crunch is a very double-edged sword, and a lot of people will shudder at the thought from PTSD. But what I want to consider is the idea of “healthy crunch”.

I haven’t yet undergone the standards of crunch as an industry professional, but personally I’ve found the crunch process to be a positive stage at university. This is because I’ve kept to a schedule that has allowed me to hit all the most important aspects of my projects, leaving crunch to be a time for polishing the extra parts. I’ve also seen others thrive during the crunch period, because pressure can sometimes breed innovation.

But to each their own, and again this is just my own perspective at a university level, and I’m well aware of the horror stories that get shared about some company approaches.

Communication (again)

Let’s take a moment to address how essential it is to possess good written and verbal communication skills.

You’re going to be working with a team of people, and you’re going to need to share a vision in order for the project to move forward. This means being able to either explain the concepts, or ask enough questions to understand the concept.

Your team won’t be around you all the time, some may be from a foreign culture where their knowledge in your language isn’t as experienced as yours, or you may even have some distant-students who solely work on their course online. In any case, you need to be able to articulate during written discussion with proper spelling and grammar.

Don’t speak in slang, it’s confusing to people without a shared background.

Dyslexia is real, and I acknowledge that, so research ways to cope and manage it. If it’s causing an issue between you and others, make sure you that you communicate your condition, it’ll help others understand.

Also, don’t be the college kid that uses a thesaurus on every other word to find the biggest ones. It doesn’t make you look clever, it makes you look stupid, and the more experienced you become, the more cringeworthy it appears. Stick to simple sentences that get the point across. The less words the better, as long as it’s conveying the right vision.

Group Conflict

This is where communication also feeds in, but more so it’s how you handle the situation and your emotions.

Conflict can happen, and it can feel pretty heated, but you need to raise grievances correctly. For instance, yelling and speaking over people isn’t constructive, that’s what children do. Adults have a conversation, listen to each other’s point of view and then discuss those points in a diplomatic way.

If you are having a hard time dealing with your emotions, suggest taking a break to process your feelings, then return to the conversation with a fresh head.

If no resolution can be achieved, that’s when the management hierarchy needs to pull rank and make a decision about the subject.

Lack of Team Contribution

From time to time, it can feel as though you are the only one putting a significant amount of effort into a group project. That is why having a strong faith in your management should ease the scope to mitigate the damage.

For the culprits themselves, unfortunately there’s not a lot that can be done about this as you can’t force someone to work, and it’s not your place to. But if the situation becomes unbearable, speak to the staff overseeing the projects about moving to another team if possible.

Lecturers

Your lecturers are there for guidance if you need it. They’ve been through what you have, and come out the other side. They’ve also chosen to stay in academia and drive their craft forward with a role that constantly researches new techniques.

So, if your own research falls flat and you’re not sure where to go next, ask a lecturer for advice and they’ll surely have a catalogue of resource materials to point you in the right direction.

But also remember, this isn’t high school. You can’t repeatedly ask lecturers to help with your work or give you a one-to-one meeting on a lecture that was given to a whole class. If you’ve exhausted your research, and really need help with your work, save this for when support sessions are hosted, unless otherwise stated.

Conclusion

So, there we have it, that’s my guide to successful group projects at university, with a focus on game development.

To re-iterate, this is all related to my perception and opinion. If you feel differently about any of the points I made, that’s absolutely fine, I hope it at least challenged you to think about your stances and affirm them. If even one point was new to you and helped you improve your approach, then I feel my guide has been successful.

For any queries, you can find a contact section on my site at lukehaslett.weebly.com.

Thanks for reading!