Ouep, on se prive de beaucoup de trucs, mais on touche un large panel de support.
Perso, si on veut faire du spécifique, je pense qu'il vaut mieux lâcher le web: autant développer son jeu de chasse RV dans la rue sur un SDK dédié à la RV. Après, ce SDK compilera peut-être pour faire une sortie "Web" (au sens "délocalisé hors du support d'exécution, pour 'pas avoir d'install'"). Mais du coup, quand on part là-dessus, on a besoin de développer autant de jeux par support. C'est souvent hors de portée de nos "équipes" indépendantes amateures.
Y'a un extra-credit d'ailleurs sur le sujet "non-professionnal game development" (qqc du genre), qui résume bien la chose: "S'il suffisait de 3 mecs pendant 6 mois pour faire The Witcher 3, alors ExtraCredit ne ferait pas des vidéos mais du jeu". Il y a des pures jeux mobiles ici qui passent parfois (développés d'ailleurs sur le SDK Android, pas "from scratch dans le web"). Il n'y a pas souvent de jeux proposant deux versions complètes (ça quadruple le taff: double car 2 support, et re-double car il faut que ces supports soient synchronisés). La seule option réaliste, me semble-t-il pour nous, c'est de se contenter soit d'un seul support (et je persiste: il vaut mieux alors juste accepter de se faire aider en dev dans un SDK) ou d'abstraire le support (et on réduit les gameplay possibles).
[Après, en réfléchissant, la plupart de tes exemples TerRowan, sont surtout des questions d'interface et non de gameplay: un jeu avec une carte et des actions multiples peut se modéliser en SQL, se coder en format Web, et se skinner pour PC avec une interface de carte iso et différemment sous mobile. Idem pour un jeu de chasse en RV dans la rue: l'innovation est "juste" dans l'interface, et non dans le gameplay de fond, car on pourrait faire de même façon FPS PC, ou façon Roleplay texte. Cela ne résoud pas le soucis de devoir faire autant de design que de supports, mais en fait, le gameplay n'est pas forcément impacté. L'expérience de jeu sur chaque support diffère, oui, mais le fond du jeu reste constant. C'est quand même hors de portée d'un dev indé à mon avis]
Perso, si on veut faire du spécifique, je pense qu'il vaut mieux lâcher le web: autant développer son jeu de chasse RV dans la rue sur un SDK dédié à la RV. Après, ce SDK compilera peut-être pour faire une sortie "Web" (au sens "délocalisé hors du support d'exécution, pour 'pas avoir d'install'"). Mais du coup, quand on part là-dessus, on a besoin de développer autant de jeux par support. C'est souvent hors de portée de nos "équipes" indépendantes amateures.
Y'a un extra-credit d'ailleurs sur le sujet "non-professionnal game development" (qqc du genre), qui résume bien la chose: "S'il suffisait de 3 mecs pendant 6 mois pour faire The Witcher 3, alors ExtraCredit ne ferait pas des vidéos mais du jeu". Il y a des pures jeux mobiles ici qui passent parfois (développés d'ailleurs sur le SDK Android, pas "from scratch dans le web"). Il n'y a pas souvent de jeux proposant deux versions complètes (ça quadruple le taff: double car 2 support, et re-double car il faut que ces supports soient synchronisés). La seule option réaliste, me semble-t-il pour nous, c'est de se contenter soit d'un seul support (et je persiste: il vaut mieux alors juste accepter de se faire aider en dev dans un SDK) ou d'abstraire le support (et on réduit les gameplay possibles).
[Après, en réfléchissant, la plupart de tes exemples TerRowan, sont surtout des questions d'interface et non de gameplay: un jeu avec une carte et des actions multiples peut se modéliser en SQL, se coder en format Web, et se skinner pour PC avec une interface de carte iso et différemment sous mobile. Idem pour un jeu de chasse en RV dans la rue: l'innovation est "juste" dans l'interface, et non dans le gameplay de fond, car on pourrait faire de même façon FPS PC, ou façon Roleplay texte. Cela ne résoud pas le soucis de devoir faire autant de design que de supports, mais en fait, le gameplay n'est pas forcément impacté. L'expérience de jeu sur chaque support diffère, oui, mais le fond du jeu reste constant. C'est quand même hors de portée d'un dev indé à mon avis]