5 ms·

If you want to not hate your life building a real-time multiplayer game, fully embrace data oriented design. I took the gamble and picked Unity DOTS and NetCod

If you want to not hate your life building a real-time multiplayer game, fully embrace data oriented design. I took the gamble and picked Unity DOTS and NetCode for our current MOBA-esque game (not other packages, we bolt regular Unity visuals on much like the V in MVVM). Outside the headaches of using preview tech, it has been amazing what we have been able to do compared to regular OOP hell. By not having hidden game state lurking in classes, lambdas or coroutines, we have been able to hide much of the networking layer as an encapsulated set of glue systems that shuttle just enough data across the wire that the view-layer can present the game to the user. Movement and other prediction has been much easier too, because the game state is just data and not intertwined with behavior, I just run most of the same algorithms locally as I do on the server — AI, steering, etc. This technique still requires a lot of foresight and challenging architecture decisions of course. I forced our core gameplay logic to not know anything about the visuals, which has made some things harder. However when it came time to make a headless build with no graphics, it was as simple as flipping a switch. No changes in our gameplay code. I have a principal engineer from Sea of Thieves on my team, and he has also breathed huge sighs of relief working on this project. Unreal is the complete antithesis to this design pattern, and is full of hidden state, magic behavior, and heisenbugs.

karpierz 5y ago
Tangentially related, do you have any advice for moving into indie game development from a regular software engineering job at a big tech company?
- hesdeadjim 5y ago
  I’d suggest searching for this question on reddit’s /r/gamedev to hear a lot of perspectives. Mine? Don’t. By that I mean, and assuming you haven’t already, spend a few years making small games from start to finish. Pick games to copy, don’t even hold yourself to having a unique spin on things. The goal being to 1) practice for the real thing and 2) decide if you actually want to make games or just fantasize about doing so. The latter isn’t a judgement, I’ve almost left games twice because of the emotional burnout. For a point of reference, I spent two years getting up at 6am twice a week with a friend to gamejam and practice. All in prep to go indie. This was even after 6 years making games and leading two. The result? We almost failed completely. If I hadn’t decided to say fuck it and stick the game on PS4 for fun, we would have grossed a grand total of $100k for a year of work. The more depressing fact? $100k is considered a significant success for an indie game on Steam. Happy to provide more anecdotal experience around this if you like.
  - karpierz 5y ago
    Thanks for the grounding take; I'd appreciate hearing more about your experience if you wouldn't mind. Either here or offline if you'd rather not share publicly.
    - hesdeadjim 5y ago
      Sure hit me up on discord, hesdeadjim oh-eight-six-four.
- QuantumYeti 5y ago
  Take my cynical pov with a pinch of salt... I left (indie?) gamedev to get a normal job, and have been much better off both mentally and financially. In addition to what hesdeadjim said, I'd also like to add don't blindly accept the common gamedev maxims. For example, "Make the game YOU want to play" is repeated as good advice, but I haven't found it to be very useful. First off, if I'm working as the sole developer and have total control over design decisions, it's easier to follow that advice than if I'm working with multiple people who all play different genres of games. A lot of the time people will only use gamedev-jargon to back up their design decisions (immersion, positive feedback, vertical slices, etc), which are hard to argue about because they're so subjective and ill-defined. Also, keep in mind how many times Level 1 gets tested. At a certain point, no matter how excited I am about the game, I'm going to get sick of playing it. From that point on, I'm no longer developing a game I want to play. I'm developing a game I should want to play but don't (I think this adds a lot to burnout). Maybe start the project as a game you want to play, but make peace with the fact that it's ultimately not for you to enjoy playing. It's for the players. You're very likely going to be sick of the game by the time it ships. "Make it juicy" and "avoid premature optimizations" are more maxims with limited use, and are even contradictory in a lot of instances. For juice/polish: Focus on the core gameplay mechanics. Once those are set in stone, make them juicy if you want/have the time. A juicy boring game is still a boring game. For performance/optimization: If a core part of your game is having 10,000 enemies on the screen at once, you're going to have to make design decisions based on performance at the very beginning of development. Kinda related: I've shipped a game where at the beginning of development, I suggested using Multiple Render Targets (we were doing deferred rendering with the XNA Framework) to speed up the rendering (instead of rendering everything, switching render targets, rendering everything again, switching render targets, repeat...) but the lead dev took the "avoid premature optimizations" maxim to heart, and we ended up with a significantly hobbled final product on PS4s and lower-end PCs. I guess I could have gone into "crunch mode" and rewrote the entire rendering pipeline to make up for poor decisions at the start of the project, but I wasn't willing to do that. It was my dream to make games from the age of probably 13 to ~28. I'm 35 now, and am not all that interested in games any more. I enjoy doing "gamedev" as a hobby, because I've realized my preferred method of "playing" is to program little toys I can tinker with for a few hours and then abandon. I also have MDD, so YMMV. Best of luck, though.
