Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Apr 2013
Offline Last Active May 30 2016 01:38 PM

Posts I've Made

In Topic: MMORPG networking Solutions

10 June 2015 - 12:05 PM

It's been a while since I've mentioned it, but it's come a long ways and I just released a new version.


Game Machine.


Game machine is an open source server platform that excels at large virtual worlds with lots of players in the same area.  It's focus is on solving a core set of hard problems not just networking.  It has built in persistence that scales well.  The best space optimization of any platform I'm aware of, and a well defined structure for writing game logic that runs concurrently.  Plus a bunch of built in functionality such as multiple characters, groups/chat, area of interest, etc..


The default client is for Unity.  Biggest market it's where I put my focus for all the client side implementation.  But it's fairly simple to integrate with the server as the core protocol is protocol buffers, and I moved stuff like reliable messaging to a higher level of abstraction.  So the networking layer is very dumb (as it should be IMO).


I wrote a completely functional open world mass pvp combat mmo in under 3 months using it, it was an eat your own dogfood project.  And all of the server side code for that is also open source and comes with.  So there are a ton of examples for how to solve most of the things you might tackle in an mmo.  

In Topic: Game content source repository?

16 April 2015 - 04:00 PM

Github is coming out with large file support, and there is a commercial git based platform that supports large files, can't remember the name.  It's based on git-annex.   So the future is looking brighter.


Even though perforce handles binary/large files really well, I just can't give up github workflow for code.  So I've been using amazon S3 for large binary files.  Managing versions gets tricky when working in teams.  Let me rephrase, it outright sucks.  But it's been manageable.

In Topic: Why is scaling an mmo so difficult?

04 March 2015 - 02:57 PM

Mmo's are kind of just the perfect storm of hard software problems.  Generally the ones you have to deal with in an mmo fall into the following areas.



- Concurrency.   Understanding how basic threading and mutexes work gets you maybe 5% of the way to where you need to be in order to do concurrency well.  Go read up on fork/join and the lmax disruptor for starters.  Read up on lock free algorithms.  That's the kind of stuff you need to know something about to do this well.


- Persistence.  Games are typically 50/50 read write when it comes to the database.  Most software is read heavy, most databases are optimized for read heavy apps.  You need to know stuff like implementing write behind caches and various other caching mechanism's to handle this problem and do it with consistent low latency.


- Networking.  This is the thing most people associate with game servers, and it's also by far the simplest problem to solve, as it's mostly already solved.  Not really worth going into.


- Scalability.  Games are stateful.  Global state synchronization doesn't scale.  Problem!  It's kind of why you don't use transactions for everything in your database and only use them when needed, because the cost for synchronizing state at scale is huge.  There are known solutions to this, it's a solved problem but more difficult to find information on.  Also ties directly into concurrency.


As far as cloud services it just depends on the type of game, and the type of cloud.  Realtime multiplayer games eat up a ton of bandwidth,more then you would think.  Most cloud services are priced for web stuff and that pricing just doesn't work for realtime multiplayer stuff.   You need to get down around $0.02 per GB before it starts to make sense.


Most cloud providers also overprovision.  If you run your own vm's then virtualization can work great, but you won't get consistent performance out of most cloud virtualization.  


Overall the cloud is overrated, especially if you have your own dev ops team.  When you do the math on buying the hardware yourself and either colocating or even just outsourcing the management of your hardware, the cloud starts to look really expensive.  Contrary to what Amazon and others want you to think, they have huge margins on this stuff.  They count on the fact that cloud hosting is just taken for granted and people not actually doing the math.


The sweet spot I found that we used on almost a dozen games, was to use a company like softlayer that could provision real hardware to our specs and manage the network/hardware level admin.  And our small dev ops team managed provisioning and stuff like that.  It was cost effective and we kept good performance.


FYI the current trend is for more companies to use hybrids and more real hardware.  People are tired of cloud providers overprovisioning, and starting to actually do the math and see how consistently they are just flat getting ripped off.  There is a reason why cloud providers don't tell you how many vm's they run per core. 

In Topic: Pathfinding in a 3D RTS or MOBA

02 August 2014 - 11:16 PM

raycasting can't give you paths for things it can't see, so it's really limited to being useful for local avoidance.   You are going to need a combination of pathfinding and steering to make a moba/rts game.


There are actually surprisingly few good open source pathfinding libraries, and TONS of crap written by people learning how to write pathfinding code.  My suggestion would be to just go with recastnavigation.   It's pathfinding is great.  The only part that's a bit dated is the crowd stuff.  It works but it's cpu intensive.  You can use it for a moba game, but for an RTS game with a lot of objects, it won't work as it just uses too much cpu.


My preference would actually be to just use an engine like Unity or UDK that already has what you need built in.  Even though their pathfinding is loosely based on recast, they provide crowd implementations that are far more performant and can handle much larger crowds.

In Topic: MMOs and modern scaling techniques

11 June 2014 - 06:09 PM


If a client wants to send 10 gold to someone and sends a request to do that, the client has no way of knowing if the request was processed correctly without an ack. But the ack can be lost, so the situation where you might have to resend the same request is present in all networked applications.


I think we're crossing wires a bit here. Reliable messaging is a trivial problem to solve (TCP, or a layer over UDP), and thus it is easy to know that either (a) the request was processed correctly, or will be at some time in the very near future, or (b) the other process has terminated, and thus all bets are off. It's not clear why you need application-level re-transmission. But even that's assuming a multiple-server approach - in a single game server approach, this issue never arises at all - there is a variable in memory that contains the current quantity of gold and you just increment that variable with a 100% success rate. Multiple objects? No problem - just modify each of them before your routine is done.


What you're saying, is that you willingly forgo those simple guarantees in order to pursue a different approach, one which scales to higher throughput better. That's fine, but these are new problems, unique to that way of working, not intrinsic to the 'business logic' at all. With 2 objects co-located in one process you get atomicity, consistency, and isolation for free, and delegate durability to your DB as a high-latency background task.



So this is an interesting topic actually.  The trend is to move reliability back up to the layer that defined the need in the first place, instead of relying on a subsystem to provide it.  


Just because the network layer guarantees the packets arrive doesn't mean they get delivered to the business logic correctly, or processed correctly.   If you think 'reliable' udp or tpc makes your system reliable, you are lying to yourself.