Sign in to follow this  

Alternative to subscribing for ORPGS?

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am using a subscription based interaction system for NPCs and PCs in a simple online rpg. This system seems far better than anything I can imagine - is this really true? In case I am not using the correct term, this is my general design: Subscribe PCs to nearby NPCs and other nearby PCs. Subscribe NPCs to nearby PCs. Update subscribed list every X interval. Every move/attack/etc will send to the list of subscribed PCs. Game ONLY updates the list of NPCs subscribed to the players. I cant really find any downsides, so I am trying to see what are other alternatives to this method that are effective?

Share this post


Link to post
Share on other sites
Quote:
Original post by Crazyfool
Game ONLY updates the list of NPCs subscribed to the players.


Depending on your game design, you may need some NPC's to update even when they aren't near to players. For example, if a particular NPC in your game is expected to travel between two points independently of the players your stated design won't allow them to do that.

Share this post


Link to post
Share on other sites
Quote:
Original post by Crazyfool
I cant really find any downsides, so I am trying to see what are other alternatives to this method that are effective?


You could just check for each event as it comes in, instead of maintaining explicit subscription lists. You're going to do a degree of that anyway (eg. private comms or trades between 2 people shouldn't generate events on other nearby PCs, even if that nearby PC would be subscribing to their emotes, movements, etc), so in theory you can extend it to all events. The issue is how to keep it efficient, since you can't reasonably check every player against every other player on the server each time you want to see whether to notify them of something. I can think of ways, but they get a bit complex. Your original idea is usually fine.

Share this post


Link to post
Share on other sites
There's generally 3 types of events:
- Broadcast (send, let anyone interested hear about it)
- Multicast (a managed list of interested peers based on some criteria)
- Unicast (send to a specific or multiple targets)

Broadcast says: CreatureSpawned(x, y, ...). All managers will receive it. Player manager will find all players that are in range of new spawn, and it will add players in range to the new creature's multicast subscriptions (update state, creature died, etc).

For direct actions, such as trades, you use unicast. These aren't events, but remote triggers. When you need to do something, you trigger something on remote entity.

First two are passive - you fire an event: forest.sendEvent( TreeFellDown ); If nobody is around, it still happened, just nobody heard it, but you don't care about that.

Unicasts are pro-active: You do something directly on something.

Broadcasts and multicasts can be refined or generalized depending on the need, perhaps there's no need to separate the two, or you want to have broadcast-type events organized by category.

But these are the general types of interaction you can have.

With events, you also rarely explicitly manage subscriptions. For example, when an object is destroyed, it unsubscribes itself. When a creature dies, all listeners will unsubscribe themselves from the corpse.

For movement, unsubscription is easy - when an object moves, scan all subscriptions, check range, unsubscribe those too far. To scan for new subscriptions, you need to scan the world, which can be considerably more expensive.

You can also attach range to events. For combat events, you only want to notify those close, for state changes you update always, for chat, you choose range based on whether /whisper, /say or /yell was used - but you only send event to the actor's subscribers.

Share this post


Link to post
Share on other sites

This topic is 3626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this