Get the latest Education e-news
  • A Comprehensive Guide To Successful University Group Projects

    - Luke Haslett

  • Approaches to Management


    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.


    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.


    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.


    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:

    • Must Have

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

    • Should Have

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

    • Could Have

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

    • Won't Have

    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:

    • Strengths

    What advantages does this feature have?

    • Weaknesses

    What could be improved about the feature?

    • Opportunities

    What trends does this feature match?

    • Threats

    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

    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

    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.

    • Systems

    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.

    • User Interface

    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.

    • User Experience

    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.


comments powered by Disqus