[Jeu terminé] Punxel Agent: jeu de plateforme 2D avec des pixels et des pew pew!

[Louck]

C'est ca . C'est quelque chose de complètement perso.

D'ailleurs j'en ai fait grand user hier pour réaliser le premier niveau du jeu... Et je vais sûrement changer d'éditeur . (sûrement pour celui que tu proposes devn).

[edenwars]

Il me plait aussi ce projet.


Je vais le suivre de près.

[Louck]

Update 3 (11/08/13)
Pour cette troisième mise à jour, j'ai fait un peu de déco dans le jeu... d'un point de vue technique.


Du côté des graphismes, j'ai réussi à faire animer nos protagonistes, avec les sprites de notre graphiste Uubu. Ils peuvent marcher, courir, sauter, tirer, avoir un regard sournois... La base des bases!
Il manque encore quelques animations et des émoticônes pour rendre le tout très fluide et bien animé .

Pour animer tout ce beau monde, je ne voulais pas mélanger le code du gameplay avec le code d'animation. Je voulais rendre la chose totalement indépendante, afin de personnaliser et de maintenir le code avec plus de facilité. La deuxième chose que je souhaitais, c'est d'éviter de gros copier coller de codes .
La solution que j'ai choisie est de réutiliser la technique mise en place pour l'AI: les Behavior Trees (ou un "arbre de comportement")


Le BT (Behavior Trees) utilisé pour mon jeu est légèrement différente. Pour faire simple, mon BT est un arbre constitué de trois types de nœuds:

• Un nœud Sélection: Celui qui liste les nœuds fils.
• Un nœud Condition: Si la condition du nœud est respecté (exemple: HP du joueur > 0), alors parcourir sa branche. Sinon, passer au noeud (frêre) suivant.
• Une feuille Action: Contient une méthode à exécuter (par une entité). Optionnellement, peut contenir une branche annexe à parcourir (en plus).

Le BT possède une fonction "select": L'arbre sera parcouru de gauche à droite, jusqu'à tomber sur une feuille (ou jusqu'à arriver au bout d'une branche). La fonction retourne la liste des feuilles "Action" qu'elle a rencontrée sur son chemin.
L'entité pourra alors exécuter les méthodes stockées dans ces feuilles.


Pour l'AI, le BT permet de réaliser un système logique et réactif.
Sinon, c'est un arbre qui est simple à maintenir, et qui évite les copier/coller de codes .

J'ai repris ce système pour réaliser les animations du jeu. Et dans un même temps, j'ai fait évoluer le moteur de mon jeu.




Du côté du son, Bigju m'a envoyé ses premiers travaux et m'a proposé l'idée de rendre la musique dynamique: Calme quand le joueur n'est pas repéré, et rapide quand il se fait attaquer.

J'ai mis en place son idée. J'ai eu néanmoins la malchance de tomber sur une petite bibliothèque qui ne pouvait streamer qu'une seule musique à la fois... :/. J'ai du revoir le code de l'auteur pour faire marcher plusieurs musiques.


Pour finir, j'ai finis de concevoir le tout premier niveau du jeu:


La maison est un peu vide pour l'instant et le niveau est prévu pour être facile.
J'ai pris beaucoup de temps pour réaliser ce niveau, pour faute d'un éditeur de map pas trop performant (je me répète ?). Je vais sûrement changer pour un nouveau éditeur pour les prochains niveaux.


Pour les prochaines semaines, je vais m'attaquer à l'interface du jeu (qui sera simple) et aux bruitages sonores (pew pew pew !). Suite à cela, il y aura une série de débogage.

Et enfin, je publie une démo du jeu . Mais il faudra patienter encore un peu.

[MrShibby]

Ça commence à vraiment prendre forme, c'est très sympa.

[SeanRon]

carton rouge pour les nuages.
je pense pas qu'on les verra beaucoup, donc si tu veux pas t'embêter, un simple ciel dégradé suffira, un peu comme tu l'as fait au niveau des immeubles, par exmple.

Pour le reste c'est super, vivement la suite ^^

[MrShibby]

C'est vrai qu'en y regardant ça fait tapisserie de chambre d'enfant. Les enlever totalement je sais pas trop mais peut être qu'en essayant de les espacer faire un pattern un peu plus random ça donnerai mieux?

[Louck]

En effet, je l'avais un peu remarqué en dessinant la map .
Dans le jeu, nous le remarquons moins vu que la caméra est de plus petite portée, et est beaucoup plus ciblé sur le protagoniste.

Je vais voir ca avec Uubu .


Si tout se passe bien, je ferais une nouvelle vidéo du jeu avec les derniers ajouts.

[Uubu]

Merci pour vos retours sur les graphismes, on va modifier ça.
Hésitez pas à critiquer les visuels, je suis preneur.

[SeanRon]

Un retour ? bah, les tiles et les sprites sont stylés. Et la carte affichée plus haut donne plutôt envie.

les escaliers font très massifs, peut-être trop. Est-ce qu'il ya une raison particulière ou c'est juste un choix arbitraire ?
J'espère aussi plus de sprites pour le mobilier destructible. Des canapés, des distributeurs de boissons, etc etc ....
De petits effets de lumières pourraient rajouter de la profondeur et de l'ambiance. Des spots, des néons clignotants, des enseignes, et d'autres trucs dans le genre.
bon courage et vivement la suite ^^

[Louck]

les escaliers font très massifs, peut-être trop. Est-ce qu'il ya une raison particulière ou c'est juste un choix arbitraire ?

C'est mon choix "arbitraire" pour dire .
Techniquement, c'est surtout pour permettre à l'AI de ne pas trop jouer à l'idiot quand il doit monter les escaliers et échelles. C'est une "marge de manœuvre" si on veut.

Néanmoins je peux essayer de réduire la taille des escaliers. A voir .

J'espère aussi plus de sprites pour le mobilier destructible. Des canapés, des distributeurs de boissons, etc etc ....
De petits effets de lumières pourraient rajouter de la profondeur et de l'ambiance. Des spots, des néons clignotants, des enseignes, et d'autres trucs dans le genre.

Pour le mobilier destructible, c'est prévu mais pas prioritaire. Ca sera surtout lors de la période de "peaufinement" .

Par contre pour les lumières, mon moteur de jeu n'est pas encore capable de "bien" les gérer. Je peux appliquer quelques effets, mais pas quelque chose d'énormes malheureusement.
Je ne dis pas que les lumières sont difficiles à gérer sous OpenGL, mais pour arriver à un résultat convaincant et qui ne plombe pas les performances du jeu, il y a du travail .


Du coup je ne prévois pas de super effets de lumières et d'ombres pour ce jeu. Peux-être dans un projet futur, mais pas maintenant.

[Poussin Joyeux]

Une nouvelle vidéo! On veut une nouvelle vidéo!

[Louck]

Suite à un long week-end, j'ai du faire une petite pause sur le développement du jeu.
Mais je reste toujours motivé, et je bosse à fond pour mettre en place les bruitages sonores .


(Interface non finalisé. Mais l'idée est là)


A la fin de cette semaine, la vidéo est toujours prévu. Mais ca sera une très courte vidéo de gameplay du jeu (un peu comme les premières vidéos du prototype... mais en un peu plus jolie ). Etant encore en version alpha, je ne peux pas montrer de nombreuses choses, malheureusement..
Ensuite, j'annoncerai une date pour la démo du jeu (indice: ce n'est pas pour maintenant ).

[SeanRon]

quand je pense qu'ils y en a qui font des kickstarters bien moins aboutis déjà.
Tu veux pas nous faire un kickstarter ? pour avoir la motivation (financière) de faire un jeu complet, avec divers niveaux, des boss, des armes à upgrades etc etc?
Si le prix reste correct, je suis sur que pas mal de canards soutiendront un projet indie issu de la communauté.

[plantmann]

