A common problem in realtime multiplayer games is that of arbitrating events and resource assignment across clients e.g. consider a simple multiplayer game scenario in which there are 4 monsters available in different colors and each player has to pick one to play. The additional condition is that no two players can pick a monster of the same color. Initially all 4 colors are available and as players select them – they become unavailable to the others. Say player 1 selects red but before the event can reach the other players – player 2 from his client also selects red. Now both the players, 1 and 2 will feel that they selected the red monster in time but immediately afterwards get the event that the other player too has selected red. How do they resolve this problem? Things will get even more complicated when the number of common resources and players involved will increase.

It is clear that some central arbitration will be required to resolve such conflicts. In case of multiplayer games which have an authoritative server, this is easier to resolve as the resolution code can be written on the server. In a pure cloud solution in which all the business logic has to be written on the client side, arbitration can be difficult due to such latency, race conditions and connection issues.

AppWarp helps its developers to easily resolve such problems through its lock/unlock room property APIs. Through this, AppWarp guarantees that only a single client can hold a lock on a given property at a time. Lock requests by other clients for a property that has already been locked by another client are rejected. When a client leaves a room or gets disconnected – any property that had been locked by it, is automatically unlocked and made available to the other clients. This simple and innovative concept allows developers to solve many such common problems with just a few lines of code on the client.

This problem can be easily solved using AppWarp Persistent room properties and lock/unlock API. Details of room properties and related information can be found here:

Defining Room:

As per the requirement, a room has four different players so I have created a room with these properties.

Hashtable properties = new Hashtable();
properties.put("red", "foobar");
properties.put("green", "foobar");
properties.put("blue", "foobar");
properties.put("yellow", "foobar");
theClient.createRoom(""+System.currentTimeMillis(), "owner", 4, properties);

Handling Lock Properties:

On SelectionActivity, all monsters are available for the selected room. User has to select any one monster. If user selects red monster:

Hashtable table = new Hashtable();
table.put("red", “foobar”);
theClient.lockProperties(table);

By calling this api call, the “red” property will be locked by the calling user and all subscribers of the room will get the notification for this

public void onUserChangeRoomProperty(final RoomData roomData, final String userName, final Hashtable tableProperties, final Hashtable lockProperties) {
….
}

In this notification, two hash tables are available – one for the properties and their values and other for the locked-properties and the holders of the lock. If any user locks some room property (i.e holds a lock) then no other user can remove or edit it.

As we get notification for locking a property we change the UI of screen.

Here is the logic to handle property change event.

public void handleLockInfo(Hashtable properties, Hashtable lockProperties){
if(properties!=null && lockProperties!=null){
Enumeration keyEnum = properties.keys();
while(keyEnum.hasMoreElements()){
String key = keyEnum.nextElement();
String owner = lockProperties.get(key);
if(owner!=null && owner.toString().length() > 0){
handleMonster(key, false);
}else{
handleMonster(key, true);
}
}
}

}

In this method we remove monster from the screen as someone has a lock on it.

private void handleMonster(String name, boolean setVisible){
…..
}

If any user disconnects or if he loses connectivity then ApppWarp automatically unlocks properties locked by that user and sends notification to all the subscribers.

So in SelectionActivity, if we get a notification for changing room property because a user has left the room (corresponding property is removed from the lock table) – we change the UI and make the locked monster available to others again.

Entire source code is available and can be downloaded or viewed from our git repo.

If you have any questions or need further assistance to integrate this in your App, please feel free to write us at support@shephertz.com.