gamedevlists-general — List for discussing general game development issues

Re: [GD-General] C# versus C++ for game engines

[Mike W. <mi...@ub...>]

>
>
>Is the Mono project "reverse engineering" anything, or 
>are participants simply implementing a public-domain
>specification?
>
yeah i'm not sure what microsoft's concerns are, besides the fact that 
MS hasn't been able to milk the mono guys out of some kind of 'license' 
fee or something to get the rights to implement ms tech on linux (like 
they are currently doing for windowsmedia licensees)

>I don't know if anyone on this list would know, but...
>Is it considered "reverse engineering" or some other kind
>of intellectual property violation to re-implement an
>API from scratch?  In other words, can it be illegal to
>deploy an API with the same class names and method 
>names as some other existing API?  (I assume this 
>doesn't apply when the API has been submitted for
>standardization.  Right?)
>  
>
the api is not patentable, only the implementation i believe...for 
example the wine project isn't a reverse engineering of anything, simply 
a reimplementation of the windows api on linux...it's the technical 
details that make the world of difference...the wine guys haven't tried 
to make a binary-exact copy of the source, just reinterpreting the API 
'their way'...

>This is veering off-topic, I know, but this relates to
>the concern that C# cannot be used for cross-platform
>game engines (e.g., Windows and Linux).  I know that
>most people mean "consoles" when they say "cross-platform"
>in the video game industry.  
>
i'm not sure about that....there's a reason the majority of servers are 
running linux versions these days - EVEN with the new console online 
ventures...of course xbox developers probably don't get this option 
(surprise, surprise)

mike w
www.uber-geek.ca

Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

>>> except that microsoft has declared that they will be suing
>>> and attacking any attempts at reverse engineering their
>>> .net technology...
>>> 
>>> the mono project seems doomed to failure as a result.

Here's a quote from the March 2002 book "C# in a Nutshell:
A Desktop Quick Reference" (published by O'Reilly):

  [On page 11, in a section entitled "ECMA Standardization"]

  "However, this openness was taken to a new level in 
  November 2000 when Microsoft, along with co-sponsors
  Intel and HP, officially submitted the specifications
  for the C# language, a subset of the FCL, and the
                       -------------------
  runtime environment to ECMA for standardization."

  [NOTE: I added the underline to draw your attention
  to a phrase.]

FCL stands for Framework Class Library, which includes
the reflection, stack trace, thread, socket, and
collection API's, among thousands of other classes.
Was the "subset of the FCL" that Microsoft submitted 
to the ECMA so small that it did not include reflection
or stack tracing ability?

Is the Mono project "reverse engineering" anything, or 
are participants simply implementing a public-domain
specification?

I don't know if anyone on this list would know, but...
Is it considered "reverse engineering" or some other kind
of intellectual property violation to re-implement an
API from scratch?  In other words, can it be illegal to
deploy an API with the same class names and method 
names as some other existing API?  (I assume this 
doesn't apply when the API has been submitted for
standardization.  Right?)

This is veering off-topic, I know, but this relates to
the concern that C# cannot be used for cross-platform
game engines (e.g., Windows and Linux).  I know that
most people mean "consoles" when they say "cross-platform"
in the video game industry.  It might be a while before
we see the Common Language Runtime (CLR) and portions
of the Framework Class Library (FCL) implemented for
PlayStation 2\3 and GameCube, but I suppose X-Box
developers might already be using C#.

--- Colin

cp...@ea...

[Secret irrelevant sub-thread continues:]
<useless_wacky_factoids>
P.S.: I like Chevron with Techron, but it's probably 
due to the fact that the station is about 200 yards
from my apartment, and has a pretty glow at
night...and it's one of the few places in Irvine
where one can buy a Coke at 3 A.M. (other than 
Ralph's and Denny's).
</useless_wacky_factoids>

Re: [GD-General] C# versus C++ for game engines

[Thatcher U. <tu...@tu...>]

On Feb 20, 2003 at 06:45 -0800, Colin Fahey wrote:
> 
> > > One thing I really like about C# is the crash tracing for release
> > > builds.  Creating a similar feature in C++ is VERY platform
> > > dependent, and I think you need to generate a *.PDB file with all of
> [...]
> > You need to keep some symbols around to pull up the crash report in
> > the debugger, but you don't have to distribute them.  Bruce Dawson
> [...]
> 
> > It's Windows-specific (but then so is .NET -- not sure why you say
> > platform-dependence is a disadvantage of stack-unwinding). [...]
> 
> If you have the Mono version of the .NET API under Linux, then
> you can enjoy the same stack unwinding.
> 
> Also, if you can get your .NET application to run under Windows 98
> (something I haven't determined yet), then you enjoy the same
> stack unwinding there, too.  Whereas the DbgHlp.dll is a little bit 
> messed up under Windows 98.

Could be, although I was using Win98 back when I stole that
exceptionhandler code, and it seemed to work OK.  I don't remember any
details though...

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] C# versus C++ for game engines

[Parveen K. <pk...@al...>]

On Thu, 2003-02-20 at 20:03, Mike Wuetherick wrote:
> >
> >
> >If you have the Mono version of the .NET API under Linux, then
> >you can enjoy the same stack unwinding.
> > =20
> >
> except that microsoft has declared that they will be suing and attacking=20
> any attempts at reverse engineering their .net technology...
>=20
> the mono project seems doomed to failure as a result.

There are two seperate issues here.  C# is an ISO standard.
http://msdn.microsoft.com/net/ecma/

I don't know what the point or the benefit of .NET will be to me.  I
don't think MS knows either.  A lot of buzzwords and spin is flying all
over the place.

Writing code in one language, calling it from another language, with a
GUI written in another language.  That's pretty cool.

Garbage collection...big deal.  Been done before, not really beneficial
for most projects that I would be involved in.  I can search google for
"C++ garbage collector" and get tons of hits and choose a GC if I
really, really needed one.  Sure that's kind of a hack...but whatever.=20
But I can also choose to use handles or smart pointers.

There's a lot of cruft in C++ but that's because it's a pretty mature
lanuage.  Java is acquiring cruft.  And C# will acquire cruft as well.

