14-08-2017, 05:34 PM
Ouep, c'est sûr que si tu as besoin/veux la main entière sur la config et le serveur, le mutu, c'est pas fait pour 
A mon sens, il ne faut justement pas prendre en exemple les boites qui se lancent dans ces technos car ce n'est juste pas du tout le profil des créateurs qui viennent ici. Ces entreprises sont des groupes d'au moins 10 personnes (à la louche), travaillant à plein temps sur un projet, avec un objectif de rentabilité, un budget, une structure, etc. On est très loin des profils de créateurs indépendants, seuls ou par petits groupe de 3, qui se lancent là dedans en voulant simplement s'amuser (et qui risquent souvent de se bercer d'illusions en croyant qu'il suffit de passer 3h de ci-de-là pour sortir un jeu révolutionnaire en temps réel sur le web).
Pour ce genre de profil, je maintiens qu'il n'y a qu'une seule solution qui me semble véritablement viable, au sens où un jeu finira par sortir *et par vivre* (parce que derrière, il faudra la maintenir la communauté de joueurs): laisser tomber les features "kikoo avancées" du multi temps réel/la 3D/du user-generated-value pour utiliser ce que les créateurs connaissent et ont accès.
Si tu connais à fond les technos Node, Phoenix, etc, et que tu y as accès en deux gestes, pas de soucis, sers-t'en. A l'inverse, si tu as accès facilement à la vieille techno Apache/PHP/Sql et que tu la connais, prends celle-là. Car je doute sérieusement qu'un créateur indé ait le temps d'apprendre une nouvelle techno, de la rendre disponible (install & maintenance) tout en créant le contenu du jeu et en assurant la vie de sa communauté et la diffusion de sa création. Tout ça bouffe énormément de temps, et il me semble que le plus simple est de tailler dans la techno plutôt que dans la diffusion ou dans le contenu pour avoir un jeu qui finit par sortir et tenir.
Après, je me gourre peut-être, mais bon, sur mon exemple personnel, ça m'a l'air d'assez bien marcher. Après, le tiens diffère peut-être (si ta techno au boulot est NodeJS, t'auras peut-être plus facilement accès aux moyens techniques et aux connaissances pour le faire). Mais bon, pour avoir jeté un oeil de curiosité aux SDK AAA et à NodeJS, je peux te garantir à 100% que le 1er est 100x plus simple à mettre en place et à utiliser que le second. D'où mon poussage pour que les récurrents MMO/RPG révolutionnaires en temps réel 3D/VR où on peut tout faire et tout devenir s'orientent plutôt vers des SDK classiques que vers du Web.
Bref, toujours est-il que la techno PHP et les habituels hébergeurs ne sont pas adaptés au temps réel, et que pour ce genre de problématique, un SDK me semble être la solution la plus simple et rapide (mais comme toute solution qui réduit les soucis techniques à presque-zéro, elle impose de s'attaquer au contenu réel du jeu).
A mon sens, il ne faut justement pas prendre en exemple les boites qui se lancent dans ces technos car ce n'est juste pas du tout le profil des créateurs qui viennent ici. Ces entreprises sont des groupes d'au moins 10 personnes (à la louche), travaillant à plein temps sur un projet, avec un objectif de rentabilité, un budget, une structure, etc. On est très loin des profils de créateurs indépendants, seuls ou par petits groupe de 3, qui se lancent là dedans en voulant simplement s'amuser (et qui risquent souvent de se bercer d'illusions en croyant qu'il suffit de passer 3h de ci-de-là pour sortir un jeu révolutionnaire en temps réel sur le web).
Pour ce genre de profil, je maintiens qu'il n'y a qu'une seule solution qui me semble véritablement viable, au sens où un jeu finira par sortir *et par vivre* (parce que derrière, il faudra la maintenir la communauté de joueurs): laisser tomber les features "kikoo avancées" du multi temps réel/la 3D/du user-generated-value pour utiliser ce que les créateurs connaissent et ont accès.
Si tu connais à fond les technos Node, Phoenix, etc, et que tu y as accès en deux gestes, pas de soucis, sers-t'en. A l'inverse, si tu as accès facilement à la vieille techno Apache/PHP/Sql et que tu la connais, prends celle-là. Car je doute sérieusement qu'un créateur indé ait le temps d'apprendre une nouvelle techno, de la rendre disponible (install & maintenance) tout en créant le contenu du jeu et en assurant la vie de sa communauté et la diffusion de sa création. Tout ça bouffe énormément de temps, et il me semble que le plus simple est de tailler dans la techno plutôt que dans la diffusion ou dans le contenu pour avoir un jeu qui finit par sortir et tenir.
Après, je me gourre peut-être, mais bon, sur mon exemple personnel, ça m'a l'air d'assez bien marcher. Après, le tiens diffère peut-être (si ta techno au boulot est NodeJS, t'auras peut-être plus facilement accès aux moyens techniques et aux connaissances pour le faire). Mais bon, pour avoir jeté un oeil de curiosité aux SDK AAA et à NodeJS, je peux te garantir à 100% que le 1er est 100x plus simple à mettre en place et à utiliser que le second. D'où mon poussage pour que les récurrents MMO/RPG révolutionnaires en temps réel 3D/VR où on peut tout faire et tout devenir s'orientent plutôt vers des SDK classiques que vers du Web.
Bref, toujours est-il que la techno PHP et les habituels hébergeurs ne sont pas adaptés au temps réel, et que pour ce genre de problématique, un SDK me semble être la solution la plus simple et rapide (mais comme toute solution qui réduit les soucis techniques à presque-zéro, elle impose de s'attaquer au contenu réel du jeu).