So I have a generic "game" system. The base "game" is abstract, and there's 
a bunch of "screen" classes you can stack up (like "main menu" is under 
"start menu" is under "select players popup" and etc.)

Now, a bunch of the abstract screens (like "pause menu" and "join network 
game menu") are all supposed to have the same "background" behind them. The 
framework I'm looking at has all the classes that are that sort of menu 
(i.e., that want to show a generic background (like a scrolling starfield, 
or some scene from the game, or etc)) inherit from "backgroundscreen", which 
you copy and replace for yourself. I.e., all these are cut-and-paste 
programming.

I'd prefer to have a "please log in" screen that's going to be the same menu 
and behavior but different background all be concrete, inheriting from an 
abstract class you replace for each game.

So, basically, I want a bunch of concrete library classes (A), all 
inheriting from the same game-specific class (B), which in turn inherits 
from an abstract library class (C).

I'm pretty sure even multiple inheritance would be unhappy with that.

Something like Python or Ruby could monkey-patch the inheritance tree at 
run-time, but that's awful.

Right now, I have three solutions. Each (A) class inherits from a concrete 
version of (C), which calls a game-specific factory-like method with the 
type of (A) as a parameter to draw the background.

Alternately, each (A) actually stacks a (B) underneath in the screen stack, 
and I fix the manager of the screen stack to draw the screens underneath 
first, and then make sure the (A) classes don't clobber the background 
already drawn.

Alternatively, I make the "draw a background" a completely separate 
component that gets turned on or off depending on whether the code wants the 
background, or depending on the top-most screen of the screen stack. This is 
kind of what I'm leaning towards.

But I thought it was an interesting question in OO Design.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

> Alternatively, I make the "draw a background" a completely separate 
> component that gets turned on or off depending on whether the code wants 
> the background, or depending on the top-most screen of the screen stack. 
> This is kind of what I'm leaning towards.

Yeh I played about a bit with variations on this idea.

Currently I'm using a "BlockDrawing" and an "AlwaysDraw" property of each 
screen.  If BlockDrawing is set to true, then all screens lower in the stack 
will not have their draw methods called, *unless* they have AlwaysDraw set 
to true.  In this way I make a background image (could be animation in 
future) with BlockDrawing and AlwaysDraw set to true, then build up my menu 
screens above that with BlockDrawing true (so the main menu doesn't get 
drawn when a sub menu is visible) and AlwaysDraw false.

The problem here is that even when the real game starts, the menu background 
is drawn, wasting time.

I thought another method could be to arrange screens into "groups" of some 
sort (maybe even each "screen" could actually contain a list of screens), 
then you could put all the menu screens (including the background screen) 
into a group/screen, and once the main game screen has faded in, the 
BlockDraw property of main game screen group prevents the menu screen group 
from being drawn.

I'm still working on it :-)

Post a reply to this message

scott wrote:
> I'm still working on it :-)

The XNA samples that MS gives out have the screens actually being removed 
and recycled when they're no longer active. The background screen just 
overrides the "Remove me when someone is on top" routine to not remove 
itself.  But you still want it to go away during actual gameplay.

I finally got it worked out, and I wound up doing factory methods for the 
various types of standard screens. It's kind of twisty.

Next on the list is refactoring the "InputManager" (which used to be an 
InputManager and an InputState) into the thing that manages the controller 
hardware and the thing that interprets button presses as actual semantically 
meaningful stuff (e.g., "enter" or "green button" translates to "menu entry 
accepted" on menus, but not during gameplay). Then I can override buttons 
and add UI sound effects as appropriate.

By the time I get a trivial "game" to test this whole infrastructure, I'm 
going to have a game possibly even worth putting out there. ;-)

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

> By the time I get a trivial "game" to test this whole infrastructure, I'm 
> going to have a game possibly even worth putting out there. ;-)

OOC are you developing this for the xbox or windows or both?

Post a reply to this message

scott wrote:
>> By the time I get a trivial "game" to test this whole infrastructure, 
>> I'm going to have a game possibly even worth putting out there. ;-)
> 
> OOC are you developing this for the xbox or windows or both?

Right now I'm doing all the development and testing on Windows, but I'm 
expecting to release it on the XBox when I'm done.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

> Right now I'm doing all the development and testing on Windows, but I'm 
> expecting to release it on the XBox when I'm done.

I'm seriously tempted to get an XBox just for the coolness factor of being 
able to play a game on a console that I wrote.  Although I don't think my gf 
will understand why we need it in addition to the PS3 and Wii!

Mind you I always seem to start projects when I have plenty of spare time, 
then work/life gets busy and I lose interest.  I have a folder full of 
unfinished projects!

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Mind you I always seem to start projects when I have plenty of spare time, 
> then work/life gets busy and I lose interest.  I have a folder full of 
> unfinished projects!

  You need a job which coincides with your projects... :P

-- 
                                                          - Warp

Post a reply to this message

>> Mind you I always seem to start projects when I have plenty of spare 
>> time,
>> then work/life gets busy and I lose interest.  I have a folder full of
>> unfinished projects!
>
>  You need a job which coincides with your projects... :P

I don't think any manager is going to want an employee who loses interest in 
a project after completing perhaps 10% of it!

Mind you, I suspect some people have a job where they work directly on the 
first 10%, then tell other people to finish it off - that would be perfect 
:-D

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> Mind you I always seem to start projects when I have plenty of spare 
> >> time,
> >> then work/life gets busy and I lose interest.  I have a folder full of
> >> unfinished projects!
> >
> >  You need a job which coincides with your projects... :P

> I don't think any manager is going to want an employee who loses interest in 
> a project after completing perhaps 10% of it!

  That's the point: If you get paid for completing a project, you will
complete it (or face unemployment).

-- 
                                                          - Warp

Post a reply to this message

>> I don't think any manager is going to want an employee who loses interest 
>> in
>> a project after completing perhaps 10% of it!
>
>  That's the point: If you get paid for completing a project, you will
> complete it (or face unemployment).

That's exactly why I would never want to code projects to completion for a 
living, I'd either be bored for 90% of the time or fired.

Post a reply to this message