Quelles technos pour les bricoleurs du dimanche ?

[Kroc]

Bonjour à toute la communauté,
J'ai développé un jeu web il y a une dizaine d'années et, bien que ce fut une réussite aux regards de mes ambitions, j'ai complètement échoué à faire contribuer d'autres personnes.

Depuis quelque temps (années ?!!) j'hésite à repartir dans cette formidable aventure avec pour objectif la création d'une petite communauté de contributeur...
Contrairement à beaucoup de projets postés ici, l'objectif ne serait pas la monétisation et la communauté de joueur ne serait même pas la priorité

Seulement, voilà, je ne suis pas au fait des grandes tendances technique qui pourrait toucher les amateurs. Par technique, j'entends l'ensemble des techniques gravitant autour d'un jeu web: les plateformes clients, la création et le test d'assets,  le(s) langage (s) utilisé, mais aussi l'environnement d'autoring, l'édition du site/forum...

J'envisageais m'orienter vers babylon.js, JS/TS, node.js, mongodb et utiliser github pages pour le site. Évidemment, l'ensemble n'est pas trivial a appréhender, mais j'espérais trouver un un environnement online pour permettre l'édition de certaine partie du client et donner envie de contribuer.
Coté assets, j'imaginais des formes 3D très simple sans animation et quelques textures pour les décors.
Peut-être avez-vous d'autres avis ou une expérience à partager sur ce sujet ?

Et si l'idée de contribuer à un wargame open source sur le web vous branche, vous pouvez aussi me contacter... Même si je n'ai pas encore pris ma décision

[Xenos]

Salut,

wow, je viens de voir donc passer un combo "JS serveur + JS partout en fait + web + 3D + simplicité/amateur" (amateur n'est pas péjoratif!)

Si tu veux te monter un projet de jeu impliquant plutôt de la 3D, type FPS à la Medal Of Honor ou RTS à la World in conflict/AOE/Supreme Commander, alors il faut regarder du côté des SDK pour "jeux AAA" (Unity, Unreal Engine, Neoaxis). Là, la prise en main est immédiate (je trouve que Neoaxis, c'est le plus simple à prendre en main... en revanche, je pense qu'Unity et Unreal sont bien plus puissants et de biens meilleurs choix pour vraiment faire le jeu; c'est à dire que faire quelques essais sur NeoAxis pour comprendre comment marche la création de jeu, puis réellement commencer à faire son jeu sur Unreal Engine ou Unity, c'est la meilleure solution). Tu n'auras rien à gérer niveau "informatique système", ton boulot se limitera "juste" à créer le contenu du jeu. Pour les assets 3D, Unity et Unreal proposent un genre de "market place" où tu trouveras tout ce qu'il faut, directement utilisable et intégrable dans ton jeu, des gratuits et des payants. Et tu auras toute une communauté de créateurs déjà présents (via ces market place; car le contenu de ces market places a bien été créé par des gens, et parfois, ce sont des amateurs qui le font pour passer le temps).

Côté site du jeu, un simple Wordpress (qui est gratuitement hébergé par le site du même nom je crois?!) suffira. Un petit forum (pareil, des hébergeurs tout-prêt gratos, y'en a des brouettes), un Discord pour le tchat temps réel, et le tour est joué.

Sinon, du point de vue "management de projet", je pense que tu devrais d'avoir exposer (et définir) clairement ce que le jeu devrait être selon toi, pour être alors capable de choisir les bons "outils" pour le réaliste. Et si les bons outils ne sont pas à ta portée (faute de temps, de compétence, de budget, peu importe) alors tu pourras revenir sur la définition de ton jeu pour en trouver une qui te permettra d'utiliser d'autres outils, plus dans tes cordes.

[Kroc]

Merci pour ta réponse rapide

Je ne connais pas vraiment les moteurs que tu cite, mais ils me semblent vraiment trop (mais trop quoi ? là est la question ). Je n'envisage pas un jeu qui soutienne une comparaison avec un jeu commercial.

Les modèles 3D a vendre sont souvent de très bonne qualité mais présente quelques inconvénients: a moins de passer commande a un créateur, il sera difficile d'obtenir un ensemble cohérent, un peut typique et adapté a nos besoins. Ils risquent d'effrayer un contributeur débutant, enfin, ils ne sont pas toujours compatibles avec une licence open source.
Je comptais débuter avec les modèles des clones opensource de total annilation. D'ailleurs, si quelqu'un a tenté des imports, ca m'intéresse.

En fait l'objet de mon message n'est pas tant "comment puis-je me lancer dans le dev d'un jeu" (je saurais faire) mais plutôt "quelles seraient les techniques pour faciliter les contributions".

Mon premier jeu publié n'était pas pensé pour cela et utilisaient du GWT, Java et AppEngine. Il fallait même une version précise de blender pour générer les images à partir de modèles 3D. Résultat, sur les quelques bonnes volontés, personne n'a pu significativement contribuer. Quelqu'un a quand même développé une IA... en smalltalk ! la encore, plusieurs joueurs on voulu contribuer, mais la barrière d'un langage peu usité a calmé toutes les ardeurs

J'envisage donc un projet similaire, mais pensé pour être collaboratif dès le départ.
Le jeu serait donc largement inspiré de http://www.fullmetalgalaxy.com/ mais en pensant "open source / collaboration / long terme" avant "productivité / game play / effet a couper le soufle", domaine maintenant réservé aux pros.

[edit] pour être plus concret, j'envisage un wargame en tour par tour (donc pas ou peu d'animation) et multijoueur par partie (entre 2 et 12 joueurs). Les techno que j'avais cité me semble former une bonne base, mais elles effraieront peut être un peu. je ne sais trop.
A l'inverse, me parler d'un moteur comme unity ou unreal, c'est moi qui suis effrayé

[Xenos]

Un jeu "commercial" ne l'est pas parce qu'il utilise un SDK, mais parce qu'il a mis un contenu énorme dans ce SDK. Tu peux très bien faire des "petits jeux" sur Unity (regarde l'un des derniers posts de Ter Rowan par exemple). Libre ensuite à toi de voire pour l'exporter dans du web si tu le souhaites.

