# Jeux vidéo > Jeux vidéo (Discussions générales) > Le coin des développeurs >  Création d'un Tower Défense

## Ariath

Bonjour,
je m’intéresse énormément au jeux video en général, et en ce moment plus particulierement au style Tower Defense du genre *Plant vs Zombie*, *Kingdom Rush* ou encore  *beware planet earth* qui vient de sortir il y a quelque jours.

Ces jeux m’intéressent car ils m'ont l'air "faciles" d'accés pour apprendre à construire un JV, en tout cas dans l'élaboration de la structure du projet (en gros ca à l'air facile à mettre en place contrairement à un jeu de grande envergure).



En tout les cas Je viens vers vous pour en apprendre plus sur l'envers du décor des JV.Je précise avant tout que Je n'ai pas l'ambition de vouloir créer un jeu a part entière dans la mesure ou je ne taquine que trés légèrement le *c++* et à peine plus le *css* et le *html*.Bref je n'ai pas les compétences requises.

Mais justement, je suis curieux.*Quelles compétences faut il pour créer un jeu de ce genre ?* 
*Quelle est la chaine de production logique ?* 

Création du design : interface,  ennemis, terrain, éléments divers ?
Création des animations :  interface,  ennemis, terrain, éléments divers ?
Création du moteur de collisions ?
Création du code : pour générer les vagues ennemmis etc...

Bref je suis pommé complet, et *je me tourne vers vous pour vous soutirez un maximum d'info, et au pire quelques liens ou autre Tutoriaux ??*

Si je dis des énormités, corrigez moi (je fournis le fouet  ::P: ).

----------


## war-p

Heu, déjà avant de commencer un projet quel qu'il soit, il faut définir les tenants et les aboutissants, à savoir réaliser une analyse, en gros pour un jeu, réfléchir au game design, plus celui-ci sera réfléchis plus le reste sera limpide. Après tu pourras envisager de passer à la production. L'idéal étant d'avoir de bonne bases en programmation.

Voilà, avec ça tu peux réaliser un projet de la taille de plantVSzombie.  :;): 

PS : Tu parles de c++, html et css, je te répondrai que peu importe le langage (bon, un jeu en css seul ça risque d'être compliqué hein) mais, par exemple, j'ai réalisé un petit jeu en utilisant seulement de l'html 5, javascript et css3 (et beaucoup de php, mais c'est une autre histoire)

----------


## Ariath

Non non mais je n'ai aucunement la prétention de réaliser un JV complet, comme je l'ai dis je n'ai aucune compétence spécifique.
J'essaye d'en apprendre un maximum au sens général du terme, pour voir tout les éléments à intégrer dans la construction d'un JV.

Aprés je suis curieux sur la mise en forme du jeu, je voudrais savoir comment on réalise des animations (avec quel logiciel) comment on réalise des collisions etc...

Tu m'a parlé de programmation, mais justement programmer avec quoi ? C ? C++? java etc..je veux débroussailler un peu tout ca  ::P:

----------


## Zerger

mouais, PlanteVSZombie mine de rien, c'etait pas un petit jeu code a la va-vite. Tout etait vraiment bien concu dans ce jeu, que ce soit le gameplay, les musiques, les graphismes. Donc n'espere pas sortir un jeu a la hauteur de PvZ en quelques mois, sinon tu vas vite etre decu  :;): 

Le mieux est de commencer par un petit jeu simple le temps que tu butes sur des erreurs et que tu apprennes mieux a gerer ton projet. Puis tu essaie de l'ameliorer petit a petit

J'avais voulu faire un petit shoot them up quand j'etais plus jeune en utilisant Delphy je crois. C'etait du langage objet, tu posais des boutons-fonctions (input clavier, clock, affichage), tu rentrais ton code et tu pouvais rapidement faire qqchose qui tourne. J'avais reussi a faire un scrolling pas trop degeu, 3-4 tirs differents... ca volait pas haut mais pour un neophyte de la prog, j'etais content
Mais bon, ca remonte a plus de 10 ans et je suis largue en langage de prog desormais

L'avantage d'un tower defense, c'est que tu n'as pas d'IA a gerer, ca me parait un bon choix

----------


## Tomaka17

Si c'était moi qui devait réaliser ça :

Tout d'abord création d'un mini cahier des charges
C'est pas forcément nécessaire quand tu es tout seul car tu as tout dans la tête, mais quand tu travailles en équipe il faut être absolument certain que tout le monde ait la même vision des choses que toi.
Par exemple pour Plants vs Zombies, j'indiquerais que le jeu est en 2D, qu'il y a des vagues de zombies (de 1 toutes les 20sec au début jusqu'à 1 par seconde à la fin du jeu environ) qui entrent par la droite de l'écran, qu'ils se déplacent lentement, que l'objectif du joueur est d'empêcher ces zombies d'atteindre le bord gauche de l'écran, que la zone de jeu est découpée en 8x9 cases (si mes souvenirs sont bons) plus un bord à gauche et un bord à droite, que la perspective n'est pas "vu du dessus" mais légèrement plus basse, ainsi de suite

Bref, pas mal de choses à écrire même pour un petit jeu
Ça paraît bête mais si tu n'écris pas que les zombies se déplacent lentement par exemple, il y a des chances qu'un dév de ton équipe va coder des zombies à la left for dead qui courent comme des malades alors que toi tu n'avais pas du tout ça en tête.


Ensuite, choix du "support". Tu sais déjà pour quelle plate-forme tu vas coder ton jeu (PC, web, iPad, etc.) il faut également choisir un "support" : moteur 3D, langage de programmation, etc. en prenant normalement en compte le coût de chaque technologie en terme de temps et d'argent.


Au niveau artistique, il faudrait dessiner : un arrière-plan, ainsi que les différentes parties des zombies : jambe, tête, corps. Il suffira alors de poser chaque élément l'un sur l'autre pour obtenir un zombie, et de déplacer progressivement chaque élément pour l'animer. Évidemment ça parait simple comme ça, mais "déplacer progressivement chaque élément" c'est une étape vraiment complexe
Les plantes et les tondeuses ont des animations un peu plus complexes, donc il vaut mieux utiliser la méthode "dessin animé" en dessinant chaque image de l'animation l'une après l'autre, puis en les faisant défiler rapidement.
Pas de secret de ce côté là, un bon dessinateur avec une tablette graphique si tu veux de la qualité


Au niveau du code, je pense qu'il vaut mieux commencer directement par créer le jeu, et tu verras plus tard pour les menus.
Tu commences donc par écrire un code qui va charger l'arrière plan et l'afficher, puis la musique de fond par dessus si tu l'as déjà.
Tu écris ensuite le code d'affichage des plantes en fonction de leur case (plante dans la case 2,4 il faut calculer sa position à l'écran)
Tu places ensuite manuellement quelques plantes directement via le code source (tu n'as pas d'interface encore) et tu codes les zombies qui vont de la droite vers la gauche.
Tu codes ensuite le comportement des plantes qui tirent et des zombies qui mangent les plantes. Il n'y a pas besoin de "moteur de collision" puisque tu connais la position des zombies. Quand tu vois qu'un zombie est sur la même ligne qu'une plante et suffisamment proche, passage en mode "bouffe".

Il ne te reste plus qu'à coder l'interface de posage des plantes (ce qui est peut être une des parties les plus difficiles si tu n'as pas de moteur), félicitations tu as un jeu ! À ce moment là, tout fonctionne, tu crois avoir fait le plus dur, et pourtant tu n'as qu'un jeu pourri, à toi de le rendre meilleur en ajoutant différents types de zombies, en ajustant la vitesse/points de vie des zombies, etc. Beaucoup de jeux considérés comme "merdiques" n'auraient pas beaucoup de retouches à faire pour devenir de bons jeux.

Tout au long du développement, utilise des "placeholders" si nécessaire. Par exemple tu n'es pas obligé de dessiner une jolie plante qui tire de jolies boules, tu peux dessiner ça toi même en 5mn comme un enfant de 4 ans et mettre ce dessin dans le jeu, dessin que tu remplaceras plus tard par sa version définitive.

----------


## Ariath

> mouais, PlanteVSZombie mine de rien, c'etait pas un petit jeu code a la va-vite. Tout etait vraiment bien concu dans ce jeu, que ce soit le gameplay, les musiques, les graphismes. Donc n'espere pas sortir un jeu a la hauteur de PvZ en quelques mois, sinon tu vas vite etre decu


Je ne dis pas que PvsZ est un jeu facilement réalisable, je dis que ce genre de jeu me parait plus facile à concevoir par rapport à d'autre, aprés je peux me tromper.Et je me répète mais je ne vais pas faire un jeu comme PvsZ dans les mois ou les années à venir, même si j'aimerais :;):  , mais je n'en suis pas du tout capable pour les raisons que tu as données. 

