Jump to content

Game source code in general (SC or anyone else in the know?)


Joel Schultz
 Share

Recommended Posts

Recently I downloaded the Freespace 2 source code. Why? Because I'm a geek and proud of it! Besides, I never saw a real game's source code before and was curious.

Besides discovering that there's something seriously wrong with my development environment at home (will need to reinstall, I think), I had an opportunity to gloss over the source code.

My immediate reaction: huh?

The FS2 developers used C++ (.cpp files) but this is one of the least OO C++ code samples I've seen in a while. I mean, I understand that C++ makes it easier to deal with the COM DirectX API (actually, I can't recall if the original FS2 required DX to run, and I can't find the game box at the moment). But still, I would have thought that a game with distinct objects, operations on the objects, and the need to sometimes hide various operational details (such as whether the graphics engine uses DirectX vs Glide) would lend themselves quite well to OO principles.

I'm wondering why a game developer would write their code in such manner. What would drive that decision? Style? Lack of OO experience (that somehow strikes me as unbelievable)? Perceived performance benefits?

(Perceived performance benefits I personally think is bunk -- C++ gets translated by the compiler into C-like code, and I would hope that the optimizer would do at least as well on C++ as with C -- the only thing I can think of which might induce a minor hit would be vtable function lookups, but unless that's in a highly frequented inner loop, how many CPU cycles would that cost? Am I way off base in this analysis?)

I'm curious to peruse through some of the rest of the code to see if I can dig up interesting tidbits on why it works like it does.

Link to comment
Share on other sites

Agreed. I can write (and have written) C code that looks/behaves more or less like C++ code and is "OO". However, that requires more "discipline" on the part of the programmer to follow the tenets of OO, since C won't enforce them. C++ does attempt to enforce the tenents. Not that you can't get around them quite easily if you want.

From that standpoint, IMHO I would think that OO would be easier in C++ than C -- it certainly is not impossible in C (or any other non-OO language), it just requires more discipline. Not to mention you get useful freebies like automatic destructor calls in C++. But I sure don't want this topic to turn into a debate on "can I do OO in language L" so...

If indeed the FS2 code is OO (and I admit I have not read it in sufficient detail yet to judge this -- my post was my "immediate reaction", or "first impression" and should be taken as such -- and I will also admit I am unused to recognizing OO code in unusual guises) why would one write OO code choosing C++ as the programming language and NOT harness the aspects of the language designed specifically to accommodate OO? This to me is an even more interesting question than whether or not FS2 is OO. This may be a pretty lousy question to ask as it assumes there's a "typical" programming paradigm, but is this sort of thing seen a lot?

I don't intend to quit my day-job to do games programming, for sure But...you know...sometimes you're curious about how someone else's code was put together, especially if it's kind of cool. A "Why'd they do this" sort of thing...

Link to comment
Share on other sites

I thought you started the discussion questioning the code written by the Freespace developers. Stick to that [pointless] argument if you will, since thats what I was debunking. Any programmer worth his/her salt can write C code that is as efficient as C++ OO code without ever knowing - nor understanding OO.

Link to comment
Share on other sites

I agree with your OO comments.

In the 7 years or so I've been working, I've only seen C++ used in a non-OO procedural manner once (that's probably in part due to the industry I'm in, not to mention the codebase I work with daily). So you can imagine seeing something (FS2) that looks at first glance like non-OO procedural C++ is somewhat of a novelty for me ("oooo...weird"). Hence my initial reaction, and the spark for my original post.

Maybe this weekend I'll have a more informed opinion of the OO-ness of FS2 if I get a chance to read over the code in more detail. Chief areas of curiosity: AI and network code.

If FS2 is not OO, well, then it's just weird to me (procedural C++). If it is OO, then it is really, really, really weird (why didn't they leverage the OO features of C++).

Link to comment
Share on other sites

I think while OO programming adds a lot of functionality and powerful features, it also adds a lot of overhead. Games need to be written more for speed than re-usability. A few of the game programming books I have tell you to make your variables global. That's a bad thing to do in regular C++ object-oriented programming, but when you're handling input, calculating behavior of the AI, and rendering the scene at a MINIMUM of 30 times a second, the less function calls you have to make the better.

