(NativeObjectWorldArchitecture) NOWA-Engine

(NativeObjectWorldArchitecture) NOWA-Engine

Written by:


  • Lukas Kalinowski


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.

Contained components of the NOWA-Engines:

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

Feature videos of NOWA-Engine:

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.
    • Dynamic physics objects: For motion and physics handling for severial kinds of collision types: Quader, Ellipsoid, Pyramid, Capsule, Cylinder, Convexhull, Cone, CompoundCollisionHull, etc.
    • Compositions: Compositions of dynamic physics objects to create more complex physics objects like connecting together a Convexhull with a Quader etc.
    • Convex compound collisions: Creating most complex active physical components composed of convex hulls, that are forming together a complex collision hull. E.g. creating gears and rings.
    • Constraints: (breakable) Hinge-, Slider-, Ball-And-Socket-, Motorized-, Screwcork-, CustomDryFriction-, Kinematic-, Pulley-, WormGear-, Spring-damping, Pin-Joints to constrain some motion behavior, e.g. creating breakable swing doors.
    • Ragdolls: Integration of ragdolls for game objects with bones.
    • Vehicle: Integration of vehicles to controll cars etc. (Unfinished)
    • Category system to group kinds of physics objects together to perform collision behavior of game objects of different categories, ray casts.
    • Physics material pairs to combine two different categories to specify physics behavior on collision, like creating a trampolin, on which a game object may jump higher.
    • Buoyancy integration for motion behavior of game objects in liquid.
    • Motion constraints: Its possible to constraint axes for a object. E.g. eliminating the z-axis could be useful for 2D Jump’ n’ Run games, in which the physics just works for x- and y-axis.

  • General:
    • The NOWA-Engine uses a state system to create own levels, menues etc.
    • Generic GameObject factory, to create GameObjects, which are composed of several components, like physics component, shader component etc.
    • It uses Ogre2.x version and “Physically Based Shading” (PBS) to keep pace with newest rendering techniques.
    • Event-Delegate system to ease the communcation between different modules.
    • Process system to create chained events like explosion of bombs etc.
    • Different kinds of game loops (VSync restricted, unrestricted and adaptive).
    • MyGui layout.
    • Artificial Intelligence to integrate to game object, to move autonome, like seek, flee, move-path, flocking, arrive etc.
    • Ability to create navigation maps and obstacles for A* path finding.
    • GameObjectController: Database for gameobjects. Its possible to perform a lot of different queries, to receive the desired game objects.
    • Realtime camera manager, to specify camera behavior like base-, first-person, third-person camera and switch between the modes at runtime.
    • Game object name display above the head.
    • Skeleton visualizer to debug bones of game objects etc.
    • Animation fader, to interpolate between to animation to create a more realistic game object motion.
    • Camcorder to record and playback camera motions
    • Screenshot manager

  • Lua scripting:
    • Lua script integration, to write lua code and control game objects at runtime. (in work…)
    • Build in console for scripting and logging.

  • Graphics:
    • Physically based shading (PBS) for realistic scene rendering and complex shadows.
    • Several predefinded workspaces: PBS, PBS and Skybox, PBS, Skybox and reflections.
    • Directional-, Spot- and Point-lights, which can be mixed.
    • Compositor effects for the screen like motion blur etc.
    • Water simulation, which can be connected with buoyancy for phyical water motion behavior of game objects.

  • Audio:
    • 3D Audio system to connect to game objects and states for sounds and music.

  • Editor:
    • Editor manager: Class container with a lot of functionalities like game objects manipulation via Gizmo, Undo/Redo, MyGUI integration etc. to create a runtime editor.
    • Picker: In order to grab and play with dynamic physics objects.

  • Resources:
    • A lot of free resources like meshes, animations, sounds, particle effects etc.

  • Networking:
    • Integration of server/client topology.
    • 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


    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.

    At that time a GameObject can be combined with following components:

    • AnimationComponent
    • AttributesComponent
    • BuoyancyComponent
    • DistributedComponent
    • GameObjectTitleComponent
    • ExitComponent
    • NavMeshComponent
    • ParticleUniverseComponent
    • PhysicsActiveComponent
    • PhysicsActiveCompoundComponent
    • PhysicsCompoundConnectionComponent
    • PhysicsMaterialComponent
    • PhysicsActiveDestructableComponent
    • PhysicsArtifactComponent
    • PhysicsMathSliderComponent
    • PhysicsRagdollComponent
    • PhysicsTerrainComponent
    • ParticleUniverseComponent
    • SimpleSoundComponent
    • SpawnComponent
    • PhysicsExplosionComponent
    • NodeComponent
    • TimeTriggerComponent
    • PlaneComponent
    • CameraComponent
    • LightDirectionalComponent
    • LightSpotComponent
    • LightPointComponent
    • CompositorEffectComponent

    Physics Components can also be connected together with joints (constraints). This joints are managed by so called JointComponents. The following JointComponents types are available:

    • JointHingeComponent
    • JointBallAndSocketComponent
    • JointPinComponent
    • JointCorkScrewComponent
    • JointPassiveSliderComponent
    • JointActiveSliderComponent
    • JointMathSliderComponent
    • JointSlidingContactComponent
    • JointAttractorComponent
    • JointSpringComponent
    • JointKinematicComponent
    • JointDryRollingFrictionComponent
    • JointPulleyComponent
    • JointGearComponent
    • JointWormGearComponent
    • JointUniversalComponent

    A joint can also be released, e.g. to simulate breakable joints (see PhysicsActiveDestructableComponent).

    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:

    • LuaScriptModule (Singleton)
    • OgreALModule (Singleton)
    • OgreNewtModule (Singleton)
    • OgreRecastModule (no Singleton)
    • ParticleUniverseModule (Singleton)
    • RakNetModule (Singleton)
    • WorkspaceModule (no Singleton)
    • GameProgressModule (Singleton)


Comments are closed.