Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jun 2003
Online Last Active Today, 09:56 AM

#5294050 Server difference regarding input

Posted by hplus0603 on Today, 09:53 AM

Because the data is already old, does it mean that server-side game loop needs to always read/process the packets from the past based on some maximum tick it allows players to be behind?

sYou have three options:

1) Play it as soon as possible on the server. This is simple, but introduces game play artifacts because of jitter. It also will let the simulation on the client diverge from the server, so continual corrections are needed.

2) Rewind the server simulation and apply the command, with some maximum allowed amount of rewind (to avoid too much cheating.) This is the "Source" / "Counter-Strike" model. This reduces lag when players are not interacting, but causes corrections when players interfere with each other.

3) Make the client schedule the event for the future -- the client actually says "play this on step 12" when sending the command. Similarly, the client then also locally delays the command until that time step. This lets you do 100% deterministic lock-step simulation, but introduces a client-side command lag.

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

Posted by hplus0603 on Yesterday, 08:28 PM

I would love to see you succeed in that vision, I really do!

#5293979 Server difference regarding input

Posted by hplus0603 on Yesterday, 04:59 PM

Do you need to mark the packets with step numbers even if you are using TCP..?

In general, yes, you'll want to do that.

If you don't, then you have to delay everybody's game if one client's stream gets delayed.
And TCP stream delays are worse than UDP delays, because even if the next packet makes it, the TCP stack will wait for the re-transmit of the previous packet before giving you any more data.

#5293942 How would you scale single-threaded server?

Posted by hplus0603 on Yesterday, 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 27 May 2016 - 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.