Comment by skydhash

> So that made me realize, a function is not really a sensible unit of analysis. They're too isolated. You want to try and understand a feature

The central element of code, IMO, is data. Where it comes from, where it goes to, and how it transforms. Whatever your paradigm (imperative, OOP, functional, relational,…), you need to design your data model first and its shapes through the stage of its lifecycle.

Once you isolate some part of the data, what I do next is to essentially create subsystems that will provide behavior. That’s the same idea as the entity component system. It’s also found in Clean Architecture (data is the core entities, uses cases are entities behavior, and everything else are subsystems) and DDD.

In your example, the netcode should be focused on state replication mechanisms, not the state itself. The state being replicated should be managed by the bullet entity, which is a core part of the game.

Such separation of mechanisms (subsytems) and policy (core logic) is a very good way of keeping cost of changes down.