=46rom the projects that I have worked on.  The success of a project
doesn't really depend on the "sexiness" of a language.  It usually
depends on the level of experience the developers have with the chosen
language.  How many C# developers can you find with 10 years of
experience?

Having said all that, I'd consider C# if there were compilers for more
platforms.  That would guarantee it will be around for 10 years or so.=20
But right now, I see it as developers using it as a more powerful
replacement for VB.

A bunch of my friends in business-software land are using C# as a
replacement for Java for apps that aren't expected to be ported.

The big benefit of C# and Java are the big class libraries.  Hopefully
the next C++ standard standardizes a lot of stuff from Boost and other
libraries.  There are benefits to having access to a widely understood,
used, and debugged library.  And you can choose to ignore the library if
you wish.

PK
www.sfu.ca/~pkaler

Re: [GD-General] C# versus C++ for game engines

[Mike W. <mi...@ub...>]

>
>
>If you have the Mono version of the .NET API under Linux, then
>you can enjoy the same stack unwinding.
>  
>
except that microsoft has declared that they will be suing and attacking 
any attempts at reverse engineering their .net technology...

the mono project seems doomed to failure as a result.

mike w
www.uber-geek.ca

Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

> > One thing I really like about C# is the crash tracing for release
> > builds.  Creating a similar feature in C++ is VERY platform
> > dependent, and I think you need to generate a *.PDB file with all of
[...]
> You need to keep some symbols around to pull up the crash report in
> the debugger, but you don't have to distribute them.  Bruce Dawson
[...]

> It's Windows-specific (but then so is .NET -- not sure why you say
> platform-dependence is a disadvantage of stack-unwinding). [...]

If you have the Mono version of the .NET API under Linux, then
you can enjoy the same stack unwinding.

Also, if you can get your .NET application to run under Windows 98
(something I haven't determined yet), then you enjoy the same
stack unwinding there, too.  Whereas the DbgHlp.dll is a little bit 
messed up under Windows 98.

--- Colin

cp...@ea...

Re: [GD-General] C# versus C++ for game engines

[Thatcher U. <tu...@tu...>]

On Feb 20, 2003 at 10:37 -0800, Colin Fahey wrote:
> 
> One thing I really like about C# is the crash tracing for release
> builds.  Creating a similar feature in C++ is VERY platform
> dependent, and I think you need to generate a *.PDB file with all of
> your symbols, along with the DbgHlp.dll.

You need to keep some symbols around to pull up the crash report in
the debugger, but you don't have to distribute them.  Bruce Dawson
wrote a little article in Game Developer a few years ago, about crash
tracing for release builds of C++ apps.  I borrowed the code, and here
it is in Soul Ride's CVS:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/soulride/soulride/src/exceptionhandler.hpp?rev=HEAD&content-type=text/vnd.viewcvs-markup

It's Windows-specific (but then so is .NET -- not sure why you say
platform-dependence is a disadvantage of stack-unwinding).  Basically
when you get a crash report from a user, you load up the old symbols
in MSVC, punch the EIP value into the registers window, and you're
looking at the crash site.

For the record, I'm a satisfied user of Texaco gasoline and petroleum
products.

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

[NOTE: I'm sorry about the irrelevant comments regarding
certain Microsoft products.]

One thing I really like about C# is the crash tracing
for release builds.  Creating a similar feature in
C++ is VERY platform dependent, and I think you need
to generate a *.PDB file with all of your symbols,
along with the DbgHlp.dll.  It's a fact that sometimes
a crash bug only appears in the release version of
the application.  Sometimes the crash occurs on a
test machine that doesn't have Visual Studio, and
sometimes it is difficult to do remote debugging.
Yes, applications should handle all exceptions,
but even so, you can log the exception in plain
text form for study, or users in the field can 
transmit the stack trace to you.  This stack trace
may still be relevant even if you are still making
changes to the code.

Reflection is also very cool.  With an in-game editor
you can get information about game objects, or manipulate
objects.  Doing something like this in C++ requires 
a lot of discipline and extra code, or *.PDB or *.MAP
files in conjunction with a symbol parsing mechanism
like the one used by the FuBi library.

I regard garbage collection as a nice safety net just
in case someone forgets to free a memory allocation.
In C++ you would have to write your own memory
manager, or create memory buffer objects that get
destroyed when out of scope, or use smart pointers,
etc, to get some assurance that an allocation won't
slip through the cracks.

Maybe it doesn't rank high on the list of good reasons
to switch to C#, but it is nice that there is no such 
thing as a "header" file (*.H) in C#.  It's a bit of
a pain to keep the *.CPP and *.H files synchronized;
it's just a chore.

C# offers a huge set of very convenient API's.
You can add FTP, ZIP, HTTP, XML, etc, to your
game quite easily.  The contanier classes and
string class have many interesting methods.
Gone are the days of having to typedef your
own primitive data types (INT16, UINT32, 
FLOAT32, etc) to prevent platform dependencies!

The strictness of the C# compiler means that there
will be fewer silly errors that wasted ENORMOUS
amounts of time on C/C++ projects.  I think that
this aspect alone makes switching to C# worthwhile
for new PC projects.  I was on a 9-month project
for a major publisher, and during the last three
months, when the entire team was living at the
office, I think I spent half the time fixing
SILLY bugs caused by uninitialized variables,
etc.  All such errors would have been impossible
with C#, since the compiler is strict about
initializing variables, type safety, use of
boolean in conditional expressions, no more
"fall through" in switch cases, and the option
of explicitly designating parameters as input
or output.

My post was written to solicit responses from people
who had written game engine code in C# to learn about
their experiences.  For some people, the transition
to C# doesn't make sense;  I won't argue that.
I'm interested in hearing about actual C# game engine
experiences.

--- Colin

cp...@ea...

P.S.:  For the record, I am a happy Windows
programmer, and I use many Microsoft products
(Visual Studio .NET, MS-Office), and I really
like Windows 2000.  I bought all Microsoft
software from stores at retail prices, going
back to Visual Studio 4.0 and Windows 95 on
my first PC.  I have fifty books on various
aspects of Windows programming and software.
I really like Win32, DirectSound, WinSock,
VfW / DirectShow, MFC, etc.

