Videogame Project Management for Hobbyists and Students

Aug 31, 2010

Joe L. recently wrote:

“I’m confident with my ability in programming and art. One area I’m less confident in is my ability to mentally visualize a process from start to finish. The act of mapping out a project can be very daunting to me. Any advice you can offer on good game project management would be extremely helpful… tips on avoiding quicksand would be great.”

As you’ve rightly pointed out, videogame development skills like programming, design, and art don’t transfer clearly to project management. Nor is it natural or automatic. Project management is a fundamentally different skill to be studied and practiced.

When working on our own, the stakes are lower. The risk of wasting time by being overly ambitious puts no one’s time at stake but our own. Uncertainty about what’s happening next isn’t blocking someone else’s work. Communication of our constantly changing ideas is a non-issue.

As soon as the time, talent, and future prospects of others are involved, the stakes go way up. Even at a student or hobbyist level, not knowing what you’re doing at the helm switches from exploratory wandering (when done alone) to high pressure responsibility (when done with the time of others).

Even though a lot of these points may also relate to solo project planning, my focus here is on team projects, since that’s when this sort of work becomes particularly important. Even though I suspect some of these relate to project management in general, including how it may be relevant to larger commercial production, my experience in those areas is overshadowed by my time on student/hobbyist projects, and so I’ll leave any such extrapolations up to reader discretion.

While leading my first project teams, I hit a number of these discoveries through trial-and-error. When I began helping with more team projects that were run by others, I picked up that these challenges or methods were by no means unique to my own particular background or style. Here are some things that I wish I had known sooner:

Mock-up Screenshot as Design Doc

Photoshopping a “screenshot” (i.e. not really a screenshot) before the game exists goes a long way. A per-pixel representation of what a moment of the finished game might look like – with consideration given to the sort of graphics work and programming that can fit into the time available – concisely communicates dimensions, layout, and user interface elements. The programming focus becomes an exercise in bringing that screenshot to life, which prioritizes gameplay first (as opposed to menus/etc.), and offers clear reminders of what’s missing (health bar serves as a reminder that health and game over need to be hooked up, etc.). It doesn’t need to be final art quality, but it should be presentable.

In the process you’ll give artists a unified sense of scale and dimensions, level designers an idea of the structures involved, and dozens of questions that no one would have thought to ask explicitly are answered simply by putting the picture together.

One Side of One Page Design Document

In terms of design document, if there is one, don’t let writing or maintaining the document take over or cut into development time.

If it can all be on one side of one page, briefly explaining what happens and what’s involved, that will have more utility than a 10-20 page document that no one reads and has too many interconnected assumptions to be easily updated.

Focus on 0-2 Innovations

Unless the project’s purpose is to be an experimental art game: don’t be afraid of applying some control, interface, and design conventions. Experiment with, at most, one or two aspects per project, and for the rest focus on execution rather than the high level questions. It’s OK for the health to be a percentage bar or a row of hearts. It’s OK to collect items to earn extra lives. Leonardo da Vinci didn’t reinvent paint, and he didn’t invent the woman, either; he changed the way that billions of people have seen the world since by simply having done a better job of painting a woman.

Tapping Other Game References

Referencing games that others know on the team can be a powerful shortcut. If a platformer is being worked on, there’s a broad history of existing platformers that could be referenced to clarify what sort of jumping, attacking, or movement is planned. Particularly with the explosion of free-to-play, work-on-any-computer Flash games, there’s almost always a few handy references that can be linked to for general gameplay or interaction demonstration. It’s good to not rely entirely on such references, though, since inevitably some otherwise interested people won’t know the games mentioned, and need to get the gist before they’ll investigate examples.

If there’s no example out there demonstrating what you have in mind, you need to make one first (see next point).

Note that the clarity that comes from this sort of communication can be a double-edged sword: suggesting the game with a five month development window is going to be “like Halo”, or even better “like World of Warcraft”, reveals how little a would-be producer understands about game development, which will keep serious developers from joining the march over the cliff.

Build a Prototype in Advance

If it’s possible to get a playable prototype (the core of the game, ready to be expanded upon) working prior to bringing others onboard, this can help tremendously in ensuring people are on the same page, and interested in a compatible direction.

If nothing exists that can be pointed to and clearly described as, “like that“, then the prototype fills the role of making that communication possible. Even if an outside example already exists (Mega Man? Space Invaders? King’s Quest?), putting together the core gameplay before bringing others onboard is proof that you’re capable of putting a project together. “I know how to program it” doesn’t win much credibility; “player movement and platforms/walls work already, we’re ready to focus on animations, sound, power-ups, enemy movement, and level design” shows that the project is ready for that kind of work.

