Hey everybody I’ve just published a new article in the networked physics series: Snapshot Compression.

Some folks out there think they can do better than the compression described in the article. Now I don’t doubt for one second that better compression approaches exist, but exactly how much better is your encoding than the one described in the article? Don’t just tell me your encoding is better. PROVE IT.

It’s time for a good old fashioned walk-off.

Here are the terms of the competition. Old school rules.

If you can beat my best encoding over this dataset by 10% I’ll link to your blog post describing your compression technique from within the article. Your blog post must fully describe your encoding and include source code in the public domain that proves the result. Compression must be lossless.

The data set to be compressed is position and orientation data (smallest 3) in integer format post-quantize with delta encoding baseline. Your job, if you choose to accept it, is to encode each frame snapshot into packets using the least number of bits.

When reporting your results please include the following: number of packets encoded, average packet size in bytes, average kbps across the entire data set. To calculate this add up the number of bytes for all of your packets (if you have encoded bits not bytes, please round up to the next byte per-packet as you can’t send fractional bytes over UDP). Divide the total bytes by the number of packets to get the average packet size in bytes. To calculate bytes per-second multiply average packet size by 60 (60 snapshots per-second). To convert bytes/sec to kbps multiply bytes per-second by 8 and divide by 1000 (*not* 1024!). My best result so far is below 256kbps.

IMPORTANT: You must encode and decode each frame individually into packets (eg. 901 cubes at a time). You may not encode the entire data set at once. You cannot assume that all packets will be received by the sender. You cannot assume that all packets will be received in-order. You may not rely on information inferred from previously encoded/decoded packets when decoding a packet unless you embed that information in the packet or can infer that information even in the presence of packet loss and out of order packets. You may not write any decompression scheme that relies on putting packets in a queue and processing them in-order as this delays realtime data delivery of snapshots and defeats the purpose. Encryption and decryption must be plausibly realtime. Static dictionaries trained on the data set are acceptable. You may not claim a win based on a dictionary trained on the same data set that is being compressed. Final results will be judged against an unreleased data set. If necessary, separate datasets for training and encoding will be provided for the final judging.

Data format is fixed records. 901 cubes per-frame. Frames 0..5 are duplicates of initial state. Start your encoding at frame 6 and encode frame n relative to frame n-6.

Each cube struct is as follows:

struct DeltaData
{
    int orientation_largest;
    int orientation_a;
    int orientation_b;
    int orientation_c;
    int position_x;
    int position_y;
    int position_z;
    int interacting;
};

Best of luck!

Hey everybody, I have great news! My GDC 2013 talk “Virtual Go” is now free to watch in the GDC Vault

Many thanks to Meggan Scavio for making this talk free for everybody to watch!

If you would like more detail on my project to simulate a go board and stones, there is an article series here, and some source code for this project available here on github.

I hope to return to this project one day so let me know if you are still interested in it. With the latest developments in Virtual Reality these days I think this project is as relevant as ever. Still massively niche of course, but how cool would it be to be able to play go with someone on the other side of the planet on a physically simulated go board inside Virtual Reality?

Hey everybody, my GDC 2015 talk is now free to view in the GDC vault!

Unfortunately the talk videos in the slides seem to have been recorded at 20fps

You can get the original slides (HD 60fps videos here). I might see if I can take the audio track from the GDC vault and splice that in with the original HD videos in the keynote.

There is also an article series covering this same material in more detail here:

http://gafferongames.com/networked-physics/introduction-to-networked-physics/

cheers

Chris Doran, co-author of Geometric Algebra for Physicists and founder/director of Geomerics has written an excellent blog post on the mathematics behind quaternion compression. His approach to quaternion compression provides significantly better compression than the delta smallest three approach described in my article.

Link: Quaternions, Rotations and Compression

Download as PDF

Last week I found this discussion on Reddit:

I’ve been trying to understand and implement networking in a game for the last few months, and every attempt I make at it has some kind of flaw; whether that’s unreliability or deadlocking. For context, the multiplayer in the game is multiple players (up to 4-8) in a single game, connecting to a server hosted either on LAN or on the internet.

At the moment I’ve just been using some sort of RPC layer over TCP in my game; you call a method, it remotes over to the server, does something and returns a value. This works for simple things, but it seems to completely break down when I need to keep large parts of the system in sync.

There are articles like http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/, which talk about distributed computing models, but other than the RPC model mentioned, they all seem non-trivally complex for the type of game that I’m developing and the benefits of extreme reliability are not particularly there for the type of multiplayer model either.

Then there are articles like http://gafferongames.com/networking-for-game-programmers/, which talk about using UDP instead of TCP, but then go on to implement 95% of TCP on top of UDP anyway. This seems kind of silly, given that the only advantage is to drop packets that are old (and surely this can be reasonably emulated by not sending newer updates until receiving confirmation from the client that it’s received the last one?)

Am I overthinking all of this? Is there a way to actually do multiplayer games without an enormous upfront cost in complexity, both in terms of modelling the game and the resulting code?

No you’re not overthinking it. Networking a game is actually really hard.

RANT MODE ON

It always astonishes me when folks don’t understand why using UDP is so important for networking games. It’s 2015 and there are plenty of good articles out there explaining why time critical data shouldn’t go over TCP. We have the Tribes Networking Model, The Unreal Networking Model, Valve Latency Compensation article. You have whole industries (gaming, video streaming, VoIP) that will laugh at you if you send time critical data over TCP and rightly so. And yet, here we are in 2015 and there are still a bunch of people out there who just don’t fucking get it.

I’m not sure what got you onto the RPC request/response thing over TCP but that is completely the wrong direction for what you want to do. It might make sense in some distributed systems (possibly) but that’s not how people ship most games these days. What most low player count realtime networked games actually look like is a constant stream of packets in both directions: client to server and server to client. These packets are usually sent all the time, not in some sort of request/response pattern, basically forming a carrier wave for the tiny subset of data that actually needs to be reliable. These packets are often sent at some fixed rate like 10 or 20 packets per-second, or even up to 60 packets-per second in some cases

Most games are discrete time simulating systems. They start at frame n and step forward in time to frame n+1, n+2 and so on. Player input sampled at a particular time once per-frame (mouse, keyboard, joystick whatever) and this input evolves the system forward: state(n) + input(n) = state(n+1). So when you’re networking a game what your sending across some data like: here is the player’s input at time t, here is the state of an object at time t. Now this is really important. You don’t give two fucks about a players input at time(t) when you are at time t+0.5 seconds. The time t has passed! Who cares about an old input or state? The data you are sending across is time critical.

Not only do you want it to get across as quickly as possible. You also want it to arrive on the other side as evenly spaced as possible because you have to show this data to the user or process it at a specific time. It’s like a video playback. Nobody cares about frame 100 of the video if the video is already gone past that bit and you’re up to frame 110. Nobody wants to see a jittering playback with hitches and gaps in it. In fact games are even harder than video playback because we have to minimize latency as well as handle packet loss and jitter. We can’t just buffer up 30 seconds of video to hide any network bullshit. We actually have to handle those network conditions with custom networking strategies (redundantly sending unacked time critical data with smart delta encoding tricks is the way it’s usually done).

So when I see people in 2015 asking a question like this:

Then there are articles like http://gafferongames.com/networking-for-game-programmers/, which talk about using UDP instead of TCP, but then go on to implement 95% of TCP on top of UDP anyway. This seems kind of silly, given that the only advantage is to drop packets that are old (and surely this can be reasonably emulated by not sending newer updates until receiving confirmation from the client that it’s received the last one?)

I can only conclude that you failed to understand my article, don’t know how TCP works, or both. I wrote that article in 2008 after I’d shipped two AAA multiplayer games. I’ve shipped 4 since. The techniques described in that article are still relevant and are still exactly how I’d approach that same problem today.

You seem to think that my article is describing some sort of TCP like scheme? Guess what. TCP doesn’t work in any way like the system described in my article! TCP is an abstraction on top of IP that makes everything look like a reliable/ordered stream. This means that everything arrives reliably and in-order. If a TCP segment (packet) is dropped, you have to wait for that segment to be retransmitted before you can receive any later data. This alone makes TCP completely unsuitable for time critical data.

What my article actually describes is a simple system where you use a sequence number, ack and ack bitfield to work out which packets were actually received by the other side. With this information you can do anything you want. You could ignore it for the bulk of your packet data (it’s typical in most game protocols that the bulk of the data is unreliable). You could take the subset of your packet that is reliable-ordered and resend those bits in a later packet until one of those carrier packets are acked. Take a look at the Tribes Network Model for some other ideas.

