Link

1. Component system design philosophy

Combination of flexibility and features

Shark 3D consequently combines high end features with a thorough modularity and flexibility.

Also complex features are consequently implemented in a modular way, without compromising the flexibility. New complex, cutting edge features can be added as new components. By this we are able to provide a lasting platform, which evolves with time.

Features are consequently split into independent components. This makes it possible to use, modify or extend features without needing detailed low-level knowledge about all internal details. You can work with the high-end features on a high abstraction level, you can step deeper into a particular component as needed and wanted, and you can add new specialized and optimized components. Our customers, not we, take full advantage of Shark 3D.

Completeness

Shark 3D provides a complete system for creating interactive online 3d content. Shark 3D can be used immediately to create and run new content by creating artwork in combination with configuration and scripting.

Consistency and orthogonal design

Shark 3D provides much more than just a rich collection of features. The central design guideline of Shark 3D is a well thought out overall design of techniques, algorithms and features. The features can be combined in a flexible, orthogonal way. In contrast to technical features, this aspect is harder to describe by some few catchwords. Nevertheless, it is such a crucial point, without of which professional software cannot live successfully over a sustained period of time.

Link

2. Low-level component architecture

Smart dependency graphs

Shark 3D supports smart object dependency graphs support delayed evaluation. Some advantages are for example:

• If an object indirectly depends multiple times on the same prerequisite, then the state of the object is not recalculated multiple times if the prerequisite has changed.
• If a prerequisite changes multiple times without needing the state of the object, then the state of the object is not calculated multiple times.
• If the state of an object is not used at all, and if nobody is interested into getting notified if the state changes, then this object does not cost any performance at all, even if the state of this object depends on the changing state of other objects.

Open architecture

Objects must not necessarily fit into a given pattern. Instead, Shark 3D supports various standard mechanisms, and each object implementation may decide to use or not to use it.

For example, one object implementation may use the standard mechanism for delayed evaluation, while another object implementation may update its state each frame every time.

Link

3. Component architecture

Object oriented component object model

The Shark 3D is not only object oriented, but consistently component based.

Components, configuration and scripting

Shark 3D uses an object-oriented micro-component architecture. The functionalities are split into quite small, decoupled pieces.

The Shark 3D component system consists of a sophisticated system of components, interfaces, and messages. The power of the system stems from a well-designed architecture, including all details like choosing the right component interfaces, components, commands, and event flows.

The Shark 3D components can be assembled and configurated without programming. This both includes high-level logic control over network and multiuser management down to shaders and shader components.

The developers can take full advantage of Shark 3D not only on C++-level, but also on a high abstraction level, enhancing productivity to hitherto unknown levels.

The component configuration system includes both object properties and command flow between components.

Component architecture levels

At lowest level, it contains a common abstract object factorization mechanism including standard DLL interfaces of components. At higher level, there exist standard interfaces for extending the application functionality and get access to Shark 3D objects.

A lot of time was spent for development of this framework, because it turned out that in the long run a good component design can simplify development a lot, especially if Shark 3D is used for more than one project in parallel.

Component configuration

Components can be configured by changing configuration resources without programming C++ or changing script code.

For example, when including an animation object into a character it can be configured which part of the character it controls. Other important component parameters are command-related parameters. They can be configured to send commands to other components. In this design, configuration resources play an important role besides the usual resources like meshes, animations, textures, sounds etc.

This configuration technique provides a development level higher and easier to use than a scripting level. In practice, it is an important advantage that there is no need to use C++ or a script language for each simple object property. First, this saves time for developers. But it also opens the door for defining new object behaviour for non-programmers.

Component composition and encapsulation

A main feature of the framework is that it allows the combination of several standard components and user-implemented components to a new object with a particular behavior. Combining components usually is called "composition".

For example, a character in a world can be combined out of some standard components like low-level walking collision detection, low-animation components, command dispatchers, and standard character scripts, together with character-specific components like special Perch™ scripts. The construction of the particular character can be done completely by configuration. No C++ or script code is needed if all necessary components are already available. And if additional components are needed for the character, only these components need to be implemented, without having to modify other character code.

Component composition improves the re-usability of code very much, especially since the components are universal and not linked to a particular code environment.

Dynamic object trees

A central property of the Shark 3D architcture are dynamic object trees. This includes that object subsystems can be created at real-time on demand by factories, and may be destroyed again. Such factories can create not only single objects, but complete object trees according object patterns.

All this can be done purely on configuration level, without any scripting or C++ development.

For example, in case of a multiplayer game, each time a new player joins the game, a new player composition object can be created using a factory for this object tree.

So all in all, objects are not only changing their states, but also the object structure, number of objects, and relationships are dynamic.

