Guide for Working on a Game Team
I’m excited about getting this rolling to you all! Below is the outline of what I put together for my first official presentation. It was given to a group of students who were gearing up for a team project in the Unreal Engine.
Let me know in the comments if I missed anything that is worth noting.
A Guide for Working With a Team
Don’t assume a common language.
Language is the foundation of any successful communication, and game creation is full of contradictory terms.
Often terms can cross disciplines but may have different definitions.
Words like “skinning” can mean one thing to an animator, and something completely different to an engineer depending on the context.
Try to create a common language between disciplines to minimize confusion and assumptions leading to wasted time, or even worse, assumptions of who is doing what.
Communicate game specific systems and terms immediatly upon creation, and update them as soon as any changes are made in order to make them common usage within your project.
This is known as cultural language. Each game project has one, and it is best to be conscious about how it’s created.
Communicate and understand who works on what.
When working with a team, all files are shared.
Meaning that at any one time you could have multiple people working on a particular file or files.
Someone may need to make an adjustment to an exported file at anytime.
It is ALWAYS important to communicate those changes to team members so everyone is on the same page.
Learn where your files are going and how they are being used.
Learning how your files are implemented can often show how they can be created more efficiently and will ultimately help determine the manner in which they are made.
Smartly Divide Work
The structure of your team always determines how work is split up. It is important for every member of the team to know their own role, as well as the role of everyone else. This ensures that people know who to seek out for specific information.
This will also prevent multiple people from trying to fix the same problems at once.
The other vital part of this is to make sure once it is time to pass something onto the next person, you communicate that hand-off to others involved.
Check your changes in-game before you upload game content
The most important lesson I can pass on is this;
The only person that can make sure your work goes in correctly, is you.
If you haven’t verified your work in-game, then you haven’t done your job.
The task of creating art, or code for that matter, is not completed when the export or compile button is pressed. It is done when the game behavior\end result is verified while running the game. The game is the final frame in which your art or code is evaluated. It doesn’t matter what it looks like anywhere else.
This will ensure that you’ve covered all of your bases which will help keep you in the clear when something breaks.
Own your mistakes.
Game creation is hard.
Don’t make it more difficult by denying your own mistakes. No one is infallible.
EVERYONE screws up.
Denying your mistakes wastes time and hides bugs and issues that need to be addressed.
Problems can be fixed, but only if the root of them is revealed to those who can fix them.
Upload source files to source control
Working with source control can be tricky to wrap your brain around, but the main issue is: If you haven’t uploaded your files, no one else will have them.
In the case of source files, (Maya, Max, Photoshop, etc…) it’s just as important to update them frequently for your own sake.
Anything that CAN go wrong, WILL go wrong. It’s best to cover yourself by having the server store extra versions for you with the same name, so upload at the end of a work session to incrementally save your progress without having to keep a ton of files locally.
Discipline Specific Concepts
It’s easy to think of each new system in isolation.
Not so much as the code itself, or what it does, but more how it does it and who else needs help to set it up for it to be fully functional.
Generally, the issues that arise tend to be where and when it interacts with art. Getting the art to show up the way the artists intened is one of the most important roles it plays for the end user.
The art is what users see and interact with, it’s also not the thing you want to spend time implementing with an artist looking over your shoulder.
Split up systems that need direct art input in a way that allows artists to control as much of the process as possible. Some back and forth is unavoidable, but peel off the simple things so that you only need to focus on the last 10% with direct artist interaction. They have owned and implemented the majority of it, and you will have a common language to help complete the last leg as a collaborative effort.
Like everything else, it’s best to stop and consider what art you will need and how it will be created and used. Once you have done that, think about how you can create it in a way that makes the art easy to fill in for the artist. This will ensure a happy artist, and will prevent your frustration later when you avoid the step of “pixel pushing” with an artist directing your mouse.
Questions to consider when writing code:
In what way is the system using art?
What would be the easiest way to implement the art needed with no knowledge of how the system is put together?
How would the functioning of this system affect how the art is created?
Does this system require certain information embedded in the art?
In what way could the art information be automated?
The most important thing you can do as an artist is figure out how your art is going to be used and how it is going to look in game. It’s more than likely that by the time your art has been exported and hooked up in game it will not look like it did in your creation package. Whether it’s the lighting, the shader restrictions, texture compression or even what is around an object in the scene, it will certainly look different than you planned.
Always use the game as the final step in viewing your art, as it is where it will be framed.
It is also important to know where and how your art is going to be used. Important questions are:
Is this going to move in game or be a static object?
Is this going to be in the background, or close up to the in game camera?
How big will this end up being on screen?
How big is our screen?
Will this be placed in multiple areas or is this one big piece?
What else can share this texture?
What is the range of motion for this character?
How much does this character need to move?
How close is this character going to be to the screen?
Is this a main character or a side character?
How many joints does this character really need?
Do the animations need to blend together?
Are these animations going to be looped?
Do I need to create an animation tree for this character?
Project Setup Gotchas
Core Needs for Game Content Creation:
The exporting of animation
Implementation of models
Exporting of models
Playing animations from code
Placing models in the game
Setting up art to be interact-able
Don’t Reinvent the Wheel
Yes, its fun to make your own version of everything out there, but it’s not time effecient.
Focus on the tools that the respective engine has available already and push them to their limits BEFORE spending time making a new system or downloading one from the store.
This will help reduce the context switching in the editor as well as preventing the project folders from being filled with extra files.
Art Polygon and Texture Budgets
Set your texture\polygon budgets based on the importance of the object.
Search online and give some basic standards for sizes and poly counts, then stick to them.
A good fallback is the think of the resolution of the screen then apply that to how big your models will be on it. If your screen resolution is 1024 x 1024 and you have a 20k bowl with a 2048 texture that takes up 1/16 of the screen, you probably need to reevaluate your use of texture space and poly usage.
The smarter you are from the start, the less engineering will have to analyze everything you’ve done, or blindly quartering your textures behind the scenes to reduce the memory.
Trust me, it happens all the time.
Set your scale!
I can’t emphasize this enough.
This can be one of the most difficult things to try to change later on and will be the bane of any artist trying to create art that fits in the world.
It is important to set this up before you even start prototyping and make sure that all team members have the settings properly in all their content packages AND that across the whole team their game engine is setup as well.
Even if it is WRONG, as long as it is wrong the same way across every team member’s machine.
Check the links at the bottom for some online tutorials on Unreal guides for setting scale and managing your project.
Standardize FBX Export Settings
Another important one to sync up with the team.
Create a standard for all the models and animations that will be imported into the engine and make sure that it is communicated and adhered to across the team.
Helps with debugging when everyone is using the same settings.
Create code that works for art
Identify what art will need to interact with and make it easy.
Identify what level of control art will need and expose that in a way that will make it easy for artists to implement.
Don’t try to do everything!
Create clean art!
Only export things you need in your file.
Don’t export extra meshes or transforms into the game!
Clean your hierarchies
Get rid of all your extra transform objects as well as all the garbage translate\rotate values from your object before you export.
Name your meshes\layers! All of them!
Save your sanity as well as everyone else’s! Keep things looking professional and easy to reverse engineer.
Future you will appreciate it.
DON’T UPGRADE YOUR EDITOR!
I know it’s fun to always feel like you are on the cutting edge, but project upgrades often lead to issues which can cause a massive time sync for people on the team. It’s generally best to keep the version you are on unless there are SPECIFIC changes with the new editor that you need immediately.
Even then, the decision should be measured carefully and discussed with the whole team.
As a general rule, take a long view of your project and how much time you have to create it. If it is less than 6 months, pick a version and make sure the rest of the team has the same one.
Setting up Project Folder Structures
As a general overview, create a directory outside of the project directory that holds your source art.
Have that directory exactly mirror your project directory so that you know where to find the source files involved with creating your in game content.
Think about every new folder you make and how it will be used.
Questions for folder\file creation:
Is there already a place that stores things of this nature?
Is this something that has a larger set of dependencies?
Should all those be grouped together?
Is this a one-off object, or is there a group of similar objects?
Who needs access to this folder?
That’s it for this post folks!
If you have questions\comments, please get ahold of me in the comments below or send me an email email@example.com.
I will keep this page updated with any corrected information as I go along, I hope you got something out of it!
Happy Game Making!
Handy Unreal Links:
- FBX import options for unreal
- Scale inside Unreal:
15 Free Unity Asset Tips
Join the community and stay up to date with the whats happening with the site!
I'll also throw in my top 15 tips for managing assets inside Unity!