search

bkconrad / wasabi

MIT License
31 stars 1 forks source link

partitioning/scoping improvement idea #21

Closed mreinstein closed 10 years ago

mreinstein commented 10 years ago

It would be really nice if there were a way to specify visibility groups, and only client and objects within a given group are visible. For larger simulations this would really be helpful, rather than having to specify a callback at connection time. It also opens up the possibility to dynamically change group membership more easily.

bkconrad commented 10 years ago

@mreinstein I really like this idea, the API I'm imagining is something like:

var group = Wasabi.createGroup();
group.addObject(obj);
conn.addGroup(group);

Then, during processConnections(), both the scope callback and the group list are checked, and any objects found in the group or the scope result are sent. I think this might address the vast majority of use cases for scope callbacks (an idea I stole from an old network library), so I might even replace scope callbacks with this.

Am I understanding you correctly, and do you have any improvements on that?

mreinstein commented 10 years ago

the API I'm imagining is something like

Yeah that seems pretty reasonable. I think the key thing is that there's a way to associate objects with group(s), and adding/removing groups from connections.

As a usage example: in my game, you control a spaceship and warp between sectors of the galaxy. Each time you warp your ship you join a group for the sector, and leave the old sector's group.

mreinstein commented 10 years ago

@kaen I've read all the code in this repo, I could take a stab at implementing that grouping functionality if you haven't already started. I didn't want to do this if you were already working on it, but if not I'm happy to send a PR for this grouping. thoughts?

bkconrad commented 10 years ago

Here's my first implementation @ 08a0f23820ec897fe036dad4e009ba622d326efe

Let me know what you think of the API (and if it fixes your scoping troubles)

mreinstein commented 10 years ago

nice! One thing I noticed though, doesn't look like you committed group.js

mreinstein commented 10 years ago

@kaen one thing to note: you're breaking the API. I'd recommend either changing the implementation to deprecate the scope functionality (but keep it around) or bump the major package number. According to semver any time you change a public api in a way that is backwards incompatible the major revision number has to go up (e.g., 0.1.14 goes to 1.0.0.)

IMO it'd be better to break the API as infrequently as possible.

bkconrad commented 10 years ago

That makes sense. The API is really unstable, but this is the only part that (I think) will be broken for a while now. At any rate, version numbers are cheap so I don't really mind burning through them for the purpose of semantics.

Thanks for the tip, I have to change my mindset a bit since I released it publicly.

mreinstein commented 10 years ago

a great read, and pretty short http://semver.org

Important because the strength of npm's modularity is partially from the expectation that modules follow this contract where the version number actually tells you API stability. For example if I declare "wasabi" : "0.x.x" in my package.json I can safely rely on being able to update wasabi without worrying about my code breaking due to API changes, as long as the module follows the semver contract.