Commands

A central technique within the component architecture is sending and receiving commands. Components are designed to be universal and not depending on a particular environment. Therefore they have to communicate with other components where no details are known at the time the component is developed.

This is achieved by a universal method invocation technique, which is implemented by using the usual technique of virtual functions. This guarantees easiness and efficiency. The crucial point is a good decoupling of components, a sophisticated design of interfaces, standard commands, and standard methods.

The mechanism how components interact by sending commands can be of course configurated on the component configuration level.

Thorough usage of configurable components

The component architecture is not only used at certain places, for example only for managing level content. It is used basically everywhere in an application.

This includes for example that the component configuration technique is also used to define the structure and functionality of a client based on standard components. This includes viewport definitions, state image definitions, and the interaction of all these components. Also the server is built of several components. This includes client connection mechanisms and level management.

For example, if only one level runs at the same time, or if several levels run on the same server and the players can switch between them, it is only a matter of configuration of the corresponding standard components, without any need of scripting or C++ code.

Game application features which can be completely implemented using only configuration without any line of script code or C++ code include for example:

• Complex animations.
• Event flow.
• Camera management.
• Player components.
• Player structure.
• Player creation.
• Level management.
• Parallel levels.
• Server-client structure.
• Multiple 3d states.
• Client login process.
• Clientside 3d states.
• Multiple viewports.
• Input.
• Actions per "tick".
• Rendering sub-actions.
• Shader structures.
• Displays.
• Many other features.

Thus, Shark 3D does not use special universal techniques only for special applications like content within a level, but everywhere. This opens up huge flexibility basically everywhere in Shark 3D.

As consequence, a Shark 3D executable itself is only a very simple loader loading components and instantiating the first component. The rest is done by interaction of all the components.

Standard project structure components

Standard components include:

• Standard 3d state management architecture.
• Standard level management architecture.
• Standard game state management architecture.
• Standard player management architecture.
• Standard mechanisms for players joining or leaving a networking game.
• Many other standard components.

Universality and flexibility

The power of the Shark 3D component system stems from its universality and flexibility. This allows to use the same universal component types and techniques again and again at very different places.

One sample of the flexibility of the component framework of Shark 3D are displays, displaying for example health points, menus or inventories. From the technical point of view, in the Shark 3D framework, a display is simply an additional 3d state and a corresponding viewport. It uses exactly the same techniques as the main 3d world, but has only some differences on configuration level. For example, in contrast to the main 3d world, a display typically is configured to be managed completely on client-side and to use a parallel projection perspective.

Furthermore, every 3d state, for example a display, can use all features used for the main 3d world. This includes all 3d object management features, TrueType font rendering, all animation techniques, switching objects, and object click features. In the same way as in the main world, you can use all advantages of the component system including scripting, for example to create an advanced inventory system at scripting level.

This is a sample for the flexibility of the component framework, demonstrating how features which at the first moment look very different (like for example the main 3d world and a display) can use the same technologies, and differ only by component configuration and some scripts.

SAP: Controlling Shark 3D via network

The SAP (simple actor protocol) is a simple text based TCP protocol that offers interactive access to Shark 3D actor components while Shark 3D is running.

For example, you can log into the SAP of Shark 3D via TCP by simply using a TELNET client. Using the SAP shell, you can interactively access the component objects by sending messages to it and retrieve their answers. For example, you can activate animations or change animation parameters by simply typing the appropriate command into the telnet window. This can the done without preparing the lift component in any special way. The messages you can send using the SAP are the same messages as used internally by Shark 3D when one component communicates with another component. In other words, SAP allows you to access the internal components of Shark 3D at runtime.

This feature is very useful for experimenting and debugging. You may inspect and modify the current state of your dynamic components interactively at runtime.

You can also easily write applications which control Shark 3D using the SAP. The client can run on the same or on a different computer as Shark 3D. For example, you also can easily write custom clients providing a graphical interface for controlling Shark 3D.

Link

4. Localization and Unicode

Consistent Unicode support

Shark 3D consistently uses Unicode. This includes supplementary characters.

Text resource files

Configuration text resources and other text resource support the following Unicode codings:

• UTF-8.
• UTF-16. Big-endian and little endian. Including surrogate code points.
• Escaped ASCII.

Localization resource files

Support for Unicode language text resource files makes it easy to port applications to different languages.

Memory representations

In memory mostly UTF-8 is used, because this is the most compact representation wasting least memory, and in practice UTF-8 is not more complicated to work with than UTF-16 due to surrogate code points. When calling operating system calls (for example file system functions), if necessary Unicode strings are converted in the format required by the system function.

Link

5. File formats

