From a7fce6616d23fa7810ad66e0e34c045bd1ed8d8b Mon Sep 17 00:00:00 2001 From: Daanish Date: Wed, 29 Apr 2026 22:01:19 +0100 Subject: [PATCH] Plan uodates --- notes.md | 37 +++++++++++++++---------------------- 1 file changed, 15 insertions(+), 22 deletions(-) diff --git a/notes.md b/notes.md index bd44b72..8f1893d 100644 --- a/notes.md +++ b/notes.md @@ -7,38 +7,34 @@ Game Engine - With Mist a maze game - A high performance - low level game engine that provides abstactions for 2d games to be built on. - A scene system - - A scene is a set of scene components used to create it, + - 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 component can be one of, + - A scene element can be one of, - A basic geometric shape - - A text, with localization maybe? + - A text, with localization codes and text db - An image - A game world - - A block, which allows merging other components into a single unit. (can be used to implement HUD systems) - - each component has coordinates on screen and z ordering. + - A scripted element, for stuff like minimaps + - each element has coordinates on screen and z ordering. - And they can handle clicks / keyboard events and have scripts attached to each. - The bus - any event can be fired on the bus by any object and then used by other objects for actions like enemy attacking player or something, - - as the game "world" captures input, the bus can be used to forward it to other objects, or just propogated through "update" loop functions - they can be scoped with lifetime rules for tighter control and avoiding a event mess - - they need to be predefined in a centralized table for making debugging easier, but this can be optional. - 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 object (defined later) - - with specail object 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 \ + - 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 object to create maze maps but also just usable for anything. - - pixel perfect or anti-aliased modes + - 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. -- Every object is just a set of components added to it to form something in a game "world" - - An object joins together components to create an entity - - Some components could be +- Every entity is just a set of components added to it to form something in a game "world" + - An entity joins together components to create an entity + - Components are: 1. Body - Shape (Dynamic or static) - - light level - Mass, physics interactions - Coordinates 2. Spritesheet (state based or singleton)/(animated or static) @@ -48,10 +44,12 @@ Game Engine - With Mist a maze game areas within a bitmap image for each animation frame and the fps of the animation. 3. Render, only for those that dont use a Spritesheet - Can be used for rendering a box or other simple shapes / text for fine grained control, this is automatically handled if a spritesheet exists. - 4. Update + 4. Controlles - Can be used to connect a script to run on every game loop for this object (delta based) - 5. Event Subscription + - Event Subscription - Can be used to subscribe to global / scoped events in the game event bus. (input can be handled through this or in update) + 5. Light + - Light level info for fog light shader - In debug mode the collisions will be visible and other info like coords etc. logged for that game "world" - It will have a physics engine for physics calculations like collisions, velocity, friction, forces, los, etc. attached to the game world @@ -63,8 +61,6 @@ Game Engine - With Mist a maze game objects for firing collision events (for exmple checking if player collides with enemy) - it also has setting for adding gravity (added for side view games.), or defining friction force relative to a coefficient defined per object for texturing. - Calculations for interacting these objects in the world and updating their positions based on velocity / forces each game loop. - - Calculations for raycasting and testing if objects have line of sight. - - See if i can GPU accelerate los/raycasting. (and maybe use haskell for that bit, would be fun to show cross language c abi) - Lighting support for fog based systems and shaders for common scenarios like clouds / fog and api to create custom shaders - A light system to render torches/light systems @@ -78,9 +74,6 @@ Game Engine - With Mist a maze game - The scripting is done in mruby with most common ruby gems available. (the actual project will be in c++) - The scene can be defined and setup in a markup-style custom ruby DSL. -- Then components in the scene have scripts for components connected to it (like linking it to a do end block or class or smthn) - -- Maybe use ffi or libruby instead of mruby? - And special predefined scenes for menu / settings types with settings having predefined settings for keybinds used. - And the godot style project settings where we can define key value pairs with datatype for value that can be used as globals. \