Simple Game Server -- request for help

[Björnke von Gierke]

As you noticed, webservers are really bad at sending data to clients without being prompted first.  If you are free to use your own computer as server, i suggest doing it like chatrev, having a server stack that is publicly available on the internet. That way is the easiest way to avoid the statelessness problem that webserver always have.

One thing to note is that libURL is really bad with repeated request, it just returns "request already loading" or similar, and there's no easy way to just force it to get the url instead of being annoying. So in an action game or chat environment, on the client side, you most likely need to use something else. That could mean making your own (basic) http code, or using curl (from the shell).



besides said caveats, i think you

On 29 May 2011, at 18:05, Jim Lyons wrote:

> Goal: To create a general purpose CGI server that would allow two players to exchange moves over the internet. Game platform might be Live-Code stack or other client capable of internet communication, either desktop or mobile. Note that the scope of this is initially only for private, low-traffic, two-player games, perhaps able to support several simultaneous games. Think board games, not action games.
> 
> First thoughts:
> 
> 1. Simple-minded, stateless version. The server accepts moves with arbitrary 'from' and 'to' code names for players, and takes requests for moves (i.e. polling) using the same code names. It responds to moves with a simple ACK, and stores the move. It responds to requests for a move with a NO-DATA, if none, otherwise returns the stored move and clears the buffer. Clients are responsible for game logic and move alternation.
> 
> 2. More sophisticated, protected, state-aware version. Players first register with server in protected area. Server knows whose move it is and which players are paired in a game and responds only if appropriate. However, it does not know details of game so cannot verify moves nor detect end of game.
> 
> In both of these scenarios, players' clients must poll for next move of other player. That is a disadvantage since it is similar in load to a chat server, which service providers discourage. However, in slow(ish) board games, polling rate could be set low enough to make this acceptable.
> 
> Questions:
> 
> 1. Is this a workable design in general, or is there a better way? (I don't know anything about peer-to-peer communication, just http/CGI.)
> 
> 2. Is there a way (using some kind of push method) that could eliminate polling for moves? It would be nice to extend the capability of the server to support faster games, such as between robot players.
> 
> 3. Does publicly available game server code already exist that I could install at On-Rev?
> 
> Any comments, suggestions, pointers welcome. (This is not for any commercial application, just for possible educational use.)
> 
> Jim Lyons
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode