What language are games written in?

  • Thread starter Thread starter Van Nastring
  • Start date Start date
maybe in c++ you can access directX a bit faster. but i'm sure games in C#
are coming very soon!
 
Games aren't written in C# not because of the language per se, but
because of existing in a managed (.NET) environment. Managed code still
isn't up to par, speedwise, with unmanaged code, and for games, every bit of
speed is important. So a lot of game vendors are writing in C++ and doing
their own memory management.

However, Managed DirectX claims something like 98 or 99 percent speed of
unmanaged DirectX. That's pretty impressive - as .NET becomes more accepted
and processor speeds grow absurdly higher, I won't be surprised to see major
game venders developing in a managed environment. The productivity savings
are considerable.

Erik
 
Isn't managed DX just a wrapper for the lower level DX APIs? If that is the
case, the speed is not truly that impressive. It simply would mean that 2
percent of the processing is simply devoted to marshalling the data through
the p/invoke layer (and other .NET housekeeping).
 
Sure it's a wrapper. But a lot of time and attention has been given to
optimizing it, ex: making sure that marshalling and memory management is
done outside of critical processing loops. The impressive part is how much
they've been able to minimize the performance hit. If you're curious,
here's a very good interview with the guys who did Managed DirectX:

http://msdn.microsoft.com/theshow/episode037/default.asp
 
What language?
----------------
C or C++ generally. Some in assembly.

Why C++/C and not C#?
--------------------------
1. C++ is faster, as it is a very low level language. For what most people
are doing with games, it is faster, although C# has some great capabilities
and can beat C++ in some respects (mostly due to the CLR).

2. You can more easily port code to other systems: game systems, Linux.

3. C# requires the .NET Framework on a machine, and not everyone has it
right now. A few years down the road, you might see the trend going towards
C#, once a good number of Windows machines are .NET enabled ... and once you
can write .NET code for other platforms rather easily.

4. Game programmers are familiar with C++/C.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************
 
That and you can turn any .exe or .dll back into its readable code
pretty easy in c#. Being runtime code you can reverse engineer it and
see whats going on. You can obfuscate it but over all, your codes easy
to be read. I dont know to many game designers want people to have the
ability to reverse their code so easily.
 
Greg Merideth said:
That and you can turn any .exe or .dll back into its readable code
pretty easy in c#. Being runtime code you can reverse engineer it and
see whats going on. You can obfuscate it but over all, your codes easy
to be read. I dont know to many game designers want people to have the
ability to reverse their code so easily.
Click to expand...

How about all of the game designers that provide the general public with the
SOURCE CODE anyway?

I know that sometimes the graphics rendering and network parts of the game
engine is not made public, and I would still almost recommend doing that in
MC++ with some unmanaged code (or at the very least unsafe C# code--since
drawing to textures directly and filling out vertex buffers is much faster
with pointers). But writing the code in C++ doesn't mean that nobody will
be able to reverse engineer it.

I'm pretty sure that most of the Quake 3 source code is up for grabs, with
the exception of a few lower-level graphics libraries that John Carmack
likes to keep to himself. And if you want THAT code, you can get it pretty
easily (but with a heavy price tag for the license).

Also, take the Unreal and Unreal Tournament games: A lot of the
higher-level code is written in UnrealScript--an OOP language that is
INTERPRETED at runtime. And if you want to modify the game for fun, this
code is easily available, and the developers even ENCOURAGE you to look at
it.

So wouldn't it stand to reason that a game could be written with it's logic
being in managed code? C# would make a hell of a scripting language for
games. Better yet, any .NET language could be used to add
user-modifications to the game. This seems to me to be the greatest reason
to want to have a game using .NET. Plus, the code certainly wouldn't be
interpreted. I would wager the CLR could run circles around UnrealScript's
interpreter.

And if somebody stole a game developer's engine and sold it to a wide
market, I'm pretty sure that game developer would have it's huge legal team
busting down doors....There is almost no need to obfuscate most of the game
code. You might want to hide your network code to prevent cheating in
multiplayer, but you are just delaying the inevitable. Your game WILL be
cracked. People WILL cheat. It's a never-ending battle.

Right now, a good solution may be for part of the game to be written in pure
unmanaged C++ that hosts the CLR for running the higher-level code (such as
UI, AI, character interaction, game events, etc.). But I see no reason why
an entire game couldn't be written in C#. It certainly would make for a
clean design. Plus, Managed DirectX is pretty good, speed-wise.

And if you wanted to go as far as to P/Invoke OpenGL, SDL, etc. instead of
using DirectX, then you'd probably have no trouble getting your game to run
on Mono. So you'd have an instant Linux and Mac ports of your game. That
can't be a bad thing.

--Matthew W. Jackson
 
I read this quote from some site, it goes something like this, "Its easy to
shoot yourself in the foot with C, its harder to do it in C++ but when you
do, you blow your whole leg off". Can someone give me some specific
examples as to why this is so? What happens when you 'shoot yourself in the
foot' in C#?
 
You may slow down your program by using up all your memory/resources....but
your program won't crash.

So if you shoot yourself in the foot, you'll limp in C#. But the fact of
the matter is it is much harder to shoot yourself in the foot, because
there's a safety on the gun now (which is disabled by the unsafe keyword).
 
Well I screwed up my analogies. I thought I was being clever... :-)

In the C/C++ sense you don't shoot yourself in the foot in C# without the
unsafe keyword.

But like Java, there are new ways to shoot yourself in the foot, few of
which cause any permanent damage.

--Matthew W. Jackson
 
Yes, but with C# and the garbage collector you might not say "ouch" for
three days. This is better then C++'s operator overloading, because then you
might have shot yourself in the head and never realized it.
 
Back
Top