21 ms·
Cool project (based on me skimming the documentation). I’m a hobbyist game dev whose been attempting a deploy of a simple multiplayer game on AWS, specifically
by sovietmudkipz 3y ago
Cool project (based on me skimming the documentation). I’m a hobbyist game dev whose been attempting a deploy of a simple multiplayer game on AWS, specifically gamelift, for about four months.
Turns out I thought I knew more than I really did thus I’ve been spending much of my hobbyist time learning more AWS. I’m pretty stubborn about a local dev experience which takes time to establish an appropriate mental model to do. So it goes. Pro tip: find your application “interfaces” and discover what tooling can be used instead of a cloud resource (e.g. a mongoDB compatible document database is the interface to which AWS DocumentDB and MongoDB are concrete implementations). I have a docker compose file I use for local dev. It’s the best setup I’ve found for myself but I am open for advice.
Anyways I’d just like to voice myself as a possible target audience. Being able to develop locally is important to me and the hardest parts with AWS is having little support on how exactly to do this. Assuming this is even a fair ask to make…
P.S. another pro tip; I use Unity + Mirror networking for my multiplayer games. GameLift requires code integrated into your game code for it to function. I use nested prefabs to handle two cases: (1) when I want gamelift code to execute and (2) when I just want to focus on writing the multiplayer code. My production code uses (1) and I usually do development in (2). (2) is a child of (1).
P.P.S. GameLift has a lag of about 2-3 minutes when registering my running game server in Unity editor with a “gamelift anywhere fleet” before it can receive traffic. I didn’t know about this for a while and stressed out over the inconsistency. Make sure to measure timings on this so you don’t go crazy.
- NathanFlurry 3y agoThanks for the kind words and tips! > Anyways I’d just like to voice myself as a possible target audience Local development is tricky, and we have plenty of room for improvement here. Currently we provide a special developer token [1] which will cause API endpoints to return mock responses when used locally. This way, you can use the exact same API with no difference in production & locally, so you don't have to mess with nested prefabs. However, this doesn't help much with exposing your local machine for testing. We've toyed around with the idea of something similar ngrok built in to our Rivet CLI and integrated in to the API. [1]: https://rivet.gg/docs/general/concepts/dev-tokens#mock-responses https://rivet.gg/docs/general/concepts/dev-tokens#mock-respo...
- sovietmudkipz 3y agoTo be honest I do wonder if my fixation with local development is even justifiable. Looking around at projects and documentation I do get the sense that local dev is not a priority, and maybe that isn’t a bad thing. Amazing projects exist. Perhaps other game devs are more resourceful than I am and simply build, working around limitations. I do enjoy learning and this constraint requires I deeply learn. However there is an opportunity cost.