Games people play

[Georg Wrede]

clayasaurus wrote:
> 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.

...

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

Hey, these guys are from Finland!
And the demo was awesome.

(Would be nice to have a 4-way, 4gigs playbox. Santa, please!)

Otoh, I guess we should not aspire to convert established major players 
at this point. The reason being, if I were the chairman over there I'd 
be scared to switch to an unknown language, if for nothing else, at 
least all our C++ libraries would become pretty hard to use.

So IMHO the best potential converts would be 1-5 man shops who want to 
get some kind of edge on their competitors. Such a shop might develop a 
game that is "technologically" (mp, rendering, etc) unremarkable, but 
the game could be a winner because they can concentrate on what the 
_game_ is doing instead of battling with C++.

Suppose it's true that D gives (say) 30% more productivity than C++, 
then this shop should get it's products out way faster, and with less bugs.

>  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

Not being an expert on this, does using several cores present some 
fundamental needs of change to a "regular" threading code?

> 5) Cross platform, it is there pretty much with GDC

I think it's still some time before we'd be comfortable on a non-x86 
platform. But that ought to be plenty enough for us. More pressing would 
be to get a 64-bit DMD out, real soon.

> 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

The one thing somebody heavyweight might use D for (for now) is for 
prototyping. Especially if they're smart enough to already demand that 
prototypes are not done in the final language.

There D could shine. Rapid coding, especially under pressure, is where I 
expect the productivity differences between D and C++ to really become 
conspicuous!

Heh, if I were a D salesman, I'd go to a programming shop, and ask for 
the _second_ fastest coder. I'd teach him D for two days, and then give 
both him and the fastest guy some moderately difficult assignment, to 
show to everybody what a difference the language really makes.

---

Back to the issue at hand, it's the smaller shops that would gain most 
from having SS implemented right in the language. Large operations 
probably would develop their own if it doesn't exist in the language, 
and once done, it would just become part of their culture. But the 
smaller shops really could benefit from it existing in the language 
itself. (Whether within syntax or the core library, as long as it is 
there, and trivially usable.)

---

I just remembered a funny thing. Back in the late 1980's when I first 
became aware of OO, I initially took it for granted that object 
instances would interact by something SS-like. Then when I got my Turbo 
Pascal 5.5 upgrade (1989, I think), I was disappointed when I found out 
all this fancy OO and "messaging" was just calling functions in structs. 
I thought this was a home-made hack below the quality and depth I 
expected from Borland.

Later, when I found out C++ did it the same way, it became "legitimate", 
and I thought that TP had actually implemented it quite subtly and smoothly.

But somehow the feeling stuck. I've always been disenchanted with OO 
that's just "calling functions in structs". And somehow I just can't 
help feeling that real OO simply needs threading and asynchronous 
message passing.

(Or maybe it's simply because instead of objects I was thinking of 
Subjects. A lot of the hoopla was like "this object sends a message" and 
the like. Maybe that's why I love Unix: the entire box is a Subject, and 
it contains other, live Subjects! "The other" boxes are just dead iron. 
They're objects to users, to viruses and to malware!)

A lot of code I see is using OO only to bag related functions together. 
Of course, there's nothing wrong with that -- it's a heck of a lot 
better than just having those functions laying freely around. But the 
dreams and promises of OO never did quite materialize as I expected.

Polymorphism is unrelated to this, and I'm happy with it as is. In the 
old days I used to wonder why Borland skipped multiple inheritance. I 
suspected it was because it was hard to do, but later I decided that 
they simply knew it wasn't worth it. With C++ multiple inheritance I 
always felt stupid, first I couldn't figure out compelling use cases, 
and then I couldn't help trying to grasp "a proper" understanding of the 
implications of inheritance networks. Well, turns out everybody else was 
stupid too, so now we've stuffed it right where the sun don't shine.