DERELICT Game Library

After finishing my directory diff tool and deciding that the HTML source code reformatter was too boring to work on; I returned to trying to get some kind of a game working in Digital Mars’ D programming language.

I downloaded Derelict, the everything-related-to-games-or-graphics linkage library for D. It takes good advantage of D’s ability to statically and dynamically link to C without hassle. I liked Derelict. Add one additional initialization function call and the C code for your OpenGL or SDL program is very nearly ready to run.

Derelict needed Build / BUD in order to run. (BUD is the name of the tool formerly known as Build. BUD parses your source files as needed and acts as an intelligent MAKE. You’ve already specified in your source which imports you need. BUD uses this information to compile and link your executable.). (Download this, then rename the junk file that downloaded as “bud.exe”. The download link was broken for me.) After using BUD to get Derelict compiling, I discovered I like it better then dmd for my compiles. No make files. The naming scheme of your files appears to be sensitive, but you can build a single file and all dependencies will be dragged in.

One of the tutorials I read recommended breaking Derelict’s zip file layout by searching for every subdirectory named “derelict” and then dropping those files into DMD’s SRC directory. This worked very well.

I grabbed one of Nehe’s articles (Try 6 and 15, I forget which I used) as a base, started with the OpenGL “flying a little plane around the screen with the keyboard” and built upwards to a Asteroids / Bosconian type game.

I took that basic file and started adding layers of functionality. I mildly kept in mind how I would be using my code in the future, but mostly I just kept a list beside my keyboard of the features I wanted to add, and then refactored the code as I went.

I haven’t been a fan of C# and Java’s one file layout because it seemed cluttered to me. A header gives you a nice concise list of what functions and structures are available, leaving the source file to do actual work in. Using BUD made splitting D source files very easy, since once the files marked what imports they needed, the compile just worked. D has nice class / object oriented support, but doesn’t mandate it religiously. I find it easier to refactor stray functions out into new files than to break an existing class in half to make navigating the files easier.

If I had worked much longer with my little toy game, I would have broken the render and keyboard process functions in half. I had code for both gameplay and the main menu in the same functions and that looked ugly. I would probably add a function pointer “process mode” system to handle which render and process was currently executing. After adding many enemies and weapons, I was starting to get irritated at the duplicated code in the “behaviors” file. Most of that code could be converted to data and placed in an external script or in an .INI type definition file.

Various Notes on D