It so happens that I have also done a lot of
Linux programming, too, including kernel mode
software, video capture drivers, etc.  I am
a big fan of Linux, and I hope the Mono
project is a big success so that my C# code
will work under Linux, too.

Everyone has their gripes about software products,
and I'm sorry that I shared a couple of my
gripes about certain Microsoft products.
But "Microsoft-bashing"?  I don't think any
intelligent person could accept broad generalizations
about a corporation or its products, but at the
same time I'm not ashamed to share my feelings
about specific aspects of products that I think
are mistakes, even if features can theoretically
be "turned off" (burden on consumer), etc.

Anyhow, I know all of this is not appropriate
for this forum.  I just want to point out that
my previous remarks weren't meant to fuel any
silly generalized dislike (or like) of Microsoft.

RE: [GD-General] C# versus C++ for game engines

[Timur D. <ti...@cr...>]

Unlikely C# will become portable in any foreseeable future,
Which in my opinion will successfully rule it out from majority of game =
engines.

Although language itself is with no doubt very cool.

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: Thursday, February 20, 2003 5:32 PM
> To: gam...@li...
> Subject: Re: [GD-General] C# versus C++ for game engines
>=20
>=20
> Noel Llopis <ll...@co...> wrote:
>=20
> >> I strongly believe that C# is a worthy successor to C++,
> >
> > This is a serious question, not an attempt at trolling. I have read
> > some about C# and I really don't see what the big deal is for most
> > game programming. The way I see it, changing languages is something
> > that will be painful and cause a medium-term productivity loss, so
> > there must be some *extremely* compelling reasons to change.
>=20
> Overall I like C# a lot, and I think that given a few years to reach
> maturity (anyone remember C++ without multiple inheritance or=20
> templates?) it
> will be a fantastic language. The fact that module interfaces=20
> are compiled
> into the binary instead of relying on the archaic "include" method is
> definitely a huge step forward from C++. Attributes and=20
> reflection should
> make interfacing with other languages / tools much easier,=20
> too. I like the
> fact that some patterns (Interfaces for example) are burned into the
> language.
>=20
> The problems you point out, however, make its adoption=20
> unadvisable for most
> game projects. There is not a lot of productivity to gain=20
> compared to the
> costs involved. I wonder if this situation will remain the=20
> same in, say, 5
> years.
>=20
> > Automatic garbage collection... shrug. It really doesn't seem that
> > much of a big deal. Do people spend all that much time with memory
> > problems in their apps?
>=20
> Certainly not. If a game developer has trouble with memory=20
> management /
> leaks, I'm sure that is only the tip of a huge iceberg of=20
> problems waiting
> to show up.
>=20
>   Javier Arevalo
>   Pyro Studios
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

RE: [GD-General] C# versus C++ for game engines

[Kyle W. <ky...@ga...>]

Noel wrote:
> Automatic garbage collection... shrug. It really doesn't seem that much
> of a big deal. Do people spend all that much time with memory problems
> in their apps?

Amen.  Memory is a resource like any other.  If you're unable to keep from
leaking memory, then God only knows what else you're leaking in the way of
handles, locks, etc.

Kyle

Re: [GD-General] C# versus C++ for game engines

[Javier A. <ja...@py...>]

Noel Llopis <ll...@co...> wrote:

>> I strongly believe that C# is a worthy successor to C++,
>
> This is a serious question, not an attempt at trolling. I have read
> some about C# and I really don't see what the big deal is for most
> game programming. The way I see it, changing languages is something
> that will be painful and cause a medium-term productivity loss, so
> there must be some *extremely* compelling reasons to change.

Overall I like C# a lot, and I think that given a few years to reach
maturity (anyone remember C++ without multiple inheritance or templates?) it
will be a fantastic language. The fact that module interfaces are compiled
into the binary instead of relying on the archaic "include" method is
definitely a huge step forward from C++. Attributes and reflection should
make interfacing with other languages / tools much easier, too. I like the
fact that some patterns (Interfaces for example) are burned into the
language.

The problems you point out, however, make its adoption unadvisable for most
game projects. There is not a lot of productivity to gain compared to the
costs involved. I wonder if this situation will remain the same in, say, 5
years.

> Automatic garbage collection... shrug. It really doesn't seem that
> much of a big deal. Do people spend all that much time with memory
> problems in their apps?

Certainly not. If a game developer has trouble with memory management /
leaks, I'm sure that is only the tip of a huge iceberg of problems waiting
to show up.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] C# versus C++ for game engines

[Noel L. <ll...@co...>]

On Thu, 20 Feb 2003 04:41:39 -0800
Colin Fahey <cp...@ea...> wrote:

> I strongly believe that C# is a worthy successor to C++,

[big snip]

What exactly do you find so outstanding in C# that you're willing to:
- Learn a new language
- Give up on lots of platforms
- Give up on lots of existing libraries
- Give up on lots of development tools
- Give up on years of expertise from your team
- Give up on a mature language with its own idioms and documentation.
- Give up on a standardized language and adopt a proprietary one

This is a serious question, not an attempt at trolling. I have read some
about C# and I really don't see what the big deal is for most game
programming. The way I see it, changing languages is something that will
be painful and cause a medium-term productivity loss, so there must be
some *extremely* compelling reasons to change.

Automatic garbage collection... shrug. It really doesn't seem that much
of a big deal. Do people spend all that much time with memory problems
in their apps?

Easier interoperatibility with .NET? Maybe OK for tools, but probably
not necessary for most games (especially not console games).

What other reasons are there?


--Noel
ll...@co...

[GD-General] Microsoft bashing...

[Gareth L. <GL...@cl...>]

Is this really the forum ? Doesn't Slashdot have an entire website dedicated
to it ?

I'm not even going to argue with your rants, just two things

How is "Left handed coordinate system" backwards ?
You can turn off XP's phone home stuff.

Regards, Gareth Lewin
Happy user of windows xp, directx, and xbox.

Re: [GD-General] C# versus C++ for game engines

[Javier A. <ja...@py...>]

Colin Fahey <cp...@ea...> wrote:

