Update analysis doc

writeup/analysis.md

@@ -1,17 +1,5 @@
 # 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
 
 ##
@@ -62,8 +50,8 @@ Godot also provodes tons of inbuilt nodes for common stuff like auto-tiled tilem
 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.
+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:
 
@@ -86,7 +74,23 @@ It is very good for fast prototyping as it has very simple methods and uses ruby
 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.
+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.
@@ -147,5 +151,63 @@ 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?
+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