A 3.x Godot Engine fork where I hack and slash and cause mayhem and destruction to all things good and godot.
Similar idea going from godot 3.x to godot 4.x, but taken in a completely different direction.
Currently this engine is a weird amalgamation of godot 3.x, 4.x, and lots of custom features.
Most of the design decisions went into making everything simple for people that knows (or wants to know) what is going on.
It contains all of my currently in use engine modules.
See the changelog for a more comprehensive list of changes.
Pandemonium Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so that users can focus on making games without having to reinvent the wheel. Games can be exported with one click to a number of platforms, including the major desktop platforms (Linux, macOS, Windows), mobile platforms (Android, iOS), as well as Web-based platforms (HTML5) and consoles.
Pandemonium is completely free and open source under the very permissive MIT license. No strings attached, no royalties, nothing. The users' games are theirs, down to the last line of engine code.
Pandemonium's development is fully independent.
Before being open sourced in February 2014, Godot had been developed by Juan Linietsky and Ariel Manzur (both still maintaining the project) for several years as an in-house engine, used to publish several work-for-hire titles.
The Godot engine developers decided to remove the GLES2 backend in Godot 4.x so they can pursue the more modern graphics API-s.
After quite a while of thinking and experimentation however I decided that I still need (and want) the GLES2 renderer for my games, I also needed some of the new features from godot 4.x.
So in early 2022 I decided that I'll fork godot 3.x, and backport anything that I need for my games / projects. While here I also used the opportunity to modularize the engine more, and fix issues I had with it. I also added my engine modules to it by default, and ended up writing lots of custom things.
Keep in mind, that I'm not really an engine dev. Which probably sounds completely bonkers from someone who develops and maintains his own godot fork almost non-stop. What I mean is that this engine is being developed to be used by my other projects. This brings some downsides, as this project cannot openly accept anything that anyone wants (like other engines). Fortunately this has never been an issue, as I don't really try to get people to use this engine, but if this ever becomes a problem I'll create an official "community edition" fork, that is much more open to outside influences.
This being said, the engine actually tries to be modular as much as possible, while being also easily extendible, and as simple to understand and use as possible with a wide selection of platforms. All this without constraints that make building apps with the required complexities of today harder than they need to be.
You can download binaries from the github actions tab [here], or the releases tab [here].
See the official docs for compilation instructions for every supported platform.
The documentation is available [Here]. It includes all official pandemonium demos.
The class docs are accessible from the editor.
You can also look at the official 3.x Godot documentation, it will work mostly (sometimes with trivial modifications).
It's also worth looking at official godot 3.x resources, like this awesome Godot list, and there are also a number of other godot learning resources provided by the community, such as text and video tutorials, demos, etc.
Even though this engine is practically unknown, and it's not really getting patch submissions as of now (realistically it won't get submissions probably ever), to be on the safe side I'm adopting QUEMU's ai content policy.
Here is a copy in case it changes (Ignore parts that are irrelevant to this project, like DCO):
TL;DR:
Current QUEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.
The increasing prevalence of AI-assisted software development results in a number of difficult legal questions and risks for software projects, including QEMU. Of particular concern is content generated by Large Language Models.
The QEMU community requires that contributors certify their patch submissions
are made in accordance with the rules of the Developer's Certificate of Origin (DCO).
To satisfy the DCO, the patch contributor has to fully understand the copyright and license status of content they are contributing to QEMU. With AI content generators, the copyright and license status of the output is ill-defined with no generally accepted, settled legal foundation.
Where the training material is known, it is common for it to include large volumes of material under restrictive licensing/copyright terms. Even where the training material is all known to be under open source licenses, it is likely to be under a variety of terms, not all of which will be compatible with QEMU's licensing requirements.
How contributors could comply with DCO terms (b) or (c) for the output of AI content generators commonly available today is unclear. The QEMU project is not willing or able to accept the legal risks of non-compliance.
The QEMU project thus requires that contributors refrain from using AI content generators on patches intended to be submitted to the project, and will decline any contribution if use of AI is either known or suspected.
This policy does not apply to other uses of AI, such as researching APIs or algorithms, static analysis, or debugging, provided their output is not to be included in contributions.
Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content generation agents which are built on top of such tools.
This policy may evolve as AI tools mature and the legal situation is clarifed. In the meanwhile, requests for exceptions to this policy will be evaluated by the QEMU project on a case by case basis. To be granted an exception, a contributor will need to demonstrate clarity of the license and copyright status for the tool's output in relation to its training model and code, to the satisfaction of the project maintainers.
These are the planned new features. On top of this there will be lots of unplanned things, also improvements to the engine as a whole.
Currently the codebase is mostly c++03 with some c++11, and c++14 (std threading) sprinkled in.
I'm not sure whether it's just me getting old, or maybe it's just timing (I started with Libgdx + java 7, then went to Unity + dotnet mono 2.0, then Godot 3.1). I like this sipmlicity. It makes the codebase a lot easier to work with. It also simplifies the tooling required, which could come in handy in the future.
After lots of thinking, it's probably the best to just say the target is c++03 instead of writing some specification of used features.
There are 3 bigger issues (none of them are too bad though):
- Threading was modernized to use the std namespace, but it also introduced a nice way of overriding the default for a platform.
- Atomics were completely reworked. The old atomic calls need to be merged into the new api.
- Templates are a bit more strict:
Vector<Vector<int>>needs a space between the last>>-s:Vector<Vector<int> >. This can be done with reverting the clang format rules, and running it on the project. It will jutst create a big diff.
Other than this it will only need small fixes.
However some third party modules might need higher c++ standard. At first they will just get it. Then we'll see.
Note that this would only be an extremely minor break, and only for engine modules. Also they would only need to specify a different c++ version in their SCSub file (for which there are plenty of examples).
Implement and enable CScript. CScript will be a scripting language similar to gdscript, but it will use a C-style syntax.
It would be extremely cool if it could just interpret engine module c++ directly, but that might be a bit too much. Maybe that could be an another module. For this to work, solving .cpp and header file separation are the biggest problem in my opinion due to how the engine works internally. Other than this it's mostly just parsing (not trivial, but relatively simple in the grand scheme of things). (Note that having the codebase use c++03 also helps with this!)
A RichTextLabel, but for markdown would be nice to have.
Since now the docs are in markdown, if the MarkDown label is implemented the docs could also be read directly using the editor itself.
Obviously it will need to be pointed to a folder, as the docs are quite big, but it would be realtively trivial to implement.
Also it could host to a web browser using the HTTPServer. (The docs repo has a demo that does this already. It's like 200 lines of code.)
Figure out how to build a working container to the UWP backend, fix it, and add it to the release.
All engine modules by default could support being built as a shared object (= dll). This can save with iteration time when public apis don't change.
Keep in mind, that this is already implemented for some modules, but would be nice to have as a core feature.
The GDNative c++ binding rework should be finished. It could also make module development a lot simpler if it's api is extremely similar to the engine's.
It's project setup should also be simplified.
Also GDNative should probably have an api that can register classes without creating resources in the project.
Setting up a separate vps for the website would be nice, instead of the current domain redirect. It should also mirror the engine specific repositories and the release zip-s.
It should also look at least acceptable.
Add multi window support for the engine.
Should oly add very little code and practically zero complexity.
The issue is popups. Inheriting them from a Window (Viewport) class is incredibly inefficient, and custom handling for them will be extremely messy. A good solution for this is going to be needed.
Currently my best idea is to have 2 sets of popups, and the user can decide whether to have multi window support or not by using the proper ones. Still trying to figure out a way to make this simpler.