Philosophy

Desire Driven, or jDsD for short, tries to capture the knowledge and desires that designers and gamers have spinning around in their heads.

The system is based on organizing knowledge in an easy to comprehend and easy to edit conceptual tree, with trivial functionality captured in the nodes. This way the knowledge can be more easily reused in other contexts, rather than having to be re-thought by the next designer all over again.

There is one simple rule to make this technique successful: don't over- or underspecify the functionality of your components. Usually the game logic is inextricably linked to knowledge about file formats, rendering trickery, ways of communicating, the user interface, etc. Having this knowledge is not wrong but having no means to easily separate it from each other restricts extensibility and maintainability, and requires designers/programmers working on different abstraction levels to understand all of it.

More importantly, the game content usually is completely static, so there's no way to have a computer handle and reuse the models and textures intelligently. TODO expand

Another issue is that programming languages work with identifiers, but it's difficult to see at once what's behind that name, both intentionally and actually. Even the most advanced software development systems can't really provide this knowledge on demand and require the programmer to already have quite some knowledge of the source code collection to avoid misinterpretation. jDsD is capable of providing a view on the knowledge tailored for the purpose at hand, and such a view can be edited directly. Details or abstractions can easily be made later on without any hassle. Modifying existing definitions is a bit more complex, so definitions should be kept as simple as possible so there's nothing to correct. Also, ambiguous concepts such as "responsibility" should be modelled in its separate forms.

TODO: knowledge of users/designers, physics

Now comes the difficult part; the system has to perform well, which implies that the knowledge in the tree structure has to be processed to make a fast system, e.g. it should know what, when and how to cache and communicate data, to satisfy the desires of the designers and gamers. TODO expand.

Current implementation choices

• A tiny native library to link to crossplatform but natively implemented libraries like opengl. This native linking will be done by buffering calls and their arguments using nio buffers (which are registered toghether with the library function).
• This way we don't need 5 mb libraries, function names can be easily generated (unfortunately the use of ordinals is not supported under posix implementations) and most importantly, we can optimize the calls for our special coding structures.
• Direct use of Java's system event queue instead of separate platform implementations for keyboard and mouse (as in lwjgl). We need special sandbox rights to use JXTA anyway.
• A basic code editor is implemented in the Java language; after that, we can use our internal tree-based language and generate Java bytecode. When the code is more developed we can implement the editor in it as well and free ourselves of javac and the sdk download.
• All language elements will be read-only and provide int, float and String values
  • State changes (mostly formed by calls to libraries) are triggered using an interface called "Triggered".
  • This basically means that it will be a functional language, like Haskell, but without the useless academic notations and conventions.
  • Aspect oriented programming is implied in functional programming; in our case this means that we define functions that (when triggered) alter the code tree based on their inputs.
  • I have been seriously considering using Haskell bytecode instead of Java bytecode, but the differences are marginal in the end, and using Java will make the platform easier to adopt and save a couple of months on development time.

TODO (for this wiki)

• Conceptual examples
• Examples of the tree implementation in Java
• Some graphical impressions of how a game would come to be, when using this system
• Features that can realistically be expected at this stage
• Give some background on the choice for Java and the libs used

Discussion

Please share your ideas here, especially if you know about similar projects. Or you can use our forum.

-- Main.frankvl - 25 Feb 2008 -- Main.frankvl - 22 Feb 2008