-
Notifications
You must be signed in to change notification settings - Fork 12
Home
- Architecture
- [Developer FAQ](Developer FAQ)
- Coding conventions
The Helion Engine is designed to be both extremely efficient at its tasks, very robust to prevent unexpected crashes, and most importantly aim to be as clean of a codebase as possible. This engine is proof that one can have readable and modular code while still outperforming every other competitor by unprecedented amounts as even in the alpha unoptimized phase of this project (as of writing it currently outperforms all other implementations by a factor between 20-30x, sometimes upwards of 65,000% faster on very large maps!).
The heart of the engine that gets the most attention is writing the cleanest code possible. It is critical to make sure that the code stays as readable and modern as possible so that we maintain the core principles of efficiency and robustness. To facilitate the cleanest code, we will stay on the bleeding edge of the language and incorporate all new features
Goals of the engine are to support a unified and wide array of editing, gameplay, and other components that unify all of the disjoint areas that require multiple programs to use. For example, someone who wants to make a map has to install a map editor, then a resource/lump editor, and target usually one specific port. If you want it to work with multiple people, then you need a browser and whatever other tools are necessary to coordinate your users. Further, almost all of these programs that exist currently are extremely buggy and unstable. The primary goal is to remedy all of these with a shared, lean, and modern codebase that provides all of the features (within reason) and more that do not exist and would greatly improve the quality of life for developers, modders, and end users.
It can be seen by the existing codebases for tools described above that their software is untenable. It's impossible for me to use resource editors without them crashing, hanging, or corrupting data. The latest updates to modern map editors change things for the worse, have buggy implementations, and focus on visual components rather than making the core features better for the end users. The ports that drive everything have bloated to sizes beyond recognition and use code that is extremely unfriendly to newcomers to read, horrible to debug, and every release is full of an unbelievable amount of bugs. The entropy of these codebases having upwards of 450,000 lines of code is too much for a person to keep in their mind, and to make matters worse it is all an interconnected cyclomatic complexity defying disaster due to pervasive use of global variables/functions, poorly written code, and no desire to maintain the code. This is also evident by how 'modern' ports are virtually almost nothing but bug fixes in their commit history. All of the above have led to massive problems with the current scene, which we hope to fix.
A lot of the core algorithms which people shy away from (such as BSP building, concave polygon triangulation with holes, rendering, etc) need not be confusing. While the low level guts of rendering in such things as OpenGL will naturally demand familiarity with the underlying API and GPU programming, algorithms such as BSP building and the like should be easy to read, easy to understand, and debuggable. This is why this engine is the first product so far known to have an interactive debuggable BSP builder which any user can activate and quickly see how it works. Other engines use printf() style solutions which is horrible to debug as well. In providing the proper software and tools for development of critical engine components, anyone regardless of experience can dive in and learn/visualize exactly what is happening.