Open source backend for a game?

Hey guys, i looking for an open source solution to manage content and store the game progress at the server. The paid solutions usually are very expensive for the small games, so I am trying to find an open source one. Does anybody know any good solutions for that? Preferably it should have some web interface to manage everything. If you have any suggestions would be happy to hear your thoughts.

 

PlayFab is mostly free until you start making serious money. Not open source, but you can pretty much make your own API FROM theirs if you want custom stuff.

Check out my signature link for an open source Node.js wrapper we made for playfab, mailchimp, and mailspark it's in alpha, so you may need to tinker it a bit, but it's fully functional

 

I just stumbled upon this thread. I think what you are looking for is Nakama - an open-source distributed social and realtime server for games and apps.

Nakama does indeed have a storage feature for game progress. You can inspect the data in the database directly using any postgres database viewer

I'm one of the devs behind Nakama, so you can ask me technical or non-technical questions. For a complete feature-list have a look at the Heroic Labs website

 

Hah! I was looking through the forums to actually post about Nakama just now so imagine seeing a post like this AND @mofirouz beat me to it!

 

do you have any experience in Nakama ?
i have visited their site but i dont find and decent information on player storage and features games need.

 

I'm one of the engineers who built Nakama. Nakama's Storage docs are here. We are working on enhancing the documentation, but in the meantime, you can chat with the engineering team directly on Gitter.

 

There's this https://github.com/NVentimiglia/Unity3d-Foundation/ which I don't recommend exactly, but it is open source storage solution. I'm working on porting it to .net Core so it can run on Linux, but the existing solution works fine if you have a Windows server.

 

How deeply embedded is the x86_64 requirement? Would be nice to be able to run your stuff on a Raspberry Pi.

 

nice to hear i havent read your complete post funny to ask developer to have experience i was in hurry.
i tried to download the windows setup but 404 failed update the page with correct link thanks i will try to make this working.

a video tutorial on how to setup will help you save lot of time in support.

 

As Nakama currently stands, we don't have any dependencies that restrict us only to x86_64. The server is written in Go which supports ARM builds. CockroachDB which is the recommended (and officially supported) database only support Linux and Mac native builds at the moment, however Nakama is (unofficially) compatible with Postgres as well and it seems like Postgres supports ARM systems. What kind of usage did you have it mind with Raspberry Pi builds?

 

Will ping your thoughts on the video tutorial to the engineering and documentation team.

The 404 page is now fixed - Thanks for pointing is out. If you are running on Windows, I suggest you try out Nakama with Postgres than Cockroach. It won't be performant as queries are optimized for CockroachDB's internal database (RocksDB) but it will work fine for development. CockroachDB team is currently in the process of enhancing their Windows support.

 

i will try it and update

 

Ok, so it would just need to be built for ARM? What about the clients? Supports anything Unity supports?

I'm interested in using a Pi or other SBC to run at least any latency-sensitive services locally. The idea is to have a small, cheap device that could be brought to a bar or other venue, plugged into power, maybe network, maybe a display and run locally-networked multiplayer games with clients probably connecting via mobile. With something as cheap as a Pi, you could actually leave it behind as a demo or to use as a pay service. I expect to keep using Unet for realtime communication, so its probably fine for me to just host Nakama on the internet. Is there a way to keep user data in sync across instances that are not co-located?

 

Yep - just a tweak to the Go build archtype and it should be good to go.

The Unity Client supports all build profiles including WebGL. We are also working on an Unreal client but that's still in closed source development.

Awesome!! I think data replication is a rather large topic to discuss over forum messages. I would suggest that you drop into the Gitter channel so you can have a chat with more of the team.

 

If you prefer Java which is more like C# you can take a look at: http://fuse.rupy.se/about.html

 

I was all set to do that because there's not enough documentation to actually get this running and I had questions about making the matchmaking service more useful. Then I noticed clustering is an enterprise-only feature and this link: https://heroiclabs.com/services/#enterprise
If you're serious about that, I'll have to just keep plugging away at my own solution. I'm not sure what other people expect from "open source" but if you hold back critical functionality, and especially if you seemingly try to hide that fact when promoting your project, you've completely discouraged me from using or contributing. Looks like a great effort, so I'm disappointed.

 

That statement made me chuckle on a couple levels, but still, cool project, and love the RPI stats!

 

I hope you’ll drop into our community and ask your questions. The type of cluster technology you want to achieve with your Raspberry Pi deployment model is not the same I think as what we offer as part of the enterprise. We have to make a living as a sustainable team as I’m sure you can appreciate so we help larger game studios run in various clouds like AWS, Azure, and Google Cloud. This requires some custom technology which we bundle separately. It’s what supports our ability to make so much of the technology open-source and free for all game developers. In any case I’m sure we can always help with what you want to achieve.

 

Understood, I just don't "agree" with that business model for my project. Your current feature hierarchy may or may not work for a specific use-case, but the issue is that you'll hold back valuable technology if you think you can make a profit on it (and seemingly not call attention to that fact. The only link I found to the pricing page was a possibly forgotten link in the client documentation.) I'm not sure what the open source gets me if you can just segment the feature set any way you want. It gets you free help and testing on your open code and a cheap way to distribute what amounts to an SDK. You have every right to make money on your work, but calling it open is misleading.

---edit---
I'm sure I'm not coming off very nice here. Just want to be really clear that despite my issues with what people call open or not, it seems like you guys are doing great work and I hope it's super successful for you. I may still "drop in" and ask you guys some questions. I'm sure it's all negotiable or whatever--but your current licensing model absolutely doesn't work for some other use cases I have in mind, which would require self-hosting and most likely self-administration without the cluster limitation.

 

@angusmf Sure. No worries. Thanks for the kind words. Don’t forget you can always load balance across a group of Nakama servers without the cluster system which could achieve what you want. I guess I just don’t know what cluster model you need for your games and how it fits into the distribution model you have in mind with your Raspberry Pi projects. Best of luck with it all.