Games people play

[clayasaurus]

Georg Wrede wrote:
> 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.")

D is unusually great for game development already. Multi-core processor 
games are the future. I remember Sweeny wrote some sort of wish list for 
a language he'd like to use to write games with and perhaps this should 
be looked at more closely.
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf#search=%22tim%20sweeny%20program%20language%22 


Plus games make a good 'extreme' case, it it works well with games, then 
it'll work well for everything since games combine system io, graphics, 
physics, networking, filesystems, and gui's all into one bundle.

Here's a game engine of the near future, which makes use of a multi-core 
system, just to show where the trend is heading...

http://www.youtube.com/watch?v=piMrNvdwYRU

 From all of the above, my conclusion is
1) D needs to be able to harness multi-core processors and enable 
concurrency, this should be built-in
2) D needs good numerical computing (already there?), set support with 
union, intersect, etc through arrays?
3) Reliability, pretty much there, need 'Super Lint'
4) Easy access to powerful scripting languages (there)
5) Cross platform, it is there pretty much with GDC
6) Make an add on library or build into phobos (not sure if this is a 
good idea or not, probably better left as an add on library, unless 
these could somehow be buit-in to the language?)
   A) Path finding algorithms
   B) Scene graph algorithms
   C) Collision detection algorithms
   D) Physics simulation algorithms
   E) Sound propagation alg.
   F) FileSytem (like PhysFS www.icculus.org/physfs )

7) Support for pixel shading (not 100% sure how this could work)
8) Modularity (there). Make package system stronger somehow?
9) feature to extend functionality of the base class using

class CBase {}
class CNew extends CBase
{
}

Already there? Just took from Sweeny's PDF.

10) Array bounds check is there

I think this would be an exciting direction for D to move toward, and if 
we could suit Sweeny's needs (we could invite him to these newsgroups) 
and he uses D for his next engine (Unreal 4), all the C++ fans over at 
gamedev.net will faint :-P

~ Clay