android brainstorming

[tom]

I'm going to braindump a load of android stuff here:

Components we need:

> Service to read bluetooth serial port and forward to broadcast intents
>> done a test of this, works a treat but we need to formalise the intent data format
>> also need to receive intents to then pass on to the gun


> Service to forward to central server
>> for map updates, general scoring
>> achievements!
>> player status changes (health, shield, death etc)


> Activities for the UI
>> main screen for health/ammo status
>> "orders" UI - compass heading and distance, with a textual message underneath ("expect fire", "take cover" etc)
>> config interfaces
>> work out some kind of interface "flow" for setting up the gun and starting a game
>> work out a swipe gesture to switch between screens?


> demonstrate that dynamic class loading is easy and workable
>> also find an easier way to package and test the jar files
>> write up a game mode interface and test some simple modes out.
>> perhaps have these as services that interact with the UI using intents?

[Will Pearson]

On 26 May 2011 12:24, tom <bollo...@gmail.com> wrote:
> I'm going to braindump a load of android stuff here:
>
> Components we need:
>
>> Service to read bluetooth serial port and forward to broadcast intents
>>> done a test of this, works a treat but we need to formalise the intent data format
>>> also need to receive intents to then pass on to the gun

An intent has a set of key/value pairs right? In getextras. So we can
just add extra bits to that when we need to extend the intents we pass
round? So we start by having a key eventType with "shot" as a possible
value, so we can just formalise the getting shot event and then work
on others as we find we need them?

I might work on an Intent to JSON string class so we can easily send
intent data to the server.

>> Activities for the UI
>>> main screen for health/ammo status
>>> "orders" UI - compass heading and distance, with a textual message underneath ("expect fire", "take cover" etc)
>>> config interfaces
>>> work out some kind of interface "flow" for setting up the gun and starting a game

I'd imagine we need (at least) 2 different flows?

Flow 1) Gun

1) Pair with Gun (Qr code or manual)
2) Gun gets info about the game via IR game server (?) to get it set
up. It tells the phone the status and game type

Or are we going with 1.5 and having the phone set up the game then get
out of the way?

Flow 2) Experimental
1) Pair with Gun
2) Acquire game server ID (probably just URL). (QR code or manual)
Maybe customised to skip the next phase?
3) Download possible roles/names/teams and code to assign it. Somehow
get assigned one of those.
4) Download custom game code for the role?

>
>> demonstrate that dynamic class loading is easy and workable
>>> also find an easier way to package and test the jar files
>>> write up a game mode interface and test some simple modes out.
>>> perhaps have these as services that interact with the UI using intents?
>

We will want them running in the background if the user decides to
change music etc, so I think services are the way forward.

Will

[tom]

Well I'm thinking the game logic can be done inside a service which
loads the ruleset classes. We shove all the events to it with intents
and it keeps track of the game state (damn the intent system is good!)

I've knocked together a prototype, it starts up, asks you to scan the
gun (currently the BT address of my laptop), connects to it and shows
a basic "health/shield" gui which responds to the word "shot" over the
serial. Its all internally forwarded by intents.
If theres a disconnection the service broadcasts that and stops
itself, shoving the gui back to the "welcome, please scan gun" screen.

its on my laptop atm, when I get a chance i'll push it to my git repo


On May 26, 7:27 pm, Will Pearson <wil.pear...@gmail.com> wrote: