So you got Websockets, but you'd Rather have UDP...

(UPDATE: I now have WebRTC Datachannel handling unreliable updates in my server. A more in-depth post is to come.)

Websockets are great! They just work. They are supported by all modern browsers. There are libraries that let you easily write servers that support oodles of them. The user doesn't have to do anything to connect with your server. TLS ensures you have strong cryptography, and even that is seamless for the user. So what's not to love?

TCP stream semantics. Guaranteed delivery can be useful. Sometimes guaranteed ordering is nifty as well. But sometimes, you just want to send updates in a fire and forget style, where if you miss one update, you just take the next one. This is where websockets can be a real pain if you are a game developer. Not only will a dropped packet get you huge outliers of latency, all of the following messages behind it will also be delayed due to the ordering guarantee. This can cause a game to look stuttery or feel laggy, especially on channel-crowded wifi networks, as the stream semantics can effectively cause a momentary across the board mini-blackout/delay of all server information.

However, I did say I had a solution. It's not perfect, but it seems to work quite well in Emergence Vector. (I haven't even thought about benchmarking it yet. Perhaps I can make that a future blog post.) For frequent server updates, I simply use N websockets and round-robin them. This effectively spoils the ordering guarantee, which is what causes the across-the-board delay.

Granted, there's also WebRTC Data Channel, which would let us specify unreliable communications. However, the Go libraries don't seem as mature, and there are reasons why I would rather not have peer-to-peer. So perhaps in the future, Emergence Vector will be moving to that. In the meantime, this seems to work pretty well.

No More Turn Limit

One of the first things testers have noticed about Emergence Vector, is that the player's ship stops rotating after 720 degrees continuous turning in the same direction. The player can turn more, but needed to press the arrow key again to restart the turn. There was a very good reason for this.

As with all good multiplayer client-server architectures, Emergence Vector's philosophy is to strictly distrust the client about everything. However, if we waited for a round trip to start turning the player's ship, the lag would be too large. It used to be that we solved this through dead reckoning at the start of a turn, with a server correction at the end of a turn. This limited the length of a single continuous turn to our dead reckoning limit of about 3.5 seconds, or 720 degrees of turning. Now, we have extended our protocol by adding updates and server angle corrections all throughout the turn.

Fixing Pay to Win (with Pay to be Awesome)


Any solution to the "Pay to Win" problem in Massively Multiplayer Online games needs to do 2 things:

  1. Make developers money
  2. Satisfy all player's emotional needs

Whatever the solution is, it has to do both of these things. If companies and developers have to leave money on the table to prevent "Pay to Win," economic forces will make "Pay to Win" the winning strategy for companies, and doing the right thing will become the losing strategy -- which is exactly the situation the industry is in right now. Obviously, the solution has to satisfy the emotional needs of both "whales" and "regular" players. The "Pay to Win" problem is precisely that the "regular" player base is being alienated. This alienation is currently unsustainable, because the whole basis for income from "whales" is their ability to lord it over "regular" players, but as more and more "regular" players become alienated, the "whale's" motivation to spend money will disappear. Don't just take my word for this analysis. This is Extra Credits and James Portnow's analysis as well. 

So instead of “Pay to Win” how about “Pay to Be Awesome?" We already know that there are plenty of ways characters in a multiplayer game can be "awesome" without lording it over players. Certain Non Player Characters (NPCs) can be awesome to have on your side. So how about creating another category of in-game user who can't win and isn't a "regular" player? I was sitting around, thinking of ways this could be done, and it occurred to me: Everything I could think of started to sound like crowdfunding donor rewards. So why not replace "whales" with "benefactors?" Such rewards could even be approximately equivalent to crowdfund rewards. 

  • Pay to Industrialize — Parts of the industrial infrastructure are effectively bought by the benefactor, which will benefit “normals” by providing goods and services. Upkeep of the infrastructure will cost a ton, so the benefactor has to run a successful business or keep paying high rates. Benefactor must sell all items on the open market.
  • Pay to Glass Cannon — In order for “normal” players to hire or summon them, normal players need to acquire resources that can’t be paid for. This means that a "benefactor" can play an important and highly sought-after role, but the advantage that the "benefactor" brings still must be earned by the players benefitting from them. 
  • Pay to “Hero” Content - Benefactor will have special items within a particular content instance giving them special powers, allowing them to give out temporary buffs or sell special items to others, but which only work within that instance.
  • Pay to Civilize — A benefactor can “rule” a new “Civilized" content area, having the ability to act as the area’s defender. (NPCs will also defend the new area when the benefactor is not logged on.) 

The key here is that benefactors are not regular players. They wouldn't appear on leader boards. The mechanics would be rigged so that they could help players, but they could not win, so they also couldn't be "whales" lording it over the ordinary players. They would effectively become Non Player Characters with human levels of intelligence and complexity. Benefactors would be just like Kickstarter donors who can inhabit their NPC thank-you gifts. Granted, the system would have to guard against a person paying for a bunch of benefactor gifts, then buffing their own player, but since benefactors are a different category, it would be easy to place programmatic limits on such buffing. My current idea is to use a "conflict of interest" score that would prevent one player from receiving too many benefits, requiring benefactor buffs to be spread out over many players -- which, incidentally is exactly the behavior we want. Alternatively, such a system could leave out buffs altogether. 

So what do you think? I think this is a way in which we could channel the desires behind the sociological phenomenon of "whales" and turn it into a way that the same money would go to funding more in-game content -- because that's exactly what this is supposed to do. "Paying to be Awesome" would become just a way for a different kind of audience to fund more game content for all players.