JeuWeb - Crée ton jeu par navigateur

Bonjour.

Pour créer mon jeu, je cherche un système un peu plus original que d'avoir une dizaine de bâtiments et de les faire monter de niveaux.
Alors j'ai un peu cherché, et je pense partir sur des bâtiments "à usage unique", c'est à dire que leurs capacités n'évolueront jamais.
En revanche, plusieurs bâtiments de même type viendront au fur et à mesure de l'avancée du joueur.

Par exemple, la première caserne permet de créer des soldats avec 5 pts d'attaque et de défense.
Il faudra attendre un autre bâtiment (un fort admettons) qui lui pourra générer de meilleurs combattants.

Dans le même temps, je ne souhaite pas que l'utilisateur puisse construire autant de bâtiments qu'il le souhaite.
J'ai donc pensé à un système de cases, je m'explique :

Le joueur possède 16 cases (exemple). Chaque bâtiment occupe un certain nombre de cases. Si le nombre de cases disponibles est insuffisant pou construire un autre bâtiment, l'utilisateur devra détruire ou acheter des cases supplémentaires.
Tout cela dans l'optique de pouvoir limiter l'avancée du joueur avec une variable supplémentaire, et non pas seulement les ressources.
L'intérêt est aussi de devoir choisir réellement entre une stratégie (si c'est bien fait) entre commerçants et attaquants, car le joueur ne pourrait pas construire tous les bâtiments.

Je précise que le jeu est en PHP, et que je ne pense pas avoir les capacités pour créer une map de la cité où l'on pourrait (comme en flash) déplacer les bâtiments etc..

Que pensez-vous de ces 2 systèmes ? De mon coté, je sais que ça implique que les bâtiments soient nombreux, sinon la durée de vie du jeu sera court, mais je n'ai pas envie de faire un système 'as usual'

Merci.

Salut,

cela reste "as usual", puisque, comme dit, beaucoup de jeux (pas forcément flash :p) permettent de placer des batiments sur les cases.
Dans ces jeux, si on place mal les bâtiments et que ceux-ci prennent plus qu'une case, on peut alors avoir des "trous" (on joue donc un peu au tetris si on est limite coté place). Sur un système sans affichage, avec un indicateur de la surface totale/libre/occupée, on n'aura pas ce problème. Donc cette approche simplifiera par rapport à un jeu où on place les bâtiments sur une carte.

Cela me semble tout à fait acceptable comme idée, à la condition:

• D'indiquer clairement quelle place est occupée et quelle place est libre (par exemple, via une jauge et un indicateur type "Occupation: 14 / 20 cases")
  
• De faciliter la vie du joueur en grisant les bâtiments qu'il ne peut pas construire (si je n'ai plus assez de cases pour faire une merveille, celle-ci est grisée pour que je vois, sans devoir cliquer, qu'elle n'est pas constructible; les UX type 'je clique sur le batiment pensant le construire et on me répond sèchement que j'ai pas la place après que j'ai choisi mon batiment' sont pénalisantes)
  
• D'indiquer clairement que le batiment requière X cases
  
• D'indiquer clairement, si le batiment ne peut être construit, qu'il ne peut l'être faute de cases (sinon, le joueur va se dire "mais flute! j'ai les ressources, pourquoi je peux pas construire ce truc?!")
  

Idéalement, pouvoir classer les bâtiments (tous, ou seulement ceux d'une catégorie, exemple le commerce) par place occupé me semble intéressant. Pouvoir les classes par "possibilité de construire ce batiment" aussi (c'est à dire les batiments que l'on ne peut pas construire sont en bas de liste, ceux que l'on peut construire sont en haut de liste).

Et, puisque tu n'a pas de représentation graphique, tu peux même remplacer le concept de "case" par celui de km², ou autre mesure de surface adaptée au jeu (à voir, si cela ne nuit pas à la compréhension).

(J'imagine déjà le message d'erreur en cas de manque de place: "Attention: il vous manque une case!" XD)

Salut.

Merci de ta réponse, je vais essayer de te répondre point par point :

Citation :cela reste "as usual", puisque, comme dit, beaucoup de jeux (pas forcément flash 10) permettent de placer des batiments sur les cases.

Mince, je n'ai pas eu l'occasion d'en tester un excepté en flash. Un nom ? ^^

Citation :Dans ces jeux, si on place mal les bâtiments et que ceux-ci prennent plus qu'une case, on peut alors avoir des "trous" (on joue donc un peu au tetris si on est limite coté place). Sur un système sans affichage, avec un indicateur de la surface totale/libre/occupée, on n'aura pas ce problème. Donc cette approche simplifiera par rapport à un jeu où on place les bâtiments sur une carte.

En effet, je connais cette problèmatique des trous en tant que joueur
Là en effet, toutes les cases seraient utilisables.

Citation :- D'indiquer clairement quelle place est occupée et quelle place est libre (par exemple, via une jauge et un indicateur type "Occupation: 14 / 20 cases")
- De faciliter la vie du joueur en grisant les bâtiments qu'il ne peut pas construire (si je n'ai plus assez de cases pour faire une merveille, celle-ci est grisée pour que je vois, sans devoir cliquer, qu'elle n'est pas constructible; les UX type 'je clique sur le batiment pensant le construire et on me répond sèchement que j'ai pas la place après que j'ai choisi mon batiment' sont pénalisantes)
- D'indiquer clairement que le batiment requière X cases
- D'indiquer clairement, si le batiment ne peut être construit, qu'il ne peut l'être faute de cases (sinon, le joueur va se dire "mais flute! j'ai les ressources, pourquoi je peux pas construire ce truc?!")

C'est clairement la vision que j'en ai : Je rage chaque fois que, dans un jeu web, je ne peux pas construire un bâtiment/techno et qu'on ne m'en donne pas la raison.

Citation :Idéalement, pouvoir classer les bâtiments (tous, ou seulement ceux d'une catégorie, exemple le commerce) par place occupé me semble intéressant. Pouvoir les classes par "possibilité de construire ce batiment" aussi (c'est à dire les batiments que l'on ne peut pas construire sont en bas de liste, ceux que l'on peut construire sont en haut de liste).

Je pense plus à classer les bâtiments par ordre d'apparition (les derniers débloqués seraient en premier), car ce système permet au joueur de ne pas se taper tous les bâtiments qu'il a débloqué plusieurs mois avant et de tomber rapidement sur ceux qui l'intéressent plus.
Par contre, un indicateur permettrait de distinguer les bâtiments constructibles (assez de ressources et cases) des autres. Dans le meilleur des cas, la raison sera directement affichée.

Citation :Et, puisque tu n'a pas de représentation graphique, tu peux même remplacer le concept de "case" par celui de km², ou autre mesure de surface adaptée au jeu (à voir, si cela ne nuit pas à la compréhension).

Très bonne idée que je vais creuser.

Encore merci à toi pour ton retour.
Si d'autres avis je suis preneur

Pour les non-flashs, je n'ai pas de nom direct en tête (jeu avec des bâtiments à placer et qui soit en ligne et opérationnel), mais canvas/svg sont les deux alternatives usuelles, la première offrant de la vitesse et la possibilité d'afficher de nombreux petits éléments, la seconde étant plus structurée (DOM) et standardisée (point de vue contenu).

Citation :tomber rapidement sur ceux qui l'intéressent plus.

Là, je suis pas d'accord: si les nouveaux bâtiments sont forcément mieux que les anciens, vire les anciens et remplace-les par les nouveaux, selon le principe des "générations": le bâtiment de génération 1 est remplacé par le bâtiment de génération 2, et on ne peut plus construire la génération 1 (qui n'apparait plus dans l'UI) car elle est en tous points moins bonne que la génération 2.
Si c'est pour garder les deux générations alors que la 2 est en tous points meilleure que la 1, alors on encombre inutilement l'interface.

Après, je trouve ce genre de système de générations très dommage car on a beau avancer dans le jeu, comme les bâtiments sont remplacés, on n'en débloque pas vraiment de nouveaux (on retombe, schématiquement, sur des bâtiments à niveaux finalement).

Je trouverai plus attrayant d'avoir de nouveaux bâtiments qui sont par certains points meilleurs (production d'unités plus puissantes par exemple), mais par d'autre moins bons (occupation de plus de cases, nouvelles ressources consommées, chantier plus long, etc).
Dans ce second cas, les bâtiments ne peuvent alors plus être classés du meilleur au moins bon, et on ne peut donc pas savoir à l'avance le bâtiment qui intéressera le plus le joueur: peut-être veut-il construire le bâtiment le plus récent qui produit de très lourdes unités d'artillerie, mais peut-être veut-il plutôt construire l'usine légère qui produira de petits chars mais qui sera très vite construite et mise en route. Ainsi, il n'est pas possible de classer les bâtiments pour tomber rapidement sur ceux qui l'intéressent plus sans être obligé de spéculer pour deviner ce que le joueur a en tête (stoooop! ne jamais faire cela -.-).

