Code Design in Teams

Started by
3 comments, last by Chad Smith 18 years, 4 months ago
Alright, I am working on my first big game. I haven't recruited a team yet, but soon I will. I haven't done work on a team before, but I have made some games. Since I don't know how code design works when your working with teams, I wanted to ask some questions here. Ok, lets say that I am coding the game, and my other coder (lets say he is the AI Programmer) is working on the AI for the game. Now, I was wondering how does the team keep up with each others code? Do you like put everything in like...a seperate .h file? Like...would he make a AI.h file, and sends it to me, and I just make the call into my main, and include AI.h? Is that how it works? Thanks to all who shed some light on this. Chad.
Advertisement
First, using CVS (or a similar alternative - I would personally advise using Subversion) will make your life easier, because you can keep a stable and shared version of the source code somewhere. Then, the development process is a sequence of iterations as follows:


  1. Lead programmer decides on what should be implemented next. He then divides the task into independent and parallel tasks that should be worked on by the different coders.

  2. Each programmer starts working on the files that pertain to his part of the job. Since the tasks are independent, each file is only edited by one programmer.

  3. The programmers write their code, using the code that already exists. They then test the code they just wrote (for instance, using unit testing or various other forms of testing).

  4. Once the code passes all tests (and, of course, compiles), the files are submitted through source control.



Once a programmer checks in his code, he gets a new task (either to write additional code, or to correct old code). Always make sure people have separate tasks, and each file is being worked on by only one programmer (use locks provided by your source control system to enforce this).
You'll need to use some method of source control. lookup and read about Subversion.
Try to keep the modules separate, so that you can always test your code without worrying about what the other one produces. Say the other programmer is doing AI. Separate AI from the game code so that you can play the game without AI. Determine how the AI will communicate with the game code: What AI functions the game code will need to call to get AI information, and what game functions the AI code will need to call to get game information. You could make empty "stub" functions for the AI features that have yet to be implemented, and use them from game code as if the AI was actually there. Then the AI would simply do nothing until the other programmer provided enough code to get the AI functional.
Hey,
Thanks for that y'all! I am looking into CVS right now, and I will see how it goes.


Thanks again,
Chad.

This topic is closed to new replies.

Advertisement