30-06-2020, 02:49 PM
Salut,
ca fait un sacré paquet de questions d'un coup, mais ok ^^
D'abord, niveau stack, je ne donnerai pas de comparatif avec ce qu'on a au boulot: le contexte n'est pas du tout le même, et la réponse serait donc hors sujet.
Ensuite, au vu du projet, je pense que tu ne pourras pas mener ça à bien. Il ne faut pas oublier que derrière les jeux cités, il y a des équipes entières, à plein temps, avec souvent de l'expérience et des moyens. Avec aucun de ces critères, se lancer dans un tel jeu, c'est une mauvaise idée je dirai. C'est comme si tu étais passionné de mécanique automobile, et que tu voulais fabriquer ta propre voiture, avec tes propres outils et tes propres méthodes. Un projet pareil, je commencerai par en délimiter complètement le contenu, le chiffrer en temps et en connaissances, et je m'orienterai vers les SDK qui permettront de faciliter au maximum le travail (exemple type en tête: Unity; niveau tutoriel "faites votre propre RTS avec Unity", ca doit se trouver)
Ca résoudra les problématiques du genre "où trouver des assets graphiques & sonores", "comment démarrer? vous avez un tuto?" ou encore "comment faire la navigation dans ma carte". Ce sont des thèmes déjà traités par ces SDK car très courants, pour lesquels les années d'expérience de ces outils ont couvert à peu près tous les cas possibles.
Là où sortir des FW/SDK/sentiers battus peut être utile, c'est si:
- tu as un concept/approche de gameplay innovant, qui ne rentre pas dans les cases déjà existantes (imaginons, tu souhaiterais faire une méthode de navigation ou de représentation de la carte totalement originale, plus ou moins inédite, pour expérimenter)
- tu as un projet de jeu bien assez simple pour ne pas requérir l'entièreté de la connaissance du FW/SDK (par exemple, pour un mini-jeu comme les miens, je n'avais aucun intérêt à passer 6 mois à apprendre l'utilisation de Unity: autant piocher dans mes connaissances existantes, qui a recoder pendant 2-3h certains éléments qui se seraient déjà trouvés dans un FW). cela peut aussi inclure le "Runtime" (un FW complet pour un mini jeu, c'est souvent un temps de chargement, parfois de 3s ou parfois de 30s, alors que le jeu derrière est simplissime)
Pour répondre à l'aspect DB, les sites un peu costaud (et les hébergements mutualisés) se servent des clusters des SGBD pour assurer la redondance et la continuité du service (et pour le serveur web applicatif, ce sont des load balancers et de la réplication aussi). En gros, tu as un serveur (parfois même plusieurs si t'as un sacré site) qui reçois les requêtes entrantes, qui les dispatche ensuite sur l'un des 3 ou 4 serveurs Apache web du site, pour répartir la charge (et pour, en cas de panne d'un serveur, pouvoir envoyer les requêtes vers un autre toujours debout). Idem pour la DB (avec, en plus, d'autres serveurs dits "slave" qui sont chargés de recopier en temps réel ce qui se trouve dans la DB, dite master, de sorte que si les serveurs de DB "master" meurent, une copie [backup] existe).
Mais sur un jeu web amateur, pas besoin de te prendre autant la tête
ca fait un sacré paquet de questions d'un coup, mais ok ^^
D'abord, niveau stack, je ne donnerai pas de comparatif avec ce qu'on a au boulot: le contexte n'est pas du tout le même, et la réponse serait donc hors sujet.
Ensuite, au vu du projet, je pense que tu ne pourras pas mener ça à bien. Il ne faut pas oublier que derrière les jeux cités, il y a des équipes entières, à plein temps, avec souvent de l'expérience et des moyens. Avec aucun de ces critères, se lancer dans un tel jeu, c'est une mauvaise idée je dirai. C'est comme si tu étais passionné de mécanique automobile, et que tu voulais fabriquer ta propre voiture, avec tes propres outils et tes propres méthodes. Un projet pareil, je commencerai par en délimiter complètement le contenu, le chiffrer en temps et en connaissances, et je m'orienterai vers les SDK qui permettront de faciliter au maximum le travail (exemple type en tête: Unity; niveau tutoriel "faites votre propre RTS avec Unity", ca doit se trouver)
Ca résoudra les problématiques du genre "où trouver des assets graphiques & sonores", "comment démarrer? vous avez un tuto?" ou encore "comment faire la navigation dans ma carte". Ce sont des thèmes déjà traités par ces SDK car très courants, pour lesquels les années d'expérience de ces outils ont couvert à peu près tous les cas possibles.
Là où sortir des FW/SDK/sentiers battus peut être utile, c'est si:
- tu as un concept/approche de gameplay innovant, qui ne rentre pas dans les cases déjà existantes (imaginons, tu souhaiterais faire une méthode de navigation ou de représentation de la carte totalement originale, plus ou moins inédite, pour expérimenter)
- tu as un projet de jeu bien assez simple pour ne pas requérir l'entièreté de la connaissance du FW/SDK (par exemple, pour un mini-jeu comme les miens, je n'avais aucun intérêt à passer 6 mois à apprendre l'utilisation de Unity: autant piocher dans mes connaissances existantes, qui a recoder pendant 2-3h certains éléments qui se seraient déjà trouvés dans un FW). cela peut aussi inclure le "Runtime" (un FW complet pour un mini jeu, c'est souvent un temps de chargement, parfois de 3s ou parfois de 30s, alors que le jeu derrière est simplissime)
Pour répondre à l'aspect DB, les sites un peu costaud (et les hébergements mutualisés) se servent des clusters des SGBD pour assurer la redondance et la continuité du service (et pour le serveur web applicatif, ce sont des load balancers et de la réplication aussi). En gros, tu as un serveur (parfois même plusieurs si t'as un sacré site) qui reçois les requêtes entrantes, qui les dispatche ensuite sur l'un des 3 ou 4 serveurs Apache web du site, pour répartir la charge (et pour, en cas de panne d'un serveur, pouvoir envoyer les requêtes vers un autre toujours debout). Idem pour la DB (avec, en plus, d'autres serveurs dits "slave" qui sont chargés de recopier en temps réel ce qui se trouve dans la DB, dite master, de sorte que si les serveurs de DB "master" meurent, une copie [backup] existe).
Mais sur un jeu web amateur, pas besoin de te prendre autant la tête