104 lines
6.7 KiB
Markdown
104 lines
6.7 KiB
Markdown
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.
|