TBase_Screen
BlitzMax Forums/BlitzMax Beginners Area/TBase_Screen
| ||
| Not so much a Bmax question but OO design. I'm writing out the design for a simple game. The game has a splash screen, intro screen, title screen, options screen, high score screen, game screen etc. Noticing these are all screens I thought it best to have a TBase_Screen and extend for the different type of screen. However, as always, I have got myself in an OO stalemate. I can't think what would be attributes for TBase_Screen. Some of the screens will have background images, some will use fonts, some will use text, some will have music but there is not one thing I can think off that all will DEFINATELY have. I'm beginning to think that I should just have a TScreen even though they seem to fit the 'is-a' rule. An alternative thought it to have no attributes for TBase_Screen but extend for common functions/methods. How have other people done this and what are the common attributes for your screens? |
| ||
| there are a few things they definitely have fields: Position, Width, Height BlendMode, Color, Alpha Childs (for overlays etc to make switching, drawing and cleanup easier and better structured) If your screens have an order: nextScreen prevScreen perhaps optionScreen as it is a general thing Methods: Draw (abstract) Update (abstract) |
| ||
| Hmm.. You're probably right but Position, Width, Height, Blendmode, Color, Alpha will all be within my TSprite object. They will all probably have a TSprite though acting as a Background. Next/Prev screens are good ideas. I think it's worth doing just to extend the methods. |
| ||
| I don't do screens as objects because - as you point out - they don't really have anything in common, or they may not have anything in common. I just have a flag which tells me which screen we're on, because I'll probably need to know, some objects will behave differently on different screens. Everything else is defined by the objects we have on the screen. Whatever GUI gadgets are there have their own properties and behaviours so they can look after themselves. ( EG: The Quit button on the title screen asks you if you want to quit to windows and the Quit button in the game screen asks you if you want to return to the title screen. |
| ||
| Yep, that's what I normally do. I *might* go for the type approach and see what happens. Thanks for the responses. |
| ||
| My framework has a base screen called TScreen. It is abstract. This is useful as my TGame object has a screen handler that tracks the current screen (extended from TScreen) and calls it's logic and draw functions and it can decide when to show another one after a fade etc. It's pretty neat. |
| ||
| I've actually gone off the 'extending' route and back to the method suggested by Gab. In fact I *do* have a TScreen type but with attributes covering the screen makeup (background image, music, effects, buttons etc). Although most are different they often have all if not some of these. Extending seemed to limit what I was doing or ended up with too many permutations of sub-types. |
| ||
| fair enough. |
   |