Archived

This topic is now archived and is closed to further replies.

OOP Game Coding

This topic is 5749 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello out there. I''ve been conding on my OOP Game for a couple of weeks now, but now, I''ve found out that my "engine" is to "big". I''ve got one class for Input, one class for Video and one class for Audio. As i told you I find that pretty messy. How do you guys write your engines? one class for the entire engine or splitted lik I am?

Share this post


Link to post
Share on other sites
have a class for everything, thats what oop is...

your "engine" class should be split up into, for example, a texture class, a mesh class, a terrain class, a camera class, a file io class, a maths class, and a physics class.

Share this post


Link to post
Share on other sites
That''s precisely how me and my coding group organized our game. Every instance of the game had an Audio Engine class initialized, for example.

Share this post


Link to post
Share on other sites
quote:
Original post by Smurfwow
have a class for everything, thats what oop is...

Not. Have a class for every logically distinct object that can be operated upon or told to operate on itself. Don''t have a class for the sake of having a class, or have classes that consist of nothing but static methods (ie, use classes as means of "organizing" code). That''s what namespaces are for.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! | Asking Smart Questions | Internet Acronyms ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
Ok, so since each part of the engines (Input, Video, Audio) often needs access to same things it SHOULD be ok to consider the while engine as ONE class instead of THREE?

Share this post


Link to post
Share on other sites
No.

Better add another class containing the game data.

So you would have
Audio
Graphic
I/O
WorldRepresentation

The last contains all game relevant data and has access functions to manipulate and read the data.

Share this post


Link to post
Share on other sites
Using OOP in a game system can be somewhat difficult at times. I know I reworked my first OO engine multiple times to allow for minium globals and loosely coupled behaviour.

Right now I have:
XGameObj
XBitmap
XTileSet
XInput
and a DirectX wrapper.

I might even get less complicated soon.

Share this post


Link to post
Share on other sites
quote:
Original post by Nali
how does namespaces work ?

Namespaces prevent identifier collisions (like when you and I both write a function named Find with the same number and type of parameters, or when we both have a class name Graphics). They also promote "localization", for lack of a better word.

Search the web for more info.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! | Asking Smart Questions | Internet Acronyms ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
Bets way to program is no classes and write everything in the WinMain function, all in one source file. If your game uses other functions and classes, then it''s not a cool game

Share this post


Link to post
Share on other sites
Things certainly aren't helped by school—I assume that most who have such nonsense notions of object orientation (such as the original poster) are usually students. I've found that teachers brainwash you into making classes simply because "that's what you're supposed to do." And they spoon-feed you such rubbish because they don't know any better.

[edited by - merlin9x9 on April 18, 2002 1:22:31 PM]

Share this post


Link to post
Share on other sites
mabye i should have elaborated on what i ment by "everything".

my point was that you could effectivly use a lot more classes for a 3d engine.

Share this post


Link to post
Share on other sites
quote:
Original post by merlin9x9
Things certainly aren''t helped by school—I assume that most who have such nonsense notions of object orientation (such as the original poster) are usually students. I''ve found that teachers brainwash you into making classes simply because "that''s what you''re supposed to do." And they spoon-feed you such rubbish because they don''t know any better.

[edited by - merlin9x9 on April 18, 2002 1:22:31 PM]