Donc, si je veux réaliser quelque chose comme ceci :



*Imaginons :*
- mon terrain de jeu fait *5 cases sur 5* (les dimensions seront déterminées plus tard dans mesure ou je suis en mode fiction  ::): )
- le jeu est en *scrolling horizontal*
- *un carre noir* est déjà sur le terrain
---- il se situe sur le 1er carré blanc en haut a gauche de mon terrain de jeu
---- il est statique
---- *il tire un même carré noir* toute les secondes
-------- ce carré se déplace horizontalement
-------- ce carré se déplace de gauche a droite
-------- ce carré met 2 secondes pour atteindre le dernier carré blanc de droite
- *un rond noir* se situe sur la dernière case blanche tout à droite
---- il est statique (je fais simple) 
---- lorsqu il est touché 2 fois par carré noir il disparait

*Donc, si je veux réaliser ce genre de chose, vers quelle langage de prog je dois me tourner ?* (encore une fois si vous avez des tuto je suis preneur)

----------


## war-p

Tu peux regarder XNA, il y a un très bon tuto pour faire un shmup ici même sur ce topic (Sébum, tu pourras me verser de l'argent  ::ninja:: ), le langage c'est le c#, c'est très facile pour les débutant. Et en plus le shmup est pas très éloigné du gameplay d'un tower defense, donc bon, tu devrais progresser vite.

Sinon, très bien le commencement de réflexion sur le gamedesign!

----------


## Tomaka17

Un langage de programmation c'est juste un outil, il n'y a pas de langage qui permet de faire ceci et de langage qui permet de faire cela
C'est comme si tu disais "je veux aller à Milan en voiture, dois-je louer une peugeot ou une opel ?"

----------


## Zerger

Je sais qu'il existe une logiciel RPG creator, ya pas des equivalents pour d'autre jeux?

En plus, tout en haut du forum, ya un post de Sebum qui file des tutos pour faire des jeux en Visual..

----------


## war-p

Nan, un vrai jeu vidéo doit être programmé en assembleur, tout le monde le sait!  ::ninja::

----------


## Zerger

> Nan, un vrai jeu vidéo doit être programmé en assembleur, tout le monde le sait!


Apres avoir concu son propre ordinateur...J'espere que c'etait sous-entendu

----------


## war-p

Oui, évidemment.

----------


## Tomaka17

Sinon pour répondre précisément à la question "quel langage utiliser ?", la réponse c'est "celui que tu maîtrises le mieux"
Programmer des jeux c'est pas forcément évident quand tu connais pas, alors en plus si tu dois apprendre un langage en même temps, c'est encore moins évident

Mais si tu ne maîtrises pas de langage en particulier, le C# comme cité plus haut est pas trop mal

----------


## war-p

J'approuve ce message, la doc est bien faite, abondante, et le langage est très puissant.

----------


## Quittouff

Bonjour à tous!

Voilà un sujet très intéressant qui m'a poussé à m'inscrire pour y répondre. Pour l'anecdote, je suis le programmeur de Beware Planet Earth, et c'est comme ca que je suis tombé sur ce thread. Déjà, merci de nous citer ça fait toujours très plaisir  ::): .

Je ne vais parler que de la partie technique pour ma part car je suis sur que quand notre Game Designer va tomber sur ce thread il ne pourra s'empêcher de vous répondre en détail pour tout le reste.
Tout d'abord il faut savoir que même si Plant Versus Zombie (PvZ), "Beware Planet Earth!" (BPE) et kingdom Rush (KR) ont l'air simple comparé à d'autres il sont encore relativement complexes. Je ne connais pas les détails pour PvZ et KR sur les temps de développement, mais sur BPE, il nous a fallu 18 mois à 4 à plein temps (en partant de 0), je reviendrai en détail la dessus.

Mais rentrons dans le vif du sujet. Si tu es seul tu as en gros 2 possibilités: soit tu sais programmer (t'as l'air de t'y être mis et donc c'est cette solution que je vais développer) soit tu sais pas ou peu programmer. Dans le dernier cas tu peux t'orienter vers des choses comme GameMaker qui permet de faire des jeux relativement rapidement et même très amusants.

*Quel langage faut-il pour faire un jeu?*
C'est en fait pas la meilleure question car il n'y a pas de réponse unique et suivant ce que tu veux faire le langage changera.

*Alors comment choisir un langage de programmation?*
Il y a déjà eu des pistes dans les posts précédents: d'abord définir ta plateforme cible : PC? XBOX Live? PSN? Smartphone? Web? c'est une étape indispensable car tous les langages ne sont pas compatibles avec toutes les plateformes. Une fois que tu as défini ta plateforme principale il y a encore 3 choses à définir: la rapidité avec laquelle tu veux développer ton jeu, est-ce que tu veux t'étendre à d'autre plateformes, et tes gouts/compétences.
J'ai rarement vu d'autres personnes conseiller de suivre ses goûts, mais moi je trouve que c'est important (après les contraintes techniques bien entendu) parce que plus tu es déjà à l'aise avec un langage, plus tu iras vite.

De même il faut te demander si tu veux faire tout de 0 ou prendre un moteur existant. Si tu prends un moteur existant il est fort probable que le langage te seras imposé par la techno du moteur. Le moteur très à la mode en ce moment dans le jeu vidéo c'est Unity http://unity3d.com/ (je ne suis pas spécialiste de Unity donc je te laisse y regarder). C'est gratos pour une utilisation non commerciale et y a une grande communauté.

Mais donc tu as l'air de vouloir t'orienter vers du C++ et partir de rien (courageux! :D). C'est ce qu'on a fait sur BPE et le C++ est mon langage de prédilection seulement attention c'est pas forcément le plus adapté à ce que tu veux faire. Est-ce que apprendre le C++ est un objectif en plus de développer ton jeu ou est ce que c'est vraiment faire des jeux ton objectif principal?

