-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The general idea is to create a simple-to-use and not very complex game engine using the D Programming Language including a rendering engine and script bindings. The project is kind of a “reference” project since this will be one of the first game engine implementations in D.
The project is divided in three subprojects.
- The Derp Engine, providing the user with an easy D interface and Lua bindings for common game requirements such as 2D/3D graphics, audio, network, resource management and more.
- The Derp Engine Runtime (DerpER), capable of loading completely scripted user applications from either resource packages or a packed binary.
- HerpDerp, a scene graph editor for use with the Derp Engine.
The Derp Engine is supposed to be a hybrid engine, providing both a D and a Lua interface. Thus it will be possible to write application code both in D (compiled) or Lua (scripted, dynamically loaded and executed with LuaD). It is planned that derp features
- 2D and 3D Graphics via OpenGL
- audio via OpenAL
- simple, extensible resource loading, with many already supported types (ASSIMP)
- simple distribution (see also Derper)
- powerful scene graph with entity/component system
- full scene serialization (level files etc.)
- full access to engine API from LUA
- and probably more
Derper is a simple to use loader for fully scripted derp applications. Similar to the distribution method of Löve2D packages, derper will be able to open a package containing all application data. This should make it very easy to distribute (open-source) projects for all supported platforms.
HerpDerp is a planned scene graph editor for the derp engine. This subproject has not yet been started.
It is important to keep a consistent code style and a good documentation. Please follow these guidelines to keep our code clean.
- Type names: UpperCamelCase
- Local / member / global variables, methods, functions lowerCamelCase
- Member / method access this.keyword... // please use this to underline that this is a member access
- Private members / methods: _underscoreAndLowerCamelCase
- Use soft tabs (4 spaces) for indentation of blocks
- Curly braces start on the same line as their opening statement, separated with a space
- Binary operators are separated from their operands with single spaces
For documentation style please follow the guidelines on http://dlang.org/ddoc.html. Triple-slashes (///) should be preferred for single-line documentation of members and methods, for classes, structs, enums, modules, and mult-line documentation blocks, please use Doxygen-style documentation blocks (/** ... * ... */). If required for code examples inside the documenation comment, fallback to /++ … +/ for the outer blocks. Use of the ditto statement is highly encouraged in appropriate cases.