RE: [GD-General] Compile times

[Donavon K. <kei...@ea...>]

Tom Nuydens [t.n...@vr...] wrote:
> In the scripting thread, Brian mentioned "faster development" (i.e. no
> rebuilds) as one of the reasons one might use scripting. Would anyone
> actually go so far as to implement a scripting engine just for this
> purpose? Or, to take it one step further, would you consider writing
> your application in a different language altogether (not C/C++), just
> for the sake of improving programmer productivity?

For years I've been desperate for something that could viably replace
C++ for at least much of game development.  Java and Python both fell
short in my estimation.  I've been using C# for two years now and it's
still looking promising.

In between contracts I do almost everything in C# and when I take a job
and go back to C++, I actually find that for a while anyway I tend to
significantly underestimate my tasks.  C# eliminates a lot of the
friction in C++ coding.  Partly it's because VS.Net integrates with C#
much better -- IntelliSense is nearly flawless, and that counts for a
LOT.  (Visual Assist certainly helps.)  And I've really become aware of
how much time gets wasted futzing around with header files -- create a
header and declare your class in it, create a .CPP and define your
functions there, make sure the signatures match, remember if you change
one to change the other, flip back and forth a lot, and of course sit
back and watch the dependencies recompile.  Header files suck.  They
need to die.

Just for kicks, I wrote a little multiplayer space trading game, sort of
like Gazillionaire, in C#.  You could play either through a browser or a
native client.  It used ADO.NET and SQL Server for the backend and
ASP.NET to serve up the web pages.  Knowing next to nothing about
ASP.NET and ADO.NET, I had it up and playable -- by multiple players --
in under a week.  And I wasn't rushing; I spent the better part of one
of those days just pulling sound effects down off the Net.

For me anyway, that's some pretty serious productivity.

But is C# viable for real game development?  Hard to say until somebody
actually does it.  Phil Taylor has claimed that the Managed DirectX
examples will run 98% as fast as the C++ examples.  That's bold, and
promising.  (Incidentally, Managed D3D is much cleaner and easier to
work with than regular old D3D.)  Still, it may be that you'd want your
low-level stuff in C/C++, and watch out for chatty interfaces.

Then there's GC.  Depending on the game you may be able to tolerate the
occasional GC hiccup and you may not.  In .NET it's so easy to create
and discard objects on the heap that every programmer would have to be
very disciplined about how memory is being consumed.

And of course there's portability.  For now you'd have to be pretty much
Windows-only.  With Rotor and Mono this may change. 

> By the same logic, if you knew that you
> could get your work done faster using another programming language,
> would you do it? _Has_ anyone actually done it (e.g. even if only for
> internal tools)? I'd love to hear about the build times for
large(-ish)
> Java or C# projects, for example.

For most tools I wouldn't use anything else.

None of my projects has gotten beyond maybe forty or fifty source files.
A normal build is one to two seconds.  A full rebuild (very rare) is
maybe a few seconds more.  I'm on vacation so I can't be more specific.
To be sure there's also a second or two hidden in the Jit compile.

Speaking of Jit, because the code is ultimately compiled on the user's
machine, the compiler can transparently use specific processor features
that C/C++ object code can't (MMX, SSI, etc).  Theoretically (some) C#
code could run faster than C/C++.

There's a lot more to say about C#/.NET's virtues and flaws (there are
some), but I'll leave it at that for now.

--Donavon