How to Divide Responsibilities Between a Two-Man Group?

Question

A partner and I are in the midst of creating a (not so) simple game via C++ and SFML (2D). We have both created some simple games (not together) and would like to start work on a more serious, larger project that challenges our abilities to program, interact with large code as well as working together without getting in each other's way.

The problem is the getting in each other's way- well, not yet at least.

We had our first group session today (us two working on the project, one to-be tester and a friend of ours) and wrote down some ideas. It's going to be a birds-eye perspective zelda-like (from SNES) game with a streamlined map and quasi-linear gameplay like Gothic (open world, but you'll likely get yourself killed if you wander around too much).

Needless to say, I'm not sure if we're aiming too high for the moment, but our biggest concern is the division of responsibilities. Our first impulse was to work on aspects of the game that had nothing in relation to the other (I would work on the menu, he would work on the map, for example).

Our next impulse was to work on closely-related things in a list-manner. (First the menu, then a map, then the character, then the monster, etc) so we can, piece-by-piece, see our code coming to life in an orderly fashion.

We haven't picked a VCS yet, but I'm thinking it's going to be Mercurial for the simple reason that I have heard good things of it (neither of us have yet to use a VCS).

Question: What would be the proper way to divy up the responsibilities between the two of us? How should we start, how should we continue and how do we do it together with maximum efficiency? Any other tips would be greatly appreciated!

Answer 1

I have found that it's best to have something to start with. Then it's easier to list the things that need to be added or fixed, and divvy those out. So you might consider pair programming at first, just to get some basic stuff running and some organized code laid out.

Just schedule a few hours one day, both of you sit down, one of you be the coder (or switch off), and start from scratch. Create the project, import the libraries, write some basic code, get something on screen. Maybe develop another couple features, to have something working. And then check it into the repository. From that point forward, split so that both of you are working on different things. Make a list, based on what you now have working, of what should be the logical next things to add. There are bound to be features that can be added simultaneously and don't conflict or rely on each other. Then each of you start owning a feature, coding it, and pushing it into the repository once it's stable (and between stable, push it to a branch repository for backup). Rinse, repeat.

Also when working with version control systems, it's very important to commit and push often. Similarly, you then also need to pull and update (and test!) often. When you pull & update a lot of code and something breaks, you're going to be relieved that you can just revert to where you were and update one change at a time until you find the breaking change.

Another thing, possibly even more important, is to keep a working copy of your game at all times. It's like a foundation, something to show friends when they ask how the game is coming and something to inspire you when you're so deep in code that you don't think you'll ever finish and have the game running again.

But I think I'm getting off topic. Basically, once you get started together, you'll find it's not as hard as you think! You just need to get off the ground.

Answer 2

Personally, I think you NEED a server for managing files, assets, versions, etc. Yet for a 2-man project, SVN can be tricky to learn when you never used it (for making merges for exemple), but still it's a good tool and completely free.

For dividing tasks, it highly depends on the time you two will need to complete tasks. In video games, tasks are really often binded to other tasks (Need to map editor to place units, need the inventory to choose object to use...). Game industries usually use a project management tool called SCRUM. It is tricky to understand and need time to use correctly so I don't think you should use this method, but there actually is some concepts that could be quite interesting for you.

For exemple, Scrum method says to divide a project in small iterations. Each iteration should give you a functionnal game (yet not complete). Using this will allow you to get a demo of your game every 3 - 4 weeks to see where you guys are and make adjustment of project scope. Next interesting feature is, in each iterations, write a set of game features that should be implemented. Theses features are not from the programmer view, but from the player's. For exemple if you want to give the ability to jump, do not write "Add physic module to Player class to push upward acceleration" anyway the way you think it should be implemented will change. The task should be "Make the hero jump". Using this method, you will choose what you are working on when it's the time. When a feature is finished, choose another one.

Another advantage of using such methods is that none of you will be the "Hero of map editor" or "Hero of physic module". If you guys are approximatively the same level, you should work on every modules of the game. Code quality is a thing you want to make sure to respect and a double check is always good. So you should work on all module to assure the quality of work, but to make your brain work on other types of problems to, it's good for the motivation! Finally I would suggest you to make your friend check every features you finish before you make the final commit in the game. Like this, you guys will learn about each others, you will help each other out and you will know about how the other modules of the game are coded. The latter will help you creating new modules.

I suggest you to check this http://www.agile42.com/cms/pages/agilo/ it's a free Scrum tool that you can use with SVN. I used it in a project with friends and it work quite well for small projects.

Good luck ! :)