# Spike Engine_ Introduction to Key Technologies

By [Spike](https://paragraph.com/@spike-6) · 2023-06-11

---

Note: The following content is derived from Spike technical documentation.

**Developed with Script Language**
----------------------------------

The following figure describes the process and principle of how script files enter the engine and communicate with the engine interface.

![](https://storage.googleapis.com/papyrus_images/df2d503be5c6d21588b7cf547ceac7b10b35566dedb538003fccf52f00036d69.png)

The core code of the game engine is implemented in C++. The most basic type in the engine is `Object`, and all types are its subclasses. `Node` is the most common direct subclass, and most of the game logic-related types in the engine directly or indirectly inherit from `Node`, such as model display (`MeshInstance`), animation playback (`AnimationPlayer`), light (`Light`), camera (`Camera`), and physical objects (`PhysicsBody`), etc.

These nodes have lifecycles at runtime, and their behavior can be controlled through script code within relevant callbacks or notifications.

![Script lifecycle overview](https://storage.googleapis.com/papyrus_images/68ee23c75568b17eecd3407db449d7a921ca06be6f591a85efcae7ba37892a1c.png)

Script lifecycle overview

The following Lua code shows a simple script structure.

*   `-@class NewScript : Node`
    
    `local NewScript = class(Node)`
    
    `---Called when the node enters the scene tree for the first time.`
    
    `function NewScript:_ready() -- Replace with function body.`
    
    `end`
    
    `---Called every frame. 'delta' is the elapsed time since the previous frame.`
    
    `function NewScript:_process(delta)`
    
    `end`
    
    `return NewScript`
    

* * *

**Universal resource format**
-----------------------------

The engine defines a universal resource format that is easy to understand and can be efficiently deserialized into corresponding object instances at runtime. This standard first defines the variant data types:

1.  Basic types: numbers and strings.
    
2.  Mathematical types: vectors, quaternions, matrices, etc.
    
3.  Complex types: colors, generic arrays, and dictionaries, etc.
    
4.  Typed arrays: binary arrays, integer arrays, floating-point number arrays, string arrays, vector arrays, and color arrays.
    

These types are rich enough to construct any complex resource type, and can be conveniently serialized and deserialized, respectively as persistent data and runtime data.

The following is a schematic diagram of a resource type save:

![](https://storage.googleapis.com/papyrus_images/d420a0f61722135f3d99c6ca51257539b0a480d6670f9b2b48d0c05d9e237523.png)

Its data structure definition reference:

`class Image {`

`int width;`

`int height;`

`Format format;`

`bool mipmaps;`

`Vector<uint_8> data;`

`};`

* * *

This is a data structure designed for runtime, and the Spike engine editor is also developed through engine runtime. Therefore, this data structure can be used universally in both development and runtime environments.

**Modular System for Gameplay**
-------------------------------

Modular development aims to encapsulate functionality, making each module completely decoupled and becoming a highly versatile functional component.

During the development process, it is necessary to define the combination relationship between modules: parallel or dependency.

The following figure shows a simple module relationship in modular development. Where:

1.  **Main** depends on the two modules **Character Controller** and **Camera Controller**.
    
2.  **Character Controller** and **Camera Controller** have no dependencies and are in parallel.
    
3.  **Character Controller** depends on the **Device Input Manager** module.
    

![](https://storage.googleapis.com/papyrus_images/669c95c34af50c863797fced526276099371baf8e98fb804c25221a3c2aaf500.png)

The relationship between modules defines their loading order at runtime to ensure that modules can start up normally: when the dependency relationship is established by module rewriting, it must ensure that the original module is loaded first before the rewritten module can take effect.

![](https://storage.googleapis.com/papyrus_images/843786dc3f23e3bbaec2952cfd983b1d970fca0ce93c06bfcf4c4b4257b74b8e.png)

Modular development is the process of obtaining or developing functional modules and defining the relationship between modules to ultimately form a `Modular Graph` resource.

**Build Modular Application**
-----------------------------

The `Modular Graph` in modular development is a resource that runs through the engine runtime. The engine will automatically acquire the required modules according to the content of this resource, and load them according to the defined rules. Therefore, the process of building a modular application is as follows:

1.  Obtain modules from the module repository.
    
2.  Rewrite or develop modules.
    
3.  Upload new modules to the module repository.
    
4.  Generate `Modular Graph`.
    
5.  Publish the engine runtime library and `Modular Graph` as an application.

---

*Originally published on [Spike](https://paragraph.com/@spike-6/spike-engine-introduction-to-key-technologies)*