A Perspective on D from game industry

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun Jun 15 20:12:57 PDT 2014


On 16 June 2014 12:44, Burp via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
>> Gamedev is about solutions being given (MSVC, closed console platform
>> tools, etc), and they are just waiting for the package to appear.
>> It's not entirely unreasonable either. Most people probably don't
>> realise how high-stress and unfair the gamedev industry is when it
>> comes to engineers time and commitment to their work.
>> To say that they literally have no time to spend on extra-curricular
>> projects is an understatement, and risk-aversion is a key form of
>> self-defence. I know many gamedev's who are frequently expected to
>> choose between their life and families, or their jobs.
>
>
>  There are some gamedev jobs that aren't like this. My last one was 40
> hrs/week and never a minute more.

I think it's the exception though, not the rule.
And did that make the employees tend towards being OSS enthusiasts, or
did the proprietary nature of the industry still shield them from OSS
on average?
You're posting here now, that could be taken as support for my theory :)


>> One thing I do think needs more emphasis though, is the true costs of
>> 'compile time parameters'.
>> People tend to only consider runtime performance, and rarely consider
>> it in relation to binary bloat, or more subtle forms of performance
>> impact, like icache misses, which are more difficult to measure, and
>> rarely express themselves in benchmark environments.
>
>
>
>  I see gamedev's use this as an excuse too much, it is mostly bunk. They
> would have manually written it N times anyway, or they simply put code into
> a template that didn't need to be.

Maybe. But often not.
I regularly balance a runtime branch vs a template.
Binary size is still a significant concern on many platforms (phones,
nintendo platforms, handhelds).


>  Anyway to make D attractive to game development?
> 1. VisualD needs to be on par with Visual Assist
> 2. D needs to figure out what the hell it is doing with GC/RC/Memory
> 3. Target all common platforms
> 4. Allow for C++ and D to call each other without requiring a C interop
> layer.(not going to happen but would help immensely)

Are you deliberately repeating my list from before, or are these your
independant findings too? :)
I don't find 4 to be a significant problem in practise. And it will
erode in relevance as a commitment is made and more code transitions
to D.


More information about the Digitalmars-d mailing list