I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there.

The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from:

A) No information about its current status: this is scary if its repo hasn't been updated in months.
B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs)
C) Lack practical references and tutorials for "real would usage"
e.g. "how to create an OpenGL window" or "how to render a triangle"
versus something like "how to load from disk an image texture onto a quad and move it around using keyboard events"

SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state.

Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening!

On Mon, 05 Aug 2013 20:18:29 +0200, Jonathan A Dunlap wrote::
> 
> A) No information about its current status: this is scary if its repo
> hasn't been updated in months.
> B) Usually are complex to get working in a new project (manually
> building or searching for undocumented dependency DLLs)
> C) Lack practical references and tutorials for "real would usage"
> e.g. "how to create an OpenGL window" or "how to render a triangle"
> versus something like "how to load from disk an image texture onto a
> quad and move it around using keyboard events"
> 
> SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state.
> 
> Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening!

A) I recommend using Derelict3--it's kept up to date, looking at the
commit log shows work in the last 24 hours to update the bindings. It's
also well designed and works well.
B) If using Derelict3, you simply need to: build Derelict3 (it's as
simple as running build/build.d) and have recent builds of whatever
libraries you're using through it.  How difficult the shared libraries
dependencies are is project by project and not really a D-specific issue.
C) Derelict3 is basically just bindings over the C functions--you should
use any and all documentation, references, and tutorials against the C
libraries.  E.g. any C language tutorials on SFML, OpenGL, etc. are
trivially translatable once you understand how to load the Derelict
modules (again, look at the Derelict README).

On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote:
> I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there.
>
> The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from:
>
> A) No information about its current status: this is scary if its repo hasn't been updated in months.
> B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs)
> C) Lack practical references and tutorials for "real would usage"
> e.g. "how to create an OpenGL window" or "how to render a triangle"
> versus something like "how to load from disk an image texture onto a quad and move it around using keyboard events"
>
> SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state.
>
> Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening!

Take a look at https://github.com/Jebbs/DSFML
The autor, aubade, me and few other guys are trying to maintain the project. I wrote a small tutorial on the wiki. And we have plans on documenting it, adding unittests and much more. The autor announced today that he will soon update the C bindings to SFML 2.1

If you have any problems using it just open an issue on github.

> C) Derelict3 is basically just bindings over the C functions--you should
> use any and all documentation, references, and tutorials against the C
> libraries.

Thanks Justin for the response. Derelict3 does seem to be the library with the most activity by far. However, it's simply not good enough to just say that since these are just bindings that the documentation/examples in the host language is adequate. This is true under the assumption that: the developer already is comfortable in the D language to know the usage difference, are familiar with the lib API to know when these differences apply, or even know to translate dependent idioms outside the actual library usage (like loading an image from disk, to apply to a texture, may be a separate but related learned task to the library). If we are looking for a broader adoption of D, we should be in the mindset of someone who may not even have a background in computer science here.

> Take a look at https://github.com/Jebbs/DSFML
> The autor, aubade, me and few other guys are trying to maintain the project. I wrote a small tutorial on the wiki. And we have plans on documenting it, adding unittests and much more.

Great stuff, Borislav. The basic tutorial https://github.com/Jebbs/DSFML/wiki/Short-example helps a lot to grok how to get your feet wet. I'm looking forward to seeing more tutorials like this.

On Monday, 5 August 2013 at 19:03:29 UTC, Jonathan A Dunlap wrote:
>> Take a look at https://github.com/Jebbs/DSFML
>> The autor, aubade, me and few other guys are trying to maintain the project. I wrote a small tutorial on the wiki. And we have plans on documenting it, adding unittests and much more.
>
> Great stuff, Borislav. The basic tutorial https://github.com/Jebbs/DSFML/wiki/Short-example helps a lot to grok how to get your feet wet. I'm looking forward to seeing more tutorials like this.

