Game delegate

[Cory Kilger]

WARNING: Lots of thinking out loud here. Please proceed with caution.

Thinking about the assignment of secret missions, maybe we should add
an optional class in the game plugin which can be a game delegate.
This can add a hook for the plugin to do additional things beyond the
triggers and actions, like throw up a custom window, alert, or
dialogue box.

For example, say we have the ViciMissionRiskGame class. in the -
initWithGameContext: method it instantiates another class which
conforms to the ViciGameDelegate protocol and assigns it to the game.
Problem: the ViciMissionRiskGame class can't set the game's delegate,
it can only access to the context.

Try again:

The VMRG class already knows the players and the map. Right? So it
can create triggers/actions which say, for example, if Player A
acquires Iceland and Venezuela he wins. The user needs to be notified
of this so that he knows what his missions are. We can't simply make
a trigger/action for this, since there is no way (theoretically) to
tell the game engine what window to show and how to show it and who to
show it to. So we place in the game plugin plist a key like
ViciGameDelegateClass which is a string with the name of the class to
be the games delegate. It's then the ViciGameFactory's responsibility
to instantiate this class and make it the delegate. Then when the
class receives the -gameWillBegin: method, it can put up the custom
window with the necessary information.

I think that works.

Any thoughts?

Cory

[Cory Kilger]

Ah, but there's more.

Now say we have a ViciCapitalRiskGame plugin. We will need some post-
configuration for the game since we can't assign capitals until all
the countries are assigned, which traditionally is done by choosing
countries in turn. This is another place where a delegate would be
useful in custom games.

[Cory Kilger]

Ok. Now why not instead of just using the plugin class to initialize
the triggers/actions we just keep it around and make it the delegate?

On Oct 21, 2009, at 3:31 PM, Cory Kilger wrote:

> Ah, but there's more.
>
> Now say we have a ViciCapitalRiskGame plugin. We will need some

> post-configuration for the game since we can't assign capitals until

[Dave DeLong]

Indeed, why even have triggers and actions at all? Why not just
instantiate the game plugin and have the triggers be methods on the
plugin object?

Dave

[Dave DeLong]

Here's a rebuttal for that idea: By only making plugins operating
during game creation, we allow for the possibility of saving a game on
one computer and finishing it on another computer that doesn't have
that game plugin. It would, however, have to have the map plugin.
(which reminds me that perhaps we do need a game object after all - we
need to store what map etc this is all playing on inside the context)

Dave

>>>> -gameWillBegin: method, it can put up the custom window with the