project_misth/writeup/analysis.md

# Outline

# Analysis

## What is a game engine?

The goal of this project is to build a high performance cross-desktop game engine for 2d games,

When a developer wishes to build a game they generally have 2 options, either they can code the entire game themselves by using a pure rendering library and handling all the assets etc. themselves, this gives them a lot of control over how the game behaves and can usually also allow them to do a lot of optimizations specific to their idea, but it means they will have to make the coordinate systems and data store, asset management systems etc. all by themselves, on the other hand they could use a game engine.

the most significant advantage of using game engines when building a game is simplifying development process.

They do this by allowing the developer to do a lot more out of the box without having to reinvent the wheel themselves:

- They allow making the game only once but having it work crossplatform on multiple different types of systems
- They allow asset management of game asstes like images, textures, audios etc. without the need to ensure a uniform format and loading them or decoding them manually
- They also usually have built in physics engines for the coordinate system, which do not need to be reimplemented with al that math by the developer, and these are done in optimized hot loops for greater performance.

The engine is expected to be built in a low level context (for high performance), but allow using it from a high level simpler environment without losing any of the performance. It should also make the development process of a game easy with any common parts for games implemented and reusable.

^ Kin, Wong (2024). Game Engines: Revolutionizing Digital Creativity Across Industries. International Journal of Advancements in Technology, [online] Available at: https://www.longdom.org/open-access/game-engines-revolutionizing-digital-creativity-across-industries-1100970.html [Accessed 13 May 2026].

## Why use computational methods

The same fifty-two cards in a deck can be used to play a bunch of different games by slapping on a new set of rules each time, it is a platform for making and playing games on, similar to what a game engine does. But unlike the standard deck the digital game engine can be used to make much more complex games with way more rules as it doesn't require for the human to keep track of all the different things and how they change every round. This involves maintaining states of hundreds of objects every frame and running tens of such frames every second to give a real time continous input and output. They are still used in a similar manner where the same game engine can be used to make many games by slapping on a new set of rules (systems) & assets. This problem is therefore much more useful if done by using a computational aproach because the engine handles way more entities and objects and their movements, rendering, collision, other custom logic etc. continously. Making it perfect to express such a system algorithmically. Also similar systems exist like godot, unity etc. that use a computational approach to give much more interactiveness to games.

## Pre-existing solutions

Here we look into other similar systems (godot, unity) and a framework gosu

For godot we can see their own docs^
Godot uses a node-scene system where scenes are a saved file of a tree of nodes that can be reused throughout the project.
Scenes are like reusable templates for defining soemthing in the game, for example an entity or ui or whatever.
Scenes can also contain other scenes as nodes in themselves allowing for a nested structure.
Nodes on the other hand are the building blocks that actually contain the logic or data, each node has a type and every type has a specific use case and godot ships with tons of these.
For example, the sprite can be a node, the audio controller another, or the shadow overlay etc.
Scripts are behaviour attachable to a node which makes them work, they can be set to react to game events or inputs or per frame, etc.
They extend a node's behaviour.

So in godot you first define the blueprint, the structure of the game using the ui (or the markup files), and then attach scripts to the nodes to extend their behaviour and actually make them work, these scripts can intercommunicate using events.

Then the godot runtime extracts these scenes and builds the node tree out of them and runs the scripts attached to the loaded nodes.

these scripts are generally written in gdscript which is an interpreted language that is prcompiled to bytecode when the project is built and later on is executed by a runtime-VM.

Godot also has it's own gpu shader system and language. This simplifies shading for a lot of game developers who can stay in their comfortable godot environment and still use shaders.

Godot also provodes tons of inbuilt nodes for common stuff like auto-tiled tilemaps etc. which could be achived by coding the system in with a script but makes it easier for developers.

This makes godot very popular amongst new developers as it has many stuff out of the box.

Next we can take a look at unity:
Unity is primarily GameObject + Component based, with DOTS/ECS as an optional data-oriented system for performance-critical use cases.
but we will focus on their ECS system in particular here.

An ECS systems has 3 very interconnected parts:

- The entity is on its own just an ID and contains no actual data, just a list of what components it has.
- A component is a block of data of a predefined structure, components can be connected to entities, the actual structure is shared amongst all components of a type but each entity gets its own data pool for that compoenent.
- A system is a script that applies logic on a component type, it modifies / reads the data from all compoenents that exist for a component type irrespective of what the entity for it is.

This allows for a very good optimization, the components of a single type can be placed in a single block of memory and operated on at once irrespective of what the entity owning it is. This very greatly improves cache locality.
If the data was attached to the entity itself then every frame when an entity has to be worked on for example a collision calculation if was done by using position data from each entity which owned its position and size data the CPU would have to load all the other irrelevant parts of the entities data for each and every entity slowing things down by a lot.

This makes ECS systems very good for high performance systmes.

And finally we can look at a framework for ruby called Gosu:
Gosu is very different from unity or godot in that it is not a full engine but more of being just a framework, and is shown here to show how the planned project will be a full engine and not just a library,

Gosu is meant for building 2d games in ruby and provides a much more low level interface than godot or unity.
It is primaririly a ruby library for rendering and input capture.
It is very good for fast prototyping as it has very simple methods and uses ruby which is very good for fast prototyping (see next sec).

But it does not have a scene or nodes or object system of it's own, all such systems are to be implemented by the developer themselves, and while it provides methods for loading and using of assets they still need to be managed manually. This comes with the up that the developer can chose what kind of system they want to use.
It also requires the ruby runtime and the full source code when sharing making it less than ideal for any production games.
Also any kinds of GPU shading requires the OpenGL libraries to be used directly and it provides no proper access to them.
As per their own homepage: Gosu is mainly used to teach or learn Ruby.

Comparisions of architectures:

- Data layout
  - In the node based system that godot uses each entity (node), stores all it's data in a single object
  - This means that when an object is to be worked on it can be used from a single place. It also closely follows a OOP like idea meaning it is simpler for developers more used to it.
  - But it creates cache locality problems for example when the physics system wants to move all elements forward, each object will have to be loaded and then updated and as objects do not have to be together in memory it causes a lot of access overhead.
  - On the other hand ECS systems (like the one that can be used in unity), seperate pure data (compoenents) from the entities.
  - This means that when a system wishes to work on a single kind of compoenent it can use tight loops to leverage performance gains from cpu cache locality.
  - It also scales very well for having way more entities as entities only use up space for the compoenents they require.
  - But it is also a much more complex mental model for the developer to work with.
- Behaviour control
  - In godot the bahaviour is very tightly attached to each node, and when executing the game the behaviour of each node is run fully before going on to the next, this means that similar behaviour like physics is recalculated for each node seperately
  - While in unity most scripts are global systems, these systems can bulk operate on data making them better at potential multithreading or cpu optimizations.
  - but they require ore boilerplate code as logic has to be filtered down to apply to the correct nodes manually rather than by vrtue of existing on a node.
- While in a more simple framework like gosu these are all dependant on the developers implementation.

^ Gosu. (n.d.). Gosu Homepage. [online] Available at: https://www.libgosu.org/ [Accessed 13 May 2026].
^ Unity Docs. (n.d.). Unity Entity Component System concepts. [online] Available at: https://docs.unity3d.com/Packages/com.unity.entities@6.5/manual/concepts-intro.html [Accessed 13 May 2026]. See sub-links.
^ Godot Engine documentation. (n.d.). Overview of Godot’s key concepts. [online] Available at: https://docs.godotengine.org/en/stable/getting_started/introduction/key_concepts_overview.html [Accessed 13 May 2026].
^ Godot Engine documentation. (2026). Godot’s architecture overview. [online] Available at: https://docs.godotengine.org/en/stable/engine_details/architecture/godot_architecture_diagram.html [Accessed 13 May 2026].

## Embedded scripting

This engine does not use a UI builder. And so all gameplay logic, entity behaviour, definitions etc. must be implemented directly through code.
Because of this it is important to use a well established language in which the developer can write their code.

Embedded scripting languages are programming lanaguges that are designed to be embedded in a host programming language. The embedded language is often an interpreted language which the host is a compiled static typed language. They allow adding code to the program that can be modified and interpreted at runtime. They are often used to extend on the functionality of the host language. And they also allow using functions defined in the host language which are usually much more performance optimized.

