DUE TO A HIGH NUMBER OF SPAM REGISTRATIONS, NEW ACCOUNT SELF-REGISTRATION IS CURRENTLY DISABLED.

If you want an account on this Gitea instance, join our IRC channel (irc.freenode.net, #octaforge; if you don’t have an IRC client, you can use https://webchat.freenode.net) and ask q66.

As of 2020/04, the OctaForge project has been restarted, for now experimentally.

What is it now?

The goal of the project is to build a game engine/framework based on http://tesseract.gg. This is not unlike the old project, however, this time, things are a little different.

Project organization

Newly, OctaForge is an umbrella project for several subprojects. The idea of providing a game hosting platform (like Syntensity used to be in the past) has been scrapped, at least for the time being, with focus being on the needs of the engine itself. Likewise, the builtin Lua scripting system has also been dropped.

Other projects may get added later.

OctaCore

Current status: Early experimentation

OctaCore is the actual game engine, derived from the Tesseract codebase. In the end, it’s meant to consist of the core engine itself, an editor, and a collection of core components to aid with game development.

libostd

Current status: Some components stable, preparing for initial release

This is a C++17 extension library to be used by the engine, but also third party non-game projects. It aims to complement the C++ standard library, adding new functionality (coroutines, concurrency, etc.) and replacing insufficient C++ standard library functionality (ranges, I/O streams, string formatting, etc.)

libcubescript

Current status: WIP, preparing for initial release

A standalone implementation of the CubeScript language, meant to be embeddable, clean, provide a safe and easy to use API, and useful in multithreaded environments. Originally based on the Sauerbraten CubeScript implementation, it has been nearly completely rewritten.

It will be used by the engine as a debug console and to provide a minimal, non-intrusive scripting interface.

Project goals

These are some of the preliminary goals of the project.

• Create a permissively licensed free/open source 3D game engine based on Tesseract
• Prefer simplicity over feature bloat, while still aiming to satisfy most people’s needs
• Modern, multi-threaded design based on lightweight tasks and ownership transfers
• Minimal dependencies and accessible, easy to understand codebase
• Clean separation of core engine, editor and game logic
• No builtin advanced scripting engine, C++17 API
• The engine will undergo a complete refactoring for this purpose, and functionality will be dropped and/or rewritten from scratch
• Entity component system
• Declarative, flexible, real-time handling of models and textures
• “Fat server” style networking and complete API-side control over the protocol
• An editor that aims to provide a good balance between the simple, builtin editor of Tesseract/Sauerbraten and more complete editors of other engines, while preserving cooperative editing functionality

More future goals include:

• A flexible volumes/materials system
• Physics engine integration with rigid body support
• More advanced particle engine
• Abstracted rendering system to allow eventual support for OpenGL ES
• VR support
• Linear space lighting/gamma-correct pipeline
• Better audio support

How do we get there?

Right now, the engine is in a refactoring stage. Tesseract has been imported, stripped down, and currently undergoing preparation.

1. All game logic has been dropped
2. Most server code has been removed
3. Audio support and SDL_mixer has been removed

Right now, the codebase is being refactored to have a strict single-header-file-per-source-file system. This will help clear up dependencies between things, and in turn, make it easier to drop more stuff. It will also improve compile times, but that’s besides the point.

Once that refactoring is done, the following will be focused on:

1. Drop as much of the remaining functionality as possible (e.g. UI)
2. Replace most of the provided utility code so libostd can be used
3. Drop the builtin CubeScript implementation
4. Take rendering engine, octree handling, physics and so on, move it into a library with a preliminary API
5. Make the remainder of the client (editor and so on) a user of the library
6. Keep iterating on it until we get to a stage where things start looking more like what’s necessary

All this is expected to take a while, don’t expect it next week. Once this is all done, other tasks can be started.