> continue using OpenGL for rendering (via my own wrapper)
> because I find many aspects of Direct3D annoying and
[Fairly unnecessary rant removed]

> One of my own concerns is that I wasn't able to immediately
> execute a release build version of a C# application
> under Windows 98.

Nor would you be able to under a fresh Windows 2000, not sure about XP. You
need to install the .NET runtime redistributable in order to run .NET
programs. I have never checked, but I'm prety sure that .NET supports Win98
and WinMe.

>   (On a side note, I will AVOID upgrading from Windows 2000
[Fairly unnecessary rant removed]

> I am also concerned about performance.  I have done some
> Google searching for performance test results.  The few
> test results I have encountered seem to indicate that the
> raw processing speed of C# is comperable to C/C++.  However,
> the "non-deterministic" (as far as the programmer is concerned)
> garbage collection seems to lead to a quadratic increase in
> execution time, and large spikes in memory usage, for
> applications that do large amounts of memory-related
> operations.

I recall some people have been figuring out ways to make the gc run in a
more consistent manner, and I assume that the .NET runtime will be adding
support for that kind of operations. You should be able to find about this
possibly in the csharp mailing lists or newsgroups.

  Javier Arevalo
  Pyro Studios

[GD-General] Re: C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

By the way, I am already aware of the ExoCortex engine,
and I can search for other C# game engines, so I am only
interested in hearing about personal C# experience,
particularly if you had any serious peeves or
problems...

--- Colin

cp...@ea...

P.S.: There were two significant spelling errors in my
previous e-mail message:

  INCONSISTENT:  comittment
   (CONSISTENT:  commitment)

  INCONSISTENT:  comperable
   (CONSISTENT:  comparable)

Did you catch them?  Add 10 points to your score!

[GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

I strongly believe that C# is a worthy successor to C++,
and my experience of programming in C# has been positive.
The DirectX 9 demonstration programs in C# are impressive,
mostly because they show Microsoft's comittment to making
it easy to use DirectX API's in C# applications.  I may
continue using OpenGL for rendering (via my own wrapper)
because I find many aspects of Direct3D annoying and 
backwards (like the left-handed coordinate system, lost
surfaces, bugs in API that can crash your application,
and general pointless complexity).

I am wondering if anyone has been seriously burned or
frustrated with their own attempt to code a game engine
or complex real-time application in C#.

One of my own concerns is that I wasn't able to immediately
execute a release build version of a C# application
under Windows 98.  (MSCOREE.DLL is the first required DLL
to not be found.  There are potentially dozens of DLL's
required to get a release version C# application to run
under Windows 98.  I haven't explored this yet.)
Yes, Windows 98 may have an "End Of Life" status.
Nonetheless, I am interested in supporting a platform
that still has a significant percentage of the gamer
market.

  (On a side note, I will AVOID upgrading from Windows 2000
  to Windows XP as long as it is practical, because I do not
  like the information gathering, "calling home", and some other
  "innovations".  I am not anti-Microsoft, but I don't like
  the lack of respect for user privacy or security embodied
  in certain products.  Okay, maybe I'll get Windows XP
  for "platform testing" since XP is perhaps the top OS
  for today's gamers.)

I am also concerned about performance.  I have done some
Google searching for performance test results.  The few
test results I have encountered seem to indicate that the
raw processing speed of C# is comperable to C/C++.  However,
the "non-deterministic" (as far as the programmer is concerned)
garbage collection seems to lead to a quadratic increase in
execution time, and large spikes in memory usage, for 
applications that do large amounts of memory-related
operations.

I guess the only way to really know the facts is to
write applications in C# that capture the essence of
what I intend to do in a more elaborate application
and see how well it turns out after trying my best
to code in the C# idiom and optimize.  And then there's
the issue of supporting Windows 98...  Maybe that's
as absurd as a rendering engine that is capable of
falling back on software rendering to cover the case
of a person who doesn't have a $49 GeForce3 card.

But I'd still like to learn about any success / horror
experiences with C# "real-time" game coding anyone
might have.

--- Colin

cp...@ea...

RE: [GD-General] Multiple Inheritance and RTTI

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

<sigh>  Saying that it's "utterly pointless" was just really uncalled
for on my part.  I've been reading too much Usenet lately.
 
Now, with my hyperbole filter properly reseated...

I don't say that ATL must be used, but I wouldn't want to preclude it
either.  And it just seems to me that COM compliance leaves open a lot
of interesting interop and remoting scenarios.  

These days I'd be leaning towards .NET interop.  Like maybe writing unit
tests in C#.  The results could be logged to a database, it could fire
off an e-mail, the tests could be remotely managed, etc.  It's not that
you couldn't do these things by other means, but in .NET, interop with
COM is pretty painless and these sorts of things are so easy it's almost
fun.  When features are easy to implement, you tend to have them.
 
One client-server game I was on used COM interfaces with a custom
remoting layer for communication.  This enabled us to run the client and
server across the Net or in the same process, talking directly over
their vtables, and for the most part it just worked.  The proxy and stub
classes were custom but still auto-generated from type info, which
streamlined things a lot -- just change the IDL and update the
implementers and everything else is automatic.  We also used this for
remote management of the server.  But -- we used COM only for things we
needed to expose or thought we might expose in the future, like for
testing.

I'd love to do something similar with a single-player game/client.  Say
you're playing the game and you see something anomalous, so with the
game running you pop up some IM-like thing and ping your teammate who
may be on VPN, and for them the IM-like thing shows what's basically a
management console.  In one pane they see a screenshot updated every
second or so, and in the same UI they can poke around in the game state,
maybe remotely control the game, and so on.  The applications for QA are
obvious.

Donavon

P.S. IIRC, you don't need IDispatch as of VB6, but you would need a
typelib, and VB has some pretty severe type restrictions.


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Paul Bleisch
> Sent: Monday, February 10, 2003 1:27 PM
> To: gam...@li...
> Subject: RE: [GD-General] Multiple Inheritance and RTTI
> 
> 
> It becomes slight less pointless when your platform changes and
> your new platform doesn't support COM (or the ATL headers don't
> compile on it properly).
> 
> Not that that would happens often.
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: brian sharon [mailto:pud...@po...]
> > Sent: Monday, February 10, 2003 1:15 PM
> > To: gam...@li...
> > Subject: Re: [GD-General] Multiple Inheritance and RTTI
> >
> >
> > There's a bit more to full COM interop than that, and in my
> > opinion it
> > mostly adds baggage that you don't want or need.  For
> > instance, all your
> > methods need to return HRESULTs and the real results in out
> > parameters
> > (after all, you never know when that pesky DCOM marshaler is going
to
> > fail to connect to the IRenderer object running on some other
machine
> > :).  Imagine having to change all function calls like
> > "interface->GetCountOfSomething()" to
> >
> >     int count;
> >     HRESULT hr;
> >     hr = interface->GetCountOfSomething(&count);
> >     if (SUCCEEDED(hr) {
> >         ...
> >
> > Blech.
> >
> > You would also want to define your interfaces in MS IDL to generate
> > typelibs for IDispatch (which Visual Basic would need).  By
> > contrast the
> > approaches discussed here wouldn't even require a windows box
> > to compile
> > IDL files on, just straight C++.
> >
> > So it might have been pointless, but not <i>utterly</i>
> > pointless  :).
> >
> > --brian
> >
> > Donavon Keithley wrote:
> >
> > >Instantiating a class by some means other than
> > CoCreateInstance[Ex] is
> > >not re-implementing COM.  Many, many standard COM objects are not
> > >co-creatable (if I remember the jargon correctly).  Like... D3D,
for
> > >instance.
> > >
> > >COM only has a few mandatory rules, like implementing IUnknown and
> > >adhering to certain QueryInterface semantics.  It's not much of an
> > >imposition and it leaves you open to interoperating with the
> > rest of the
> > >COM world.  Implement a typelib and adhere to some basic
> > type rules and
> > >your objects will be callable from Visual Basic and .NET.
Implement
> > >IDispatch and you open your objects up to the scripting world.
> > >
> > >Just don't do what one company I know did, and that's
> > redefine IUnknown.
> > >They called it "IUnknown", it had QI, AddRef, and Release,
> > but IIDs were
> > >strings, not GUIDs.  So their "custom" COM system looked
> > just like COM,
> > >but it was totally incompatible.  There was no possibility of
interop
> > >and where they could have taken advantage of ATL's rich set
> > of classes,
> > >they instead had to redefine their own macros and template classes.
> > >
> > >It was an utterly pointless exercise in NIH.
> > >
> > >Donavon
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: gam...@li...
> > >>[mailto:gam...@li...]
> > On Behalf Of
> > >>Gareth Lewin
> > >>Sent: Thursday, February 06, 2003 4:31 AM
> > >>To: gam...@li...
> > >>Subject: RE: [GD-General] Multiple Inheritance and RTTI
> > >>
> > >>COM basics are extremly simple to implement.
> > >>
> > >>You really need a standard way to implement a "Give me this
> > interface"
> > >>function. (QueryIterface)
> > >>A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> > >>And a base interface that concreate class implements.  (IUnknown)
> > >>
> > >>A lot of COM also uses Factories, Ref counting and sometimes smart
> > >>pointers.
> > >>They are not needed, but tend to fit well ( For example ref
counting
> > >>
> > >>
> > >works
> > >
> > >
> > >>nice with QueryInterface because you might have a few interfaces
to
> > >>
> > >>
> > >the
> > >
> > >
> > >>same
> > >>object ).
> > >>
> > >>Again, Inside COM is a must read if you plan on having a COM like
> > >>
> > >>
> > >system.
> > >
> > >
> > >>>-----Original Message-----
> > >>>From: gekido [mailto:mi...@ub...]
> > >>>Sent: 05 February 2003 21:30
> > >>>To: gam...@li...
> > >>>Subject: Re: [GD-General] Multiple Inheritance and RTTI
> > >>>
> > >>>
> > >>>with this said, anyone know of any opensource projects
> > >>>implementing a base
> > >>>COM-style cross-platform & cross-compiler library out there?
> > >>>
> > >>>surely there must be someone that's done the hard part for us ;}
> > >>>
> > >>>just curious
> > >>>
> > >>>mike w
> > >>>www.uber-geek.ca
> > >>>
> > >>>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] opensource for online play

[Mike W. <mi...@ub...>]

Tom Hubina wrote:

> At 02:14 AM 2/10/2003, you wrote:
>
>> Hey all.
>>
>> We've been slowly setting up the inner workings of the network play 
>> for our engine. One thing that has come up is the fact that our 
>> engine also happens to be Open Source, so how do we deal with 
>> security issues for hacking online games when we are giving the 
>> hackers all of our source code.
>
>
> I don't believe an OpenSource FPS can work without rampant cheating.
>
> Let's say you're smart enough not to put any kind of authority for 
> movement, heath, hit/miss, etc on the client. That means that you have 
> to validate everything that comes from the client. Source code 
> validation of any kind (CRC, run time code queries, whatever) just 
> won't work so let's assume for the moment that you do as much client 
> validation as is reasonable on the server in an attempt to identify 
> hackers. You have limits because you have to deal with fairly high 
> latency players with packetloss problems and slightly out of sync 
> clients. This slack and the fact that all rendering is done on the 
> client opens the door for some fairly serious hacks that would destroy 
> gameplay for non-cheaters. 

i agree, which is why i was asking the question ;}

> The following things are what I would hack if I wanted an unfair 
> advantage over others, and you'd be practically unable to detect it 
> without hurting legit players:
>
> 1. I'd use partial transparency on the walls to uncover hidden 
> opponents... and thus be able to track them and shoot them the second 
> they became "visible". You can address this by only sending position 
> information from the server on people that are actually visible, but 
> that has implications for shadows, sounds, and other things that 
> happen outside the direct view of the client but still require the 
> client to know the position of. It also means that people would "pop" 
> into view when they came around a corner due to latency issues

could see this being pretty useful though...hmm....

> 2. I'd use auto-targeting to always get a head shot. Basically, when I 
> fired I'd look to see what targets were close to what I was shooting 
> at, then orient the player to make a head shot right before the "fire" 
> packet was sent out. Even a 10% improvement in targeting here can make 
> a HUGE difference and could be pretty damn hard to catch on the server.

this is a problem we run into on our counter-strike servers all the 
time...only the ability for an admin to shadow players seems to be an 
effective counter...

> 3. I'd perturb the player position .. basically makes the player hop 
> all over the damn place so others can't target him, but within a small 
> area that should be within normal "jitter" for a low latency/lossy 
> connection to make detection more difficult. However, the real player 
> would be running at full speed and clean. You can attempt to catch 
> this by comparing jitter to latency/packetloss, but those things can 
> also be simulated on the client with ease and still allow the client 
> to make sure the "important" packets (the ones when firing happens) 
> are correct and fast.
> These are only a few things that I could think of off the top of my 
> head. I'm sure players would find a ton more things to screw with. In 
> short, it isn't about security as much as it is about players being 
> able to take the information you give them and gain an unfair 
> advantage over other players.

good point...

> Basically, once you hand the player an executable they can hack the 
> hell out of it to do what they want, but there's at least some limits 
> and difficulties involved because they have to shoehorn whatever 
> they're doing into the base executable. Any new executables mean the 
> work has to be repeated. Once you hand them the source code, things 
> become an order of magnitude easier for them, and your ability to 
> stymie their efforts becomes significantly harder.

on thing i'm sorta hoping is that the hacking community won't be as 
interested in creating hacks for the game based on the very 'ease' of 
doing so...what fun is it to hack something that is handed to you on a 
plate like this?  

of course, this is mostly delusional, but can't hurt to hope ;}

one article that has been a major motivation to this line of thinking is 
this:

http://www.gamasutra.com/features/20011226/fitch_pfv.htm

thanx for your opinions...

mike w
www.uber-geek.ca

Re: [GD-General] opensource for online play

[Tom H. <to...@3d...>]

At 02:14 AM 2/10/2003, you wrote:
>Hey all.
>
>We've been slowly setting up the inner workings of the network play for 
>our engine. One thing that has come up is the fact that our engine also 
>happens to be Open Source, so how do we deal with security issues for 
>hacking online games when we are giving the hackers all of our source code.

I don't believe an OpenSource FPS can work without rampant cheating.

Let's say you're smart enough not to put any kind of authority for 
movement, heath, hit/miss, etc on the client. That means that you have to 
validate everything that comes from the client. Source code validation of 
any kind (CRC, run time code queries, whatever) just won't work so let's 
assume for the moment that you do as much client validation as is 
reasonable on the server in an attempt to identify hackers. You have limits 
because you have to deal with fairly high latency players with packetloss 
problems and slightly out of sync clients. This slack and the fact that all 
rendering is done on the client opens the door for some fairly serious 
hacks that would destroy gameplay for non-cheaters.

The following things are what I would hack if I wanted an unfair advantage 
over others, and you'd be practically unable to detect it without hurting 
legit players:

1. I'd use partial transparency on the walls to uncover hidden opponents... 
and thus be able to track them and shoot them the second they became 
"visible". You can address this by only sending position information from 
the server on people that are actually visible, but that has implications 
for shadows, sounds, and other things that happen outside the direct view 
of the client but still require the client to know the position of. It also 
means that people would "pop" into view when they came around a corner due 
to latency issues.

2. I'd use auto-targeting to always get a head shot. Basically, when I 
fired I'd look to see what targets were close to what I was shooting at, 
then orient the player to make a head shot right before the "fire" packet 
was sent out. Even a 10% improvement in targeting here can make a HUGE 
difference and could be pretty damn hard to catch on the server.

3. I'd perturb the player position .. basically makes the player hop all 
over the damn place so others can't target him, but within a small area 
that should be within normal "jitter" for a low latency/lossy connection to 
make detection more difficult. However, the real player would be running at 
full speed and clean. You can attempt to catch this by comparing jitter to 
latency/packetloss, but those things can also be simulated on the client 
with ease and still allow the client to make sure the "important" packets 
(the ones when firing happens) are correct and fast.

These are only a few things that I could think of off the top of my head. 
I'm sure players would find a ton more things to screw with. In short, it 
isn't about security as much as it is about players being able to take the 
information you give them and gain an unfair advantage over other players.

Basically, once you hand the player an executable they can hack the hell 
out of it to do what they want, but there's at least some limits and 
difficulties involved because they have to shoehorn whatever they're doing 
into the base executable. Any new executables mean the work has to be 
repeated. Once you hand them the source code, things become an order of 
magnitude easier for them, and your ability to stymie their efforts becomes 
significantly harder.

Tom

RE: [GD-General] Multiple Inheritance and RTTI

[Paul B. <pa...@mi...>]

It becomes slight less pointless when your platform changes and
your new platform doesn't support COM (or the ATL headers don't
compile on it properly).

Not that that would happens often.

Paul


> -----Original Message-----
> From: brian sharon [mailto:pud...@po...]=20
> Sent: Monday, February 10, 2003 1:15 PM
> To: gam...@li...
> Subject: Re: [GD-General] Multiple Inheritance and RTTI
>=20
>=20
> There's a bit more to full COM interop than that, and in my=20
> opinion it=20
> mostly adds baggage that you don't want or need.  For=20
> instance, all your=20
> methods need to return HRESULTs and the real results in out=20
> parameters=20
> (after all, you never know when that pesky DCOM marshaler is going to=20
> fail to connect to the IRenderer object running on some other machine=20
> :).  Imagine having to change all function calls like=20
> "interface->GetCountOfSomething()" to
>=20
>     int count;
>     HRESULT hr;
>     hr =3D interface->GetCountOfSomething(&count);
>     if (SUCCEEDED(hr) {
>         ...
>=20
> Blech. =20
>=20
> You would also want to define your interfaces in MS IDL to generate=20
> typelibs for IDispatch (which Visual Basic would need).  By=20
> contrast the=20
> approaches discussed here wouldn't even require a windows box=20
> to compile=20
> IDL files on, just straight C++. =20
>=20
> So it might have been pointless, but not <i>utterly</i>=20
> pointless  :). =20
>=20
> --brian
>=20
> Donavon Keithley wrote:
>=20
> >Instantiating a class by some means other than=20
> CoCreateInstance[Ex] is
> >not re-implementing COM.  Many, many standard COM objects are not
> >co-creatable (if I remember the jargon correctly).  Like... D3D, for
> >instance.
> >
> >COM only has a few mandatory rules, like implementing IUnknown and
> >adhering to certain QueryInterface semantics.  It's not much of an
> >imposition and it leaves you open to interoperating with the=20
> rest of the
> >COM world.  Implement a typelib and adhere to some basic=20
> type rules and
> >your objects will be callable from Visual Basic and .NET.  Implement
> >IDispatch and you open your objects up to the scripting world.
> >
> >Just don't do what one company I know did, and that's=20
> redefine IUnknown.
> >They called it "IUnknown", it had QI, AddRef, and Release,=20
> but IIDs were
> >strings, not GUIDs.  So their "custom" COM system looked=20
> just like COM,
> >but it was totally incompatible.  There was no possibility of interop
> >and where they could have taken advantage of ATL's rich set=20
> of classes,
> >they instead had to redefine their own macros and template classes. =20
> >
> >It was an utterly pointless exercise in NIH. =20
> >
> >Donavon
> >
> > =20
> >
> >>-----Original Message-----
> >>From: gam...@li...
> >>[mailto:gam...@li...]=20
> On Behalf Of
> >>Gareth Lewin
> >>Sent: Thursday, February 06, 2003 4:31 AM
> >>To: gam...@li...
> >>Subject: RE: [GD-General] Multiple Inheritance and RTTI
> >>
> >>COM basics are extremly simple to implement.
> >>
> >>You really need a standard way to implement a "Give me this=20
> interface"
> >>function. (QueryIterface)
> >>A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> >>And a base interface that concreate class implements.  (IUnknown)
> >>
> >>A lot of COM also uses Factories, Ref counting and sometimes smart
> >>pointers.
> >>They are not needed, but tend to fit well ( For example ref counting
> >>   =20
> >>
> >works
> > =20
> >
> >>nice with QueryInterface because you might have a few interfaces to
> >>   =20
> >>
> >the
> > =20
> >
> >>same
> >>object ).
> >>
> >>Again, Inside COM is a must read if you plan on having a COM like
> >>   =20
> >>
> >system.
> > =20
> >
> >>>-----Original Message-----
> >>>From: gekido [mailto:mi...@ub...]
> >>>Sent: 05 February 2003 21:30
> >>>To: gam...@li...
> >>>Subject: Re: [GD-General] Multiple Inheritance and RTTI
> >>>
> >>>
> >>>with this said, anyone know of any opensource projects
> >>>implementing a base
> >>>COM-style cross-platform & cross-compiler library out there?
> >>>
> >>>surely there must be someone that's done the hard part for us ;}
> >>>
> >>>just curious
> >>>
> >>>mike w
> >>>www.uber-geek.ca
> >>>     =20
> >>>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

Re: [GD-General] Multiple Inheritance and RTTI

[brian s. <pud...@po...>]

There's a bit more to full COM interop than that, and in my opinion it 
mostly adds baggage that you don't want or need.  For instance, all your 
methods need to return HRESULTs and the real results in out parameters 
(after all, you never know when that pesky DCOM marshaler is going to 
fail to connect to the IRenderer object running on some other machine 
:).  Imagine having to change all function calls like 
"interface->GetCountOfSomething()" to

    int count;
    HRESULT hr;
    hr = interface->GetCountOfSomething(&count);
    if (SUCCEEDED(hr) {
        ...

Blech.  

You would also want to define your interfaces in MS IDL to generate 
typelibs for IDispatch (which Visual Basic would need).  By contrast the 
approaches discussed here wouldn't even require a windows box to compile 
IDL files on, just straight C++.  

So it might have been pointless, but not <i>utterly</i> pointless  :).  

--brian

Donavon Keithley wrote:

>Instantiating a class by some means other than CoCreateInstance[Ex] is
>not re-implementing COM.  Many, many standard COM objects are not
>co-creatable (if I remember the jargon correctly).  Like... D3D, for
>instance.
>
>COM only has a few mandatory rules, like implementing IUnknown and
>adhering to certain QueryInterface semantics.  It's not much of an
>imposition and it leaves you open to interoperating with the rest of the
>COM world.  Implement a typelib and adhere to some basic type rules and
>your objects will be callable from Visual Basic and .NET.  Implement
>IDispatch and you open your objects up to the scripting world.
>
>Just don't do what one company I know did, and that's redefine IUnknown.
>They called it "IUnknown", it had QI, AddRef, and Release, but IIDs were
>strings, not GUIDs.  So their "custom" COM system looked just like COM,
>but it was totally incompatible.  There was no possibility of interop
>and where they could have taken advantage of ATL's rich set of classes,
>they instead had to redefine their own macros and template classes.  
>
>It was an utterly pointless exercise in NIH.  
>
>Donavon
>
>  
>
>>-----Original Message-----
>>From: gam...@li...
>>[mailto:gam...@li...] On Behalf Of
>>Gareth Lewin
>>Sent: Thursday, February 06, 2003 4:31 AM
>>To: gam...@li...
>>Subject: RE: [GD-General] Multiple Inheritance and RTTI
>>
>>COM basics are extremly simple to implement.
>>
>>You really need a standard way to implement a "Give me this interface"
>>function. (QueryIterface)
>>A standard way of iding interfaces (GUIDs or FourCCs or whatever)
>>And a base interface that concreate class implements.  (IUnknown)
>>
>>A lot of COM also uses Factories, Ref counting and sometimes smart
>>pointers.
>>They are not needed, but tend to fit well ( For example ref counting
>>    
>>
>works
>  
>
>>nice with QueryInterface because you might have a few interfaces to
>>    
>>
>the
>  
>
>>same
>>object ).
>>
>>Again, Inside COM is a must read if you plan on having a COM like
>>    
>>
>system.
>  
>
>>>-----Original Message-----
>>>From: gekido [mailto:mi...@ub...]
>>>Sent: 05 February 2003 21:30
>>>To: gam...@li...
>>>Subject: Re: [GD-General] Multiple Inheritance and RTTI
>>>
>>>
>>>with this said, anyone know of any opensource projects
>>>implementing a base
>>>COM-style cross-platform & cross-compiler library out there?
>>>
>>>surely there must be someone that's done the hard part for us ;}
>>>
>>>just curious
>>>
>>>mike w
>>>www.uber-geek.ca
>>>      
>>>

Re: [GD-General] opensource for online play

[Mike W. <mi...@ub...>]

Mads Bondo Dydensborg wrote:

>On Mon, 10 Feb 2003, Mike Wuetherick wrote:
>
>  
>
>>We've been slowly setting up the inner workings of the network play for 
>>our engine. One thing that has come up is the fact that our engine also 
>>happens to be Open Source, so how do we deal with security issues for 
>>hacking online games when we are giving the hackers all of our source code.
>>    
>>
>
>This have been discussed extensively on the LInux game related mailing 
>lists. The consensus seems to be that there is no way you can protect your 
>game, wheter closed or open, if you place any trust on the client. Open 
>source in general makes it easier.
>  
>
this is pretty much what we've come up with as well...somehow to make 
the clients a simple 'dumb terminal' that renders instructions sent to 
it by the server...

>>We've decided that the network side of things will be a .lib that we 
>>distribute, along with the source, for people that need to recompile the 
>>engine....most users don't, so this is no big deal...
>>    
>>
>If you have the stuff in a single file, you actually make it easier for 
>the cracker.
>
very good point...i'll pass that on to the programmers (i just come up 
with the dumb ideas and try to get them to make it work ;)

>> 
>>This still leaves us with the problem of having someone create a stub 
>>exe using our network lib to create hacker tools mind you...
>>    
>>
>
>Yes, not to mention intercepting system calls, using a scripted debugger, 
>etc etc.
>  
>
yeah it's not that difficult to do if you are really looking

>>Perhaps some sort of time/date stamp authentication, along with a check 
>>of the exe's size (to make sure it's not hacked), etc...but overall, 
>>none of these systems seem to respect our 'open source roots'...
>>    
>>
>
>And are easily fooled both for open and closed source.
>  
>
yes i would imagine, but it seems that valve and other companies do this 
type of thing with their games as at least a 'deterent' type of 
prevention...however 'effective' it might be...

>>screens of the multiplayer maps in action - 
>>http://www.uber-geek.ca/games/turing/ctf/
>>    
>>
>this gives a 404.
>
hmm...oops

www.uber-geek.ca/games/turing/screens/ctf/

forgot a directory in there.

>>anyways...i'm curious how (if) people have managed this before, and what 
>>techniques they've used to provide security for your client applications...
>>    
>>
>
>I am sure some will have more constructive answers than mine, but I 
>believe it boils down to minimize the trust in the client.
>  
>
yeah, i agree.  we'll have to focus specifically on this during the 
initial design...

cheers,

mike w
www.uber-geek.ca

Re: [GD-General] opensource for online play

[Mads B. D. <ma...@ch...>]

On Mon, 10 Feb 2003, Mike Wuetherick wrote:

> We've been slowly setting up the inner workings of the network play for 
> our engine. One thing that has come up is the fact that our engine also 
> happens to be Open Source, so how do we deal with security issues for 
> hacking online games when we are giving the hackers all of our source code.

This have been discussed extensively on the LInux game related mailing 
lists. The consensus seems to be that there is no way you can protect your 
game, wheter closed or open, if you place any trust on the client. Open 
source in general makes it easier.

> 
> We've decided that the network side of things will be a .lib that we 
> distribute, along with the source, for people that need to recompile the 
> engine....most users don't, so this is no big deal...

If you have the stuff in a single file, you actually make it easier for 
the cracker.
>  
> This still leaves us with the problem of having someone create a stub 
> exe using our network lib to create hacker tools mind you...

Yes, not to mention intercepting system calls, using a scripted debugger, 
etc etc.

> Perhaps some sort of time/date stamp authentication, along with a check 
> of the exe's size (to make sure it's not hacked), etc...but overall, 
> none of these systems seem to respect our 'open source roots'...