Donc, dans le cas des générations, les nouveaux bâtiments remplacent directement les anciens.
Dans le cas contraire où les nouveaux bâtiments s'ajoutent aux anciens, le joueur doit rester libre de classer comme il veut (du plus récemment débloqué au plus ancien, les constructibles d'abord, les bâtiments militaires en premier, etc) voir croiser les classements (classer par constructibilité, puis par type de bâtiment, puis par date de découverte, puis par quantité d'énergie consommée,...)

Il n'est pas prévu de remplacer tel bâtiment par un autre. Tous les bâtiments débloqués sont accessibles tout le temps.

Il est évident que les bâtiments les plus récents sont ceux qui rapportent le plus, ou produisent les plus grosses quantités ou puissantes unités.
En revanche, ces bâtiments coutent de plus en plus cher, mais la production/nombre de cases/ temps de récolte n'est pas forcément vers l'amélioration. Car je souhaite que le joueur soit présent pour qu'il puisse récolter les ressources produites (j'explique plus bas).
Ainsi, il est possible qu'un bâtiment débloqué 2 mois avant soit plus intéressant qu'un nouveau bâtiment, s'il a un meilleur rapport case/production/temps de récolte.
Mais là aussi, j'espère pouvoir créer un système ou tous les types de joueurs trouveront un compromis, afin que chacun puisse jouer selon le temps disponible qu'il a. Bien sûr, cela favorise un peu le joueur qui est connecté 24/24 sur le jeu.
Pour cela, je force la présence du joueur à l'heure où les bâtiments finissent leur production, et le joueur récolte ' à la main', via un clic sur le bâtiment ou autre. Sans map, j'imagine que je listerai tous les bâtiments en cours de prod/ prod finies.

Ex : Un bâtiment de 4 cases produit 10 ressources toutes les 10 minutes.
Un autre en occupant 6 produit 160 ressources toutes les 8 heures.

-> Le premier bâtiment (qui rapporte le plus au rapport case/prod/temps) de récolte n'est pas forcément plus récent que le second
-> Si le joueur ne peut se connecter que 1 à 2 fois par jour, il y gagnera à prendre le second
-> A l'inverse, le joueur acharné (celui connecté h24) prendra le premier car il y est gagnant

=> En résumé, je ne vois pas l'arrivage de ressources en automatique comme dans les ogame like
=> Les nouveaux bâtiments ne sont pas forcément plus avantageux pour le joueur, cela peut varier en fonction du type de joueur
=> Les bâtiments ne sont pas classés par 'génération' ou niveaux

Par contre, je pense tout de même à garder un système de classement par ordre de déblocage, peut-être avec des onglets (un pour les bat de guerre, un onglet commerce etc).

hello

quelle est la fréquence "rapide" de récolte que tu prévois. Est ce dix minutes comme ton exemple ? ou 1 heure ? 6 heures ? etc ?


grosso modo ce type de game play pour moi représente d'énormes risques de perte de joueurs :

si les premiers bâtiments doivent être récoltés (donc le joueur connecté) toutes les 10 minutes :
- le joueur casual (on dira une fois par jour) n ira jamais jusqu'au super batiment qu'on ne récolte qu'une fois toutes les 24 heures
- le joueur semi hard core va se laisser tenter puis s'apercevoir qu'il est fortement défavoriser par rapport au hard core gamer qui joue 12/24
- le joueur hard core voudra autre chose qu'un jeu non graphique


quelque soit la qualité de ce que tu développeras, mesure bien les pour et les contre de la connexion = récolte. Et pose toi même la question de pourquoi, a part dans les mmorpg 3D, la plupart des jeux partent du principe que la récolte se fait automatiquement.

en ce moment j'essaie goodgame empire (rien de révolutionnaire soit dit en passant, même super agaçant sur l'aspect monétisation). Ils ont fait un mix :

les batiments de production de ressource produisent automatiquement
et en plus par un système de quete et de clics le joueur très connecté peut récolter peut être 10 ou 20% de plus et ainsi rentabiliser sa connexion, sans pour autant décourager le casual

Hello !

Citation :quelle est la fréquence "rapide" de récolte que tu prévois. Est ce dix minutes comme ton exemple ? ou 1 heure ? 6 heures ? etc ?

Ca peut-être de 5-10 minutes à 12 ou 24 heures.

Citation :si les premiers bâtiments doivent être récoltés (donc le joueur connecté) toutes les 10 minutes :
- le joueur casual (on dira une fois par jour) n ira jamais jusqu'au super batiment qu'on ne récolte qu'une fois toutes les 24 heures
- le joueur semi hard core va se laisser tenter puis s'apercevoir qu'il est fortement défavoriser par rapport au hard core gamer qui joue 12/24
- le joueur hard core voudra autre chose qu'un jeu non graphique

