(NativeObjectWorldArchitecture) NOWA-Engine

(NativeObjectWorldArchitecture) NOWA-Engine

Written by:

Lukas Kalinowski

Introduction

Games fascinated me even as a child. I was keen on understanding how a game does work behind the scenes. So I started to study media and computing to lay the foundations.

During my study, I started to develop an application in C++ to ease the creation of graphical simulation.
At that time I was inspired by Advanced Ogre Framework. Henceforward, all my projects where developed using the OgreBaseArchitecture, which is an DLL and can be linked to applications.
This had also the effect, that the OgreBaseArchitecture had been extended bit by bit. Now a few years have passed since 2010 and the engine is still growing. I re-branded the name to NOWA-Engine (NativeObjectWorldArchitecture-Engine). NOWA is a word play for the same polish word, which means ‘new’. Put It in another words: from something old, something new emerges like a star that explodes in a nova creating something new.

The idea of the NOWA-Engine is to ease the development of games as far as possible, so the engine is as generic as possible.
Thus a lot of design patterns are used in the engine like Observer-, Eventing system with delegate functions, generic factory-, Composite-, State-, Strategy-, Singleton-, Null-Object-pattern, Curiously recurring template pattern etc.
The NOWA-Engine is intended for C++ developer and Designer with basic knowledge of the scripting language Lua.
The developer can concentrate on a higher level building a game without the need of taking care of lower level issues.
The NOWA-Engine became a hobby project and will be extended in future.

The NOWA-Engine is now used in an runtime virtual environment editor called NOWA-Design.

Feature videos of NOWA-Engine:

Performance NOWA-Engine:

A stress test with the NOWA-Engine and the NOWA-Design editor.

Scenario: Spawning lots of barels which are also physically simulated.

First test:

Ogre3D Threads 4, Newton Physics Threads 1: ~250 Barels FPS went down

Second test:

Ogre3D Threads 4, Newton Physics Threads 4: ~650 Barels FPS went downNote: In the video the FPS went down earlier because of the additional resources consumption of the screen capturing tool.

See:

So what are the features of the NOWA-Engine:

Nearly full OgreNewt physics integration:

Static physics objects with complex collision, which can also be automatically serialized and deserialized, when something changed on the collision map for loading speedup. Also collision map for Ogre Terrain.

Replicating game objects like players statically by cloning GameObjects at realtime.

Efficient automatic dispatch of movements of game objects using the procedure “playout delays”.

Area of interest: Information about a game object will only be sent to other remote game objects, if there are in range.

Whats still left:

A lot of things! Since my timewindow is small.

Instancing for collision objects.

Other constraints like magnets, pulley joint etc.

Planet systems

…

Basics

The most import piece is the GameObject. A GameObject represents a model in the scene. It contains mainly a position, orientation, scale and a mesh. A GameObject may be composed of so called Components. This is a really powerful design pattern. Because each Component comes with a specific behaviour. By adding Components to a GameObject, the GameObject will be armed with the functionality of the Components. Thus a GameObject knows its Components and each Component knows its GameObject (owner). Therefore a Component can also communicate via its owner with another Component. This design architecture prevents derivation explosion, as there is just the game object and a list of components.
GameObjects are gathered by the GameObjectController. It keeps track of the lifecycle of GameObjects and has a lot of manipulation functionality. Like cloning GameObjects, query GameObjects, add categories of GameObjects to group them together for ray scene queries and physics materials. Its also possible to activate (heavy) game objects when player is in a certain range and deactivate when the player leaves the range.
The next important piece is the DotSceneImportModule. The DotSceneImportModule is responsible for loading and parsing virtual environments described in XML. In order to save a virtual environment to XML, the DotSceneExportModule is used. In the past the Ogitor was used but it has been abandoned, as the Ogitor has being stopped developed.
Hence yeah! Why not creating an own virtual environment editor??? Thus the NOWA-Design editor has been created for this task.

GameObjectTitleComponent: A game object title is shown with custom text.

ExitComponent: Level exit component. When reached, a new level will be loaded.

NavMeshComponent: A*-navigation component, which is used as obstacle, so that the path is computed around the obstacle.

ParticleUniverseComponent: Used for particle effects

PhysicsActiveComponent: Physics component that is dynamic and uses law of forces.

PhysicsActiveCompoundComponent: Active physics component, that is build of several collision pieces, forming a more complex collision hull, like a ring.

PhysicsCompoundConnectionComponent: Active physics component, that is build of several components, forming a more complex collision hull.

PhysicsMaterialComponent: Used to connect to physics groups together and adding specifig physics materials like elasticity, friction, conveyor and even Lua callbacks when a physics collision occured, to react in Lua.

Physics Components can also have physics materials. With this material component the physical behaviour between groups of physics components is specifed. E.g. whether a GameObject of the category ‘vehicle’ will have a high friction with the GameObject of the category ‘ground’ etc. The following material attributes are available:

MaterialFriction

MaterialSoftness

MaterialElasticity

MaterialSurfaceThickness

MaterialCollideable

MaterialContinousCollisionMode

MaterialContactBehaviour (ConveyorPlayer, ConveyorObject)

The NOWA-Engine comes with a lot of helper modules, which support GameObject, Components etc. by its tasks. A module can be a Singleton when it does make sense, but not every module is one. The following modules can be listed: