0

I'm learning React.

I'd like to create a game with a basic tile-board (like here http://richard.to/projects/beersweeper/ but where tiles can have two states ('available' or 'already clicked').

In terms of speed, React looks interesting as with its virtual DOM/diffs, I could only adjust the css and text inside tiles that have been clicked (so that they visually differ form those still not clicked by anyone).

My goal (and personal challenge haha) is to make this game playable by 1000 simultaneous players who can click where they want on a 100,000-tiles board.(distribution among clients in real time of tile status would be done with Firebase)

Should I use basic standard React and its built-in features (onclick events,ts listeners...) or is it impossible with only-React to enable that many events/listeners for 1000 people on 100K tiles in real time with any user being able to click anywhere (on available tiles) ?

Should I use alternative/complentary tools and techniques such as canvas, React Art, GPU acceleration, webgl, texture atlases....?

user229044
  • 232,980
  • 40
  • 330
  • 338
Mathieu
  • 4,587
  • 11
  • 57
  • 112
  • 1
    You might want to implement it first. Benchmark. Do some calculations. See if it can handle 100k (in theory). Then you find bottle necks, fix, adjust, find alternatives to improve certain parts. – majidarif Mar 22 '15 at 15:20
  • @majidarif yes thanks I know but as I'm a rookie and learning, the time I'd need to make structural changes would be high for me. I'd rather ask here which direction to take even if I have after to change it – Mathieu Mar 22 '15 at 16:47

2 Answers2

5

WebGL is the right answer. It's also quite complicated to work with.

But depending on the size of the tiles, React could work but you can't render 100k dom nodes performantly... no matter how you do it. Instead, you need to render the subset of tiles visible to the user.

To pull something like this off, you'll need to have a lot of optimized code, and firebase most likely won't be up to par. I'd recommend a binary protocol over websockets and a database that makes sense (fast lookups on multiple numeric index ranges, and subscriptions).

Ultimately, I'd probably go with:

  • webgl (compare three.js and pixi.js)
  • custom data server in golang (with persistence/fallback managed by a mysql engine like maria or aws's aurora)
  • websocket server written in golang
  • websockets (no wrapper library, binary protocol)

The only reason for golang over node.js for the websocket server is CPU performance, which means lower latency and more clients per server. They perform about the same for the network aspect.

You'll probably ignore most of this, but just understand that if you do have performance problems, switching some of the parts out for these will help.

Do a prototype that handles 2 concurrent users and 1000 tiles, and go from there. In order of priority:

  1. don't render 100k dom nodes!
  2. webgl instead of dom
  3. binary websocket protocol, over socket.io or similar (not firebase)
  4. custom data server in go
  5. binary websocket protocol not using socket.io (e.g. ws package in node)
  6. websocket server in go (not really that important, maybe never)
Brigand
  • 84,529
  • 20
  • 165
  • 173
  • Thanks, that is so damn helpful! it's true that i might not implement all of it, but you've opened seriously appealing directions. pb with golang is that I'd have to learn this language (heard of it of course). Second problem: i can't use "regions" (minecraft use them) as you propose, that is to say i want players to see the whole 100K tiles (even if they'll have to zoom in to find them), i cant' have sort of giant map and only render 2K nodes and only load the rest when people scroll over it. so i'll have to find a way to support 50k to 100K DIRECT. – Mathieu Mar 22 '15 at 19:45
  • Also, why do you think back end database services like https://www.firebase.com/ or http://www.realtime.co/ which claim to enable persisten real time among thousands of simultaneous clients, would not fit. too many players doing too many things? – Mathieu Mar 22 '15 at 19:48
  • if I use webgl i'd have to ignore a lot of people as webgl is not well supported, especially on Internet explorer, firefox (partial support) and opera mini (http://www.caniuse.com/#feat=webgl) – Mathieu Mar 22 '15 at 19:49
  • lastly, if you had to make a wild guess, up to how many dom nodes (tiles) do you think React would be performant (1K?10K?50K). hard maybe to know without testing:) – Mathieu Mar 22 '15 at 19:54
  • 1
    Then DOM isn't the answer. WebGL or Canvas are the two remaining options. WebGL is more complicated, but at least would handle some of the rendering math and optimization logic for you. With canvas you'd be working in a 1D array of bytes (4 bytes = 1 pixel). firebase, etc. are great when you need to have a few users working on a document or similar, and they scale well for small groups of users, not one large group of users with a lot of data and changes bouncing around. WebGL support is limited, but three and pixi have canvas fallbacks, which gives you pretty good support. – Brigand Mar 22 '15 at 20:00
  • 1
    It depends on your definition of performance, but React isn't optimized for this kind of work, it's optimized for complicated applications (e.g. you could use it for the inventory system of a RPG, or menus, or the in game shop, etc.). If you do tiles in plain hand-optimized DOM, you could have (estimated) 2k tiles and do up to 50 updates per frame to stay at 60fps on fast computers, and 20fps on average computers. There are more factors than I can go into here, though and I haven't benchmarked this. – Brigand Mar 22 '15 at 20:04
  • If I use webGl, I guess React is out of the room? React to my understanding is leveraging the DOM (with its virtual DOM). Are there any frameworks/structured patterns to connect my backend data (Rails or Go) to WebGL? I liked the opiniated/organized structure I would have had with the View in React and the M(model) and C (controlle)r on Rails. – Mathieu Mar 22 '15 at 20:09
  • I've found some libaries with Reacts.js and using three.js, so it seem it's possible to use both: https://github.com/Izzimach/react-three. Would React be useful actually if I use webGL to display the 100k nodes? – Mathieu Mar 22 '15 at 20:13
  • I'm not a database expert: i use postgresql and know the concepts of nosql(mongo, redis...). You suggest a custom data server in golang (with persistence/fallback managed by aws's aurora). Well, could I store this data on postgresql or redis using the language Ruby to access it. Or does it really have to be in golang? Would you mind sharing why? – Mathieu Mar 22 '15 at 20:27
3

Lots of people use React as the V in MVC.

I believe that react is fine for UI but you should ask yourself what will be the server side logic, you still have to think about M and C

If you are looking for 1000 simultaneous users load, the keyword scalable will be your friend.

Also you should check out Node.js for the server side service. Express.js for it's fast implementation, and finally Pomelo.js which is a js game server implementation, based on node.js

On the subject of performance.. WebGL will most likely boost your performance. Here you can grab a nice tutorial on the topic : https://github.com/alexmackey/IntroToWebGLWithThreeJS

If you want to build it without GL languages whatsoever, you should digg deeper into JavaScript create your own pseudo-class library with dynamic data bindings. Otherwise you might end up using small percentage of a powerful framework that will only slow down your API.

I would restrain from using canvas, as they are good for model visualization rather as game front-end. Checkout d3.js for it's awesomeness and unfortunately performance issues.

Here I have written a nice fiddle, that creates 100x100 matrix with hovers, and perfromance is not so good. You can easly tweak it to get 100k element matrix: https://jsfiddle.net/urahara/zL0fxyn3/2/

EDIT: WebGL is the only reasonable solution.

Piotr Dajlido
  • 1,982
  • 15
  • 28
  • thanks for your answer. as for only the "V", I'll use Rails (I already have an app in rails) as a json API that feed data in json to the Reatc view (ex: http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-backed-by-rails-api/) – Mathieu Mar 22 '15 at 16:49
  • as a beginner, to manage data and distribute data among clients in real time and enable multi player gaming, I'll use firebase and won't do too much Node/express... – Mathieu Mar 22 '15 at 16:50
  • the problem with webGL is that it's not well supported, especially on Internet explorer, firefox (partial support) and opera mini (http://caniuse.com/#feat=webgl) – Mathieu Mar 22 '15 at 16:52
  • @Mathieu it would be nice if you could reproduce my fiddle field generation to do same task using React.js ( jsfiddle has support for react.js) We could see if there is a significant difference in performance. – Piotr Dajlido Mar 22 '15 at 16:53
  • i will but it might take a few weeks at least, i must first learn more javascript and React, never even touched theses languages and frameworks (coming from Ruby and Rails). Will do after for sure. – Mathieu Mar 22 '15 at 16:59