Les avantages du C++ sont principalement que c'est portable, puissant, assez bas niveau pour pouvoir gérer la mémoire, communauté gigantesque, librairies à foison etc. Cela dit il y a de très gros inconvénients aussi.
Gérer la mémoire est relativement compliqué (c'est paradoxalement un des principaux avantage et aussi inconvénient) et pas forcément nécessaire pour un petit jeu, il n'y a pas de framework de base inclus au C++ non plus, juste la librairie standard permettant de gérer les tableaux, chaines de cararctères, hash tables... On peut y ajouter des librairies mais ils faut un minimum de manipulations qu'il n'y aurait pas avec un built-in Framework comme dans C# ou JAVA

Tu as parlé aussi du dev web, la c'est un peu moins mon domaine donc je ne m'avancerait pas trop et je laisserai les mecs qui s'y connaissent mieux que moi répondre, mais je déconseillerais tout de même le PHP qui est un langage un peu erratique.

Vu que tu parles de jeux principalement PC, je vais partir du principe que tu veux faire ton jeu sur PC.
Une bonne alternative au C++ comme l'a fait remarquer war-p c'est le C# avec XNA. T'as l'avantage d'avoir toute la facilité et la puissance du Framework .NET, c'est beaucoup plus facile à mettre en place/programmer que du C++. Par contre oublie le portage sur autre chose que XBox (mais je pense pas que ce soit ton objectif dans premier temps de toutes façons)
Perso je préfère le C# au JAVA, car même si JAVA est plus portable, je trouve que c'est une monstruosité niveau perfs. Cela dit tu peux y jeter un oeil si tu veux et des jeux (comme minecraft) sont développés en JAVA.

Si tu choisi le C++ et de ne pas utiliser de moteur, il te faudra encore choisir ta librairie graphique cad Direct3D(D3D) ou OpenGL
Direct3D fait partie du sdk DirectX de microsoft, il n'est donc supporté que par windows et XBox, la communauté est très importante et la plupart des jeux PC tournent sous DirectX
OpenGL est open source, est supporté par à peu près toutes les plateformes, la communauté est aussi très importante et il est indispensable sur mac, Linux, et autres smartphones

Il ya des tutoriaux de débutant à avancé pour les deux, je te conseille ni l'un ni l'autre en particulier, à toi de faire ton choix avec ce que tu peux lire. BPE tourne en DirectX, mais pourrait très bien tourner avec OpenGL.

Une fois que tu t'es familiarisé avec tout ça tu peux commencer à afficher des choses (mais ca fait déjà du taff si tu n'es pas trop à l'aise avec tout ca)

A ce moment là tu vas pouvoir te lancer dans ton projet de jeu. Moi je t'aurais conseillé de partir sur un truc encore plus simple qu'un TD pour te familiariser avec les outils, le langage et l'affichage, genre un puissance 4 ou quelque chose dans ce gout là. Ca peut paraitre "naze", mais c'est en commençant petit qu'on apprend et qu'on se crée de bonnes bases. Je me rappelle encore du projet de noel de ma première année de prog "dessinez un sapin de noel dans la console"... Je reconnais que c'est frustrant de commencer petit, mais ca évite de se décourager et ca permet de créer de bonnes bases.

Ta question portant sur comment faire un TD cela dit je vais te répondre sur ça:

Pour commencer il faut, comme tu as l'air de l'avoir fait, créer une grille qui va contenir tous tes objets (en gros un matrice ou chaque case contient une liste des objets présents dans la tile qui correspond)

Ensuite tu crées tes entités "Tour" et "Creep" que tu places dans ta grille.

Dans un premier temps t'embêtes pas avec les projectiles et les collisions c'est pas le plus important, contente toi d'updater ta tour pour qu'elle tire à intervalle régulier sur ton creep et fasse des dommages directement. Ensuite tu donnes des points de vie à ton creep et tu les réduit chaque fois que ta tour tire, jusqu'à le faire mourir quand il arrive à 0 ou moins.

Pareil, dans un premier temps contente toi de faire avancer ton creep tant qu'il est vivant et considérer que le niveau est perdu quand il arrive à un position "plus à gauche" que ta tour.


Quand t'arrives à faire ca tu pourras commencer à réfléchir à des animations, des collisions etc mais avant ca serait prématuré imho.

Je pense que t'as de quoi digérer pour mon premier post xD
Je vais tout de répondre à tes questions générale sur comment les choses on été faites sur BPE:




> Création des animations : interface, ennemis, terrain, éléments divers ?


Pour les animations en 2D il y a en gros 2 possibilités comme l'a dit Tomaka17: les sprites  ou réellement animer des faces. Les sprites c'est prédessiner toutes les positions d'une animation et les faire s'enchainer à l'affichage pour donner l'impression d'un mouvement fluide (tout à fait comme un dessin animé). Animer les faces c'est découper ton personnages en plusieurs morceaux (genre en rectangles) et transformer séparément chaque élément. La deuxième est plus complexe mais permet de faire beaucoup plus d'animations à moindre cout de performances. Dans BPE nous sommes parti sur cette dernière technique d'animation. Tous les éléments sont créés et animés sous flash duquel on exporte un swf. Un outil maison permet ensuite de récupérer les informations contenues dans le SWF afin de créer des fichiers d'animation lisible avec notre moteur maison.




> Création du moteur de collisions ?


Alors je sais pas trop ce que tu entends par moteur de collision. Si tu parles de moteur physique, il y en fait très peu de jeu 2D qui en utilise un. Les collisions c'est juste vérifier si 2 éléments ne se rentrent pas les unes dans les autres à chaque moment que nécessaire. Dans BPE les aliens on en effet des collisions, sous forme rectangulaire englobantes, pour permettre de savoir si un alien est à porté d'une tour ou savoir si un projectile rentre en collision avec celui-ci. Mais ca reste très très simple comme détections de collisions.




> Création du code : pour générer les vagues ennemis etc...


Pour générer les vagues d’ennemis c'est un peu plus compliqué. Tu peux soit prédéfinir tout l'enchainement de la vague dans un fichier (ou dans ton code), soit réellement générer les vagues. Dans BPE les vagues sont éditées et donc prédéfinies. Dans PVZ il me semble qu'elles sont générées aléatoirement avec des règles précises. La première façon est la plus simple à coder et à régler.

J'avais dit que je reviendrai sur le temps (qui peut paraitre très long) de développement que nous avons eu sur BPE. Déjà il faut savoir que 4 dans le monde du jeu vidéo (en général) c'est une toute petite équipe et que 18 mois (toujours en général) est un temps de dev moyen. Ce qui fait que ca été si long c'est déjà que nous avons développé notre techno (moteur) de 0 http://lightmare-studio.com/fr/pourq...moteur-maison/. Si on devait refaire BPE aujourd'hui avec le moteur dans l'état actuel, il pourrait etre fait en environ 8 mois (je ne parle que de la partie dev, je me rend moins compte pour tous les assets). Ensuite il faut savoir que la dedans nous avons "perdu un peu de temps" avec la création de la boite et plein de trucs pas intéressant du tout quand on veut juste faire du jeu vidéo  ::P: . De même il y a plein de choses qui ont été faites de manière à pouvoir par la suite facilement créer du contenu supplémentaire, permettre aux joueurs de modifier le contenu etc... et ce genre de choses rallonge le temps de dev car c'est un peu plus complexe que de faire "tout en dur" comme on dit.

Voilà j'espère que ce pavé t'aideras, t'en auras surement un autre très vite de la part de tohwaku

----------


## Tohwaku

Salut Ariath (et les autres  ::P: )
Je me présente rapidement, je m'appelle Fough, je suis game designer et animateur sur "Beware Planet Earth!" et oui, mon codeur a raison, je ne peux pas m'empêcher de sauter sur un thread du genre (d'ailleurs actuellement mes yeux pleurent des petits chatons et des poneys arc-en-ciel)

Tout d'abord je te dirais que si tu veux créer un jeu mais que tu n'as pas de solides bases en programmation, le mieux est peut-être, au moins dans un premier temps, de t'orienter vers un programme de création assisté tel que Construct ou Game Maker. Personnellement, j'utilise Game Maker, que ce soit pour tester des concepts dans mon coin ou pour prototyper certains morceaux de nos jeux. "Beware Planet Earth!" a été en partie éprouvé et réglé sur un prototype Game Maker rudimentaire, et je dirais que, en ce qui concerne les mécaniques abstraites et le déroulement de base du jeu, il était fidèle à plus de 90% à ce que nous avons au final.

Mais commençons par le début : qu'est-ce qu'un jeu vidéo ? Déjà, c'est un jeu, et mine de rien, il ne faut pas l'oublier. Et pour faire un jeu, il faut en fait se poser relativement peu de questions, mais pouvoir répondre à toutes celles qui surgissent par la suite. Ce que je donne ici est ma logique personnelle de design, elle ne fonctionne pas forcément pour tout le monde. C'est juste la façon dont je décompose les problèmes que je rencontre.

Déjà, il faut savoir que pour "Beware Planet Earth!" (qui est en effet inspiré de Plants versus. Zombies mais qui s'en éloigne pas mal au final, vu qu'il tire aussi d'Insaniquarium, Diner Dash, Defense Grid, etc.), un de nos grands chevaux de bataille était la recherche d'un gameplay moins passif que la plupart des Tower Defense. Personne dans l'équipe n'était particulièrement fan de cet aspect, et à titre personnel, j'en fais une philosophie de design  ::): 
Cette simple décision a énormément influencé le gameplay du jeu, et je t'encourage d'ailleurs à jouer à la démo pour t'en rendre compte (le dernier niveau de celle-ci est ainsi particulièrement parlant). La démo se trouve ici : http://lightmare-studio.com/games/bpe/fr/

Pour partir des questions de base, donc, je dirais qu'il faut se poser les questions suivantes (c'est presque de la théorie pure à ce niveau-là) :

*1- But du jeu, conditions de victoire, conditions de défaite*
Quel est le but du joueur ? Y a-t-il une condition de victoire et si oui quel est-elle ? Y a-t-il une condition de défaite et quelle est-elle ? (on peut peu très bien n'avoir que l'une des deux, ou les deux, mais ne présenter aucune des deux en fait un type de jeu à part que je ne couvrirai pas ici). Dans "Beware Planet Earth!", il n'y a pas une vraie condition de victoire, comme souvent dans le Tower Defense : il faut survivre à l'assaut des creeps jusqu'au bout. Dans Beware, comme dans Defense Grid, la vie du joueur est cependant représentée par des unités passives (ici, les vaches), et il possible de gagner s'il en reste au moins une à la fin de l'assaut. La condition de défaite est bien entendu de se faire piquer toutes ses vaches au cours du niveau.

*2- Moyens et outils à disposition du joueur*
Quels moyens le joueur a-t-il à sa disposition pour atteindre ses buts ? C'est le point le plus copieux, et dans l'industrie, on a tendance à parler des "trois C" (character, camera, control). Personnellement je n'utilise pas littéralement les 3C, mais ça aide pas mal. Je préférerai donc donner ma propre méthode, qui s'en rapproche mais me contraint moins (encore une fois c'est personnel, faut adapter !). Je ne suis pas fan de dogmes qui ne s'appliquent qu'au jeu vidéo, et les 3C ne s'appliquent hélas qu'au jeu vidéo. J'essaie plutôt de penser en termes de jeu général (jeu de société, jeu en bois, jeu de carte, jeu de kermesse, etc.)
Je vais prendre uniquement l'exemple de "Beware Planet Earth!" vu que c'est sur lui que porte en partie ta question.
La question des moyens trouve en grande partie sa réponse dans le genre même du jeu, le Tower Defense : le but est d'empêcher les Martiens de voler des vaches (donc d'aller d'un point A à un point B, et d'en revenir), en mettant des tours de défense. Comment mettre des tours ? En cliquant et en les posant. Le Zapper (le pistolet laser qui permet de tirer directement sur eux) est aussi arrivé très tôt dans le design, afin d'éviter la frustration de voir un Martien hors de portée des tours prendre tranquillement une vache, sans que le joueur ne puisse y faire quoi que ce soit.
C'est aussi en se posant la question des moyens, comme dans les 3C, qu'il faut se poser, effectivement, la question de l'interface, au sens large. Le joueur a-t-il un avatar ? Comment se contrôle cet avatar ? Quels sont les outils à sa disposition ? Comment interagit-il avec chaque chose ? Mais tout bon moyen est limité. C'est le point suivant.

*3- Contraintes et limites du joueur*
Qu'est-ce qui limite le joueur ? Quelles sont ses contraintes ? Ce point est très important, c'est lui qui donne du sel au jeu. Si on suit de façon bête et méchante le but du golf, il suffit d'attraper la balle à la main, de marcher jusqu'au trou, et de l'y lâcher. Le but "mettre la balle dans le trou" est donc atteint. Est-ce fun ? Pas vraiment. Ce qui est fun, c'est d'essayer de faire la même chose en se foutant à des dizaines de mètres du trou, et de taper la balle avec un bâton qu'on appelle un club. C'est donc une contrainte forte, une limite. Le club est ce qu'on appelle l'interface, puisqu'il lie le joueur au jeu en limitant en plus ses capacités physiques.
Et c'est très précisément ce qu'on appelle "les règles du jeu". Une règle c'est une loi, et une loi, une limite. Dans un tower defense, il est facile de percevoir les règles : déjà, on interdit souvent de placer une tour sur le chemin (on peut y placer des pièges, mais pas une tour permanente qui bloquerait les monstres > PvZ est entièrement fondé sur le non respect de cette règle puisque le terrain constructible EST le chemin). Ce sont les contraintes au placement. Ensuite, il y a une contrainte économique, de laquelle découle la stratégie de placement : chaque tour a des caractéristiques, des forces et des faiblesses, et surtout un prix, qui équilibre l'intérêt de la tour et évite qu'on ne pose que la plus puissante. Le prix appelle naturellement... la question des ressources, qui est "comment est-ce que le joueur obtient plus de ressources ?".
Comme "Beware Planet Earth!" est un hybride entre time management et tower defense, donc un jeu très orienté "temps réel", nous avons pris le parti de faire comme dans PvZ : le joueur doit poser des générateurs (les Fabriques d'Engrenages), et ramasser les Engrenages qu'ils génèrent en leur cliquant dessus. Nous voulions éviter le principe de ne choper des ressources que quand un ennemi meurt, parce que c'est notablement plus difficile pour le joueur, ça n'autorise pas beaucoup d'erreurs ni de stratégies très variées sur le peu de minutes que fait un niveau, et c'est moins nerveux (ce ne sont pas des vérités absolues, ce sont juste des visions personnelles du TD). Cela signifie cependant qu'il y a une ouverture de l'économie qui fait que nous ne maîtrisons pas la production du joueur (il peut donc avoir très peu d'Engrenages, ou décider d'en générer beaucoup).

Ces trois questions couvrent l'essentiel de la base du design. A chaque fois que tu te les poses, à tous les niveaux du design de ton jeu, les réponses doivent te venir assez naturellement. Si tu galères et ne vois que des mauvaises solutions, il est possible qu'il faille remettre en question ton design, au moins en partie. Mais un jeu doit toujours sembler logique, et ne jamais violer sa logique interne. Et surtout toujours, toujours être compréhensible pour le joueur (c'est le plus difficile) et toujours être juste (si tu ne peux pas être juste dans une situation donnée, alors avantage le joueur, pas le jeu !).

Après il y a ce qu'on appelle pompeusement l'élégance, qui est en fait un principe simple mais difficile à cerner et à appliquer : quand tu as une possibilité d'arriver à un résultat de façon simple ou de façon compliquée, il faut toujours choisir la plus simple, même si elle est moins spectaculaire. La solution simple est en fait la plus difficile à trouver dans 99% des cas ; une erreur de débutant est de privilégier instinctivement la solution compliquée.

Et donc, sans déconner, le design, c'est rien de plus que se poser des questions simples et y répondre simplement. Après tu déroules en inventant des nouveaux trucs, et si possible en utilisant ce que tu as déjà, pour exploiter au mieux tes bonnes idées (exemple dans Beware : le Zapper permet de tuer les Martiens directement, soit. Mais pourquoi ne pas créer des interactions autres avec les Martiens ? Ainsi le Martien Incognito n'est pas visible par tes défenses tant que tu ne l'as pas Zappé un coup, le Savant Fou crée des boucliers qui doivent être zappés, etc.). Il faut bien sûr savoir ne pas être trop gourmand (parce que sinon ton codeur fait la gueule, hein Quittouf ?  ::P: ), il faut savoir appliquer le Rasoir d'Occam et virer tout ce qui n'a pas une légitimité forte, même si c'est quand même super sympa et que ça fait mal au coeur de s'en débarrasser. Comme je le dis souvent, la difficulté en game design, c'est pas de trouver des bonnes idées (tout le monde en est capable), la difficulté c'est de distinguer celles qui sont vraiment les plus adaptées à un jeu donné. Un bazooka arc-en-ciel qui rétrécit les ennemis ça peut paraître cool comme ça, mais dans un Tetris-like, ça sert à rien.

Je clos ainsi ce post déjà long, n'hésite pas à poser d'autres questions, je ne suis pas avare en étalage de science  ::P: 

Par ailleurs je t'invite aussi à aller faire un tour sur notre blog : http://lightmare-studio.com/fr, car il y a pas mal d'articles sur les rouages du développement.

Sur ce, je vais bouffer.

----------


## Tomaka17

Il y a tout le studio qui débarque  ::o: 
Cela dit la publicité fonctionne puisque je vais aller jeter un coup d'oeil à ce TD que je ne connaissais pas

----------


## war-p

C'est bon ça d'avoir des mecs qui ont de l'expérience! Vous devriez intervenir plus souvent! /HS

----------


## Tohwaku

Tomaka17 : techniquement c'est la moitié du studio qui a répondu  :^_^: 

war-p : et t'imagines même pas le kiff que c'est de parler de ce qu'on aime aux (autres) joueurs  ::wub:: 


Si vous avez des questions n'hésitez pas !

----------


## war-p

Alors imagine le kiff quand lesdits joueurs sont aussi programmeur!

----------


## Tohwaku

T'es programmeur ?

----------


## Anonyme957

Fascinant  ::o: . Veuillez continuer, tous.  :Cigare:

----------


## war-p

> T'es programmeur ?


Oui!

----------


## Louck

Personnellement, je suis entrain de développer avec un collègue un Tower Defense dont les actions du joueur sont limités par un deck de cartes, avec la capacité de fusionner ces mêmes cartes entre-elles (pour mélanger leurs effets, les améliorer, etc...)
Parmi les cartes, le joueur peut autant poser des tours de défenses, qu'invoquer un "sort offensif" sur l'ennemi ou appliquer une modification sur le terrain. M'enfin, c'est l'idée de base.


Par manque de temps (mémoire d'ingénieurs + été) j'ai dû faire une pause sur le développement. Mais dès qu'une première version alpha pointe son nez, je pourrais présenter notre travail.

PS: Il y a déjà un bon travail de fait sur le projet  :;): .

----------


## Zerger

Whoa, bravo les mecs de BPE pour vos paves de reponse  ::): 

Ca fait tjr plaisir de lire les reponses de passiones !

----------


## Quittouff

En fait je viens de réaliser que nous n'avons pas répondu à 2 des questions d'Ariath (qui sont pourtant en gras (de canard!))




> Quelles compétences faut il pour créer un jeu de ce genre ?


C'est là tout le problème, un jeu comme PvZ et BPE (c'est un peu moins le cas pour un jeu flash quoi que...) ca demande beaucoup de compétences et surtout des compétences très variées. Dans les grands domaines il te faut (un (ou plusieurs pour multiplier le fun)):
Un game designer (GD)
Un level designer (LD)
Un programmeur
Un graphiste
Un animateur
Un musicien.
Des testeurs
Si tu as toutes ces compétences assez développés tu peux développer un jeu comme ça tout seul, mais en fait c'est rarement le cas d'avoir quelqu'un qui est assez compétent dans tous les domaines. Surtout qu'on est souvent spécialisé dans une sous partie de ces différents dommines, ainsi un programmeur peut etre plus à l'aise avec du code Gameplay et un autre plus avec du code d'affichage ou que sais-je. Mais tu peux t'en sortir si chacun prend 2/3 casquettes sur un projet de taille raisonnable.




> Quelle est la chaine de production logique ?


Alors comme je comprends pas trop la question je vais répondre d'abord aux étapes logique de création d'un jeu comme BPE (du moins d'après moi parce que c'est pas toujours ce qui se fait) c'est:

*1) La préprod :* 
C'est la phase ou le GD va définir les bases du jeu les règles, éventuellement commencer à tester certaines mécaniques de jeu sur un proto (à l'aide ou non du programmeur).
C'est là ou le graphiste va rechercher et définir l'univers du jeu, des différents éléments définis par le GD, et définir un "Target Render" cad typiquement à quoi devrait ressembler un screen du jeu une fois terminé.
C'est la ou le programmeur fait de la R&D (Recherche et Développement, typiquement tester plein de trucs nouveaux voir ce qui pourrait coller avec ce qu'on cherche à faire). Code des nouvelles fonctionnalités au moteur, commence à définir les contraintes et les outils qui vont être utilisé (et en développer si besoin est)