This is about addressing a potential time black hole before it’s too late. The less has been figured out when reaching out to others, the more disparity there can be in expectations – some coming onboard imagine it as a 3/4 overhead action game, some imagine it as a first person adventure, some imagine it as an RPG – and that mismatch in interests can dovetail the project throughout as members pull it in different directions to be more like what they want to work on. “It could be about sci-fi, wild west, modern day, or abstract visuals” may attract people with 4 different types of interests, 3/4 of whom may either be saddened by the direction it takes, choose to leave when they don’t get their way, or thrash until the last week of production trying to wrestle back to what they joined for.

By contrast, if the core of the gameplay and concept is stood up beforehand, so that everyone can see and try it, people that have interests aligning with the direction it’s moving it are more likely to self-select.

Clear Functional Roles

Clearly define roles to make accountability clear. One person can of course wear multiple hats, provided that they keep up with those respective duties. If roles are ill defined it’s likely to run into a variety of stepping on each other’s toes and diffusion of responsibility, both of which cause time to be lost to thrown away assets and hopeless confusion.

Tracking Isn’t the Same as Leading

Facilitate, motivate, and make sure everyone has as much to do as they’d like to be doing – it isn’t sufficient to track what people do, any more than it’s a football coach’s duty to simply record what happened after each play, or a general’s to jot down after the war how things unfolded. Being aware of what everyone has done in the past week is important, but it’s equally important to be aware of what everyone is doing the following week.

People like clarity. People like the confidence of direction. People like to feel like they’re a part of a coordinated effort.

A word of caution: note that this is not about giving orders, bossing others, or stamping out ideas. Rather, it’s about having a plan. That plan can (and often should) be tentative and up for discussion, but having one helps ensure that if everyone just chugs forward roughly following the shared schedule, the work will all come together in a meaningful and worthwhile way.

Well-Run Meetings Aren’t Useless

People complain about useless meetings. They should. Useless meetings are infuriating. Useful meetings, by comparison, are terrific. Meetings aren’t the problem – poorly run meetings are the problem.

Run correctly, meetings are efficient, get everyone on the same page, clarify objectives for the week, reassure those involved, and result in some discoveries or action items that would have otherwise gone unnoticed.

There are things that come up in person which absolutely won’t come up by e-mail or text chat. Sometimes it’s in the tone someone uses, sometimes people just feel more comfortable bringing things up face-to-face, and sometimes preparing for the meeting is the only hour that week someone spends reflecting on their involvement with the project.

Have a plan for meetings. A half page list of bullet points is fine – the agenda need not serve as a standalone form of notes. This makes it more clear when various topics are coming up, increases the chance of the meeting having value, and generally is part of respecting the time of peer developers. Are there decisions that need to be made? How does the latest version of everyone’s combined efforts look, play, and sound? What is there to look forward to coming together over the next week?

Table one-on-one discussions about particular aspects to be resumed at another time or setting, even if only after the group meeting adjourns. If the sprite artist and the audio person need to discuss their work to make sure the appearances fit the sound effects being made, there’s no reason for the programmer or level designer to be there unless they want to be.

Let the team members have input on project design and direction (both of which are good), but don’t confuse that with counting on the team to run the meetings (which is bad). Several people trying to do the work of one is inefficient and ineffective – keeping order in a meeting is a one person job.

Clear Weekly Goals

With accountability roles well defined, a rough weekly schedule can be drawn up – each week, what is being done for audio? Functionality? Level content?

“What are you doing this week” should never be answered, “More programming.” The goal is not to spend a certain amount of time every week in front of a computer typing, it’s to get more things working, or to fix things that are broken.

Better answers are along the lines of “By Friday we’ll have the level format saving and loading,” or “By Friday we’ll have the second half of our sound effects hooked up with placeholder files.” The weekly plan can be adjusted, if the schedule begins to fall behind, but it’s better to do that as soon as reality is starting to take its toll, and not on the tail end of a project after other roles drove forward under the assumption that certain things (3D animations, boss fights, whatever) would be ready.

Who will be doing what each week? What is one tangible result that each team member can independently take on during that time? Are there things the programmer or designer can do in a different order to unblock another’s animations, audio, or other work showing up in-game sooner?

Schedule Backward from Completion

Creating each week’s goals one week at a time is the equivalent of driving around the highways until we run out of gas, hoping that when the car stops, we’re happy with where we are. That’s insane, but it’s also a surprisingly common way for first-time project leads to manage a team (regardless of how much game development they’ve done on their own).

An excel spreadsheet can be a lifesaver for this – early on, make each column a Friday date, make each row a developer’s role, then do your best to figure out how to fill in those remaining cells for who might be able to realistically get what done each week. Work backward from the end result, or if you’ve already started some aspects of production, work in from both sides and meet in the middle. Work with team members to figure out if they see their involvement as different, expect that they’ll have more or less time to offer, or have suggestions on how to more effectively use the time available.