Link to comment
Share on other sites

If I'm not wrong, I remember that C++ isn't a true OO language. You can mix OO code with procedural code without any kind of problem. But I agree with Matchoo in the point that games should be written with speed in mind, not reusability and here a more modular approach (like in C) rather than an OO approach (like in C++) could be the best solution.

I disagree with him in the point of global variables: if I'm not wrong in C++ you can define static classes where you can put those global variables.

Another different problem is what OO libraries are suitable or not for gaming. And as I remember when FS2 was shipped no Unreal Engine was available in the market for make the life easier to the game programmer.

Link to comment
Share on other sites

That's a very interesting thought. OO design principles *would* tend to encourage additional function call overhead. Following data encapsulation and hiding would tend to block direct access to data in favor of accessor methods. Use of virtual functions also incur an array lookup on the way to making the actual call.

Is the cumulative penalty really that great? Can the compilers/CPUs of today not optimize or predictively branch their way to near-ideal performance?

I can see your point about reusability, but game engines (like Unreal) are designed to be reusable by third party. OO is supposed to assist reuse, among other things. But your point about reusability possibly not being a priority is an interesting one.

(And before SC jumps on that statement reusability has NOTHING to do with OO and any good programmer can just as easily write reusable non-OO code.)

Link to comment
Share on other sites

When I say that games should be written with speed in mind I mean that the main effort of development should be focused in get the best performance with the tools and compilers available for the development team (apart of the game itself, of course ).

Writing reusable code isn't exclusive for the OO paradigm, but OO techniques emphasizes this particular more than others methodologies. If someone has programmed in C (without ++ or in another structured language such Pascal) knows that any module can be reused if is designed and written for reuse.

This could be the key point: Design.

Any design can have one or more focus: reusability, performance, usability, etc.. but is very rare an app focusing in every posible use. Most of the times, as programmers, we take decissions that affect one area for get advantages in another. I can sacrifice some performance in my apps for get a more complete class hierarchy that serves as base for a future implementation. When I make a new design one of the first questions I ask myself is: Which should be the main areas of interest? Code Reuse? Performance? Design Reuse?. After I respond that question I get a clear overview on how I should design the app.

Link to comment
Share on other sites

Amen nomad.

This is why I not like to choose any language before I get a fully and clear desgin of the work to do.

If the app, then, requires speed I can choose a mix between C and Assembler. If i need code reuse can choose a variety of OO languages, including C++, Eiffel, Java or C#. If the portability is the key can choose a C++ implementation such as GNU C++ or even Java.

But returning to the FS2 question, did you detect any pattern in the coding, Joel?.

A first task when I deal with foreign code is do a reverse engineering process with a tool such as Rational Rose. If the code is OO all classes and inheritance relations should appear after this.

Once I got all the classes I'll try to do a few class diagrams with the objective of understand the overall architecture. After this step is completed satisfactory I am in a position where I can understand the code because I can understand how is organized.

With non OO code the solution I use is different, involving code listings, function documentation and by drawing top-down diagrams.

Link to comment
Share on other sites

I haven't had a chance to look at the code again. Maybe this weekend. Of course, my main reason for looking at the code is not an OO-ness analysis...

Where I come from, code reuse and maintenance are important priorities. Speed is too, but not to the point where we want fast code at the expense of long-term maintenance. So that biases my perceptions.

Link to comment
Share on other sites

Where I work these topis are very important too. I design real time systems where speed is a crucial factor so our philosophy of design depends on the product itself. We take care about all these topics but centering more efforts of design and development in the areas in wich we think will be crucial.

Maybe the FS2 development team was thinking the same and they create the product centering in graphical speed rather than a future reuse of the code.

I've downloaded the code and perhaps this weekend take a look, and with luck, I can get a map of the entire app for further research.

If I discover something interesting for you I'll promise inform ASAP.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...