Thanks! Bear in mind that the autor is working on splitting the 5 modules into separate files for each class. That is because currently everything is too cluttered into one file for each sfml sub-module. See the Experimental branch, it is almost done. After the change you would be able to more easily browse code and the only change you would have to make is in the imports. So instead of:
import dsfml.system; -> import dsfml.system.all;
or import specific classes:
import dsfml.system.vector; //or something like that

Also about building and assembling everything together, see https://github.com/Jebbs/DSFML/issues/34
A build.d script is being worked on and things like adding more documentation, unittests and examples are being worked on too. Also an suggestion has been made to add dsfml to the DUB package manager(that is used by vibe.d) and is something similar to ruby's gems manager.

And now that Direlict has been mentioned, I suggest you to not use it for sfml. It is just a collection of c-bindings of popular libraries.

I'm working currently on Dgame: http://dgame-dev.de/
I'm almost finished, but the documentation, the tutorials and the download there is not up to date, but that will change in the next few days (now that I had my last exam today).
My fellow students and I also work with Dgame on a 2D sidescroller. The work on it was stopped because of exams, but it will continue in the coming weeks.

> ...

Oh and I completely forgot to mention that I am working on a D version of the spine runtime (http://esotericsoftware.com/). If you haven't heard of it it is a 2D skeletal animation tool that exports to bin or json(other formats too). And there are many runtime libraries for many languages(currently no D support) and popular game engines. Although the tool isn't free ($70), it helps development A LOT. However the 'format' is open, so one could write his own editor/exporter.
Runtimes are usually split up in two - engine and renderer. The engine part is language-specific (for example C#) and it only parses the data into appropriate structires that the renderer will use later. The renderer part is gameengine-specific (for example Unity, XNA, MonoGame for C#) and uses the engine part's source. Then the renderer part just implements one or two classes that do the actual rendering and logic updates that are engine-specific.

And yeah, I decided to make a D runtime for spine:

https://github.com/nikibobi/spine-d - engine part (pure D)
https://github.com/nikibobi/spine-dsfml - renderer part (D + DSFML)

Also I forgot to mention that aubade made an separate repository for SFML extensions ported to D like sfMod and sfMidi

https://github.com/aubade/dsfml-contrib

Also about your original post you mentioned SFML-D and if you have looked the original SFML site's bindings page(http://www.sfml-dev.org/download/bindings.php) it is indicated that SFML-D is inactive. And there is Jebbs DSFML marked as active along with Direlict 3

On Monday, 5 August 2013 at 19:33:59 UTC, Namespace wrote:
> I'm working currently on Dgame: http://dgame-dev.de/
> I'm almost finished, but the documentation, the tutorials and the download there is not up to date, but that will change in the next few days (now that I had my last exam today).
> My fellow students and I also work with Dgame on a 2D sidescroller. The work on it was stopped because of exams, but it will continue in the coming weeks.

Wow that's great news! I will try it and maybe try to help you test it and improve it. I will look more into it tomorrow when I have more time. But from the first looks, I like the site design and the engine looks a lot like SFML(a good thing).

On Mon, 05 Aug 2013 20:59:32 +0200, Jonathan A Dunlap wrote:

>> C) Derelict3 is basically just bindings over the C functions--you should use any and all documentation, references, and tutorials against the C libraries.
> 
> Thanks Justin for the response. Derelict3 does seem to be the library with the most activity by far. However, it's simply not good enough to just say that since these are just bindings that the documentation/examples in the host language is adequate. This is true under the assumption that: the developer already is comfortable in the D language to know the usage difference, are familiar with the lib API to know when these differences apply, or even know to translate dependent idioms outside the actual library usage (like loading an image from disk, to apply to a texture, may be a separate but related learned task to the library). If we are looking for a broader adoption of D, we should be in the mindset of someone who may not even have a background in computer science here.

All Derelict3 "usage differences" are clearly documented in a wonderfully short section in the README.  I don't think it's a problem to assume that someone who wants to "write a video game in the D programming language" has a basic working knowledge of D and of the various aspects of language agnostic game programming; i.e. documentation on how to invent the universe should not be a prerequisite for baking an apple pie.

That said, I will seriously consider writing an article on getting started with modern OpenGL with Derelict3.