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 the following policy (very similar to zig's):
- No LLMs for issues.
- No LLMs for patches / pull requests.
- No LLMs for comments on the bug tracker, including translation.
- No generative AI models for other assets. (For example icons.)
- English is the main language of the issue tracker, but I can also speak Hungarian.
You can write in your own language, but if you can, include an english translation as well.
- For translation you can use traditional tools. (Yes, these use neural networks, but these are
not LLMs. They also only use fraction of the power and compute.)
- For example here's a FOSS one, thay you can even run locally. (Should work on raspberry pi tier hardware): libretranslate.
- For translation you can use traditional tools. (Yes, these use neural networks, but these are
not LLMs. They also only use fraction of the power and compute.)
A strict no breaks policy would be ideal, but unfortunately that won't work for a project of this type.
Breaking changes can (and will) happen, but their rate and impact should be minimized as much as possible.
- Nothing.
- Fix up docs for PScrit. Make sure to cherry pick it to the previous branch as well.
- Update docs for GDScript, add the new features to it. Make sure to cherry pick it to the previous branch as well.
- Add a CI build script using the build containers.
- Add a nightly build name variant to the build all script.
- Add a script to automate nightly generation. (I found 2 old ddr4 memory sticks lying around, and with that I was able to build a good enough computer that can do nightlies and CI.)
- Try to setup an editor again, and fix PScript's lsp.
- Double check all of GDNative's api, fix everything if there are more issues, and call it stable.
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.
Likely this will end up being c++11 with a relatively strict coding guideline, that starts with banning the use of stl outright.
I'm not too fond of the c++03's template in template syntax thing, and this gives move constructors, which is a nice optimization. Also it gives in class variable initialization (no need to only use constructors), but if a constructor is present, it should probably be the guideline that it's the only thing to init variables.
I'm pretty sure some of the thirdparty dependencies need c++11, so at least that would be solved as well.
Old description:
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).
Now that the engine has TypedArray, it' would probably be a good idea to also have a TypedDictinary.
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 relatively 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.
Set up a git mirror on the engine's domain as well, not just on my personal page.
Also should probably migrate from gitea eventually, as they seem to be using llm-s for coding a lot now, and I'd prefer if they don't blow up my server with low quality code after doing this for the next few years.
Forgejo seems pretty good for now, or I could probably throw something together (or port something) eventually.
Add multi window support for the engine.
Being able to open more windows should only add very little code and practically zero complexity by itself.
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.
Likely the proper solution:
Have an another set of popups in an engine module, so they can be disabled if not used.
WindowedPopup etc...
Have them inherit from Window, if windowing is enabled, and Control if it's disabled, So no performance penalty on platforms with no windowing.
Could force windowing support for them to be disabled at compile time even if a platform can do windowing.
Their api does not need to match the built in popups exactly.
The implementation should probably be in the demos repository for easy customization.
Since this can be done lots of ways, the best way I think would be to make it abstract, and implement tiny bits.
- Render a page.
- Ask for email.
- Call virtual, or fire signal.
- Try to render success page.
And just print error in the default implementation.
The User class should probably have an is_email_valid property.
An UserEmailValidationCheck Middleware could be added.
Maybe an extremely simple git integration could be added to the editor.
Godot has something like this, but it's more like a VCS integration with a module that adds git support.
This could be a lot simpler. A commit gui, and some simple history gui. Probably around a few hundred lines of code.
If helper methods that are not yet available but needed are exposed would also allow for other vcs integrations even using addons.
There are already ways to get the socket itself out from the web server, so websockets are already possible, but need a few demos to see it the current api is good enough for general use. If not add helpers as needed.
Maybe compression could be added. At least the algorithms that are already available in the engine.
It was never too difficult to convert GDScript to engine side c++, but with PScript it's even easier to do.
A special build could be done, which only enables properties on objects for serialization, and no other methods.
Something like a no_scripting=yes option.
It should set a NO_SCRIPTING define.
This would reduce the executable size by quite a bit.
In the editor the docs could be simplified in this case -> no need for methods, only node descriptions.
The editor would work too, so assets can be assembled the same.
But everything that's scripting only in _bind_methods() need to be wrapped in #ifndef NO_SCRIPTING.
What's more problematic is that in the editor build everything the editor uses for undo / redo needs to be enabled,
so probably an another define should also be added. Something like #ifndef NO_SCRIPTING_TOOLS.
Note that it should use be #ifndef, so incorrectly setup ide-s don't make most of those lines grey.
There should be more scripts making building + handling custom export templates easier.
Swt up a container build script that builds an editor for all platforms.
A built-in simple 2D software renderer would be nice to have for gui apps.
MESA has a full monster software renderer for gles2, and it also works really well, so something simple should be enough.
A another, simpler gles3 renderer wouls be nice to have.
One that works more like the gles2 one, that does not really need too much features.
Other rendering backends would be also nice to have.
They don't need to be extremely complex and scriptable.
slCreate() was deprecated in the current android NDK, update the code eventually.
Implement some kind of shader caching, or pre-compilation feature. (Ideally both.)
They could be (amonngst other things) recorded and saved to a file (shaders, and their defines), and then loaded.
Binary shaders could also be saved, and then loaded on demand.
The Inverse Kinematics system has some bugs, those should be fixed.
Also it will probably need some api and usage improvements.
I just noticed that scons is getting the ai treatment very hard. I see lots of co-authored by claude...
So seems like the clock is ticking, things are likely to break eventually.
Fortunately I have been thinking about removing scons as a dependency yeas ago (SCSCons folder was one of the experiments to not have to rely on scons being installed). I guess I'll need to continue working on this.
If I have to rework a build system I'd prefer to not depend on constantly changing technologies. I don't need that for job security, I don't have time for that.
I see a few ways realistically:
- Use the engine's scripting language itself
- Either an older SCons could be ported to GDScript.
- Or a new build system could be written, that's similar enough to SCons so it's not that much work to port everything.
- Obviously this would be the most ridiculous (and probably needs the least amount of work) out of all of these, but engine needs to be bootstrapped on new platforms, which would be annoying.
- Use sfw to create a simple single cpp build system for the engine.
- Create something similar to sfw but it's a build system.
- Create a simple scripting language (or take PScript for example) using sfw, and just use that for the build.
- Use an extremely portable scripting language like lua or python directly. Lua would be preferable, as it's very stable, but I don't like the syntax that much. Python is annoying because it's ever changing, but it's syntax is better.
- Fork SCons, publish it on pypi and just use that. If I have to fork I'd rather also get rid of pypi as a dependency too.
- Continue with the SCSCons built in scons thing, so it doesn't have to be installed anymore.
Note that other traditional build systems will not work, there are a bunch of failed pull request in godot's repository as a testimony. Most build systems are made for way simpler projects.
Eventually set up a local CI which would actually build for every supported platform, could also use it to build and make nightlies available.
Note that I would have already done this if the American AI clownpanies wouldn't have gone berserk and screwed us over with hardware prices, but it will be done eventually.
- 4 vertex mesh. This would allow for arbitrary shapes.
- splined mesh? Spline on 4 sides?
- N vertex mesh.