[Version PROTOTYPE] Warpfire Revolution (RealTime Space Ship battle)
#21
(01-28-2015, 09:10 AM)Xenos a écrit : Tout ce qui est 100% destiné au référencement et non aux utilisateurs, donc les hidden texts, est très mal vu par les moteurs de recherche (spamdexing).

La sollicitation de BDD, suivant ce qui est cherché, peut ne pas être un problème: connexions persistantes, index et maintenance peuvent écraser "l'avantage" d'un gros array PHP 16

On dit "ID", pas "idée" XD microtime(true) pour le temps avec les µs en virgule. Je regarderai le reste après.
EDIT :
pour le problème de référencement des textes cachés. bah justement, j'ai mis un position absolute à -X pixels, ce qui permet de le faire passer pour un simple menu, il est donc visible mais hors de l'écran, après si je veux vraiment poussé au vice, je fais une phrase avec les mots et comme les bots ne lisent pas le javascript, supprimer le contenue du div au chargement de la page via JS. (window.onload = function(){window.removeChild(TAG_DIV);}16

Dans ce cas :
- Mise en place d'une table de type "memory" qui contient les données à échanger entre les divers processus (au lieu de memcached)
à chaque envois de donnée l'on fait un insert tout simple dans la table
à chaque lecture des données, un simple select avec l'id du "channel" à lire ['id','method','value']
- Autre table "memory" pour la gestion des déplacements et du champ visuel
-> Je conserve alors le système de cluster pour simplifier la selection des objets, ce qui m'évite de comparer tout les objets pour savoir si je les revois ou pas.
Swap vers le prochain custer -> selection des cluster différent, ceux qu'on affiche et ceux qu'on masque, loop des objets présent pour effectuer les modifications et informer les joueurs des changements sur ces cluster
- pour les crons, je me tate .... quand j'execute un cron j'ai directement l'objet accessible, même si il serait facile d'utiliser simplement un champ id qui contient l'id unique de mon objet sur la map, de toute façon les crons concernant un objet sont supprimé lorsque l'objet lui même est supprimé.
- Une autre table memory pour me permettre de créer des "zones" qui n'ont pas de forme géométrique, donc je dois simplement checker quand je suis sur une case si elle correspond à une zone précise, executer une fonction d'entrer de sortie ainsi qu'une fonction principale (si par exemple, dommages infligées toutes les secondes, réparation, ralentissement, etc ...).

Exemple : Joueur se déplace en x200:y200 
1) calcul du temps met pour traverser une case (qui devrait faire dans les 20 pixels, me permettant de faire une map détaillé), mais à savoir que ces cases donnes grossièrement les positions des divers zone, un joueur peut tout à fait aller en 201:202 si il clic au bon endroit pour obtenir la case je fais alors

position_x/largeur_case:position_y/largeur_case
2) Ajout d'un cron qui executera le check de la case actuel
...

3) Execution du cron
 -> Selection de toutes les zones correspondant à la position du joueur (ainsi pouvoir cumuler plusieurs buff/debuff)
