Starting and Maintaining Your Own Game Project: Part 1

As you probably know, I’ve been rather busy working on my game project, Delirium. (Don’t worry, I’m still working on those UDK videos, too!) We’re currently preparing for an upcoming pitch for possible sponsorship to GDC, but I thought I’d do a post about what it’s like to start up your own game project, and, more importantly, keep it running. This post marks part one of the guide, which details project planning and team recruitment. This will mostly be a guide for anyone who hasn’t started their own project before, but it will also include some helpful tips that I’ve learned through my own experiences.



Project Planning

Lots of people have game ideas, but the majority of them never take the next step towards executing them. If you’re serious about making your game, then the first thing you need to do is figure out how you’re going to make it. Planning is an important part of any project, and it’s no different for video games. Long before you can even begin development, or pre-production for that matter, you need to set specific goals for your project, come up with an estimated time frame, determine a target audience, do risk and cost analysis, and recruit a team. Creating goals for your project should be one of the easier tasks, as you should already have a good idea of what you want the game to be. If you set up clear goals early on, it will make it much easier to get across to your team, once you’ve recruited them. I’d recommend creating a one-pager, which is literally a one page document that lists out what you want in the game in bullet points. When doing this, don’t just list a bunch of cool design aspects you want in your game; list out what the whole game should look and feel like when it’s completed. You should also define your target audience here, as it will help to shape what your game will be. If you do make a one-pager, you can even send this out to your team members to help them understand what needs to be done.

Next, you need to establish a time frame for the game’s development. I started by listing out the phases of development for my project: pre-production, prototyping, development with alpha and beta builds, polishing, playtesting, marketing, and release. Then, I estimated how much time it would take to complete each of those phases and created a Gantt chart. While you don’t have to create a Gantt chart, I did find that it was helpful to see an actual schedule and how things like holidays might affect the time frame. A time frame is a helpful tool for scheduling milestones, sprints, builds, etc., as well as for the recruiting process. If your time frame is looking pretty lengthy, then it may be a good indicator that you need to cut down your scope. For my project, my initial time frame was one to two semesters, about eight or nine months, granted that my project’s scope isn’t very expansive. Many of you are probably looking at close to a year for your time frame, and that’s typical of most game projects. 

Now that you’ve got a little bit more of your project planned, it’s probably a good time to try and find a producer. I originally took this role, which stacked on top of my project manager and lead designer duties, so I found that I didn’t do a very good job of this. Once I did bring a producer onto the team, it was extremely helpful, and I’d recommend finding a good one and having them help you out early on. A good producer will help you with all of your project planning needs, including risk analysis and cost analysis if you’re going to sell the game. If you can’t find or decide you don’t need a producer, you can certainly do this yourself, but if you’re a designer like me, you’ll find yourself more inclined to do design work and might neglect some important project planning. Either way, you should be using this time to prepare for development and set up goals for your project. Before you begin recruiting your team, you want to be sure you have everything set up and ready to go. If you plan on using any project management tools, such as Assembla, or a Wiki, take the time to get them working. If you can, go ahead and start writing on a design document, as it can help both during and after recruitment. If you have any ideas about art or sound direction, write up your ideas into a document so you can show prospective artists and/or audio designers what you’re looking for. If there’s anything you can do that will help your team be better prepared when it’s time for development, you should do it before recruitment. Prospective team members are going to have lots of questions about your game and what you want to do with it, and if you did your planning properly, you should be able to answer all of their questions with ease. 


Finding Team Members

Let’s face the facts: you probably can’t make this game all on your own. You’re going to need a team, and you can’t expect them to all just magically appear and start working on your game. Instead, you need to recruit a team of able-bodied, talented, and hard working individuals. To start with, think of team size. For my project, I wanted a team of roughly ten people, but you may need more than that depending on your game’s scope. When estimating team size, consider the scope, the project length, and the general amount of work that will need to be done to reach your goals. Don’t forget to include yourself in that number, since you are part of the team. Once you have a good idea of how many people overall you want on the team, break it down into a hierarchical structure to help you better assess how many of each discipline you need. Below is an image of what my initial structure looked like:

Using this hierarchy, I was able to divide up my team size among each discipline. I was taking the role of lead designer and producer, but I determined that I would need one to two other game designers, one art lead, one tech lead, one audio designer, two artists, and two programmers. At the time, this sounded completely feasible, but these numbers did shift. My current team size is roughly fifteen, with a producer, two designers, an art lead, a tech lead, an audio designer, five artists, three programmers, and myself as the lead designer and project manager. Remember that the team size you come up with is just an estimate, and if you fall short during development, you can always recruit more people where and when you need them.

Now that you have a pretty good estimate of how many team members you need for your team, it’s time to start recruiting. There are a number of ways you can go about this, so it’s really up to you. For my project, I created a recruitment blog, which contained information about the game, what the team would be like, a time span, and more. I posted the link to the blog on various social media sites and on my school’s forums to help spread the word. Having a web site to direct people to made it much easier in the recruiting process, and it  answered many of the questions they might have had otherwise. The other thing I did with this web site was job postings and the ability to apply directly from the site. I looked at a bunch of actual job postings from various studios, and based my own off of those. It made the overall project look more professional, and helped to weed out the slackers. I had job postings for game designers, an art lead, a tech lead, artists, programmers, and an audio designer. I got a lot of positive feedback from those who looked at the job postings, and many told me that it helped them to understand exactly what would be expected of them if they joined the team. I also included a form on the site that allowed those who were interested to apply for the desired position, which meant that the main questions I had for them were answered when they applied. After I received their application, I sent out a follow-up email, and if I thought they would be a good fit for the team, I set up an interview with them. The interviews were rather casual, but it helped me to get to know everyone and gave them the opportunity to ask additional questions and show off their work. Overall, this process seemed to be well received, and I’d definitely recommend doing something similar for your own project if you can.

As I mentioned before, there are a lot of different ways you can go about recruiting a team for your project. No matter what methods you use, there are a few things to keep in mind:

  1. Never lie or offer incentives you can’t deliver on.
  2. If you do have incentives you can offer, be sure to mention them (portfolio piece, internship, etc.).
  3. Be sure to state exactly what you expect of prospective team members.
  4. Don’t expect everyone to come to you; it’s your job to find people.
  5. Look for people who are willing to stick with the project, and won’t just drop it if times get tough.
  6. For leads, look for someone who has good leadership and communication skills.
  7. Don’t recruit friends unless they are serious about working.
  8. Look for people who are passionate and driven, even if they are lacking some of the skills.
  9. Don’t just look in one place for team members. Use a variety of methods to spread the word about your project.
  10. Don’t be discouraged if you don’t get any applicants at first; keep working at it!

For my project, I initially only got about three applicants, all of whom were artists. It did feel a little discouraging, but I continued to spread the word, and I did receive more applications in the following week or two. Once more people started hearing about the game and became interested, more and more applications came in, which eventually forced me to reject some people, simply because we didn’t need any more artists or designers. There were two areas we had difficulty in recruiting, which were for programmers and an audio designer. Luckily, we were only starting with pre-production, so we didn’t absolutely need them. I did manage to find a programmer who was interested fairly early into the project, and he actually took the role of tech lead. With his help, we were able to find the other programmers we needed, so don’t forget that your team members know people who might be interested, as well.



That’s it for part one, but keep an eye out for part two, coming soon! Feel free to ask me any questions, as I’m always glad to help out! I hope that this post was helpful and thanks for reading.

    • Jeff
    • December 8th, 2011

    I was interested to see that you’re using XNA, I looked a year or so a go but I didn’t pursue it as I felt it was neither a game engine or a game development system. I have re-considered this recently as I am learning Visual C# and I can now see how it would be interesting to learn.

    Have you made any headways with CryEngine ? – I had bad experiences with it (instability, silly login requirement etc) It does remain an interesting option but I think I’ll stick with UDK and Unity for the mean time.
    Check this out (its free for students)

    Lookng forward to your UDK videos.


  1. February 17th, 2012

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: