Hello community! This is a very strange question, but I’m a little confused. I want to create an online game using three js library and socket io, but I know unity and unreal engine have webgl export too.
Which is better to choose? I heard that this does not work well. If someone has worked with this technology, can you give some advice?
please do not kick
The forum is not stackoverflow^^. Questions which create opinion-based answers (e.g. because of personal experiences) are allowed. Let me just update the topic’s title…
Sorry, i understand it. just interested in personal experience. Thanks, I did not come up with anything better for the topic title 
These kind of questions are hard to answer. Or rather, it’s hard to find someone who can answer well. You need to have a working knowledge of three.js and Unity or three.js and Unreal. All three systems take months to learn to a level where you can meaningfully compare them. So, very few people have the expertise to answer.
However, word on the street is that Unity is much easier to learn than Unreal. I would say that’s a good system to use for building games. If you use three.js, since it’s not a game engine, you’ll write a lot of game engine code yourself. If your game is simple and you already know three.js, that might be a good tradeoff. I’d recommend reading this book before you start, it’s free: http://gameprogrammingpatterns.com/
Or you could use Ecsy or Meep, engines built to use three.js (Ecsy works with any engine I think). But again, there’s no way I can advise you on those since I’ve never used them. There are probably other three.js based game engines besides those two.
Personally, if I wanted to create a game, I’d use Unity. If I want to create 3D websites that load super fast, I’ll use three.js. But that’s just my opinion, it’s not based on experience.
A small elaboration about meep. Meep is not three.js centric, it has a very good binding to three.js, but you could just as easily add a binding to any other rendering engine. It’s completely modular in this respect.
Unreal and unity are game engines, while i think three.js is not. I think in general, for a game, you would get more tools out of the box, they would be more robust, and you wold have access to an entire ecosystem of additional tools (like the unity’s asset store).
Three.js on the other hand, won’t have as many game centric tools, or they won’t be as robust. However there are other scenarios where three excels. A game is self contained, the ui is within it, so you’d design yours in unity. But when this needs to bridge that gap, and your “game” needs to interact with other elements of a web page, i’ve heard unity starts getting in the way. In this sense, three integrates much better, as it’s just a part of the page by its very nature. Up to you though, how well you integrate it, but analogous to the unity asset store, here you have a whole ecosystem of “front-end”.
Some examples of where three.js makes more sense:
Unity:
Out of all the three examples, the last one actually is the best match for three. Because you can:
The washing machine is the second best as you may need some extra work and experience to make it as smooth as it should be (quick loads, comfortable UX etc).
The starry background is not as perfect, while easy to make it’s quite a heavy library for a simple effect, it could be done perhaps with just raw webgl (but it’d be much more involved to develop).
The CAD application is 50-50. You’d benefit a lot from the ease at first, but when scaling it would start to get tricky. Some alternatives here seem to be to compile some non web code to be web compatible and work with that, but it’s orders of magnitude more involved.
With the unity examples, the idea is that any example will be some kind of a modified game. With the idea that a game engine would have bindings for a device such as a kinect out of the box, while it may be more involved to setup something like that on a web page (for various reasons).
Hence, even when choosing the technology for the same thing (a kiosk) it would make sense to analyze the requirements and the problem beforehand and choose the right tool.