Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jun 2003
Offline Last Active Today, 11:10 AM

#5293942 How would you scale single-threaded server?

Posted by hplus0603 on Today, 10:54 AM

Take a look at how irc networks work.

I agree that it's an interesting systems design example, and looking at how it grew from the first implementation in the 80s is another interesting case study.
But IRC is not a good architecture for games, for the same reason you said: latency is not a goal there.

It's worth looking into how others solved problems, even outside of the games industry

This is also a reasonable statement, but with some caveats. A lot of companies and individuals in other industries have over the years come in, and thought "we're the best in our industry at doing X, and games seem like they do a lot of X, so our solution will totally rule games!"
That seldom ends well. Doesn't matter if it's physical simulation, networking, visualization, stock trading, media serving, or whatever -- the evolutionary pressures in the game industry are very different from the evolutionary pressures in most other industries.

#5293829 Cloudhosting a C# Console Application utilizing UDP

Posted by hplus0603 on Yesterday, 11:29 AM

The hosting difference between TCP and UDP isn't that big.
The main question is whether the latency/jitter performance of the virtualized host is sufficient for your use case.
There are many cases where it will be just fine (especially if you "reserve" something that's a "full" computer.)

#5293711 How would you scale single-threaded server?

Posted by hplus0603 on 26 May 2016 - 08:53 PM

how would you scale single-threaded server?

You run one process per core on the hosting server, and send different users to different processes.
Typically, each process will listen on a different port, and you'll use some kind of registry/discovery to manage it all.

#5293703 MySQL server vs Microsoft sql server

Posted by hplus0603 on 26 May 2016 - 07:34 PM

Benchmarks for different databases are available online, and the throughput really depends on your specific workload.

That being said, if you can live with the schema constraints of SimpleDB, or BigTable, then you can scale order of magnitude larger than you can with a single-instance database.

#5293627 What is the top factor for MMO engines limiting world size?

Posted by hplus0603 on 26 May 2016 - 11:59 AM

Also: There exists companies that review and publish user-generated content already.
Including "virtual world" companies as well as aggregation platforms like Steam.
What, exactly, are you bringing that's new and will change the dynamics for these efforts?

#5293265 What is the top factor for MMO engines limiting world size?

Posted by hplus0603 on 24 May 2016 - 03:49 PM

Having deep experience with user generated content, I second the suggestion that Sturgeons Law applies.
If you want to build user-generated content, building a way to make good content naturally flow to the top of discovery is important!
And, the simple ways of doing that, tend to favor some very few who have the most main-stream offerings, leaving great content that caters to niches somewhat under-exposed.
This is a really, really, hard problem! (You see this on all online marketplaces, including things like Steam!)

Again, perhaps you have some breakthrough in organization or business model that will work around these known challenges, and if so, I encourage you to share! Dreams don't become reality unless you can clearly articulate them to others :-)

#5293263 What about Load Balancer

Posted by hplus0603 on 24 May 2016 - 03:43 PM

Your diagram doesn't make it clear how each client ends up talking to a particular server.
It also doesn't make it clear how each server will end up finding out about other servers/clients on those servers.
As far as I can tell, the design you suggest ends up with every server on average talking to every other server, which scales like N-squared.
For well implemented systems, and 500,000 connections, N can likely be very small, though, so it might work fine.

I think the bottleneck, in the system as you describe it, will be the "lookup if B is online, and if so which server B is on." That will probably not scale to 500,000 users with a single "master server" if the typical use case is that players talk to other players on other servers, unless connecting is rare and connections are persistent after establishment.
You'll probably want the ability to horizontally shard the "presence" bit (meaning "player B is on host Q.") You can likely build this by using a key/value store with ephemeral keys, like Memcached, Redis, or Zookeeper. (You'd have to investigate which of them best matches your particular use case.)

#5293221 What is the top factor for MMO engines limiting world size?

Posted by hplus0603 on 24 May 2016 - 09:48 AM

this isnt Second Life Plus Plus ... that thing is a shadow of a shadow of what I would envision this possibility

Second Life had almost exactly the vision that you lay out.

Could you try to analyze why they, with lots of smart people and funding, did not manage to actually make that reality?

