Game Engine - With Mist a maze game

# What?

### The engine

- 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,
    - 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 basic geometric shape
    - A text, with localization maybe?
    - 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.
  - 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 \
    (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

- 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
    1. Body
       - Shape (Dynamic or static)
       - light level
       - Mass, physics interactions
       - Coordinates
    2. Spritesheet (state based or singleton)/(animated or static)
       - State based is for like player sprite can switch between states like facing direction etc.
       - It will have an api to load and manage game sprites with animations handled automatically.
       - The developer can define sprite locations for static and for dynamic a list of files or pixel \
         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
       - Can be used to connect a script to run on every game loop for this object (delta based)
    5. 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)
  - 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
  - It applies to all objects with collision bodies
  - It has a center property that explains where the objects center is relative to the shape, and the size of the shape
  - it has a mass which shows its inertia
  - And they can be static or dynamic, rigid is used for walls and dynamic is for player / enemies etc. \
    with an api to simulate a force on a dynamic object, with collision handling with other static objects to stop it and with other dynamic \
    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
  - With api to implement shaders for special effects
  - These are GPU accelerated shaders
  - owned by world

- An api for game "world" persistence. and generic data store.

- Normal classes / logic can be written outside and reused in the system.

- 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. \
  and interfaced through autogenerated settings scene, or hidden but used as globals internally.

- And as a sample game implemented using it I will make mist.

### Mist - A maze game

- The main focus of the game is to show off all features of this engine.
- It also focuses on maze generation and solving with choices to select different types of maze generation algorithms and solving ai for npc's
- The main game has 4 modes
  1. _Classic_ - A finite maze is generated on world creation and player has to fight enemies, collect resources / weapons and find the exit to win
  2. _Tutorial_ - A smaller map with basic elements and npc's for player to inteact with and tooltips for helping them learn how the game works
  3. _Infinite_ - A maze is procedurally generated as the player walks using predefined seeds and memory optimizations to allow storing such information, \
     the goal is to get as far from spawn as possible without dying.
  4. _Editor Mode_ - A mode in which teh user controls the map itself and can test out various maze generation algorithms and place npcs / rooms and tweak \
     game rules to create custom game scenarios.

# Who?

- This game engine is targeted towards basic to intermediate indie developers trying out 2d game development for 2d open world like scenarios with \
  physics etc. (in both topdown or side view mode)
  - They can use the scene editor to make scene setups for all the visible stuff in teh game and then write scripts for behaviour of it using ruby syntax, \
    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.