Thoughts on final design for noBackend cross-device platform for turn based games?

[Laurent Sigal]

Hey guys,

 

 

tldr:

 

I'd love to know if any of you would be interested in a noBackend solution for turn based games. For you (as a game dev) that would mean just program 2 files for a game: client.js (all the game design) and server.js (the game logic, so that cheats are prevented) and upload them, and you would have your game online, with all the multiplayer functionality (login, invitation flow, game creation, notifications, chat) for free. 

These are not words in the air, most of the pieces are technically coded already.

 

 

Longer version:

 

After having spent an important time looking around, it seems that nowadays, making a multiplayer game cannot go without having to set up a backend and some kind of infra.

More importantly, most games that I have seen that supposedly offer a multiplayer functionality, are actually lacking most of the important features to do so. In particular, it seems almost impossible to play with friends in any of them.

And in a way, it totally makes sense: When you are an indie developer, what you're mostly interested in is designing a great game, not dealing with all the stuff that has to go around it.

And the sad part is that some great games never make it online because of these barriers.

 

 

I have been working on a game (adaptation of Risk) for a long time - can be found at http://plynd.com ; already mentionned in an earlier post on this forum.

And as a matter of fact, all the extra stuff (what I call the beyond-the-game experience) really interests me, as I am a backend engineer originally.

And all the work that I've done for Risk has no reason not to serve other people.

 

 

Therefore I am turning this game into a platform, and these are the specs:

- All the identity and game management flow is taken care of by the platform (think of : "you've been invited by .. to play" or "it is your turn")

- The backend is provided to store your game state (think plain json)

- The realtime and notification flow is for free

 

=> This would basically always set you up in a situation where n players have joined your game.

 

Which means that, as a game developer you can just focus on 2 things:

- implement all the game design within one client.js file. It is run in the browser of the user. nothing new there.

