Within the primary FreeBuildJ directory there are three hierarchies of folders that are important to understand as a developer.
This is the package containing the main engine code. It is divided into several classes and subpackages
- `Main.scala` -> this file is in charge of constructing a Jython interpreter and the logging service, and choosing a main script to run, which will return an `AbstractDriver` subclass, whose `mainloop` will be executed.
- `boxui` -> contains for code for a user-interface layer built on CSSBox (and implementation of an OpenGL-driven renderer for HTML/CSS UI elements)
- `console` -> contains an implementation of the multiplexed logging service and a class representing the Jython interpreter. You shouldn't have to pay it much mind, unless you want to subscribe a new `OutputStream` listening to standard out/standard err (e.g. for a GUI based console).
- `drivers` -> this contains implementations of "main loops" that the engine might want to run. Since the world-representation should be separate from rendering (to cleanly separate dedicated servers from clients, or whatever odd utilities someone might want to construct), we all subclass `AbstractDriver` here. It will probably be useful to added a `DedicatedDriver` sometime soon, for net + physics debugging. Any new drivers will need to be registered, probably by adding a line to `Main.scala` (where `GFXDriver` is currently registered), unless we come up with something cleaner. `GFXDriver` currently consists of a UI rendering loop.
- `gfx` -> this contains everything related to rendering. It's under active development and things might change. But look here if you need to see how rendering stuff works.
- `platform` -> any platform-specific code related to the engine should go here. As of now, this is only `ConventionMinder`, which is the binding to libcrane, for finding things like user data directories.
Eventually we'll need to add other subpackages for at least net-code and physics, as well as classes representing the non-physics related abstractions of in-game objects, and stuff like that.
main.py + scripts
- `main.py` -> implements a bunch of utility functions, and also initiates the reading of certain preferences (for now), and reads command line arguments
- `scripts` -> contains a class implementing a `DOMSource` on top of the Validator.nu parser, to work around CSSBox defaulting to NekoHTML. This probably doesn't need to be a top level script, but we haven't organized everything else yet. Also contains an `__init__.py` that should probably be a template for most subpackages, as it handles things in a nice dynamic fashion.
- `scripts.gfx` -> contains the code used for our configurable graphics pipeline (still in the works)
- `scripts.ui` -> contains the code that sets up all of the UI handles used by `GFXDriver`, plus a module defining a representation for key bindings that trigger actions, and another module that sets up our dummy main menu. Any scripts related to user interaction should go here (though possibly eventually with better organization).
- `scripts.util` -> contains currently only a topological sort algorithm to be used for dependency analysis, among other things. Can be populated with other utilities that don't appear to belong elsewhere.
- `scripts.prefs` -> the `__init__.py` for `scripts.prefs` subpackages are a little bit more elaborate. They define symbols that should be exported by that subpackage, and read a global configuration dictionary to decide which module in that package should be chosen to export them from. Right now we only have keybindings (which is more or less a dummy/holdover, from brief flirtation with librocket), and fonts, which just provides a handle to a directory full of fonts that we want to use. The full preferences system isn't set up yet, but between `main.py` and this you should have a good flavor for how it will work.
Eventually, we'll need to add server + client subpackages, plus probably a "common".
Sounds, models, textures, and ui related stuff will go in here. Add directories as needed, in an organized + hierarchical fashion. As with scripts, the top of these hierarchies should probably be related to server/client dichotomies, plus some stuff in common.
Back to top