I''m currently learning C++ and OOP and I was wondering, is it worth using objects in games? Why is it better than procedural programming? I''ve heard that they''re slow... /. Muzzafarath

See: http://www.geocities.com/SiliconValley/Grid/2832/oogame.html
for why you would use objects in games.
See
http://www-cs-students.stanford.edu/~amitp/Articles/EfficientObjects.html
for a bit more on the efficiency of c++ over c.

Mike

I prefer OOP, IMHO it's more natural to think in objects.
Polymorphism is great for games, you can re-use objects you made in others projects, saving time.

I don't think that OOP is THAT slow , bad algorithms can do more damage in the speed .

I may be wrong, but I think the benefits you gain using an OOP aproach is worth. ( I really like OOP )

Just my 0.02$



Edited by - Strauss on 2/27/00 12:46:02 PM

Don''t believe the performance and memory hog rumor mill, those are just people who are afraid of change. There is a great Q&A with Bjarne Stroustrip at slashdot that I recommend everyone read.

http://slashdot.org/article.pl?sid=00/02/25/1034222&mode=thread

We''ve been using C++ to develop game engines at Dynamix now for 5 years. Those engines are in dozens of commercial games, Silent Thunder, Red Baron II, Aces of the Deep, Pinball, Bass Fishing, Kings Quest: Mask of Eternity, Starsiege, Tribes, etc...

--Rick

I really like Tribes Spent many moons playing that game when it first was released here in Sweden.

/. Muzzafarath

With procedural programming you must re-invent the wheel so to speak, meaning that to do the same type of procedures in a linear sequence you will always have to declare various functions and variables. With OOP, you can include a "black box" with a header file like #gamemap.h, which handles events and data for you. OOP will allow your programming to be more abstract and more easily mirror real world problems.
I suggest digging into some object tutorials

As long as you don''t use OOP badly, you don''t lose any (or much) performance over procedural. Here are some guidelines I try to stick to:

1) Use public member variables of a class as much as possible. This kills the data hiding factors of OOP, but if you are going to create a function that says "SetX(int px){x=px}" and one that says "GetX(){return x}" without any sort of scope checking, etc, then don''t bother with the overhead for calling the function. Just make the variable public.

I only use private variables when I need to do some strict bounds checking or need to determine which variable to use (ie, in my current game, if I set an integer variable in a certain class, a pointer variable was set to NULL. If I set the pointer variable, the integer was set to zero. I needed to have a function for this so that I didn''t need to remember it when implementing). As long as the variables have meaningful names, setting Bob.HitPoints is as easy (and faster) than calling Bob.SetHitPoints().

2) Use inheritance, but use it wisely. If you have classes that are nested 5 deep in your high-performance classes (graphics classes, per-turn AI classes), you''re going to have one helluva performance hit. Try inheritance only when truly needed. (In my game, my PC and NPCs have basically the same structure -- with the only exception being that the NPCs have AI information in the class. Since I have only 1 PC, and plan to have about a 1000 NPCs (using staggered AI updates for the NPCs based on their proximity to the PC), I decided to use the same exact class for all of them -- having a little extra data for the PC was worth not having to check the inheritance of every single NPC in the game)

3) Pointers are your friends. Only put the data in one location -- having to sync data in 5 different classes because of the use of copy over pointers is painful, and can lead to a LOT of problems. Pointers may be more difficult to understand, but ultimately making your program work much better.

4) Overloaded functions are a necessary evil, but don''t overload everything. Doing this requires run-time determination on the part of the system as to which function to use (cycles which could be more useful in your game). Absolutely DON''T use it on time-critical functions (ie, pixel-plotting functions). If you have two functions, one of which says "Plot(int x, int y, BYTE c)" for 8-bit pixel plotting and one that says "Plot(int c, int y, SHORT c)" for 16-bit color pixels, the time spent by the program determining which function to run is probably about the same (if not more) as plotting the pixel to begin with. Use a function-pointer in times like these, and make that determination only once (before pixel-plotting even begins)

That''s all of my advice for classes (for now, until I think of more). My overall best advice is to build your game to work on a lower-end box. If it works smoothly there, it will work smoothly anywhere. My time programming games on my piece-of-crap Tandy-1000 was probably the best thing that could have happened to me. I still had it when the Pentium first came out. I saw all of the great games for the newer systems, and did my best to make that piece of crap scream (which I actually did, to an extent, with a LOT of assembly-language mixed in with my C -- I never quite made Quake, but I did manage to get a pretty good copy of PacMan and MineSweeper out of it)

-Chris

---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com