Link

1. Live editing the running console and PC game

Immediate feedback by live editing

Game designers can live edit and manipulate the running application. In this way you take advantage of the following workflow:

• Modify something in some tool.
• Click "update".
• See the result in the running game.

See also Live editing the running console and PC game.

Updating changes into consoles

Since the live editing mechanism works over TCP, you can work on one computer and see the changes in your application running on a console or a different computer.

For example, you are running your game on a console. At the same time you are editing the game on your development computer. You can update your changes directly into the running game and can see how your changes look like on the console.

Updating changes into other computers

Another situation is the following. You are running your game full-screen on a less powerful PC which is typically used by persons who are going to play your game. At the same time you are editing the game on your powerful development computer. Also in this situation you can update your changes directly into the running game and can see how your changes look like on the running target system.

Updating changes into your proprietary application

You can update changes into your proprietary Shark 3D based application. See Live editing the running console and PC game for details.

Updating out of third-party tools

This works not only for specialized tools, but also for third-party tools like Photoshop™ or 3D Studio Max™.

For example, the designer can play the game level for testing. He might find out that, for example, some mesh, some bone animation or some texture bitmap should be modified. Then the level designer can perform this change for example in Photoshop™ or 3D Studio Max™. With clicking on the "Save" respectively "Update" button, these changes are updated into the running Shark 3D based application. The designer can continue playing the modified level in Shark 3D.

Editing the game logic

Live editing also includes game logic objects, for example animation objects, command flow objects or sensor object parameters. You can change an animation control object, and Shark 3D can re-load the animation component in-place. You also may change the command flow defined by some command dispatcher objects, and Shark 3D can adopt this new command flow configuration.

In addition, live editing also works for Perch scripts. For example, during test playing your game, you find out that your Perch script has a logical error. A simple case may be that health points are calculated in a wrong way. Now you can modify the script, compile the script into the byte-code again (which is very quick), and Shark 3D will use the new script code. The update preserves the values of the script variables. So you can continue playing your game in exactly the same situation.

Live editing various kinds of resources

The live editing features allows you to edit and update for example the following resources in the running game:

• Shaders.
• Vertex and pixel/fragment programs.
• Lights.
• Texture bitmaps.
• Meshes.
• Texturing and mapping coordinates.
• Particle systems.
• Object positions.
• Skin information.
• Skeleton animations.
• Object path animations.
• Sound files.
• Perch scripts.
• Custom C++ objects and its parameters.
• Various other resources.

Team collaboration

The live editing features also makes team collaboration more productive. For example, a game tester is performing a complex test session of a console game or computer game. During this session he spots a game logic bug, making it impossible to continue his test. The game tester informs the level scripter about this bug. The scripter quickly realizes that this bug is easy to fix. He commits the change on his personal work station into the version control system. Assuming that the version control system is set up correspondingly, the bug fix is automatically updated into the running game of the game tester. The tester can seamlessly continue his test session. No restart of the game is needed.

Link

2. Resource compilation

Make system

Some kind of resources need to be compiled for the runtime. For example, a Perch script must be compiled from source code into a byte code which is executed by the runtime.

Internally Shark 3D uses a flexible make system for resource compilation. This includes dependency rules and checks.

Easy customization and extensions

By modifying or adding make rules, the resource compilation system can be easily customized for particular projects.

Link

3. Efficient error handling

Resource compile time errors

If your resources include errors which can be detected at resource compilation time, you double-click the error message, and your editor jumps to the corresponding location. For example, a script file may contain a syntax error. Then you easily can jump to the corresponding location.

Runtime errors

In practice runtime errors Shark 3D are similarly important: If Shark 3D reports a runtime error, you also can double-click this error message, and your editor opens the corresponding source file and jumps to the corresponding location. For example, if some dynamic command that cannot be dispatched dynamically under some circumstances and you get an error, you can easily jump to the corresponding component configuration.

In Shark 3D, runtime errors are handled similarly easily as compile time errors. This is especially important because even the most sophisticated tools cannot avoid every possible runtime error. Tools cannot know and understand all actions happening at runtime. Therefore, comfortably handling runtime errors is very important for an efficient workflow.

Link

4. Customize your workflow pipeline for your project

Workflow pipeline customization

Every advanced game project needs customized tools and proprietary special tools. The Shark 3D workflow pipeline is no hard-coded tool chain. Instead, it is a generic framework. Existing tools can be easily integrated into the Shark 3D workflow pipeline.

Integration of existing tools "as-is"

In the simplest case, such a tool can be easily integrated without any modification. It can directly take advantage of Live editing the running console and PC game.

For example, a image manipulation program like Photoshop™ can directly take advantage of Live editing the running console and PC game by simply saving a file.

Customized extensions of existing tools

Existing tools, for example, 3D Studio Max™, can be easily extended to provide user interfaces for proprietary components, for example using Max Script™. New project-specific proprietary tools can be easily integrated into the overall workflow pipeline. Different kinds of editing features can be easily integrated in a modular way into Shark 3D itself.

For example, a C++ developer can implement a new specialized low-level shader. All the complex live editing mechanisms are handled by the existing Shark 3D functionality. The C++ developer has not to worry about live editing or DRU. A very simple configuration entry page provides a customized user interface for this new shader. Using the editor plugin mechanism, it is also easily possible to create advanced configuration interfaces going far beyond a fixed set of simple parameters. Then the level designers and artists can use this new shader in the same way as any other existing shader, including updating changes into the running game.

See also Live editing the running console and PC game.

Adding proprietary editing functionality into Shark 3D

The modularity of Shark 3D is prepared for easily adding game-specific editing features into Shark 3D itself. This provides an optimal workflow for editing many high-level game-specific features. By using the DRU mechanism internally, it is easy for developers to add such live editing features without having to worry about persistence.