![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott <sco### [at] scott com> 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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |