PDA

View Full Version : How does it all work?



Tr00jg
04-09-2007, 03:23 PM
Lately I've been thinking. Since I have no experience in Big-ish studios how do they do it? I program alone on my game, but what happens when there is more than 1 guy working on the same code? How does it all work? Does the company set the rules on how the code is structured or what? Do they develop a special in-house application for this?

FuzzYspo0N
04-09-2007, 03:42 PM
WEll i think there is code repositories with check in check out functions, so i check out the file for the menu, and edit it according to guidelines, and then submit the changes...

That way we all get simlar code and all ppl can fix other ppls bugs ;p

other than that there shud just be a place for all the developers to interact and work on projects together i dunno really,

:)

Himmler
04-09-2007, 04:06 PM
This is exactly the reason we should be working on team projects in Game.Dev

This is the only way to really understand the way things work in the "Big" development houses.

Etienne
04-09-2007, 04:16 PM
Well, I don't know how big game companies do it, but I can tell you how a big bank does it. I work for one of the biggest banks in SA. We have lots of coders work on the same project. As FuzzySpoon (You that oke from RAU?) suggested, we use code repositories. I book out the file I need to work on, then book it back in once it's done.

You can also search on the net for some tips on how to work on big projects. I know KDE (a Linux Desktop environment) has a code repository policy, which basically states rules for booking out and booking in code.

Fengol
04-09-2007, 04:46 PM
Yeah, I think game dev teams use the same methodologies as business app teams when it comes to code repositories, build scripts, unit testing and code coverage. I think one of the major differences would be the inclusion of non-code assets like textures and sound which might have extra build rountines you'd have to cater for in your build script

Tr00jg
04-09-2007, 04:53 PM
I book out the file I need to work on, then book it back in once it's done.


Oh okay.. But your code obviously has to "reach" out to other pieces of code. Bah, its hard to describe. Do you have to then book out all the code that you have to work on?

ShadowMaster
04-09-2007, 05:10 PM
Oh okay.. But your code obviously has to "reach" out to other pieces of code. Bah, its hard to describe. Do you have to then book out all the code that you have to work on?

You probally mean the code has to "intercommunicate". A hard enough thing for a single coder, but harder still in teams. The key is planning the interface of the code and having it documented.

BlackHawk
04-09-2007, 05:11 PM
In my day to day environment every coder pretty much have a complete copy of the code base on his machine before he checks out the file(s) he needs to start work on. Of course, if one of he's colleagues has a file he needs, he has to ask for it (usually because the colleague has forgotten to check said file back into the repository).

As for game development, I would suspect "code base" would be different depending on what you do: textures, art assets would change more often for artists than the engine code so the engine code source isn't checked out by them and thus doesn't change often on their machines. Inversely, engine coders will have a copy of the latest textures on their machines and work with the engine code around those.

As Fengol noted, if you are on the bleeding edge of the engine (ie your work directly affects the loading of textures) you would have to have a build action in your compilation routine to get the latest textures from the repository each time you press the compile/build button.

A necessary rule in a team environment is to make sure that everyone is on the same code base after a major/minor roll-out of the app/game.

Rabs
04-09-2007, 07:11 PM
Well I can tell you that you guys are right.. I work at quite a big developer and we use software called Perforce (you can probably look it up. it is known as Version Control) where the code will be on the network and you have to log a piece of code out and edit it and then submit it back in again.. And then when you next log on to perforce you sync your files to the ones that have been updated and all of the old files get logged so you can keep a close eye on the changes and say you need to release a build and it hasn’t been working you can revert it back to a specific day.

We have a team of about 8 coders on each project and they each work on a specific area of the game... But as we use an internal SDK they all use the same type of code and techniques.

We also have a Labs side as well as a Studio where they work on the tech making sure the SDK we use does what it says it should and they find allot of the programming issues for us.. Of course then we have to test it in the actual game to see if it works.

Oh and if you are wondering, there is usually a Lead Coder or a Coder experienced producer who will give out the work to the various coders depending on their strengths and make sure all of the code tasks are covered.

Tr00jg
04-09-2007, 08:48 PM
Ah cool Rabs (and the others)! That explains it all. Thanks. :)

DrDeth
05-09-2007, 08:16 AM
I use Subversion (http://subversion.tigris.org), TortoiseSVN (http://tortoisesvn.tigris.org/) (which is a Windows shell add-on) and AnkhSVN (http://ankhsvn.tigris.org/) (a VS extension) for version control. It is essential in a team environment.

Another useful tool is CruiseControl - which is an automated build environment. We use it to do nightly builds, run code analysis, automated regression testing, etc.

FuzzYspo0N
05-09-2007, 08:25 AM
Yea, Thats great information. I was actually typing in a rush haha, i know many game developers who have told me how it works and its basically described above.

SVN or Version control mirrors the same folder on every developers machine and every developer can build his/her own copy, then there is a tracker which follows changes, most Version control software has a difference checker and a sync folder tool etc, just to make sure you are current.That way you login, it updates all the changes warning you of which so you dont lose work , and it usually keeps a few roll backs as well.

All code checks are as said are managed and overlooked by a lead Coder and a project manager also usually steps in and ensures all aspects of the original design documents are being met as well as new ideas and concepts being integrated within the design...

That way everyone feels they have a say, And also eliminates me doing something redundant, its also a great way of making sure the developers experiment, cos i can take my version and mess with it as much as i want to without it affecting the team, and i can archive/track those changes to show the team without affecting the main code base...

I think for game.dev it wud be awesome to make a team project but it wud take a large amount of foresight and planning in terms of getting to know how can do what, what kinda game etc.We cud even right a tool to use like that to administrate the creation of game.dev games or projects :)