*2) La production :* c'est la plus grosse phase
C'est la que tout le monde avance avec ce qui a été défini en préprod.
Le GD bosse avec le programmeur pour être bien sur que tout est comme il l'a pensé et répondre aux questions du programmeur ou réfléchi à ce qui aurait pu lui échapper dans un premier temps.
Le GD règle aussi les différents élément et les équilibre.
Le graphiste produit tous les assets graphiques du jeu.
L'animateur anime les-dits assets.
Le LD construit les levels en fonction de ce qui a été défini en GD.
Le programmeur code toutes les interactions du joueur, l'IA, poursuit les outils/éditeurs, l'interface etc...
Le musicien crée les sons (SFX) et musiques et les intègre et les mixe dans le jeu

On la parsème aussi de focus tests qui permettront de voir la réaction d'un joueur cible à tout ce qu'on a pu développer (on avait fait un article la dessus) http://lightmare-studio.com/fr/playtests/

*3) Le polish:*
C'est le moment ou le jeu est pratiquement final (typiquement une Beta) et ou on va fignoler les derniers détails, soigner un peu plus les interfaces, rerégler les anims etc. Et c'est toujours plus long que ce qu'on aurait pu penser (c'est meme virtuellement infini).

*4) Le Debug:* le jeu n'avance plus et on fait la chasse aux bugs
ca se chevauche typiquement avec le polish et des fois des bugs de moindre importance peuvent etre considérés comme du polish. En gros la tout les testeurs (en fait souvent tous les membres de l'équipe quand l'équipe est trop petite/pauvre pour avoir son propre QA) passent leur temps à finir le jeu et a faire tout ce qu'il est possible de faire dans le jeu pour traquer le moindre bug. Et un bug ca ne concerne pas que les programmeurs contrairement à ce que l'ont pourrait penser! Un bug ca peut etre une donnée de jeu mal formatée ou éronnée qui fait planter le jeu ou au moins se comporter anormalement

