Thanks thanks,
There aren't much data in mechar.io yet, so I can tell you about wilds.
> How are you monitising this?
Displaying ads and selling virtual currency that players can exchange for swords, etc
> Are you in a position to share your stats on average play length, DAU etc?
About 300K UU / mo, with average gameplay time around 14 minutes. (10 minutes for new players, 25 minutes for hooked up players)
> What engines are you using, (particularly server side)
Custom solution on both client and server side. It's not really an engine - I am just copying previous project when starting a new and remove the parts that are coded the most terribly.
> Any plans to get this on iOS/Android?
Not really, the controls are kinda complex and it's too fast paced, I would rather write a game dedicated for mobile devices.

TL;DR Mechar.io
Ahoy everyone - it's been a year since I have released my previous game. I thought that I will be shipping a new game each three months but it turned out it takes a full time job to constantly improve the game so it can stay afloat Fortunately one day I have been approached by a fan of my other game who happens to be an artist - he sent me some lovely robots and I couldn't refuse to turn them into a game.
So here it is - http://mechar.io - a fast paced multiplayer shooter using the same engine as wilds.io
I don't have good gameplay video so enjoy this one:

> And to get local .json files ?
Do you mean you want to have some of the files stored locally and some globally?
You can use this undocumented notation
/* This way you can explicitly tell playground what to load and where to store it. */
this.loadData("<any/path/to/file.json> name");
/* examples: */
// this will look for some json file in google domain and store it as this.data.apple
this.loadData("<http://google.com/some.json> apple");
// let's assume you are in http://localhost/something/index.html
// this will look for http://localhost/something/common/heroes.json and store it as this.data.heroes
this.loadData("<common/heroes.json> heroes");
// this will look for http://localhost/common/heroes.json and store it as this.data.heroes
this.loadData("</common/heroes.json> heroes");
Let me know if you need more assistance.
It also works for sounds and images.

1) Playground is setting its container background. You can override it (see fiddle below). I don't even know what was my reasoning to do that
2) Each call of playground() creates a new application - you have two applications now. I have modified your fiddle - that's how you set paths.
https://jsfiddle.net/hgwqjyua/
* Fiddle doesn't work on chrome because you are linking playground.js directly from github and it doesn't want to execute it because github is sending it with MIME type text/plain.

@WombatTurkeyI have no idea but the codebase is rather small and written in C++ I simply think websocket/ws adds a big overhead in comparison especially when it comes to message encoding where it creates tons of intermediate objects.

@danzel Thanks for your intervention on Github - I would leave it as is if you haven't poked the topic and now we have that fixed - and dear God - this lib IS fast.
@ZISGAMING21: There are TONS of ideas - but there are two problems - I am working alone currently (splitting the time for freelance as I still have commitments to fulfill) - the second one is that the game is not popular enough to add more modes that require match making - it results in extremely long waiting times - nevertheless yeah - there will be mage, and shaman hero soon - then archer. Soccer and CTF game modes.

@ZISGAMING21 It's not your fault mate - the game has been under DDoS attack. It should be working by now.
@danzel Lovely idea. I would add up more juice to it - the fade out animation doesn't feel rewarding for clearing out the blocks - especially you should differentiate visual reward between clearing up 3, 4, 5 or more blocks.
1) If you want to decrease the bandwidth usage with one line of code - compress your JSON with LZW
2)Tho I would change this {x: 44, color: 6, type: 0} into a fixed [44, 6, 0] and go with BiSON - https://github.com/BonsaiDen/BiSON.js
Above all - if you are sending the same message to all players - the main secret is to compress ONCE and then send to everyone - disable perMessageDeflate and set { compress: false } when sending data - because you compress the same thing 20 times.
I wouldn't bother with any binary stuff for this game - and focus on gameplay instead - it's almost turn based.
ps: I have asked uWebsocket author about the spike - but I don't really understand the answer - https://github.com/alexhultman/uWebSockets/issues/137 @moka Ok - so despite of everyone thinks - I am not a technical nerd - so some of my answers may sound silly to a professional (:
As for extrapolation I will be adding movement prediction - and fire the attack right away - my attitude to that is more psychological - I believe that players are ok with some delay as long as it is constant - that create certain flow of the game. Not my words actually, but guy who did networking for Age of Empires. Also my game is much slower than regular FPS or any kind of arcade shooter.
1) If you mean how do I take advantage of multi-core architecture - I don't - I am using bunch of 1 core servers.
2 and 3) I send same data to all the clients - which of course makes things like hiding in bushes impossible to implement or at least very prone to abuse. I compress a bulk of data once and send it to everyone.
4) The game eats up between 6 to 12 KB/s
5) IDK, I don't measure the latency - but I guess anything resulting above 200ms response time becomes annoying
6) 20 times per second - I have experimented with rising up this value - but it doesn't improve the feeling much.
Now for the technical juice part - I am using websocket/ws (I can't understand popularity of socket.io which is just an abstraction over another abstraction over websocket/ws). I have high hopes for uWebsocket pointed out by @danzel - the performance is AWESOME - but the spikes it has are untolerable (see this https://github.com/alexhultman/uWebSockets/issues/137)
I am most successful with UTF8 and BiSON without even deflating that - and I have tried tons of compression combinations. From binary methods I have only tried BSON (not BiSON) - which was 50% CPU gain over UTF - but for some reason my servers became very laggy after an hour.
I believe that Protocol Buffers (or simply any form of fixed structure encoded into a binary) is the cutting edge of what you can get. I will be switching to that too - soon - I just don't have time to rework my architecture now. I am also using fixed structure binary packets, although I send them over UTF-8 - read specs of BiSON - it's not much different than BSON or PB... or any binary format since decades ;p
If some of my answers are not adequate - don't hesitate to tell - I am not a native english speaker so if you rephrase something for a 5 years old it might click

@danzel The library is great in terms of performance (clearly faster that websockets/ws) but I am getting serious spikes/lags for an unknown reason.
Arrival times between packets. 0 means that two updates arrived at the same time - so it either fails to deliver or postpone delivery. That's not the case with websocket/ws

Soz for the delay. Would love to say that it was due to a break like @benny! suggested - but I had to meet my commercial deadlines
One server ($5 digitalocean thing) can now withstand 140-200 players - the most CPU goes into websocket communication not the game logic as one would expect. Not that I am using UTF-8 not binary packets - but I plan to switch soon, so I can give you a report was it worth the work.

Not sure if anyone is interested but perMessageDeflate in websocket/ws is super bugged - it causes huge memory leaks - after disabling that my server can handle 200 players instead of 40.
Also thanks for all the congratulations. The game is getting steady flow of users but with that comes a responsibility, worries about loosing players and feeling of constant demand for new features - it burns you out nonetheless than corporate work

@WombatTurkey I have moved to Digital Ocean because they let me clone a server with one click.
I am currently running it on cheapest nodes which stands for:
512 MB RAM
Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz
I am running 10 of these.
It can only handle 40 players - although from what I can tell only 20% burns in the game logic, the rest sinks in websockets communication.
Take note that I didn't bothered with binary transfer - it's all based on LZW compressed JSON which might be the reason it's underperforming

@kevdude: I can't answer marketing question yet - we shall see in a few months. I am hosting it on a bunch of 1 core (node js doesn't support more anyway) VPSes on https://www.ovh.com/
@end What's more important than extrapolation is predictability - as in the constant flow of the game - if every action takes 200ms to see a response - players will get used to it and. For player controled character tho it's good to have some instant response even if it's not truly synced with server state - legs and torso direction for the main hero in my game are determined by client. The skills are however not - because it could lead to very frustrating misses.
@umz: The controls are in the early stage and lots may change.
@blackmoondev: One thing that I don't miss - is Jameson. It was painful experience :S
@mattstyles: I want to reply to everyone - so -thanks
@Gio:
Postgres - some people who are dealing with millions of records told me that I will cry at some point if I pick mongodb.
Yes I am going to roll my business model solely around Patreon - if it fails I will think about switching to real payments or Steam. The game is browser based - it's always extra work to make it available and updated on Steam - I can put these extra hours into gameplay instead. Also there is a ongoing myth that being on Steam = super revenue. I have earned around 5000$ (minus Steam cut, minus taxes from QbQbQb) which wasn't worth the hustle - I've made a lot more from bundles than the Steam alone.

Almost.
I bought most of the sounds - also Yeti and Goblin are some stock models.
The biggest challenge was to sync object life-cycle - as in take care of that the client doesn't try to operate on objects that have been already removed - or not yet added.
It's not my first attempt at multiplayer so I find the whole thing rather easy - but I remember that the first time I have read too much about extrapolation (predicting where the object will be) and overengineering the whole thing. Today I don't give a damn about extrapolating data (except very fast objects - like bullets) - I just interpolate everything - which simply means tweening positions to the next set of data received from server.
Also I do not recommend "do it all yourself" attitude I am practicing - it's a waste of time, health and potential. The only upside of it is that there is nobody except you to screw up.