More about the development mindset behind Addaadah, and how the entire thing fits together.

Introduction

I can’t stress enough on that Addaadah is mainly for learning purposes, but that doesn’t mean that it can’t be used for commercial game-making. For example, I’ve used (and still use) Nongl as my favorite tool to develop games. While writing this, I still actively develop Nongl while making a new game (Candypede) that uses it for a client (a really awesome one). That’s the only way a tool can become mature, by actually using it.

In this view, I’ll shamelessly get inspired by existing game engines, like Unity3D and Godot. I don’t mind having Addaadah being compared to them all the time (still too early to be compared, but…). In fact, I’ll appreciate the comparisons. I don’t have much experience using engines that are not of my making, since I’m too busy eating my own dog food, so any comparison can become a motive for change. I will not have the least bit of shame while copying bits of other engines’ designs and how to do things. But I’m not planning to make a clone, so we don’t have to stick to their rules either.

Addaadah Core Decisions – Part 2

While these might feel like random decisions, I’ve really put a lot of thought into them (I haven’t been slacking off for 7 months since the last update, not much at least). They represent the engine’s architecture and way of thinking. However, they:

• are subject to change during actual development, or whenever better ways are discovered.
• don’t represent the actual way things are done (specially during the project’s infancy). Rather than that, they represent the ways things are intended to be.

Now, to the actual list of principles:

• Addaadah is to be written in C (no C++). Addaadah is meant to become self-hosting at some time in the future (because it’s cool, and because I want to be able to run the engine itself on any of the supported platforms without many changes). Since I don’t want to waste my life making a C++ compiler (I want to waste it making engines instead), I chose a language I can make a compiler for in a bounded amount of time.
• The natural way to write Addaadah programs is by writing scripts. This allows for easier program debugging and updating (by downloading new scripts). However, in some cases, scripts can be compiled and shipped as a part of the platform specific binaries. This might provide useful when supporting app-stores with strict terms of service (like Apple’s, which prohibit functionality changing scripts).
• Addaadah should be built with support for adding new scripting languages in mind.
• A VM to run scripts written in Bite language (our own language, a subset of C with some additions) is to be written:
  • C might not be the best language for scripting, nor the most user-friendly language, but it’s extremely powerful and portable.
  • Tons of portable C libraries exist, which should facilitate adding new functionality.
  • Making a C compiler is not very hard (I need it to be easy. it’s my first non-toy compiler, after all).
  • Having the scripts written in C (or easily convertible into C-code) allows for compiling the scripts as a part of the application for maximum performance.
• I barely have time to work on Addaadah at all, so while the Bite compiler is being developed, the first language to be supported is going to be Javascript, using Duktape.
• The underlying operating system is to be completely abstracted using an abstraction layer. This abstraction layer should be implemented for each of the supported platforms (with each platform implementation called a backend).
• As a high-level overview of an Addaadah program components, it’s comprised of:
  • Operating system abstraction layer (backend).
  • Scripting languages’ VMs. Initially, Duktape only. Later, Bite VM and any other VMs that we decide to support.
  • Addaadah engine’s core. That’s where the usable user components (activities, views, events, …etc) exist.
  • User scripts that use the engine’s core (that’s where the games’ code should be).
• You should be able to mix scripts in multiple languages in the same program.
• Addaadah engine’s core itself should be written as scripts. Therefore, inter-VM communication support is mandatory. Until the Bite VM is mature enough, the engine core is going to be implemented in C (the subset of C that’s supported by Bite) to allow for easy migration to Bite whenever possible.
• Addaadah is data-driven. It uses an Entity-Component-System architecture. It doesn’t go by the book, it has a lot of twists. However, it’s these twists that make program development more flexible.

Typical Addaadah Program Parts

An Environment

The small confined space in which all our objects exist.

Entities

• Another name for an object. Buttons, Activities, Sprites, Enemies, Players, Items, Coins, Bags, …etc are all entities.
• All entities are the same thing, component-containers with attributes. What tells them apart are the components they have and the values of their attributes.

Components

• A small specialized set of data and code that operates on them.
• Components can’t exist on their own, they must belong to parent entities.
• Components communicate with each other through attributes.
• Components have an optional priority value which dictates which component code runs first (when recurring events are implemented, like onUpdate).
• Code from a component (a script) can freely call exposed functions from other scripts. That’s another means of inter-component communication.
• Components can refer to each other or to other entities. Addaadah should provide means to check whether an entity/component is still alive in a script before using it.
• Component examples: transformation, drawable, melee, ranged, health, …etc.

Systems

• Global code that runs on certain component types. For example, physics. In order for the physics code to easily affect all entities with physics components, it has to be written as a system.
• When components are created, they are automatically added to the corresponding systems’ lists. This way, the system doesn’t have to search for the correct components every time it performs it’s action.
• The engine should have some built-in systems that cover most of the essential global functionality. Most applications won’t need to make their own systems at all.

Resources

Textures, shaders, …etc

• Resources are components themselves.
• A resource can be reused by referring to the same component repeatedly.

An HTTP Server

• needed during development only. Allows for communication between Addaadah Editor and the program.
• allows for reading/modifying variables and updating scripts/resources on the fly.
• makes testing on devices much easier (like being able to push changes to an iOS device without using a Mac at all). In such case, a development-client is installed on the target device first, then changes are pushed to the client to make it into the actual application being developed.
• Even if the program is run within the editor’s environment (same process, same window – possible thanks to having different environments), this HTTP server would still be used for communication between the editor and the client.
• may not be necessary at all. Since strong HTTP request support is mandatory in Addaadah, maybe the server should be part of the editor and not the client, and have to client periodically check for updates?

Extensions/Modules

The engine is extensible through the use of systems and components (if built with re-usability in mind). The engine becomes richer and more capable the more it is used. If special SDKs or platform-specific functionality that’s not exposed through the system abstraction layer are required, they have to be added as modules. Modules:

• should be implemented for every supported platform.
• need to be compiled together with Addaadah to be used. That’s a lot of work, but hopefully needs to be done only once.
• Addaadah build system should allow for incorporating these extensions with the minimal effort possible (like, placing the required files in a certain folder and typing make in the terminal, or through a wizard).

Things to be Added Later

• Details on specific resources.
• Shader editing (common uniforms, node-editor, …etc).
• Bite VM decisions (page 182 in my dev-diary).
• Graphics system abstraction layer (sw rendering, GLSL VM, …etc).

Having laid out all the above, nothing is preventing us from writing our first Addaadah program. Stay tuned! Thanks a lot for having this much interest in Addaadah <3