Generic chunk-based file format

All Shark 3D file formats use a generic chunk-based format. This makes it easy to enhance existing file formats and define new file formats.

Efficient binary representation

Shark 3D files can be stored in an efficient binary representation. This format is optimized for fast load time.

Textual representation with simple syntax

For debugging purposes and for simple manual manipulations, Shark 3D can be also stored or converted into a Unicode textual representation. See also Unicode.

Link

6. State serialization (saving game states)

Universal and flexible serialization mechanism on C++ level

At low-level, Shark 3D provides an universal state serialization mechanism for saving and loading game states to disk.

Serialization can be also implemented for existing external classes which were not prepared for serialization.

Automatic serialization of high-level components

At higher level, all component states are serialized automatically without resulting in any extra work for the designer. This includes for example Perch™ script states and Python™ object states. A developer who implemented new low-level C++-objects can integrate them seamlessly into the Shark 3D serialization mechanism.

Link

7. Live editing the running console and PC game

Editing the running console or PC game

For optimal workflow, the Shark 3D supports updating modified resources into a running console or PC game. See also Workflow and Live editing the running console and PC game.

Changing different types of resources

DRU are supported for many types of resources. See Updating various kinds of resources for samples.

Out of the box DRU into a proprietary Shark 3D based application

The Shark 3D runtime modules support DRU out of the box. The Shark 3D code is consequently implemented in such way.

In this way, a proprietary application using Shark 3D runtime modules automatically supports DRU. This includes the standard Shark 3D player as special case.

Proprietary code

Proprietary code can easily use the advantage of DRU. In the same as as standard components, also proprietary code can support DRU by taking advantage of the underlying DRU infrastructure.

Due to the design of Shark 3D, proprietary code often automatically supports DRU without any additional work at all. For example, a custom shader module automatically supports DRU without having to take special care of.

Link

8. Resource management

Resource manager abstraction

All resources are loaded from an abstract resource manager. This resource manager itself can be assembled from multiple components. For example depending on resource name prefixes or directories, resource requests are dispatched to different child resource managers. Different resources may be fetched from different child resource managers.

Resource manager abstraction

Child resource managers include for example the following:

• Fetching resources from individual files.
• Updating resources via TCP (Live editing the running console and PC game).
• Fetching resources from a packfile.
• User-implemented resource manager components.
• Other standard resource managers.

Pack files

An useful resource manager component is a standard pack file reader. A corresponding packfile tool packs files into a pack file.

• The packfile layout can be optimized for maximum read performance without seeking.
• Each individual resource of a pack file may be compressed or stored plain.

Link

9. Easy implementation of customized tools

The purpose of the Shark 3D component system is to allow an easy implementation of project-specific scripts and tools in a flexible way, working closely together with the Shark 3D component system.

The simple format of component description files makes it very easy to generate such files by scripts or tools. This smoothly works together with Live editing the running console and PC game. No involved C++ tools or C++ components are necessary to customize your development environment in this way.

For example, it is straight forward to write a simple 3ds max™ script which allows to edit game-specific properties of 3d objects, and write out component description files. Using Live editing the running console and PC game, you can view the changes in Shark 3D without having to restart Shark 3D.

Link

10. Stability software technologies

Overview

Shark 3D uses various software technologies based upon low-level C++ techniques to generate stable applications.

Usual C++ development contains several risks, causing hard-to-find bugs like illegal pointers and memory leaks. These bugs are particularly dangerous, since they usually don't cause a simple malfunction, but cause instable software. Furthermore, such kind of bugs are usually hard to find.

At some places, such kind of risky C++ code is necessary for performance reasons, needing very special care during development. But such kind of software development is not suited to make complex systems really stable and reliable.

Fortunately, the power of C++ allows to build more secure and more reliable systems upon low-level C++. But even typical modern software projects using C++ use these possibilities only partially.

Shark 3D thoroughly uses several modern techniques to avoid hidden bugs and offer stable software. These techniques are essential to make complex systems with many heterogeneous object relations and references stable and reliable.

To really take advantage, these software techniques are used not somewhere at some places, but thoroughly within Shark 3D.

Secure object reference system

Shark 3D uses an object reference system which is optimized for performance and also works for complex circular object reference relationships. This avoids memory leaks and illegal pointers also for complex dynamic systems.

Secure polymorphism

The component system thoroughly avoids dangerous type casts. One typical cause of hard to find bugs, namely buggy type casts, is reduced remarkably.

Error management

As far as possible, errors are non-fatal, and program execution can continue after an error.

C++ exceptions are used thoroughly for critical errors. This includes using thoroughly exception save code. This technique allows for robust behaviour of the system in local or global error conditions.