Another thing I really take offense at in 2015, is stupid shit like this:

Yeah… Gaffer is well-known as a guide, but also kind of horribly flawed. Question 1 for networking development:
Do you need everything that TCP offers?
If yes, then use TCP. You’re not going to outperform TCP to do what it’s good at.
If not, read on.

This idea that nobody could possibly do reliability better than TCP. Because people really should know better by now. You can’t even imagine a way that reliability could be implemented on top of UDP that beats TCP? What total bullshit. I can think of two ways right off the top of my head to implement reliability over UDP that totally kicks TCP in the nuts:

1. Rendundantly sending all unacked inputs, delta compressed from client -> server
2. Snapshot delta compression where a snapshot is implicitly encoded relative to the last acked snapshot received by the client

That’s why it’s so frustrating to see this sort of shit out there, in 2015 when people should bloody well know better. I swear you guys are like the fucking climate change deniers of network programming. What the fuck is wrong with you? Is the idea of head of line blocking hard to understand for some reason? Do you lack the imagination or creativity to see that things can be done better? Do you not understand that TCP delays the data you want to access unnecessarily until old stale shit you don’t ever care about is retransmitted? Is implementing reliability over UDP too hard for some reason? There are perfectly good libraries out there that will do this for you!

My advice to the original poster. Create a simple protocol that sends player inputs to the server 30 times per-second. Send this data over UDP and in the server -> client packets include an ack of the last sequence number received from the client. Add some reliability by sending all unacked inputs in each input packet, and delta encode the inputs in those packets relative to each other to reduce bandwidth. You should probably also write a bitpacker at this point as well.

Apply those inputs raw off the network on the server side and focus on sending world state back from server to client. Initially, send it uncompressed and buffer these time series of packets on the client for display and interpolate between them to render on the client. Once you have this working start looking into delta encoding, eg. encoding your world state relative to the last acked state received by the client.

Once you do this, you’re ready to start thinking about hiding latency.

It was good enough for Carmack. It’s good enough for you.

Welcome to the 10,000 hour journey

When Titanfall was in development my colleage Jon Shiring made a bold decision: Titanfall would be entirely hosted on dedicated servers. At the time this was revolutionary. No console FPS at this scale had ever considered hosting all games on dedicated servers, instead hosting all or most games on player hosted servers (player’s PCs and consoles!) leading to rampant cheating, lag switch exploits, NAT issues, slow matchmaing and host migration all being part of the standard user experience.

Of course Titanfall went on to launch successfully and the rest is history. I was lucky enough to spend the last 6 months on the project helping to push it across the finish line. During this time I got to spend a lot of time working with Jon understanding his rationale behind the switch to dedicated servers.

Now you too can follow Jon’s reasons for going fully dedicated and perhaps for your next game you should consider this option instead of going peer-to-peer or player hosted servers. As you will see the benefits of going fully dedicated are massive and worth the cost.

Hey everybody, Glenn Fiedler here. I’m the author of gafferongames.com

I have an important announcement. I’ve started up my own company!

The Network Protocol Company, Inc.
www.thenetworkprotocolcompany.com

The goal of my company is to help people network their games. You may wonder, but Glenn, why did you leave Respawn? Respawn is a really cool company. Titanfall is a really cool game. I agree 100%. Respawn is great! I loved working at AAA studios but I’ve been doing that for almost 20 years now. Truth is that people ask me for help with networking all the time and when you are employed at a studio you have an employment contract and you are limited to only help the one studio you are working at. This is frustrating! So while I really enjoyed working at Respawn I wanted to do something more. I want to help LOTS of people not just a few.

It also seems to me like quite a good business opportunity. Lots of people need help with networking, I know because they ask me all the time, but very few people are available to do it. Most experts in this field are locked away working for salary at large companies and simply can’t engage with different teams. You’ll notice as well that very few people write about game networking let alone provide quality example source code showing how it’s done. It seems like there is a really big hole in game networking knowledge and I have a great opportunity to fill it.

Now that I have my own company I can do whatever I want.

So what sort of stuff will my new company do?

All the work I love to do such as expert consulting, mentoring teams, writing game networking articles on gafferongames.com, original research in game networking and VR, talking at GDC, developing open source game networking software, creating example source code to demonstrate networking concepts and so on.

And as of today, the first order of business at my company is that I’m starting work on a new article series.

