Is D Language mature for MMORPG Client ?

[Klaim - Joël Lamotte]

Hi people,
I am a game developer (using C++ and various other languages), I stop by
sometimes to see how D and it's community evolves.
I was reading this interesting (but a bit depressing) thread and I mus just
point something for new programmers not knowing a lot about game
development:

On Sat, Aug 4, 2012 at 5:11 AM, Kapps <opantm2+spam at gmail.com> wrote:

>
> C++ is a terrible language to make a game in.
>

Wrong. It's the best approximation available of something that gives low
and high abstractions and still let us do anything we want if we ask to (I
mean, very specific optimizations that should never be in a some generic
code). Also, it's the only one letting us code for undefined yet platforms
with the less frictions for portability - other than code architecture that
have to match with the (console) hardware too.

D could do this too, but apparently it's not there yet. I hope it will. I
see some excellent features there.

Also


>
> -Unmaintainable code
>
This is a team issue, not a programming language issue. I don't have
unmaintainable code and as said someone famous around here if you work in a
company that have such kind of code "contact headhunters".


> -Template bloat everywhere
>

In game-specific code, it is not very common to use template heavily, so
this is wrong.


> -No garbage collection, inevitably causing memory leaks
>

You apparently know nothing about "modern" C++. This is wrong.


> -Due to no garbage collection, higher overhead passing references around
> with smart pointers.
>

One don't imply the other. Different tools, different use. Smart pointers
don't replace garbage collection. there is just less a need for it in C++.
In games, in particular, you don't want garbage collection, because there
is no way to guarantee performance.
For example, lot of C# based games have uncontrollable hics because of
garbage collector.
>From what I understand, but i'm not a specialist, it is impossible to avoid
this with a garbage collector. I suppose it is one reason why D allow
non-managed objects too.
This kind of problem can kill a game experience. It greatly depends on the
game though.
The best thing for a game programmer, is to rely on RAII. C++ have RAII,
(as D, from what I understand), so it is very good for games.


> -Difficult to code cross platform for.
>

Wrong. Also, what is the difference with D on this point? The only thing I
could see is that D have a bigger standard library...but it's not clear to
me if it is "standard".
Anyway wrong.


> -Disappointing lack in standard library
>

That is not a problem for video games. It was a problem when there was no
standard container.
Most of what you want from the standard library for video games are very
generic stuffs: containers, sometimes threading, utilies.
Most of C++11 libraries are useful for games, but the most important
libraries you use in games are domain-specific.
For example, graphic rendering (not just OpenGL, I mean, the layer above
it, to manage scene graphs or whatever is higher abstractions of graphic
rendering),
input acquisition (hard to make generic when your input devices are not
"standard"...), audio rendering, etc.

So, wrong.


> -Confusing build system supporting portability issues.
>

I'm not sure what you mean here. I think you might point to the fact that
there is no associated build system to the language.
I think it is a good thing.


> -Different features supported by different compilers, even in different
> ways.
>

Less true today but it might have been true 10 years ago.


> -Features that may result in your engine giving undefined behaviour
> everywhere.
>

I don't see the point.


> -Many features are not implemented yet, let alone widespread.
>

You mean in C++11? Yeah, it have been only 1 year since the
standardisation. Also, D is apparently in the same case without having any
standardisation process.
Building a language and making it real is no easy task.


> -Threading is not part of the language, when games now-a-days tend to be
> heavily multithreaded for maximum performance.
>

In C++11 it is. Boost provide it. In fact there is tons of libraries for it.
However I agree that a standardized task scheduler interface would be great.
But the point is: multithreded maximum performance is not really
interesting in most games.
For example I am planning several projects right now. On 6 projects, only
 1 would benefit from multithreading.
Rendering libraries are already using multithreading so the game code is
not always necessary to use it.
On some consoles it is necesary to use it, because of the architecture of
the console, but then the console provider provides the console-specific
library.
It's better if you use a standardized library though, but it's here now.


>
> C# is a terrible language to make a game in.
>

No, it is good for a lot of kinds of games. I'm playing Fez these days, it
is very good and would have been hard to make by only 2 people
(1programmer) with C++, without really high knowledge of C++.
It have sometimes slowdowns ans hiccups, but the game itself don't suffer
from that because it's not a high speed action game.
Not all games require full power of the machine.


>
> -Can be difficult to interop with C/C++ libraries.
>

You rarely work directly with C/C++ libraries in C#, evne in games. Most C#
gaming libraries abstract, hide their native parts in a way that makes you
not bother about that.


> -Code can be decompiled easily and stolen, even obfuscated.
>

Since when it is not possible in other languages? There are tons of native
code applications cloned on Apple Store.


> -Bugs can be easily found and exploited due to IL code.
>

Not on a gaming console. Anyway, that's not a real problem for a game. Most
developers will say that if you want to aleterate your game experience,
you're on your own.
If it is about multiplayer hacks, then whatever the language, it is the
organization of your game communication that makes or breaks the
possibility.
Language have nothing to do with this in games.
I cannot say for other domains.

Also, consider that tons of developers use Javascript in games. Think about
it.



> -Does not compile to native code, so your game will have performance
> issues.
>

Not all games require high performance. In games "there is no rule". Use
what works. Tons of excellent C# games have been made.


> -Overhead when calling native code.

-Your game may not easily run on every platform.
>

Obviously, that's why you should have preferred C++ if it was your goal.
Game developers are smart, they make decisions based on goals only.
They use C# for tools though. It's highly efficient to just build some nice
tools in short time.


> -Different compilers (all two of them) support different parts of the
> language.
>

I don't know, if I wanted to use different compilers for C# i would have
used another language, like C++.
No point.

-Forces your userbase to install yet a second product for .NET runtime
> and/or Mono.


Only if you are not up to date in Windows Xp, or you use Linux.

That said, then you might better bet on C++.

I am currently developing a MMORPG, client part is in c++ and
> server in c#, i want to know if D language is "ok" for the client
> side ?


First you need to consider two properties of your game:
 1. does it's code have to be maintained in years?
 2. do you have time/budget to deal with issues that might occure from D
not-yet-finished developpement?

A game that have to be maintained for years have better to stick with a
stable version of it's tools.
If you have time to deal with changing the tools or fixing problems related
to them, then why not experiment?
The problem is that it have a cost. In classic game industry, the costs are
too high so there is no point in changing the tools when it can only add
instability (from a end-user point of view, not from a programmer point of
 view).
However, the indie scene is full of people in position to "just try". Not
everybody however.
For example, I cannot bet on D right now even if I really think it would be
nice in theory, because I cannot afford to deal with problems coming from
it's implementation (maybe for future games though).
However, once stability is complete (on both compiler and standard
library), at least with a fixed version I could use it IF there would be at
least graphic and audio rendering engines available. If not I would have to
do extra work I don't really have the time to deal with so it would be
required for me (I said the same in another thread).

Anyway, I wish D gets to the point I can finally use it in real context.
C++ is good enough for me right now though.

A game developer.

Joel Lamotte - Klaim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120806/59879526/attachment-0001.html>