And are easily fooled both for open and closed source.

> screens of the multiplayer maps in action - 
> http://www.uber-geek.ca/games/turing/ctf/

this gives a 404.

> 
> anyways...i'm curious how (if) people have managed this before, and what 
> techniques they've used to provide security for your client applications...

I am sure some will have more constructive answers than mine, but I 
believe it boils down to minimize the trust in the client.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
The low quality of [MP3] files should prevent this format from threatening
control of our intellectual property. Why would anyone listen to a sub-CD
quality song when they can easily buy the CD at the local Tower Records?
                               - RIAA head, Hillary Rosen, March 1997

Re: [GD-General] Galaxy HQ, major trouble

[Mike W. <mi...@ub...>]

lol

good point...might want to turn down that mail filter setting, just in 
case...

Colin Fahey wrote:

>I guess that was the first time a game generally
>started to develop on the general game development list.
>
>Still, I'd be a little afraid to turn down messages from
>"Galaxy HQ"...  It just seems like we might one day
>miss a legitimate e-mail from Galaxy HQ, and maybe 
>not know about public hearings concerning the Soylent
>Green rollout plans, manditory "renewal" celebrations
>at Carousel when our lifeclocks reach "Red 6", and 
>possibly zoning decisions for Vogon interstellar
>freeways.
>
>Okay, okay, I'll just put the aluminum foil back
>on my head and tape an "X" on the window...
>I can't HANDLE the truth!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>.
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>
>  
>

Re: [GD-General] Galaxy HQ, major trouble

[Colin F. <cp...@ea...>]

I guess that was the first time a game generally
started to develop on the general game development list.

Still, I'd be a little afraid to turn down messages from
"Galaxy HQ"...  It just seems like we might one day
miss a legitimate e-mail from Galaxy HQ, and maybe 
not know about public hearings concerning the Soylent
Green rollout plans, manditory "renewal" celebrations
at Carousel when our lifeclocks reach "Red 6", and 
possibly zoning decisions for Vogon interstellar
freeways.

Okay, okay, I'll just put the aluminum foil back
on my head and tape an "X" on the window...
I can't HANDLE the truth!





































.