That spreadsheet is also a handy tool for peeking at weekly during development, to see what’s falling behind and needs to be re-evaluated. If any developer’s objectives start to fall two weeks or more behind, and strategizing with that team member doesn’t seem like it’s going to put things back on track, find a way to design around the loss of that work, having less of what that developer projected, or picking up the slack (either yourself or via another reliable team member).

Time Estimating: Min/Max/Avg

Figuring out how long something will take to do is a notoriously difficult thing to do, especially if it isn’t something that you’ve done before. If it’s not your skill area, be sure to speak with someone that does it when working out the initial schedule. Even then, people can have a hard time, since there’s inevitably some flexibility in how much time gets poured into each thing. One simple technique around this is to ask for how fast it could possibly be done (minimum), how long it might take in the worst case (maximum), and then base estimates on roughly the average, tending toward the maximum end.

There’s a tendency to think in best cases only when scheduling, which runs into disaster when at least half the time conditions are far from best case.

1-2 Nights per Week per Developer

For students and hobbyists there’s coursework or rent-paying work to contend with, and so estimating for 1-2 focused nights of effort per week per developer tends to be fairly realistic. If someone can fit in more than that, great (though I would advise against expecting it to be consistent, as competing deadlines or life issues inevitably crop up); if someone can’t fit in 1-2 focused nights of effort per week, then they aren’t able to put enough time in to make a tangible difference on the project anyhow, and may as well not be with the project.

There are, of course, exceptions. Certain specializations, like music composition, manual writing, or menu design may only be relevant for a couple of weeks in the project, depending upon how someone prefers to work, and what else has to be done before they can start (it’s often hard to put together a cohesive manual PDF/readme until the game is almost done). In those cases it’s of course unnecessary to expect that they hang around doing something weekly.

There’s generally no reason to have people track their hours, or to be Draconian about someone missing one week due to a perfect storm of exams/deadlines/personal. The 1-2 night estimate is simply a rough guideline for modelers, animators, level designers, etc. to put a meaningful dent in the project week by week. Not 5-7 days per week (unrealistic), and not 0-3 hours per week (not useful). The important thing is that the developer’s objectives are getting done, within a week or so of when estimated, and adjusting plans if necessary if it turns out that the original schedule estimates were overly optimistic.

Dividing Work Requires More Work

Involving multiple programmers takes a substantially different type of programming expertise to structure shared code properly (or else a very clear cut separation). Having 5 programmers doesn’t get the code done 5X faster, it adds a substantial overhead of communication, misunderstanding, necessity for internal documentation, and disagreement about abstract details that (mostly) won’t affect the outcome. See: Mythical Man Month.

If art is split, it should be carved into distinct compartments that won’t result in inconsistent visuals serving in parallel roles (ex. one does background art, one does characters, one does power-ups). This also minimizes communication overhead, and the likelihood of running into a choice between rework or bizarre inconsistencies.

If there’s one member solely responsible for the audio, it’s less likely to have dramatic variation in volume and duration. Music composition, of course, separates nicely from sound effect production, and voice recording (if present) may also be split out if necessary.

In general: if it can be done well by one person, don’t have it spread between two.

Focus Design to Fit Time Available

A lot of developers do this backwards, extending their schedule arbitrarily to keep up with expanding design ideas. Those projects, even the ones with millions of dollars, a full staff of experienced professionals, and years of development time tend to Duke Nukem Forever into the abyss of unfinished games.

If people join the team with the expectation that the project will take 5 months of commitment, as the producer you are the guardian to ensure that promise is kept, and that there’s something complete to show at the end of that time period. If others want to stick around after that initial release and work on an expansion pack or sequel together, more power to them, but don’t let others in the group be held hostage by a poorly managed schedule dragging on indefinitely before they can share the fruits of their labor.

(Note that, fairly reliably, the project’s production will tend to slip a little beyond the time window, as a matter of tying up and fixing things leading to more tying up and fixing things. That’s true even if that inevitability is accounted for in planning; see Hofstadter’s Law. Don’t be surprised when it happens, try to not to use it as an excuse, and tough it out.)

Scope Control

The main tip for this is something that I covered in my recent Game Developer article: about 3/4 through the project’s allocated time, make a list of what must be done for the game to be presentably finished – not necessarily complete to the original vision, but first-and-foremost done. Only allow that list to get shorter, ideally by cutting anything on that list if it turns out to not be essential.

Rather than seeing great disparity between what was originally in mind vs what’s in the game, try to think in terms of starting on something “new” with a substantial head start. Imagine you’re given a pile of assets (conveniently, the art/sounds/levels/functionality currently yielded by development to date), with the challenge to weave it together coherently into a finished videogame, which may or may not be aligned with what was originally envisioned.

