Moteur de jeu 2D

[niahoo]

Cette argumentation n'est pas correcte selon moi. Bon déjà on ne parle pas de jeux AAA 3D/VR ou autre, c'est hors sujet. Ensuite, tu pars du principe que quelqu'un souhaite faire un jeu, n'importe lequel, et que pour cette personne ça sera plus simple d'apprendre le PHP.

Je vois les choses différemment : premièrement, une personne souhaite faire un certain type de jeu, pas n'importe quel jeu. Et pour ce type de jeux, certaines technos sont plus adaptées, parfois PHP, pafois non. Combient y a-t'il de questions sur ce forum dans le genre "faire un CRON à la seconde", tout ça parce on maintient l'idée, notamment avec ton raisonnement, que PHP est l'outil par défaut.

Secondement, PHP n'est pas plus facile à apprendre que Javascript ou Elixir pour ne citer que les alternatives que je connais. Combien de personnes ne sont pas foutues de faire du orienté object correct en PHP alors qu'il n'y a même pas besoin de se préoccuper de ça dans un langage FP ?
C'est tout simplement faux, PHP n'est pas plus facile. Sans parler des librairies dispo pour tout ce qui touche au multi et au network sur npm et hex.

Ce qui te paraît exotique à toi ne l'est pas forcément pour le milieu du dev en général.

Pour ce qui est des boites insouciantes qui utilisent node js on va simplement dire que tu étais fatigué quand tu as écrit ça.

M'enfin je trouve pas ça logique que dès qu'on veut faire autre chose qu'un simulateur de déclaration d'impôts ta meilleure solution est un SDK style Unity.

