-
Notifications
You must be signed in to change notification settings - Fork 62
Project Structure
If you take a look at the root-folder of a freshly cloned REGoth repository, you should see something along these lines:
- content/
- lib/
- src/
- toolchain/
- CMakeLists.txt
- README.md
- ...
This is the home for all kinds of content that has to be shipped with the compiled binary to run the engine successfully. Right now only the shaders for the different platforms are placed here.
When running from a newly compiled executable, you have to make sure that you either have the working directory to this folder, or copy the contents to be next to the executable.
REGoth does not yet try to search for the content/
-folder, but it might do so in the future, which saves you the hassle of getting the paths right.
In here are external libraries used by REGoth. It is important to notice, that everything that is bigger than a couple of files has been added as a git-submodule. For example, since ZenLib is used extensively by REGoth, but is still updated often, you can just update it's submodule to get hold of the new code.
Also the core-repository will be smaller, since the libraries can be pulled externally.
The downside to this approach is, that working with git-submodules is always a hassle and it's easy to make mistakes, like not pulling everything you thought of because git decided to be weird again.
Planned to hold CMake-Toolchain files for different platforms. Currently only one for MinGW is there and the android-toolchain-file is somewhere in the src/-folder. The android-build is pretty tricky to set up, but more information and a cleaner version will follow.
Contains the engines 'modules', which can be read more about here:
Build files and tiny Java-Boilerplate-code for building on Android. More documentation regarding these is to come!
Contains most core-object functionality. For information about how the internal component system works, you can read this wiki-page. This is only about the most important files:
-
Entities.h
- While the name is not really matching, this contains all the different components an entity can have. Other than the definition of the components, there is next to no functionality in here, except some to work with the component mask.
-
Vob.h/cpp
- To make working with entities as real objects easier, these files provide an access-interface to most used components and the controllers for an entity (or a series of entities) acting as a vob. It also provides basic functionality like creating a vob, setting the transform or changing its visual.
-
VobTypes.h/cpp
- Contains specialized methods for working with Characters, Mobs or Items.
- Note: Some of the functionality should be moved out of here or deleted, especially the NPC_*-methods, since they can be accessed through the character-controller.
Allocators and loaders for all kind of game-content, like meshes, textures or audio. These can be accessed through a WorldInstance-Object and are bound to their world, which means that all content inside a world, will be unloaded, when the underlaying world gets unloaded.
Mostly Platform-specific code and basic internal engine-classes.
Inside World.h/cpp you can find a class, which happens to manage everything going on in the game, or at least one of the loaded worlds. It contains allocators for content like textures and audio, as well as a list of every object/entity spawned in the game, which it updates and renders every frame.
Definitions of all kinds of handles to things, since bare pointers are only rarely used anywhere inside REGoth. More on handles can be read here.
Everything about game-logic can be found here.
That contains:
- PlayerController (Character-controller, to be renamed)
- Visuals
- Mobs (Interactable objects, thats what PiranhaBytes called them)
- Dialogs
- Scripting-Engine (Daedalus VM + Script-Externals)
More information regarding controllers can be found here.
Have a look and poke around the files as well! Most interfaces should be pretty well documented.
Math-library wrapping GLM.
Different kinds of allocators. See engine internals [todo] for more information.
Simple physics-engine wrapping BulletPhysics. Not much work has been done here, but it does the job for now.
So called "RenderSystems" are stored here, which, for example, can draw the main world, shadows or reflections. These need be be called from somewhere inside the WorldInstance manuall at the moment, and the API is far from done. Currently everything is crammed into "WorldRender" so we at least get to see something on screen.
Source files for vertex, fragment and other shaders. Compiled shaders are located in content/shaders
and are tracked in repository as well, for simplicity. You can recompile shaders with make -f src/shaders/makefile rebuild-all
command. It requires shaderc
tools from bgfx
, you can build it once with cd lib/bgfx-cmake/bgfx/ && make tools
command.
"main"-function, so to say, of REGoth resides here. This initializes the engine, loads the start-world and reacts to input. Mostly debug-code and a little bit of "startup and run the engine".
Will contain objects about UI (hence the name, who would have guessed?), like Dialog-Boxes or the inventory. Also rendering using the original fonts is done here.
Random small utilities which were needed here and there.
Some of the contents:
- String-split
- Foreach for std::tuple
- File-System access
- Fixing a case-insensitive path on case-sensitive systems