Game; Achievements screen classes

[ArenaFlash]

So I'm making a game and I'm done designing everything on paper, about 10-12 pages filled with numbers, drawings and lists. Now to start making the classes hierarchy (mainly display ones for now), I'll type here my idea but I would appreciate the feedback of people used to OOP to voice what they think.

Here are the main display screens: MainScreen, AchievementScreen, CharacterScreen, BattleScreen. There is also 2 small display screens for when an achievement is received and for the reward after a battle. Later on a shop screen, crafting screen etc...

I'll use the AchievementScreen for the example of the way I think will work.

So this screen will display 10 sets of 5 medals, 2-3 display squares at the bottom for information on objective/current/bonus (when the player mouse over a medal) and 1 line which will show the type of achievement when the player mouse over the medal also.

Classes: (higher number means it is nested into the lower number)

(1) AchievementScreen
----------The whole display of that screen, contains everything in it
(2) ObjectiveDisplayBox
----------When the player mouse over the medal, information on how to get the said medal is displayed. ex: "Kill 100 monsters"
(2) BonusDisplayBox
----------Again, on mouse over the medal, this one shows what you get as power from obtaining the medal
(2) InfoLine
----------This will display the type of achievement. ex: "Killing Achievement"
(2) MedalSetContainer
----------The rectangle containing the 10sets x 5medals
(3) MedalSet
----------A rectangle containing the 5 medal containers of that set
(4) MedalContainer
----------A square that will only contain the medal... let me explain... I was thinking it would be a good idea to let some space between medals but, also have the mouseover event working even when a bit out of the medal lines so the player can compare 2 medals easily (with the display boxes) without the say 5-6 pixels (between 2 medals) empty of mouseover event listener
(5) Medal
----------So yea the medal
(6) Ribbon
----------Shape for the upper part
(6) Badge
----------Bottom part of the medal, shape as well

There is actually a bit more than this, but my goal here is to make sure I can start building without, later on, realizing this won't do and have to restart the class structural hierarchy.

So is this structure something that is likely to go wrong, give problems etc... or is it what you, someone used to good OO programming would consider likely to be reusable and work well? Looking for as much constructive opinions as possible

[ArenaFlash]

I'll bump this once before I go sleep in the hope of replies, I'll just let it die then.

[gamingPC]

I dont think you"ll have problems, but I think you've gone too far.
Unless your supposed to have 99999 different looking badges.

[moagrius]

from what little info there is, it should be fine. i disagree with the above poster when he suggests you've gone to far. i make a class for every "concept" in an operation. i use floating windows a lot, emulating a typical OS window - which seems pretty straightforward, but there are a ton of classes involved. even just the scrolling mechanism has its own package with several classes - a base class for the up and down arrows, then subclasses for up and down, respectively - a class for the bar itself, a class that handles the motion and relationship between content and bar, class that extends another that just sticks that scroller where it normally appears (vertical right or horizontal bottom), etc. i didn't use to micro-manage everything so much, but when running into a situation where i wanted to put the scroller on the left, for example, i would have had to rewrite the whole thing, instead of just making a new small extension. same thing when i want the "skin" to change - instead of rewriting every little tweak and dimensional computation, i leave all that open. e.g., when dragging the scrollbar itself, it's position needs to know where and how large the up/down buttons are - if one version has 13x14 pixel buttons, and a new look has 15x15, you'd have to rewrite. also, this made configuring the scrolling for horizontal versus vertical take about 5 minutes to implement.

anyways, probably rambling here, but yeah - i'd suggest using a class for any "thing" - visual or not - that appears in your application.

[ArenaFlash]

Thanks moagrius, that's exactly the kind of answer I was looking for, and I appreciate the examples, helps me a lot.

I feel much more confident going ahead and creating the classes without fear of having to rebuild everything from scratch because of lack of re-usability and the such.

[moagrius]

[v5000]

"No battle plan survives first contact with the enemy." - Helmuth von Moltke the Elder

But that doesn't mean you shouldn't try, got to start somewhere. For complex projects UML diagrams, CRC cards or whatever method you use to antipate the structure of an application are vital in getting the basic responsibilities, relationships and naming conventions solidified before you start coding, but they might get tossed pretty quickly once things get bloody.