• Announcements

Archived

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

Over the top OO?

Recommended Posts

So, I''m making this crappy little platformer and I am trying to make everything nice and object oriented. However I think I may have either gone over the top or even strayed entirely from having an OO design. I have placed EVERYTHING in classes. I have put the basic drawing functions into a CGraphics class, all Input is in a CInput class and the CGameEngine class contains the two previous classes. I was then going to make a GameObject class a derive all of my little guys and crap like that from it. But am I actually gaining anything by doing this or am I just making my program a hell of a lot more complex? -Donuts

Share on other sites
Actually I think it''s a good idea to do it like you did it...

the good think about a design like that is that if you ever want to use another API for the graphics you just have to replace the CGraphics class...

if you''re going to support other input devices just replace CInput... (ok in that case replacing is not a good idea... a polymorph class would be a better idea and you just derive new classes from it).

so you can have a lot of advantages making a string OO approach. But the question is if it makes sense for what you''re doing now. If you''re doing a PacMan clone I wouldn''t suggest using such a complex design, but for more complex games it can be really helpful to have a nice OO design.

I hope this helps a bit... ;-)

--
Programmer of Star Torn

--

There are only 10 types of people in the world:
Those who understand binary, and those who don''t.

Share on other sites
The first time you realize that you have gained something will be when you have your GameObject and those who are derived from it. GO_Player, GO_Box, GO_Ballon, GO_BouncyBall all have a Update method which they implement diffently (the Player checks for input, the box just sits there, the ballon goes up until he hits the ceiling and the BouncyBall ... bounces) and which was still pure (or default implemented) in the GameObject.

Once you have an array of GO_ objects all stored in a GameObject** vector you can walk the length of the vector, updating each entry. And each one will react as befits a Object of its type. No bouncing boxes or players that float to the ceiling.

Sure OO seems like huge overhead but once the code of your app grows beyond two screens you''ll be happy for maintainabilty

---------------------------
I may be getting older, but I refuse to grow up

Share on other sites
I don''t see how this is wrong, its organized isn''t it?

Only thing wrong is sticking C on your classes.

Share on other sites
quote:
Original post by Donuts
But am I actually gaining anything by doing this or am I just making my program a hell of a lot more complex?

You''re not giving enough details for anyone to give a proper answer to that question.

"Putting everything in classes" doesn''t in itself make your game OO.

AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.

Share on other sites
oh, this is something that makes me crazy, too. i realised that i spend most of my time scribbling engine-desings and walking up and down all the night, thinking about what would be the best structure for everything. "do i need an extra "Room"-class? or should i implement the funtionality in the "core"-class? where belong the NPCs to?" etc.
often im ending up rewriting parts of my code, because what looked good yesterday just looks crap today. and maybe good again tomorrow. i just can''t find a nice, clean implementation...
and theres also very few material about general engine-design available...

Share on other sites
quote:
Original post by Donuts
I have placed EVERYTHING in classes.

I have put the basic drawing functions into a CGraphics class, all Input is in a CInput class and the CGameEngine class contains the two previous classes. I was then going to make a GameObject class a derive all of my little guys and crap like that from it. But am I actually gaining anything by doing this or am I just making my program a hell of a lot more complex?

GOOD! I LOVE YOU! When you finally complete all your classes, you''ll find that it will make more sense. Even though creating it will sometimes get confusing, the end product will be idiot-proof.

Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore

"Do or do not. There is no try."
- Yoda

Share on other sites
quote:
Original post by maximAL
often im ending up rewriting parts of my code, because what looked good yesterday just looks crap today. and maybe good again tomorrow. i just can''t find a nice, clean implementation...
and theres also very few material about general engine-design available...

That was me a couple of months ago. I have 8-10 older versions of my project.

I just strive to be as minimal as possible in the engine itself; in my current version the components do not even know of the engine. Obviously this isn''t always possible.

Share on other sites
Refactoring is a way of changing the structure of your code without changing what it does. Sounds like a waste of time?

Read this: What is Refactoring?, and the following pages. The example chapter starts here

[edited by - petewood on May 27, 2003 5:41:45 AM]

Share on other sites
IMHO, probably the most important thing in OO is to ask right questions. Something I have trouble with.

Share on other sites
The most important things that you should think about in OO designs are data encapsulation and polymorphism. Classes are the tool you use to achieve these OO goals. If your classes are not doing these things, then you don't necessarily need them to create a good OO design. If something is better located in a regular old function, then so be it. Put it there. If, however, you need to expose interfaces to data manipulation, then classes are your best choice.

Look at each of the sections of your code and decide what you're really trying to do there and choose the best tool to get the job done. If everything requires encapsulation, then everything should be in classes.

Also be aware of the *relationships* between your data when creating your OO structure. There are many programmers who put every little piece of data in its own class when in reality a lot of that data is related to other pieces of data and should be grouped accordingly.

Again, the most important thing about OO design is to encapsulate your data in a logical manner and provide interfaces that work on that data, using polymorphism to generalize.

[edited by - fizban75 on May 27, 2003 9:07:51 AM]

Share on other sites
quote:
Original post by Rob Loach
GOOD! I LOVE YOU! When you finally complete all your classes, you''ll find that it will make more sense. Even though creating it will sometimes get confusing, the end product will be idiot-proof.

Nonsense. OO does not automatically make something make more sense'' or more idiot proof''. It might even make less sense'' if the problems being modelled do not fit well into OO, particularly in a broken implementation of OO such as that of C++. There''s more to OO than single-dynamic despatch, static typing and classes as implicit namespaces. When the OO constructs provided do not hang well, it makes perfect sense to look for solutions from the non-OO'' constructs on offer.

Share on other sites
I agree. There are some things that may work better in OO and some things that are done in good ''ole C style. Heck, I use classes frequently, but I still use structs all the time too.

I don''t see the advantage in writting a class for something you will only instantiate one of. Like a level loader/renderer. You will *not* have more that one level at a time. Writting a class for it will only slow things down (due to the extra pointer reference used int function calls, especially with recursive functions found in many partitioning schemes).

I made the same mistake of doing this a long time ago. I figured if OOP was the future of code design I had better go nuts with it. Needless to say it was a bad venture. Then of course they released pure OO languages which border the edge of redundancy.

• Partner Spotlight

• Forum Statistics

• Total Topics
627676
• Total Posts
2978582

• 11
• 12
• 10
• 12
• 22