Games people play

[Georg Wrede]

Seems to me that while D is marketed as a Systems development language, 
it will be quite some time before anybody has developed a System with D.

More plausible should be that one day games developers will find D /en 
masse/ because everything in D really is perfect for games development. 
We already have astonishing power of expression, an integrated GC (while 
it may at the outset look like it discourages games development, serious 
game shops should have no problem in discovering that you can either 
disable the gc for critical sequences, pool staple instances, or just 
new and delete (in essence, "touch") in advance the expected amount of 
memory), very easy integration of scripting languages (DMD-Script, Lua, 
Python), in-built associative structures, direct access to C-code 
libraries and system functions (while touted as trivial to use from D, 
they at least aren't impossibly cumbersome in practice), and in-built 
UTF-8 all the way.

And, I've heard some games developers state, they'd "rather lose 10% in 
game speed if they can win 10% in developer costs". I'm sure all here 
agree D can deliver at least this 10% slash in developer costs, while 
possibly even making the binary /faster/ than with e.g. C++, hands down!

The games industry is something we can expect to become one of the 
absolutely most important areas of code development in the near future, 
both in lines of code and in reaped revenue. Being a successful language 
in that single area would give D success beyond conservative dreams.

The one thing that could really set D apart from other languages would 
be a siglnals/slots mechanism that was incorporated as an _integral_ 
part of {the syntax | the core | Phobos} of D.

That something happens in a game that has bearing on potentially a lot 
of objects or individuals in the game, is simply key in games 
development. Having to manually code all this is ridiculous at a time 
when there exist established and well understood mechanisms for it.

---

Recently I had to write a command interpreter for a (in itself trivial) 
control language for a materials production process control program. The 
ease and joy of development was largely due to the std.regexp library. 
It was simply exhilarating.

If we could offer the game developers a smooth and transparent method 
for passing messages instead of a cumbersome design pattern, I think 
many shops would look upon us with a new eye.

In my humble opinion, the reason why QT is an absolute winner in the 
industry is simply because the signals/slot paradigm is central to that 
library. That in itself creates a sensation of robustness, quality, and 
a kind of completeness. The ease of utilizing it has most probably made 
the overall quality of the rest of the library much higher, by letting 
their programmers concentrate on the issues at hand instead of fighting 
with the trivialities of message passing.

We have to remember that interactive "real time" games development is 
the one area where signals (or messages) are an essential part of every 
major application. Both in the user interface and in the games engine 
logic itself.

---

We only have to become the _preferred_ language in _one_ area! After 
that it'll automatically follow that we gain other areas and a huge 
general interest. ("If C is good enough for Unix itself, it has to be a 
good language. -- If D is good enouhg for some of the best games shops, 
it has to be a good language.")