Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jun 2003
Offline Last Active Yesterday, 11:21 PM

#5202714 creating basic lobby services

Posted by hplus0603 on 07 January 2015 - 06:37 PM

That would probably work just fine for may cases, especially when player joining/leaving is not frequent, and games have long life times -- chess, or whatever.

When I wrote a version of this, I put both "currently available games" and "players seeking games" in RAM only. This was more for a FPS-like experience, where games may be shorter, and player are at least semi-often looking for new matches.

A server that is currently accepting users would send an update with current game state (name/mode/current-players/open-slots/whatever) every 5 seconds or so. When the lobby server hasn't heard from a game hosting server for 12 seconds, it would drop that game from its list of available-to-match games.

Meanwhile, a player looking for games would send match parameters, and be sent back a list of games, typically once every 5 seconds as well. If you expect for there to be 100s of matched games in the response, you'll want to manage this with some kind of consistent sorting and pagination.

The only persistent data I'd store in a DB for a game matchmaker would be the user name and password hashes, to verify the user accounts (and perhaps something like a game purchase serial number or whatever.)

#5202710 best data connection structure for a mmo game

Posted by hplus0603 on 07 January 2015 - 06:20 PM

MMO design is a very intricate collaboration between available technology, art, story, and community assets.
Is it 2D/2.5D/3D?
How much is the focus on skill/die-roll versus action/fps gameplay elements?
How much simulated physics do you need for players? For environment?
How many players do you need to support in a single "area" (whatever that means in your game)?
What happens when more players want to go to the same area than are supported?
What level of lag are you prepared to accept for the player? For group members? For players that are just around? For NPCs? For the NPCs the player is currently fighting?
Is there PvP?
Is there player construction, or other environment modifications?
Will you need a single global world where anyone can meet anyone, or can players choose world instances ("servers" in WoW, EQ, etc)?
How much revenue do you intend to make per player per month? (This dictates what kind of resources you can put into it.)

If you are a small indie group with one or two programmers and three or four artists, you probably want to start somewhere simple, like with the "PyMMO" example, and grow from there as needed: http://www.enchantedage.com/pymmo

#5202290 creating basic lobby services

Posted by hplus0603 on 06 January 2015 - 11:23 AM

I have never used a database for such high volume data before,

If I were to build it, I would store data that is going to be stale within an hour in RAM, and data that needs to be more persistent than that in a database.
I would also design my protocols to avoid changing persistent data frequently :-) Or, to put another way, any data that changes frequently, should be in RAM, and/or supplied on demand by the client.

#5201977 Average user packets per second

Posted by hplus0603 on 05 January 2015 - 10:38 AM

need to find out how many packets per second the average user can process

The number of packets per second is a reasonably meaningless value for most situations (perhaps except for certain mobile situations.)
The reason is that any client computer and client link is likely to be able to process many thousands of empty packets per second.
The real questions are:
- what's in those packets?
- how much is in those packets?
- what are the characteristics of the link between the sender and the receiver?
You have control of #1 and #2, but unfortunately not #3, which means that you have to assume some minimum, and when a client can't fulfill the minimum, detect it and disconnect (giving a clear error message about what the problem is.)

#5201600 Can you hack together the network coding of an MMO?

Posted by hplus0603 on 03 January 2015 - 02:29 PM

these will cost you users

If you have a slow influx of users that you can test with (say, by paying $50/month for Google ads or whatever,) then that may be acceptable.
Once you find that some users actually like the game, you figure out how to reach more of those kinds of users, and turn up the efforts.
It's very hard to predict what will be important, and how close you are to "good enough," without actually measuring on real users.

#5201043 Can you hack together the network coding of an MMO?

Posted by hplus0603 on 31 December 2014 - 01:05 PM

Yes, you can: http://www.enchantedage.com/pymmo
Is it a good idea? Depends on your actual needs and the amount of money at stake.

#5201042 Dealing with the latency and chattiness of REST

Posted by hplus0603 on 31 December 2014 - 12:58 PM

HTTPS is just HTTP with encryption.

Agreed! Thus, it solves the "encryption" part.

You still end up with like 100-300 bytes of headers in ASCII text that mostly serve no purpose.

I can't think of a single header that's not used by our web stack. Except the Accept: header sent by Internet Explorer when you have Microsoft Office installed -- that's insanely obese.
With HTTP2, you will likely be able to not repeat headers that haven't changed.

You can send binary data in HTTP content but you have to either base64 encode it or use MIME.

If you say something like that in a public forum as if it were fact, it's usually a good idea to verify with the specification first. That makes you look better when you catch yourself from saying falsehoods.

How do you think Flash movies, or JPG images, or application/octet-stream data, is served by a HTTP server?

#5200723 Dealing with the latency and chattiness of REST