Building a Game Network Protocol

This new article series is going to be awesome. Starting today I’m going to build up a professional grade game network protocol (hence the name of my company) completely from scratch. Follow this article series and you’ll see exactly how it’s done. You’ll learn so much reading this series. 15 years of game networking experience distilled and all example source code will be open source, you can use it however you like, even in your own commercial projects!

Once I’m finished with this series, I’m going to start researching game networking and VR. Thank you so much to Valve and Oculus for providing me with hardware to do this. I’ll be continuing my popular Networked Physics article series and fleshing out the second half of that series with full implementations for lots of different networking models. All with full source code. If you have a game in VR and you are wondering how to network physics then this is the article series for you.

The best way to support my work is via patreon: http://www.patreon.com/gafferongames

I appreciate that not everybody needs or can afford $250 an hour expert consulting on-site. So let me briefly make my pitch for patreon support. If you need some help on game networking, one of the most cost effective ways you can get it is to support me on patreon and encourage me to write about topics that interest you. The more support I get on patreon, the more time I can spend writing articles and open source software to help you. Also, if you have found that in the past articles on gafferongames.com have helped you with your projects or you’ve just even enjoyed reading the articles, now is the time that I really need your support. Please support generously!

Help me live my dream. I want to write articles and develop open source software for gafferongames.com full-time

Please support me here: http://www.patreon.com/gafferongames

Hey everybody, I’ve just started up a new article series: Building a Game Network Protocol.

In this article series I’m going to do exactly that: build up a modern, professional grade network protocol over UDP for action games (eg. FPS, melee combat, realtime MOBA) using nothing but my Macbook Pro, Sublime Text 3, my trusty C++ compiler and a couple of UDP sockets.

My goal for this article series is to share game networking knowledge I’ve learned professionally in the field over the past 10 years because nobody else seems to be writing about this stuff. What’s up with that other network programmers out there. If you enjoy reading this series, please support my work so I can write more articles for you. As well as supporting my work you also get access to example source code for this article series (which is open source, so you can use it for anything you want, even commercial works!) and a password that gives you access to draft articles on this website before they’re published.

Also, as for the image shared with this post, that’s from the linotype machine and typesetting of the New York Times before they switched from hot press (actual molten lead cast molds of type!) to a computerized printing system. For details of the old printing process check out this fantastic video:

Publishing in 2016 is so much easier. Thank you so much for supporting my writing!

This is awesome stuff. Gaffer on Games approved ™. Worth a watch!

A lot of people are complaining online about cheating in The Division lately, especially on PC. So much so that it’s starting to hit mainstream media.

But how bad are these hacks, and more importantly, can they be fixed?

I don’t own a copy of The Division so I watched a few videos and dug around to see what’s going on. As a game networking expert (I’ve shipped a few titles) I can usually look at exploit videos and see what’s going on fairly quickly.

The first videos I saw were the usual overly smug glitchers out there, super proud to have discovered things the QA department should have probably picked up when testing the game:

Not a great thing to see in a shipped game, but also not the end of the world. These glitches can be fixed.

But then, I saw this video:

And this is super bad news 🙁

Because here we have a client-side cheat program that is poking memory locations and giving players infinite health, infinite ammo, and teleporting players around the level.

This indicates that The Division is most likely using a trusted client network model.

I sincerely hope this is not the case, because if it is true, my opinion of can this be fixed is basically no. Not on PC. Not without a complete rewrite. Possibly on consoles provided they fix all lag switch timing exploits and disable players moving and shooting while lag switch usage is detected (trusted client on console exclusive games is actually more common than you would think…), but not on PC unless they completely rewrite most of their netcode and game code around a server-authoritative network model.

When I present such a bleak outlook people often people ask: why can’t they just implement more server-side checks? In fact the developers prior to release seemed to say something along the lines of: Oh, don’t worry. We haven’t implemented server side checks yet. Everything will be fine. Don’t worry. We’ve got this! Hmm. <network spider senses tingling>

To me this displays a fundamental misunderstanding of how FPS games are networked. It’s actually a fairly common misunderstanding so I’m going to spend some time in this post debunking this myth.

Top-tier competitive FPS games don’t work by having clients send a bunch of actions to the server for validation such as: I moved over here <position>, I reloaded my weapon, I fired my gun, I hit this guy and did X damage. The server does not sit there and run checks over the stream of actions sent to them by each client, validating each action, checking to make sure each action is safe, magically detecting cheaters and banning them from the game.

