Procedural Development

For openFrag to develop into a unique and capable engine, with special functionalities that are unavailable in other engines-- ones that make it notable, even amongst commercial game engines, the features below will be necessary.

Anvil will be the graphical scene editor that incorporates all content relevant to gameplay into the openFrag module. However, it is prudent that developers will someday implement content creation tools that use procedural techniques that will allow the rapid, integrated development of game content. This will extend the ability to develop useful content to a broader user base, who will become less daunted by the possibility of game creation, if they realize they don't have to build a large toolset and become familiar with all of its options.

The integration of simpler to use but far more powerful procedural software programs could be used to create textures and models that are dynamic and interactive.

Procedural Textures

Instead of using GIMP or Photoshop to create a texture, it would be better to tell the engine itself how to create the texture on its own, much as the MaPZone software is able to do. With the MaPZone editor alongside the ProFX middleware it is possible to develop a procedural map of how the texture should be created, which is simply a series of steps the program has to take to achieve a final result. These steps are often done with filters in Photoshop; there is no reason why a game cannot do the same on-the-fly nowadays.

Although the MaPZone editor and ProFX middleware are viable solutions for this sort of functionality in games, this is not appropriate for GPL'd, opensource undertakings such as openFrag. In order to keep the software truly free, the openFrag team must "re-invent the wheel."

One up-and-coming editor and library, the FxGen project is a viable option for integrating procedural textures into the OGRE3D rendering engine. The author of this project is forthcoming with support.

Another very important concept to the development of procedural textures is that of noise. Perlin noise in particular is valued by procedural texture developers, which generates pseudo-random noise that can be used to create realistic-looking textures. One opensource library that can produce this noise, libnoise, may be helpful in augmenting current opensource solutions.

Procedural Models

When one creates a model, to the game engine, it is more or less static. A developer can tell it to have physics, and can tell it to have animations, but the game doesn't know how the model was made, and thus, cannot deviate from the model without having a new, user-created model. This is, for the most part, an accepted truth of game development. However, instead of having a dozen different models of rocks, and two dozen models of trees, there is another way: To tell the computer what a rock or tree should roughly look like, and tell it, through a combination of scripting and modeling, how to create a unique rock or tree.

For procedural modeling, there is another excellent utility-- gSculpt [1]. It can create procedural models, though it is uncertain of how to port them into a project such as openFrag. Also, for users of more developed 3D softwares, this may seem pretty primitive, however, it only lends (in my mind) to how simple the software can be. The interface is difficult to learn at the moment, however.

A very well-known example of procedural generation is .kkrieger, created with the .werkzeug utility [2]. Although it is also another complicated program, it holds a great amount of potential for making small games or presentations. One limitation, however, is that it is not licensed under the GPL.

These applications are not perfect by any means, but the openFrag team can use them as they are right now to build the desired application. To integrate these development tools into Anvil would be very difficult. However, as has been detailed above, the rewards to doing this are uncalculable. Procedural development is, to put it simply, the future of gaming.

Advantages

Another benefit that will be seen from using procedural models and textures in the opensource environment is that the code created by these programs can be shared easily, and easily be easily modified, without the creation and distribution of large PSD files where the nature of the filters that were used and what steps were taken to create the image are often unclear to the casual user. With procedural models, the procedural texture can be loaded into the editor and the developer make subtle modifications to the texture itself by seeing all that was done to create it.

Disadvantages

There are a few drawbacks that to the procedural approach. First, it is notable that these ways are different than the accepted norm. This will require very specialized software. Development of the software will take some time. And also, when the content is re-created or calculated by the computer, a significant amount of overhead will result. It is important to realize, then, that a computer will need to have a not-insignificant amount of power to render these simulations, i.e., to play the game.

The best part about procedural techniques is that they should scale very well between many different setups. The quality will obviously be reduced on a lesser computer, but the game will run. And when the player upgrades, the game will be of higher quality.

Procedural Interactivity

With all this technology inside this game, it would then be possible to do such things as to allow the player themselves to edit parts of the world their computer simulates, to extend a certain amount of in-game interactivity. They could deform terrain, change parts of the scenery and buildings, or maybe build a simple robot. In an FPS these would be important to the gameplay; imagine building a robot to fight alongside the player, or destroying a wall to get to another part of the complex, or even magically making a door where the barrier once stood.

Procedural Animation

TODO A third procedural development technique is procedural animation.

Procedural Audio

Once 3D mesh and texture content is converted to procedural content, a great deal of space has been freed in the project. However, there remains one last group of files that are just as large, if not larger-- The audio files associated with games, such as game music and sounds. This is particularly troublesome for an opensource project such as Revolutionary, since releases without procedural content would without a doubt be much more bandwidth-intensive. Even in this day and age, that can be a major obstacle in the testing and distribution of releases.

One type of audio format that could technically be considered to be procedural is the MIDI. However, the sound quality is severely lacking. The benefit of the MIDI file is that entire songs are usually less than 100 kilobytes. Also of note are SoundFont libraries that allow for much higher quality reproduction of sound from MIDI files. However, these libraries are sometimes tens of gigabytes in size. It would be an even greater impracticality to distribute those, or even the sections that we would use.

At this time, no further satisfactory procedural audio software solutions can be found by the author of this article. If you have any ideas, please contact: CryptoQuick

Further ideas on the distribution of audio with opensource games can be found here: Technical Outline: Audio

Conclusion

Hopefully the development of such powerful technology, in the editor, Anvil, and in the game engine, openFrag, would not only allow the openFrag team to create our their game more easily and allow it to be more dynamic, but also it will inspire people to create their own games now that they know what can be done. With procedural development, it is possible to do more with less, to create more content with less work and less project space. The benefits of this approach are invaluable.