Comments by "p11" (@porky1118) on "Getting Started With Microservices" video.

  1. How can this be applied to gamedev? Most things can't be independently deployable. Especially things, you would put into a library, like a physics or render engine, or more important your math stuff. But you could put the rendering and the physics of a specific game into different microservices for example. Not sure, if that counts. But both could be independantly deployable. You could test the game rendering by sending the game state to it, where which object moves and how they change, which objects get destroyed or created, if a new scene is loaded, etc. You could even use it for different games, which use different physics or no physics at all, as long as the rendered objects stay the same. Or you could test the game physics by using a very minimalistic renderer, or just outputting the expected positions. You could run the game with many different renderers, maybe some minimalistic 2D one or some realistic 3D one, or some surreal style. That's basically how I tried to make some game I made less coupled. But I'm not really happy with it. They use the same base code, some shared structs which are used by both services. But both services include most of the same structs, only cleaned up. For example balls in the renderer don't contain the speed, and balls in the physics don't contain the color. So it's kind of code duplication. I created a library for both "services", so I still have to add some code to really make it run. I basically just have to define how the communication works. I can use both libraries and just move data around inside the application to create a standalone. Or I use only one of these libraries to write to and read from a tcp stream and create a client and server this way. I like the basic design, but I'm not happy with the specifics. What I also can think of is packing menus and the real game or each different part of the game into a single application, and then add a meta application, which just selects the next application.
    1
  2. 1