 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> 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.
Then don't make every class inherit from a common base class. Interfaces
don't, so why should classes?
If you really want must have classes inherit from Object, then simply
allow interfaces to have member variables and function implementations.
Then you'll have full-fledged multiple inheritance without diamond
inheritance.
--
- 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.
Complexity, perhaps.
Also, remember the CIL is designed to support multiple languages. Granted,
you're going to have trouble accessing objects from COBOL, but it's likely
that MI would just make it that much more difficult. There's already kludgey
work-arounds for (e.g.) getting to properties and indexers from languages
that don't have properties.
> If your answer contains the term "diamond inheritance", then forbid
> diamond inheritance, not multiple inheritance.
Impossible if everything inherits from Object. :-)
> (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?)
That's certainly part of it, but you don't need to support multiple
inheritance in the same way C++ does it. Eiffel has multiple inheritance,
garbage collection, and O(1) virtual dispatch. (That last would probably be
quite difficult if you didn't compile everything at the same time, of course.)
C# allows you to inherit from multiple interfaces that define the same
method names and distinguish between them at compile time and runtime.
(I.e., you can already have a Dog::Run interface and a Thread::Run interface
and invoke them that way and have different implementations.) So it's not
just a problem with the metadata and naming. (Eiffel has a different
solution to this problem.)
Some of the rules of the language are based on superclasses. If you throw an
object, it has to descend from Exceptions. A class with value semantics has
to descend from "Values" or something like that. A delegate (like an OO
function pointer) has to descend from Delegate. Etc. Maybe that's part of
the problem.
But really, I don't think there are any obvious technical problems that
couldn't be solved with enough work.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