*5) Le Marketing!* (qui dans l'idéal est commencé tot et menée en parallèle du dev)
Et oui, un jeu qui doit se vendre pour faire vivre ses auteurs bin faut en faire la pub, en parler, faire des interview des démos, des presskits etc et ca prend ca aussi pas mal de temps.

*6) Le support*
Bin ouais parce que malheureusement nous ne sommes que des hommes (et des femmes) et il y a forcément des problèmes à la sortie du jeu qu'il faut résoudre au fur et à mesure que les joueurs les rencontrent.


Après si la question concernait le pipeline de production dans chacune des étapes ca marche souvent par itérations:
Pour l'intégration d'une nouvelle fonctionnalité:
- On défini une (liste de) fonctionnalité(s) à intégrer
- on les dev
- on les teste
- on les livre (sous forme d'un nouvelle version interne à l'équipe)
- et on recommence

et on peut itérer pour chacune des features, c'est à dire qu'une fonctionnalité n'est pas figée une fois intégrée, mais va évoluer au fur et mesure des tests et des focus tests.

---------- Post added at 15h51 ---------- Previous post was at 15h45 ----------

@lucskywalker
Hé bien bon courage à toi et ton pote! Faut pas se laisser abattre, car c'est souvent terminer projet qui est le plus dur.

----------


## Ariath

Déjà *merci à tout les intervenants*, les créateurs de BewarePlanet et les autres (insignifiants en comparaison  ::P:  non non je rigole merci à tous).

J'ai des tonnes de questions c'est sur, mais je ne peux pas les poser pour l'instant vu les connaissances générales (sur la programmation notamment) qui nous séparent...j'ai besoin d'apprendre les bases, ensuite j'aurais surement des questions précises.

Le but ultime serait de développer un jeu (tower defense) sur PC, mais en étant réaliste je me dis que c'est tout bonnement impossible vu la masse de travail à abattre seul, c'est pour ca que je suis venu ici, c'est pour prendre plus ou moins conscience des différentes problématiques à gérer, et surtout savoir par ou commencer.

Je vais donc me renseigner sur *gamemaker*  , sur le *langage C# et xna* , j'y verrais déja plus clair.


Je dévie du sujet de base, mais je voudrais m'adresser à l'équipe de *BPE*, j'ai entendu parlé de votre jeu grâce au site* JV.com* sur lequelle ils ont fait une news concernant votre jeu, par contre je n'ai pas vu de pub ailleurs.

Donc mon questionnement se situe sur la publicité :
**Comment ca se fait que votre campagne de pub soit si restreinte ?* (ou peut être que c'est moi qui traine pas assez sur le net)
* *Avez vous visé un marché étranger en proposant votre jeu en Anglais par exemple ?*
**Avez vous proposé votre jeu à steam ?*  (car il semble avoir toute les qualités requises pour y être) EDIT : j'ai lu sur votre forum qu'apparemment c'est en cour..
**quelles sont vos projets videoludique pour la suite ?* pour allez plus loin *est ce que vos projets futur dépendent du succés de BPE ?*

En tout les cas, maintenant vous avancerez plus vite grâce à vos connaissances acquises ces derniers mois suite à la sortie de BPE, dans le cas ou vous souhaiteriez créer un autre jeu.



*PS :* Attention, Le PS du mec qui se permet de donner des leçons alors qu'il a pas le quart de la moitié du talent des gens à qui ils parlent :

Je trouve qu il y a un défaut à votre jeu, en tout cas je le perçois tel quel, c'est que comparé a PvsZ (oui oui c'est inévitable ::P: ), lorsque les ennemis se font shooter, on a du mal à savoir au bout de combien de projectile ils meurent, concrètement l'alien de base je ne sais pas au bout de combien de shoot de barril de base (celui a 200) ils meurent.Du coup ca enlève, je trouve, un aspect tactique et stratégique que je voyais dans PvsZ.

Évidemment *ca reste un avis perso, basé sur la démo* car je n'ai pas encore acheté le jeu...mais ca ne saurait tarder.En dehors de ca j'apprécie énormément la direction artistique, l'humour, le joueur qui n'est pas passif (assez rare dans les TowerDef), la difficulté qui m'a l'air bien dosé etc...Bref, j'espere que vous pondrez d'autres jeux.

EDIT : bon bah je l'ai acheté, ma copine veut jouer aussi, j'ai pas pu lui dire non, je suis faible...

----------


## Tohwaku

Salut Ariath !
Eh bien déjà merci de ta question, puisqu'elle nous a amenés sur ce topic, et on s'amuse bien  ::): 

C'est bien d'être réaliste sur la masse de boulot à abattre, mais il faut aussi savoir rester positif  ::):  Avec quelques tutoriaux et si tu n'es pas trop gourmand, tu arriveras à faire un bon petit jeu. Il vaut mieux un petit jeu bien fait et amusant qu'un gros jeu bancal.

Hop je vais répondre à tes questions en gras.

**Comment ca se fait que votre campagne de pub soit si restreinte ?* 
Alors à ce sujet je vais juste apporter une précision de vocabulaire. La "campagne de pub" est un élément d'un domaine plus général qu'on appelle la "communication", et cette communication consiste, en effet, à faire connaître le jeu. Cela passe par l'envoi de communiqués de presse à divers sites et magazine, par exemple pour annoncer la sortie du jeu, avec quelques screenshots et une vidéo éventuellement, ainsi qu'éventuellement la version du jeu pour test. Cependant, il y a beaucoup beaucoup de jeux qui sortent tout le temps et la presse n'a pas forcément le temps (ni l'envie) de couvrir tous ces jeux. Nous sommes ainsi relativement insignifiants pour l'instant, c'est bien compréhensible ; personne ne nous connaît, nous n'avons rien fait avant. Ça n'empêche pas que quelques sites aient répercuté nos news, et nous les en remercions. Donc, en dehors du temps que cela prend (et il n'est pas négligeable) ce type de comm' ne coûte rien.
Et donc, pour en revenir aux termes que tu as utilisés ("campagne de pub"), c'est une autre paire de manches. La plupart des sites et des magazines gagnent de l'argent grâce aux sponsors qui achètent de la place sur leur site pour y placer des pubs. Par exemple, EA sort un jeu, boum ils ont un budget et un service marketing qui vont s'employer à acheter disons 3 jours de pub en page principale pour annoncer le jeu (enfin beaucoup plus en réalité), et ce sur plein de sites, gros ou petits. Bien évidemment, plus un site est gros et peut se targuer d'avoir un énorme trafic (= beaucoup de visiteurs réguliers), plus il peut faire monter les prix de sa pub.

Et qu'en est-il de Lightmare dans tout ça ? Eh bien nous n'avons tout simplement pas d'argent pour acheter ce type de publicité. Mais vraiment pas  ::P:  Non seulement c'est assez cher, mais en plus, déjà que nous bouffons des pâtes pour finir le dév, on ne peut pas trop se permettre ce genre de dépenses. Non que nous pensions que c'est inutile ; c'est utile ! C'est juste qu'il faudrait avancer énormément d'argent avec un espoir d'y gagner plus que ce qu'on engloutit, et que nous n'avons littéralement pas cet argent.

Nous ne pouvons donc compter que sur trois types de publicité, gratuits, mais à l'efficacité variable :
1- La couverture presse standard (ce que j'expliquais plus haut) ainsi que les (bonnes) reviews, qui feront connaître le jeu et éventuellement donneront envie de l'acheter.
2- Les "spotlights" chez les distributeurs : nous essayons de faire distribuer le jeu sur divers sites de vente (comme Steam, mais pas que), qui, en échangent d'un pourcentage du prix de vente, hébergent le jeu et gèrent les transactions, mais qui peuvent aussi aider le jeu à se faire connaître (par exemple en foutant un gros pop-up avec "Nouveau jeu super de la mort !" marqué dessus).
3- Le bouche à oreille positif, avec les joueurs qui ont acheté le jeu et qui en parlent autour d'eux, conseillant à d'autres joueurs de l'acheter. Cela peut être très puissant si le jeu plaît (Plants versus Zombies en a beaucoup bénéficié, même si PopCap était déjà extrêmement connu à cette époque), mais si le bouche à oreille ne s'amorce pas, ça peut carrément capoter.

Comme tu le vois, la "communication", qui est un aspect essentiel du succès d'un jeu vidéo, est un élément difficile à maîtriser si on a pas de budget à mettre dedans, et même ainsi, on n'est pas à l'abri de l'échec.

** Avez vous visé un marché étranger en proposant votre jeu en Anglais par exemple ?*
La vente dématérialisée a ceci de merveilleux que la distribution du jeu n'est pas limitée dans l'espace : un américain peut acheter le jeu, suivi d'un chinois, puis d'un anglais, puis d'un français, puis d'un espagnol, etc. Faire le jeu en français uniquement, alors que nous avons les connaissances linguistiques en interne pour le faire en anglais, aurait été une perte d'occasions de vendre le jeu partout, sans pour autant nous faire économiser beaucoup de temps de prod. Donc oui, nous avons toujours cherché un marché international, et nous comptons ajouter des langues selon le succès du jeu (par exemple l'espagnol et l'allemand). Nous n'avons cependant pas encore planifié ces ajouts, car l'anglais, pour l'instant, suffit à toucher une grande partie des joueurs. Le français est plus un bonus parce que nous sommes français, pour être franc, et si nous avions dû ne supporter qu'une des deux langues, cela aurait sans conteste été l'anglais !

**Avez vous proposé votre jeu à steam ?*
Pour autant que nous aimions la transparence, nous ne pouvons pas divulguer ce genre d'informations. Mais il est plus difficile d'être sur Steam qu'on ne le croit généralement. Ceci dit bien évidemment, c'est un de nos objectifs, non seulement au niveau commercial, mais aussi au niveau personnel ; nous sommes fans de VALVe, se retrouver sur leur plate-forme serait une belle occasion de déboucher une bonne bouteille.

**quelles sont vos projets videoludique pour la suite ? pour allez plus loin est ce que vos projets futur dépendent du succés de BPE ?*
Nous avons plusieurs pistes, et toutes en effet dépendent du succès de BPE. Comme piste, nous avons bien sûr d'autres projets PC (nous avons des milliers d'envies  ::P: ), des portages sur d'autres plates-formes comme BPE sur tablette ou smartphone, etc.
Pour l'instant cependant, nous comptons déjà apporter du contenu gratuit à BPE. Ça fait toujours plaisir, les DLC gratuits.




> En tout les cas, maintenant vous avancerez plus vite grâce à vos connaissances acquises ces derniers mois suite à la sortie de BPE, dans le cas ou vous souhaiteriez créer un autre jeu.


Oh oui, nous avancerons incontestablement plus vite sur le deuxième jeu ! Déjà parce que nous avons pris de l'expérience et que nous bossons plus vite, mais aussi parce que certaines choses ne seront plus à refaire, comme monter la boîte (ça prend un temps fou !), gérer l'aspect administratif (plus lourd la première année que les suivantes), et faire le moteur. Par ailleurs, Quittouff nous pond des outils tellement merveilleux qu'il m'arrivait encore en fin de prod d'être pris d'euphorie en les utilisant. Sans ces outils, je pense que je serais environ 5 à 10x moins rapide dans une certaine partie de mon travail d'animateur, sans exagérer !


Concernant ton PS, eh bien figure-toi que le manque de feedback de la vie des Martiens a été un épineux problème de design, de graph et de code. Assez tôt dans le projet, nous avons renoncé à l'utilisation de jauges, extrêmement précises, mais peut-être aussi trop précises, pas très jolies, et confusionnantes s'il y en a une centaine à l'écran. Nous avons donc décidé de représenter les dégâts des Martiens avec des bris de casque (il y a 4 stades qui correspondent à des tranches de 25%). Nous nous sommes finalement dit qu'il n'était pas bien utile d'en mettre plus, parce que les Martiens meurent assez vite dans l'ensemble.
Nous avons en effet sacrifié un peu de précision pour gagner en immersion. Pour autant, tu peux tout à fait calculer le nombre de tirs de base nécessaire à tuer un Martien de base, vu qu'à la manière de Plants vs. Zombies, les dégâts ne sont pas variable. Tu verras que tu prends vite l'habitude de savoir ce qui peut passer tes défenses, et ce qui ne peut pas  :;):