- implement all the game logic that you do not want to run on the client side in server.js. This is where the game state should be updated (to react to players' events). This will run on our servers and you will have a seamless bridge to call these functions from the client.js file.

 

This is not completely implemented yet, I am working hard to make it happen with a friend of mine. But we have technically proven all the pieces required to make it work. We are now working on making a very basic Connect-4 so people can see how it would really all work together.

 

Note: the game would be available everywhere (iOS, Android, web) within dedicated apps (but that's HTML5, so you were expecting it right?)

 

 

So (finally) comes the questions: would you see that as interesting? Would you use it? What would be your potential concerns? Aside from the technical aspect (that we are pretty confident about) do you think we are completely off somewhere?

 

 

Thank you very much for reading this very long post!

 

 

Laurent

[Sebi]

I wouldn't use that.

The only one who benefits from that would be you.

 

 

 

And in a way, it totally makes sense: When you are an indie developer, what you're mostly interested in is designing a great game, not dealing with all the stuff that has to go around it.

And the sad part is that some great games never make it online because of these barriers.

 

Based on what? lol.

Which games did never make it online? Why do I have to be more interested in the game design than the backend?

 

 

 

 

This is not completely implemented yet, I am working hard to make it happen with a friend of mine. But we have technically proven all the pieces required to make it work. We are now working on making a very basic Connect-4 so people can see how it would really all work together.

 

Because creating multiplayer connect 4 games is so difficult?

 

 

Note: the game would be available everywhere (iOS, Android, web) within dedicated apps (but that's HTML5, so you were expecting it right?)

 

Yup, that's what I'm expecting.

 

You need to provide some more informations for anyone to discuss your project/idea.

Right now I don't see any benefit, but maybe my opinion will change as soon as you have some more to show.

[Laurent Sigal]

Thanks for your answer, it is very interesting.

 

 

Could you just dive deeper into why it would only benefit me? At the moment I don't even really see how I could benefit from it at all myself (but that's a whole different discussion).

 

 

Based on what? lol.

Which games did never make it online? Why do I have to be more interested in the game design than the backend?

 

 

Based on conversations I've had, and games I've seen. Although I clearly do not put into question that some people love backend (it'd be pretty weird coming from me), I noticed that the ones who have the game design skills are not necessarily the ones who have the backend skills.

Think of all the games you've seen where you have a popup asking what your name is. This is to circumvent the need to implement all the authentication logic. but it means the game is not really playable in its intended way. In particular, how would you be able to go back to one of your games later in such a case?

 

I also know that some people would agree their games only make it to localhost.

It might not apply to you, which does not mean it is not true. It used to be true for me, did not know how to setup an API server. Parse probably shows that I was not the only one in this case.

 

 

Because creating multiplayer connect 4 games is so difficult?

 

Haha, I suspect this is being intentionally bitter :-) But yeah, creating a Connect-4 is simple, finishing the framework so that a Connect-4 game nicely fits into it and that it could apply to other games later is a bit harder.

 

 

The important part here is that you do not need to set up an infrastructure at all to host a multiplayer game. And that you do not have to focus on all the authentication/creation flow. You basically have nothing more to do in order to get your multiplayer game working than you would for its single player version.

[James Cat]

I once developed a graphical chat room / vitual world (something like Habbo Hotel) and all the functionality was in the client, this worked by a kind of negotiation between the clients and effectively one client performed space management (e.g. pathfinding to prevent avatars colliding) the big problem was that if that 'special' client was closed the others would not cope - obviously this rarely happens when the game is managed by the server, but clients regularly start and stop. So we gave up and moved the spacial logic into the server, that's not difficult to do by the way, in many ways it was technically simpler

[alex_h]

all the functionality was in the client, ... one client performed was .. 'special' client 

 

the other problem with this model is that all the network traffic has to travel twice as far. Effectively the length of a single broadcast is doubled since normally a broadcast to other players just goes from player A to server, to other players B & C. In the 'special client' model a broadcast goes from player A to the server, to the 'special client' back to the server then off to the other players B & C. This means that there is inherently much more lag.

[Laurent Sigal]

Just to clarify, I am not proposing a solution where there is a "special client". In the specs that I outlined, server.js is run in a server.

Simply you don't have to set it up, and the javascript there is in essence run exactly the same way as it would be if it was on the browser. i.e. the function someFunction that you define in server.js can be called from client.js simply with Bridge.someFunction().

[AVENGER NO WAR]

as a developer who developed several game servers for my multiplayer games (which have myown servers), if you include a good distribution program along your api, i would use your api, BUT beside my own servers.

who can guaranty you serve our server.js files life time?.

after a while you might come and say: hey guys we have problem by paying servers costs and we decided to shut down our api. (which i experienced it before with another program)

 

http://www.gamooga.com/ is very similar to what you want to done, except they support both TurnBase and RealTime games. (i did not tried their service yet)

[James Cat]

oh hi sorry Laurent I misunderstood... I should have read your post more carefully.

 

sure it sounds like a good idea, I am most surprised it does not already exist....

[Laurent Sigal]

@Ali, you're making a great point here, yes there will be a guaranty of service. Otherwise, you're right, there's a too big dependency to rely on.

 

As of gamooga, it is really an abstraction of the realtime logic, with the nice touch that they allow to upload the backend instead of having to deploy own servers (which is similar to what I am proposing). However, this is very generic so they have nothing specific for games (neither realtime or turn based).

[Christopher johnson]

I'm not familiar with any of the above options, but I'd like to recommend one that meets your needs.

Experience next-generation !! Real-Time Conversation Cloud | Omnichannel Marketing Automation

Meet Resulticks Totally integrated, built and proven to scale, Resulticks brings together a powerful audience data platform, true omnichannel orchestration, and advanced analytics in one intuitive, flexible solution that delivers measurable business results through individualized, real-time communications.

 

Edited May 11, 2022 by Christopher johnson
Just removed the pic