Ideas for time-keeping in a webbased RPG?

Question

I'm assigned a task of doing the preliminary research stuff for a web-based MMO RPG. Now my buggiest problem here is "web based" vs "MMO RPG". I did some research about time keeping systems and I'm totally confused as how exactly something as real-time as an MMO-RPG can work on some pull-only (unidirectional) platform like HTTP.

I know there is also a turn-based alternative to time keeping but can it work in an MMO setting ?

EDIT: Take a battle for example, player A (human) wants to attack Player B (also human) in the open. How does it work when when player A issues the "attack" command on player B ? how do I inform player B that he is being attacked ? and then how exactly the battle goes on between the two in an HTTP based communication channel?

To my knowledge this is impossible unless you resort to another technology (HTML is 1-way, that is you can just ask server and get response, server can't update you unless being asked to. this is very well-known and simply explained). So I though maybe I can somehow change the whole timekeeping model from real-time to a more non-real-time model (towards a turn based RPG for example) and somehow work around the whole problem of "interactivity".

EDIT2: It is not that I don't wanna use any server side technologies. For sure it is not gonna work client-side-only even for the most trivial of the multi-player games, let alone an RPG. So sure there would be a (probably complex) server side component to it (the so called Game Engine I suppose). The problem is not the technology that implements the logic (game mechanics) bits but the communication technology and how it limits the game mechanics abilities (like how real-time or turn based it is gonna be). HTTP is a request-response protocol meaning you get served only if you ask for it (explicitly send a GET or POST request to the server). HTTP server can not inform you if anything of interest happens in the game world unless you refresh the page (as some suggested) or you use some bi-directional tech (totally different animals) like Flash, WebSock, HTML5 etc etc.

So maybe the question is: Is it possible to implement a MMORPG using only HTML5/PHP and no periodic page refreshes? if so what would be rules to make it an MMO-RPG?

Can't explain it any clearer. Sorry :D

Answer 1

If you need realtime push you will probably end-up using some sort of TCP mechanism for your client.

If you use flash have a look at flash.net.Socket

Else for HTML5/javascript you could use the WebSocket API for modern browsers. To add support for the older ones you could get inspired by this answer. It suggests using java or action script to bridge your JS client with your server:

• jsocket
• Stream
• socketJs

On the other hand if lag is not the major issue then you can start prototyping with the usual HTTPRequest methods.

---

Edit in answer to ashy_32bit's:

I want to make an MMORPG work in a non-real-time platform like classic HTML+Java script (read Ajax) and not any fancy Flash or HTML5 or client-server or anything

Consider using JSON if you need a simple data interchange format. It became very much the defacto standard, It is used even in AAA C++ games for things like leader boards, social integration, micro transactions...

Also what do you mean by RPG? Today this monicker is used for a large variety of games, from text to action RPGs going through card and figurines based games.

I would strongly suggest you play a few web based MMOs first and then you can start figuring out what you really want to do.

Will your game be more text based? Will it be more graphics based. Will the graphics be static, will they move and interact like in action games?

Text/static graphics

The thing about existing web based MMOs is that they are mostly text based or rely heavily on static graphics. They already include mechanisms for combat resolution. Usually they are either turn based and the user's client interface will simply fetch the latest events and highlight the ones that have not been highlighted yet.

Players periodically receive an amount of actions to execute, can accumulate a fixed amount of actions and can spend them for buildings/unit generation, research, attacks etc...

In this case the server can simply react on the clients' requests by fetching data relevant to the player, handling the player's action fetching and sorting the data relevant since the last acknowledged request and sending the results (either as a new page or in the form of a XML/JSON result).

Action

Realtime MMOs rely heavily on animations and large amounts of data about the immediate state of other players/mobs/environment. You will rather stream deltas of the game state in the zone/instance relevant to each players.

In that case using binary data over UDP or TCP is deemed preferable. The more players you have to serve the more compression and savings you have to do in regard of data transmission.

Also you want your server to run the game environment instead of simply fetching data calculating and storing sending the result because the amount of actions, interactions is much larger you can't simply keep fetching and pushing data to your store. It has to live in the server's RAM and be periodically saved but not upon every action.

---

Is it possible to implement a MMORPG using only HTML5/PHP and no periodic page refreshes?

Yes. You can. But when you speak about HTML5 it includes javascript. It means you intend to refresh the content of a canvas or on the page dynamically. And PHP is not suitable for more action oriented games.

For more action intensive games I would recommend writing your server with - in order of preference:

• ERLANG which is made for large distributed systems. Remember as a game grows the server side will have to grow: become distributed. And while PHP+SQL seem like a good solutions for scaling there are other solutions. This presentation is not fully relevant to the subject but it demonstrates the usefulness of the language in situations involving large amounts of users.
• C/C++ the amount of games written in this language attests of its popularity. It will be much more powerful. As you have direct access to primitive data structures you can also harness the power of hardware accelerated features like OpenCL. And it will be easier to find game developers who have good experience writing games in C/C++. But if you are not familiar with it I would not recommend using it for your server.
• Java. It's easier to quickly write a game server in java. Like with C++ you can then either create your own syncing mechanism across servers or simply break the game into zones and/or instances.

if so what would be rules to make it an MMO-RPG?

This question is very weird. My answer would be; allow a large amount of people to interact in a role playing game...

Answer 2

Here is how it was done in olde web-based RPGs circa 10 years ago:

• HTML Meta Refresh tag was used to automatically refresh the combat page (or maybe iframe) each N seconds
• In one of those games combat worked the following way: it consisted of rounds, and in each round the participants had limited time (say 15 seconds) to submit their turns. These turns then resolved simultaneously.

On the top of my head, here is how I would implement a simple game like that:

• Store all game state (e.g. location of all players and NPCs, current state of all fights in progress etc.) in an SQL database, rather then having it in the memory of a game server application. This automatically gives you persistence and thread-safety.
• Implement a set of scripts for players to interact with the game world. Since you use a database, it could be even something as simple as PHP scripts. For example, you could have a move.php script, which would accept location parameter. After checking all game rules (e.g. how often and where the player is allowed to move?), this script would issue a query to the database to change the location of the currently logged character ID (which would be stored as a cookie)
• Create another "game loop" script that would be executed regularly. You can do it with cron, or simply implement an actual loop, which would sleep for, say, 1 second after each iteration. The purpose of this script is to increment the game time counter and resolve timed events, for example, advance fights to the next round each 15 seconds.
• Finally, make the primary interface script, which would automatically update using the meta refresh HTML tag. The server would generate the correct page depending on the state of the player character, e.g. if it is currently in a fight, the page would contain buttons for possible abilities that can be used in a fight.

Alternatively, instead of many separate scripts, you can have a single game server application that would listen to HTTP requests and process them accordingly.

Answer 3

I'm by far no expert, but if you want 2 human players to be able to interact in anyway you need some form of server-side language, simple html dont have the functionality needed. You need to somehow store/get the actions they perform.

Might be possible with WebSQL though but then again it is HTML5.

Why exactly don't you want to use server-side?

Answer 4

Without using something like flash or a websocket, there is still a way you can facilitate bi-directional communication, though it is it a bit of a hack: http://en.wikipedia.org/wiki/Comet_(programming)

Essentially, you are making an HTTP request for which the server does not specify a size, so the browser will hold it open and the server can then continue to push data as events occur. The client can then make additional requests in the normal way which the server will process, update its state and then push out updates to the clients through these standing requests.

In terms of it being "real time", there are two basic approaches you can take, which really depend on what sort of events are taking place in your game.

The first would be to have a "tick", where the server refreshes the state of the game on some interval. If you need smooth, continuous movement, this is probably what you want. The exact rate depends on how frequently the client needs to be updated in order to not feel laggy. For reference, a fast paced action game will usually feel pretty good at a frame rate as low as 20 frames per second (50ms per frame), less action means you can push that up higher and thus stress the server less.

The other option is to schedule events. If you have discrete movement (i.e. on a grid) and action durations that tend to be measured in seconds, this might be a better approach. Each time some action takes place, you add it to the schedule, which fires off some sort of notification or callback when the event needs to be resolved.

Answer 5

Take a look at Node.js + socket.io combination. I'm currently finishing a multiplayer browser game with it and I'm very satisfied how it works. socket.io uses websockets by default, but falls back to flash sockets and then XHR, JSONP, htmlfile and other long-polling/Comet variants. This allows you to cover all browsers using a single, very simple interace.