Thoughts on Some Issues in Developing 2 Player Web Browser Based Games

Posted on 11.01.11 1:59AM under Arts & Entertainment

I will use the following trivial game as a concrete example. The game will display toys individually (from a large array of them) to the two players. Each player will decide whether he/she like the toy or not. If both of them liked it or once they both disliked it, they are going to each score a point. If one likes it although other does not, no one score any points. The game is so simple that 3 to 5 year old will have no problem to play the idea. To implement such a sport in a web environment, however, can drive a thirty or forty year old crazy.

It is not really difficult to implement this online game, if user experience is not taken into consideration. We can simply send the main toy to both players when the user finished (we. e., if user offers decided whether he likes the toy or not), browser will send a request to your server to post an individual decisions. If the server gets the results from both players, the score can end up calculated and returned to the user. Otherwise, we just tell an individual the score is not ready yet, and they just need to wait for the other user in order to complete. When the other user does finish, we can return the score along with the next toy as the response so the user can start to look at the next one.

This implementation is easy but it will useful users waiting at many points inside game. When the game is played online, it most likely means that users will have to spend more time waiting than playing and it reduces the fun in the game.

The problem available is that we may not be programming a classical client/server functionality. Since two browsers cannot talk to one another directly, all the information has to feed the server. In Diagram:

 Client1 Server Client2

This suggests, if we do not program correctly, the players have to have to wait two (or even more) internet trips to be able to get the score.

To enhance user experience, one obvious solution is to apply Ajax, to put interaction along with the web server into the backdrop. Another trick is to make use of double buffer so a gamer can view the next toy when the current one is scored. This will make our program more aware of the players; however, it’s going to make the program even more complex, as you can see.

We will make these basic assumptions:

so we will try to minimize may be network traffic before this online game can proceed. However we will make an effort to make the game aware of the user even though we can, so when a network trip can guide the responsiveness, we is going to do so. It is also worth noting that the request and response may be lost and/or out of step, therefore we cannot assume once we send out the information (from the client) it will unquestionably reach the server, and vice verse. Once we find some good information from the client, we have to check that it is not some outdated one. Each party (the server along with the two clients) will generate its very own unique increasing sequence #. Every communication is tagged with such a seq # to avoid processing an out-of-step transmission.

data structure.

On the server side, we will continue the following data structure.

 Toy id, details, status_client1, status_client2;

Toy can have it’s usual attributes together with two statuses one for any client. 


Game current_toy, next_toy

We is going to do double buffer. At almost any given time, we will continue two toys in the adventure. So on server we will have the following info:

 seq_no_server; //which may be global

sgame, seq_no_client1, seq_no_client2; //for each couple of players.

The sgame is going to be sent to the customers whenever necessary and probable.

The client will be in one of many following status, and in that order:

READY, START, WITHOUT A DOUBT or NO (YN for short), YES_SCORED or NO_SCORED, DONE.

The client knows what it’s doing and its standing (for itself) is always up to date. The server could be using sync and one demand behind. The information on one client about the other client could be two requests behind.

Over the server side, when the adventure start the game composition is initialized:


sgame 

current-toy = get_a_toy();

next_toy = get_a_toy();

;

current_toy. status_client1 = current_toy. status_client2 = SET;

next_toy. status_client1 = next_toy. status_client2 = AVAILABLE;

when a request is in: 


Player p = get_player(demand);

if(p == player1) 

If(get_seq_no(request)

Status changes are always initiated at the client and then propagated to the server.

On client we start with:

 cgame = null;

seq_no_server = 0;

seq_no_client = 0;


We need to do several things, one is to process user input, the other is to process server response.


processServerReponse 

If(get_seq_no(response) = YN) 

//we can score now.

update_score();

cgame.curent_toy.status_client1 = cgame.current_toy.status_client1 + '_SCORED';

show_next_toy();

server_out_sync = 1;

If(sgame.current_toy.status_client1 >= YN) 

//server knows we made a decision so

//we are done with the current toy.

//we can move to the next

// this is really unnecessary since we are going to discard right way.

cgame.current_toy.status_client1 = DONE

cgame.current_toy = cgame.next_toy;

cgame.next_toy = null;

If(server_out_sync) update_server(); 

processUserInput 

//user made decisions

new_status = YES or NO;

If(cgame.current_toy.status_client1 == START) 

cgame.current_toy.status_client1 = new_status;

if(cgame.curent_toy_client2_status >= YN) 

update_score();

cgame.curent_toy.status_client1 = new_status + '_SCORED';

show_next_toy();

update_server();



One much more thing, we will need a background job to keep update the server after we made decision but struggling to score yet (considering we don't know the other player's decision).


backround_job 

While(1) 

sleep(1sec);

If(cgame.current_toy.status_client1 == YN) 

update_server();

//optionally, we can constantly query the server

//after we start to work on a toy, in the hope of

// getting the update from server quicker.



Now we have one last problem to solve, when do we feel confident that we successfully finished the current_toy that will happily move to another and so we can perform



current_toy = next_toy? 


NOT we when display the get! Whenever we can display the score, we are confidence that the game is passed for us. However, we still have make sure that the other player knows our decision and to do that we need to tell the server. We do update the server after we display the score. However, we cannot be confident that this update will definitely accomplish the server. We can only do so when we know this server knows our standing is YES, NO or even better.


On the server side, we can discard the current_toy until both clients are done with it or more simply if both clients have started along with the next_toy:


 If(sgame. next_toy. status_client1 > = START OUT AND

sgame. next_toy. status_client2 > = START) 

sgame.current_toy = sgame.next_toy;

sgame.next_toy = get_next_toy(); //this is how we move to the next toy in the server,anyway



The benefits for going through all these troubles? Let's say the player B is always late. It will take a long time for him to make decisions, (or his internet connection is bad). In the original implementation, after your dog made his choice, a request is sent to the server. When the response is arrived at the client, the game may be scored and next gadget displayed. In the double buffered version, a request is sent out as soon as he starts and the response with the request may bring back the other players' decision and which means that now player B can score and move to another toy right away. If we are willing to waste enough network bandwidth, we could make the user experience as pleasant as we can. 2 Player Games, Two Player Games

Post Comments





XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

* Required. Your email will never be displayed in public.

fibromyalgia syndrome fibromyalgia newyork travel payday loan buy cipro sciatic nerve damage ezetimibe narrow angle glaucoma headache sciatica cluster headache glaucoma Poker Software buy ziagen payday loans