Quote:
just out of curiousity why did choose C instead of going with C++ and taking advantage of classes - something i would think would make more sense for a game like Halo. also if Halo 2 was in C++ how much was it to change code around for the OOP stuff? again just curious.

I'm fairly certain that zedz's original post was supposed to be a quote, although I'm not sure from where, because it conflicts with implications made by Mat Noguchi that the underlying code was at least compiled as C++ (or they faked a vtable implementation for manual dynamic dispatch).

[Edited by - jpetrie on June 5, 2007 2:28:52 PM]

Quote:I'm fairly certain that zedz's original post was supposed to be a quote, although I'm not sure from where, because it conflicts with implications made by Mat Noguchi that the underlying code was at least compiled as C++ (or they faked a vtable implementation for manual dynamic dispatch).

yes it was a quote, gdalgorithms list ( amazingly i remembered the conversation cause it was 5 years ago )

heres a reply from mat noguchi

Quote:
Given the target
platform (Xbox), there was no need to include a binary/text parser to
load and save game data.
....
Working on a code base developed and augmented over 10 years in
C was a lot more rewarding in terms of quality and style than any
project based in C++ I have worked on.

note im absolutely not advocating C in any way, i just wanted to correct the misinformation that halo was written in c++

Quote:Original post by DaBookshah

Quote:Original post by NickGravelyn
All managed code is compiled into the CLR code which can be de-compiled. However I've read there are numerous obfuscators that take care of this problem for when you wish to ship the game.

You should either do things properly or not at all. There do exist decent protection packages/encrypters for .net programs (an obsfucator doesn't count).

Then go for not-at-all. Any code that ships in a format that can ultimately be executed can be decoded/decrypted. Unless the encryption keys are held by the processor, the binary can be opened in a debugger or disassembled. Once you have the ability to disassemble the loader, you can either decode or decrypt the package that the loader will process. Once you have the package in the clear, you can proceed with normal reverse engineering.

Beyond that, obfuscators will be enough of a PITA to stop someone who doesn't have the right tools, and if they do have the right tools, it will be moments (or occasionally hours) of aggravation. If you do have something innovative enough to present a challenge, you will only attract the more competent attackers as they pick your 'protection' system apart for the fun of it.

If you are that worried about protecting your intellectual property, save the money you would spend on technology, and spend it on good lawyers instead. Sue (or at least C&D) anyone who uses your IP, and if they are in the US, file a charge under the DMCA.

Quote:
I think I'll lay off XNA, c#, managed c++ until there is clear info on this stuff.

There's plenty of "clear info" on those technologies. What are you confused about? It is certainly possible to use them to make games like the ones you've listed; just because the games you listed were not made with those technologies doesn't mean much.

Quote:
By the way I think the term cross platform shouldn't be confidently used to refer to moving from windows to xbox360

You can't just redefine terms, though, so that's not going to fly. Cross platform refers to something that can be made to work on more than one platform. Not necessarily all platforms, and not necessarily without any effort.

Quote:just out of curiousity why did choose C instead of going with C++ and taking advantage of classes

Don't work at Bungie myself but do work at another Microsoft Game Studio, and I think I can field this one... if your company has been around for 25 years, you've probably got a lot of old C code (maybe millions of lines) that you still use, and a lot of C programmers who aren't that hot at C++. So any change to C++ will be gradual and very much one step at a time.

I know of at least three companies for absolute certainty who are still using a lot of C code for exactly this reason, though in all three cases the move to C++ is well underway.

from memory, quake3 was also C (not c++)
im not to sure about doom3 though