druerridge's comments

Speaking to language usage (just as one topic) for Online Services for Games. I now contract in the games services space (after half a dozen years at a AAA studio) and have gotten to see a bit of an overview of how folks approach it. For small and medium studios, I see a lot of Python/Django approach to the problem which is quick to develop in and has a lot of problems solved for you. I also think Python is a frequent choice because a lot of the engineers are pulled from gameplay engineering, and python is familiar to a lot of folks from scripting their tools or plugins (e.g. Maya). Node/express pokes its head out for some small studios as well for similar reasons to Django. Go is increasingly popular for both AAA and indie companies for pretty obvious reasons (online services is literally what it was built for). C++ and then Java/Scala are common choices for older and more established studios.

In my experience, all of these languages are fairly well equipped to the problem space - even the interpreted/garbage collected ones can handle these problems well as they are (in my experience) infrequently CPU bound, and frequently the scaling considerations come in around your usage of databases and caches (network or IO bound). When you have enough players to hit CPU boundaries, you also typically have enough money to buy some pretty beefy CPUs. The caveat to this is that concurrency gives huge wins, since a lot of the requests/data are not related to each other (beyond the 10-20 people in a game) and so languages or frameworks that don't solve concurrency and/or async IO well are at a disadvantage. This puts Python/Django and Node.js further down the totem for me. Of course, there are ways to resolve those problems even within those languages so they are far from ill-equipped.

When I get my choice, I choose something garbage collected in a VM, with mature web frameworks (basically Java & C#) for online services in games. Knowing an engineer's errant null pointer isn't going to tip over your whole process is pretty handy, and the CPU gains in C++ or Go (native code) aren't put to as good of use here as they are in gameplay engineering where you're trying to squeeze cycles out of client machines. Client machines don't really get more powerful the more players you have, but your servers can, haha.

Spent half a dozen years working in AAA realm for multiplayer games and an equal amount of time working on my own indie projects, and as you can see already in this thread, there's really two (often confused) pieces to this conversation. First, there's Multiplayer Gameplay Engineering. This is typically a single process handling the 2~64 people shooting each other in a single game. Second, there's Online Services Engineering for Games. This is typically orchestrating the above process, hundreds or thousands of times, as well as things like Matchmaking systems, party systems, Storefronts, etc.

Below are two articles which I think can be really valuable "Baby's first" for the topics of Multiplayer Gameplay Engineering and Online Services for Games. I wrote them beginning from my perspective of approaching these problems my first time as a college student many years ago, and continued with how my approach evolved through experience. I also include lots of links to seminal articles/talks on the topics that I read as I attempted to "do my homework" while making my own indie game.

Multiplayer Gameplay Engineering https://www.gamasutra.com/blogs/DruErridge/20181004/327885/B...

Online Services for Games https://www.gamebreakingstudios.com/posts/dedicated-game-ser...

So happy to see this happening! I've also been advocating for more community development and knowledge sharing in this space. I believe there's a huge unfulfilled need to connect the industry more on these topics. I've also been organizing an event in the space, and looking at the possibility to land a special interest group in larger organizations that can support our community. I'll drop you a line!