Makai Game Engine

Table of contents

• Overview
• Supported Operating Systems
• Requirements
• • Windows
• How to Use
• • Note
• Libraries Used
• Documentation
• TODO
• • Future

Overview

This is (currently) a header-only C++20 bullet hell engine, that utilizes SDL as a rendering and audio backend.

Currently in active development.

Enough spaghetti (code) to put an italian restaurant out of business.

Supported operating systems

• 64-bit Windows

No plans to support 32-bit systems.

Requirements

Windows

• GCC via MinGW (MSYS (Recommended), Cygwin, TDM-GCC) (DOES NOT SUPPORT CLANG)
• Make
• 7-Zip command-line (Recommended) or zip command-line
• RSync

If using MSYS, all of them must be installed via pacman:

For toolchain (GCC): pacman -S mingw-w64-x86_64-toolchain
For make: pacman -S make
For zip: pacman -S zip
For 7-zip: pacman -S p7zip
For rsync: pacman -S rsync

In a single line: pacman -S mingw-w64-x86_64-toolchain zip p7zip make rsync

How To use

1. Create a C++ source file within the build/ directory (create directory if nonexistent);
2. Add #include <makai.hpp> in your source file;
3. Program your game (TODO: Tutorial and Documentation);
4. Open root directory on command line (MSYS MinGW64 or Cygwin, if you're using it);
5. Compile with make (TARGET) [src=PATH_TO_YOUR_FILE.cpp [name=YOUR_PROGRAM_NAME]] (See notes for more detail);
6. Done! Your compiled program should be within the res/ directory.

Note

For more information, type make help.

The src only needs to be set if your file is not at the top of the build/ folder or not named main.cpp.

Any resource files that the game uses MUST be placed inside the data/ folder in the res/ directory. If the folder doesn't exist, create it.

The data/ folder gets archived during the packing procedure, if no-archive is set to 0 (default) and the target is not pack-debug. This allows the folder to be compressed and encrypted, ensuring security.

Any subsystems that the game uses can be placed inside the subsys/ folder in the res/ directory, for organization purposes. If the folder doesn't exist, create it.

The subsys/ folder does not get archived during the packing procedure, so it is recommended to be used for stuff that must be loaded unarchived.

Libraries used

These are already included in the lib/ folder.

Name	Purpose
SDL	Window & Input handling
OpenGL	Graphics backend
SDL2_Mixer	Audio backend
stb_image	Image loading
cute_c2	Collision
nlohmann::jsoncpp	Multiple things
cppcodec	Data encoding & decoding
CryptoPP	Encryption, decryption, compression & decompression

Documentation

Currently VERY scarce. Some of the code is commented.

TODO

Current

• Separate itembox and grazebox
• data/ folder packing system
• "Optimize" GPU usage
• • Instead of rendering every layer from the layerbuffer to the framebuffer, maybe implement sublayers?
• • ( ) A: Group every X layers to be rendered by clearing the depth bit in-between layers
• • • • Would play nicely with the sublayers in gamedata
• • • • Would still be somewhat resource-intensive, but not as much
• • (x) B: Create special functions to tell the system when to render the layerbuffer to the framebuffer
• • • • Would be called in the onPreLayerDraw step
• • • • Would also play nicely with the sublayers
• • • • Would also be the fastest, but more complicated on the end-user
• • • • This one would also play nicely without messing the current rendering pipeline too much
• • It is now up to the developer to figure out when to render their own layers, or to just just leave it like the old system
• Implement a framebuffer push-pop stack system, perhaps?
• • On second thought, this might be a stupid idea. Or not
• Replace .ini-based savefile system with a different format
• • Using JSON
• GUI system
• Menu system
• Dialogue system
• Curvy/Bent lasers
• Bugs & Errors (see Issues.txt)
• File format implementation (These need better names):
• • For more info, see the specifications folder
• • Material configuration definitions
• • • ObjectMaterial
• • • WorldMaterial
• • • BufferMaterial
• • Renderable object definition
• • • Mesh Parser
• • • Transform Parser
• • • Material Parser
• • • • Requires ObjectMaterial definition
• • Animation keyframes definition
• • Danmaku stage layout definition
• • • Possibly via combining 2nd & 3rd implementations
• Custom language (compiled (preferable) or interpreted)
• • Currently have an idea, don't know if it would be feasible
• • Could also implement support for Squirrel/LUA/AngelScript

Future

• Other game types
• More "multi-purpose" game classes
• Cleanup & polish entity system
• (Maybe) replace JSON to other specification
• • For the custom file formats, that is
• • See File Format Alternatives for more informaion
• Multi-platform support:
• • Linux

Major refactor

• Cleanup & polish graphical system
• Cleanup & polish audio system
• Replace raw pointers with smart pointers (see referential.hpp)
• Remove or replace $ macros
• Reorganize and remove haphazardness/mess
• "Async"-ify tasking system (see asynchronous.hpp)

Under consideration

• C++20 modules?
• Rename stuff

Very far future

• Vulkanize graphical system (VERY DIFFICULT, might not be done)