Home

svenstaro edited this page Apr 15, 2012 · 3 revisions
Clone this wiki locally

What is derp?

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.

Project structure

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.

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

Derp Engine Runtime (DerpER)

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 - Editor

HerpDerp is a planned scene graph editor for the derp engine. This subproject has not yet been started.

Code style and Documentation

It is important to keep a consistent code style and a good documentation. Please follow these guidelines to keep our code clean.

Symbol names

  • 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

Spacing

  • 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

Documentation

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.