1
\$\begingroup\$

I'm coding in Python. Currently, with some group of people, we are making a decision about server-side language choice for our web-browser-based strategy game. I have some questions:

  1. Are games like Travian based on asynchronous requests or it's all normal synchronous?
  2. WSGI for Python web apps is synchronous. Does it mean only one request is processed in the moment? If I have 10000 requests, I must wait for each one?
  3. For this type of game, requests based on RESTful or GET/POST methods are most suitable? No need of sockets (I hope so)?
\$\endgroup\$

closed as off-topic by Anko, congusbongus, Kromster, Seth Battin, Josh Oct 15 '14 at 16:02

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about "how to get started," "what to learn next," or "which technology to use" are discussion-oriented questions which involve answers that are either based on opinion, or which are all equally valid. Those kinds of questions are outside the scope of this site. Visit our help center for more information." – Anko, congusbongus, Kromster, Seth Battin, Josh
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ What tech to use is a personal choice and depends on the game you're making, so we've decided to discourage such questions, as there is rarely a "one right answer". Python sounds good to me though. Travian uses AJAX techniques to make asynchronous requests and no WebSockets, last I checked. WSGI doesn't specify whether implementations should be asynchronous. I think there's no need to worry about that for a turn-based game, but if you really want non-blocking, look into Tornado. \$\endgroup\$ – Anko Oct 12 '14 at 19:27
  • \$\begingroup\$ @Anko But when I click "build lvl 2" on building, it sends request with GET parameters e.g ?a='2'&c='fa732d, where a is building id and c is propably something like 'build on level 2'. Those requests are asynchronous too? \$\endgroup\$ – Andrzej Sołtysik Oct 13 '14 at 11:08
  • \$\begingroup\$ If you use an XMLHTTPRequest from JavaScript on the client with the async parameter set, then yeah. The player's UI won't block and the request will happen in the background. \$\endgroup\$ – Anko Oct 13 '14 at 11:13
  • \$\begingroup\$ I mean if those requests are asynchronous on the server side, not on the client side :) \$\endgroup\$ – Andrzej Sołtysik Oct 13 '14 at 11:24
  • 1
    \$\begingroup\$ Depends on the game and how much load you're planning to put on your server. If you're more comfortable with a server that doesn't support asynchronous requests, build a prototype with that and see how it performs under your workload. It's really the only way to know. \$\endgroup\$ – Anko Oct 13 '14 at 12:28
1
\$\begingroup\$

Pre-rant answer:

There are only two technical reasons to require asynchronous requests, and neither of them applies to a game like Travian because real-time updates are not required.

  1. You need to make instant updates to the client, so you need to initiate communication from the server. Before websockets, this could be accomplished with long-polling (keeping a request open long after it was initiated), and submitting additional response content as soon as it became available.
  2. You need to answer or receive requests that take a long time because of total size and bandwidth, but still need to accept and work on new requests during that time.

These reason don't apply to Travian-likes because:

  1. You don't need instant updates. Timed resources can tick continuously on the client-side, but the server always should validate them based on previous_value + rate * elapsed_time. That update can happen whenever a user refreshes their page or attempts an action; no real-time push is required. Even if you need regular updates, they can occur through a simple polling mechanism (without keeping connections open).
  2. Your requests should not (and can not) be that large. This requirement would cripple any game server with a large number of users. Even Youtube delivers video via so-called "pseudo-streaming", delivering only the bit of content you need when you need it, which can be accomplished with separate requests to the server.

If you believe you can get away with RESTful or any other stateless communication (and indeed you can), then you do not require an asynchronous server architecture. You should select a server based on its ability to process the game state quickly, and possibly the ease of increasing that capacity on-demand. Concurrent connection count is mostly irrelevant.


It sounds like you are falling for the term "asynchronous" as a buzzword. I call it a buzzword because non-blocking requests have no benefit on a server that is busy doing work to answer the requests. Asynchronous requests only offer one "advantage", which is to allow the dog-piling of more incoming requests (that still take unacceptably long to receive a response). The single reason to require asychronous requests is if you expect your requests to take a long time to complete.

Asynchronous server systems increase the maximum number of concurrent connections. That is completely irrelevant if you prefer to use stateless (RESTful) requests. For example, the largest number of twitter posts per second, EVER, was about 6000. Will your game community need to make more requests per second than that? Some quick math will allow you to disprove that notion. Half that rate would be 260 million requests per day.

\$\endgroup\$
  • \$\begingroup\$ thanks for comprehensive answer, i found it hard to get any knowledge on this topic on google! :) \$\endgroup\$ – Andrzej Sołtysik Oct 15 '14 at 17:37
0
\$\begingroup\$
  1. Most browser-based games are going to use asynchronous communication. You might want to read what the difference between the two actually are. The biggest thing to note here is that typically synchronous communication will block until a response is received. Meaning if I fire off a request for high-score data from the same thread that does the rendering, my game will appear to freeze until I get the response. On the other hand, if I use an asynchronous model, then I can fire off the request, and handle the response if/when I ever get it.

  2. You are correct. WSGI is synchronous which means that each request must be processed in order before the next request can be processed. Typically this means that the calling thread is blocked until the request has finished processing, which for something that must stay responsive can be a huge deal.

  3. You can use either one, really the biggest difference here is personal preference and availability of one or the other in a preferred framework. Personally I've used both in varying projects, and found no significant difference in either one. Typically the biggest deciding factor here is finding technologies that play well together.

Also since you mentioned it, based off this data I would have to say that browser-based games are better off shying away from web sockets for now. It says that 20% of all people don't have browsers that support it. However in 5-10 years where the majority of browsers support it, websockets might be the thing to go to.

\$\endgroup\$
  • \$\begingroup\$ I don't know how you interpret that data, but I would say that when you don't target mobile devices, then you should be fine. And when you want the mobile market, you can just create a html5 app with the networking reimplemented using the native API. \$\endgroup\$ – Philipp Oct 13 '14 at 11:18
  • \$\begingroup\$ that means I can't really use WSGI-based Python frameworks like Flask for game like Travian (>15k users per server is possible)? Only possible solution if I want to use Python is Tornado or to learn something like node.js then? \$\endgroup\$ – Andrzej Sołtysik Oct 13 '14 at 11:25
  • \$\begingroup\$ TBH I've never tried. Synchronous isn't inherently bad, it just means that you've got some unique challenges. I believe WSGI is synchronous in the sense that once you start processing a response, you can't process another until the entire response is sent off. If the responses are short or don't rely on something slow like another network request or a disk request, you can still achieve good results. Testing would be preferred in this situation. \$\endgroup\$ – Thebluefish Oct 13 '14 at 14:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.