un peu typique + e comptais débuter avec les modèles des clones opensource de total annilation (+ ils ne sont pas toujours compatibles avec une licence open source à la rigueur), je trouve cela incohérent et incompatible... l'avantage de la banque de modèles, même si elle n'a pas vraiment de cohérence, elle te permettra au moins d'avoir des briques de base qui attireront les contributeurs. Un projet vide, ça n'attire pas (je trouve). Un projet qui a démarré et où il faudrait "changer le modèle du tank parce qu'il est genre 2e guerre mondiale et non futuriste", ça attire (ça fixe un objectif, et cela permet de voir où le tank sera utilisé, comment il sera utilisé, et donc, comment le créer pour coller au mieux à ce contexte).
Bref, cela te fera au moins un point de départ d'où tu pourras ensuite converger peu à peu vers ton projet idéal.

Pour faciliter les contributions, IMO, il faut intéresser les contributeurs. J'ai été intéressé par l'idée de faire un Fan Game sur Oban il y a des années de cela parce que, d'une part, je connaissais la série animée et je l'aimais bien et car d'autre part, Alucard avait déjà entamé des modèles 3D très bien fichus qui donnaient envie de continuer le boulot (même si cela a finit par capoter mais c'est autre chose).

Franchement, un wargame par partie de 2 à 12 joueurs, c'est juste totalement taillé sur mesure pour les SDK (ou les SDK sont taillés sur mesure pour cela). Télécharges NeoAxis, installes-le, lance-le (ie lance sa démo fournie avec) et tu verras que tu as déjà tout ce qu'il faut pour faire un RTS wargame tactique multijoueur à 2-12 joueurs par parties. Il ne tient alors plus qu'à toi de penser au gameplay que tu veux faire, de voir s'il n'existe pas déjà un jeu similaire, puis de l'implémenter en allant chercher les assets d'Unity/Unreal (comme dit, NeoAxis, c'est juste pour voir ce qu'un SDK sait faire "out of the box"). Tu gagneras des contributeurs en ayant déjà toute la communauté d'Unity/UE avec toi (= tu présentes les prémices du jeu et les premières screens sur leur forum, et tu auras sûrement des gens intéressés pour jouer voire aider), tu auras tous les modeleurs dont tu utiliseras les assets qui seront peut-être ravis de rejoindre l'aventure, et tu trouveras sans soucis des gens qui connaissent les langages de ces SDK.

Ce qui effraie les contributeurs ou les rebute, c'est d'être lâchés dans la nature sans savoir quoi faire, sur un projet qui n'est que du vent.
Si tu veux des contributeurs, il te faudra proposer un prototype à peu près décent, avec un élément de gameplay clairement identifiable et novateur (cf: StickFight, SpeedRunner, et..; SpaceCraft je crois) et une "todolist" claire. La première partie attirera le chalant, la seconde le fera rester et la 3e le poussera à participer.

Après, ce n'est que mon avis...

[Ter Rowan]

