RFC: Wherigo Multi-Player API

[matejcik]

A rough draft of what i came up with recently. I have an implementation in mind, but i can't promise any kind of timeline.

This would, of course, only work in OpenWIG, and only on devices with functioning Bluetooth support (so many WinMobile smartphones are out), and of course limited by the number of simultaneous BT connections the device can handle (remember that in many cases the GPS will eat one)

 

so without further ado: The Multi-Player API.

 

1. mode of operation

 

When enabled, your device would periodically scan its surroundings for other devices like it. If it found one, it would establish a connection, exchange greetings, showed some confirmation dialogs to users and then create link objects in Lua.

 

Lua code could then pass and receive messages, in the form of method calls: each new player would represent a new source of events and a new object to manipulate.

 

The object would allow you to query the other player's nickname, GUID of their cartridge (two cartridges could be made to cooperate with each other - much like Pokémon Gold/Silver) and connection status (in range/out of range)

 

2. the API

 

core of the api is a new object class: openwig.RemotePlayer

it has the following properties:

Name - the nickname of geocacher who downloaded the cartridge

CartridgeID - the GUID of the cartridge

CartridgeName - the regular name of the cartridge

CartridgeVersion - the end of the world as we know it

InRange - true/false property indicating whether the connection to this player still exists

and one method:

Send(nameOfMessage, parameter)

- nameOfMessage must be a simple alphanumeric string, this will be the name of event on the other side

- parameter can be a string, number, true/false, boolean, Lua table or nil.

this might possibly include object references (passed only as IDs - basically indexes into AllZObjects table), but i am still not sure about how good idea this is.

returns True if the message was successfully sent, or False if sending failed (probably the other side disconnected or went out of range)

if you try to send a message while the other player is out of range, you get False. it is your responsibility to make sure that the message is re-sent later.

getting True does not mean that the remote side processed the message or that it even supports it.

 

ZCartridge object gets two new events: OnPlayerInRange(openwig.RemotePlayer), OnPlayerOutOfRange(openwig.RemotePlayer)

 

Player object gets new events, each for every supported message. same as with Commands: OnWeirdMessage(openwig.RemotePlayer, parameter) is called when a remote player represented by the RemotePlayer variable sends a message named "WeirdMessage"

 

3. possible usage

 

a simple game of cards: one player deals, others receive.

the dealer sends "Deal" messages with "cardname" as parameter - this unit makes sure that every player has different cards

individual players can then send "Play" messages with "cardname" as parameter back to the dealer, and dealer resends "CardPlayed" with {"playername","cardname"} to every other player

 

two-cartridge cooperation: each player has a different version of cartridge. each must pick up an item that the other requires to complete.

then they meet in a designated zone and swap completion messages

 

4. comments, questions?

[+TheHarvesters]

two-cartridge cooperation: each player has a different version of cartridge. each must pick up an item that the other requires to complete.

then they meet in a designated zone and swap completion messages

 

The players could have the same cartridge, but the cartridge allows different character options, e.g. Boy and girl, or builder and architect, or warrior and wizard - whatever that game dictactes.

 

Those different characters may have the abilities that enable them to perform certain tasks required to fulfill tasks and collect items or interact with virtual characters to move through the game. Maybe both (many) characters need to be present to complete a task - like bringing down the boss needs x many players or a variety - with different items.

 

Also - would they have to meet in a designated zone? Couldn't they meet in any zone (if the cartridge were developed that way), or couldn;t they even meet outside of a zone - because the remote-player proximity could work in a similar way to zones?

 

Anyway - The sky is the limit. I like this idea.

 

As sTeamTraen has already queried - would bluetooth actually be 'strong enough' for this?

Edited June 17, 2010 by TheHarvesters

[+TheHarvesters]

Oh, and sTeamTraen - how about Earwigo being modified to accomodate the new Object class etc? (assuming this works out sometime)

 

Edited June 17, 2010 by TheHarvesters

[matejcik]

Also - would they have to meet in a designated zone? Couldn't they meet in any zone (if the cartridge were developed that way), or couldn;t they even meet outside of a zone - because the remote-player proximity could work in a similar way to zones?

sure, sure .e) that was the first thing i came up with.

 

As sTeamTraen has already queried - would bluetooth actually be 'strong enough' for this?

for some usecases yes, it even has its advantages - you have to be physically close to the other player, so if he's a cheater, you can punch him in the nose more easily ;e)

for others, not so much - e.g. if there was only one item of a kind in the cartridge, there is no good way to check which player picked it up first, unless they are travelling together

 

