Game Development Community

dev|Pro Game Development Curriculum

Focusing development by way of bootstrapping

by Joe Maruschak · 11/07/2006 (9:11 am) · 5 comments

www.joemaruschak.com/dotplan/drift.jpg
boot-strap-ping To promote and develop by use of one's own initiative and work without reliance on outside help.

As part of my planned series on game prototyping, I am feeling that I need to lay out my opinion and theory of game development and project management, because I feel that one cannot divorce the two topics.

Game Development cannot be separated from decision management. Creating a game is all about making many small good decisions during the creating of the game. Good games are the result of not one brillaint idea, but thousands of small good ideas and thousands of small good decisions. The best way to practice making good decisions is to practice making them. The best metric for seeing whether or not you are making good decisions is to make decisions in an environment that rewards good decisions and makes very clear bad decisions that are made.

Bootstrapping is such an environment.

If you start with very little, it forces you to immediately make a decision that will get you moving forward. If you make good decisions, your project will move forward. If you make bad ones, you will not make progress. If you can make a game while bootstrapping, you are getting the best practice that one can get in making good decisions. It may be a fairly brutal and darwinian process, but it really rewards those who have what it takes to manage projects and complete games.

Bootstrapping forces you to ask yourself, what is important right now. You can cut through the crap and cut to the chase. What is really important? What about cutscenes? sound? music? when you don't have the resources to pay for all of these things right away, you are left to contemplate the core of the game you are trying to create. What is at the core of it may not be immediately apparent. Bootstrapping forces you to thnk about it and decide where you are going to focus your precious resources. What is most important to focus on now.

If you make the right decisions, you will be rewarded with success. Your game will slowly come together, becoming more fun and more engaging each day, and it will gather it's own momentum. If you make the wrong decisions, it will seem like an uphill climb, with each task a chore, the game not progressing, and motivation waning.

When you have little or nothing to work with, or when you are working alone, you have little you can waste. If you spend all of your time on things that really matter, you will have optimized your development process so that when you tackle bigger, harder projects, you have the skills to make the right decisions more often then not.

Often I read threads about developers who 'don't have enoiugh funding' or 'the team I have cannot complete the design we have' and I almost tear my hair out in frustration. If the first decision one makes is to undertake a project that they have no chance of completing and they are fully aware that they are resource constrained coming off the starting blocks, how are they ever going to learn how to make good decisions?

My own theories of how to make games the 'right' way deal specifically with forcing decision points at the right times, and assessing and addressing the risk level associated with each implementation item. Often times, it is experience that allows one to understand what are 'big' features and what are small, and what constitutes a risk to the project. Knowing what is a high risk item and what is low risk will help you to properly assess what should go into your priority queue.

What constitutes a risk is different for every team. Every collection of 'resources'(people) comes with a unique set of skills and experience. Knowing what you can and cannot acheive is key to understanding what might constitute a risk to a project.

Knowing your team is step one, knowing the project is step two. I try to break whatever I am working on into small understandable chunks, or work items, so that I can look at them objectively, and break them down into implementation items. Implementation items allow me to look at each one and decide, this item is very important, and these other items are not so important. As an example, the external art design of the GUI for a racng game needs to be done, but without a driving model, there is no game at all. This is an example that is very obvious, but I have seen many examples of projects that have gone very far down a path where the core gameplay was not yet proven.

Bootstrapping forces the issues to the surface. If you have little resource, you need to be selective about what to work on. In order to be selective, you need to have items to select and you need to have some process to select what you think is important. Good decisions happen when you can pick the right things to work on and don't waste time.

Many of the agile development methodologies are based on the ideas of iterative prototyping and rapid development, and give one the tools and process to help decide what one works on and what is put off until later.. I highly recommend looking over some of them and lifting whatever you can from any of them and incorporating them into your workflow. I would not suggest blindly following any of the methodologies, as they are just tools. Pick up anything that seems useful, discard anything that is not helping you to focus on the task at hand, which is deciding what you need to work on to get your project done.

I am not going to go into many of the agile methodoloies in depth as I go over my ideas about prototyping. I am going to keep it very general and very high level. The main idea behind everthing that I feel is important when prototyping and creating a game is to know what is important and what needs to be worked on next. To me, it is all about setting priorities, and keeping them in order.

If you are making good decisions and keeping your priorities straight, you will make progress. If you don't, you won't. It is important during the process that you are aware that every decision you make about what to work on (and what not to work on) and what is important (and what is not) contributes to your success or failure.

When in bootstrap mode, any failure or bad decision hurts, and it is immediately apparent. Time is of the essence, so learn not to waste any of it. If you start with very little, you have very little to lose, so move forward and learn to make the decisions that will take you to the top, and not leave you stuck

an excellent blog on Agile Development on Ganes From Within, which was referenced from Lost Garden can be read here. I would suggest reading it and applying whatever concepts seem appropriate to your development practices.

#1
11/07/2006 (9:52 am)
Well written.

Rapid iterative design approaches are perfect for game development, but the largest hurdle is getting the entire team to understand and follow it.

Most of the programmers / experienced developers have already used it in one form or another, but the others... well in my experience, everyone that hasn't actually been on a team using a specific development methodology tend to migrate to a waterfall approach with one and only one iteration in the implementation plan.

Normally my iterations are about 3 weeks long, with a week that's primarily for design, a week that's primarily for implementation and a week that's used for integration and testing... but with part-time game developers, that's difficult to achieve.

My modified approach for part-time deveopers is more like this... throw as many ideas out there as possible, step back, see what can be accomplished in a weekend, then do it... wash, rinse, repeat. Some tasks will take longer than a weekend... those should be considered higher risk and should be put off until later if at all possible.

The goal is to have a working game at the end of every week.... at least something added and if possible nothing that was finished prior to the week should be broken. Some tasks might take more than one person collaborating, but for the most part, the tasks should all be kept as individual tasks. The more people involved in a given task, the higher the risk.

After doing this for a few weeks / months, then you can risk doing something that will take longer than a week / weekend.

This methodology has worked for me several times in programming projects outside of game development... The symptoms of it not working for game development, although not necessarily the true cause, has primarily been my inability to explain the methodology and the benefits for following it... maybe this article and the one's you pointed out will help as I introduce this concept to the members working on my current project...

Thanks again for the well-written article.
#2
11/07/2006 (3:49 pm)
Thanks for posting this Joe.
#3
11/07/2006 (7:18 pm)
Thanks for the words of wisdom.
#4
11/07/2006 (10:04 pm)
I would venture as far to say that Joe's advice applies to any software project, not just games. Good read.

-Jason
#5
11/08/2006 (2:28 am)
Thanks Joe.