I am just starting to learn about your engine to use it in my game development process. I see that you have a huge variety of features, but if I use your engine all my game will be residing on the client-side. Then how in this case I prevent cheating? Everything on the client side can’t be trusted, right?
In the past I was using a server authoritative model, where all the client was doing is sending keyboard commands to the server and accepting game changes from it. Can I implement a similar model here? Essentialy use PlayCanvas on the server side?
Depends on the your game design. Is it single player? Do the players interact with each other? Is there a high score board or something similar that you would want to prevent cheating?
To directly answer your question. The only way I’ve seen PlayCanvas being used on the server side was to use a headless browser. (@devMidgard did this I think) but you could instead your own server (nod, something else) and use PlayCanvas on the client side for user input, rendering etc.
Yes, it is a very competitive game and I want the server to be authoritative in the matches, to prevent any cheating. I am thinking about using babylon.js on the server-side (using their NullEngine feature created specifically for server-side scripts), because it seems like PlayCanvas is not intended for server-side at all. What do you think about that?
Generally, no. PlayCanvas was not intended for backend use. TBH, I’m not 100% sure why you would want to use WebGL framework/engine for the backend beyond simulation of physics. I would consider writing a custom server and using babylon/playcanvas/something else for the client.
The situation is that I am just starting to figuring out how to use engines to develop an online game. In the past, I was creating my own node.js/socket.io server, and I didn’t apply any engines. But building your own game engine is very difficult, so I am looking for a way to simplify my work. That’s why I want to use Babylon.js physics engine for the server side.
I would love to hear any advice from you about it. What game engine should I use on the server-side? Let’s say I use Playcanvas for client rendering, PlayFab as a BaaS and I want it to be a js engine.
Do you need a full game engine server side though? What benefits do you think it would give you? I think that’s the part where I’m having trouble in understanding the requirements.
It sounds more like you want a single code base for both the backend and client in which case PlayCanvas won’t fit your requirements.
Personally, I would have separate codebases between the server and client just so I have the option to use different technology on the client (eg mobile).
I’m having a quick look myself of the libraries and didn’t know there were so many for the server side.
After some experience doing multiplayer web games, I would recommend not to use JS for the backend (aka GameServers). While it seems like an approachable solution, it comes with a lot of drawbacks if you’re doing something complex, also NodeJS is ages slow in comparison to C++ or C#.
My recommendation would be to use a Unity GameServer written in C# and then compiled to run on a linux machine, that would be the easiest way you can think of. No need to reinvent the wheel as Unity provides lots of useful stuff.
And just use PlayCanvas for the client, sending inputs and rendering as @yaustar mentioned.
Also, completely forget about using SocketIO anymore. It is no longer needed. And it shouldn’t be an option for realtime multiplayer games. Maybe for other things.
Also, completely forget about using SocketIO anymore. It is no longer needed. And it shouldn’t be an option for realtime multiplayer games. Maybe for other things.
Do you mind expanding on this? What do you use instead?
You can use the websockets API provided by the browser directly, no need to use socket.io unless you want specific features (e.g. Rest/polling callbacks).
Doesn’t that mean you’d have to rewrite all networked game logic for the server?
I’ve used Mirror with Unity before, and as you said, since Unity lets you run a headless instance, I could reuse all my game logic. But if you were to use PlayCanvas for the client, then wouldn’t you have to reimplement a lot of the same code in Unity?
Even setting aside the extra time, that introduces a new window for bugs–if the server code doesn’t exactly match the client code.
The idea would be that you have a shared library for the client and server that holds the game logic.
At the moment, I don’t think PlayCanvas can be ran fully headless yet although it is open source. I do think a few people have created their own forks that have been made to fully headless.
If you’d like to run PlayCanvas directly on a Node.js backend you might find this post helpful. I haven’t tried it myself yet, but I’ve heard some people have some success using jsdom to run PlayCanvas in a simulated document.
Not to sidetrack too much, but I’m also kind of curious as to what the best approach might be for running a backend with PlayCanvas as the frontend. With the engines I’ve used (namely UE4, Source Engine and Unity with UNET & Mirror), it’s always been very helpful to have the client and server code incorporated into the same codebase running on the same engine. This allows for running listen servers, i.e. a local server that runs on a client and can be connected to by local or remote peers. This is particularly helpful when you want to host LAN games, create P2P games without the need for hosting fees other than a matchmaking backend (although P2P does usually mean more latency, looking at you CoD with host advantage) or have a single player game that still uses the same networked code as the multiplayer portion of the same game.
Using a separate codebase on the server without the main engine would mean a few things could become quite difficult:
When you want to spawn an entity over the network from a template (maybe a player pawn), you’d have to implement the same template instantiation mechanism on the server and ensure all templates have settings identical to the settings on the clients so the clients can predict movements and behavior properly to mimic what’s happening on the server;
As previously mentioned, if you want an authoritative server that verifies player physics, you’d have to implement the physics engine yourself which is quite a nut to crack. This would also mean you’d have to implement an entity system with transforms, hierarchies, some form of the rigid body component, a scripting system that uses the same character controller scripts as the ones on the clients to replicate the exact movements on the server using the input from the clients, and likely you’d need other general engine features that are already available in PlayCanvas;
If you want to run a non-JavaScript codebase, there would be overhead in porting the same code to another language and you might have to deal with language specific issues (JavaScript is kind of picky for instance when it comes to mixing signed and unsigned integers in bitwise operations when serializing to a network stream);
I’d really love to have a catch-all solution for running listen servers on the client and dedicated servers without PlayCanvas on the backend, but so far I haven’t really been able to find the perfect solution yet. Perhaps I should make a separate threat before I hijack the discussion, sorry in advance haha. I absolutely agree it makes much more sense to run a more lightweight implementation on the backend to save on CPU & RAM (especially when scaling up with lots of concurrent users), but having to reimplement so much engine logic to get the same behavior between clients & the server is a daunting task. Hopefully this helps with the discussion a bit even if I went a tad off-topic perhaps .
Edit: sweet lord I just realized this thread was created in 2018 and revived, haha oops
Wow this is pretty much exactly what I was looking for haha. Cool to see how it implements only the parts of the engine that it really needs. Very exciting stuff, can’t wait to see how it develops!
Haha gotta love @moka ! Would have given anything to have this 4 years ago
Now I pretty much just grab the playcanvas math functions and the GraphNode class and you can run any position/rotation transformations, for top-down 2D games that’s usually all you need (and very lightweight).
If I require to simulate a 3D world in server-side tho I just grab ammoJS or cannonJS depending on the project needs.
I’m looking at achieving something similar in the near future, this thread is very useful for future reference for me.
I also noticed that venge io was developed in PlayCanvas by a developer here, it seems like they have implemented a very nice client-server communication and I was wondering how he/she achieved it as well.
Why would you discourage it? Does socket.io have some limitations? I was thinking of using it originally. When I look at google tutorials for creating multiplayer for HTML5 games they all favour using socket.io, but most are pretty outdated.
.