Posted by hplus0603 on 29 December 2014 - 09:46 PM

Seriously we are long overdue for a binary http-like protocol with encryption and compression built in. Nobody actually uses a terminal to access web servers anymore.

HTTPS fulfills all of that.

HTTPS is encrypted.
HTTPS supports gzip (and other) encodings.
HTTPS supports binary payloads (if you want.)

And, with HTTP2, we may start getting the ability to support multiple separate streams on top of the same connection (for out-of-order, prioritized, and overlapped requests.) SPDY showed the way, and once HTTP2 is finalized, browsers and servers will swap out SPDY to HTTP2.

#5200280 Dealing with the latency and chattiness of REST

Posted by hplus0603 on 27 December 2014 - 11:58 AM

Writing responsive web pages (games, and other interactive experiences) should be easy.
Anyone who has tried to do this, realizes that it's actually hard, because each layer in the stack gets in your way.
At work, we've built out all the different library support and back-end infrastructure needed to make really responsive web services, working around various caching and scalability problems.


What the article doesn't say is that we also use the underlying message queue for non-HTTP data, for various games and experiences. But the article was already long enough :-)

#5199175 Is it possible to use Dart lang for Apach server?

Posted by hplus0603 on 19 December 2014 - 04:14 PM

In the release article, there is this disclaimer:

Note: I wouldn't put this on a public host for now, there are probably bugs!

Also, the last commit was 2 years ago, so I don't think it's actively maintained.

That being said, if you clone it and build it and install it for your Apache host, you can likely use Dart in Apache:


If you go the other how to access PHP code from dart client, how to implement it?

Easiest is to decide on an intermediate representation, such as XML or JSON.
Then write POST handlers in PHP, and POST to your Apache/PHP server from your Dart client.

#5199114 Is it possible to use Dart lang for Apach server?

Posted by hplus0603 on 19 December 2014 - 10:25 AM

Yes, you can use Dart language server-side within Apache, with the (unsupported) mod_dart plug-in:


#5198221 best way to send an receive multivarible data by socket

Posted by hplus0603 on 14 December 2014 - 07:18 PM

you just can set some varibales into an string

Several suggestions above indicated why this is a bad idea. For example, string manipulation in C# generate lots of garbage, and the string encoded values will use more bandwidth (as they are longer than equivalent binary encoded values.)

#5198162 extreme NAT punchthrough, UDP over DNS :p

Posted by hplus0603 on 14 December 2014 - 12:41 PM

Points for creativity :-)

Here are some challenges you'd have to overcome:

1) DNS is heavily cached. The time-to-live for various DNS entities is measured in hours, not milliseconds.
2) Many ISPs actually intercept DNS and resolve it themselves, rather than forwarding to an external DNS server. For example, Comcast does this, to send you to their own ad-filled "search help" page if you mis-type a domain name.
3) Most pay-for hotspots that I know about hijack both DNS and HTTP/HTTPS to bring up a "please pay now" paywall for whatever the first request is that your browser makes.
4) Some ISPs with strong "intrusion detection" systems (to clamp down on botnets and whatnot) may detect your unusual traffic as malicious.

Good luck, and please let us know how it goes :-)

#5198042 best way to send an receive multivarible data by socket

Posted by hplus0603 on 13 December 2014 - 04:00 PM

Check out the BinaryWriter and BinaryReader classes.

Note, though, that the TCP stream will not tell you where one packet ends and another starts. Thus, you need to prefix each packet with a length in itself.
Thus, you typically generate a packet by writing data using a BinaryWriter to a MemoryStream, then get the length, and write length (as a two byte ushort, typically) and the actual data from the MemoryStream. When receiving, you do the reverse: wait until there's at least two bytes read the length, then read that many bytes, stuff it into a MemoryStream, and use a BinaryReader to read the data back out.

#5197715 TCP clients-servers-servers

Posted by hplus0603 on 11 December 2014 - 08:51 PM

Generally, for each user, there is some management state. Every so often (server tick rate) the game examines the world state, examines what it's told that specific user about, and figures out what to tell the user next. It then makes up a packet of messages, and sends that packet on the socket. Repeat for all users, for all time steps, forever.

If the server has X connected users, and Y steps per second, and Z cores, the max amount of CPU time it can spend on a user is Z/(X*Y) seconds, or it will start to fall behind. Some games can get away with very low values of Y -- 1 or 2, say.

The "world state" for each user could include a queue of messages. A broadcast would then mean creating the broadcast message, and linking it into the outgoing queue of each user. (Ref counting may help save memory here.) However, if a particular player logs in even one simulation step after the world broadcast is sent, that user will not see the broadcast. Thus, it's much better to sync state (and control information) than it is to sync events, for most cases. (Events can still be useful for some things.)