Jump to content
  • Advertisement
Sign in to follow this  
Sean_Seanston

Game Programming in a Team

This topic is 3343 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This probably could go in Software Engineering but since it deals with the specifics as relating to games and how to program in a way that makes code from multiple people easy to integrate I figured it might work best here. This is a problem that I've encountered before in college when assignments come up with mandatory teams. The very fact you have double or triple the amount of people involved seems to make things many more times harder in the end and this is an area where I have very little experience and so I'd like to learn more from people who know about this kind of thing. I'm having real difficulty seeing where to even begin with somehow dividing programming work between 2 or more people that must in the end mesh together seamlessly without having to do extensive rewriting. Let's say the design is for a simple 2D scrolling platformer. There are maybe several discernible areas to work on such as: enemies, player control/movement, collision detection, level design etc. but these are all essentially interconnected to a great degree and seem almost impossible to produce in isolation as they're reliant on other things that makes testing impossible unless you have the entire program. Even if testing that something actually behaves as expected wasn't necessary, how would these "components" made by different people be made to effortlessly form a finished whole? Might you perhaps work in semi-abstract ways by using functions such as DetectCollisions() in your code if collision detection was being worked on by someone else? Though collisions would have to take into account level geometry and every single thing that is to collide, making those very hard to separate and even if generic DoCollisionCheck() functions where put in as placeholders to these entities, the collision detection programmer couldn't test his work in any real way. So yes... I'm pretty clueless about this at the moment. Any ideas on how to separate coding duties and fit everything together would be great. Examples of past projects would be especially useful.

Share this post


Link to post
Share on other sites
Advertisement
I've only worked on a couple of teams but the one basic requirement I take from that experience is that there is a well-defined project specification. That specification should not only include the technical requirements for developing project outputs but a clear description of the method for changing the specification. Team members should understand that the specification is not a suggestion. It's like gravity - it's not just a good idea; it's the law. You either work to the spec or get the spec changed. The more team members there are, the more rigid the requirements must be enforced.

You will also need a project manager, who may or may not be involved in the actual programming. A project is not a democracy. The project manager will have to take into consideration all the inputs of the participants but will be the final authority for decisions that affect the specification, the product (in all its intermediate forms) and the schedule.

The spec should start out relatively general and include things like: the target platform, the graphics engine, the collision engine, etc. Those choices may not be final but, hopefully, the team member responsible for each area will be familiar with (if not an expert in) that general area and be able to make recommendations. As the project progresses, the more general requirements become fixed as more detailed requirements get fleshed out. The more detailed requirements get fixed as even more detailed requirements are worked out. Etc.

Each team member should propose additions to the spec, providing general then more specific requirements for input needed from other areas and respond to needed outputs from his area of responsility. Those inputs and outputs become part of the spec. That allows for a degree of independence for each team member. He/she can refer to the spec to find out what inputs can be expected and what outputs are required.

EDIT: alvaro implies something very important - early testing to ensure the project is heading down the right path.

Share this post


Link to post
Share on other sites
Disclaimer: I've written software for a long time, but never games.

In my experience, you rarely divide responsibilities up very cleanly among group members, although certain people will end up being more familiar with certain parts of the code than others. It is important to keep your design modular and to clearly describe the interfaces between modules, although realistically many of these interfaces will change over time.

It helps to build a prototype very early on, even if many features are not implemented. Collision detection can be implemented initially with every object seen as a rectangle, or as a circle, just to get something working quickly. Then one team member can improve that module to use other collision shapes, or pixel-by-pixel collision.

The game can be tested on some really simple level to begin with, so level design shouldn't stop the rest of the game from being put together. There should be some basic understanding of the format in which levels will be described early on, so people can start working in implementing levels.

There are many interactions between different parts of the project and you cannot plan everything in advance. Make sure that there is a repository of the latest greatest version of the code, so everyone is on the same page, and the level designer can go talk to the programmer doing character movement as soon as he commits a code change that makes jumps too short for most levels.

I bet experience has a lot to do with getting a team to work, which is why it usually doesn't go very well with college students.

EDIT: What Buckeye said is a lot more orthodox, but I don't think it will work well for hobby programming or for completing college assignments, which I think is what you were after. Perhaps you should find which model of development works best for your team.

Share this post


Link to post
Share on other sites
Quote:
Original post by alvaroEDIT: What Buckeye said is a lot more orthodox, but I don't think it will work well for hobby programming or for completing college assignments, which I think is what you were after.


Yeah, actual team organization probably won't be much of an issue, especially with the size of project we're working on. I'm more concerned with the actual nuts and bolts of how the code can be created in relative isolation and fitted together in some way. A well-defined project specification is probably very important to doing that smoothly though.

By keeping the design modular, what exactly would you have in mind?
I suppose very generic function calls I mentioned might fit somewhat into that idea in the sense of the functions being black boxes of a sort where the functionality can be taken from someone else and slotted in later. It just appears to my rather naive perspective that most of the game, or maybe rather most of the engine framework in any case, might be best done by a single person for at least the kind of basic 2D game project they I'd have in mind.
I'm also kind of worried about the result ending up as spaghetti code even if it does work due to the different coding styles.

Share this post


Link to post
Share on other sites
I don't think you can get good results without lots of communication between the team members. You don't have to be in the same room: I've seen a project go quite well with 4 developers in three countries communicating via email, IM and a Wiki.

Programming in a group is primarily a problem in managing a group of people, and secondarily a problem in programming.

Make sure you all write clear code. Don't worry about how clever it is or how fast it runs (at least initially): Just make it clear. You will have to read each other's code at some point or another, so clear code is almost the only thing that matters.

Share this post


Link to post
Share on other sites
Keep in mind that a specification document is a form of communication. Just having a talk or a brainstorm session is also a form of communication (but write down the decisions, or you'll forget and different people will remember different things). Sometimes you just need to ask a teammate, how was your code supposed to work?

Modular designs are good, yes. Sure, some systems have to use others, so there will be dependencies, but try to keep their number low. It helps to decide how things will interact beforehand, so modules that are built by different people will work together without too much trouble. If you're unfamiliar with a certain subject, it can be hard to come up with a workable design, so it can be useful to prototype a few designs.

Some modules can be built in isolation, but others depend on other modules, so those can only be created later. Plan accordingly. As for integrating things, you should do that all the time. Source control software makes this a lot easier: it's easy to stay up to date and to commit your changes. Should someone elses work break your code, then only your build is broken. If you commit regularly, you likely won't need to change much to get things working again. Of course, keep the central repository working at all time, or you'll be blocking everybody else.

As for coding styles, you can enforce a certain style for your project. It'll help to keep the code uniform (keep in mind that a code standard can contain more than just style rules - it can be helpful to set rules for other things as well, such as memory management, folder structures or asset name conventions).


Usually, this leads to programs that gradually grow in features. First, you only have some sprites on-screen. Then, a moving player, and a level that's loaded from a file. Later, collision-detection is added, and the level file format is extended to contain collision data. Then enemies and other game objects are added and level-designers can add features as they become available. Menus are added, placeholder art is replaced by final art, sound effects are added, gameplay is getting tweaked, bugs are being ironed out...


I hope that helps you somewhat. :)

Share this post


Link to post
Share on other sites
Once the design has been agreed upon and done well however, what's a logical way of splitting up a game project to be worked on separately?

I just can't quite picture it. It's obvious that graphics are one area and I suppose that would pretty much fall under the engine category somewhat and one person should probably do that in such a project as a simple 2D game, but then what could someone else work on with the graphics system not complete?

What areas seem to be ones that should be grouped together for minimum hassle? AI could probably be sectioned out on its own quite easily but then that's after the real engine has already been created.
The Player's specifics might be another but these both seem to rely on all the basics of the technology being already implemented. Then 1 could get the player movement/controls/logic done and another the AI and then maybe come together to mesh them together but for a game similar to... R-Type let's say but obviously lower in scale, it does seem to me that getting the basic engine system set up would be most of the work which leaves little else unless of course in a 2-man team the other coder would take on most or all of the responsibility at that point with obviously some cooperation to iron things out.
That actually doesn't sound terribly bad I suppose, though you'd have to make sure that there's a relatively equal amount of work for both.

Am I heading in the right direction? I can't much see 2 people working independently on different parts of a DirectX graphics system and doing it simultaneously would seem to bog the whole process down unnecessarily for the sake of cooperation.
Problems I see are that the 2nd coder wouldn't be able to start until the first was finished and the 1st would probably wind up doing more work since after all, it only makes sense to help with the 2nd part.
This kind of thing just seems so very unnecessary for the scale of projects done over 2-3 months in college to me. I know it's meant to prepare you for the real world but when it's a contrived situation that doesn't accurate reflect the workings of reality I don't see a great point I must admit but now I'm going off the point.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sean_Seanston
Once the design has been agreed upon and done well however, what's a logical way of splitting up a game project to be worked on separately?

Depends on the design, really.

Quote:
I just can't quite picture it. It's obvious that graphics are one area and I suppose that would pretty much fall under the engine category somewhat and one person should probably do that in such a project as a simple 2D game, but then what could someone else work on with the graphics system not complete?

Another person could build game-code, or work on a level loader or some other tool (if your game is data-driven then tools are an important part). Sure, he won't be able to test the visual aspects of it yet, but that doesn't mean he can't build the non-visual parts. It's a matter of dependencies. Some things heavily depend on others - those would be done in chronological order. Other things don't depend on each other at all - do them in parallel. Yet other things depend on a little bit of functionality from something else - build that little bit first and then both things can be done in parallel from that point on.

Having that said, graphics is usually one of the first things I'd get up and running. It helps a lot to visualize things. Nowadays it's pretty easy to get it up and running though, with so many engines and frameworks around, so in most cases it's pretty much a given anyway.

And yeah, some things are too small to split up.


So, for your platformer, how would you split that up into modules, and which ones depend on others, and how/why? Which modules would take a lot of work and which would not? Are there any modules that are easily split up? (I just happen to be working on a platformer bytheway - so this could be a useful brainstorm session for both of us ;) ).

Share this post


Link to post
Share on other sites
I don't know why you insist on this model where there is an initial design and then people implement things separately. There are some cases where you can actually divide the project the way you are thinking, but they are rare. For instance, you can make a chess program and separate the engine from the GUI. The two of them will run as separate programs and will use the UCI protocol to communicate. That can be done separately and then put together.

In a more typical project, after the initial analysis and design, someone will create a code repository that the others can access (using something like CVS or Subversion). Somehow a first prototype will be made. Perhaps all the sprites are just colored rectangles, there is no sound, no input, no player character, the scene is a horizontal floor with ground below (solid brown color) and sky above (solid blue color): Whatever simplifications are necessary to get something going, with the structure of the code being approximately what has been agreed on initially. Then people work to upgrade their part of the project to be more functional, prioritizing the things that others will have to wait for. Weekly meetings recommended. Documentation in the form of a Wiki is very helpful too.

I don't see why something like that wouldn't be workable in a college setting. You guys even have computer labs where you can meet and work together on something for a few hours.

Share this post


Link to post
Share on other sites
Programmers working on a project should understand the whole project slightly and their part roughly. They should use brainstorming and give themselfs todos .You give one programmer a todo and he will do it, wheather it is a bounding box display or physics. But there are programmers knowing a lot about rendering engine and programmers that are mainly knowledgable of game play engine, and lead programmers who knows just anything and can code anything and correct anything.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!