Table of contents
1 Development tools

1.1 C++ compiler
1.2 Debuggers
1.3 Source control
1.4 CPU Profiler
1.5 GPU Profiler
1.6 Code Editing

2 Object modeling
3 Drawing and painting
4 World design

4.1 Terrain generation
4.2 Full world design

5 Level design
6 Libraries

6.1 Game Engine
6.2 Physics
6.3 Artificial intelligence
6.4 Networking
6.5 Sound
6.6 Scripting
6.7 Input

7 Project planing/Project Management Tools
8 Other tools
[edit]

Development tools

Here we discuss basic development tools. Please help fill out this list.

[edit]

C++ compiler

To work with OGRE, you of course require some kind of C++ compiler. The most popular are:

other C++ compilers

[edit]

Debuggers

[edit]

Source control

Many OGRE add-ons require you to download code from CVS repositories. CVS is also the best way to get the bleeding-edge updated version of OGRE. CVS clients include:

[edit]

CPU Profiler

When getting towards the end of your development process, it is often extremely useful to optimize your code and fix the bottlenecks to the best of your ability. To find these bottlenecks you may use a code profiler to show you the time and memory usages in each function call. Some of those available are:

[edit]

GPU Profiler

[edit]

Code Editing

[edit]

Object modeling

Games include models of people, monsters, cars and so forth. These models are almost universally created using a third party tool. Models normally consist of a polygon mesh that specifies the structure of the model, textures which are layered over the polygon mesh, and animations. Animations specify standard motions that the object can perform, such as laughing, waving, running and so forth.

In theory, it is possible to specify models and their animations directly in Ogre, but this would be so time-consuming that people use third party modeling tools instead.

Modeling tools use proprietary formats for the models they generate. However, many tools provide a plug-in capability, allowing them to be extended to provide output in the format that Ogre expects.

Dedicated to animation:

[edit]

Drawing and painting

Drawing/painting tools are used to create textures for models and landscapes. Textures are simply bitmap images that are stretched over polygon meshes to make them look realistic.

[edit]

World design

Worlds normally consist of exterior terrain populated with entities (trees, houses, monsters, etc.), water, sky and light sources. Very broadly speaking, there are two problems in creating worlds: creating the terrain, and populating the terrain with all those other things (entities, water, sky, light sources.) World design tools help to solve these problems. Some tools deal exclusively with terrain generation, while others help with laying out the scene.

This appears to be an area where there's room for contribution to Ogre.

[edit]

Terrain generation

[edit]

Full world design

Using exporters available for the following programs allows for export to a scene format known as DotScene. This can be efficiently optimized using the DotSceneOctree scene manager, and lends itself well to large outdoor areas.

[edit]

Level design

The term level is normally used to describe the interiors of building, dungeons or industrial complexes in which many games take place. Levels are different from exteriors in that they typically consist of regular geometry (hallways, staircases, etc.) rather than terrain. Level design tools typically allow the definition of the level's geometry as well as the placement of entities (furniture, monsters, etc.) and light sources.

While levels can be displayed in any scene manager, Ogre provides the BSP scene manager which employs BSP culling and collision management to render levels efficiently. This scene manager is subject to difficult legal restrictions, however. BSP levels are gnerated from Quake .map files, created via a map editor. Most (if not all) BSP compilers are proprietary, and the .map format itself may be proprietary to Id Software (http://www.idsoftware.com). For discussion, see this thread (http://www.ogre3d.org/phpBB2/viewtopic.php?t=8153&postdays=0&postorder=asc&highlight=bsp+scene+manager&start=0) on the forums, which also discusses a new work-in-progress BSP compiler for Ogre.

[edit]

Libraries

You can find some code in the web links section too, along with articles and paper introducing it.

[edit]

Game Engine

[edit]

Physics

Games or simulations normally follow some consistent model of the physical universe. Physical laws dictate that balls bounce when they hit the ground or that a arrows arc upwards then down when fired into the air. More recently, ragdoll physics has become popular as a way of animating characters according to physical models, for example, enabling realistic animation of a person falling after being shot.

If anyone knows enough about these engines to compare them, please do so!

[edit]

Artificial intelligence

There has been little standardization yet as to what an AI engine might contain. But there are enough common AI problems in games, such as pathfinding, that seem to need writing over and over again. Most Ogre projects use custom-built AI libraries.

[edit]

Networking

Effective use of the network is important to multiuser games. To support games played over the Internet, it is necessary to deal with problems of network performance, fault-tolerance, concurrency control and security. Most Ogre prjects are based on custom networking libaries. The following libraries, however, have been found useful by some Ogre users.

[edit]

Sound

Games and simulations rely greatly on sound and music to provide atmosphere. While we often focus on graphics as programmers, sound is at least as important to developing an immersive atmosphere.

[edit]

Scripting

3D applications are often organized so that the performance-critical parts are written in C++ while the application itself is written in a so-called scripting language. Scripting languages are typically interpreted allowing a tighter code/execution cycle, and are usually easier to debug than C++. This allows more rapid application development while retaining good performance.

Alternatively, the application can be structured where scripts are embedded within a C++ application.

[edit]

Input

Although OGRE does already provide an input management system, it isn't meant to be complete and is only there for convenience. For example, it doesn't provide joystick support, which is quite an important feature for any arcade game. Success has been reported in the forums with the following input libraries :

[edit]

Project planing/Project Management Tools

Here you get a list of free/open Project Management Tools: http://proj.chbs.dk/

[edit]

Other tools

This section is for tools that I don't understand well enough to categorize. Please fill in some details and move these to the appropriate sections.


Views
Personal tools
Navigation