This page has been translated automatically.
Setting Up Development Environment
High-Level Systems
UUSL (Unified UNIGINE Shader Language)
File Formats
Rebuilding the Engine and Tools
Double Precision Coordinates
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
Rendering-Related Classes
Warning! This version of documentation is OUTDATED, as it describes an older SDK version! Please switch to the documentation for the latest SDK version.
Warning! This version of documentation describes an old SDK version which is no longer supported! Please upgrade to the latest SDK version.

Typical Architecture of a Unigine-Based Application

Regardless of the type or genre of your application, its architecture is very important as decisions made in this step will influence the whole project. Since many questions on this topic are asked, we've prepared some guidelines.

Note that in this article we will not consider the internal structure of the engine, and even if you purchased a version with a source code, modifications should be done only as a last resort, otherwise you might break integrity of the engine.

If you want to learn about the engine architecture, see Engine Architecture.

Typical Architecture of a Unigine-Based Application

Unigine provides a lot of features and supports a variety of hardware, but it will definitely be not enough for your project, either it's a game or a virtual reality application. At least, you will need to add application/game logic, but there can be other tasks like adding support for uncommon hardware. When working on this, it is very important not to duplicate functionality which is already implemented in Unigine and to use the right tools, if you actually need to write extensions.

To avoid doubling of functionality, please thoroughly check if your goal can be achieved with Unigine alone. Choosing the right tool for extension implementation requires more lengthy recommendations.

Unigine extensions can be divided into three types depending on the interface to be used:

How to choose between the interfaces? Well, here are a few rules. Of course, there might be exceptions from them but they are rare and questionable.

  • Material system. Write custom shaders when you need some special way of rendering. But please check if the same effect can be achieved with ready-to-use Unigine materials.
  • Interpreter. Thanks to language properties of UnigineScript and to functionality provided by Unigine Library, scripting can and should be used in system scripts (application start-up and shutdown), world scripts (main game logic and state), AI (states, simple decision making), GUI. Do not underestimate UnigineScript, it was specifically created to make developers' life easier; even junior developers quickly start writing in it. Full list of language and interpreter features of UnigineScript is listed in the article UnigineScript.
  • C++ API. C++ components should be used for interaction with hardware, networking, heavy utility code, complex decision-making like path finding. Also, if you want to use third-party libraries, use C++ wrappers to export functionality provided by those libraries into UnigineScript. Avoid writing game logic in C++ because it is inconvenient, prone to errors and can be platform-dependent.

A small example to make the above guidelines clear. Say, you want to create an arcade game for a specific controller that will be shipped with the game: a magic wand. You also want to use a third-party AI library to breathe life into player's enemies. Then you will do the following:

  1. Implement controller support in C++, export necessary functionality into UnigineScript.
  2. Export required AI library functions into UnigineScript.
  3. Write main logic in UnigineScript. Game state, player's state and enemies' state will be stored and updated in scripts.
Last update: 2017-07-03
Build: ()