Hello.
Im currently working on the environment for a project of mine. You could say Im and environment/texture/props artist.
What I was wondering is how professionals collaborate in a production environment? And most specificly, are there any guidelines towards the environment artists that they need to follow before they present their work to a coder.
…Or what are the top tips or rules you follow before you present a ready model/terrain/prop to a coder.
I hope this makes sense.
Cheers.
I am by no means an expert on this topic.
Most major companies that develop games have multiple teams working on different things. For example, your position (environment designer), would have en entire team working on it, which takes a lot of coordination. You need to coordinate yourselves. Make sure you are all working on the right things at the right time and have the same expectations of the result. The best thing you could probably do is work on concept art before presenting it. http://www.youtube.com/user/FZDSCHOOL has some great tips on concept art.
When presenting the models for “coding”, however, make sure that the objects are in the right file format (max, obj, 3ds etc.), properly UV unwrapped and has all the textures with it. This will make the coders’ lives much easier – ask them what they want you to do with the objects.
I think this should be of some help if I understood you correctly. 
“Coding” implements the behavior model while “modelling” implements the presentation model.
Both are development steps at the same level of abstraction. With well defined interfaces they should work pretty independently from each other. At any time they can text their work against this interface even when there are just mockups at the other side (e.g. cubes rather then high detailed characters or characters with standing animation without complex behavior)
The requirements such as level dimensions, visible sizes, character sizes, number of visible objects, file names, naming conventions, content containers …
Should be determined beforehand or at least by an architectural instance.
This instance should be involved at any change at the above mentioned interfaces.
Please do not forget the other parts of game development: sound design, level design, animation, story line, text authoring, localization, pizza delivery …
Ok,
One way that works, is to have a “MasterMind” that codes “Toys” for level builders,
these toys are generic enough to be filled in by the artist.
Like switch with property “target”
Parent 2 objects
switch1 and switch2
(two models for on and off)
and default door 1 Etc.
(opens when switch is pressed “ON”)
(closes when switch is pressed “OFF”)
This way multiple levels can come together, to make a game much faster.
I think the fastest way to actually make a game is to make a “toolbox”
for the artists to use. If I steadily build up tools until you can do almost anything,
and decide what is relevant to include in this game…
Look at Quake 1
Duke nukem 3d 
They had their in house tools packaged in the game.
Also some knowledge of the overall scale and detail level, is required to keep the “Resource Budget” slim and fast.
Thank you so far for the feedback. Great answers. Would love to hear some more views on the subject.
Oh! This is an excellent topic. I’m about to start on this same thing. Any questions I’ve thrown out the last few weeks are just so I can build a “concept”. Some half-working version to get the creative juices flowing. Anyway, the thought of version control, naming conventions, best communication practices, etc. have popped up. There’s so much that goes into game development before the game development even gets started. I don’t know if the op is satisfied with the three thorough answers already, but if people could keep expanding on this topic that would be awesome – and for more than just the two of us, as well.
If it’s convenient and isn’t going to steal the thunder from the ops original question, going over a tool such as git or mercurial would be awesome.
Anyway, nice question, and nice answers so far!
Typically, I don’t need (or even want) to know anything about art assets, because I can write code to act on simple geometric primitives, and artists can change the mesh to whatever they wish.
For designers, it’s a little different: There’s a system of conventions that they need to follow, which depends on the specifics of the system.
As Monster said: It’s about well defined interfaces.
I agree with Goran here. (and most other people)
The key is modularization. Everything should be modular.
So the basic workflow for a large game is:
I know a person who works at a radio manufacturing plant, and one of his jobs is to manage hardware/software issues. In other words, he’s the step 2 and 4 man. I think this is a major part of every product and company.