6

We're a bunch(4-5) of 3nd year college students about to begin our 3 months summer vacation and we would like to get going on a project. We want to make a game with XNA, it doesn't have to be big or something but we have 3 months so I'm not sure how big it can get.

I plan on being the "team leader" because I have the most experience with C#/XNA and I'd like to learn how to be a team leader, this could be good training.

So how should I proceed with this ? Whats the best way of leading a small team when you've never done it before ?

Tristan Dubé
  • 163
  • 4
  • Why would you need a "team leader", what roles and responsibilities go with this title? – jzd May 09 '11 at 15:58
  • You could start by trying determine the strengths of each member of the team. Once you do that assigning tasks should be simple enough. The first thing yyou should figure out what is possible in 3 months and what is not possible. – Ramhound May 09 '11 at 16:00
  • By team leader I mean more like someone who pushes and organizes people during the project. My friends, by themselves, won't start projects by themselves so my task is to get everyone together and coordinate our project. Like setting goals, mentoring people if they need, determine what we should orient our efforts toward, etc. I'm not trying to be some kind of "boss" here, I won't stop anyone from doing what they want during the summer but from what I understand someone needs to be there to make sure our project happens and doesn't just stay on paper. – Tristan Dubé May 09 '11 at 18:06
  • Half of you are artists, right? Because 4-5 programmers working on a game of the sort you could make in 3 months is probably going to make it take 6 months. At the very least, you're likely to run into problems with finding enough work for some of the programmers. Check out http://en.wikipedia.org/wiki/Brooks%27s_law for some of the reasoning. It might be better to do 2 projects with 2 people working on them, and using each other for moral support and motivation. – thedaian May 10 '11 at 01:06
  • Mm, thanks for reminding me of that principle @thedaian. I agree, adding more people to the boat would only add complexity if the project isn't wide enough for people to fit it. I'll try to think of something. And no, no artists or anything else than programmers. Too bad really, we'll think of something. – Tristan Dubé May 10 '11 at 03:05

3 Answers3

4

first, kudos on stepping up to a leadership role

second, leadership is an independent set of skills and aptitudes from programming; the fact that you have the most programming experience in the target platform is irrelevant

third, for a team of relatively inexperienced peers on a short-term project, your best bet would be to facilitate agreement among the team members on how you want to work together, what you want to build, and how you'll know when you're done right at the start, then assist and nudge as needed to keep things on track as you go.

Bear in mind that nothing will go as expected; expect that. Even the simplest things can go haywire in a hurry when more than one person is involved. The key to leading is to help people get what they want, so that you get what you want. If everyone wants the same thing, e.g. successful project and fun process, that's great. Don't expect it. People's level of interest and commitment will wax and wane over the course of a project, things will come up, new girlfriends will materialize right before deadlines, pets will get ill and require emergency attention, and so on. That's life. If the project is unpaid, there will be even more temptation to do other things, especially in the not-so-fun parts of the project.

Good luck!

Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • 1
    Thanks for the tips. I'm hoping I can get them to put enough energy into this project so it materializes into something. I don't see this project as something "oh so very important" as such I don't expect my friends to devote all their time to it. I just figured we could meet a few times weekly to update everyone else on our advancements. I find the idea fun because 4 people can accomplish way more than I could alone. That means a (let's assume) finished game could be made, would look great in a resume. – Tristan Dubé May 09 '11 at 18:15
2

We want to make a game with XNA, it doesn't have to be big or something but we have 3 months so I'm not sure how big it can get.

If you want to lead a team of developers, you're going to have to start by making basic decisions like how big it's going to be, what the game is going to be about. Starting off with "we have 3 months" is indecisive. You'll need to start cutting the project into bits that are manageable for your team-mates to look into, and how you'll measure progress.

I can't believe this hasn't come up in a group college assignment already.

temptar
  • 2,756
  • 2
  • 23
  • 21
  • I wish they would teach us something else than code at my school, thats why I'm going for with this summer project. This gives us a chance to learn something by ourselves so we are ready when we hit the market. My entire programming student career I've had to educate myself with Google, so very lucky to have programmers.stackexchange at hand. – Tristan Dubé May 09 '11 at 18:21
  • 1
    "I can't believe..." Actually, it seems pretty common based on my experience. I only had four team-based projects (while getting a BA in CS) and they were all 300/400 level courses (i.e. "senior" level). Furthermore, _none_ of them were anything like what I've found in the real world. – Michael Todd May 09 '11 at 20:48
2

Universities don't seem interested in going out of their way to teach any project management in their computer science curriculum. It seems like they expect it to evolve out of the fact that they give you a final project at the end of the semester, which is often poorly executed since you try to balance it with other class projects and finals. Disclaimer: I'm only a CS minor taking a few courses above & beyond, but my roommate is a CS major and confirms this as well as our classmates.

The points below are from what I've gleaned from observing effective leaders of teams I've worked with at game jams as well as longer term projects with a group of peers:

To succeed, you should try to follow a pretty tight routine that everyone is on board with and enthusiastic about.

Plan ahead, but don't commit

Have a brief period of prototyping as necessary if your gameplay mechanic ideas do not fit into a well established genre. Focus on having some playable demos up within a week and weed out what isn't fun.

Having prototyped, design a rough end vision (rough, because this will change), and set goals for a first milestone. Do some work thinking about what core systems will be required in your game and focus on getting them up and running. But don't overdesign these, use the simplest type of sprite or 3d model manager you can get away with. Set a due date for a week or so.

Stay motivated and focused

Have a regular cycle for milestones, and meet regularly. If you're roommates or live nearby, meet at the beginning of every day you know you'll be working. Or, if your schedules aren't aligned, schedule two times a week when you can have a scrum-style meeting.

Everyone should report on what they've done, what they will be doing, and what problems are preventing them from completing their work (this is not to say you should absolutely follow the scrum methodology, but this specific practice is very helpful).

The smallest tasks take the most time to complete

Remember to leave roughly 1/3 to 1/4 of your development time for polish. A game with less complexity but has really tight controls and presentation for its core mechanics is more impressive than a masterpiece of design that feels clunky.

Team members are like RTS AIs with their difficulty levels set all over the place

As a leader, you should be encouraging the team to move forward on goals. Some team members will intuitively know where to focus their efforts after they're done with each task. Others will need more guidance on where to go next. Furthermore, some may spend too much time perfecting a feature, in which case you need to tell them to move on. Conversely, somebody might write something in a way that is not farsighted enough to accomodate the full scope of the project and you'll need to help them toward a better solution.

Note although I say "you" a lot in the above paragraph, remember to delegate these leadership and mentorship tasks to others who are able to fulfill the role. It will free up your time to accomplish your tasks and at the same time help team cohesion.

Community
  • 1
bearcdp
  • 131
  • 4