-> Pour les zones identiques (ce qui implique le stockage des zones actives) il ne se passe rien, on redefinis alors le prochain cron de check, exemple, je suis sur une case de type "champ d'astéroïde" qui me ralentis, la case suivante est aussi une case "champ d'astéroïde" alors il ne se passe rien.
-> Pour les zones différentes (donc si elles n'apparaîssent pas dans les résultat de selection on appel une sorte de "leaveZone(type_zone)") pour les nouvelles zones on applique un enterZone(type_zone)

et voilà, mais petite question. si je fais une map de 30 000 x 30 000 px, ce qui est petit, et que je souhaites avoir de la precision concernant les zones il faut soit que j'utilise ce bricolage de système de zone soit que j'arrive à prédire des collision, sachant que ces zones sont fixes, mais vu que le déplacement est la fonction principale du jeu , celle appelé le plus souvent, je souhaiterais éviter de l'alourdir, mais avec un système stocké dans sql, sortir une réponse devrait être très rapide.

AU passage : Array_diff est apparemment moins performant qu'un bon foreach & isset pour comparer deux tableau.

Le passage d'array en référence est plus rapide est environ 4% plus rapide que le passage d'un objet en référence. donc pour le transfer de donnée dynamique, j'utilise la methode B :
Code PHP :
define('R','<br/>');

function 
m() // Temps en microseconde
{
    $m explode(' ',microtime());
    return $m[0]+$m[1];
}

function 
A(){ // Création d'un objet et modification de celui ci par une methode
    $a = new a();
    $a->over();
}

function 
B(){ // Création d'un array et passage de celui ci en référence
    $a = ['state'=>false];
    overB($a);
}
function 
C(){ // Appel directe sans référence d'un array
    $C overC(['state'=>false]);
}

class 
// Objet test pour le cas A
    public $s 0;
    public function over(){
        $this->1;
    }
}


function 
overB(&$obj){ // Fonction test pour le cas B
    $obj['state'] = true;
}

function 
overC($obj){ // Test pour le C
    $obj['state'] = true;
    return $obj;
}
foreach ([
'A','B','C'] as $k => $test){ // Execute les fonctions A B et C pendant 1 seconde pour compter le nombre d'itération
    $e m()+1// End
    echo 'Start at : '.($e-1).' end at '.$e.R;
    for ($t 0;m() <= $e;$t++){
        $test();
    }
    echo 'Turn '.$test.': '.$t.'<br/>';

B() est plus rapide que A() en executions par secondes, les références d'array sont donc plus efficaces que les tableau en création/lecture/ecriture ?
Répondre
#22
Si ton but est de piéger les bots de référencement, tu te feras éjecter quand le site commencera à être connu (cf les CGU des différents moteurs de rercherche). Si tu fais une vraie page de présentation, avec un texte lisible par tous, en HTML/CSS classique, les moteurs d'indexation n'auront rien à en redire et tu seras correctement référencé, sans aucun risque de black-listing. A toi de voir si le référencement t'intéresse ou non.

Les comparaisons de perfs avec moins de 10% d'écart sont assez peu pertinentes: les résultats réels vont fortement dépendre de l'état de la machine, des éventuelles optimisations tierces (opcache par exemple) et de paramètres aléatoires type accès mémoire.
Mieux vaut utiliser des fonctions claires, qui délègueront le travail au core PHP, plutôt que des ré-écritures perso en PHP qui vont faire monter la quantité de code à maintenir, et priver ces codes des optimisations dont le core PHP pourrait bénéficier.

Et franchement, je ne comprends pas ton histoire de cluster: ce n'est ni plus ni moins que réinventer (de travers probablement, désolé!) les arbres binaires dont les indexs SQL se servent. Pour les CRONs, les FOREIGN KEYS de MySQL te permettraient de gérer les suppressions automatiques (cas-type: une ligne dans une table, avec un id unique, liée à N lignes dans une autre tables via cet ID; quand la ligne de la première table est supprimée, le SGBD va supprimer les lignes de l'autre table qui référençaient cette ligne disparue, et cela sans avoir rien à faire de particulier coté code SQL: moins de maintenance, plus de bonheur).

Note que tu peux peut-être déléguer certains calculs de collision au client, et n'en faire que la vérification coté serveur (sur le modèle des preuves de travail). A voir, c'est simplement une idée lancée là maintenant.
Répondre
#23
(01-28-2015, 12:42 PM)Xenos a écrit : Si ton but est de piéger les bots de référencement, tu te feras éjecter quand le site commencera à être connu (cf les CGU des différents moteurs de rercherche). Si tu fais une vraie page de présentation, avec un texte lisible par tous, en HTML/CSS classique, les moteurs d'indexation n'auront rien à en redire et tu seras correctement référencé, sans aucun risque de black-listing. A toi de voir si le référencement t'intéresse ou non.
Non pas de piéger, mais disons d'utiliser les mots clé qui pourrait être tapé dans un moteur de recherche pour mener à mon site, jusqu'à maintenant ça marche, quand ça sera fait, oui je ferais une page de présentation avec une tag liste clickable en bas.

(01-28-2015, 12:42 PM)Xenos a écrit : Les comparaisons de perfs avec moins de 10% d'écart sont assez peu pertinentes: les résultats réels vont fortement dépendre de l'état de la machine, des éventuelles optimisations tierces (opcache par exemple) et de paramètres aléatoires type accès mémoire.
Mieux vaut utiliser des fonctions claires, qui délègueront le travail au core PHP, plutôt que des ré-écritures perso en PHP qui vont faire monter la quantité de code à maintenir, et priver ces codes des optimisations dont le core PHP pourrait bénéficier.

C'est indicatif, il ne m'est pas difficile de comparer les performances en jeu, suffit de regarder le lag et de faire une moyenne, sinon je m'éclaterais pas, un simple array_diff et bam, je ré-invente pas la roue pour le plaisir, ce n'est pas la seule fonction concerné par ce problème, les natifs sont moins rapides que les core. depuis depuis php 5.6 le code est convertis automatiquement en opcode rendant APC cache obselete, donc bon, c'est une petite partie du code que je pourrais toujours optimiser 2

(01-28-2015, 12:42 PM)Xenos a écrit : Et franchement, je ne comprends pas ton histoire de cluster: ce n'est ni plus ni moins que réinventer (de travers probablement, désolé!) les arbres binaires dont les indexs SQL se servent. Pour les CRONs, les FOREIGN KEYS de MySQL te permettraient de gérer les suppressions automatiques (cas-type: une ligne dans une table, avec un id unique, liée à N lignes dans une autre tables via cet ID; quand la ligne de la première table est supprimée, le SGBD va supprimer les lignes de l'autre table qui référençaient cette ligne disparue, et cela sans avoir rien à faire de particulier coté code SQL: moins de maintenance, plus de bonheur).

j'ai une carte de 30 000 x 30 000 pixels, le joueur peut voir jusqu'à 4400 pixels à gauche et 4400 pixels à droite. donc quand il bouge il faut qu'il voit au minimum 2 zones de 4400 pixels. donc j'ai découpé la carte en zone de 4400 pixels de coté, quand un joueur bouge on calcul quand il sort de cette zone, un cron s'execute alors pour effectuer le changement.

chaque cluster à un tableau "child" pour dire quelle autres cluster le joueur doit voir quand il est sur celui ci, il ne reste qu'à faire la différence entre les tableau "child" du cluster actuel et du cluster de destination, virer la liste des objets des childs qui ne seront plus visible et ajouter les nouveaux.

Puis SQL, j'y suis un peu allergique, beaucoup plus à l'aise avec php, à moins qu'on me donne du tout cuit mais là n'est pas le but, à vrai dire ce que je souhaites c'est utiliser au maximum php, à quelle différence peut-on jauger l'utilisation de sql au lieu de php ?

