Back to General and Gameplay Programming

Game Programming in a Team

Sean_Seanston · 2009-10-16T12:09:22

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.

General and Gameplay Programming Programming

Started by Sean_Seanston October 14, 2009 11:35 AM

13 comments, last by EJH 14 years, 6 months ago

Sean_Seanston

880

Author

October 15, 2009 07:11 PM

Quote:Original post by Captain P
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 ;) ).

Seems like AI would be a good thing to call a module. Then maybe the whole sort of entity system for the NPCs which could be done together with the AI.
Loading and collision detection of levels sounds like a good thing to be a module.
The player and all associated info such as score etc. maybe.
Menus if there are any.
Sound if you have any.

But they still largely depend on some sort of basic implementation of the game already existing...

Quote:Original post by alvaro
Then people work to upgrade their part of the project to be more functional, prioritizing the things that others will have to wait for.

I suppose that's largely what I need to get at right now. What parts of the project might make most sense to be separated out? And then, should perhaps one person make the prototype himself?

Kylotan

10,510

October 16, 2009 04:38 AM

Quote:Original post by alvaro
I don't know why you insist on this model where there is an initial design and then people implement things separately. [...] Whatever simplifications are necessary to get something going, with the structure of the code being approximately what has been agreed on initially.

Surely that what was 'agreed on initially' is 'an initial design'. To set several people to work on anything you need to have an idea of what that thing is (a design) and need to be able to allocate the work to different people. I don't see a difference here.

Captain P

1,092

October 16, 2009 06:08 AM

Quote:Original post by Sean_Seanston
But they still largely depend on some sort of basic implementation of the game already existing...

Define 'basic implementation of the game'? What you described makes up your game, so this is a very vague statement. Analyze it some more: what modules depend on what others? And why? It's precisely 'the game' that you're trying to split up into parts.

In some cases, you need a bit of code in place already: an Entity class that you can derive from or that you can add components to, for example. Once that's in place, you can divide the various entities or components across multiple programmers.

In other cases, you can use temporary code. Write a class interface, mock up some quick function stubs and voila - dependency problem solved, you can continue working on other code that needs this class. So what if the collision module doesn't do anything yet when the level loading code calls addCollisionShape()? Of course, this won't work everywhere, but it's helpful at times.

Sometimes however, you just need a working implementation of some module or class. That's where you need to prioritize: this class needs to be built first, that module can wait till later.

When you're making an initial design, these are things to keep in mind.

Create-ivity - a game development blog Mouseover for more information.

alvaro

21,604

October 16, 2009 07:49 AM

Quote:Original post by Kylotan
Quote:Original post by alvaro
I don't know why you insist on this model where there is an initial design and then people implement things separately. [...] Whatever simplifications are necessary to get something going, with the structure of the code being approximately what has been agreed on initially.

Surely that what was 'agreed on initially' is 'an initial design'. To set several people to work on anything you need to have an idea of what that thing is (a design) and need to be able to allocate the work to different people. I don't see a difference here.

No disagreement here: There is no difference. I probably didn't express myself clearly. By that what was "agreed on initially" I mean the same thing as "an initial design". I am not saying that that phase is not needed: I was trying to emphasize the need for continued communication during the coding phase.

EJH

315

October 16, 2009 12:09 PM

In addition to having a strong design document, it is extremely helpful to designate 1 or maybe 2 people (usually the most experienced) as "the architect". The architect will personally design and implement the overall app framework. Everyone else will be assigned classes or functions to implement by the architect, and be given exact function prototypes.

Since the architect designed and implemented the app framework, they can instantly answer obscure questions like "when i right-click on an object in the game world, how can I change the context menu items for that object, and then propagate the selected action over the network" (something that may take substantial time figure out by only reading the code or design doc).

If you are the architect, and you are assigning people work, the best thing to do is write blank classes or functions that are already hooked fully into the project framework (updating, drawing, colliding, etc..). Then the person assigned the work can simply fill in the classes and functions with new code.

Game Programming in a Team

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Game Programming in a Team

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines