Jump to content
  • Advertisement
Sign in to follow this  
onfu

How much OOP is too much OOP?

This topic is 4170 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

I'm building an RPG in Flash, so I don't know how well you guys will be able to give an exact idea of what I'm asking, but that's ok. I'm currently putting together the character/creature construct (basically the same). I want to have about 20 or 30 core skills (covering everything from aspects of combat to different magic skills, etc), all of which are derived from and modified by a combination of character attributes, current circumstance, and equipped items. So the way I was thinking about setting it up, would be to have attribute class/object, an item class/object, and a skill class/object (I'm just talking about these three classes for this question). The character class creates a set of attribute objects, and then a set of skill objects. Each skill object is assigned a parent attribute, and also when an item is equipped during gameplay, the character class assigns relevant attribute and skill objects a pointer to that item. This way whenever a skill check is needed, it begins with its base number, but then looks at the governing attribute (which might be damaged/enhanced) for a modifier, and then looks up items that are assigned to it, which may or may not be full strength at the time (etc), and thus arrive at a final modified number. My questions is though: Since I want to use the same construct for all creatures, NPCs and whatnot, is that going to be overboard on the instantiated objects? Say 10 creatures with active behavior - 10 x 30 skill objects, 10 x 10 attribute objects, etc... Is it better in this case to simplify? does it matter? Just looking for very general advice here. My OOP ventures have thus far been quite small-scale. Cheers, p

Share this post


Link to post
Share on other sites
Advertisement
Depends.

Flash isn't known for efficiency, but I don't have enough experience to know where it matters.

In C++, especially in combination with boost, templated classes are instantiated by possibly thousands, even tens of thousands - but the compiler is smart to reduce them to bare minimum.

Java has no problems, tens of thousands of classes don't matter. Instantiating tens of thousands of objects per second doesn't matter either (ok, there's better ways to solve such cases, but not necessary)

OO is about making your intentions clear. Design is what's important. If you feel you have too many different classes, rething your design - are all really necessary? Are some merely duplicating others? Do they represent distinct quantities?

There is no "too much" or "too little". Find class relations that describe your object model.

Also, make sure you understand the difference between a class and an instance. Class is definition. Instance is each copy of class that is created. Classes are unique - a Point class is only one. But you will instantiate hundreds, or thousands of classes.

If you only make 1 class for 1 instance, then that's redundant. Having one single class for entire application, that's not enough.

Share this post


Link to post
Share on other sites
It's not that I think I have too many classes, but rather that I don't want to hurt performance by having too many instantiations of those classes.

I could keep the attributes of a create in the creature class as variables, but that's not how I want to organize and work with the data. I would like to isntead organize it as I described above, but not at a severe cost to performance comparatively. As you said - Flash is not efficient, so it counts.

I appreciate your introductory OOP advice, but I am pretty comfortable with object oriented design and am not new to OOP. It's just the OOP I've done has usually been fairly small scale - for example a game where there might be 10 creatures, or 20 alien spaceships, but they have only a few properties each and a very rudimentary A.I.

Cheers,
p

Share this post


Link to post
Share on other sites
This is too much OOP:


// C++ STL
std::transform(myString.begin(), myString.end(), myString.begin(), std::tolower);


It's not so much a problem of object orienting your game as going completely overboard and overdesigning.

Design what you need, not what you think might be cool in 0.00001% of the usage cases.

Note: I'm not particularly responding to your post, I'm ranting on stupid STL design. Your design is more of the high-level idea than actual implementation, so I can't really comment.

Share this post


Link to post
Share on other sites
Quote:
I appreciate your introductory OOP advice, but I am pretty comfortable with object oriented design and am not new to OOP. It's just the OOP I've done has usually been fairly small scale - for example a game where there might be 10 creatures, or 20 alien spaceships, but they have only a few properties each and a very rudimentary A.I.


10,000 isn't too many.

With flash you need to be more careful about invocations, allocations and such. But the total number of objects only impacts memory use. Other performance factor, as always, is the cost of allocation and de-allocation.

So more importantly than how many you have (only limited by memory) is how long it takes to construct them.

The rest doesn't have an impact.

Share this post


Link to post
Share on other sites
Well what I'm doing right now is focusing 100% on design, to create the best workflow for a complicated combat and gameplay engine down the line.

I was just concerned that say 10 or 20 creatures with 10 attributes, 30 skills, 5 equipped items, etc...might end up being too many instances.

But if C++ can do tens of thousands, I'll trust Flash to handle a few hundred without skipping a beat.

It just has notoriously bad runtime performance.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nypyren
This is too much OOP:


// C++ STL
std::transform(myString.begin(), myString.end(), myString.begin(), std::tolower);
Yeah, see, the problem with that is that line is typical of functional programming in C++ rather than object oriented. It's pretty much a map operation that writes back into the original storage.
Quote:

But if C++ can do tens of thousands, I'll trust Flash to handle a few hundred without skipping a beat.

It just has notoriously bad runtime performance.
I believe the new Flash/AS 9 use a JIT engine for their runtime now, so performance might be a lot better now than it used to be.

Share this post


Link to post
Share on other sites
Not to mention that the "annoyances" with that std::transformline are mostly an unfortunate side-effect of the verbosity imposed upon you by C++ itself, and have little to do with the underlying concept, which is quite elegant and sound.

In any case a more illustrative example might have involved iostream_iterators, bind1st, mem_fn, or all of the above...

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by Nypyren
This is too much OOP:


// C++ STL
std::transform(myString.begin(), myString.end(), myString.begin(), std::tolower);
Yeah, see, the problem with that is that line is typical of functional programming in C++ rather than object oriented. It's pretty much a map operation that writes back into the original storage.


Notice that there is no std::string::to_lower method to compete with the std::transform way of doing it. That's what I meant by bad OOP design. You have a very common operation and force the programmer to jump through bizarre hoops just to do something simple.

As far as the functional aspect goes, this pattern is sweet. I can replace std::tolower with anything that operates on the elements of the string (I could encrypt a container using the 5-argument version of std::transform and pass in two separate iterator pairs and an encryption functor). But as far as the lack of a well developed string class goes it is an unacceptable alternative.

A better alternative in the functional style would have been to define a container interface (ala .Net), and a function signature like "std::transform(container, functor);"

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!