Design Overview
N2D is built on top of libgdx, a high-level, cross-platform game development library written in Java. The use of libgdx allows us to not worry about the low level implementation of things such as rendering, sound playback, input management, etc… and instead focus on building the engine itself. Users will use a WYSIWYG interface written in java for creating their game worlds and managing their assets. The use of the java programming language means that we only need to maintain one code base and can deploy to all three of the target operating systems (PC, Mac, Linux). To create their games logic, developers can use the javascript language.
Various SDKs, such as the Android SDK and the OUYA ODK will also be used for their respective platform specific features.
A robust CBES serves as the core of N2D. Each N2D project is composed of multiple scenes. A scene can be thought of as a single level, or zone in your game. A scene contains a set of GameObjects. GameObjects are the heart of N2D's CBES. Anything that has an existence in a scene is a GameObject. By themselves, GameObjects are no more than an empty shell that has a position, scale, and rotation. They do nothing, and are nothing. In order to give a GameObject functionality, we need to give it a list of components. A GameObject is defined by its components. Think of a computer. A computer has a motherboard, CPU, a storage drive, some RAM, a video card, probably an optical drive, etc... All of these components help define a modern computer. If you take away some of these components, it can no longer be defined as a computer. That is the philosophy behind a CBES.
N2D uses components for things such as rendering, audio playback, behavioral scripting, etc... Unlike many CBES, N2D has a predefined set of components to choose from, and relies on one of those components, the Behavior component, to provide custom game logic and functionality.
The final piece to N2D's CBES is the concept of layers. Since a GameObject is updated by simply updating all of its components in turn, we need some means of forcing some order. It can be cumbersome to keep track of what component is added to what GameObject and in what order, so we use layers to organize our scene. A layer is just a collection of GameObjects and a given z-order. When a scene is updated, it updates its layers in order, from the layer with the lowest z order, to the layer with the highest z order. For example, if you had a scene with 2 layers, the first at z1, and the second at z2, and each layer had one GameObject with some form of a rendering component (We'll get to that later), then the object in z1 would be rendered before the object in z2, no matter what order they were added to the scene. This means that if both objects were rendered at the same spot, the object in z1 would be rendered underneath the object at z2. Convenient, eh? N2D's CBES is extremely flexible, yet concise and simple to understand. In the end, it is a giant tree looking something like this:
This tree is known as a scene graph.
If you notice, some of the nodes in the example scene graph above have the same name. This is because the name of each node must only be unique for its parent node.
N2D's CBES is relatively simple, but can take some time getting used to, especially if you are coming from a more traditional OOP background, but once you master it, the possibilities are endless, and the paths to get there are shorter.