Un jeu "commercial" ne l'est pas parce qu'il utilise un SDK, mais parce qu'il a mis un contenu énorme dans ce SDK. Tu peux très bien faire des "petits jeux" sur Unity (regarde l'un des derniers posts de Ter Rowan par exemple). Libre ensuite à toi de voire pour l'exporter dans du web si tu le souhaites.

j'ai certainement dit quelque chose de très... intelligent sur Unity mais.... je sais plus quoi ? t as un lien ?

sinon je suis d'accord avec tout le monde :

si tu veux faire un jeu 3d, a moins d'avoir une idée un peu farfelue, les moteurs unreal et unity me semblent la meilleure option

mais quand je vois ton jeu, c est pas de la 3d, c'est des cases avec des changements au tour par tour, donc ces moteurs n'ont pas d'intérêt à mon sens

Côté front
là je bosse sur angular X (5, 6 ... numérotation à la con), c'est pas mal, mais y a de la complexité si on creuse un peu profondément. Maintenant, je suis pas sûr que pour un jeu tu aies besoin de descendre dans la mine jusqu'à tomber sur du très costaud.
En plus ca permet de faire du svg dynamique (jamais essayé mais pas mal pour un jeu comme le tien)
Après y en a multitude d'autres

Côté back
utilise ce que tu sais déjà utiliser, quitte à mettre à jour, t as pas besoin non plus d'une énorme techno donc prend celle que tu connais. Perso j'aime pas trop  ni java ni javascript côté back mais c'est une question de goût

[Kroc]

Bon... Xenos m'a convaincu de regarder les moteurs type unity et unreal. Et franchement, ca ne me semble pas adapté. Le web n'est vraiment pas la cible et les capicités sont orienté vers les jeux temps réel.
Il y en a cependant d'autre, qui seraient peut être adapté... J'ai été intéressé par superpower mais le projet semble déjà mort

Comme le fait remarquer TerRowan, le jeu que je souhaite (ré)implémenter a très peu d'animation. La 3D est pour moi une façon de permetre différent angle de vue et limiter le nombre d'image à télécharger.
En effet, l'interface du jeu actuel est un assemblage d'image dans des div (le canvas n'exitait pas encore). Imagine le même genre en vrais 3d: ca nous permetrait de tourner autour du champs de bataille, avoir une vu d'enssemble tout en téléchagant moins d'assets.
A titre de comparaison, il y a actuellement une vingtaine d'unités, une douxaine de couleur, 6 positions et 2 angles de vue soit environ 3000 images... que j'aimerais remplacer par 20 petit modèles 3d.

Générer du svg, oui il faudrait que j'étudie cette possibilité mais je craint qu'il soit plus difficile de demander au contributeur de faire des dessins vectoriel. On vois beaucoup de gens faire du pixelart ou des modèles 3d, le reste est plus exotique.
Et même si on peu zoomer, les angles de vue resterons les mêmes.


Pour la techno, je ne souhaite justement pas me limiter à ce que je connais actuellement, mais découvrir celles qui seront plus accessible, quite à être plus limitée. L'expérience montre qu'un backend en java et des outils exotiques limitent drastiquement le nombre de contributeur.

Il y a quelques années, le php semblait le language de prédilection des développeurs de jeu web amateur. Qu'en est il aujourd'hui ? Le javascript n'est il pas en train de prendre le dessus ?

Les bases SQL sont elles toujours à la mode ? Ou au contraire, est-ce qu'un mongodb n'attirerait pas un peu plus les néophites ?

[Xenos]

limiter le nombre d'image à télécharger.
C'est bien trop tôt pour te poser ce genre de question.

20 petit modèles 3d.
Indépendant de la notion de SDK ou non. Après, si t'as des gens qui savent faire du modèle 3D, ça peut se faire.

Qu'en est il aujourd'hui ?
Y'a une "hype" sur le JS pour le côté serveur, perso, je la trouve surfaite. PHP tient encore bien la barre dans l'ensemble (de même que Java, de mémoire). Idem avec MongolDB: il n'y a, au fond, aucun intérêt à se jeter dessus. Attirer des "néophites", perso, je ne suis pas sûr que cela soit un bon argument (tu attireras des gens qui n'ont jamais mené de projet au bout, je doute donc de leur capacité de réussir...) Pour info, MySQL (et probablement tous les autres SQL) gèrent aussi le JSON et l'approche "noSQL" (parce que bon, NoSQL, c'est bien, mais on met quoi à la place? et de ce que j'ai vu, souvent, c'est... une réinvention de SQL en JS).

A mon avis, il faut clairement clarifier le projet, et que tu définisses ce que tu voudrais faire comme jeu, et les moyens dont tu disposes (les technos connus et les gens qui sont déjà présents pour aider). Là, on pourra essayer de faire coïncider les deux.