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.