(01-28-2015, 12:42 PM)Xenos a écrit : Note que tu peux peut-être déléguer certains calculs de collision au client, et n'en faire que la vérification coté serveur (sur le modèle des preuves de travail). A voir, c'est simplement une idée lancée là maintenant.
Le client je lui fais jamais confiance. si j'effectue des calculs de collision au client il faudra bien qu'il envois la demande de verification au serveur, qui devra reverifier à son tour car si le client modifie le code js via la console, bah je l'ai dans le baba et faire un check toutes les X ms c'est possible, mais pas très précis (mais suffisant pour mon jeu tu me diras, je veux juste que lorsque je m'amuse à aller à la limite de la zone, le changement se fasse dessuite , comme pour les cluster, c'est pas checker toutes les x ms mais un cron calcul quand il sortira de la zone, sorte de detection de collision mais simple car c'est un carré, mais pour les zones à formes variables .... soit jme tape un GD où j'obtient la couleur de la zone sur laquelle se trouve le joueur (mise en cache dès le début du jeu, attribution des zones etc pour n'avoir jusqu'à faire un isset($zone[$x.'-'.$y]).

enfin bref, pour les zones j'y suis pas encore, c'est chiant la gestion de l'espace mais c'est la base de ce type de jeu moi qui suit pas doué en math je bricole pour réussir.
Répondre
#24
La différence majeure? SQL traite des données par lot, PHP traite des données par élément. Le premier serra rapide pour tout ce qui concerne le traitement par lot, comme de la recherche & extraction de données dans un grand ensemble (exemple: extraire les objets distants de moins de D unités du joueur par exemple, avec D une distance type 2x la distance de vue, histoire de pré-charger ce qui sera vu 'plus tard'; mais si ces infos sont envoyées au client direct alors il pourra tricher et les afficher en agrandissant sa zone de vue).
Le second sera utile si on souhaite traiter les éléments indépendamment.

Y'a SQL qui gère les polygones 2D et les intersections. Si tu ne t'en sors pas en maths, utilise des lib existantes: ou (My)SQL, ou PHP (geoPHP pas testée, mais trouvée en 3 secondes chrono donc il en existe certainement de bonnes déjà prêtes à l'emploi).
Répondre
#25
(01-28-2015, 02:33 PM)Xenos a écrit : La différence majeure? SQL traite des données par lot, PHP traite des données par élément. Le premier serra rapide pour tout ce qui concerne le traitement par lot, comme de la recherche & extraction de données dans un grand ensemble (exemple: extraire les objets distants de moins de D unités du joueur par exemple, avec D une distance type 2x la distance de vue, histoire de pré-charger ce qui sera vu 'plus tard'; mais si ces infos sont envoyées au client direct alors il pourra tricher et les afficher en agrandissant sa zone de vue).
Le second sera utile si on souhaite traiter les éléments indépendamment.

Y'a SQL qui gère les polygones 2D et les intersections. Si tu ne t'en sors pas en maths, utilise des lib existantes: ou (My)SQL, ou PHP (geoPHP pas testée, mais trouvée en 3 secondes chrono donc il en existe certainement de bonnes déjà prêtes à l'emploi).

Très intéressent en effet 16 ça nécessite un changement dans tout les traitement par lot, et yen a un paquet, à voir pour l'avenir donc.

Objectif : Avoir un serveur potable sans trop de lag car peu de joueur, terminer les outils pour n'avoir plus qu'à mettre du contenu.
Problème : Prévoir les futurs amélioration du jeu, histoire de pas tout livrer d'un coup.
Solution : Établir un cahier des charges avec les différentes suggestion, mettre en place une infrastructure souple autorisant les modifications, donc multiplier le nombre de fonctions.

Note : Les améliorations possibles sont celles de turmalith wars (la version d'après sortie par gameforge), une bonne partie est déjà prête à être codé + les quelques idées qui me trotte en tête.

Avancement :
Là, je suis en train de corriger les fonctions pour tirer et envoyer des rockets, car à la base le joueur n'a que ça pour se défendre, plus tard il pourra utiliser des buffs (qui seront des laser et des "projectiles", les laser ont un impact immédiat, les projectiles doivent se déplacer), cependant mes projectiles ne tiennent pas compte du faite que le joueur s'éloigne ou se rapproche, le calcul est fait lors du lancement de celui ci, donc si il doit exploser dans 1s de distance (en fonction de sa vitesse) alors il explosera a 1s de distance, que le joueur bouge ou non pour ensuite infliger des dégâts dans la zone.


Une fois ça fait, je corrige la distribution des bufs au tour des plateformes (point fixe sur la minimap soit gris, bleu jaune ou rouge dépendant de l'alliance qui la contrôle) pour que ça colle avec mon nouveau système de cron et de selection des zones, ensuite les divers bugs, ensuite je test le serveur.
-> si c'est bon lag corrigé, je passe dessuite au client car il en a grand besoin
-> si le lag n'est pas corrigé j'approfondis l'optimisation et continue de réduire les données échangées.

Mais à quoi est du ce lag ? (peut être une piste)
Je communique avec le client en lui envoyant directement du javascript, c'est json_encodé décodé partout c'est moche, ya pleins de fonctions pour la même chose en bref c'est un peu le bordel, j'ai donc tout recentré les fonctiones servant à la communication client/server et server/server dans un trait (simplement trait.com.php), ainsi en évitant d'envoyer la même information aux joueurs j'économise un peu de ping.
(avant sendDataToVisibleUser ajoutait autant de donnée qu'il y avait de joueur pour recevoir la même info)
(maintenant j'envois les id des joueurs concerné et le data à envoyer, plus simple, plus rapide, tout le tri se fait côté client, le serveur n'a connaissance que si le joueur est connecté par une simple bool).

Il me reste tellement à faire, le travail est titanesque mais bordel, qu'ece que ça a dla gueule quand ça marche et que je vois la progression, tout "petit à petit".

Petit point pour lequel j'ai déjà regardé sur le forum et que tu pourrais m'aider concerne l'équilibrage, mais bien entendu, ça ne sera fait qu'à la fin du jeu, mais j'ai déjà ma petite idée 16 à savoir que l'ancien warpfire possède déjà ses formules de progression, j'ai les valeurs, mais pas les formules qui vont avec, mon niveau en math doit être collège ... et encore, alors pour trouver une fonction avec les résultat ya excel, ouais, mais ça m'aide pas à le convertir en php.

Note2 : Pour le côté client et l'optimisation c'est pas mal de math, là aussi tu pourrais m'être utile.
Note3 : Non je suce pas, mais je ferais bien volontier de la pub pour les quelques pèlerins qui se perdent sur mon jeu 2 (échange de bon procédés)

Et enfin, question qui m'intéresse grandement :
Connais tu Pthreads et sais-tu l'utiliser ? je me suis documenté, mais à première vue ce n'est pas fait pour ce que je souhaites, pourtant un thread est bien moins lourd qu'un processus et j'ai déjà réussis à faire un système de synchro perso (les pool, je suis pas copain avec).

Genre un thread par cluster ça serait le must. ainsi les joueurs ne se rendrait même pas compte lorsqu'ils changent de map, plus besoin de porte de saut, je fais une animation ig le temps du chargement et bim.

Tu prendras un peu de salade avant le steak fritte ?
Répondre
#26
Fait pas de l'optimisation au détriment de la maintenance. Mieux vaut, au fond, un code lourd voire pas jouable du tout qu'un code impossible à maintenir, ne serait-ce que parce que le code pouvant être maintenu pourra être post-traité ("compilé", ou autrement dit, on génère de nouvelles sources optimisées à partir des sources lourdes), alors que le contraire ne sera pas possible.

Non, pas testé pthread. Mais je sais qu'Apache peut être threadé pour processus-isé. A voir lequel des deux te va mieux niveau perf et souplesse d'utilisation.
Répondre
#27
Pas con pour apache, l'équivalent d'un get_url_data(http://localhost/monthread.php); avec un expire à 0

à tester, ça promet ! (mais plus de mode console, alors obliger de faire un debugger). ou se sevire de l'astuce que sur le mode production. (facile à réaliser)

Je vais essayer de bricoler un truc du genre :

script A :
- lancer script B, retourner immédiatement
- laisser tourner B en fond.
- lancer script C, retourner immédiatement
- laisser tourner B en fond.

avec file_get_contents : http://php.net/manual/en/function.file-get-contents.php peut être
Répondre
#28
UP. Evolution depuis le temps.

- Aquisition d'un nom de domaine et d'un serveur
- Migration vers unbuntu
- Plusieurs nouveautés IG

(http://www.helden-space.com)

Et suivis du projet sur facebook : Warpfire revolution (ou heldenSpace) dans la barre de recherche
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)