content creation: increasing productivity

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

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).

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! ): "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.

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.

absolutely! I think this is the most productive trick I've come across yet.

With my current project fast approaching 70,000 lines of code, I'm looking at about 50 seconds just to link a fully optimized release version. Add the time to compile (5 seconds) and fire up the game (maybe 15-20 seconds), and its almost 2 minutes each time you want to move something just one pixel left or right!

So its gotten big enough that you actually plan your development around recompiling as infrequently as possible. Big projects get like that towards the end. 65,000 lines seems to be the breaking point.

To streamline the pipeline for drawing simple dropped objects (one mesh and texture only w/ scale, translation and rotation), i made one of the objects editable. hit a hotkey, and a popup menu lets you set the mesh, texture, scale, rotation, and translation in real time in the game. When it looks good, you copy down the numbers and move on to the next object. When you have the numbers for all the objects, you plug them into the code, recompile once, and then go check them all. Knocked out over 200 objects in about a week.

I've also added a value manipulator tool to the game's modeler. As well as being able to click on a value (such as mesh ID or x scale) and entering a new value, you can now also simply press and hold buttons that increment or decrement the value in real time and update the display in real time. so you select the x position for a limb (such as an upper arm) hit the increment or decrement buttons, and move it in and out in real time. The value manipulator lets you increase and decrease the amount of increment by an order of magnitude by clicking two other buttons. this way you can easily move things by thousands to thousandths of a unit as desired - very handy when trying to scale that girl's thigh mesh just so! ; ). Granted, this feature is nothing special compared to modeling software where you can click and drag to move, scale, and rotate. But this is just an in-house editor (for the moment), probably less than one day's total development time spent on the tool over the life of the project so far. And yes, its built into the game itself. It was easier to make it a menu pick on the main menu of the developer's version that it was to write a separate program.

Being able to change and save objects during testing also helps a lot. If a model doesn't look right, i can quit the game i'm playing, go back to the main menu, run the modeler, load the model, edit it, save it, and quit the modeler. But then i have to quit the game and restart it to force it to load the new version of the model. But then i can go right back in and see the change. A menu pick on the main menu to "reload all graphics" would avoid quitting and restarting. OTOH, all the time for the restart is loading graphics anyway, so probably not much savings there.

[quote name='Orymus3' timestamp='1355941838' post='5012533']
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]

Yes, when beginning a new project, this is always one of the fundamental design decisions i struggle with. Do i do everything hard coded, or do i do everything with loaded data files? Hard coded is usually faster and easier until the code gets so big that compile times become an issue. But data files let you edit without recompiling, which is a big plus on big projects. Hard coded requires access to the source and graphics coding skills. Data files don't. data files let folks without code access create content. But data files require the additional overhead of load and save routines, and editors - so more work upfront. data files also open up the possibility of user editable content.

In the ultimate "data file" game design, everything is in data files, even the sizes of the game's databases - IE how many kinds of targets there are in the target types database, how big the active targets database is, how big the world map is, as well as things like list of all meshes, texture, models, and animations to load, level maps, the actual data for the target types and object types databases, etc. this would be the ultimate editable game engine. I once did a space fighter simulator called Gamma Wing that actually had a weapon type editor in it. The contents of the weapon types database was loaded from a data file.

I usually start with hard coding, and go with loaded data files for the stuff that makes sense to do so. Since I'm basically the last of the "Lone Wolf" developers, i have the luxury of code access and graphics coding skills, and don't have to build any tools for non-coders. This lets me do things the most efficient way from the point of view of the code, without having to make allowances for the capabilities or limitations of individual development team members. In the current project, textures, meshes, models, and animations are all loaded from disk. Each has its associated editor and load and save routines. primarily paint.net and free clone stamp tool for textures, truespace 7.61 for meshes, and the in-game modeler/animator tool for models and animations. music and sfx are data files too. but most of the simple objects (one mesh, one texture, scale, rotate, translate, that's it) are hard coded, as are the earlier static (non-animated) models. I contemplated adding static models (multiple meshes and textures, but no animation) as a separate data type, but ended up simply using animated models that are drawn using a "static" animation (all limbs, no rotations, for all key frames). The data size and execution time overhead of using animated models were negligible.

Needles to say, if this were a group project, all objects would be models loaded from disk, with none hard coded. And the modeler / animator would probably be a stand alone application. I'd spend my time modeling stuff like exposure, body core temperature, and illness, and i'd have an army of artists creating models of every paleolithic artifact under the sun.

In case you're wondering why the game has its own custom modeler and animator, here's why: The game uses a limb based modeling system,as opposed to the more common bones and skinned mesh deformation system. each limb is a separate static mesh. since the meshes are static, you don't have to update the points in the mesh when you draw. so it runs much faster than a bones/skin system. This allows the game to draw the large number of targets required onscreen at once. The original version from 2000 could do 50 characters in combat on screen at once. By comparison, the Direct X Skinned Mesh code could do perhaps half a dozen on the same PC.