Jump to content
  • Advertisement
Sign in to follow this  
ChocoArcher

Object oriented design question

This topic is 4866 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 have a class called Battle. It's meant to be a top-level class that contains other classes (such as BattleVisual, BattleStorage, BattleActions, etc). I have two questions: 1) How would you recomend lateral movement (i.e. BattleActions wants to call functions of BattleVisual) 2) How could I make the public functions of the other classes (i.e. not Battle) available only to any Battle classes that may need them and not to the rest of my game? Thanks! :)

Share this post


Link to post
Share on other sites
Advertisement
Quote:
1) How would you recomend lateral movement (i.e. BattleActions wants to call functions of BattleVisual)

First up, I'll assume that BattleVisual handles displaying a battle, BattleStorage stores some sort statistical data of the battle, and BattleAction handles the actual logic of each action that can take place in the battle.

Now, ideally, if you find yourself in a situation where you want 'lateral movement' between the classes, you should probably be taking a closer at your design. Taking your example, why would something that renders a battle (BattleVisual) care how decisions (BattleAction) are made in the battle? Whatever happens happens, just so long as it gets shown. BattleStorage stands out a bit though, it could make sense for both BattleVisual and BattleAction to access it, so you would keep a reference (or pointer, or smart-pointer) to the appropriate BattleStorage instance.

However, another possibility is that your top-level class, Battle, could act as the coordinator between the three classes. Your Battle class may pass any necessary information from the BattleStorage instance through to your BattleVisual and BattleAction classes as required, without the 3 classes knowing about the others. This keeps down dependencies between classes which is good for class, but perhaps more importantly for you it can aid in debugging. If the classes don't know about each other, there can't be any odd bugs appearing in one class that are actually caused by a different class.

Quote:
2) How could I make the public functions of the other classes (i.e. not Battle) available only to any Battle classes that may need them and not to the rest of my game?


Assuming your design does actually require this, it depends on what language your using. In C++ check out the friend keyword. Some languages may not allow this (it is generally considered bad design), for example C# doesn't.

Share this post


Link to post
Share on other sites
Thanks. I realize what I'm doing is not the best design, maybe I need to rethink it a lot more.

I'm using C++. I will have to look in the friend keyword. I don't want to do anything to crazy, it's just that I really see the entire battle as one separate component, and the main reason why I'm breaking it up into other classes is for my own ability to handle it (I'd rather have four or five classes of 1000 lines than one huge class), as far as I'm concerned though the battle itself is one class that just happens to be separated in smaller classes. I worked once in COM and I love the idea of making the battle into a component with a few public interfaces, but unfortunately COM was horribly presented to me (three month stage where we were told to use the books and try out best to develop in it but nobody had the time to show us the basics properly) and I don't want to touch it again!

Right now I see myself using a design with five classes:

Battle Visual (handles the display of the battle)
Battle Player (contains the array of objects of players, and any functions needed invovling the players)
Battle Monster (same as Battle Player but for Monsters)
Battle Actions (stores the functions that determine how a player can attack a monster, casting spells, using items, etc)
Battle (stores the other four classes, will probably handle keyboard input and the order of events in the battle unless I add them into a sixth class).

This seems to be good for now. You're right, the more I think about it the more I realize that as long as the top level class includes the keyboard input and order of events, then it has complete control over what messages to send (i.e. when the user presses enter, it can check the menu position and send the appropriate information to Battle Player, then when a player needs to act, the main class can check with Battle Action to see how to do the action and send a message to Battle Player to choose another action). You're right, and I'm going to try working on a design that won't have a string of lateral calls.. that feels almost a bit like a goto -_-


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!