I''m not a student at all, I''ve learned this all by my self and hasn''t taken any course at all! Do you recommend to not have any OOP at all? That doesn''t make any sense TO ME that is. I just want to have a simple OOP like:
1 Class for Engine (Audio, Video, Input)
1 Class for Data (Load Textures, Models, Worlds
1 Class for the actual Game...

But before i Dig any deeper in this matter, I''d like some more opinions on OOP in games

Share this post


Link to post
Share on other sites
quote:
Original post by Metus
I''m not a student at all, I''ve learned this all by my self and hasn''t taken any course at all!


Good show!
quote:

Do you recommend to not have any OOP at all? That doesn''t make any sense TO ME that is.

Hmmm... that depends on what you think OOP really means, as it means different things to different people. I recommend that you check out this article: OO(A, D, P(C++)) to give you a push in the right direction.


[C++ FAQ Lite | ACCU | Boost | Stroustrup on Learning C++]

Share this post


Link to post
Share on other sites
OOP for games rocks It makes things alot more logically organised and bug free. My current game has 16 classes and thats without all the game objects and ignoring standard classes like HashMap etc.

If you''re gonna do OOP, do it right. And don''t skimp on classes. I''d recommend splitting your Data class into several others: wrap your models and textures up in a game object class that holds its own appearance (with possibly a class to load and hand out models etc. for better sharing).

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
Good show!



Well, Thank you, Im doing my best, but that''s hard with no high-school-or-whatever knowledge in Math or Physics

Share this post


Link to post
Share on other sites
yeah,

OOP v. not-OOP is one of those theological debates. it''s possible to write tight code using either.

what i like about OOP game design is that if i want to update an AI or the way a particular feature of my game works, i can just rewrite one class. As long as that classes method names are the same and provide the same function i don''t have to change anything else anywhere else in my game. that is, in a nutshell, what OOP is designed for: modularity of design.

the big drawback with OOP is that you end up with a bazillion .cpp and .h files and it''s easy to loose track of the organizational hierarcy of your game. it helps me, anyway, to keep a hand-drawn (or Visio drawn) chart of which objects do what.

definitely the trick to OOP, as Oluesyi points out is to become good at recognizing what are the functional and distinct components of your game.

you''re going to have a ton of files and more lines of code of you use OOP. it''s the trade off you make for modularity and making your life easier when you realize that you screwed the pooch on your AI implementation.

-me

Share this post


Link to post
Share on other sites
quote:
Original post by Palidine
what i like about OOP game design is that if i want to update an AI or the way a particular feature of my game works, i can just rewrite one class. As long as that classes method names are the same and provide the same function i don''t have to change anything else anywhere else in my game. that is, in a nutshell, what OOP is designed for: modularity of design.

No. That is the concept of seperating interface from implementation, and is very possible with procedural code. OOP is designed for modularity, but what you just described isn''t modularity.

quote:

the big drawback with OOP is that you end up with a bazillion .cpp and .h files and it''s easy to loose track of the organizational hierarcy of your game.

People go crazy with source files as well. You can have a number of logically tightly-coupled classes in the same header and source files. The only time you are virtually guaranteed to have an excess of source files is when you emulate OO-enhancing features in C++ using a procedural language like C (emulating static class members, for example).

As for organizational hierarchy, any significantly non-trivial application will display hierarchical complexity. OO actually alleviates that particular problem somewhat.

quote:

definitely the trick to OOP, as Oluesyi points out is to become good at recognizing what are the functional and distinct components of your game.

Precisely!

quote:

you''re going to have a ton of files and more lines of code of you use OOP. it''s the trade off you make for modularity and making your life easier when you realize that you screwed the pooch on your AI implementation.

Again, I''ll have to disagree. OO does not necessarily result in more lines of code; the reverse is actually often the case for a well-designed system. Consider a case where a process is performed for several different data types. In a non-OO project, this would be implemented as several methods that perform the same operations on different data types (remember overloading by data type?) In OO you can design an object hierarchy and abstract the functionality into the base class, then receive a pointer to the base class type. Fewer lines of code, but only marginally so.

Then came generic programming, which allowed you to be type agnostic and alleviated the misuse of inheritance and polymorphism for solving problems like this. Trivia: the strongest advocate of templates and generic programming in C++ and the STL doesn''t like object-oriented programming! Go figure...

OO is not a panacea. It''s a tool that must be used wisely by the craftsman, much like a chisel or a spanner.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
quote:

Do you recommend to not have any OOP at all?



Of course not. But I certainly don't advocate using it all the time. Use it when your app would benefit from it, otherwise use some other paradigm.

And I didn't say that you were a student or product of the system, but just that most who ask questions like you are.

By the way, for one last bit of pedanticism, it's "not to have" instead of "to not have." "To have" is the infinitive form of the verb, so both parts are actually a unit. Therefore, it's illegal English syntax to put anything in between. Such an error is called a "split infinitive."

[edited by - merlin9x9 on April 18, 2002 3:19:30 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by merlin9x9
By the way, for one last bit of pedanticism, it''s "not to have" instead of "to not have." "To have" is the infinitive form of the verb, so both parts are actually a unit. Therefore, it''s illegal English syntax to put anything in between. Such an error is called a "split infinitive."

English class-level utter bollocks. Like how they tell you not to start sentences with conjunctions.

"Is it possible for you to not do that?"
"Is it possible for you not to do that?"

Both valid. Different meanings and emphases.

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
Oluseyi, how did you get to be so wise? Is it that you eat your Wheaties every day?

Share this post


Link to post
Share on other sites
Nice thread (sarcasm) but it is a good question.

This is the framework I use for all my game oriented programs:

I created objects to handle each DirectX interface (DirectGraphics, DirectSound, DirectInput, etc.) This would be easy if Microsoft made an Object-Oriented DirectX API. You''d only have to have your objects inherit the interface and viola! BUT, this isn''t the case, so suffer =b Once you get it working, it will be worth it. =)

Next, I created a system object. This object is responsible for passing error messages for clean error handling and also contains pointers to all system objects (DirectX, Real-time, etc.). The system object is initialized with references to the DirectX objects that are defined in the main function of the program. You now have an object that either handles or points to all your system and I/O objects.

Next, I created a simple class called CObject. CObject contains a static pointer to the system object (meaning all instances of CObject share the same pointer rather than having a seperate pointer for each instance). This object also handles other operations needed by all objects in my program. This could include unique object ID''s and displaying error information.

Now, all your objects that you create from here on are children of CObject and therefore have access to all of your I/O, realtime and errorhandling functionality.

Hope this helps,
Jay

Share this post


Link to post
Share on other sites