Interfaces for Dynamically Loading code

[Will Pearson]

I'm imagining something like this:

Store Game state in a bundle for now?

And we can then have an interface like this for the dynamically loaded
code to implement

interface DynamicGameUpdate
{
public Bundle updateGameState (Intent event, Bundle currentGameState);
}

Storing everything in a Bundle means we don't have to keep on making
new game state classes with different members if we don't want to and
we can easily send the entire game state via intent at game end.

We also need an standard way of setting up the initial game state
based on an URL, which should also be based upon a set pattern.
Perhaps this can just be an activity that takes a string for the url
and returns a Bundle for the initial game state? So we can dynamically
load a class that extends an Activity and use that?

Will

[tom]

i was thinking along the lines of

public abstract class GameMode {

//stick some util classes here?

public abstract void think() //called every "frame" for updating
internal state

public abstract void gotShot(int playerid){} //i got shot
public abstract void unhandledPacket(byte[] rawpacket) //top level
classes dont recognise this packet
..etc...

}

any class that extends this will be responsible for storing the game
state internally, I think it should be possible to spawn activities
from here a normal.

[Will Pearson]

On 30 May 2011 22:38, tom <bollo...@gmail.com> wrote:
> i was thinking along the lines of
>
> public abstract class GameMode {
>
>  //stick some util classes here?
>
>  public abstract void think() //called every "frame" for updating
> internal state

I can see the need for this if we are doing animations, but otherwise
I would prefer to have named timers that can be created (and stored
functions that are called by each timer, implemented like onClick for
gui elements).

That way you could avoid tying together the implementation of health
regen and score increase for holding onto the hill. Each could have
their own timer.

>  public abstract void gotShot(int playerid){} //i got shot

I like the idea of this but worry that it will lose its meaning in
some situations. Lets say we decide to parse a rawpacket in a
different way for getting shot in a certain type of game. Then we
would have to implement gotShot as an empty function and then create a
new function. Then we would have to remember we implemented it in this
way if we subclassed it,

I'm not sure what the right solution is. Possibly just have them take
rawpackets as inputs?

>  public abstract void unhandledPacket(byte[] rawpacket) //top level
> classes dont recognise this packet
> ..etc...
>
> }
>
> any class that extends this will be responsible for storing the game
> state internally, I think it should be possible to spawn activities
> from here a normal.

Will we want to be able to specify custom UI as well? We might want to
subclass Activity.

Will

[tom]

aah you mean the plugin class does something like:

public MyGameMode(PluginLoader parent){
parent.registerShotListener(this);
}

so it then receives "shot" (i.e. information from anotehr gun)
callbacks? This way we could also have registerRawPacketListener(this)
as an alternative.
It means each plugin doesnt have to worry about the packet format the
gun is using, if we change it later on for some reason then plugins
shouldnt break. The Raw mode stuff would be handled entirely by the
plugin so wouldnt be affected

We could also have some thing like registerPluginActivity which the main
classes can spawn a needed, maybe just add a "tab" for them in the main
UI as an example. The plugins then get bundled with their own activities
as needed

[Will Pearson]

On 31 May 2011 15:30, tom <bollo...@gmail.com> wrote:
> aah you mean the plugin class does something like:
>
> public MyGameMode(PluginLoader parent){
>   parent.registerShotListener(this);
> }
>

Summat like that. Probably worth prototyping a few games with and adjusting.

Will