Chat system

shawnmccarthy
edited August 2010 in Photon Server
I'm curious how many Photon server developers have developed a custom chat system and their high level approach (think Mmo chat - Player to Player, Player to Alliance, System messages, etc).

I was considering basing a chat system on the MmoRadar implementation (minus the items), but this may be a little overkill, and I believe some of you have already found what works best.

Basically I'm just looking at from a high level how other users are implementing this type of system within the core Photon logic.

My high-level thoughts:
1) Implement an MmoChat object with a new messagechannel similar to the MmoRadar
2) Attach the MmoChat object to the MmoWorld
3) Have the peers subscribe to this message channel (similar to an OnRadarSubscribe, but OnChatSubscribe)

Thanks for your time.

Comments

  • I see three different cases
    1) Private messages (player to player)
    2) Player to everyone near
    3) Player to a group that is not visible

    Number 1: Send the chat event to the target item (avatar) owner.
    Number 2: Send the chat event through the own avatar item event channel (to all subscribers).
    Number 3: Extra channel as you suggest.. or if you want to reuse an existing mechanism - a special "chat Item" that is located outside of the world dimensions. To join the chat channel the player subscribes to the chat item manually (operation subscribeItem). Then publish chat events with the item event channel. In general it's similar to using an extra channel, maybe easier to implement or understand (or maybe not, that really depends on the developer).
  • Thanks Boris
  • wouldn't 3) become a pretty massive problem with distinct channels, in relation to the masses of channels (and related ids) that for party chat / guild chats would be in use, especially in relation to the byte identifier?
    Routing items on the other hand would be slightly slower but not have any such restrictions.
  • dreamora wrote:
    wouldn't 3) become a pretty massive problem with distinct channels, in relation to the masses of channels (and related ids) that for party chat / guild chats would be in use, especially in relation to the byte identifier?
    Every world region (grid cell) is a channel, too - so we already have masses of channels, what problem do you anticipate?
    Which byte identifiers are you referring to?
    dreamora wrote:
    Routing items on the other hand would be slightly slower but not have any such restrictions.
    Where do you see the performance loss?
    An Item has:
    - an event channel,
    - a dispose channel
    - a fiber.
    - a position and a position channel
    The event channel is obviously needed and would be the used anyway.
    The dispose channel can be useful if the chat channel can be closed, e.g. for temporary dungeon parties.
    The fiber is needed if you want to bring chat messages into a distinct order or to track who participates.
    The position and position channel is only needed if you decide to auto-subscribe a chat channel when you come near, like a radio tower.
    The counter part - the interest area - is a collection of subscriptions, which you would need for chat channels, too.
    So depending on your requirements there may be 2 channels, a position and a fiber per chat channel overhead- and of course the wrapping Item object itself. Is the memory allocation where you see the slight performance loss? That would happen just once per chat channel.
  • The byte identifiers I'm referring to are the channel identifiers to send the events to.

    Thats what I assumed you would have in mind for using, not?
    In that case the restriction to 256 channels would be a pretty massive problem

    If not then I missunderstood your channel idea.
  • Oh - you are talking about enet channels, right? They are unrelated to what I'm suggesting.
    I was suggesting to use the Channel class from the ExitGames.Concurrency namespace...
  • D'OH!
    No idea how I dropped that out of my head after reading it just to drift over to enet channels ...

    Was likely too deep in enet channel related stuff due to a current "quick and dirty" prototype implementation for a customer with Photon Lite.