 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Actually, I think that clued me in a bit. They *are* all of type
> "object". ;-)
>
> So I could just have a list of objects, and when I get an update,
> (dynamic)-cast each element to a IUpdatable and invoke that if it works;
> when I get a draw, cast each to an IDrawable and invoke that if it
> works, etc.
>
> Ugly, but it'll do the trick, I think.
Ah yes, ye olde "upcast everything to Object" antipattern. :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> It wasn't an entirely serious suggestion. (Although you could probably
> make it work. Just have the functions point to the state you want them
> to mutate...)
We already have that. We call them "objects". ;-)
No, seriously, what do you think a pointer to an array of closures all
referencing the same variable is?
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> There's no way to make a "collection of objects that implement
> IGameComponent, IDrawable, and IUpdatable" as far as I know.
I suppose you could subclass a collection of IGameComponents
and add run-time type checks to only allow adding objects which
also implement IDrawable and IUpdatable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>
>> Actually, I think that clued me in a bit. They *are* all of type
>> "object". ;-)
>>
>> So I could just have a list of objects, and when I get an update,
>> (dynamic)-cast each element to a IUpdatable and invoke that if it
>> works; when I get a draw, cast each to an IDrawable and invoke that if
>> it works, etc.
>>
>> Ugly, but it'll do the trick, I think.
>
> Ah yes, ye olde "upcast everything to Object" antipattern. :-D
Well, it gives me the advantage that I could use the same container as a
"service provider." So as soon as you create something that inherits from
a specific interface, you can also retrieve that thing from other
components. This should work out better with what I'm trying to do, which
is more a scene manager (opening screen, start menu, options menu, game,
high-score list, cutscenes, etc) than a single-screen game. The services
manager that comes with XNA is tied to the overall game, meaning you
couldn't have (say) different gamepad managers or different cameras for the
different sections.
But yeah, it would be a generic bag'o'objects, which is certainly not the
best way of doing things.
http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gameservicecontainer.getservice.aspx
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> Darren New wrote:
>
>> There's no way to make a "collection of objects that implement
>> IGameComponent, IDrawable, and IUpdatable" as far as I know.
>
> I suppose you could subclass a collection of IGameComponents
> and add run-time type checks to only allow adding objects which
> also implement IDrawable and IUpdatable.
Yeah. I think I'm just going to make it an array of objects, and only act on
the ones that have the right routines defined.
Unfortunately, GameComponent also implements a whole bunch of stuff that
isn't in the interfaces, like LoadContent (for loading textures and such
whenever the screen resolution changes) and UpdateOrder (for determining
what order to update the components in).
I think I'll just do it myself. The stuff that's already there isn't that
sophisticated, and the promise of lots of people building standard
components apparently didn't materialize because MS never released the
point-and-click "designer" part that would let you build games out of
components the way you build Windows apps out of widgets.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> Darren New wrote:
> > Actually, I think that clued me in a bit. They *are* all of type
> > "object". ;-)
> >
> > So I could just have a list of objects, and when I get an update,
> > (dynamic)-cast each element to a IUpdatable and invoke that if it works;
> > when I get a draw, cast each to an IDrawable and invoke that if it
> > works, etc.
> >
> > Ugly, but it'll do the trick, I think.
> Ah yes, ye olde "upcast everything to Object" antipattern. :-D
Yeah, that kind of OO programming has always been considered bad design.
If C# offered multiple inheritance (I don't know if it does), then you
could inherit all the objects you are using from GameComponent and your
own "base class", which is what the container then contains.
(Of course this solution wouldn't help if you have to store objects
which have been eg. instantiated by the library framework itself because
those would not have been inherited from your "base class".)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.04.2010 22:46, schrieb Warp:
> If C# offered multiple inheritance (I don't know if it does), then you
> could inherit all the objects you are using from GameComponent and your
> own "base class", which is what the container then contains.
>
> (Of course this solution wouldn't help if you have to store objects
> which have been eg. instantiated by the library framework itself because
> those would not have been inherited from your "base class".)
I guess the typical C# approach to this type of problem would be wrapper
classes, which IIRC are not too difficult to write in C#. Such wrappers
could then just implement a common interface you intend to support.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Yeah, that kind of OO programming has always been considered bad design.
Actually, in this case, it kind of makes sense. You want to call draw() on
things with a draw() function, call initialize() on things with an
initialize() function, etc. Basic duck typing.
> If C# offered multiple inheritance (I don't know if it does),
Only via interfaces. Much like Java in that respect.
> then you
> could inherit all the objects you are using from GameComponent and your
> own "base class", which is what the container then contains.
Then everything would be of type GameComponent, and that wouldn't really fix
that I wanted to use both GameComponents and my own stuff. :-)
In other words, I wanted a generic list that would hold both GameComponents
that other people wrote that I don't have the source to, as well as my own
components that have the same routines but a different base class.
> (Of course this solution wouldn't help if you have to store objects
> which have been eg. instantiated by the library framework itself because
> those would not have been inherited from your "base class".)
Oh. Yes, right, that's the problem. Other people are writing those
components. That's what makes them "components." :-)
Altho I found another sample project that the documentation makes it look
like it's using the same framework I want to use (same class names, layouts,
etc), as well as talking about using custom GameComponents as part of it, so
I need to take time to dig into that source and see if they changed the
framework to invoke the right routines of a GameComponent as needed.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > If C# offered multiple inheritance (I don't know if it does),
> Only via interfaces. Much like Java in that respect.
I really can't understand what would be the problem in supporting
full-fledged multiple inheritance.
If your answer contains the term "diamond inheritance", then forbid
diamond inheritance, not multiple inheritance.
(Could this be, perhaps, related to garbage collection? It makes GC a lot
more complicated if references don't always point to the beginning of the
allocated memory block?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I really can't understand what would be the problem in supporting
> full-fledged multiple inheritance.
>
> If your answer contains the term "diamond inheritance", then forbid
> diamond inheritance, not multiple inheritance.
If you add multiple inheritance to a language where every class inherits
from a common base class (Object), every time you multiple-inherit you're
getting a diamond.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
