confused about display list and organising my classes

[nicolanicola]

I'm making the game Breakout as an AS3 application using OOP. I am getting very confused though. I know that objects should be only responsible for themselves. But this is where I get stuck, they need to communicate as some level to add and remove screens, and I am getting majorly confused as to what is going too far, when it could maybe achieved in a simpler more OOP way.


I've worked out the hierarchy of my classes, in terms of where they are being added (I think). I've attached it as a screenshot.



Have I got the order right based on OOP principles? Like, Introscreen will listen for play being pressed then call a method of the document class that will remove introscreen and then attach gamescreen. Is that right?


Another thing that puzzples me. It seems to me if I made a level and put the paddle and the ball in that, then arranged all the bricks in that level, that I'd be duplicating work (based on the fact I need paddle and ball for level 2 also). So it would be best if I could have gamescreen with paddle and the ball and then add level1/2/3 to display list which would therefore set up the appropriate brick placement. But then, wouldn't that mean that I couldn't do hittests because my level 1/2 or 3 wouldn't be a sibling to the bat and the ball, them residing as a sibling in the level's parent class?


Please help if you can. I'm extremely puzzled and can't stop frowing.

[BoppreH]

What I'm going to say is by no means the truly correct answer or only option. But here's what I think:

Introscreen should interact with the DocumentClass the same it interacts with it's button: events. Listen for the button click event, dispatch a "Introscreen.PLAY" event and make the DocumentClass listen for it so it can advance the game. This works well with AS3's event-based concepts and keeps the interactions to a top-down approach.

Now, the levels. Choosing between including the paddle and ball inside the level instance is more of a design concept. Do you want your game to flow through levels, keeping a sense of continuity (paddle and ball maintain position when level is advanced, for example), or do you want to separate the levels, resetting the components at every level change or placing a end-level screen?

Regardless of your choice, you have to fight that redundancy feeling ("I'd be duplicating work") with inheritance. Make a Level class that all levels will extend and put all code that is shared between the levels in there.

And there should be no problem with hittest regardless of display hierarchy.