Pub/Sub for game Servers... Are you?

Started by
20 comments, last by Septopus 5 years, 5 months ago

@Hodgman I think I'm making some more sense out of your link today.. still not sure, but I think you're trying to say that I should be weary of the overhead I'm creating..  Make sure that my solutions aren't creating more problems.. that kind of thing..  Gotcha.

I think I'm smelling your fire. ;) 

I get that any change from a "single threaded" approach to anything WILL add overhead.  I've accepted that fact.  I'm designing my system without a "central simulation" because the overhead of splitting that kind of mechanism into many different parts would be almost impossible for me to engineer around.  Instead of the single central simulation, there will be many nodes on the network that can interact with players in real-time.  The clients will be the physics processors and collision detectors.  The servers will orchestrate synchronizing the interactions between game entities and make corrections to game entities that risk breaking the illusion of multi-player interactions.

My game/system is a different kind of thing.  I'm not just trying to mimic or improve on existing systems/methods, I'm trying to engineer a different one.

And I'm probably a bit naive in some of my approaches, and that's fine too, because I'm learning lots, and it doesn't take me long to re-gear when things don't test out the way I'd like. ;)

Advertisement
Quote

My point is, implementation possibilities change month to month these days. 

I think you don't have enough experience yet to realize that, the more things change, the more they stay the same.

Yes, Redis wasn't available in 2010. But, you know what? Redis can't magically do something that code written in 2010 couldn't. You had to do a little more yourself, but given the primitives available in Erlang, not a lot more. And the solution in Erlang scales horizontally with adding more nodes, whereas Redis does not (Redis Cluster is a joke, technically speaking.) (Yes, you can do application-level sharding for particular use cases.)

Quote

My game/system is a different kind of thing.  I'm not just trying to mimic or improve on existing systems/methods, I'm trying

 to engineer a different one.

If you have a specific kind of game that you want to build, with specific use cases and requirements that aren't met by existing technology, you may be on to something!

If you're just trying to "build a system," without any kind of strong evolutionary pressure on the features and implementation of that system, then experience (not just mine!) says you won't build something that's all that useful. The reason is that many billions of dollars, and tens of thousands of man years are spent on networked games every year, and the market will already have explored most implementation nooks and crannies for the kinds of games that have already been generally funded and delivered. It doesn't matter if it's games, financial trading, car maintenance or movie production -- if there's already a large market, and you don't really have a very specific use case that's not currently served by the market, then you're quite likely not going to make something successful.

Or to put it another way: Do things differently, is not particularly compelling and generally don't build successful projects. Do different things, is where it's possible to truly innovate and push the envelope of what's possible. And sometimes, you need to do things differently to be able to do the different things, but it's the different things that are the reason you win.

That being said, building systems is fun and educational. As long as you learn the right lessons, and draw the right conclusions, testing a bunch of things and pushing them until they break is always a good way of gaining more experience. After all, good choices come from experience, and experience comes from bad choices ?

 

enum Bool { True, False, FileNotFound };

Those are song lyrics man, not reality.. ;)  Everything changes except human perception.  We're keying in here on a long standing rivalry between Systems guys and Coders I think..  Every coder I've known takes your perspective on this..  And every network/server guy I've known thinks y'all are crazy.  It seems as though coders like to behave like the changes in the hardware never really make any difference because their code never really has to change significantly.  Just because it doesn't HAVE to change significantly, doesn't mean it couldn't become something better in it's newer environment if it did.

You keep snagging on Redis, I don't think I'm using it how you think I'm using it, it I think.  I was considering possibilities for it, earlier on, that proved not to be feasible.  Documentation is very helpful.  It's just my database man, and a WICKED fast one! :D

Aside from that, yes.  I'm building the system to fit the game I'm making.  The game I'm making will be different.  But I think it also has potential to be a platform for more different games. 

Possibly even done differently. ...  No, certainly done differently.

You might be pushing me into a Slogan here! :D  hahaha

This topic is closed to new replies.

Advertisement