Party Finder Notification

[Yshnal]

It was mentioned already that doing what you suggest in the OP would cause much server stress, so they went with that simple implementation and will monitor servers to see if they can improve it at a later time.

[DSN]

It was mentioned already that doing what you suggest in the OP would cause much server stress, so they went with that simple implementation and will monitor servers to see if they can improve it at a later time.

Not true unless you dont know what you are doing

[Yshnal]

Not true unless you dont know what you are doing

Explanation below:

Can you add some sort of feature where we can select what content we would like to do and then there is a notification when someone creates a party for it? For example, if I want to fight Ifrit, I can check a box on the list and when someone starts a party in Party Finder for Ifrit I would receive a notification.

The notification feature that is to be added in patch 2.16 is an extremely simple message that displays the number of recruiting parties every 15 minutes.

By only notifying the number of new parties and sending this to all players, the stress on the server would be minimal.
*On the client side, you can hide this notification, so that it won't appear in the chat log.

This feature alone should be sufficient enough to prompt you to check the party finder list, instead of having to open the party finder window to check if there are any new parties gathering.

However, from a player's perspective, the requested feature is useful and it would definitely be convenient to have this.

The problem with this, as usual, is server stress.

To implement the requested feature, the following is a rough idea of the data and processes that would have to be added.

1. Expand the party finder server so that players can register content they wish to participate in and be notified when it appears.
   
   Add server memory.
   
   Make it possible for each player on each World to register (roughly a max of 5,000 players).
   *With the implementation of the feature in 2.16, this memory is not needed.
   
   
2. Make the party finder feature server execute the notification process at either of the below timings:
   

   a. When the notification list is updated in #1 (possible for 5,000 people to update this whenever they like).
   b. When a new party recruitment is registered.

   To give a breakdown of the notification process, all of the newest notification list registrations and all of the newest parties that are recruiting would be compared, and then the system would determine to which character and for which recruitment a notification should be made, and this process would involve sending out notifications to each character on an individual basis.

Therefore, compared to the previously mentioned feature planned for patch 2.16, memory would be needed to perform this process on the server side, and due to the fact that the processing load would significantly increase, countermeasures would be necessary to disperse the load (which could potentially involve enhancing the actual servers). As a result, this would drive up the time needed for implementation as well as the work needed to ensure stable operation.

Due to the above reasons, we will be pushing out smaller-scale changes to features that can be accomplished with a small amount of server stress and bit-by-bit improve their convenience. As for features that run large risks of server stress, we will continue to look into everyone's requests and see if we can implement them in some way as operation of the game moves forward and the conditions change.

http://forum.square-enix.com/ffxiv/t...=1#post1829032

[DSN]

Over complicating something does not make a good solution, there is no I need to perform all this analysis.

The desire to make the server do and be the final end for everything is not good practice.
Read about collision detection in online gaming, there is a reason the majority of the market has scenarios where the client wins because it doesn't matter what the server sees if it is not accurately portrayed to the clients (I shot him why did it miss?, I dodged that why did I get hit)

Here is how pub / sub works. You subscribe to a queue, when an event occurs that affects members of that queue you fire a message to members of the queue.

Real world example:

I want to run Ifrit Extreme. I mark notify me of new groups for Ifrit EX.
On the backend I am put in the queue Ifrit Ex
Someone Creates a party for Ifrit Ex
This triggers an event to notify users in the queue Ifrit EX

What does this take to process?
Sending a message

What great analysis needs to be done to accomplish this?
None

How do you deal with 5000 people wanting to run the same content?
You create sub queues based on data centers, languages, or abitrary max limits for queues (If queue A has 200 members create queue A.2 and start putting new users in here using LRU and FIFO)

How much data is required to process this data?
This could be accomplish this with a small JSON message {queue: 'ifrit ex', count: 20} which could trigger the message client side "There are {count} groups in Party finder for {queue}" or "A new group for {queue} has been created in the party finder". You could even put the rate limiting on the client side as to not repeat messages to frequently by adding a timestamp to the messages.

But what about the servers?
Look websites do this all day everyday, if the servers powering this game cant do what a basic Ajax website can handle something is very wrong here. The queues should be per data center and should be a system that sits besides current infrastructure in an SOA architecture, it should also be resilient to the point where if this should fall down and crash it does not impact normal game play as it is again not a part of the main servers running instances, zones, etc.

None of this is not hard to accomplish.