content creation: increasing productivity

Started by
10 comments, last by Norman Barrows 11 years, 3 months ago
Hi everyone!

I'm faced with the daunting challenge of creating content (meshes, textures, models, animations, SFX, music, level maps, etc) for a number of titles, and i'm looking for ways to speed up the process of creating content.

A couple days of research online has only yielded the following (mostly obvious) tricks:

1. use off-the-shelf content when possible.
2. re-use existing content when possible.
3. use editors, either custom built or 3rd party, built into the game or stand alone.
4. apparently quick and dirty built-in custom editors for in-house use only are the best option if no 3rd party editor fits the bill.
5. custom built editors should be as easy to use as possible without requiring too much development time. after all, the goal is to build a game, not an editor.
6. get a big budget and a big staff (not always an option).

as an example of what i'm up against:
my current major project-in-work has 8 outdoor and 3 indoor environments, 61 weapons, over 100 monsters, 162 objects (so far, not including weapons and ammo), and about 400 action animations, plus SFX and music. maps are the only procedurally generated content. granted, this is for one of my larger projects, a FPS/RPG/person sim weighing in at about 50,000 lines of code.

i have a number of released titles in need of new versions, as well as a number of new titles that have passed rapid prototype and are ready for development. the project above is just one of them. coding is not the bottleneck, i have a decent game library that lets me quickly assemble 2d and 3d game engines. the basic code of another project took only 4 weeks from prototype to alpha, being a smaller project at about 7000 lines of code. content creation is the real bottleneck - at least in my case. i suspect its the general case as well, give the ratio of graphic artists, level designers, musicians, and Foley artists to coders in most big studio titles.


anyone know any other tricks for speeding up the process of making all this stuff?

Norm Barrows
Rockland Software Productions

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

Advertisement

anyone know any other tricks for speeding up the process of making all this stuff?

Target perfection:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.[/quote]
Honestly, try to reduce complexity.
Hi,

Group like tasks in each timeframe and work hard. Things which people will rarely see can be "good enough" to fit the game. Hide things as much as possible, such as placing buildings against one another, hill, or vegetation to conceal unfinished or missing sides. Have some buildings be closed with no access and therefore no interior. Handle one type of object at a time, placing the total number of that kind in the scene then move to the next object. Place each type very fast.

The higher the quality of the art which people call "content", then generally the longer they take to create. It sounds as though you will need team members sooner or later.



Clinton

Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software. The better the workflow pipeline, then the greater the potential output for a quality game. Completing projects is the last but finest order.

by Clinton, 3Ddreamer

It occurs to me a lot of games are far too complex. When I make a list of the games I thought were the most fun, as opposed to the most impressive, almost all of them are really simple compared to things like Skyrim or Company of Heroes or whatever.

Honestly, try to reduce complexity.


Yes, I think you hit the nail on the head. Its all about that nasty question of scope. The scope of the game. How big should I make it? How much should it do? The bigger the scope, the more complex the engine and the more content you need.

Reduction of complexity is key for implementing large scope games efficiently.

On the game engine side, I use "generic" routines to deal with the hundreds of actions in the game. One generic routine that handles an entire class of actions such as learning a skill or making a weapon.

On the graphics side, i try to do this as much as possible. Textures, meshes, models, and animations are stored in global databases and reused as much as possible. So any combo of textures, meshes, models, and animations is available to implement the drawing code for an object. While this maximizes reuse, you still need one of each unique texture, mesh, model, and animation.

I've been taking a look at different categories of games and their scope and content requirements recently. If I come up with some result, I'll post them.

Another reply recommended working on similar tasks in batches. This is also another productivity secret. Development on this project has been all todo list driven. Its a new version of a previous hit, being re-built from scratch as a full tilt immersive VR world. So there's a lot to build before you have enough to really playtest. Todo lists make you build one section at a time, instead of bouncing around from task to task. This keeps the task at hand fresh in your mind and speeds implementation.

Right now, drawing missiles is my current task on the todo list. I'm on missile 18 of 27, the throwing hatchet. Fortunately, drawing player weapon in hand and dropped objects on the ground have already been implemented, so I already have the textures, meshes, and models for just about everything. Most of the work will be on animating spinning missiles at the right speed, and creating models of flaming missiles whose texture i can then animate with code. Elsewhere in the game flaming missiles are drawn as individual meshes with animated textures, not as a model that can be easily manipulated as a whole (IE draw this model at this missile's location and orientation).

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php


Most of the work will be on animating spinning missiles at the right speed,

Here's the danger of complexity. Once you start to see benefits of re-using art and feel safe, you will add new features on-top of the stack. But eventually you will come to a point, where changing something at the end will have a impact on items at the beginning and here the whole stack could collaps.

Top-down game content design is really dangerous. What I mean is, that you start with a (very broad) vision of the final content,break it down and develop piece for piece. This is based on a vision, on ideas, which are plenty and cheap. Bottom-up is more like starting with a single content element, learn to master it and after this think about adding an other element.

When looking at successful games like portal, you will quickly see, that there's not really much content. This is what is important: a good game does not need lot of content. On the other hand games like WoW have massive content which is often experienced by the player for only a few minutes.

E.g. are really 27 missiles necessary ? How many are only better versions of previous one. How many deliver really different game play ?

The hard part about game (content) design is not to come up with ideas, the really hard part is to identify and push the core of the vision and remove all the unneccessary junk.
Tools tools tools, there can never be anything such as too much reliance on tools (!= too many tools).
Apart from reducing the complexity and choosing the right tool, I like to stress the importance of a short and fast asset-pipeline to speed up the cycle of designing and testing. Being able to quickly check out the results of your last edit to the model will help a lot in saving time. If you waste 5 minutes per weapon only just to get your testing running, you already wasted 5 hours of work.
Another thing that greatly enhances the speed is to be able to change & save the objects during testing, so you can tune while testing and quickly apply the results.

Being able to quickly check out the results of your last edit to the model will help a lot in saving time

A lot of modern engines achieve great "preview tools".
I've seen a few "real-time" engines that allow you to add stuff in and immediately see the result without requiring someone to build or anything. There are even a few engines where continuous development of several developers can occur at once, meaning you can update assets and whatnot in real-time, while somebody else updates something else, and so you can quickly determine whether its going to clash or not.

[quote name='Ashaman73' timestamp='1355303216' post='5009756']
Here's the danger of complexity. Once you start to see benefits of re-using art and feel safe, you will add new features on-top of the stack. But eventually you will come to a point, where changing something at the end will have a impact on items at the beginning and here the whole stack could collaps.
[/quote]

too true. unfortunately, the title has always been very susceptible to "creeping featuritis". large scope is one of its major selling points. one fan email summed it up best (yes, we get a lot of fan mail! <g>): "In short, [we want] more of EVERYTHING!"

does it really need 27 types of missiles, 64 type of weapons, 100 types of monsters, 400 actions, 200 targets onscreen at once, and a 2500 mile by 2500 mile world to make a cool game? absolutely not! it was fun even when all there were was stone knives, berry bushes, and caves.

However, this title is a little different from your average game. its actually more of a simulator than a game. And in simulators its all about realism (or believe-ability, in the case of sci-fi / fantasy themes). Model and simulate more stuff. Model and simulate stuff more accurately and realistically. So creeping featuritis is endemic to the species so to speak.

The point about later features or changes being incompatible with or breaking earlier features is a good one. As each feature is added, the amount of stuff to track as to "what changes affect what" goes up. I spent 6 hours last night doing text searches on 70,000 lines of code fixing one such issue in the game - making sure range checks (older code) work across map square borders (a later feature). This means that with each new feature, the implementation can become more complex as there is more code to potentially be affected by the change. This increases the risks of introducing errors (bugs) into the code during implementation. Its very important to understand how the entire game engine works when planning such changes and improvements. modular code design helps. makes it easy to "unplug" or "turn off" an old section of code, and replace it with a new, better chunk of code.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

This topic is closed to new replies.

Advertisement