[L'Omniscient]

Moi j'ai appris le Javascript et le PHP sur le tas pour faire mon jeu. J'avais un peu pratiqué le JS, mais juste pour faire des petits diaporamas.

Ce qui me fait peur avec mon jeu c'est que chaque joueur a une requête vers la BDD quasi toutes les deux secondes (bon par pour chercher des masses de données). En plus je suis sur un mutu (je sais même pas comment ça fonctionne les serveurs dédiés). Dimanche je vais avoir une vingtaine de joueurs en même temps, je vais bien voir ce que ça va donner, mais j'ai peur T_T Du coup aller sur un dédié c'est préférable? La transition est-elle difficile ?

Quand on était à 2 sur le jeu le processeur de mon serveur était utilisé à 10% l'heure, ça veut dire qu'à 20 en même temps ça va être limite ?
Utilisation de mémoire je suis à 50%
Bon utilisation de disque je suis même pas à 1giga
Débit réseau pendant le test à 2 : 40ko entrant 400ko sortant / l'heure
Les requêtes je comprends pas exactement, je vous donne en détail les requetes max sur une heure de test à 2 :
1 error, 58 hit, 311 miss, 1670 not, 4439 pass
467 bytes error, 9 700 000 bytes hit, 15 000 000 bytes miss, 2 000 000 bytes not, et 0 bytes pass

[niahoo]

20 joueurs à 1 requêtes toutes les 2 secondes, honnêtement à part si tes requêtes sont hyper mal foutues ou ultra lourdes, c'est rien. Absolument rien. Ne t'inquiète pas

[Xenos]

Je ne pars pas forcément sur le principe que PHP est le langage à apprendre par défaut, mais sur la constatation que, me semble-t-il, les jeux qui se pointent ici sont portées par des gens qui ont appris PHP de base (ont-ils fait le bon choix pour leur jeu, ça, c'est à voir). peut-être que c'est juste le premier résultat de recherche quand on veut créer un site... ou que WAMP s'installe tout seul très facilement. Il y a peut-être des stacks similaires sur tes autres technos, mais elles semblent avoir moins de visibilité...

Ce que j'essaie de pointer (de travers peut-être), c'est qu'il faut être en adéquation entre le jeu qu'on veut faire, les compétences qu'on a déjà, les moyens dont on dispose, et le temps qu'on peut y consacrer. Partant de là, oui, si l'objectif est de sortir un jeu, je préfère pousser quelqu'un à abandonner son temps réel pour un bête points d'actions (ou assimilé) s'il connaît déjà le PHP et qu'il a déjà tout en place pour le faire tourner. Toi, tu la pousses plutôt dans l'autre sens, pour se lancer dans une nouvelle stack plus adaptée à son besoin.

C'est peut-être mon boulot d'ingé qui ressort ici: je ne me considère pas comme un "codeur", mais comme un ingénieur dont le but est de réduire la complexité d'un projet, ce qui passe souvent par une vision différente de ce que le client demande, correspondant tout aussi bien si ce n'est mieux au résultat qu'il souhaite et surtout, aux moyens dont il dispose.

Donc, oui, si le but de ton jeu est de faire du temps réel et que tu n'en démordras pas, c'est sûr qu'avoir appris PHP finira en perte de temps... Changer de langage est alors une solution. Changer de contexte aussi, et basculer sur un SDK classique et non plus un jeu web te prendras littéralement 2 minutes: 1 pour installer, et 1 pour le lancer et avoir un premier aperçu de jeu. T'as ensuite tous les outils direct embarqués pour développer ton contenu de jeu (et même des assets sur l'Unity Store).

De ce que je vois (ce n'est peut-être pas une référence, certes, mais c'est la cause de mon raisonnement), tous ceux qui passent ici avec des technos non AMP (et non SDK, le nouveau Sephy n'est donc pas inclus là dedans) ne sortent au mieux que le "Hello, World!". S'il faut perdre des semaines à installer et apprendre ces stacks, je comprends que beaucoup abandonnent ce genre de techno ou n'aillent jamais très loin. Atteindre le simple stade de "mon perso se déplace en temps réel sur ma carte de RPG et je vois les autres joueurs!", ce n'est pas le début du jeu. C'est la fin de l'installation d'un SDK (pour la comparaison). Le vrai début de la création du jeu, c'est le premier contenu inséré là-dedans.


@L'omniscient: ce n'est pas forcément linéaire: si 2 personnes bouffent 10%, peut-être que 3 en boufferont 30%, ou 40% (si la charge double à chaque joueur car elle serait exponentielle). Sinon, bon, je ne veux pas te déprimer, mais auras-tu 20 joueurs actifs dans la durée? Perso, j'avais dimensionné la carte d'Eclerd pour plusieurs milliers de joueurs. Résultat: n'ayant pas dépassé la centaine (et même pas la dizaine d'actifs), la carte s'est avérée sur-dimensionnée et cela a même nuit au jeu. Donc bon, tu peux repartir from scratch. Ou alors, tu peux te balancer des perfs, continuer pour avoir ta release de base et tes premiers joueurs, et aviser ensuite entre virer la partie temps réel au profit d'un autre mécanisme, ou la conserver en l'optimisant (via une meilleure utilisation de AMP ou via une nouvelle stack/langage).

[niahoo]

Ce que j'essaie de pointer (de travers peut-être), c'est qu'il faut être en adéquation entre le jeu qu'on veut faire, les compétences qu'on a déjà, les moyens dont on dispose, et le temps qu'on peut y consacrer. Partant de là, oui, si l'objectif est de sortir un jeu, je préfère pousser quelqu'un à abandonner son temps réel pour un bête points d'actions (ou assimilé) s'il connaît déjà le PHP et qu'il a déjà tout en place pour le faire tourner. Toi, tu la pousses plutôt dans l'autre sens, pour se lancer dans une nouvelle stack plus adaptée à son besoin.

C'est sur qu'en ne se forçant à ne rien utiliser d'autre que PHP, avec des compétences de débutant, on ne peut guerre espérer mieux qu'un jeu via formulaires. Je ne dis pas le contraire.

[L'Omniscient]

niahoo tu me rassures, Xenos tu me stresses xD

On verra si mon jeu aura du succès ou non, mais le but est en tous cas d'avoir pas mal de joueurs. Une fois que mon jeu sera vraiment sorti, je ne travaillerai que sur la com, mais si ça plante avec 20 joueurs... ça sert en fait à rien de faire un jeu multijoueurs ? xD En tous cas pour dimanche, faut que ça fonctionne avec 20 joueurs, sinon c'est un peu la misère.

Mais si ces chiffres ont pas l'air de vous affoler ça devrait aller.

[incodewetrust]

Ce que j'essaie de pointer (de travers peut-être), c'est qu'il faut être en adéquation entre le jeu qu'on veut faire, les compétences qu'on a déjà, les moyens dont on dispose, et le temps qu'on peut y consacrer. Partant de là, oui, si l'objectif est de sortir un jeu, je préfère pousser quelqu'un à abandonner son temps réel pour un bête points d'actions (ou assimilé) s'il connaît déjà le PHP et qu'il a déjà tout en place pour le faire tourner. Toi, tu la pousses plutôt dans l'autre sens, pour se lancer dans une nouvelle stack plus adaptée à son besoin.

C'est sur qu'en ne se forçant à ne rien utiliser d'autre que PHP, avec des compétences de débutant, on ne peut guerre espérer mieux qu'un jeu via formulaires. Je ne dis pas le contraire.

Je tiens quand même à rappeler que le système des jeux par points d'action n'est pas un sous-genre, dédié au tiers-monde des développeurs amateurs qui n'auraient pas les moyens de faire du temps réel. Il existait d'ailleurs bien avant les jeux-web, des parties d'échec par lettres interposées.

L'absence de temps réel est complètement VOULUE dans de nombreux projets (web ou non) pour des raisons de game design. Aujourd'hui, Civilizations, HMOM, x-com, constituent un genre qui entends favoriser la réflexion contrairement à la microgestion brute récompensant l'APM du joueur dans les RTS.

Je pense que le concept a de l'avenir car il permet une meilleure gestion du temps de jeu (l'interruption n'est pas préjudiciable au joueur, contrairement à un fps multi, un rts multi ou un mmo).

Pour finir, je ne sais pas si aujourd’hui, avec l'utilisation d'outils comme rpgmakers avec une base de graphismes libre de droits, la réalisation d'un jeu en temps réel est vraiment plus complexe que celle d'un jeu "par formulaire" créer à partir de rien par un débutant en php.

[niahoo]

Oui les jeux asynchrones sans temps réel sont un genre à part entière. Personnellement mon avis n'est pas de limiter la créativité des gens sous prétexte que ce serait plus simple à mettre en place. Ce qui d'ailleurs est faux. Le temps réel est plus simple à concevoir, il n'y a pas de gestion de points d'action, de gestion d'ordre du tour, de gestion d'attente maximale, etc.

Comme tu dis, l’absence de temps réel doit être voulue et non pas imposée, notamment par le fait qu'on choisisse PHP par défaut et qu'il est mal adapté à faire autre chose.

[Xenos]

Comme tu dis, l’absence de temps réel doit être voulue et non pas imposée

Si tu veux adapter tes moyens au but que tu t'es fixé, ok, pas de soucis, mais ce genre de méthode implique nécessairement que tes moyens puissent s'adapter. Ce n'est pas toujours le cas: le temps, les compétences, et les moyens financiers des créateurs amateurs ne sont pas toujours extensibles.

Donc, pour moi, j'en reste au fait que si tu te fixes l'objectif d'un multi-joueur en temps réel avec du web, il va t'en falloir les moyens et les compétences. Lâcher le web si tu veux faire du temps réel, ça facilite vachement les choses. Lâcher le temps réel si t'as déjà les connaissances PHP aussi. Lâcher le multi-joueur, ça peut aider aussi...

[L'Omniscient]

Alors, j'ai fais des analyses plus approfondies avec le test de performance de Firefox, et en fait j'ai presque 3 requête par seconde pour un joueur.
Sachant qu'une requête par seconde est une requête SQL (voire 2 selon là où on est situé).
Sachant aussi qu'il y a des situations où les requêtes sont bloquées puisque pas utiles.
C'est un peu plus que ce que j'avais dis, mais je comprends pas pourquoi ça utilise autant de mémoire au serveur (peut-être que c'est là la lacune de PHP/MySQL pour le temps réel, ça utilise trop de ressources ? Ou alors c'est une ressource global pour tous les joueurs et le nombre de joueurs augmente de manière minime l'utilisation de la mémoire ?) Je vérifierai attentivement les statistiques de dimanche et je vous ferai un retour (mais je crois pas pouvoir avoir les stats en temps réel, c'est dommage).
Si jamais la mémoire atteint les 100%, voire la dépasse, qu'est-ce qu'il se passe ? Ca rame pour les joueurs ? Si c'est que ça ça va. (Tant que c'est pas un crash de la page web )
En ce qui concerne la récupération de données avec Ajax je suis rassuré, ça a l'air très rapide (est-ce qu'il en est de même pour des UPDATES ?)
Et est-ce que, plus y a de joueurs, plus les traitements de requêtes sont longs ? J'ai cru comprendre que SQL faisait une pile et traitait les requêtes dans l'ordre alors que Node.JS traitait les requêtes en même temps. (Ca pour le coup j'espère que ça ralentira pas trop, je me rends pas compte en terme de chiffres).
Ya un moyen de faire traiter au SQL des requêtes en simultané avec une technologie ou autre ?
(Si je raconte des bêtises dites moi hein xD)

D'ailleurs si quelqu'un peut me renseigner sur ce que veulent dirent des requêtes SQL hit, miss, not et pass, je suis preneur.

EDIT: C'est dur d'analyser la rapidité d'exécution du code. Sur mon local c'est immédiat, mais sur internet c'est un peu long. A cause de ma connexion pourrie vous pensez ? (Elle est pas SI pourrie que ça, desfois je peux jouer à un jeu en ligne genre Starcraft II, mais parfois ça rame (en fait j'ai presque le même délai de rame).