project_misth/notes.md

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 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 element can be one of,
    • A basic geometric shape
    • A text, with localization codes and text db
    • An image
    • A game world
    • 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,
  • they can be scoped with lifetime rules for tighter control and avoiding a event mess

• 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 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 entity to create maze maps but also just usable for anything.

• 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)
       • 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. Controlles
       • Can be used to connect a script to run on every game loop for this object (delta based)
       • 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

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

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

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