(Having worked in this space for a long time, I have my own theories, but I'd like to hear your take as a fresh perspective!)

#5293088 What is the top factor for MMO engines limiting world size?

Posted by hplus0603 on 23 May 2016 - 12:08 PM

For farming, instead of hitting the same button over and over, let that character be a semi autonomous so you can have it doing stuff while your out adventuring or PVP'ing

A.K.A. "the plot device of the book REAMDE."

Just because you haven't seen it done yet doesn't mean it can't be done and not bankrupt the company.

Agreed! What it does mean, however, is that the "obvious" approaches don't actually work, and to make it work, you need to have something that the previous entrants did not, in addition to the surrounding prerequisites of funding, artists, marketing, etc.

#5292501 Understanding Peer 2 Peer

Posted by hplus0603 on 19 May 2016 - 09:36 AM

Someone could easily get the IP of someone their connected to.

This is a real risk of peer-to-peer games (or any other system) on the current Internet. Rage booting services are cheap, and people with an inflated sense of entitlement and common.

The game rule bits are relatively easy to solve. The authorization server could issue a token to each player; each player when connecting to another player would provide a signature of some challenge, and that other player would then verify the signature with the auth server. This avoids the "you're not supposed to be here" problem.
However, rules enforcement, and outside-the-game shenanigans like DoS-ing, aren't under your control anymore. If you use a fully lock-step system with no late joiners, like most RTS-es, then you can detect that <i>someone</i> in the game cheated, if there is a rule-breaking move, but you'll never be certain of who it was (voting rings are a thing.) And information leak cheats wouldn't even be visible on the network -- if I had a side screen that showed me all your units in an RTS at all times, I'd have a significant advantage!
If your game has any kind of persistent value (level progress, monster loot, mining resources, ...) then trying to keep that cheat-proof in a peer-to-peer system is a losing battle.

If you plan to make a real business out of your game, carefully consider these challenges! Servers are cheap, relatively speaking.

#5292500 What is the top factor for MMO engines limiting world size?

Posted by hplus0603 on 19 May 2016 - 09:27 AM

But combine them somewhat, add RPG and RTS features and it would work.

Every five years, someone tries that idea. It has it's niche, but it's not what most people are looking for.
Most people already have an eight-to-six where they put together widgets for the use and consumption of others; coming home to a virtual widget-making business just isn't that compelling.
Only a few "active worlds" have had staying power (and, ironically, Active Worlds wasn't one of them :-)
Eve Online is probably the biggest example; Entropia Universe is another, although the draw there seems to be mainly the lottery aspect.

The main problem is: Most people don't want to play the role of subservient to some other player in any but the most abstract sense.
Guild leader? Seems OK, the Guild adds enough social value to put up with it.

Front-line soldier in an RTS, going where other players tell you to?
Farmer, clicking the "plow field" button over and over again?
Policeman, dealing with griefers?
Not player enjoyment.

The theme park design has not grown up because game developers "lack imagination." Imagining is easy, relatively speaking. The "free worlds where I can do anything" games aren't being kept out of the market by a lack of enthusiastic developers wanting to make it happen. The reason the MMO game world looks like it does, is much more fundamental than that, and has to do with what most people are willing to pay for as a gaming experience. Building a lasting business requires a product/market fit, which is much harder!

#5292356 What is the top factor for MMO engines limiting world size?

Posted by hplus0603 on 18 May 2016 - 04:12 PM

To fill a large world with relevant content costs money

I concur. This trumps anything else.

#5292080 Browser strategy game server architecture (with pics)

Posted by hplus0603 on 17 May 2016 - 09:24 AM

Moral of the story: it would be nice if somebody creates a framework doing these kind of things ;-).

Some of these frameworks exist. Build your game on Amazon SimpleDB, SQS, Lambda, Elastic Beanstalk, and all the rest. You will be able to scale as much as you want!

The draw-back is that:
1) You have to learn how to properly use all these technologies, which takes a lot of time.
2) You have to pay the cost of this infrastructure, even during development.
3) Each feature you're trying out will have to be architected to fit within this system, which reduces development velocity.

Another option is to factor the system on your own servers, but just rune "two of each" all on a single box (or a couple of boxes.) Start hosting this box in your server closet; when you go to beta testing, buy into some co-location facility.
This method lets you scale costs a little better, but the draw-back is that you have to factor the services yourself. (This is also a benefit, because you can factor based on your games' needs, not based on whatever primitives Amazon happens to have built for their business.)

If you're a growing studio, with a separate back-end team, and sound business reasons to go into large multiplayer systems, then that totally makes sense!
If you're on your first real game, funding by living on Ramen, then that's probably not where you should spend your efforts.

Now, does it make sense to think at least a little bit about server-side structure and costs? Yes, absolutely! It's just that the right amount of thinking is, for 99.9% of games, probably less than this entire stack.

#5291865 Browser strategy game server architecture (with pics)

Posted by hplus0603 on 16 May 2016 - 10:15 AM

If we're speaking about serious volumes (over 10-100M DB transactions/day total), it is not that simple.

Agreed! At work, we have to deal with those volumes and more. Meanwhile, 99.999% of all games will not see those volumes, and I would not recommend that a game developer spends too much time worrying about horizontal sharding or read slaves when the real challenge is making a fun game and figuring out how the world will learn about how fun it is.

BLOBs as such are traditionally pretty bad for DBs

Right -- I used "blob" in the sense of "state checkpoint from the game," not necessarily implemented using the SQL BLOB construct. You should implement it however it best suits your storage.

1000 transactions/second is indeed achievable, though depending on DB experience and on the transactions themselves, it can be rather tough to do it

A desktop PC with a quad core CPU and a SATA SSD can do it.

That being said, if it's truly just "userid/gameinstance -> statecheckpoint" then a file on disk would be sufficient, and those can do ... many more :-)

So the question then becomes: Are you doing this just to design a "what if" for a very large game? Or are you actually trying to build a game of your own, and want to know where to start?
For the "what if" scenario, the assumptions about transaction rates and the design of the game play a very crucial role.
Regarding the "let's centralize login" question, the only thing that login does is issue a cryptographic token, valid for some time, identifying the player as a particular customer ID. The world state databases then just verify this token, without having to connect to the central database. Thus, the load on the login database is only as much as how often users need to log in.

#5291591 How can I optimize Linux server for lowest latency game server?

Posted by hplus0603 on 14 May 2016 - 12:52 PM

that it not the latency I am measuring

Then you're measuring a latency number that does not accurately reflect the game playing experience. That may lead you to optimize the wrong thing.

I don't think there is anything wrong with it.

Lots of games do fine at 20 Hz, or even less, so I agree. My main comment comes from the question of "what can I do to shave latency off the server?"
It seems to me that you have no data nor real reason to believe that that's the actual bottleneck for your experience, so the best answer is probably "nothing" until you receive data to tell you otherwise :-)