----------


## Froyok

Tiens j'y pense en passant par ici : http://www.siteduzero.com/forum-83-6....html#r7359032
Si jamais tu te lances sur l'UDK, tu pourras t'inspirer de ce projet là.  ::):

----------


## Tohwaku

(je me rends compte que j'avais mal lu la question sur l'anglais : en fait, le jeu supporte déjà l'anglais, ainsi que le français, sur le même installer)

----------


## Quittouff

Arf le salaud! il a été plus vite que moi!
Donc tout pareil que tohwaku xD.
Et donc moi aussi je tiens à remercier les soutiens qui nous sont apportés, vous savez pas à quel point ca peut faire plaisir de savoir que les gens jouent ne serait-ce qu'à la démo du jeu et qu'ils apprécient le travail fait et en parle.
Et comme dit tohwaku, c'est clairement un plaisir de partager notre expérience, malheureusement on ne peut pas le faire partout et tout le temps à cause du temps que ça prend.

----------


## Louck

> @lucskywalker
> Hé bien bon courage à toi et ton pote! Faut pas se laisser abattre, car c'est souvent terminer projet qui est le plus dur.


Merci !
J'ai déjà fait l'expérience du "polishing" et du beta-testing sur mon précédent projet (cf signature). Et en effet, j'ai pris autant de temps pour developper le jeu que de le peaufiner (mais c'étais aussi mon tout premier projet avec mon moteur fait maison. Ca prend du temps ces conneries  ::P: ).

Pour l'instant notre objectif est de sortir une version "light" du jeu, mettant en avant le gameplay du jeu (dans le mode de jeu "endurance"). Si le jeu plait par son gameplay, nous ferrons une version amélioré  :;): .


Par contre l'erreur, c'est de n'avoir pas fait de prototype. Mais nous n'avons pas d'idées de comment en faire un pour ce genre de jeu (TD + jeu de carte).

----------


## Quittouff

Bon je vais faire un peu de HS du coup, j'avais pas envie de ressusciter le vieux post vers lequel mêne le lien de lucskywalker mais donc je viens de tester le jeu et c'est vraiment pas mal du tout, surtout pour un premier jeu, GG mec!

----------


## Louck

Merci  ::): .

Tiens d'ailleurs, je conseil de faire un jeu dans le même genre qu'HATU pour débuter: C'est un shoot'em'up qui affonte un groupe d'ennemi dans une arène. C'est très simple à faire  :;): .

----------


## Black Wolf

Juste pour préciser, Unity est également gratuit pour une utilisation commerciale. Il y a juste quelque fonctions qui ne sont pas disponibles dans la version gratuite (tout ce qui est render to texture et posteffects surtout) et la version gratuite ne peut être utilisée par une société réalisant plus de 100'000$ de chiffre d'affaire annuel.

----------


## war-p

Ceci dit, je pense que pour un premier projet, c'est pas forcément l'objectif d'être une entreprise faisant plus de 100000$ de bénef à la fin de l'année...

----------


## Black Wolf

Surtout que si tu te fais 100'000$ de chiffre d'affaire on peut supposer que t'as les moyens d'investir dans une version pro  ::P:

----------


## war-p

Ça dépend, si tu dépenses tout en coke et en pute, non, pas forcément...

----------


## LightmareGwen

@lucskywalker: Salut! Je suis Gwen, graphiste à Lightmare ! Manque plus que le prod sur ce forum et on sera effectivement au complet!  ::P: 
C'est vraiment un chouette thread, merci pour vos questions et commentaires sur BPE !

Je voulais juste réagir sur ton jeu HATU: je viens de le lancer et je trouve ça pas mal !  ::):  C’est en effet un bon "petit" projet pour débuter... Malgré tout, je vais me permettre 1 ou 2 remarques de graphiste  ::P: 
La première chose qui m'a surpris en lançant le jeu, c’est l’absence de repères dans l'espace. En déplaçant le vaisseau, le feeling est assez particulier et on ne comprends réellement le "comportement", la vitesse de son vaisseau que lorsque l'on peut se repérer à un ennemi où un tir adverse (les nuages en background sont trop sombres et sont sur un plan différent, et ça donne un petit côté flottant au premier abord). Dans geometry wars par exemple, la grille présente sur tout l'écran aide très fortement à donner le feeling du vaisseau dès la première seconde et tu comprends le comportement de ton vaisseau sans ennemi.  ::): 

Le second truc: c’est le design des ennemis: je les ai trouvés trop proches les uns des autres, et lorsque l'action devient rythmée et qu'il y a beaucoup d'ennemis à l'écran, j'avais du mal à donner une priorité pour éliminer intel plutôt qu'intel. Même exemple: dans geometry wars, le formes et les couleurs des ennemis sont vraiment très très marquées. D'une façon générale il faut toujours bouriner sur le feedback visuel des éléments gameplay: ennemis, objets, etc.
Par exemple, toujours dans la frénésie du combat, j'ai confondu les petits bonus que les ennemis droppent avec les mines que droppe l'ennemi orange il me semble.
En un mot comme en cent: le graph doit être au service du gameplay.  ::): 

Bon enfin voila c’est pour pinailler, malgré tout c’est plutôt cool, et j'ai hâte de voir le second projet !  ::P: 

Et je vous fait des bisous !
Gwen

----------


## Louck

Réponse simple: Je ne suis qu'un piètre graphiste x).

Concernant la sensation du mouvement, je voulais surtout jouer sur le déplacement de la caméra (plus le vaisseau avance, plus il s'approche du bord de l'écran, au lieu de rester au centre). Mais ce n'étais pas chose aisé à gérer et le joueur avait besoin de visibilité. La grille peut être une solution oui  ::): .


Pour tout les graphismes du jeu, je me suis basé sur un générateur de pixels (dont le lien est mort maintenant... :/). A partir de ces générations, j'ai appliqué des couleurs et quelques modifications. Je ne suis pas un grand graphiste et c'est mon plus gros défaut.

Pour combler le défaut, je mise sur les effets et la fluidité... des pixels  ::P: . Mais il y a encore du travail à faire.


Mon deuxième projet est un défis pour moi  ::P:  
Merci pour ce retour.

----------


## Quittouff

Plus sérieusement 100 000$/an ca fait env 80 000€/an et c'est très peu pour une boite (française) de ne serait-ce que 3 ou 4 personnes quand il faut faire vivre une boite et ses salariés avec, donc non la boite n'a pas forcément les moyen de claquer 3 ou 4000€ par an dans des licences supplémentaires  ::): 
Cela dit je trouve ca plutôt cool le principe de ne pas faire payer les utilisations non commerciales, ca permet de se former dessus sans avoir à lacher plein de thunes ou t'obliger à le pirater.

----------


## matheod