When features and requests come up mid-development that seem tempting, but would either take the project in a wildly different direction or add significantly to the game’s development needs (say, adding RPG-like character dialog to what was previously a side-scrolling action or overhead strategy game), table the suggestion for a sequel. If the core game initially released turns out great, those team members passionate about those additional ideas have a strong foundation to build upon. The initial release may even be helpful in pulling additional talent onto the project more relevant to new types of challenges, filling in gaps created by others that choose to move on to something different.

Protect the Team Member’s Time

If there are 5 people involved in a game, all of whom came onboard agreeing to an initial vision, and then 1 of them suggests a change that will take the project in an entirely different direction and grossly expand the time required, don’t feel bad about being resistant to that request. Instead, feel good about defending the time and work of the 3-4 other people involved. That’s a different game, to be taken on a different time, and if they wish to assemble a team to build that vision, nothing prevents them from doing so separately. (Of course, if the idea is lobbied effectively to others, with half the team sold on it, that’s another situation entirely. The best course of action in this situation is significantly more blurry.)

Good Ones Want You to ‘Fire’ Bad Ones

If someone is having more of a negative impact on the project than a positive one, or even if they’re simply having no impact, let them go. It’s not necessary to be a jerk about it, it should never be done in front of other people, and it’s good to try to discuss/attempt other options first (would they be better able to help the project in a different role?), but on occasion it’s necessary for the good of the team and the good of the project.

Someone should not wind up in the credits simply because they came around, offered to do something, then were hard to get a hold of or never contributed anything. That’s unfair to the people building the videogame.

Healthy perspectives on this difficult matter:

  1. The person being let go usually isn’t surprised – they know better than anyone how much they have or haven’t been contributing.
  2. As a student or hobbyist, you aren’t disrupting their income, throwing off their rent payments, or turning their life upside down. If they weren’t constructively involved anyway, they have nothing to lose but the idea that this was filling a slot in their life that would be better filled by something that’s a better fit.
  3. If they weren’t using the time to work on this project, then they had/have plenty of opportunity to be using that time on something else instead.
  4. Some people have it so ingrained into their worldview that quitting is a bad thing that they may be hoping you’ll let them go, but lack the courage or conviction to quit on their own. Set them free. It may be a relief.
  5. Do it to defend the efforts and integrity of others on the team, because as the producer or project lead you’re the only person in a position to do it. Nobody wants to organize a group “vote off the island” of a stray individual, because it’s necessarily indicative of group condemnation and conspiring behind someone’s back. Take responsibility. If 3 other team members are annoyed by team member #4 seriously needing to be let go, they’ll be as frustrated by your ineffectualness or lack of awareness as team lead as they are about the team member needing to be let go. It’s rare, it’s important, but as project lead, people are counting on you to know when and how to make that call.

Prepare for Disaster: Make Backups

Nightly, or at the very least weekly, make regular backups of source code, asset files, documentation, anything that the team would be devastated to lose. SVN everything to a remote server, upload a zip to your student web space, use an external hard drive – whatever method works for your budget and comfort. If a hard drive fails, whether it’s yours or anyone else’s on the team, that should not be the end of the project. The producer/lead is accountable for seeing to the completion of the project, and any potential risk that could lead to non-completion is up to that position to mitigate.

Finish It

Less is learned from an unfinished project. The thoughts are never completed, the scope is never fully understood, the project is never presentably put before others in a way that their reactions or feedback can be observed in the context of the work that was done.

I hear “almost done” about a lot of hobby videogame projects. This is as distressing as it is inexcusable. If it’s “almost” done, then do the last 6 hours already and make it done. Nobody wants to drive a car that’s “almost complete”, or sleep under a roof that’s “almost repaired”. Even if the game isn’t a high profile project likely to get a lot of publicity, it’s likely to get orders of magnitude more players if it’s done than if it’s almost done.

If the project needs to end earlier than anticipated, due to a team split, a dramatic schedule disruption (core people moving away usually falls into this category), or other factors, triage it. At least stitch back up the openings, however far it may be from the ideal or original vision, so that it’s able to stand on its own.

We get better at what we practice. Practicing doing unfinished work will only make someone better at doing unfinished work.

Launch Plan

After the game is done, don’t release it immediately. If you can’t wait, it’s not the end of the world to make it available as soon as it’s presentable. However an extra couple of weeks to put together some public facing material – compelling screenshots, short description text, simple web site (ideally on its own domain), and a marketing video highlighting key features and qualities can go a long way in getting more people playing.

I’d suggest not including that launch plan in the original schedule. Keep a marketing timeline (if any) separate from the development schedule, or it’s likely – as the QA/testing time at the end often does – to become subsumed as the project goes past its deadline. “Well, we were counting on not releasing until July anyway…” is a dangerously appealing excuse to slip past an end-of-semester deadline.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.