Germano123 / mobagen

MoBaGEn - Module Based Game Engine - Educational tool to teach game programming concepts

MoBaGEn

MoBaGEn - Module Based Game Engine - Educational tool to teach game programming concepts.

Join us:

Metrics:

CI:

Try online

Before checking it online, some demos are intended to be implemented by you. So most of the demos would looks like empty;

• Empty demos.
• Flocking demo for this AI class.

Want to showcase your work here? Create a pull request.

Do you like it?

Motivation

• Act as functional game engine to teach and use as base for presentations;
• Don't want to recreate all game engine stuff, glue them all. "Life es too short to build a game engine from scratch";
• Have full control of all the processes from code to the delivery;

Follow me!

Did you like this project? Follow me on social medias

Why C++

• Has many solid, well maintained, efficient and stable libs;
• It speaks straight to hardware, you can do whatever you want;
• It is portable.

Why CMAKE

It is the best all-around solution to:

• Create projects cross-platform
• Configure variables and flags
• Build complex projects in easy way
• Most relevant libs supports it

Why CPM

• Best package manager to import and use third party libs from source code with low maintenance code.

Architecture

Please refer to this doc.

Restrictions

• If a library do not easily compile on all supported platforms, we won't use it.
• Use consolidated libs and do not reinvent the wheel (only if is strictly needed)
• Start small and make small steps towards the goal.
• Always make everything lib interaction swappable as good as we can.
• Never use any lib on the core code. The core should interact with the libs through a glue code. Ex.: core lib -> physics module -> bullet physics engine
• Target the latest C++ version that is portable to our targets(iOS, Android, Windows, Linux, OSX, WEB). compiler support table.
• CI should be able to build to all targets at once.

Essential Modules

• Core
• Job/Task Module
• Resources Manager

Optional modules

• Graphics
  • 2D - Needs to not rely on SDL_Renderer anymore
  • 3D
• Physics
• Sound
• Networking
• Scripting
• GUI
  • ImGUI via 2D renderer - needs to become agnostic
• Input
• Game Components
• Scene
• Logger

Todo List

• Image Editor Application
  • Design Editor similar to Slicer3D
  • DICOM loader
  • 3 viewports synced with exam data
• Game Editor Applications
  • Compilation of scripts
  • Execution of scripts within their respective contexts
  • Manipulation of variables within script contexts
  • Support importing and exporting compiled scripts