They are usually very lightweight (so that the final binary doesn't get bloated and runs fast enough). They are very useful for cuztom DSL/syntax.

And according to [this aticle](https://caiorss.github.io/C-Cpp-Notes/embedded_scripting_languages.html) they are particularly useful for game engines.

We can also see a list [list](https://dbohdan.github.io/embedded-scripting-languages/) of embedded scripting languages that exist, common ones being Lua, javascript variants, squirrel, and ruby variants (mruby in particular).

These all have a C-ABI, meaning they can be used by almost any compiled language.

The author [here](https://caiorss.github.io/C-Cpp-Notes/embedded_scripting_languages.html)

^ Rordrigues, C. (2023). Embedded Scripting Languages. [online] caiorss.github.io. Available at: https://caiorss.github.io/C-Cpp-Notes/embedded_scripting_languages.html [Accessed 13 May 2026].
^ Github. (2022). Embedded scripting languages. [online] Available at: https://dbohdan.github.io/embedded-scripting-languages/ [Accessed 13 May 2026].

## Target users

The target users for this project could be one of 2 categories:

1. Game developers

- The engine can be used by game developers to create high performance games quickly.
- The games are also built cross-platform meaning they can use the same project to export for different kinds of users.
- The standalone output of the game engine means they wont have to worry about sharing multiple files and makes releases easier.
- And for my own games it would help create a unique brand image for my games, it also helps out with any potential licensing issues with using external engines in my games.

2. Educators

- The game engine can be used by educators to teach programming / game development to students without making them build all the systems from scratch.
- Using such an engine means that the students could be taught about paradigms like ecs and OOP in a simple environment.
- They would also be learning ruby, which is an arguably very good for rapid prototyping due to its forgiving and highly readable syntax.

## Survey

Survey:

In order to help me gauge what my users would like,

we'll be splitting the survey into 2 sections, one for indie developers and one for educators

### Survey: Game engine

1. Are you a game developer or are teaching game development to others?
   - Game developer
   - Educator
   - No

#### Game Developer:

2. What level of experience do you think you have with game development?
   - Beginner
   - Intermediate
   - Advanced
   - Expert

3. Which game development tools do you currently use?
   - [ ] Godot
   - [ ] Unity
   - [ ] Unreal
   - [ ] Pygame
   - [ ] Gosu
   - Other

4. Would you put more focus on development ease or runtime performance in a game? (1 for development ease and 10 for runtime performance).
   - 1-10

5. How important is it that the engine supports scripting in a high-level language? (as opposed to compiling againts it as a library)
   - Extremely important
   - Somewhat important
   - Neutral
   - Somewhat not important
   - Extremely not important

6. What is your biggest frustration (if any), with game engines you currently use?
   - Open question

7. What systems would you consider very important to be inbuilt a game engine? (Like physics, localization, persistence etc.)
   - Open question

#### Educator

2. What subject do you teach?
   - Computer Science
   - Game development
   - Programming
   - Other

3. What level of students do you teach?
   - Middle school
   - High school
   - University
   - Other

4. What tools do you use for teaching game development?
   - [ ] Godot
   - [ ] Unity
   - [ ] Unreal
   - [ ] Pygame
   - [ ] Scratch
   - Other

5. What is more important when teaching?
   - Concept simplification
   - Technical depth
   - Industry relevance

6. How important is it to make low level work (like memory management) obvious when teaching new students?
   - Open question

7. What do students find particularly difficult to learn when using game engines?
   - Open question

   ***

## Results

Summarization of survey results and its limitations

## What more is needed?

Other features that a game engine should have

core:

- app, defined with fixed heght/width and aspect ratio is maintained with letterboxing, and fps

- scenes
- elements in scenes (in screen coordinates)
  - ElementText
  - ElementRect
  - ElementImage
  - ElementWorld - (It is a view through a camera)

- The world has to have an ecs system buitl in it
  - components are type definitions (and thier instances are stored in cache efficient arrays)
  - systems use queries to select components (with filtering) and can perform bulk operations on them
  - entities - an id and position which can relate to compoenent instances

- The world can render everything in view based on camera, and everything inside here is in world coordinates

- shaders, layers on top of the world, (per world, not possible per entity)

extra:

- physics (forces, mass, movement and collisions)
- Localization
- keymappings (and settings)
- tilesets
- sprite system (tiled, animated, static etc.)
- 9 segment ui system
- audio playing
- network interface, with a lib to stream data rom & a server instance also built into the packer binary (should allow ruby scripting the backend)
- persistence store
- rng helpers
- tweening helpers
- layout system (with tree like grouping of elements that inherit transform of parent)
- video player (ffmpeg texture and audio streams) (requires ffmpeg at runtime)

- super simple neural network system (with training and runtime phases) (if i have enough time)

## Embedded scripting language choice.

Why ruby is great for development for the runtime of this engine:

- Dynamic typing. it has almost no type declarations on variables, and duck typing means any object with particular behaviour can be treated the same.
- Expressive syntax. ruby has one of the most expressive syntax that improves code readability by a lot, it allows operator overloading, very clean dsl structures, minimal puntuation neccessary, and a lot of syntactic shortcuts.
- Very rich standard library. the ruby std lib has a lot of helpers for json, sockets, networking, file management, multithreading, regex etc.
- It also has a lot of inbuilt datatypes with helper methods that allow doing a lot of stuff. it has integers with no hard maximum, floating point numbers, strings and arrays, but it also has symbols, hashmaps and regex etc. for much faster development.

And as its official website itself states, ruby is easy to write, easy to read with natural syntax like spoken language.

> Ruby's expressive syntax allows you to write complex logic concisely. By leveraging powerful features like metaprogramming and blocks, you can reduce repetition and focus on solving core problems. With rich testing frameworks, you can maintain quality while achieving rapid development cycles.

> Ruby has a simple and intuitive syntax that reads like natural language. By eliminating complex symbols and verbose constructs, Ruby's design philosophy allows you to express what you want directly. With minimal boilerplate and high readability, it's friendly to beginners and maintainable for experienced developers.

For these reasons and my personal familiarity with the languge i've planned to use ruby as the languge in which the game engine is written code for.
More specifically we will use the `mruby` version as it allows for embedding a lightweight ruby VM into our engine that can run the scripts without needing an external interpreter.

`Mruby` is a very lightwieght impleemntation of the ruby runtime and also supports semi-compiled bytecodes.
The engine could compile the developers scripts into mruby bytecode when building the application and when it is to be used the the mruby vm can run these bytecodes.

^ Mruby.org. (2026). mruby - Lightweight Ruby. [online] Available at: https://mruby.org/ [Accessed 13 May 2026].
^ Ruby (2019). Ruby Programming Language. [online] Ruby-lang.org. Available at: https://www.ruby-lang.org/en/ [Accessed 13 May 2026].

##

- then a draft one of the requirements with justification of each based on the previous sections

Requirements v1:

- A game loop capable of handling any max fps given to it.
- A scene system
  - A scene is a set of scene elements used to create it,
    - For example, a scene for menu, for game over screen, and most importantly, for the main game scene.
  - A scene element can be one of,
    - A rectangle
    - A text
    - An image
    - A game world
    - A pixel scripted element, for stuff like minimaps (called Surface).
    - A sdl command batch element, for something that batches a bunch of image/rect/text into one element. (Called Render)
  - each element has coordinates on screen and z ordering.
  - And they can handle clicks / keyboard events and have scripts attached to each or the scene itself.
- A game world is just the game world (everything is coordinates in the world map relative, and this object controls the camera), \
  and it can be defined as topdown or side (for z ordering rules).
  - everything is an entity
  - with specail entities for tiling spritesheets where a set of tiles can be defined and the engine will place the right kind of tile based on the scenario \
    (for example in a maze if i define a spritesheet with tiles for corner / edge peices and then tell the maze as a grid of cells with 1 for wall and 0 \
    for empty it will automatically place the correct tile from that list.)
  - and support for maze generation and solving algorithms, which can be used with tiling entity to create maze maps but also just usable for anything.

##

- then any limitations / problems that can arise with certain choices in that list and how i might tackle them or ignore them

- then specifics of what ill need to actually make this, like the libaries, languages & hardware ill use with reasons of why, can have a big section on stuff like explaining why i chose sdl3 for rendering, or mruby (mostly because of mruby precompiling and how i can prepack the engine into a single binary)

- and finally a rigid list of requirements of things it should be doing by the end with 2 priority levels and this time just the list and not any justifications this time