Réactions aux annonces

[phoe]

Personnellement je trouve le choix pour java injustifié (D'autres points aussi comme la non utilisation de la POO).

Il serait beaucoup plus préférable d'utilisé des techno comme nodejs, socket.io, rabbitMQ, angularJS et Symfony2 avec une base de donnée type postgreSQL avec une mongoDB et du redis.

Ce choix permettrai d'atteindre des performances supérieurs à celle de java, sans oublier que pour le temps réel ces techos sont largement préconisé.

Enfin chacun ces gouts, mais java c'est tous de même moins adapté.

[Mech]

Pour la conception, Pom avait parle d'un corps en c++, qui integrait directement un moteur http pour repondre a des requettes ajax, afin de delivrer le contenu.
Du coup, on se retrouvait avec un code natif, avec une interaction directe avec les clients.

Némunaire avait effectivement l'intention de développer cette architecture.

Si c'est [trop] chiant a faire (surtout la partie ajax, malgre l'utilisation d'une lib comme BOOST), et que vous etes fan d'ocaml (qui est quand meme un language assez sympa), vous pouvez vous orienter du cote de Ocsigen, qui permet de faire un super programme compile en natif, exporte en JS pour la partie client, et etant prevu pour fonctionner de base avec des websocket.

Euh ... pas bien compris non plus. Nigel a plus de chance que moi.

Personnellement je trouve le choix pour java injustifié (D'autres points aussi comme la non utilisation de la POO).

Euh ... justement l'utilisation du java comme POO est logique dans le cas présent

Il serait beaucoup plus préférable d'utilisé des techno comme nodejs, socket.io, rabbitMQ, angularJS et Symfony2 avec une base de donnée type postgreSQL avec une mongoDB et du redis.

Ce choix permettrai d'atteindre des performances supérieurs à celle de java, sans oublier que pour le temps réel ces techos sont largement préconisé.

Enfin chacun ces gouts, mais java c'est tous de même moins adapté.

D'après mes recherches, il s'agit de technologie utilisant le javascript ou le php ... Dans l'utilisation du java, dont l'objectif est quand même le traitement des combats et des flottes, le multithreading ainsi que l'objet sont quand même intéressant ... ou alors j'ai raté des cours ... (je rigole, je n'en ai presque pas eu )

EDIT: Et voilà, on se retrouve en réunion de développement.

EDIT 2: En conclusion de cette réunion avec Nigel, nous avons pris en compte les remarques et nous avons mis en balance ces solutions par rapport à notre architecture et surtout, notre besoin (les solutions front-ends ne nous sommes pas utile pour une application back-end). Il est vrai que la décision du java a été prise il y a un moment et beaucoup de chose ont changé depuis donc je vais étudier la question du C++. Du coté front-end justement, il y a eu du changement depuis la monthly qui n'est du coup plus à jour.

[phoe]

Le multi thread pour les calculs de combat ... Les calculs sont simple je ne pense pas que le multi thread est d'une grande utilité ici.

Pour le frontend, regardez du coté de angularJS de Google. Pour du temps réel asynchrone regardez du coté de express fait en nodeJs

[Mech]

Hum ... permet moi de te remettre en question concernant les combats. Il est vrai que le calcul en lui-même est simple. Par calcul, j'entends avec x d'attaque effectue y de dégâts sur l'ennemi.
Maintenant, on rajoute les attaques primaires et secondaires pour la plupart des vaisseaux (CAM, missiles par exemple), qui n'ont, bien entendu, pas la même cadence de tir, ainsi que le bouclier/blindage/structure et cela, pour chaque vaisseau. Sachant aussi que les tirs sont tous calculés indépendamment puisque justement, chaque vaisseau est indépendant. On rajoute à ça les dégâts sur la structure qui peuvent mettre hors service un vaisseau ainsi que la possibilité de rajouter d'autres flottes en milieu de combat et que les porte-vaisseaux larguent véritablement des chasseurs, on arrive vite à une grande quantité d'information à traiter et de calculs simples. D’où la nécessité d'utiliser du multithreading et un langage de programmation backend.

[uman]

Desole de me re - ramener sur le sujet !

Phoe a raison sur ce point (et sur d'autres).
Il n'y a strictement aucun interet a multithreader les combats en eux meme, car il y a de tres fortes dependances entre tous les elements qui agissent sur ce combat, dont une utilisation forte de mutex, donc une "perte" de perf.

Ici, l'ideal serait d'avoir une threadpool qui, pour chaque "tache", realise son execution sur un seul thread. Par tache, j'entend aussi bien le "recalcul du leaderboard", que "les combats", ou plus simplement tous le reste.

NodeJS permet de realiser plusieurs taches simultanements, avec un systeme d'evenement pousse super bien fait. Le tout transformant du JS en c++ et en l'optimisant au runtime. Mais il faut avoir la foi de faire tous le prog en JS, qui reste un language de £/\ç$µ†.

[phoe]

Merci uman

Et le multi thread dépendra aussi énormément du serveur.

De plus si pour le temps réel vous compté utiliser les servlet de java, cela imposera au joueur d'avoir une JVM d'installer sur sa machine et son navigateur.

Mech, tu a mis en avans le nombre de calculs a faire pour un combat par exemple avec tout les paramètres a prendre en contre et autre. Je pense qu'un bon modèle object serait bien plus adapté.

Dernièrement j'ai fait un audit sur une application écrite en PHP5 orienté object de calculs mathématiques sur la division cellulaire. Il y avait des centaines de milliers de methodes appelé, et objets crée par requêtes (~ 780 000 méthodes appelé pour plus de 4500 création d'objet ) et tout cela fait en moins de 120ms en prenant en compte les méthodes appelé par le framework sur lequel est basé cette appli. Et tous ça sur un pauvre serveur de 1Ghz, avec 1go de ram.

Je pense que le plus gros des perfs doit ce passer sur l'architecture de l'application.

Comme par exemple un système de cache avancé comme Youtube fait par exemple, pour la fluidité une appli coté client comme backboneJS, angularJS. Pour le temps réel une gestion des websockets avec NodeJS ou express et socket.io.

Mais d'un autre point de vue la sur optimisation n'est pas très bon pour HB, en effet cela fait très longtemps que les joueurs attendent le jeu, et que donc une version 1, sans toutes les opti ne serait pas de refus. Et lorsqu'il y aura plus de monde une refacto sera à envisager.

Avec un développement rapide avec 3/4 dev, 1 graphiste, 1/2 mec pour guider le projet, et des mec pour faire le buzz alors en 3/4 mois on peut avoir une V1 propre, modulable, scalable.

Qu'en pensez vous ?

[Nigel Sheldon]

On pensait a multi-threader plusieurs combats en même temps, nous sommes d'accord que surcharger de mutex ne sert a rien.

Les calculs du combat seront en Objet bien sur, C++ (ou Java) oblige.

Surtout pas de VM ! (il est fou !) c'est pour ça qu'on as une base de donnée au mileu.

Il est vrai que l'on pouvait faire du PHP via une cron pour un combat, mais dans tout les cas, le résultat est le même non ?

On essaye d'avoir le moins de Javascript possible sur ce projet, pour le moment, il n'y as que l'horloge affiché en JS, et encore, si le javascript est désactivé, une horloge "fixe" est affiché à la place. Dans l'idéal, on pourra jouer a HB avec Lynx

[phoe]

Je parler tu temps réél, en java il faut créé une servlet et pour la faire tournée le client doit avoir une machine virtuel java d'installer. (80% des gens je pense).

Pourquoi pas de JS en front ? C'est dommage pck par exemple Google, Gmail, Youtube, c'est du full JS grâce à GEA/GWT.

Je ne comprend pas vraiment certains de vos choix techniques.

Pour la base de donnée vous partez sur laquelle ? lesquelles ?

[Mech]

Les combats ne sont pas vraiment du temps réel, ils sont simplement plus réaliste que ceux rencontrés dans les jeux comme Ogame ou la bataille est instantanée.

Quand à nos choix techniques, ils se font en ayant pleinement connaissance des objectifs à atteindre dans le développement du jeu en prenant en compte les ressources dont nous disposons (nos propres connaissances en informatique en font partie)

[phoe]

En temps réél je parle du fait que quand par exemple je lance ma flotte sur ta planète par exemple, alors sans que tu n'es a rafraichir ta page tu es notifier qu'une flotte viens chez toi

Pratique aussi pour des discutions notification d'evenement d'alliance, de mouvement de résultat de mission etc.

[uman]

Je parler tu temps réél, en java il faut créé une servlet et pour la faire tournée le client doit avoir une machine virtuel java d'installer. (80% des gens je pense).

A mon avis, ils parlaient de Java cote serveur. Cote client, c'est une vieille blague / nid a malware.

Les calculs du combat seront en Objet bien sur, C++ (ou Java) oblige.

Surtout pas de VM ! (il est fou !) c'est pour ça qu'on as une base de donnée au mileu.

Java tourne dans une VM.

Il est vrai que l'on pouvait faire du PHP via une cron pour un combat, mais dans tout les cas, le résultat est le même non ?

Le PHP, c'est SUPER lent "Oh, on appelle le script, bah on va reparser tout les fichiers php, pour les recompiler et les executer!".
Il y a une grosse difference entre language de scripting, et language compiles.

[phoe]

uman, £/\ç$µ† est fait en Symfony qui tourne en PHP donc je ne suis pas d'accord avec toi sur ce point, cela fait un petit moment que je suis développeur et je peut te dire que les différences sont minime entre language compiler et interpreter (Pour le web bien sûr), surtout avec le cache d'opcode de PHP.

Pareil pour le JS coté front, ce n'est pas du tout un lit à malware, regarde le code source générer de gmail

Le problème est de savoir bien manipuler toutes ces technos.

[TazVadu]

£/\ç$µ†? xD Tu veux pas dire Youtube? xD

Désolé, c'est la seule chose que j'ai compris dans les derniers messages... xD

[Nigel Sheldon]

Non, je parlais de VM client qu'il ne faut surtout pas faire, un VM serveur, c'est pas gravissime (même si il est vrai que moins performant que le C++ par exemple)

[uman]

Il parle de £/\ç$µ†, pas de Youtube.

Je suis d'accord que, une fois mis en cache avec Twig, la page apparait facilement, sauf qu'ici, on parle de calcul brut, pas d'affichage mis en cache. Et meme si une page peut etre generee en super peu de temps, ce temps restera plus long que l'equivalent en c++.

Malheureusement, je ne pense pas que l'equipe de HB puisse se payer les serveurs de youporns, il faut donc optimiser un maximum le cote serveur, si on veut un jeu fluide pour les utilisateurs.