Introduction

Welcome to the documentation for the Micro Game Engine! This is a Rust game engine build to focus on teaching game development in Rust. For this reason, there are several things that it does a bit differently than other Rust game engines.

Here are some goals of the engine:

  • Implementing a game without too much complexity. Many other game engines contain a lot of structure that help you with a large project, but can often just add cognative overhead to smaller projects.
  • Shipping the engine alongside your game. If you use this repo as a template for your game, then you can (and should!) extend the engine to fit your needs. In fact, there are some things that are specifially missing from the engine for you to go implement yourself, you can read this chapter to find out more about that.
  • Get a prototype running in just a few hours. This engine is designed to make prototypes and toys. Ideally, you should only need to spend a few hours to get an idea up and running. After the prototype phase, you should really consider moving to a more robust engine. There happen to be a quite a few existing options!
  • Some batteries included, you choose the rest. This engine is designed to be a starting point for your game, not a complete solution. It includes some basic things like a window, input, and a renderer, but it doesn't enforce how you should manage your data. There are some chapters of this book that focus on that topic, and you should check them out to learn more about the theory.

Here are some non-goals:

  • It is not a general purpose game engine. This means that it isn't designed to solve every problem that many other game engines do. Some of the things it won't include:
    • Networking
    • Physics

Getting started

For the ease of not duplicating data (for now), this section can be found in the Micro Jam docs here.

Engine Fundementals

This section of the book will cover some everything that is happening under the hood of the engine. Because this engine is designed to be small, it shouldn't be too much to get an overview from top to bottom.

There are several different modules that the engine is split into. Each represents a different core system of what might be needed in a game, and each tries to encapsulate that functionality as much as possible. This means that if you are looking for something related to drawing, you should look in the graphics module.

Interfacing with the engine

To make use of the Micro Game Engine, you will need to implement the Game trait provided by the engine. The reason a trait is used here is that it allows the engine to expose a very simple API to the user, while the user can then go on to expand each of these functions however they like. Here is the trait's definition:

#![allow(unused)]
fn main() {
pub trait Game: Sized + 'static {
    const TITLE: &'static str;
    type SaveData: Default;

    fn init(console: &mut Console<Self>) -> Self;

    fn tick(&mut self, dt: f32, console: &mut Console<Self>);

    fn run() { run_with::<Self>() }
}
}

As we can see, there are three functions that need to be implemented.

The first is init, which is called when the game is first started. This is where you should initialize any data that you need for your game.

The second is tick, which is called every frame. This is where you should update your game state, and draw to the screen. Often, in other engines, this might be split into several methods. For example, you might have an update method, a draw method, and an input method. Micro Game Engine takes a different approach of just including all this data in one method, and letting the end user decide how and when to use it.

For the sake of simplicity for demos, some of this book's "design docs" are implemented by just filling this function with all this separate logic. In your game, you might want to split this up into several methods, or even several modules. However, that's an implementation detail that is up to you.

Design Docs

This section of the book takes a basic game implementation, and suggest some ways to tweak it to make it more interesting.

Here are a list of the case studies and their topics:

Pong - A simple 2D game similar to tennis

Topics covered:

  • Rendering basic shapes
  • User input
  • Simple game state

Design Doc: Pong

We've built a version of Pong to work within this engine. It's very rudementary, and doesn't include all of Pong's mechanics, but it has basic input and physics.

Mechanic tweaks

This section will highlight some ideas about what could be done on the existing mechanics to turn it into a different game.

  • Against the horde: Instead of a single ball, have a bunch of balls flying around the screen. The player can only move a single square paddle in both the x and y directions. The player needs to protect a zone in the middle of the screen.
  • Dodge the peeps: This time, the player is a single ball, and the goal is to dodge the other balls. The player can only move in the x direction, and can't move up or down.