Avec quoi vous développez votre jeu ?

[Kassak]

Hello !

Je me rapproche de plus en plus du moment de bascule où, ayant une idée de jeu derrière les oreilles  depuis des années, je n'aurais plus la flemme de m'y mettre.

Le dernier point qui me donne une excuse pour repousser encore et encore, c'est les technos. Avec quoi je vais faire mon jeu ? J'ai eu ma période "Unity c'est super", mais mon domaine c'est le web, et il y a encore je pense pas mal de choses intéressantes à faire... du coup me revoilà !

Le type de jeu : grande map vue de dessus, déplacement case par case, l'UI étant directement intégrée par dessus la map (Du style Wayward, qui lui est développé full JS), et pas de multi (plusieurs joueurs sur la map) pour le moment.

Étant développeur Symfony2, j'ai pensé coupler l'application full JS à un back en Symfony2, peut être même en mode API. L'idée d'utiliser un framework JS en plus ne m'aguiche pas plus que ça, mais pourquoi pas.

Ce que j'essaye d'éviter c'est le moment ou, après 6 mois de développement, je me rend compte que j'ai fais un mauvais choix au début. Ma motivation ne tenant qu'à un fil, faut que se soit du one shoot !

Un avis sur mes choix ? Des propositions ? Des suggestions ?

Et vous, quel type de jeu développez vous ? Avec quoi ? Pourquoi ? (oui ça fait plein de questions !)

Merci !

Edit : Peut être que le sujet serait mieux dans la catégorie juste au dessus

[Xenos]

Technos usuelles, et les miennes en gras.

Server side: PHP, Java, Rails, NodeJS (j'en oublis surement)
Client side: HTML (5), CSS (3), Javascript (Vanilla, jQuery), XSL, Plugin-spécifiques (Unity, NeoAxis,...)

Pour ma part, je trouve que JS est un effet de mode qui généralement alourdit inutilement le temps de développement et de maintenance. Les technos SVG sont adaptés pour des cartes de ce style, et l'interaction IHM sera déjà codée par le navigateur (donc, moins de trucs qui seraient de ta responsabilité). Le JS dans un site devient la respo du développeur du site, et donc, c'est du taff en plus.

Pour éviter les soucis de démotivation, je travaille selon deux principes:
• Releases régulières (toutes les 2 semaines par exemple)
• Sépare clairement les tâches dans le projet. Chez moi, le PHP fait le controleur du jeu, le modèle de données est du pur SQL (oui, des fichiers SQL, pas du SQL embarqué dans le PHP), la vue est du pur XSL, l'API est du XML (la sortie du PHP) etc. J'ai donc des "modules" (on va dire, des dossiers) ayant chacun une tâche définie. Si je me dis "merde, MySQL c'est pourri: j'ai plein de données géographique et Postgres serait mieux", je n'aurai qu'un bloc de code à changer, et non le projet entier (j'ai pas des "bouts" par-ci par-là).


Et n'oublie pas que du "full-JS coté client", ça peut te jouer des tours quand HTML6 sortira, ou quand de nouveaux supports apparaitront (ce sera à ta charge de faire en sorte que le jeu s'y adapte).

[niahoo]

Hum bas pas trop le temps d'argumenter pourquoi je les aime, mais j'aime beaucoup mes outils :

Serveur:
Langage: Elixir
Serveur web, websockets, framework web: Phoenix
Orm: Ecto
DB: PostgreSQL (dans le futur) et cowdb ou SQLite en attendant (pas utile pour le moment)

Client:
Librairies JS: Reflux, React, Keymaster
Build tools: Webpack + Babel + Stylus

[niahoo]

Mince j'avais pas vu ton post Xenos, tu peux montrer un exemple de modèle en SQL pur ?

[Xenos]

C'est pas super visuel... Le principe est simplement le suivant: la classe PHP représentant un traitement de données (un select des cases de la carte dans la zone [x0;y0]..[x1;y1] par exemple) n'embarque pas directement le SQL, mais charge le contenu d'un fichier SQL pour l'exécuter (grosso modo, du $pdo->prepareStatement(file_get_contents('/resources/sql/.../xxx.sql'))).
Du coup, j'ai une seule classe générique PHP, capable de charger et exécuter un fichier SQL, et un fichier SQL par traitement du modèle (plutôt qu'une classe PHP par traitement à faire dans le SQL, voir par type d'objet dans le SQL, cf l'un de mes récents billets sur MySQL et le traitement par lot).

Au taff, le "MVC" est appliqué différemment: un dossier "model", un dossier "view", un dossier "controlleur", chacun contenant des classes PHP qui, la plupart du temps, embarque des sous-langages (du HTML dans le view/mypage.php, du SQL dans le model/query/mesgenoux.php etc). C'est ignoble à coder (les HTML, les SQL etc sont des chaines de caractères, donc 0 coloration syntaxique, 0 auto-complétion, 0 refactoring possible). Donc j'ai fait différemment sur mes projets.

