This game engine started out as my first video game, but since the project kept growing, it ended up splitting into a game engine and a video game. So, here is my game engine code, as I'll keep my video game stuff private :) Checkout the roadmap below to see what's in store!

• Roadmap for NP-Engine found on Trello
• Building is done with CMake. All dependencies are submodules (under the vendor directory) except for Vulkan, so install the Vulkan SDK. (Linux might require libgtk-3-dev or more but check the CMakeFiles.txt.)
• Goals/Features/Baseline of this engine:
  • Support for Windows and Linux (latest Debian). Official support for Apple is deferred.
  • Detailed memory management. (I aim to use vendors that I can pipe memory management through my own stuff.)
    • Types of allocators:
      • Red-Black Tree (efficient general-purpose)
      • Implicit List (efficient bookkeeping, but allocations are a minimum size)
      • Explicit List and Explicit Segmented List
      • Linear (allocate in a straight line until unable -- can only deallocate all)
      • Fallback (use the primary unless it fails, then use fallback)
      • Segregated (use primary for up-to threshold sized allocations, else use fallback)
      • TraitAllocator (uses a statically-registered allocator under the hood)
      • StdAllocator to tap into all std objects
      • CAllocator (the classic malloc/realloc/free we all know and love)
      • AccumulatingAllocator will use whatever type T allocator to give it under the hood, and will grow as your needs grow.
    • Templated Object Pools. These return smart pointers so you do not have to remember to deallocate/destruct objects. They will automatically go back to the pool when that smart pointer goes out of scope or is reset.
      • Accumulating Pool will continue to grow as your needs grow.
    • Smart pointer. Counters and object are stored in one contiguous block. Smart pointers come in the Strong Pointer (sptr) and Weak Pointer (wptr) variants. Strong Pointers act like the classic shared_ptr, and Weak act like the classic weak_ptr. No unique_ptr, just use Strong Pointer.
    • Delegates
      • Can call functions, methods, and capture-less lambdas
      • Provide access to a payload
      • Provide context to callbacks via an id value
      • Can return any type via template (all primitive delegates are provide i.e. BlDelegate, I32Delegate, FltDelegate)
      • lambdas with capture clauses will not be supported
  • Vulkan rendering - currently under heavy construction. (OpenGL and DX11/DX12 probably much later as means to improve our API).
    • Add list of features here
  • ECS via Entt
    • I am seriously considering forking Entt to force it support my own containers, which all use my memory management.
  • 2D Physics via Box2D with liquidfun's particle physics.
    • I will use Box2D V3 when it is available.
    • I will also improve the pressure solvers to probably IISPH or something that is better, faster, and more accurate.
  • 3D Physics via Bullet
  • A feature-rich JobSystem (task graph architecture):
    • Lightweight. Job submition is as small as an ui32, smart ptr, and boolean.
    • Power-efficient. JobWorkers sleep when no Jobs are available, and are woken up when Jobs are submitted.
    • Priority-based jobs: Highest, Higher, Normal, Lower, Lowest.
    • Braided-parallelism support: you can create a job anywhere, adding job-dependencies anytime.
    • Considerate of the main thread so thread scheduling does not throttle/crowd the main thread
    • Jobs can be directly checked for completion so the caller can easily know when a Job has completed.
    • JobWorkers can be directly assigned immediate jobs.
    • JobWorkers can steal their coworkers' next immediate job.
    • Jobs can be marked as CanBeStolen or not, just in case you want only a specific worker to execute a job. (Priority-Based jobs are stored in the JobSystem, so there's no concept of stealing them.)
    • Every JobWorker's list of coworkers can be customized any time.
    • JobWorkers pass their id into the Job they execute so the Job's callback can know which JobWorker is executing it.
  • A profiler that outputs a JSON file for Chrome's Tracing tool. (Type "chrome://tracing/" in Chrome's url.)
    • I am going to migrate to wolfpld's Tracy Profiler
  • Networking
    • Add TLS / cert stuff / etc
    • Add list of features here
  • A wiki (coming soon) for all documentation needs, including high-level examples. (I might make a separate repo for working samples.)

Note: This project is pre-pre-alpha. Tags will be implemented when the initial backlog is complete so you can navigate official versions of the engine. Until then, commits are liable to break the build.

Here is the internal dependency of how things are arranged. Everything is subject to change, and this is liable to be out of date.