- jiggawatts 5y ago
  Just to add to the chorus of similar comments: I fantasized about becoming a game developer in school. I had no allusions, I knew what that took. I studied linear algebra, wrote toy games on my own, and even took up physics at university so that I could learn things like optics and motion simulation. I got a job as a game developer, and I wrote a game engine. I was so burnt out and unhappy that I had to go on anti-depressants. Years later, some of the most fun I had was optimising financial reporting databases. Why? I dunno, it was just more fun somehow. It wasn't my dream, and I felt like I was that kid that wanted to become an astronaut and ended up in middle management at some megacorp. But you know what? Optimising queries uses the same skills as optimising a game engine! It's fun, and you get paid for it. You get immediate feedback from users, instead of complaining from entitled brats on forums two years later...
bob1029 5y ago
> If you want to not hate your life building a real-time multiplayer game, fully embrace data oriented design. I'd say if you want to not hate you life building any software, start with the data/schema/et. al. Before you open Visual Studio, open Excel and conference in your business stakeholders for a few design sessions. We recently started down a "data-driven" path with our B2B application. We went from ~90% of the application being code-based to ~95% of the application being configuration-driven in a matter of months. We can bootstrap an entire customer's setup by doing some simple JSON copypasta now. The best general model I have found so far would be to declare a global Domain type, and then put a List<T>/T of each constituent domain type within it. No nesting of complex types (reference types) should be permitted. All properties in the domain model types can map cleanly to/from SQL tables. The overall schema should be in 3NF/BCNF/DKNF. Relation types will be required. You can trivially serialize instances of the Domain type for whatever purpose. Each serialized copy of the Domain type can be thought of as a deterministic snapshot of all state, assuming you did everything correctly elsewhere. Use of language features such as LINQ can make this approach almost fun to work with. A clean, well-managed schema is the most powerful tool in your box when dealing with complex problem domains.
- lostmsu 5y ago
  > We can bootstrap an entire customer's setup by doing some simple JSON copypasta now. This read badly. Why is JSON in the picture?
  - bob1029 5y ago
    Because with this model, it's a 1-liner to take an instance of our entire domain to/from a byte array. In situations where we have "bad things" happen, we can simply dump the entire domain instance to disk and then reload it on a dev machine.

karpierz 5y ago

Tangentially related, do you have any advice for moving into indie game development from a regular software engineering job at a big tech company?

hesdeadjim 5y ago
I’d suggest searching for this question on reddit’s /r/gamedev to hear a lot of perspectives. Mine? Don’t. By that I mean, and assuming you haven’t already, spend a few years making small games from start to finish. Pick games to copy, don’t even hold yourself to having a unique spin on things. The goal being to 1) practice for the real thing and 2) decide if you actually want to make games or just fantasize about doing so. The latter isn’t a judgement, I’ve almost left games twice because of the emotional burnout. For a point of reference, I spent two years getting up at 6am twice a week with a friend to gamejam and practice. All in prep to go indie. This was even after 6 years making games and leading two. The result? We almost failed completely. If I hadn’t decided to say fuck it and stick the game on PS4 for fun, we would have grossed a grand total of $100k for a year of work. The more depressing fact? $100k is considered a significant success for an indie game on Steam. Happy to provide more anecdotal experience around this if you like.
- karpierz 5y ago
  Thanks for the grounding take; I'd appreciate hearing more about your experience if you wouldn't mind. Either here or offline if you'd rather not share publicly.
  - hesdeadjim 5y ago
    Sure hit me up on discord, hesdeadjim oh-eight-six-four.
