4 ms·
OK, this is awesome. As a fellow game developer who learned to navigate the complexities of matchmaking and server orchestration the hard way (and begrudgingly)
by bcjordan 3y ago
OK, this is awesome. As a fellow game developer who learned to navigate the complexities of matchmaking and server orchestration the hard way (and begrudgingly), seeing Rivet open source a matchmaker and server orchestrator is exciting and honestly refreshing. For those outside of games, the use of modern webdev / infra tooling is frustratingly nascent, and production-ready OSS usable by smaller-than-AAA-sized studios is even more rare, just beginning to come online (the efforts behind https://game.ci https://game.ci are a recent shining example in game infra).
I'm particularly encouraged here by the tools and approaches chosen — Redis for matchmakers, ClickHouse for analytics/logs, Rust for speedy backend operations were tools I eventually came upon as best for the job after a long and painful process of iteration with inappropriate cloud dev tooling (with basically any datastore other than Redis you will run in to issues matchmaking).
High traffic/concurrency in matchmaking is a hard problem when you need fast, consistent matches. Existing industrial-sized matchmakers (Google's OSS OpenMatch, AWS GameLift, etc.) require locking in to a very specific format or spinning up an entire K8S cluster, which for game devops teams already stretched thing is a tall ask). And for all that effort, you may discover the performance characteristics of their approaches aren't what you need, or (as has happened to us with different game web service/API/middleware providers) they may choose to abruptly deprecate the service upon which you built.
Appreciate the dedication to making this available and the focus on helping gamedevs get up and running as fast as possible. Looking forward to playing around with Rivet and seeing where it might fit in our stack — & would love to talk shop on this with anyone since I've been tortured by / interested in these problems while trying to simultaneously run a game studio / make new games / keep everything online the last few years!
- devbug 3y agoThis echos my experiences, especially with the move to “live services” model for games. Often the teams working on the services for multiplayer games are very small so it’s all about leverage. They’re also embedded within a culture that doesn’t value or understand the practices and tools that are taken for granted in webdev, mostly because they’re hard to transfer to the other domains in gamedev. I’m glad to see the open source development of these tools. Personally, there’s a lot of stuff colleagues and I have built that I would love to see open sourced. Otherwise we just end up implementing the same services over and over again. Another example is patch delivery. It’s a solved problem yet everyone keeps rolling their own, or only shipping to Steam. Of course, all managed with some Jenkins scripts written by someone that’s no longer at the company. I want Fastlane for games that makes it easy to target the various distribution channels across desktop/mobile/console.
- lazypenguin 3y agoThe lack of a standardized patch system for games is mind boggling! Sure there’s some for desktop software exes which just ship the new version every time but those apps are rather small and games can be several GB! We had to roll our own for our game but I couldn’t believe there wasn’t a universal standard when I went searching for one last year. Butler from itch.io looked interesting but I couldn’t decipher how to use it in the end. Also rolling patches manually seemed crazy to me and we ended up using a library similar to rsync that works pretty well and makes deploying patches easier but still not perfect.
- NKissel 3y agoThanks for sharing your experience and kind words — we would always be happy to talk shop. I think it’s a shame that current infra solutions prevent a lot of hobbyists and studios from ever launching a multiplayer games, I would love to see it as prolific as single player experiences.
- doctorpangloss 3y ago> https://game.ci https://game.ci I don't recommend it. Game CI has been in development for a long time. It only really supports GitHub Actions. It can't correctly build il2cpp Unity projects. The licenses needed to run it are more expensive than Unity Build Automation / Unity Cloud Build. If you want to automate Unity builds and you don't want to learn the Windows Containers ecosystem, Jenkins and/or Tekton, you should use Unity's service. CI/CD is a bad choice for most developers, on most platforms, for most clients. That said, it makes sense to do for your backends. > or (as has happened to us with different game web service/API/middleware providers) they may choose to abruptly deprecate the service upon which you built. Which service was that? GameSparks? That sucks. > with inappropriate cloud dev tooling Well everyone takes their own journey to discover how shitty Lambda, Cognito, CloudFormation and related are. > with basically any datastore other than Redis you will run in to issues matchmaking Matchmakers do not have to be complicated.
- GabeIsko 3y agoI'm having a good experience with some automation build automation with Councourse CI. Of course, I self host, and I am doing some real trivial stuff right now.
- appplication 3y ago> CI/CD is a bad choice for most developers, on most platforms, for most clients. That said, it makes sense to do for your backends. Are you making this statement about game devs, or more broadly? I don’t know much about game dev, but if more broadly that’s a pretty spicy take.
- doctorpangloss 3y agoOnly in my experience, automated building of the client side of a game is usually low ROI. In broader contexts yeah you should be doing CI/CD.