What language are games written in?

[Van Nastring]

I believe it is c++ right? Why don't they use c#?

[Jazper]

maybe in c++ you can access directX a bit faster. but i'm sure games in C#
are coming very soon!
"Van Nastring" <va*@yahoo.com> wrote in message
news:br************@ID-198839.news.uni-berlin.de...

I believe it is c++ right? Why don't they use c#?

[Erik Frey]

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

"Van Nastring" <va*@yahoo.com> wrote in message
news:br************@ID-198839.news.uni-berlin.de...

I believe it is c++ right? Why don't they use c#?

[Peter Rilling]

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).

"Erik Frey" <er*******@hotmail.com> wrote in message
news:e5**************@TK2MSFTNGP10.phx.gbl...

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

"Van Nastring" <va*@yahoo.com> wrote in message
news:br************@ID-198839.news.uni-berlin.de...

I believe it is c++ right? Why don't they use c#?

[Erik Frey]

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/ep...37/default.asp

"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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).

"Erik Frey" <er*******@hotmail.com> wrote in message
news:e5**************@TK2MSFTNGP10.phx.gbl...

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

"Van Nastring" <va*@yahoo.com> wrote in message
news:br************@ID-198839.news.uni-berlin.de...

I believe it is c++ right? Why don't they use c#?

[Cowboy \(Gregory A. Beamer\)]

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!
************************************************** ********************

"Van Nastring" <va*@yahoo.com> wrote in message
news:br************@ID-198839.news.uni-berlin.de...

I believe it is c++ right? Why don't they use c#?

[Greg Merideth]

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.
Cowboy (Gregory A. Beamer) wrote:

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.

[Matthew W. Jackson]

"Greg Merideth" <gm*******@removethis.uclabs.com> wrote in message
news:Cs********************@comcast.com...

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.

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

[Van Nastring]

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#?

"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in message
news:FA*******************@twister.austin.rr.com.. .

"Greg Merideth" <gm*******@removethis.uclabs.com> wrote in message
news:Cs********************@comcast.com...

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.
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

[Matthew W. Jackson]

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).

"Van Nastring" <va*@yahoo.com> wrote in message
news:bs************@ID-198839.news.uni-berlin.de...

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#?

"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in message news:FA*******************@twister.austin.rr.com.. .

"Greg Merideth" <gm*******@removethis.uclabs.com> wrote in message
news:Cs********************@comcast.com...

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.
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

[Matthew W. Jackson]

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

"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in message
news:6e*****************@fe1.texas.rr.com...

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).

"Van Nastring" <va*@yahoo.com> wrote in message
news:bs************@ID-198839.news.uni-berlin.de...

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#?

"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in

message

news:FA*******************@twister.austin.rr.com.. .

"Greg Merideth" <gm*******@removethis.uclabs.com> wrote in message
news:Cs********************@comcast.com...
> 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.
>
>

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

[Dave]

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.
"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in message
news:vm******************@fe1.texas.rr.com...

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

"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in message news:6e*****************@fe1.texas.rr.com...

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).
"Van Nastring" <va*@yahoo.com> wrote in message
news:bs************@ID-198839.news.uni-berlin.de...

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#?

"Matthew W. Jackson" <th********************@NOSPAM.NOSPAM> wrote in

message

news:FA*******************@twister.austin.rr.com.. .
> "Greg Merideth" <gm*******@removethis.uclabs.com> wrote in message
> news:Cs********************@comcast.com...
> > 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.
> >
> >
>
> 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
>
>