Waou, quelle chance que le bouton pour détruire les machines ait fait crashé le jeu (ça c'est du bouton de destruction ^^), car en cherchant si d'autre personne avait eu ce soucis, je suis tombé sur ce post qui est très intéressant !

----------


## Tohwaku

Hmmm intéressant, on va faire des tests en boumant toutes les machines du jeu :D Merci pour cette remarque matheod :D

----------


## SeanRon

> le principe de ne pas faire payer les utilisations non commerciales, ca permet de se former dessus sans avoir à lacher plein de thunes ou t'obliger à le pirater.


D'ailleurs je pense que c'est ce qui a desservi les moteurs comme Torque ( http://www.garagegames.com/products/torque-2d ) le jour ou Unity est sorti.
( en dehors du fait que torque est un moteur très moyen en terme de perfs. )

----------


## fckps

Je me permets de relancer ce post car je l'ai trouvé très instructif.

Je suis toujours surpris de voir à quel point, à propos de la création d'un jeu, la majorité des questions posées tournent autour des techniques informatique à utiliser, logiciel, langage de développement, graphisme..etc...

Bien entendu que tout cela participe à la réalisation d'un jeu.

Mais qu'est ce qui fait le succès d'un jeu-? La jouabilité-!

Hors, dans le cas d'un jeu de Tower Defence par exemple, moi, les questions que je me pose sont relatives au game design (game design est un terme qui définit l'aspect conception du jeu, et ne désigne pas uniquement son design graphique ou sonore, précision pour les vrais néophytes)

Quelle vitesse donner aux personnages
Combien de points de vie pour le gentil, le méchant
Quelle vont être les ressources pour placer des nouveaux modules
Comment vont être distribué ces même ressources, à quel vitesse, dans quel pourcentage
Combien de temps va durer un niveau
Et comment va évoluer le jeu, les niveaux, relativement aux questions précédentes-?
Dans quelle proportion augmenter la vitesse, les ressources, les difficultés...etc..

Bref tout ce qui concerne véritablement la jouabilité et qui va faire que le jeu pourra trouver un public, parce que fun, excitant, difficile et en même temps jouable..etc...

Pour ma part, j'en appelle donc aux pros-qui ont aimablement participé à ce post, afin de savoir s'ils ont des pistes à nous donner sur ces aspects, bien que j'imagine modestement que quand on a bossé 18 mois sur un jeux, il va de soi qu'il est normal qu'on ait pas forcément envie de dévoiler toutes nos astuces  :;):

----------


## Tomaka17

Tous ces paramètres tu peux les copier depuis un jeu existant. C'est comme ça que ça marche dans le jeu vidéo : tu copies un jeu existant, tu modifies les trucs que t'aimes pas, éventuellement tu rajoutes deux/trois bonnes idées après avoir vérifié qu'elles plaisent, et tu sors ton jeu.

----------


## kenshironeo

Tower defense: la gestion des ressourdes est automatisée, peut éventuellement être améliorée par des unités qui amélioreront la production ou bien en tuant des ennemis.


Un tower defense ça doit être facile.Les niveaux doivent durer de 5 à 10 minutes, peut-êtreplus pour les dernières missions.
Il est important que les types de tours soient variés et disposent d'upgrades.


Le tower defense c'est un truc simple, sympa, avec une histoire simple dans le mode campagne.


L'IA ne doit pas être trop bourrine, même dans les difficultés les plus élevées, les modes de difficulté sont avant tout là pour donner prétexte à des HF. Autrement dit même le mode difficile devra être relativement facile.(il est aisé de s'appuyer dans ce domaine sur le savoir faire des grands éditeurs)
Un tower defense aura un petit tutorial car le genre peut toucher des joueurs très casual.


Il est regrettable que la simplicité de prise en main des tower defense ne se retrouvent pas dans les autres genre de jeux de guerre.

----------


## Tohwaku

Re à tout le monde, je ré-émerge des limbes pour venir papoter ^^ (merci Quittouff !)




> Hors, dans le cas d'un jeu de Tower Defence par exemple, moi, les questions que je me pose sont relatives au game design (game design est un terme qui définit l'aspect conception du jeu, et ne désigne pas uniquement son design graphique ou sonore, précision pour les vrais néophytes)
> 
> Quelle vitesse donner aux personnages
> Combien de points de vie pour le gentil, le méchant
> Quelle vont être les ressources pour placer des nouveaux modules
> Comment vont être distribué ces même ressources, à quel vitesse, dans quel pourcentage
> Combien de temps va durer un niveau
> Et comment va évoluer le jeu, les niveaux, relativement aux questions précédentes-?
> Dans quelle proportion augmenter la vitesse, les ressources, les difficultés...etc..


Ah c'est une excellente série de questions, ça !

Alors il faut déjà distinguer deux choses... euh, distinctes. Déjà, même si dans les deux cas on parle bien de game design, les choix ne se font pas forcément au même niveau.

------
D'un côté, on a quels paramètres vont être présents dans le jeu, ce qui est une décision assez fondamentale de game design (et on articule beaucoup le design du jeu autour de ces paramètres, ce qu'on appelle des paramètres atomiques et de fait, le "rational design", je te renvoie vers ce super article : http://www.gamasutra.com/view/featur...e_core_of_.php)

Un exemple simple de cette méthode c'est ce qu'on explique sur notre blog : http://lightmare-studio.com/fr/encore-des-martiens/
En faisant varier deux paramètres des martiens (la vitesse et la vie, leurs deux paramètres génériques), et sans définir de valeur numérique dans un premier temps, il était assez facile de "déduire" des nouveaux archétypes. Par exemple, tu prends le martien de base, qui a une vitesse et une résistance moyennes, et si tu fais varier ses deux params, tu peux te retrouver avec soit un martien avec une vitesse haute et une résistance faible (ce que nous avons habillé en "ninja"), et un avec une vitesse faible et une résistance élevée (ce que nous avons habillé en "blindé").

-----
D'un autre côté, on a quelle valeur va prendre chaque paramètre, et là on entre dans une sous-discipline plus concrète du game design : l'équilibrage à proprement parler. Fab dans notre équipe pourrait en parler mieux que moi vu que c'est lui qui s'en est chargé sur BPE, mais je vais donner les grandes lignes.

L'équilibrage ça consiste à trouver un réglage pour chaque param tel que l'ensemble soit aussi fun, rejouable, et équilibré que possible entre frustration et challenge. Il n'y a pas "un" bon réglage pour un jeu donné, ça dépend de la cible que tu vises. Par exemple, un joueur casual aimera un jeu qui pardonne les erreurs (un réglage permissif donc), alors qu'on joueur hardcore aimera un jeu où ses capacités sont testées jusqu'à leurs limites et où la moindre erreur n'est pas pardonnée (ces joueurs se font rares, même si la plupart des joueurs aiment à croire qu'ils en font partie).

Un réglage est "bon" quand il correspond au public visé  ::): 

Vu que c'est un boulot très concret et constitué à 95% de tâtonnement, je ne peux pas trop répondre à "combien mettre de vie au boss" ou "quelle vitesse doit avoir le ninja". L'idée c'est d'abord de définir des grandes lignes qui définissent les intentions principales de design, par exemple "on veut que le joueur ait des engrenages fréquemment, mais qu'il n'en ait jamais trop", "un martien moyen doit être capable de supporter tout seul le tir d'une tour de base et pouvoir sortir de sa portée sans être trop endommagé" ou encore "la tour mortier doit pouvoir one-shot tous les martiens, mais elle doit avoir une cadence très faible et un prix très élevé", etc.
Ensuite, on définit des "classes" de paramètres, par exemple on sait qu'on a 5 vitesses différentes pour les martiens, et autant en nombre de points de vie. C'est pas forcément linéaire (100 / 200 / 300 / 400 / 500), par exemple tu peux avoir le plus faible à 100 HP, le second à 120, le troisième à 160, ensuite 180 et enfin 250. Y a pas vraiment de "règles" autres que celles que tu te définis.

Si ça colles aux intentions et que c'est fun à jouer, c'est bon. Le mieux c'est de pas trop partir dans tous les sens, lister les paramètres que tu as, et sélectionner ceux que tu veux réellement faire varier (tous les paramètres ne sont pas obligatoirement variables).

Je sais pas trop si ça répond à la question, ou si c'est complètement à côté. N'hésite pas à demander des précisions  ::):

----------