What top-tier competitive FPS games actually do is actually quite different…

For a competitive first person shooter there is a pretty standard approach to networking pioneered by Quake and later on perfected by Counterstrike. This is the same network model used today by top tier FPS games like Call of Duty, Overwatch and Titanfall.

This networking model has two main features you’ve probably heard of:

• Client side prediction so players don’t feel lag on their own actions (movement, shooting etc…)
• Lag compensation so when you shoot another player and bullets hit on your machine, you generally get credit for that hit as you saw it (so you don’t have to lead the target according to lag). But, critically, this decision of bullets hitting other players is decided on the server, not on the client.

Behind all of this, the key idea behind this network model is that the server is THE REAL GAME. What happens on the server is all that counts and the server never trusts what the client says they’re doing:

• The server does not trust where the client says they are (position)
• The server does not trust when the client says they fire a bullet or when the client says they hit another player with that bullet.
• The server does not trust the fire rate of the weapon or the ammo count on the client.
• The server does not trust what the client says they have in their inventory, and especially not the weapon the client says is in their hands…

What happens instead is that the server takes the inputs from the client and runs those player inputs in THE REAL GAME (on the server). What happens as a result of those inputs on the server is what really happens and is seen and experienced by other players in the game. Not because those actions were sent from the client to the server and magically validated, but because those actions are what actually happened on the server in response to the player’s inputs.

For example, if the input sent from a player is that they are holding down the fire button, then the server runs the same player code on those inputs (fire button pressed) which results in bullets being fired on the server according to the the current weapon the player is holding, the fire rate of the weapon, the amount of ammo in that weapon, and so on.

And those bullets emitted on the server are the ones that actually hit and do damage to other players.

In the standard FPS network model, what the client sees if they hack their client is just a ghost…

• If they increase ammo counts or fire rate of their weapon, it doesn’t matter because they are just firing ghost bullets on the client that don’t actually do any damage.
• If they hack their inventory and give themselves a weapon they don’t really have, it doesn’t matter because the bullets that actually do damage are fired on the server out of the weapon that the server thinks they have.
• If they poke memory to warp around it doesn’t matter because bullets are fired from the server position not the hacked client position, and bullets fired by other players hit or miss them based on their server position.

If a competitive FPS was networked the other way, with client trusted positions, client side evaluation of bullet hits and “I shot you” events sent from client to server, it’s really difficult for me to see how this could ever be made completely secure on PC.

I’m rooting for the dev team on this one and I sincerely hope really they can turn it around.

I hope they’re not using a trusted client networking model. I hope they have something up their sleeves. I hope they have a valid networking approach based around server-side checks that can address this issue in some way…

But unfortunately, so far, all signs point to no 🙁

Just a few days left… click here to support this book on Kickstarter!

Hey everybody, thanks to your support on patreon I’m one third of the way through writing my new article series: Building a Game Network Protocol.

My goal for this article series is to show how to build up a professional grade game network protocol using nothing but C++ and some UDP sockets. If you’re a game programmer and you want to get into multiplayer programming, if you are wondering how game network protocols work, how packets are serialized over the network, how reliable messages are sent over unreliable UDP, or even how a client/server connection is established, then this is the article series for you.

In addition to articles in this series I also make all the example source code for the articles, a full implementation of the game protocol available for patreon supporters under BSD 3.0 licence, so they can adapt and use it in their own projects, even commercial ones. So not only do you get excellent quality reference code for each article, you also know I’m writing about something I’ve actually implemented. As such, you will find that each of my articles are incredibly detailed with practical implementation details for building a game network protocol that you simply won’t find anywhere else.

In the past few months I have written the following articles for you:

• Reading and Writing Packets
• Serialization Strategies
• Packet Fragmentation and Reassembly
• Sending Large Blocks of Data

Over the next few months I’ll have the rest of the series finished:

• Packet Aggregation
• Reliable Packets over UDP
• Message-Based Reliability over UDP
• Messages and Large Blocks Sent Reliably and In-Order
• Client/Server Connection
• Packet Encryption
• Securing Dedicated Servers
• Basic Matchmaking
• Bringing it all together: An Example Client/Server Game

I hope you enjoy reading this article series and please remember that I rely on your support to continue writing articles and open source code. Please support my work so I can continue sharing my game networking knowledge with you.

