Suppose you were creating an interactive application that allowed the user to manipulate a virtual world where all the objects in that world were made by different people than those that constructed the logic on how those objects were to interact. This is one of the biggest conundrums in game developement, especially amoung indie game developers.
The following is set of guidelines for what information collaborting programmers and artists should be aware of when they are making a 3d indie game. PLEASE ADD TO THIS AND CRITICIZE IT.
1.) A living design document: This is the most fundamental collection of information to your development team. If they do not understand the mechanics of your game and the visual design of your game, your teammates will be confused and ultimately get entangled by a lack of motivation. Also it is almost impossible to expect any sort of coordination in visual theme without every artist sharing a universal vision for how things will look in your game world. Although the mechanics seem to be something only worried about by programmers, it is also important for artists to have a deep understanding of how the game’s logic will work.
2.) Artists must understand their limits in terms of data. Unlike a piece of art that will be used for stills, or used in an animated film, art assets in video games must be designed with two important things in mind: data size, and frame rate. When making models for a game the artist must understand his restrictions on how many polygons(or vertices) his models should have, and at what resolution the textures he drapes his meshes in, should be. If you crowd your world with many extremely complex objects the frame-rate will die quicker than new player in “Socom Navy Seals” online. It is equally important to limit the resolution of your textures, for the same reason. Yet with textures there is the more complex issue of mip-maping, which allows the artist to make textures of higher quality with-out it dropping your frame-rate and extending your loading time.
3.)Programmers must understand direct3d or the basics of how 3d applications operate on their lowest level. Even if you are using a rendering engine(such as Ogre3d) you will, in most cases, have the option to manually create objects. By this I mean writing out all the data that describes vertices, indices, u-v coordinates, etc. This may seem like trivial knowledge, but it is enormously useful to know if you want to add in non-scripted(pre-defined) morphing and other niche, custom, and peculiar effects to your environment. When you have a programmer that knows the general knowledge of how you must communicate with your graphics card, then she can use this knowledge to create almost anything that can thought of and do it so that it may operate in a more dynamic manner.
4.)Programmers must understand the very basics of 3d modeling applications. Some times you just need to augment a model in a small way and it would be more of a hassle to get an artist to do it than for a programmer to. For example lets say you have a very complex model of an elephant. Every time the programmer puts the elephant in the game, the frame rate goes below 24. So it would be very convenient for him to know how to load the model into a modeling program and use the “decimate” function to lower the amount of faces on it.
5.)What is displayed on screen and what the physics engine “sees” are 2 very different(although more similar than different) possible representations of the game environment. Physics engines cannot process anywhere near the amount of vertices that you are able to render. So the world the physics engine “sees” is a dumbed down version of the graphical world. On the screen you will see a running human, yet to the physics engine that human is simply a collection of moving boxes that detect collision with other objects. Often making sure that these two representations of the game world match each other, is a difficult process. The best solution is for an artist to make 2 models of each object, and make one as simple as possible for the physics engine, and one as complex as possible for the graphics engine.
6.)Artists, programmers, and especially designers need to know what can’t be done. I’m not saying that there are things that exist that are completely impossible to accomplish, its just that they would be impractical to pursue.
------ More issues of a semi-related nature
- I personally believe that there should always be two designers, and only two designers, on any indie development team. There should be one designer who is a programmer who designs the interactions and relationships between objects, and a designer who is an artist that designs the world visually and puts a story to the environment so he may then communicate his vision to the rest of the team. Although there are people who are equally good in programming as they are in art, this is usually not the case in most development teams. Most of the time people will have a certain specialization.
The reason why there should be two designers is governed by an educated presumption
of what one is good at, based on their chosen specialization. I am a programmer, I appreciate art, but that is not how I see games. I see games as data that is manipulated through processes that exist to allow a user to interact with an environment. And as a designer I try to make those interactions as fun as possible. An artist sees a game as more of an outlet for creative expression. They see a game in terms of characters and a story that connects those characters in a fictional realm with its own unique artistic quarks. So lets split the design to fit our strengths?
*Please help make this more comprehensive!