Analysis update

notes.md

@@ -101,19 +101,3 @@ Game Engine - With Mist a maze game
     which is a high level OOP interpreted langauge with a low learning curve due to its simple to learn syntax, and tons of helper functions for rapid development.
 - It could be used by educators for teaching game development basics to students and getting hands on experience.
 - This engine also indirectly effects the gamers, the end users as they are the ones to feel any performance costs when enjoying the games.
-
-# Analysis
-
-(an outline)
--> first i say what is teh kind of thing im making is (an engine and the core job of an engine) and similar softwares (godot, unity etc.), and then explain that doing physics calculations and controlling multiple objects in a virtual world etc. can be done using computers
--> then the kind of people it is meant for
-
-- teachers of about high school level can use it to teach students about game development and using ecs systems and even OOP or teh languge ruby (the engine uses mruby for teh games with the engine itself written in c++), and explain how they can use it.
-- indie developers, similar explaination but also teh fact that the engine is built to work crossplatform on desktops and also packs the final binary as a standalone (which can be very useful), and helps keep a unique brand image (+ normal stuff like high performance and ruby prototyping speeds for making games quickly and support for ecs and object oriented styles they could choose and audio and animations etc.), also include myself in this category and hwo it will also simplify licensing issues for myself.
-- and then a section of research into existing engines both ones with ui/without: unity, godot, gosu etc., by going into their specifics and how they manage systems liek unity's ecs system and godots object based, then like gosu and how it is much more minimalist and more like a library than a proper engine, and then parts of tehir architectures i like vs ones i dont, like the ecs from unity, or physics and shaders and animations / tiling and templates etc from godot, or ruby from gosu, but also stuff i dont like like gosu requiring a ruby runtime etc.
-- and then use the data from the previous section about possible choices in architecture / dev i have and then design a survey asking people (with 2 categories, education or game developers), and what they think about it, (in which alongside data i can explain a bit about the data being done on a very small scale possible issues with such data etc.)
-- then a little interview chat with an actual developer who's used godot a lot and what features of it makes them use it and what i should add more
-- 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 etc. ill use with reasons of why, can have a big section on stuff like explaining why i chose sdl3, or mruby (mostly because of mruby precompiling and how i can prepack the engine into a single binary - as im doin)
-- 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 or none

samples/main.rb

@@ -108,10 +108,8 @@ query = tag(:enemy) & component(:health, true) & anti(name("Trap Preview", true)
 world.system :health_regen, for: query do |match, dt| # no trigger means always
   # example of a simple health regeneration system that regenerates health for all entities with a health component
   healths = match[0]
-  healths.each do |health|
-    health.health += 1 * dt # regenerate 1 health per second, dt is the delta time since the last update frame, so this will regenerate 1 health per second regardless of the frame rate
-    health.health = [health.health, 100].min # cap health at 100
-  end
+  healths.add_scalar! :health, 1 * dt
+  healths.clamp! :health, 0, 100
 end
 
 trigger = [:place]

writeup/analysis.md

@@ -0,0 +1,151 @@
+# Outline
+
+- first i say what is teh kind of thing im making is (an engine and the core job of an engine), and then explain that doing physics calculations and controlling multiple objects in a virtual world etc. can be done using computers
+- and then a section of research into existing engines both ones with ui/without: unity, godot, gosu etc., by going into their specifics and how they manage systems liek unity's ecs system and godots object based, then like gosu and how it is much more minimalist and more like a library than a proper engine, and then parts of tehir architectures i like vs ones i dont, like the ecs from unity, or physics and shaders and animations / tiling and templates etc from godot, or ruby from gosu, but also stuff i dont like like gosu requiring a ruby runtime etc.
+- then the kind of people it is meant for
+  - teachers of about high school level can use it to teach students about game development and using ecs systems and even OOP or teh languge ruby (the engine uses mruby for teh games with the engine itself written in c++), and explain how they can use it.
+  - indie developers, similar explaination but also teh fact that the engine is built to work crossplatform on desktops and also packs the final binary as a standalone (which can be very useful), and helps keep a unique brand image (+ normal stuff like high performance and ruby prototyping speeds for making games quickly and support for ecs and object oriented styles they could choose and audio and animations etc.), also include myself in this category and hwo it will also simplify licensing issues for myself.
+- and then use the facts i learnt from the previous section about possible choices in architecture / dev i have and then design a survey asking people (with 2 categories, education or game developers), and what they think about it, (in which alongside data i can explain a bit about the data being done on a very small scale possible issues with such data etc.)
+- then a little interview chat with an actual developer who's used godot a lot and what features of it makes them use it and what i should add more
+- 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 etc. ill use with reasons of why, can have a big section on stuff like explaining why i chose sdl3, or mruby (mostly because of mruby precompiling and how i can prepack the engine into a single binary - as im doin)
+- 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 or none
+
+# 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:
+While untiy has historically used a object oriented aproach they are now phasing into an ECS system they call DOTS.
+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.
+It is mainly used to teach or learn Ruby.
+
+^ 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](https://dbohdan.github.io/embedded-scripting-languages/) 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
+
+Main questions:
+would you put more focus on development ease vs runtime performance?