5 deleted 14 characters in body
source | link

UPDATE

Now I'm trying to implement 2-a in such way:

UPDATE

Now I'm trying to implement 2-a in such way:

Now I'm trying to implement 2-a in such way:

4 added 6 characters in body
source | link

But where do timers go? Should I have additional Update method on MatchingRoomBase which returns"finalizes" all createdtimed-out rooms? [I would prefer to avoid events here because they lead to frequent dynamic adding/removing subscriptions (with CloneEmpty) which can affect performance.] But what if one user gets registered in two rooms and both timeout at the same Update pass?

But where do timers go? Should I have additional Update method on MatchingRoomBase which returns all created rooms? [I would prefer to avoid events here because they lead to frequent dynamic adding/removing subscriptions (with CloneEmpty) which can affect performance.] But what if one user gets registered in two rooms and both timeout at the same Update pass?

But where do timers go? Should I have additional Update method on MatchingRoomBase which "finalizes" all timed-out rooms? [I would prefer to avoid events here because they lead to frequent dynamic adding/removing subscriptions (with CloneEmpty) which can affect performance.] But what if one user gets registered in two rooms and both timeout at the same Update pass?

3 added 10 characters in body
source | link

Then I can have intermediate rooms like decorators (e.g. GameModeDecorator should forward calls only for specific game mode requests) and "multi room" nodes (e.g. ServerSplitNode should call RegisterAndTryMatch on each of room in the internal list [of requested prefered servers] until any returns not null result). A user can be added to multiple rooms simultanously but when he gets matched the system should invoke TryUnregister to remove him from the whole hierarchy.

Then I can have intermediate rooms like decorators (e.g. GameModeDecorator should forward calls only for specific game mode requests) and "multi room" nodes (e.g. ServerSplitNode should call RegisterAndTryMatch on each of room in the internal list [of prefered servers] until any returns not null result). A user can be added to multiple rooms simultanously but when he gets matched the system should invoke TryUnregister to remove him from the whole hierarchy.

Then I can have intermediate rooms like decorators (e.g. GameModeDecorator should forward calls only for specific game mode requests) and "multi room" nodes (e.g. ServerSplitNode should call RegisterAndTryMatch on each of room in the internal list [of requested prefered servers] until any returns not null result). A user can be added to multiple rooms simultanously but when he gets matched the system should invoke TryUnregister to remove him from the whole hierarchy.

2 added code example for 2-a
source | link
1
source | link