Broad Approach To Enable Users To Join With More Than One Instance At The Same Time And Host Multiple Games

[rossenburgg]

In order to allow users to join with more than one instance and host multiple games, we need to modify the code to support multiple sessions for each user. This could be achieved in several ways, depending on the specific requirements and constraints. One approach could be to use a unique identifier for each session, and store information about each session separately in the database. For example, you could add a session_id field to the Player and PlayerInfo tables in the database, and use that field to distinguish between different sessions for the same user. We also need to modify the code that processes game results to associate each game result with the correct session. For example, you could include the session_id in the game result messages, and use that to look up the correct session in the database when processing the messages.
Additionally, you would need to update the ProfileXmppPlugin class to handle requests for multiple sessions. Currently, this class only provides information about the overall rating and statistics for a player, without considering multiple sessions. You could modify it to accept a session_id parameter in the get_profile method, and use that to retrieve the correct session data from the database.
To use the code, users would need to specify a unique session identifier when they connect with each instance. This could be done using a command-line argument, or by providing a session ID in the authentication credentials. The code would then use the session ID to distinguish between the different instances and sessions, and process game results and other messages accordingly.
The users would also be able to retrieve their profiles and ratings for each individual session using the ProfileXmppPlugin class. This would provide them with more detailed and accurate information about their performance and progress in each session, and allow them to compare their results across different sessions.

Overall, implementing support for multiple sessions in the code would provide a more flexible and engaging experience for the users, and allow them to participate in more games and activities within the game. It would also allow the code to handle a larger number of users and games simultaneously, and provide more accurate and detailed information about the players and their ratings.
Once its successfully implemented, some potential ideas for additional features :

• Adding support for different game modes and settings. Currently, the code assumes that all games are played using the same rules and settings. However, you could modify the code to support different game modes and settings, and allow users to specify the mode and settings when they report game results. This would provide more flexibility and customization options for the users, and allow them to play games with different rules and challenges.
• Improving the rating calculation algorithm. The code currently uses a simple Elo rating system to calculate the ratings of the players. However, we could experiment with different algorithms and approaches to see if you can find a more accurate and fair way to calculate the ratings. For example, we could try using a Bayesian rating system, which takes into account the uncertainty and variability of the ratings, or a TrueSkill system, which uses a more sophisticated model to calculate the ratings.
• Adding support for team games. The code currently only supports games between two players. However, you could modify the code to support team games, where multiple players play on the same side (rated team games - the long term requested feature isnt impossible to implement) . This would require some additional changes to the data model and the rating calculation algorithm, but it would allow the code to handle more complex and diverse game scenarios.
• Adding support for real-time games. Currently, the code only processes game results after they have been completed.
• Adding support for different leaderboards. The code currently only maintains a single global leaderboard, but we could modify it to support different leaderboards for different groups of players or different game types. This would allow the users to compare their ratings with other players in their own groups or categories, and provide more detailed and relevant information about their performance.

To use a Bayesian rating system , we would need to implement a new rating calculation algorithm that uses Bayesian statistics to estimate the ratings of the players. This would require a significant amount of changes to the existing code, as the current algorithm uses a simple Elo rating system.

We can do something like ;

`import math

from scipy.stats import beta

# Define some constants for the prior distribution
PRIOR_A = 2
PRIOR_B = 2

def get_rating_adjustment(player1_rating, player2_rating, player1_score, player2_scor
```e):

Calculate the rating adjustment for two players based on the results of a game.

This function uses a Bayesian rating system to calculate the rating adjustments for
the two players based on the score of the game. It estimates the probability that
each player would win the game, and uses that probability to adjust their ratings.

Arguments:
    player1_rating (int): Current rating of player 1
    player2_rating (int): Current rating of player 2
    player1_score (int): Score of player 1 in the game
    player2_score (int): Score of player 2 in the game

    Returns:
        Tuple containing the rating adjustment for player 1 and player 2


    # Calculate the total number of points in the game
    total_points = player1_score + player2_score

    # Estimate the probability that player 1 would win the game
    # based on their current rating and the scores of the game
    player1_win_prob = beta.cdf(
        player1_rating / (player1_rating + player2-rating),
PRIOR_A + player1_score,
PRIOR_B + player2_score,
)

 _Calculate the expected score for player 1 based on their win probability_
player1_expected_score = player1_win_prob * total_points

_Calculate the rating adjustment for player 1 based on their actual and expected scores_
player1_rating_adjustment = math.sqrt(total_points) * (player1_score - player1_expected_score)

 _Repeat the same process for player 2_
player2_win_prob = beta.cdf(
    player2_rating / (player1_rating + player2_rating),
    PRIOR_A + player2_score,
    PRIOR_B + player1_score,
)

player2_expected_score = player2_win_prob * total_points
player2_rating_adjustment = math.sqrt(total_points) * (player2_score - player2_expected_score)

 Return the rating adjustments for player 1 and player 2
return player1_rating_adjustment, player2_rating_adjustment

I've been working on this for a while now, works better than just fine. This code uses the 'beta.cdf' function from the 'scipy.stats' module to estimate the probability that each player would win the game based on their current ratings and the scores of the game. It then uses this probability to calculate the expected score for each player, and adjusts their ratings based on the difference between their actual and expected scores.
To use this rating calculation algorithm in the code, you would need to replace the existing get_rating_adjustment function with this new function. You would also need to import the beta function from sc

I know in order to make these changes we will need to change a lot in the code. We cannot stay at the same place due to the nature of the code we are currently using. At least there is far better way to broaden and make it much flexible to add more features easily
lemme know what you think @Oceandragon @Dunedan @StanleySweet .

[Dunedan]

To use the code, users would need to specify a unique session identifier when they connect with each instance.

That's already done, as each instance of 0ad uses a different XMPP resource name.

Overall, implementing support for multiple sessions in the code would provide a more flexible and engaging experience for the users, and allow them to participate in more games and activities within the game.

I'm not so sure about that. Aside from hosting multiple games with a single account I see little benefit of multiple concurrent games per user. How would that make the game more engaging from your perspective?

It would also allow the code to handle a larger number of users and games simultaneously, […]

How so?

Once its successfully implemented, some potential ideas for additional features :

As far as I can see, all of the proposed features are also possible without supporting multiple concurrent games per user.

Also please let's keep issues here short and clear and discuss only a single topic per issue! So for this issue please focus on support for multiple concurrent games and consider opening separate issues for other topics. Also please mind that there are already topics discussing various ideas (e.g. related to the rating system) in the forum.

[Dunedan]

@rossenburgg Any update on this? Do you plan to update this PR?

[Dunedan]

Sorry, this of course isn't a PR. As no discussion about the topics raised here, I'm going to close this issue. If there is need for further discussion we can reopen it again or these discussions can happen in the forums.