IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseau et multijoueurs Discussion :

Smart fox server


Sujet :

Réseau et multijoueurs

  1. #1
    Membre confirmé

    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    786
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 786
    Points : 602
    Points
    602
    Par défaut Smart fox server
    Bonjour je regarde smart fox server

    http://smartfoxserver.com/

    J'ai teste un peu en local ca fonctionne bien.

    Leur slogan c'est "Massive multiplayer platform" mais je ne comprend pas bien car si on achète une licence pour 100 utilisateurs je ne vois pas comment cela peut tenir sur un serveur dédié.

    Je me demande si ils on prévu des trucs pour gérer la charge?
    Loadbalancer sur plusieurs serveurs etc... ou c'est a nous de tout gerer?

    Merci de votre aide.

  2. #2
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Citation Envoyé par saturn1 Voir le message
    100 utilisateurs je ne vois pas comment cela peut tenir sur un serveur dédié.
    Tout dépend ce qu'on demande de faire au serveur pour chaque utilisateur.
    Si on parle d'un MMOFPS avec des calculs de physique, de collision, etc... avec de fortes contraintes temps réel, 100 joueurs sera difficile à tenir sur un serveur à moins d'avoir une vraie bonne grosse bête de course.

    Par contre, si on se réfère aux jeux présentés dans leur showcase, c'est du jeu 2D ou isométrique, avec des besoins en calculs à priori très faible. Dans ce cas, un serveur bas ou moyen de gamme sera capable de gérer quelques milliers de joueurs sans trop broncher.

    De même, avoir 1000 joueurs qui partagent un unique espace de jeu n'induit absolument pas la même charge que les même 1000 joueurs répartis dans 500 parties de deux joueurs, disjointes les unes des autres.

    Donc tout dépend de ce que tu comptes en faire de leur techno.

    Quant à la question de savoir s'ils ont des choses déjà toutes prêtes pour la répartition de charge sur plusieurs machines physiques, je pense que c'est plutôt à eux qu'il faut le demander directement.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  3. #3
    Membre confirmé

    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    786
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 786
    Points : 602
    Points
    602
    Par défaut
    Je n'ai pas les calculs de la physique a faire sur le serveur.

    Mais le serveur se charge de transmettre les positions et d'autres infos de tous les joueurs a 60 fps.
    Ca fait beaucoup?

    Merci.

  4. #4
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    26 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 26 815
    Points : 218 179
    Points
    218 179
    Billets dans le blog
    117
    Par défaut
    Bonjour,

    Je doute que transmettre les données à une fréquence de 60 fois par seconde soit une bonne chose. D'ailleurs, cela voudrait dire, dans un cas optimal, qu'il faudrait avoir un ping de 16ms (et même plus bas), pour que cela soit fiable ?

    Il faudrait voir à envoyer moins de paquet, quitte à faire des interpolations / extrapolations entre deux paquets.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  5. #5
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Citation Envoyé par LittleWhite Voir le message
    Je doute que transmettre les données à une fréquence de 60 fois par seconde soit une bonne chose.
    Je plussoie, mais je pense que c'est justement l'implémentation du SmartFoxServer qui se cherge de s'occuper de ce genre d'optimisation (dead reckoning et compagnie). A vérifier dans leurs docs.

    Pour le reste, même si on a 'beauoup' de chose à faire par joueur et par seconde, tout dépend en fait de la complexité de ce qu'il y a à faire. S'il s'agit uniquement de recevoir un paquet et le retransmettre aux joueurs 'présents dans les alentours', sans faire aucun forme de traitement complexe dessus, c'est relativement trivial pour un serveur de nos jours et c'est le genre de chose qui peut supporter une montée en charge importante.

    A titre personnel, j'ai déjà implémenté un serveur de sockets en Java, avec un binding PHP pour traiter les messages reçus et les réémettre vers des listes de joueurs. Autant dire que c'était pas optimum en terme de consommation des ressources, et pourtant je tenais plusieurs milliers de clients avec une dizaine de messages par seconde chacun, le tout sur un serveur pas folichon (un AMD moyen de gamme d'il y a 5 ans).


    Bref, à nouveau, tout dépend de ce que tu fais concrètement dans ton application ; il ne peut donc pas y avoir de réponse toute faite, le mieux étant de faire des essais avec la version gratuite qu'ils semblent proposer. Et ça personne d'autre que toi ne pourra le faire à ta place étant donné que seul toi sait ce que tu mettras réellement dans ton appli.
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  6. #6
    Membre confirmé

    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    786
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 786
    Points : 602
    Points
    602
    Par défaut
    Merci de vos réponses.

    Actuellement pour afficher un joueur remote je recois toutes les informations ca position , son state graphics etc...

    Je me demande si il est possible d'implémenter cela en simulant ces inputs par le reseau?
    Par exemple sur le réseau j'envoie joueurC appuie A, en local je reçois cela et j'appelle la même méthode qui si il avait appuyer sur A.
    Mais je laisse le client gérer la physique et vitesse etc...

    Mais il me semble qui forcement je vais devoir envoyer des packets de "fallback" pour resynchroniser la position? au cas ou la simulation physique ne se déroule pas pareil sur le remote et le local

    Merci

Discussions similaires

  1. application smart device et sql server CE
    Par abdou.amara92 dans le forum Accès aux données
    Réponses: 1
    Dernier message: 04/03/2013, 15h58
  2. Problème SDK Smart Ad Server et Android
    Par tlili_info dans le forum API standards et tierces
    Réponses: 2
    Dernier message: 26/01/2012, 19h59
  3. Pb migration Access / SQL server
    Par yoyo dans le forum MS SQL Server
    Réponses: 10
    Dernier message: 25/04/2005, 11h39
  4. Backup BD SQL Server
    Par Ethmane dans le forum Administration
    Réponses: 3
    Dernier message: 07/06/2002, 01h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo