Is there a need for Game Session (Infrastructure) as a Service?
Hey game developers, I'm trying to validate the idea of building a Game Session as a Service or even as a Backend.
I imagine a lot of game developers want to spend most of their time building the game and the game mechanics not the multiplayer infrastructure, the game matching mechanism, etc.
As the founder of Chessroulette – a chess platform that connects people with camera over a game of chess, and I had to build the whole thing myself. It was fun but that took a way a lot of time from launching the product, and failing fast. Also, I mostly think in terms of turn based games or board games, not AAA games with intensive io, but who knows – maybe that could be achievable too.
The solutions out there are either very low-level like AWS GameLift or built into the Game Engine, but not much as a plug and play saas.
Any thoughts?
I really think game development infrastructure is a very empty and untapped market, especially for the game engines that are used by indies (eg. Game Maker, Unity has some native stuff, but there is always space for more, Godot has none, Defold, etc).
But it seems you are talking here about multiplayer game management, which might be a more difficult endeavor.
But if you would be talking about a session stats tracker for games (eg. time spent per session, some event tracking, etc), I think you would be standing on a goldmine :D
Hi @vladcalin, thanks for your reply! Yeah, my experience is mostly with chess and other turn based games, more or less simple multiplayer games where the IO isn't
crazy complex, but I believe that there is room for building stuff in this territory as well.
By Session I mean all of the transitory game state, like the moves in a chess game or the positions in a Tik Tak Toe to keep it simple in the example, but it could also be any realtime data state that needs to be synced among all of the players or even users of the game/platform – like for example "a challenge has been created" and it gets shown to everyone who's currently "waiting" or even a chat box, etc.
So the way I see it, it could work as a cloud service, with and Server SDK where we take care of the infrastructure (io, protocols, databases, etc) and Clients only care about hooking it up to their backend. This way they don't have to deal with database/redis, sockets, etc. It could potentially work with a Lambda/Function as well.
Later on it could even become a backend as a service as well, where the SDK could be loaded on the client directly (like firebase for ex) and at that point they really don't have to do anything other than building their game and hooking it up with us. This needs proper validation though.
Curious to see what you think,
Cheers and Happy New year
6 months later, I'm ready to share that https://movex.dev was born as a result of this question and I am ready to launch it! :D