Discussion :

[Hydrargyrum]

Bonjour,

Je développe actuellement un petit MMO en C# et j'aurais besoin de conseils concernant la gestion des mise à jours de mon monde.

Résumé rapide du problème :
Chaque partie du monde est géré par une 'zone' qui connait toutes les entités qui s'y trouvent (joueurs / bâtiments / ...).
Chaque entité possède une liste d'actions en cours, qui déterminent comment elle va évoluer dans les secondes suivantes (blessure / déplacement / bonus divers, ...)
Actuellement, chaque 'zone' est un thread séparé qui met à jour chaque action de chacune de ses entités, en boucle (la fréquence de mise à jours est donc potentiellement très variable, ce qui complique la gestion de certaines actions).

Hors je viens de lire un peu de doc sur Threading.Timer, disant que c'était très économe en processeur pour gérer les événements répétitifs. Je me tâte donc à passer sur un modèle où chaque action aurait son propre timer, qui appellerait sa fonction de mise à jours à intervalles fixes (ou pas, suivant l'action).
Le problème est que cela va rapidement faire énormément de timers - même avec seulement 500 entités, à raison de 2-3 actions par entités, on atteint des chiffres qui vont au-delà des cas parlant de la fonction Timer sur internet.

Donc ma question est : les timers restent-ils une solution efficiente lorsqu'on les utilisent massivement (de l'ordre de plusieurs milliers simultanément), ou bien vaut-il mieux que je garde mon modèle actuel ?

Merci.

[Pol63]

plus de 3 timer ca me semble trop ...

[tomlev]

A vrai dire je ne vois pas trop l'intérêt d'utiliser des timers ici, ni même des threads : tu peux très bien avoir un seul thread qui traite les actions de chaque zone, chacune à son tour :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
while(true)
{
    foreach (var zone in zones)
    {
        zone.ExecuteNextAction();
    }
}

[Hydrargyrum]

Si j'utilise un thread par zone c'est pour tirer parti des machines multi-coeurs, ce qu'on ne peut pas obtenir avec une boucle unique (les zones sont grandes et peu nombreuses : 7-8 au maximum).

Quand à l'intérêt des timers, ça aurait été d'économiser des vérifications inutiles et de simplifier le code.
Actuellement si un bonus dure 2 heures je vérifie quand même toutes les X msecondes si il est fini. Idem pour tout un tas d'autre actions qui n'ont pas besoin d'être mise à jours aussi souvent mais qui sont mélangées avec d'autres qui elles en ont besoin. Du coup j'aimerai quitter les modèles à base de 'boucle où l'on met tout le monde à jours'.

Mais si comme le dit Pol93 les timers C# sont inutilisables à grande échelle, je vais peut être bricoler mes propres timers ... peut être un Dictionnary liant un DateTime et un Delegate vers la fonction de mise à jours de l'action que le thread de la zone lirait, en se mettant en pause quand aucune action n'est proche.

[Pol63]

pourquoi vérifier quelque chose, un évènement à la fin du bonus conviendrait il ?

les timers sont peut etre utilisables à grande échelle, mais c'est surtout qu'arrivé là ça relève souvent du problème de conception

couche graphique ?

[antoine.debyser]

Bonjour,

La solution des Timer n'est pas vraiment viable, un Timer reste un thread, et on est limité en nombre de thread.

Si ton but est de faire chuter la consommation CPU quand tu n'as rien a faire.
Une liste l'action, un AutoResetEvent qui est lancer à chaque modif de la liste, et en debut de boucle tu attend l'event avec un timeout.