bomberman javascript multiplayer
this post is a documentation briefing about the project that runs here:
http://www.e-forum.ro:8080/dynagame/index
In order to provide the platform for users to play against users bomberman online, we have to :
1. create the possibility that a user can create a game, or join a game created by others
2. we must let the user choose the variant of the game he wants to play, or let him customize the game
3. the game can be customized in different ways: max number of players, filter the users that can play the game, arrangement of the rocks , with or without monsters, time limit or not, with powerups or not, etc …
Architecture::
we have a GamesContainer that hold all the games.
when a user cretes a game, you add it to the GamesContainer.
you can retrieve a game from it by providing the id of the game.
you can also obtain a list of all games on the server.
a game is represented by the Game class.
it has an id, which is a number autogenerated, and incremented by 1 , and starts from 1 upon every restart of the servlet container.
a game has a status, it has a creator, players, viewers.
it also has a map, with rocks and walls, and powerups, and monsters.
the game class must be able to transmit that to the browser, so that the js code can paint the map.
Communication done to assure the game can be played by users across the internet.
the philosophy:
the first client sends a request to the server in order to create the game.
then, the other players will just join the game, so their first request will be to join the game.
this is done by providing 2 links:
1. create new game and
2: a page with all active games existing on the server and a small status on those games: how many number of players are in that game.
upon first request they must tell the server the following info:
- username
- gameid : null if the game is to be created, or an int X the gameid already existing on the server.
- in case game is to be created, properties of the game are to be sent if the user wants to customize the game
- number of cols and rows, monsters yes or no, powerups yes or no, etc … , arrangement of fake walls
The server does the following upon getting the initial request:
- it locates the game / creates a new one
- adds a new player to the game -
it positions the new player so that in doesn’t stands on a wall, and safely away from the other players.
The server responds upon initial request with: – the game arrangement: walls, powerups, players’ positions and attributes, etc…
Game ideas:
1. a game map huge, where anybody can join and kill other real players.
2. players can team up, and teams can play against players or other teams.
Technical observations:
1. the http header the browser and the server are sending must be reduced drastically, in order to have a packet sent through the wire as small as possible, like in the tcp socket based games.
2. there will be 2 connections: one long polling connection , that will wait for the server to send some info based on an event generated by the other players and another one that will go with a request to the server informing that this player just generated an event. the events here are 6, all keyboard type:
4 arrows [keydown event]
keyup event [meaning stop any movement]
and space – bomb launch.
these key events generate game events and act on the character and through the server on the character on the other web pages related to this game.
3. the client code will adjust the positions of the other players and other state variables [fakewall destroyed, speed increased for player X] according to the server. the server sends state [ex: x,y of players] + the state counter, and the client game takes that info into account if and only if server state counter > last server state counter applied. the real process should be like this: any client page, has a game with 1 character [its hero] controlled by the user and X other characters controlled by the server [actually other players]. the code on this page is master reference for the hero, and the server listens to this code about the hero; and the other code on other client’s pages listen to the server about this hero state. the game running on every page has a stateCounter, and the server game object has one too. when an user generates an event , the eventCode [ keyCode in my implementation] is sent to the server + the hero’s state [x,y for now]. this info, generates an event on the server, and all other requests that are suspended by jetty’s continuation mechanism are resumed, and the hero’s info is sent to the other players’ browsers. this way , the eventCode reaches all web pages linked to the game, and the js code takes care of acting on characters. if the state is not the same as the one on the server, then the js code adjust it. this usually happens not only because of network delays but mainly by the fact that setInterval doesn’t execute the same on all machines , unfortunately.
4. when one sends messages too fast [fast arrows changing in the game] , the others do not have time to reconnect to get subsequent messages. for this, a stack of events for these things will be created on the server, and the whole series of events gets sent upon reconnection of the interested parts.
Very interesting project. Keep updating the progress and good job so far!!
Few queries,
1. the server will be handling all the rules? (player 1 died etc)
2. when client sends keydown/keyrelease events (and grid co-ords/valocity) to the server, the server then disemminates these to all the other clients. I presume the clients would then trigger that player to continously walk until it received a key released command.
3. Are you using ‘messaged received’ notes backs to the server (overhead in traffic but ensures the server that the message was received).
4. oh and finally when a client looses connection will they just jump to their new location or will you blend the transittion in (e.g. make the client move the character at x2 rate until they’re fully synced with the server again)
alex, thanks for the questions.
here are the responses:
1. no, not all the rules, only the important ones. for now it plays the role of transmitting info from player to player, and that’s it. it will also keep the history of the games played, so you can re-play an old game [view only mode].
2. yes, the server disemminates that info by PUSHING this info to the others. when the clients receive that key event, the js code takes control and moves/stops the respective player accordingly.
3. no, i do not. there is a paper here related to carmack’s network code. i try to follow that. it is based suited for web-based multiplayer games in my opinion. here is the link http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking. there is much to do on this issue, i intend to make it as a separate lib so i/others can use it in other game projects too.
4. right now it jumps, but yes , what you say is the way to go.