Même principe pour la partie vue: j'ai un fichier XSL par page affichée, qui utilise le XML que le controleur PHP génère. Du coup, si je veux altérer mon modèle → mettre à jour les fichiers SQL. Si je veux altérer la vue → mettre à jour les XSL (et comme ils peuvent être exécutés coté client plutôt que serveur, ce sont les joueurs eux-même qui pourraient altérer cette vue). Si je veux altérer le contrôleur (ajouter une feature) → mettre à jour le PHP. Ca peut aussi s'appliquer hors du code: tâche à faire → issue tracker; audit de qualité → SonarQube ; déploiement → Magallanes (ou Jenkins? j'ai pas décidé).

C'est ce que j'appelle "séparer les tâches du projet".

[niahoo]

Ok merci. Pour le SQL en PHP je préfère les ORM du style Eloquent :

$flights = App\Flight::where('active', 1)

               ->orderBy('name', 'desc')

               ->take(10)

               ->get();

ça te donne également la possiblité de n'avoir qu'un seul fichier pour toutes tes requêtes, le query builder, que tu invoques comme suit :

$user = DB::table('users')->where('name', 'John')->first();

Mais bon, j'aime bien avoir mes classes par modèle. C'est très léger et tu les glue dans un seul fichier en prod.

[Xenos]

$flights = App\Flight::where('active', 1)
->orderBy('name', 'desc')
->take(10)
->get();

Et tu as l'auto-complete ou le refactoring pour 'name' ?
C'est ce que j'aime dans le fait d'avoir un vrai fichier pur-SQL: on utilise seulement le SQL et on n'a plus besoin que d'outil SQL (plutôt que d'outils SQL+Erlang). On récupère ainsi toute la puissance et la souplesse du SQL (pas obligé d'attendre la mise à jour de l'ORM quand la nouvelle version MySQL sort).

C'est encore plus visible en XSL & compagnie, puisque je peux avoir, dans mon XSL (qui est un XML classique au fond) l'auto-complétion de n'importe quel langage XML (XSL lui-même, mais aussi XHTML, SVG, ou tout autre format passé ou à venir, y compris les miens).

Du coup, je bénéficie de l'auto-complétion, du refactoring, de l'analyse de SonarQube, de la coloration syntaxique, de l'analyse de l'IDE (même si celle de NetBeans n'est pas phénoménale), du découplage des versions PHP et MySQL (l'ORM requiert une version spécifique des deux, là je peux monter en version PHP sans me soucis du SQL et inversement)...
Il serait même possible, si on était plusieurs codeur sur Eclerd, d'avoir un codeur SQL pur, un codeur PHP pur, un codeur XSL pur etc... Alors que trouver des codeurs PHP+SQL+SQL serait bien plus dur (ça permet l'embauche de spécialistes).

[niahoo]

Hum non pas d'autocomplétion (à part celle automatique de sublime_text, je suis pas très IDE perso). Je n'ai pas d'outil SQL, juste des outils PHP. (ici c'est du php). Et quand une version de ma base de données sort je n'ai pas besoin de migrer immédiatement, ou bien ça reste très souvent compatible de toute façon. Les version sont très peu couplées. Mais je ne dis pas que ce que tu fais est mauvais, c'est une histoire de goûts.

Cependant, si je veux passer de MySQL à Postgres, mon code ne change pas d'un pouce, ça c'est un avantage qui me plait : je commence souvent par dev sur une SQLite pour avoir la bdd dans git. Et ensuite quand c'est prêt je déploie en prod sur Postgres.

Pour les vues, je ne saurais dire, je te fais confiance.

[Xenos]

Si j'avais à jongler régulièrement entre deux SGBD, je passerai par un genre de "meta-SQL" qui compilerait dans les différents langages SQL. Ensuite, y'a plus qu'à faire une petite classe PHP par SGBD pour aller lire le bon fichier et l'exécuter sur la bonne ressource BDD.

C'est une histoire de goût, libre à chacun, mais j'aime franchement bien ma petite structure (comparée à celle du taff, c'est le paradis). Y'a aussi qu'apprendre un ORM, c'est peut-être pratique, mais c'est moins plaisant à mon gout qu'apprendre un vrai langage. C'est plus parlant d'avoir un "dev MySQL" qu'un "dev ORMachin" (même si, suivant l'ORM, cela peut être plus lucratif d'être dans le 2nd cas). L'effet "je fais du jQuery, je sais pas faire de JS" est peut-être pour quelque chose dans mon choix...

[SorenS]

Pour ma part je pars sur la stack que je maitrise le mieux.

Pour le back du Symfony et en front du Angular. Symfony me sert au backend et à fournir les API, avec des bundles comme friendsofsymfony/rest-bundle.

En PHP/JS, j'ai l'impression que c'est là dessus que partent beaucoup de monde.

Sur d'autre projet, je fais aussi du Symfony en back et front, et du js via Angular ou autre pour les parties où il y en a besoin.