but the big advantage of BT is that it is simple to implement, does not require any kind of server and works in areas without cell/wifi coverage

 

5. one more thing

 

the remote players should probably be shown in "You see" list. it should be possible to use them as regular Character objects - i.e. assign description, media, commands.

there should probably be a library function that would "copy" a selected character object's properties onto the RemotePlayer instance - so that if the other player chose to be a girl, you could display his character as a girl etc.

[+TheHarvesters]

5. one more thing

 

the remote players should probably be shown in "You see" list. it should be possible to use them as regular Character objects - i.e. assign description, media, commands.

there should probably be a library function that would "copy" a selected character object's properties onto the RemotePlayer instance - so that if the other player chose to be a girl, you could display his character as a girl etc.

Nice!

 

and then I thought... oooh oooh... If Groundspeak ever update the website, they could have a feature where players could store their own avatar information. So as well as downloading the player.name you would get the player media, maybe an alternative 'game name' which they could change for each cartridge they downloaded, or....

 

oooh oooh! maybe each cartridge designer could even specify the variables they wanted the player to populate before downloading the cartridge - to personalise the game experience more.

 

[+sTeamTraen]

Advantages of using Bluetooth:

- No communication costs.

- Can work with non-phone enabled devices (but will anyone ever make one of those again?).

- No server-side effort required.

 

Disadvantages of using Bluetooth:

- Players have to be within 10 metres (or a bit more) of each other in order for interactions to take place. (Games which rely on constant interaction are going to be hard to do.)

- Difficult to scale up to more than 2-3 players.

[+TheHarvesters]

Advantages of using Bluetooth:

- No communication costs.

- Can work with non-phone enabled devices (but will anyone ever make one of those again?).

- No server-side effort required.

 

Disadvantages of using Bluetooth:

- Players have to be within 10 metres (or a bit more) of each other in order for interactions to take place. (Games which rely on constant interaction are going to be hard to do.)

- Difficult to scale up to more than 2-3 players.

That's a good inisght to someone like me who doesn't really know this stuff.

 

I'd also say it's a favourable set of pro's and con's - there is a lot of potential in that.

 

Is there a possibility that bluetooth will develop to make this even more attractive? i.e. longer range and bigger scale of players?

[+sTeamTraen]

Is there a possibility that bluetooth will develop to make this even more attractive? i.e. longer range and bigger scale of players?

To a first approximation: no.

[matejcik]

well, somewhat bigger scale, probably yes. longer range, probably not.

 

but blah blah, bluetooth it is for now, at least for this experiment ;e)

 

what i'd like to know, do you see anything in particular that is missing from the draft? some functionality that is important but i overlooked it?

[+TheHarvesters]

what i'd like to know, do you see anything in particular that is missing from the draft? some functionality that is important but i overlooked it?

I don't see anything missing. The recognition of in/out of range, coupled with the ability to send a 'message' gives tremendous potential. In game the message could become a task, or an item, even another character... so that's good.

 

Someone else would need to comment on the Object / class / method completeness, but I expect you are confident you have that covered anyway.

 

I'd be very excited to see this come to fruition, but then the challenge will be to see how many developers and players there are out there who would pick up on it.

Paul.

[+charlenni]

What's about the case, if the player didn't want events from the a special player in the sourrounding? Could you disable a special player? Could you transfer this object also to WLAN and Internet? I know, you didn't want to be online to play cartridges, but in a few years, i think, we did have more mobile internet than today.

 

I think the most remarkable thing is, that this cartridges wouldn't be compatible with the normal players. Or could you implement the objects, so that they also work, even if you play the game on a garmin device?

 

Best regards

Charlenni

[matejcik]

What's about the case, if the player didn't want events from the a special player in the sourrounding? Could you disable a special player?

you have to enable the other player first. i didn't think about disconnecting later, that could certainly be added if it seemed necessary

Could you transfer this object also to WLAN and Internet? I know, you didn't want to be online to play cartridges, but in a few years, i think, we did have more mobile internet than today.

it's much harder to do proximity detection with wi-fi, bluetooth is designed for it.

if we're considering internet, the protocol would probably have to be somewhat different.

I think the most remarkable thing is, that this cartridges wouldn't be compatible with the normal players. Or could you implement the objects, so that they also work, even if you play the game on a garmin device?

sure, this is no problem. this protocol works only with new events that will not be started on garmin, so the new code will not run and everything will stay as before.

of course, if you need more players to complete one cartridge, it will be impossible on garmin. but the cartridge will work.