@hidden world mechanics kind of defy structure. I suspect if you spent a bunch of time making an elegant structured solution, down the road you want to add something and realize you have to unwind your elegant solution and make a new one.
or you can just make a big unstructured mess and it's easy to add things even if it causes maintenance problems down the road.
@i@hidden where do you learn this, every guide and book seems to assume you're a beginner and is just about how to move something around a screen, not how to write a complete networked game backend.
@Moon@hidden game devs have come up with as many standardized abstractions as any other field, you just have to read and live through them, be it MVC or ECS
it never gets easier though, even with decades of volumes written down, since few ever read them in modern times
@Moon@hidden mmo's are like the first big thing you don't write, you take a hard thing, and then introduce untrusted network calls on top of that, it always goes badly
so you go to the trenches, and borrow all the game programming gems and see which chapters cover the problems you're facing each one is gonna have a big ass section with people talking over all the common networking and multiplayer woes and how they've dealt with them https://archive.org/search?query=Game+programming+gems
@Arwalk I am making a really simple thing so it's probably not bad I didn't use one but if I make something more complex I should look. Right now I have a little character that can walk around onscreen and it synchronizes location with a backend server, and if you disconnect and reconnect it puts you back where you were. it's all hacked together.
@Moon Tbh I have never done any game programming, I hate anything related to making stuff appear and move on the screen. But from what I know, ecs makes it easy to have different elements loosely coupled.
@Arwalk@Moon loose coupling is a blessing and a curse. It's probably the best option we have, but used incorrectly it causes update order to be very very hard to control and maintain, leading to a lot of subtle bugs that are very common in unity games. Unity encourages absolutely horrible design in all of its documentation. It especially encourages variable time step which is something professionals have known not to do since the 90s.
@RustyCrab@Arwalk this is kind of what I was thinking of but didn't know how to express. there's the world relationship code and there's the code that is responsible for cause and effect
@RustyCrab@Arwalk I just had a realization while coding the thing this morning that there aren't shortcuts probably. I thougth of the time I was training a new employee. He got assigned a task and asked me how to do it. I explained the process and he said "uh, that's a lot of work" and I said "yes, you are here to work".
@Moon@Arwalk it's best to avoid falling into the trap of trying to explicitly express cause and effect as code. Usually the way it works is you want to have a set of mechanics defined on actors and the real science behind the game is how those mechanics happen to interact with each other. Eg: you don't program hotboxes colliding together explicitly, you say "my actor has a set of hithoxes that applies some effect to whatever it touches" and the enemy actor will normally handle the hit reaction himself.
@RustyCrab@Arwalk incidentally that's basically what I am doing. I am working through how to sync the state to my backend so it can be shared among multipe players. I have dug myself into a hole probably haha
@Moon@Arwalk it is, especially when network stuff gets involved. All of netcode programming is trying to deal with the fact that the server is in the future and both clients are in the "past". If you display the past perfectly that means the players will experience extreme latency and laggy input. That means you have to predict the future on client side somehow. Then both players are living in a slightly different version of reality for some fraction of a second and the server has to decide who is right about what aspects. How this is resolved highly depends on the game mechanics and what is least disruptive to the experience. Eg: delay/interp netcode is great for hitscan and bad for melee. Rollback is best for melee but is almost impossible to code if you are not experienced with it.
@RustyCrab@Arwalk bookmarked to read tonight, thanks. right now I'm using a tcp websocket, I figure if it's good enough for minecraft I don't need udp.
@RustyCrab@Arwalk literally just moving around a small 2d map at a walking pace! when I've got it synching everyone in a room I'll share it and see how it works with multiple players.
@Moon@Arwalk should probably be fine then. If clients are authoritative (leaves you open to cheating but much simpler than server authoritative) then your players will see themselves moving slowly but more likely than not other players will stutter significantly. You can use an interp method ad described in the paper to avoid that most of the time but TCP will make it harder.
@RustyCrab@Arwalk my motion right now is slow enough that on the backend I should be able to detect if a step is skipped and can put them back or punish them.