QuantumYeti 5y ago
Take my cynical pov with a pinch of salt... I left (indie?) gamedev to get a normal job, and have been much better off both mentally and financially. In addition to what hesdeadjim said, I'd also like to add don't blindly accept the common gamedev maxims. For example, "Make the game YOU want to play" is repeated as good advice, but I haven't found it to be very useful. First off, if I'm working as the sole developer and have total control over design decisions, it's easier to follow that advice than if I'm working with multiple people who all play different genres of games. A lot of the time people will only use gamedev-jargon to back up their design decisions (immersion, positive feedback, vertical slices, etc), which are hard to argue about because they're so subjective and ill-defined. Also, keep in mind how many times Level 1 gets tested. At a certain point, no matter how excited I am about the game, I'm going to get sick of playing it. From that point on, I'm no longer developing a game I want to play. I'm developing a game I should want to play but don't (I think this adds a lot to burnout). Maybe start the project as a game you want to play, but make peace with the fact that it's ultimately not for you to enjoy playing. It's for the players. You're very likely going to be sick of the game by the time it ships. "Make it juicy" and "avoid premature optimizations" are more maxims with limited use, and are even contradictory in a lot of instances. For juice/polish: Focus on the core gameplay mechanics. Once those are set in stone, make them juicy if you want/have the time. A juicy boring game is still a boring game. For performance/optimization: If a core part of your game is having 10,000 enemies on the screen at once, you're going to have to make design decisions based on performance at the very beginning of development. Kinda related: I've shipped a game where at the beginning of development, I suggested using Multiple Render Targets (we were doing deferred rendering with the XNA Framework) to speed up the rendering (instead of rendering everything, switching render targets, rendering everything again, switching render targets, repeat...) but the lead dev took the "avoid premature optimizations" maxim to heart, and we ended up with a significantly hobbled final product on PS4s and lower-end PCs. I guess I could have gone into "crunch mode" and rewrote the entire rendering pipeline to make up for poor decisions at the start of the project, but I wasn't willing to do that. It was my dream to make games from the age of probably 13 to ~28. I'm 35 now, and am not all that interested in games any more. I enjoy doing "gamedev" as a hobby, because I've realized my preferred method of "playing" is to program little toys I can tinker with for a few hours and then abandon. I also have MDD, so YMMV. Best of luck, though.
jiggawatts 5y ago
Just to add to the chorus of similar comments: I fantasized about becoming a game developer in school. I had no allusions, I knew what that took. I studied linear algebra, wrote toy games on my own, and even took up physics at university so that I could learn things like optics and motion simulation. I got a job as a game developer, and I wrote a game engine. I was so burnt out and unhappy that I had to go on anti-depressants. Years later, some of the most fun I had was optimising financial reporting databases. Why? I dunno, it was just more fun somehow. It wasn't my dream, and I felt like I was that kid that wanted to become an astronaut and ended up in middle management at some megacorp. But you know what? Optimising queries uses the same skills as optimising a game engine! It's fun, and you get paid for it. You get immediate feedback from users, instead of complaining from entitled brats on forums two years later...

bob1029 5y ago

> If you want to not hate your life building a real-time multiplayer game, fully embrace data oriented design. I'd say if you want to not hate you life building any software, start with the data/schema/et. al. Before you open Visual Studio, open Excel and conference in your business stakeholders for a few design sessions. We recently started down a "data-driven" path with our B2B application. We went from ~90% of the application being code-based to ~95% of the application being configuration-driven in a matter of months. We can bootstrap an entire customer's setup by doing some simple JSON copypasta now. The best general model I have found so far would be to declare a global Domain type, and then put a List<T>/T of each constituent domain type within it. No nesting of complex types (reference types) should be permitted. All properties in the domain model types can map cleanly to/from SQL tables. The overall schema should be in 3NF/BCNF/DKNF. Relation types will be required. You can trivially serialize instances of the Domain type for whatever purpose. Each serialized copy of the Domain type can be thought of as a deterministic snapshot of all state, assuming you did everything correctly elsewhere. Use of language features such as LINQ can make this approach almost fun to work with. A clean, well-managed schema is the most powerful tool in your box when dealing with complex problem domains.

lostmsu 5y ago
> We can bootstrap an entire customer's setup by doing some simple JSON copypasta now. This read badly. Why is JSON in the picture?
- bob1029 5y ago
  Because with this model, it's a 1-liner to take an instance of our entire domain to/from a byte array. In situations where we have "bad things" happen, we can simply dump the entire domain instance to disk and then reload it on a dev machine.