Producers and managers face unique challenges when managing a team of student game developers. This article examines these challenges, how these challenges prepare students for leadership in the industry, and some recommended solutions to the challenges.
I have worked on several large student game projects as an undergraduate, alumni, and graduate student. On most of these projects I have filled a management or team lead role. Some of these student projects went very well, and some of these projects were plagued with issues from the beginning and ended up failing. I have learned much from these projects that I'd like to share with you.
To clarify, by large student game projects I mean a development schedule of multiple semesters and teams of more than five developers. Oxygen, the project I'm currently working on, has a team of 18 students working on it and we're aiming to ship our game after 12 months of development.
Behind every great game is a great team. They didn't always exist - they had to form at some point, so how do you go about building your team?
The best way to recruit new team members is to sell them on your project's vision and objectives, but you need to understand your vision and objectives before anyone else will. With Dia de los Dinosaurios, our team was inspired by the platformers of the Nintendo 64 and our goal was to create a game that could be a memorable part of our player's childhood. This means pitching your ideas to other student developers and not being afraid of them "stealing" your ideas.
An alternative method that we use at the University of Advancing Technology are our game studio courses. The courses are required for graduation and students that are in the game studio courses apply to and work on the set of games that the game development faculty have greenlit. Even if the students are required to work on your project for a class you still need to sell them on your project or you're going to get the bare minimum out of them and they'll leave the project at the end of the semester.
You must understand that bigger isn't always better. In fact, on teams less is more. In one of my first student projects, we made the incredibly faulty assumption that a bigger team meant we would get more work done. The problem with large student teams is that scheduling meetings and communicating becomes more and more difficult very quickly as your team grows in size. The overhead of managing a team of 20 or 30 is more than you're going to have time to deal with as a student. Don't be afraid to cap your team size but make sure you cap your project scope accordingly.
Larger teams tend to break into cliques and these cliques don't always play nicely together, which can be very unfortunate since the team leads tend to form a clique of their own. When this happens, you're almost guaranteed that everyone that isn't a lead is going to leave your team at the end of the semester if not sooner. If you act early enough, you can prevent the barriers between cliques from forming through team building exercises and shuffling seating arrangements in the work area. If cliques have already formed you're going to have to be prepared to manage conflicts that arise between the cliques.
One distinct difference between working in the industry and working as a student is that you and your peers are not permanent employees at a studio. Every potential team member at the university will be there for a limited amount of time. In general the more experience a person has, the closer they are to graduating and leaving the university (and by extension, they will probably be leaving your team).
The biggest motivator for someone to stay on your project is an intrinsic motivator - it's not a grade or a paycheck. If you want people to stick with your project to the end, they have to believe in your team and believe in your project and that takes a good amount of persuasion and you need to understand and communicate your goals and vision for the project, as well as listen to your team to find out what is important to them.
Full-time students have a lot of work on their plate that takes precedence over your game. A full-time student is taking 12-18 credits each semester, which translates roughly into a 40-60 hour work week. A full-time student is working full-time on your degree, and you can only reasonably expect 4 hours of productive work each week from each team member! Over the course of a semester, they have less than two weeks of full-time work to commit to projects. As tempting as it may be to work on multiple projects at once, a student is better off committing their four hours exclusively to one project to see it through to completion.
At the start of the semester, everyone has this perception that they have a lot of time to complete their work for the semester so there is this tendancy to try and do too much in a single release or to put off the difficult tasks to the end of the semester. In school, we've been trained through the years that the hardest task is always the final project or final exam, but in projects you frequently want to begin working on the hardest tasks early in the project to ensure that they get done.
Scope management for a student project is a pretty big topic - big enough to warrant its own article (which is coming soon). My scope management process is pretty involved and includes a mix of agile and waterfall practices.
Since you have a four hour work week, I guarantee you that whatever your planned scope is, it is too large and needs to be adjusted.
There are legal challenges you'll face if you want to comercially release your student project. I would actually advise against building a student project with the goal of making a profit - you're better off starting a studio if you want to go that route. I actually recommend treating your student projects as learning experiences, releasing them for free, and entering them into student competitions.
Even after all the work you put into your student game, you probably don't own the intellectual property rights to the game which means you can't release your game commercially. This may be some pretty bad news if you were planning on making millions by selling your game. The standard in the education industry is that your university takes ownership of what you create as a student. Make sure to check your university's intellectual property policies to avoid nasty surprises.
I lucked out by working on projects at the University of Advancing Technology - students retain ownership of the works they create but grant the University a non-exclusive royalty-free license to use, copy, display, describe, mark-on, modify, retain, or make other use of student work consistent with the university's educational mission, and the university may use both the student's likeness and work in its marketing, promotional, and instructional materials.
Even if you find a way to retain ownership of your intellectual property, you still need to get the intellectual property of the game assigned to one owner. As mentioned previously, students tend to come and go on long-term projects. The students aren't employees, so you need them to sign a legal document that assigns the intellectual property rights. As a student, a lawyer is going to be prohibitively expensive. Luckily, there is a free option - it's called docontract and it generates plain-English legal agreements.
Unfortunately, even if you follow the above advice you're probably working with software licensed for educational non-commercial use only. This means that the work made by a student project can't see a commercial release. That's going to put another kink in your plans to release your game commercially.
Alternativeto is a great resource for finding free or discount alternatives to premium software that you could not afford a professional license for.
This is an element of game development that students forget all to often - releasing the game. If you're trying to get a job in the AAA industry the hiring managers are going to care more about games you've shipped than games you've worked on. You may have heard the cliche, but it's true that the hardest work on a game project is the last bit of polish in the run up to release.
Ultimately, you must release the game. Don't just stop working on it - make sure it's releasable before you finish working on it and ship it. It probably won't have all the features you wanted to implement and it might not look nearly as good as you imagined, but get it out into the world and into the hands of people that can play it and give you feedback. Feedback is how you improve as a game developer.
There are several great digital distribution platforms out there these days. I'm fond of itch.io because it's easy to get your game on there and you can release your game for free. If the game is something you're proud of, make sure you submit it to the IGF student competition and talk to your university about entering it into the E3 college game competition.
Was there something I discussed in the article above that you'd like me to explore in more detail? Have any questions? Post them in the comments below!