Sponsored By

How To Be A Successful Student Videogame Producer

When I was studying Game and Simulation Programming at DeVry University I had several experiences leading a team of student developers. After leading my second videogame project I decided to compile a guide for the student projects following mine.

Miles Aurbeck, Blogger

January 11, 2011

6 Min Read


The best way I can see to go about providing the information I am about to is to follow typical book conventions, so please excuse the formality.


This article provides student game developers with information to bolster their current knowledge by providing a structure for handling project management and producer type responsibilities.

Who Am I:

I am currently working as a programmer and level designer at an educational videogame company in downtown Chicago, Il.  When I was studying Game and Simulation Programming at DeVry University I had several experiences leading a team of student developers and now have professional experience carrying out tasks that an associate producer typically does.  While in school my peers and I were all very inexperienced. Project management and producing was the last thing on anyone's mind.  There were large misconceptions about what it really meant to be 'team lead'.  I have always had an affinity for planning the course of action for a given goal and I can see that others might struggle in this arena. After leading my second videogame project I decided to compile a guide for the student projects following mine.  I have revisited my work and am both rounding it out and updating it with the knowledge I have gained since then.

Who Are You:

I hope this information is used by all students who take on the responsibility of leading a team to the completion of one or several of their student game projects.  If you are reading this and are in school for video game development in any capacity you will learn many things to help keep you on track.  You will be able to use this information to make sure your project is completed to specification, on time and to the satisfaction of the team, your professors, and yourself.  If you are a professional experienced at managing videogame projects all I can hope for is that you lend a hand and help me to evolve this book into an evermore useful entity for all the budding game developers out there.


Some of the information within can be extrapolated to real world projects and applied elsewhere.  The text is primarily written for a student's resources (i.e. time and people).  I don't intend for you to assume that all the information here is timeless and correct.  What I do know is that this is how I completed my midterm game project, Jojamian, and the way I carried out leading the project could be beneficial to you as well.  If any of the information here conflicts with what your professors say listen to them instead of me.  They are the ones grading your project and ultimately the client of your software product. Use this as a buffer to the processes you may have already learned about in your studies.

Chapter 1: Ping Time

Student team members need to constantly stay in contact with each other. Ping time is the amount of dedicated meeting time within each week of development.  I recommended at least three meetings a week. Two of these should be face to face meetings. One of them can be an online group chat.  The ideal setup would be Monday-Face, Wednesday-Online, Friday-Face. I suggest that the online meeting be between the two face to face meetings and that they all be 2-3 days apart from each other.  The purpose of these face to face meetings should be designated as either discussion or development.

Chapter 2: Scope

The largest factor as to whether or not a student development project succeeds is the scope of the project from the outset.  Several criteria should be taken into consideration when establishing the scope of a project.  These include but are not limited to prior experience, natural abilities, length of development cycle, familiarity with technologies used, and number of completed games.  These listed items refer to each individual member and the team as a whole if its members have worked together in the past.

It is highly recommended to choose an existing game to recreate or port.  This might mean choosing a less exciting game and risking buy-in.  Changing one small portion of an existing game in its recreation process is also acceptable.  A few occasions where an original idea could be considered is if one or (less likely) several members have developed an original game from start to finish, the majority of members have worked on several complete titles, or a demo or proof of concept has already been developed.  It is also safe to consider creating a new idea if the team is comprised of the same (or with the addition of 1 to 2) members and has completed at least 2 re-creations or ports.

Included in the scope of a project is art styles, gameplay, platform, team size, and original ideas.  It is very important to note that a challenge will still be present with even the smallest scope.  Many unforeseen circumstances can occur, preventing all but the humblest of projects to fall short of the team's goals.

Chapter 3: Tasks

3.1 - Assigning the appropriate sized tasks to the correct people is important to the success of any student game development project.  The size of each task should depend on the meeting times for the group.  If you are following the M-Face, W-Online, F-Face schedule the size of the tasks will fall into place nicely.  Larger tasks are assigned on the Monday meetings and due on the following Friday.  Little tasks or cleanup can be set on Friday for completion on Monday.

3.2 - An important part of handling tasks is revising them when appropriate.  Doing so allows the project to stay on the course to completion and keep the morale of each member up.  The necessity for revision should be discovered either the same night or the day after they are assigned.  On the M-Face, W-Online, F-Face schedule this would allow the Wednesday meeting to focus on re-scoping or revising the task.  Revisions could be splitting the task up into smaller pieces.  This can be achieved by discovering several constituent pieces that a task can be broken up into. The other pieces are candidates for next week's tasks.

[End of Excerpt]

If you have positive or negative  feedback please provide it in the comments.  I will continue to update this pool of knowledge and include more information but I'll need help and suggestions along the way.  Would anyone like to take me under their wing as an apprentice and help me see the end of this?

Thanks for reading.

(This post can also be read here, at my development blog, Running Thru Life As A Game Developer)

Read more about:

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like