ps. Thanks to Alaska Robotics for the image at the top of this post!

I have a big announcement to make.

Over the past few months not only have I been hard at work writing an article series Building a Game Network Protocol I have also been extremely busy creating open source software. In fact, my strategy when starting this article series was never just to write articles, but instead to use this article series to create something that I feel has been missing for a long time – a professional grade open source library for creating a game network protocol.

There is a reason why I called my new company The Network Protocol Company after all.

So I’m very happy today to announce a new open source project: libyojimbo.

libyojimbo is a hardened version of the network protocol described in Building a Game Network Protocol. A C++ library for creating your own client/server network protocols over UDP. It supports 2-64 players and is meant for games that host dedicated servers. It provides secure client authentication, client/server connection management, packet encryption, and a framework for extending the protocol with your own packet types.

With libyojimbo it is easy to create your own client/server network protocol suitable for networking an FPS, a MOBA and any other realtime action game. It is also quite different from other network libraries out there, being created by somebody with actual experience shipping and networking these sort of games over the past 10-15 years.

Thanks to the generous support of my corporate sponsors and my patreon supporters (thank you all so much!) I have been able to move forward the development of this library and open sourcing of it under BSD 3-Clause significantly earlier than I had previously expected. But there is still so much more work to do before libyojimbo is ready for a 1.0 release…

If you would like early access to this library as it is developed, please support my work on patreon!

Thanks for your support!

– Glenn

Hey everybody, I’m up in Seattle this week attending DockerCon 2016.

If you’re anything like me (being a typical, sheltered in the game industry sort of low-level guy who prefers UDP over TCP), you might be wondering, as I was approximately one week ago, what in the actual fuck is Docker?

In short, Docker is a system to standardize deployment of apps (typically server-side stuff like web services) that lets you bundle up all the dependencies (eg. perl, redis, golang, python, wget, nginx whatever) into a binary called a “container”. This container is now a portable binary description of all these dependencies plus your application that can be run as an “instance” anywhere that Docker is installed.

For more information on Docker I highly recommend just googling What is Docker? and spending a few hours going through links.

This is of course all super interesting for the web nerds who have to deal with dependency hell on a regular basis, but what’s in it for us, the game industry guys? That’s what I came to DockerCon to find out…

What I learned is that that Docker is on the cusp of breaking out in the game industry. While you may have heard in the past that Docker is used by Riot in their build pipeline, what you probably have not heard is that this effort was so successful that Riot are now in the middle of transforming their production environment to be based around Docker as well.

On a similar note Romain Dura, Lead Programmer @ Boss Key Productions just had a successful Alpha Test of Lawbreakers last weekend with not only their web backend in Docker but also their dedicated game server instances. To my knowledge this is the first case where game servers for an FPS have been run inside Docker containers in a production environment.

This is what I think the trend is: studios that were ahead of the curve and evaluated Docker early are making the transition to using Docker in production. Other studios are just evaluating Docker for the first time and wondering what to do with it. They’ll catch on quickly.

One of the things I appreciate about Docker is its democratizing influence on development. Things that previously required expert teams can now be done by pretty much any old idiot (eg. me) and in such a way that it doesn’t lock me in to one particular hosting provider.

The game industry could do with a healthy dose of this sort of democratization. Teams shouldn’t be worried about hosting dedicated game servers but right now so many games are peer-to-peer or have player hosted servers due to concerns about complexity and cost.

Not only are new technologies like Docker making it radically easier for small teams to build backend infrastructure, now that Docker has been shown to be performant for an FPS, I believe Docker has the potential to radically disrupt how the industry hosts dedicated servers.

My interest in Docker is of course not in hosting web applications but in dedicated servers. One of the most interesting things about Docker for me right now is Joyent Triton which lets you run docker instances on bare-metal servers without a VM underneath, giving much better performance than EC2.

Joyent does not yet have a large enough distribution of data centers around the world for hosting servers for a top-tier AAA FPS, but this is likely to change in the near future with Samsung’s recent acquisition of Joyent.

If you’d like to experiment with Docker, they just released new versions today that make the whole experience feel much more native on Windows and Mac OS. It’s a big upgrade compared to previous versions and I recommend you check it out. There’s also a bunch of new stuff like Docker Swarm that are super relevant to teams needing to scale up dedicated server instances.

http://www.docker.com