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).
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).