Tiens, encore une question pour toi: à part HATU et ce projet, ça fait combien de temps que tu développes des jeux? Si ce sont tes 2 premiers, je suis wouaouh! (bon, je le suis quoi qu'il arrive)

[Louck]

quand je pense qu'ils y en a qui font des kickstarters bien moins aboutis déjà.
Tu veux pas nous faire un kickstarter ? pour avoir la motivation (financière) de faire un jeu complet, avec divers niveaux, des boss, des armes à upgrades etc etc?
Si le prix reste correct, je suis sur que pas mal de canards soutiendront un projet indie issu de la communauté.

Merci .
Cependant mon but actuel n'est pas de vendre un jeu (même si je le voudrais).
En réalité, j'ai un très gros objectif, qui peut se conclure sur un jeu qui peut être commercialisé.


Actuellement, je cherche à développer un certain nombre de jeux. Pour chacun de ces jeux, je conçois un gameplay différent (simple ou complexe) et je fais évoluer mon moteur de jeu maison. Je cherche à me faire une petite expérience dans le développement des jeux, je tente des choses, j'essaye de mettre en place des trucs... Tout en essayant de faire un jeu pas trop dégueulasse.

Pour résumer ma méthode de travail: avant que je commence à développer un nouveau jeu, je définis un thème et un gameplay qui me plaisent, et je planifie le délai nécessaire pour réaliser ce jeu (en me basant que sur mon temps libre). Quand le délai n'est pas trop long, alors je commence à réaliser le prototype du jeu .

Une des contraintes pour ces projets est le délai. Je cherche à être dynamique et à m'expérimenter dans de nombreux domaines et genres, sur le court terme. J'ai plein de petites idées que j'aimerais tenter (un roguelike dans le monde du hacking, un hotline-miami-like avec une gestion de bande, un simulateur d'enquête, etc etc...).
Face à cette contrainte, je dois me focaliser sur le core et le gameplay du jeu. Du coup: le contenu, les graphismes et les sons du jeu seront vu au minimum (il ne faut pas s'attendre à un gameplay de 10h).

Pour ce jeu de plateforme, la situation est assez exceptionnelle: A la base, je voulais faire du minimalisme avec des cubes et des sons 8bits. Si Uubu ne c'est pas proposé avec son super travail, le jeu ne serait pas aussi beau que maintenant .


Globalement, je prévois de réaliser une dizaine de jeux (voir une vingtaine selon l'envie) de cette façon. Quand un de ces jeux est finis et est débogué, je passe à un autre.
Quand j'aurais finis avec mes expériences, alors je développerai un vrai et gros jeu . C'est mon objectif.

Tiens, encore une question pour toi: à part HATU et ce projet, ça fait combien de temps que tu développes des jeux? Si ce sont tes 2 premiers, je suis wouaouh! (bon, je le suis quoi qu'il arrive)

Avant que je réalise HATU, j'ai déjà développé des petits trucs pas finis sous de nombreux logiciels (dont RPG Maker).

Depuis que je me suis mis à coder mes jeux, j'ai travaillé sur 3 projets:

• HATU, un shoot'em up simple dans une arène.
• Un jeu de dauphin pour le concours "Make Something Horrible" de CPC.
• Un Tower-Defense qui se joue avec des cartes, dans un style cyberpunk. Le gameplay se réside sur la constitution du deck, composé de cartes "tours", "armes", et "cyber-action". Le joueur peut poser une carte sur le terrain afin de l'activer (pour créer une tour, pour s'équiper d'une arme, ou pour enclencher un événement/action). Il peut aussi fusionner les cartes entre-elles afin de faire évoluer la qualité/niveau de ces cartes et pour produire de jolies effets (exemple: une tour + lance-flamme: une tour qui crache du feu). Malheureusement j'ai du stopper le développement de ce projet pour cause d'une mauvaise gestion et d'un mauvais planning de ma part.. et suite à de nombreuses pauses :/. Je pense recommencer le développement de ce jeu, mais pas pour l'instant.

Et aujourd'hui, j'ai ce jeu de plateforme .


EDIT: Je ne cherche pas non plus à abandonner mes projets du jour au lendemain, après que je les ai finis. Je prend un moment avant de passer à autre chose .

[Poussin Joyeux]

C'est une bonne philosophie ça!

Et puis quand ton "vrai" jeu sera un succès, tu sortiras une compilation sur Steam avec tous les petits jeux que tu auras fait avant (comme le "Basement" des créateurs de Super Meat Boy )

[Icebird]

Je suis intéressé de savoir comment tu gère/vas gérer les animations des personnages.
Je suis en train de réfléchir à ce qu'il faut pour faire un side-scroller, et notamment le moteur d'animation.
Je part complètement de zéro, mais je souhaite surtout créer un moteur flexible et moddable. Pour l'instant, j'envisage un moteur capable de traiter un fichier entity contenant la liste de toutes les "actions" possibles, et les conditions pour chaque action.
Je recolle ici une partie de mon googleDoc où je suis en train de mettre çà en forme:

Side-Scroller Animation Engine

Entity: Contient une Sheet et plusieurs Actions
Sheet: image contenant toutes les frames possibles
Actions:

• ActionName: nom de l'action
• SpriteID: Identifiant de sprite dans le cas où l’entity est composée de plusieurs sprites.
• Frames: tableau listant la position dans la sheet de chaque frame de l’action.
• Offset: tableau listant l’offset par rapport au centre du perso à appliquer à chaque frame.
• StartCondition: quand est-ce que l’action se déclenche (si rien, il faut un appel direct à l’action pour la déclencher)
• StepCondition: quand passe-t-on à la frame suivante
• BreakCondition: quand est-ce que on stop une boucle (si rien, on stop dès que la StartCondition n’est plus valable)
• Loop: action faite une seule fois, ou en boucle tant que la StartCondition est vraie
• Priority: Unique pour une SpriteID donnée, détermine quelle action prend effet si plusieurs StartCondition sont vraies.

Exemple:
IdleAction: Animation du perso quand il ne fait rien. Une frame toutes les 200 millisecondes
SpriteID: 1
Frames: tableau de 8 rectangles
Offset: tableau de 8 vector2d
StartCondition: Velocity.X == 0 && Velocity.Y == 0
StepCondition: TimeLapsed == 200
Loop: true
Priority: 0

WalkAction: Animation de marche. Une frame tous les 20 pixels parcourus
SpriteID: 1
Frames: tableau de 8 rectangles
Offset: tableau de 8 vector2d
StartCondition: Velocity.X>0
StepCondition: Distance.X>20
Loop: true
Priority:10

RunAction: Animation de course. Une frame tous les 30 pixels parcourus
SpriteID: 1
Frames: tableau de 8 rectangles
Offset: tableau de 8 vector2d
StartCondition: Velocity.X>30% MaxVelocity && Acceleration.X>0
StepCondition: Distance.X>30
Loop: true
Priority:11

BrakeAction: Animation du personnage qui freine en glissant sur le sol avec un petit nuage de poussière. Une frame tous les 10 pixels parcourus. Ne se déclenche que quand le perso arrête d’accélérer après avoir pris une vitesse de course, et ne s’arrête que quand la vitesse retombe à zero, ou qu’une autre animation prend le dessus (priorité basse).
SpriteID: 1
Frames: tableau de 2 rectangles
Offset: tableau de 2 vector2d
StartCondition: Velocity.X>30% MaxVelocity && Acceleration.X<=0
StepCondition: Distance.X>10
BreakCondition: Velocity.X==0
Loop: true
Priority:1

PunchAction: Animation de coup de poing.
SpriteID: 1
Frames: tableau de 4 rectangles
Offset: tableau de 4 vector2d
StepCondition: TimeLapsed == 50
Loop: false
Priority:20


Bon, peut-être que je suis complétement à coté de la plaque, ou que çà existe déjà et que c'est facilement trouvable/récupérable quelque part.
Mais dans tous les cas l'exercice me plait.
Donc, si tu a le temps, si tu pouvais m'expliquer en quelque mot comment tu envisage la chose?

[devn]

Je suis en train de réfléchir à ce qu'il faut pour faire un side-scroller, et notamment le moteur d'animation.

Si tu ne veux pas te prendre la tête avec les animations et les spritesheets, j'utilise un format maison avec un éditeur graphique qui fait tout pour moi: http://devnewton.bci.im/projects/nanim

Il y a un exemple en java2d dans le code et tu peux consulter le code de mon jeu pour de l'opengl.

[Tomaka17]

Je suis en train de réfléchir à ce qu'il faut pour faire un side-scroller, et notamment le moteur d'animation.

Ou sinon tu utilises Spine comme moi

[Icebird]

Je pense que je me suis mal exprimé.
Je ne cherche pas à créer moi-même des animations de toute pièce (je ne suis pas assez doué artistiquement pour çà).
J'ai récupéré des SpritesSheet contenant des séries d'animations, et je souhaite que mon programme les exploite correctement.
Donc c'est plus la gestion des différentes animations qui me pose problème. Quand faire tourner l'animation de marche? Et le faire à une vitesse adaptée à la vitesse actuelle de marche du perso. Enchainer naturellement sur l'animation de course. Et utiliser une petite animation où le perso glisse en freinant quand il veut s'arrêter en allant au-delà d'une certaine vitesse.
J'ai commencé à coder çà en dur, mais je trouve que çà fait beaucoup de redondances et des if en pagaille, et je me demandais si je ne pouvais pas créer un système qui gère çà différemment. Des fichiers contenant la liste des actions possibles et leur conditions, fourni à un moteur qui se charge de trier çà et de déterminer quelle frame de quelle action doit être affiché.

Bon, je suis en train de dérailler le sujet d'origine, désolé. En tout cas, voilà un exemple de ce que j’obtiens pour le moment (c'est ultra-ultra basique, je sais).
https://www.dropbox.com/s/yxc5v7gers...rojet%20-1.zip

[devn]

Je pense que je me suis mal exprimé.
Je ne cherche pas à créer moi-même des animations de toute pièce (je ne suis pas assez doué artistiquement pour çà).
J'ai récupéré des SpritesSheet contenant des séries d'animations, et je souhaite que mon programme les exploite correctement.
Donc c'est plus la gestion des différentes animations qui me pose problème. Quand faire tourner l'animation de marche? Et le faire à une vitesse adaptée à la vitesse actuelle de marche du perso. Enchainer naturellement sur l'animation de course. Et utiliser une petite animation où le perso glisse en freinant quand il veut s'arrêter en allant au-delà d'une certaine vitesse.
J'ai commencé à coder çà en dur, mais je trouve que çà fait beaucoup de redondances et des if en pagaille, et je me demandais si je ne pouvais pas créer un système qui gère çà différemment. Des fichiers contenant la liste des actions possibles et leur conditions, fourni à un moteur qui se charge de trier çà et de déterminer quelle frame de quelle action doit être affiché.

Tu pourrais gérer ça avec des machines à états finis.

[Louck]

J'ai déjà une réponse à ta question, dans un précédent post: J'utilise les Tree Behaviors .

De façon plus détaillé, j'ai un objet "Animation" qui contient une liste de sprites et les règles d'exécutions de cette animation (si c'est une boucle, délai avant de passer au sprite suivant, etc etc...).
J'ai aussi un objet "Animator" () qui stock et gère toutes les animations d'une entité. J'ai codé une fonction dans cet Animator pour qu'il exécute une (ou plusieurs) animation.

Ensuite j'ai une classe singleton qui a deux boulots à réaliser pour chaque protagoniste du jeu:
- Générer l'animator (et les animations et ses sprites) pour un protagoniste donné.
- Générer un TB (Tree Behaviors) pour ce protagoniste.

Toutes les 100ms (arbitraire), je parcours ce TB afin de déterminer le ou les animations à exécuter.
Globalement, j'ai des conditions très simples du genre: "Est-ce que l'entité regarde à gauche?", "Est-ce qu'il marche ou il court ?", "Est-il dans l'air ?", etc etc...
Et au bout de chacune de ces conditions, il y a soit d'autres conditions... soit une action: Exécuter la nouvelle animation . Je vérifie au préalable si cette animation n'est pas déjà en cours d'exécution (sinon ca serait très con);

Pour me simplifier la vie, j'ai aussi des actions un peu bâtardes qui récupèrent les sprites d'une animation et lui appliquent un certain effet. Par exemple pour la condition "Est-ce que l'entité regarde à gauche?", j'applique un effet de miroir sur les sprites de la prochaine animation.


Cependant, ce n'est pas "la" meilleure solution, imho. Les TB aident beaucoup pour éviter les invasions de "IF", mais ca ne peut pas gérer toutes les animations possibles...
Par exemple: Il est difficile de déterminer la condition a tester dans le cas où le joueur tire à l'instant T. Dans ce cas, j'ai du invoquer l'animation du tir dans le code de l'arme (malheureusement).


Je ne sais pas si je suis bien clair. N'hésites pas à me poser des questions .

[Uubu]

[Patate]

Sympa Ca devient bizarre au bout de quelques secondes le bras qui ne bouge pas vu que l'image est fixe

[Uubu]

Attention tout ceci est une "pré-alpha-version-prototypeuse" !

[Icebird]

J'ai déjà une réponse à ta question, dans un précédent post: J'utilise les Tree Behaviors .

De façon plus détaillé, j'ai un objet "Animation" qui contient une liste de sprites et les règles d'exécutions de cette animation (si c'est une boucle, délai avant de passer au sprite suivant, etc etc...).
J'ai aussi un objet "Animator" () qui stock et gère toutes les animations d'une entité. J'ai codé une fonction dans cet Animator pour qu'il exécute une (ou plusieurs) animation.

Ensuite j'ai une classe singleton qui a deux boulots à réaliser pour chaque protagoniste du jeu:
- Générer l'animator (et les animations et ses sprites) pour un protagoniste donné.
- Générer un TB (Tree Behaviors) pour ce protagoniste.

Toutes les 100ms (arbitraire), je parcours ce TB afin de déterminer le ou les animations à exécuter.
Globalement, j'ai des conditions très simples du genre: "Est-ce que l'entité regarde à gauche?", "Est-ce qu'il marche ou il court ?", "Est-il dans l'air ?", etc etc...
Et au bout de chacune de ces conditions, il y a soit d'autres conditions... soit une action: Exécuter la nouvelle animation . Je vérifie au préalable si cette animation n'est pas déjà en cours d'exécution (sinon ca serait très con);

Pour me simplifier la vie, j'ai aussi des actions un peu bâtardes qui récupèrent les sprites d'une animation et lui appliquent un certain effet. Par exemple pour la condition "Est-ce que l'entité regarde à gauche?", j'applique un effet de miroir sur les sprites de la prochaine animation.


Cependant, ce n'est pas "la" meilleure solution, imho. Les TB aident beaucoup pour éviter les invasions de "IF", mais ca ne peut pas gérer toutes les animations possibles...
Par exemple: Il est difficile de déterminer la condition a tester dans le cas où le joueur tire à l'instant T. Dans ce cas, j'ai du invoquer l'animation du tir dans le code de l'arme (malheureusement).


Je ne sais pas si je suis bien clair. N'hésites pas à me poser des questions .

Ta réponse me conviens très bien, c'est typiquement le genre de truc que j'essayais de concevoir.
Du coup je continue à réfléchir à mon truc, merci pour les infos.

[Louck]

Update 4 (25/08/13)


Yeah .
Je n'ai pas grand chose à dire pour ces deux semaines. A l'exception de ces deux vidéos .
J'ai beaucoup bossé ces semaines pour intégrer les sons dans le jeu (bruit de pas, tirs, etc...). Je n'ai pas implémenté tous les sons encore, mais il y a de quoi faire pour la démo.
J'ai aussi retouché à l'interface et à la caméra du jeu... ainsi qu'une petite séance de débogage .

Les deux prochaines semaines risquent d'être chargé pour ma part (pour divers raisons). Je ne promet pas de grosses nouveautés du coup :s.


Par contre, je prévois la démo pour le 7 octobre, w00t!.

L'attente risque d'être encore longue malheureusement (et désolé pour cela). Mais c'est le temps nécessaire pour mettre en place ce qu'il faut pour la démo (animations, victoire/game over..) ainsi que de corriger les bugs majeurs... sur mon temps libre.
Je tenterai tout de même de respecter le délai .

[Vader_666]

C'est vraiment super sympa !
Félicitation à tous !

[Louck]

Merci .

Au vue de la démo, nous pouvons remarquer que la durée du niveau est d'une minute en moyenne.


Il est à préciser que ce niveau est le tout premier niveau du jeu, et le plus simple. A partir du niveau 3, la difficulté du jeu sera relevé eà la hausse, offrant plus d'obstacles et bien plus d'ennemis (ainsi qu'un plus grand terrain de jeu) .



Et même s'il n'y aura que 10 niveaux dans ce jeu, il sera possible de les rejouer dans un niveau de difficulté encore plus élevé (ou dans un autre mode de jeu.. mais chut ).

Enfin, à la fin d'une partie, le jeu note le joueur et lui offre des médailles selon la façon dont il a joué cette partie (tous les ennemis sont morts, pas repéré une seule fois, niveau terminé rapidement, etc...).

Si le temps le permet, je mettrai en place des niveaux/modes bonus pour les joueurs qui auront récupéré un certain nombre de médailles .

[Uubu]

Merci ! Content que ça vous plaise.