project_misth/writeup/analysis.md

Outline

Analysis

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 teh 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.

What is 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 teh box without having to reinvent the wheel themselves:

• They allow making teh 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 teh 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 teh 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, W. (2024). Game Engines: Revolutionizing Digital Creativity Across Industries. International Journal of Advancements in Technology, [online] 15(6), pp.1–2. doi:https://doi.org/10.35841/0976-4860.24.15.318.

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.

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 teh 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 teh ruby runtime and teh full source code when sharing making it less than ideal for any production games. Also any kinds of GPU shading requires teh 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 teh 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 teh 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 teh 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 teh 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].

Why ruby is great for rapid 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. teh 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 ruby VM into our engine that can run the scripts without needing an external interpreter.

Mruby is a very lightwieght impleemntation of teh 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 teh mruby vm can run these bytecodes.

Other popular options for embedded languages include Lua (used by neovim & factorio), which is very commonly used in similar systems, but mruby seems to do the job well enough.

This list also shows other options we could have chosen for embedded languages.

^ Github. (2022). Embedded scripting languages. [online] Available at: https://dbohdan.github.io/embedded-scripting-languages/ [Accessed 13 May 2026]. ^ 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].

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 teh game engine means tehy 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 teh 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:

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

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

Are you a game developer or are teaching game development to others?

Main questions (developers): BG: what level of experiance do you think you have with game development? which game development tool do you currently use? (can choose zero or more)

would you put more focus on development speed or runtime performance? (0 for development ease to 5 for runtime performance)

how important is it that the engine supports scripting in a high-level language?

what is your biggest frustration with current game engines that you use?

what systems are very important to be inbuilt in a game engine?

Educators: BG: What do you teach? (like game dev specifically or cs or programming or other) what level of students do you teach?

What tools do you use for teaching game development? (if any)

what is more important when teaching?

• concept simplicity
• technical depth
• industry relevance

how important is it to make underlying architectures like ECS, OOP, etc. obvious when teaching?

what systems are very important to be inbuilt in a game engine to give the students some support?

Summarization of survey results and its limitations

Other features that a game engine should have (need to go in depth)

• physics (forces, mass, movement and collisions)
• Localization
• keymappings (and settings)
• shaders
• tilesets
• sprite system (tiled, animated, static etc.)
• 9 segment ui
• audio playing
• network interface
• persistence store

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

• 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