Au contraire, j'essaye avec ce système "d'accrocher" le joueur. S'il arrive, qu'il construit un bâtiment et n'a pas d'autres actions à faire avant 2 heures, qu'il soit casual ou hardcore gamer il se tire..
Là au contraire je lui propose de "cliquer partout" dès les premières minutes du jeu, avec déjà quelques constructions et récoltes.
Enfin, c'est ma façon de jouer. Je ne compte pas le nombre de jeux alternatifs ou je me suis barré après 3 minutes, faute d'avoir des actions à faire..

Citation :quelque soit la qualité de ce que tu développeras, mesure bien les pour et les contre de la connexion = récolte. Et pose toi même la question de pourquoi, a part dans les mmorpg 3D, la plupart des jeux partent du principe que la récolte se fait automatiquement.

Sérieusement je n'en connais pas la raison. Peut-être parce que c'est plus dur niveau code ?

Sinon, je ne veux pas avantager à fond le hardcore gamer, mais il y aura de toute façon un avantage à être présent souvent, et j'estime ça normal.. Pas vous ?

(06-08-2014, 07:08 PM)Max72 a écrit : [ -> ]Au contraire, j'essaye avec ce système "d'accrocher" le joueur. S'il arrive, qu'il construit un bâtiment et n'a pas d'autres actions à faire avant 2 heures, qu'il soit casual ou hardcore gamer il se tire..

mais si tu lui donnes envie de revenir ? est ce grave qu'il ne reste pas connecté (donc qu'il ne bouffe pas de ressources serveurs :p ) ?

(06-08-2014, 07:08 PM)Max72 a écrit : [ -> ]Là au contraire je lui propose de "cliquer partout" dès les premières minutes du jeu, avec déjà quelques constructions et récoltes.
Enfin, c'est ma façon de jouer. Je ne compte pas le nombre de jeux alternatifs ou je me suis barré après 3 minutes, faute d'avoir des actions à faire..

n'oublie pas que toi en tant que joueur tu es attiré par certaines choses mais toi, as tu le comportement d'une majorité de joueurs ?

est ce que celui qui a 5 minutes ce jour va cliquer partout et s'apercevoir que s'il avait 10 minutes de plus il serait 4 fois plus puissant ? va t il rester celui la ?

et celui qui a le comportement du "je clique partout tant que j'ai a cliquer", vas tu être capable de lui offrir la qualité qu'il attend (graphiques, temps de réponse, etc...)

(06-08-2014, 07:08 PM)Max72 a écrit : [ -> ]Sinon, je ne veux pas avantager à fond le hardcore gamer, mais il y aura de toute façon un avantage à être présent souvent, et j'estime ça normal.. Pas vous ?

la question a mon sens à se poser n'est pas "est ce que x ou y est normal (sous entendu moralement)" mais "est ce que ton système va te permettre de capter bcp de joueurs sachant que le joueur a le choix d'une foultitude de jeux gratuits ou free to play -pro comme amateur-"

et à cette question je pense (mais c'est que intuitif, j'ai pas d'étude de marché la dessus) que tu ne capteras que très peu de joueurs pour les raisons ci dessus (mais encore une fois je peux me tromper)

d'où mon message (pas pour dégommer, mais pour alerter)

Ce n'est pas parce que les autres jeux proposent de la ressource en auto qu'il faut forcément aller dans ce sens, et je ne pense pas que c'est à vous que je vais l'apprendre, donc ma question est :
Selon vous, il vaut mieux reprendre tous les concepts d'ogame (ressources auto etc) et en faire un jeu qui sera comme tous les autres, donc qui n'attirera que quelques personnes ?
Ou tenter quelque chose au risque de se casser les dents ?

Dans les 2 cas, ça ne me ramènera pas grand monde, alors peut-être qu'il vaut mieux partir sur quelque chose de différent non ?

tu rentres dans un faux débat

je ne dis pas il faut tout faire comme x ou y (ogame n'est qu'une voie parmi les jeux d'empire), je dis sur un point particulier de gameplay que tu soulèves, il y a un souci. Etant entendu que pour une partie des joueurs c'est un vrai sujet effectivement

Tu peux peut être le résoudre autrement que comme l'ont fait les jeux d'empire, et là être innovant, mais je ne vois pas comment perso, je vois le problème mais pas de solution alternative, ce qui ne veut pas dire qu'il n'y en a pas.

essaie quand même ce jeu, car je pense qu'ils ont voulu résoudre ton point de gameplay
http://empire.goodgamestudios.com/


quant à ta question finale, pour moi la seule réponse est : tu es seul maitre a bord, donc fais comme tu veux, tout dépend de tes priorités (apprendre des techniques / avoir beaucoup de joueurs / monétiser / faire ton jeu idéal à toi) sachant que toutes ce valent dans l'absolu.