W4 Engine architecture
W4 Engine Wiki > General Concepts > Engine architecture:
- 1 Scope
- 2 Core
- 3 Hardware Abstraction Layer
- 4 Render
- 5 Game
- 6 Resources
The W4 Engine is a library of C ++ modules with framework elements. The Engine allows you to create projects in C ++ language, that are compatible with any modern browser.
Easy installation along with the project creation templates resemble framework; however, it is a library of solutions that you can use according to your needs.
Note. Most templates use the IGame class (it is responsible for the Main Game Loop, and implicitly contains the rest of the modules) - which is convenient and allows the majority of modules to be used independently.
This article provides a brief description of the engine modules and subsystems. Let's start by exploring a general architectural scheme:
The following groups of modules are presented:
Note. Since the W4 Engine is generally a library of independent modules, the separation is given for understanding the modules' scope and does not indicate any relationship between them.
- Core. Some modules are not related to the render and the game itself. Any of them can be used separately.
- HAL. Interaction with the platform. In general, the platform is a browser, but it also contains features for different devices and OS.
- Render. Modules that are responsible for rendering.
- Game. An interface designed to make the main game loop easier to implement.
- Resource. Resource management. In W4 Engine anything that can be loaded (i.e., data without logic) is a resource.
More details are described in the article below, with separate articles dedicated to complex modules (pay attention to the hyperlinks in the text).
The modules and subsystems of the Core group carry out various common functionality of the W4 Engine. Next, let's consider each module separately.
Implementation of basic solutions that are applied inside the Engine, thou be almost useless from outside of the Engine (although such use is possible). For example, the use of smart pointers (sPtr, ivPtr, cPtr) and the FATAL_ERROR module (emergency shutdown and reporting errors to the user.).
The Logger module implements an output (to the console, file, etc.) from within the Engine. Various levels exist, such as Debug, Info, Error, and the like.
Note. Since browser performance is highly dependent on the amount of transferred data, it is better to limit the number of messages to a minimum. Therefore, when building the release version, only critical errors are displayed, the rest is turned off to ensure smooth performance.
Math is a set of standard solutions for various calculations (vector classes, rotator, color, etc.).
The Filesystem module is required due to the fact that the standard C ++ file handling mechanisms cannot be used in a browser. The module implements a virtual file system that allows you to access files by path (URI). Both synchronous and asynchronous calls are used.
Note. Due to the specifics of web applications, the file system is read-only.
This is a C ++ compile-time way of defining state machines. The FSM module is implemented as a separate interface that can be used from anywhere.
See also the W4 FSM How-To article.
The W4 Physics Subsystem is an independent solution that calculates the state of the world (a set of objects) at the current time, taking into account the influence of physical forces and physical properties of the objects themselves. Since the subsystem runs in parallel with other components and does not require their presence, you can use the physical subsystem for calculating interactions only (no drawing).
The idea of an independent approach is that an object on the screen (see W4 Coordinate system and Node structure) and in the physical world are two different objects. Still, the W4 Engine implements a transparent connection between these two objects. Therefore, you just need to connect the physical component to the object and get the physical simulation result.
To find out how to use the physics subsystem when creating games, see W4 Physics for Dummies.
W4 Event System is an independent solution available from any engine module. The user can create events himself and/or use the built-in ones.
Create an event (or just use a built-in one), subscribe and pass the function. When the event occurs, the function is executed from anywhere in the application.
This separate system allows you to convert any engine object to JSON or binary format. The binary format is smaller and faster, but JSON is human-readable and human-writable.
The system provides a ready-made serialization interface anywhere in the application, including objects developed by the user.
Note. All W4 Engine Resources are JSON-like, which enables you to control their content. At the release stage, they can be converted to a binary format using the W4JsonToBinary utility (Note. The reverse process is impossible).
Hardware Abstraction Layer
W4 HAL contains modules for interaction with the platform.
The Input module provides processing of the current input (keyboard, mouse, touch, gyroscope, etc.), sets CallBacks to click, determines the behavior in the absence of a resource, etc.
The Window module is responsible for working with the browser window and passes system metrics (screen size, resolution, supported number of colors, content updates, etc.).
Using graphics APIs such as OpenGL.
The audio module provides audio playback and handles cases when playback is not possible.
Modules and subsystems are responsible for displaying objects on the screen.
The W4 Collision System allows you to subscribe to object intersections, register Callback, and call the function for processing the intersection. For an object, you can set one or several volumes which determine the fact of an intersection.
The W4 Material System is part of the Render, along with the concepts of Material and MaterialInstance.
The Node system (see W4 Coordinate system and Node structure) implements a hierarchical node structure, with the following capabilities:
- The W4 Engine has introspection inside the node structure, so you can identify the type of object. Introspection is especially important for a game engine.
- A node is stored in pointers. It is a self-assembled object, and when it is no longer needed, it is destroyed.
- The transform concept. It is a class of modular mathematics that determines the position in space. The transform is decomposed into rotation, position, and scale.
- Childing (parenting). The W4 Engine has many methods for adding, removing, and finding child nodes.
- Coordinate systems. You can work with the position in the world, local and parent coordinate systems. Affine transformations and axis orientations are similar to the Unity engine.
The Renderer module is responsible for drawing objects on the screen. It can occur in one or more render passes. Each pass, using the camera, draws a RootNode (see W4 Coordinate system and Node structure) and its further descendants to a specific destination, which can be a screen or a texture. By default, the Renderer draws to the screen in one pass.
The camera is a resource that is stored in memory and is not drawn until it is added to the render. This allows you to preload cameras into memory and to draw through them in different passes. For each pass, only one camera can be specified.
The camera is also a node. With its position in space and the possibility to be a child / parent node for something, it allows to bind the position of the camera to the position of the object.
Note. Even if the camera is not tied to anything in the node structure, you still can draw through it.
The W4 Animation System is in charge of playing animations. Animations are not part of the skinned mesh, they are different resources. You can play different animations on the same skinned mesh, as well as use the same animation on different skinned meshes.
GUI is a separate subsystem for rendering controls. See also W4 GUI Creation.
The modules that form the Main Game Loop.
The IGAME class allows the user to conveniently interact with the Engine in order to create a game, and not to use the platform or render directly.
The Component System allows you to add components to objects. For example, if you add a physical component to a node, the position of the node in space begins to be controlled by the physical subsystem. Thus, instead of several stages, such as receiving data from a node, transferring it to a physical subsystem for calculations, and subsequent coordination of the node system and physics, the user simply adds physics to the node and gets the result. If the physical component is removed from the node, the node remains on the screen but is no longer controlled by the laws of physics.
Similarly, you can add the DebugView component to the node to view the debug information.
This system allows you to lighten your code using a familiar add/remove component interface.
The Resource includes texture, cubemap, animation, sound, shader (yes, it's a loadable resource), and so on.
Any resource returns a shared_ptr, and any resource is cached.
You can use Load or Get to obtain the resource. The difference is that Get takes a resource from the cache if it is present, and if not, it calls Load (the loaded resource is immediately cached).