Scirra Construct 2

[Anxious]

Bonjour les canards.

Après avoir découvert Construct grâce a cette news, me voilà lancer sur un projet de jeu à la Flashback.

Pour me faire la main sur ce logiciel, je me suis dit pourquoi ne pas essayer de reproduire les mécanismes de ce jeu dans Construct (le cloner, quoi...) pour voir si j'arrive à mettre ça en place...

Et dés le début, je bloque sur un problème simple:
J'ai une animation de marche décomposé en 12 images; mon perso doit faire un simple pas lors de la pression d'une touche (la moitié de l'anim) mais lancer l'animation complète si je laisse cette touche appuyé et l'enchainer tant qu'elle le reste.

J'ai un peu tout tester (à l'aveugle, je reconnais...) mais pas moyen de différencier ces deux façon d'appuyer sur une même touche.

Je sais que je ne comprends pas encore ni la logique, ni les possibilités de ce logiciel mais avez vous une idée sur la façon de gérer ce genre de déplacement?


EDIT:

Ah bein au temps pour moi...

En reprenant tout depuis le début et en mettant un Behavior « Grid» avec déplacement sur 32 pixels, un Event «Key is down» et comme action mon animation, mon perso se déplace exactement comme je voulais...

C'était tout con (ouais vraiment j'ai honte devant la simplicité de la solution), et je pensais pourtant avoir déjà testé ça...
Comme quoi ça aide de tout reprendre à zero.

Donc ne tenez pas compte de ma question, mais tout conseil sera le bienvenu!

Bon weekend.

[Tyler Durden]

Pour faire un jeu de type Faskback, utilise plutôt le behavior plateforme, il gère d'origine tous les types d'animations pour un jeu de plateforme (sauter, courir, stop etc), ainsi que la vitesse, la gravité etc...
Pour l'histoire des touches, tu peux dans l'event sheet, définir si l'action doit se produire "si" une touche est pressée, maintenue ou relâchée.

[Anxious]

Merci du conseil, Tyler.

Mais après moult tests, j'arrive à rien avec ce Behaviour pour des déplacement comme je les souhaite ou tout est défini par une distance en pixels.

Exemple: comment faire avec le Behaviour «Platform» pour que le sprite bouge de 32 pixels (pas un de plus, pas un de moins) sur l'appui d'une touche.

En gros est-ce que les déplacement à la flashback (une action par touche et une touche à la fois) sont régis par des mécanismes de jeu de plateforme?

Mais je vais continuer à approfondir ce Behaviour et voir ce qui m'échappe.

[Tyler Durden]

C'est pas con ce que tu dis, il faudrait que je test plus en avant pour te donner mon avis. En l'état le Grid mouvement peut être effectivement une très bonne alternative.

[TastyKool]

C'est pas con ce que tu dis, il faudrait que je test plus en avant pour te donner mon avis. En l'état le Grid mouvement peut être effectivement une très bonne alternative.

En effet. D'autant plus que le grid movement compte aussi bien le déplacement sur la grille que la vitesse de déplacement entre les cases, donc c'est un poil plus souple que ça en a l'air.

[TastyKool]

Plop !

Je me permets de revenir vous hanter avec mes questions, car j'ai un petit souci.

Grâce aux explications de Mephisto, j'ai pu faire une routine générant un damier de 11 cases sur 10, chaque case étant une instance de l'objet damier.

seulement voilà, je ne trouve aucune explication sur comment appeler telle ou telle instance d'un objet. J'en aurais besoin dans l'idéal pour pouvoir faire réagir une case en fonction de la case adjacente.

Du coup une autre possibilité est envisageable: au lieu de créer chaque instance du damier séparément, je peux tout aussi bien faire un fond représentant ce damier, puisque je ne sais pas appeler des instances particulières dans mes conditions/actions.
Et du coup plutôt que de passer par le damier pour définir la case d'à côté, je fais en sorte que chaque pion sur le damier envoie à chaque fin de tour un "sonar", un petit objet créé relativement à chaque instance de l'objet jouet (pas besoin d'appeler l'instance du coup), et je fais en sorte que ces sonars soient créés à (par exemple) 33 pixels du centre de mon pion (qui fait 64x64 pixels). En gros, je créé des objets sur les cases adjacentes, et en fonction du pion en collision avec cet objet "sonar", je fais mes calculs (genre sonar sur pion ennemi: enlever 2 points de vie au pion ennemi).

Quelle solution semble la meilleure ? trouver un moyen d'appeler les instances et m'en servir pour créer des cases sur lesquelles se trouvent les pions, et appeler chacune de ces cases pour déterminer les bonus et malus appliqués au pion situé dessus ?
Ou éviter les instances et faire que chaque pion envoie un objet sur les cases adjacentes qui agira en fonction de l'objet avec lequel il est éventuellement en collision ?

J'attends votre réponse en me rongeant les ongles.

[Mephisto]

Euh, c'est ptet la fatigue ou la connerie, mais j'ai relu au moins 5 fois ton post et j'ai toujours rien compris.

Je suis pas sur de bien saisir ce que tu souhaites faire. Si tu le souhaites, envoies moi ton .cap par mp ( sur dlfree ou megaupload ) et j'y jetterais un oeil. Par contre j'ai rien contre une explication plus simple de ce que tu veux, quite à m'expliquer ça en terme de gameplay, ce sera ptet plus clair.

( Je crois que l'on peut "appeler" une instance comme tu dis avec l'objet Mouse&Keyboard, avec un "over object" ou "object clicked", ça marche bien sur mon "tycoon".)

[Voltrek]

Je pense qu'il faut que tu crées un objet Array dans lequel tu stoquera l'état de chaque case de ton damier.

[LaVaBo]

Je pense qu'il faut que tu crées un objet Array dans lequel tu stoquera l'état de chaque case de ton damier.

J'aurais répondu ça aussi, après la première lecture.

Mais de ce que je comprend (plus ou moins, c'est moyennement clair), ce sont les instances de pions ennemis que tu devrais stocker, plus que les cases qui ne sont (dans ton explication) que des coordonnées géographiques. A moins que les cases aient des propriétés différentes, comme par exemple si elles représentent différents types de terrain.
Tu seras de toute façon obligé d'instancier les pions, vu qu'ils perdent des hp, donc je pense que c'est eux que tu devrais mettre dans un tableau.

Précise quand même ton histoire de sonar, parce qu'en l'état, on ne voit pas où tu veux en venir.

[TastyKool]

Je vais essayer de m'intéresser à l'objet Array auquel je ne goutte que dalle pour l'instant.

Pour l'histoire du sonar, imagine un pion qui envoie une "balle" dans chaque direction (haut bas gauche droite). La balle étant un objet à part entière, c'est elle qui porte les conditions pour intéragir avec les pions en cas de collision.

Mais je pense que je vais suivre les conseils de Mephisto et plutôt essayer de gérer la collision à l'aide d'un sprite attaché à chaque pion, sprite invisible, mais chargé de la collision, et qui empiète sur les cases d'à côté (il a la forme d'un +, quoi).

Dites moi si je suis toujours pas clair.

EDIT: oh et au passage, Mephisto, si tu aimes bien les dessins sur mon blog, fais un tour sur Croustination, le site de dessins en ligne qu'on tient avec deux autres dessinateurs (on y fait une vanne par jour ouvré). http://croustination.com

[Voltrek]

J'ai fait un petit jeu de morpion pour tester (mais pas fini, il n'y a pas de test de victoire par exemple).
J'y utilise justement un Array pour mémoriser l'état du jeu.

Voilà le .cap :
http://dl.free.fr/cK9E0QDL9

[JulLeBarge]

Pour ma part, pas de nouvelles de mes projets car j'ai mis en pause Construct pour découvrir Unity 3D, bien plus complexe mais ô combien puissant !

[Tyler Durden]

Pour ma part, pas de nouvelles de mes projets car j'ai mis en pause Construct pour découvrir Unity 3D, bien plus complexe mais ô combien puissant !

C'est pas le même genre de logiciel, mais c'est vrai qu'il y a des trucs sympas fait avec Unity.

[LaVaBo]

C'est pas le même genre de logiciel, mais c'est vrai qu'il y a des trucs sympas fait avec Unity.

Pour un débutant, si c'est en 3D, ça doit être bien moins accessible. Enfin, faut avoir envie de démultiplier la complexité des calculs...

[Mephisto]

Surtout que ça implique de toucher un minimum en 3D, textures, modélisation, lumières...Déjà que de la 3D iso c'est une plaie au cul pour moi...

En tout cas jullebarge si tu en sors un truc, on veut voir hein.

@ LaVaBo : Qu'est ce que ça donne en fin de compte ton problème avec tes cases adjacentes ? Tu as résolu ton soucis ?

[JulLeBarge]

Surtout que ça implique de toucher un minimum en 3D, textures, modélisation, lumières...Déjà que de la 3D iso c'est une plaie au cul pour moi...

moi je connais déjà très bien Blender donc la 3D n'est pas le problème principal concernant ce soft, c'est plus la partie programmation, encore que ça soit assez simple à comprendre et qu'il existe une base énorme de scripts tout prêts. ça ne semble pas insurmontable.
On trouve aussi très facilement des modèles 3D et des textures gratos et de bonnes qualités.

Je vais essayer de créer un petit jeu de voiture une fois que j'aurai fini quelques tutos, c'est ce qui me semble le plus simple pour commencer.

[LaVaBo]

@ LaVaBo : Qu'est ce que ça donne en fin de compte ton problème avec tes cases adjacentes ? Tu as résolu ton soucis ?

VAZY WOHH SPA MOI, J'AI RIEN FAIT MSIEUR L'AGENT !

Jveux pas balance mais j'crois que TastyKool il a des problèmes lui avec les cases tavu.

Jullebarge, si t'es chaud, vas-y mais ne vois pas trop élevé dès le départ, c'est le meilleur moyen de te dégoûter, pour ensuite :
- ne jamais concrétiser ton projet
- avoir plus de mal à en lancer un autre plus tard.

[Mephisto]

Roh putain faut que j'arrête l'absinthe moi.

Ouais, donc même question mais pour TastyKool alors, et désolé pour la confusion, je devais être encore un peu Jean Claude Bourré de la veille.

Sinon, plusun pour LaVaBo, voir trop grand c'est le meilleur moyen de pas aller au bout et de détruire ta motivation. La plupart de mes idées à la base sont un peu trop irréalisables, ce que je fais c'est que je réduis mes attentes, va au bout, puis j'améliore petit à petit. C'est un poil plus "facile". Sinon après y a des mecs comme tyler qui ont pas peur de s'attaquer à un truc monumental, mais vu qu'il passe son temps sur Borderlands ça doit pas l'inquiéter.

@ TastyKool : J'ai fais un tour sur votre site, j'aime bien l'idée, le style et certains strips m'ont bien fait marrer ( l'un des dessinateurs fait pas le mot de la bite par hasard ? ).Continuez comme ça.

[TastyKool]

Roh putain faut que j'arrête l'absinthe moi.

Ouais, donc même question mais pour TastyKool alors, et désolé pour la confusion, je devais être encore un peu Jean Claude Bourré de la veille.

Sinon, plusun pour LaVaBo, voir trop grand c'est le meilleur moyen de pas aller au bout et de détruire ta motivation. La plupart de mes idées à la base sont un peu trop irréalisables, ce que je fais c'est que je réduis mes attentes, va au bout, puis j'améliore petit à petit. C'est un poil plus "facile". Sinon après y a des mecs comme tyler qui ont pas peur de s'attaquer à un truc monumental, mais vu qu'il passe son temps sur Borderlands ça doit pas l'inquiéter.

@ TastyKool : J'ai fais un tour sur votre site, j'aime bien l'idée, le style et certains strips m'ont bien fait marrer ( l'un des dessinateurs fait pas le mot de la bite par hasard ? ).Continuez comme ça.

Si, si, c'est Helmet (QQQ sur son blog) ! Il ne me croit jamais quand je lui dis qu'il s'est fait une petite notoriété avec son mot de la bite.

Sinon c'est en effet moi qui ai un problème de case (note: toute blague visant à exprimer que j'aurais un case en moins sera immédiatement considérée comme pas drôle et son auteur sera jeté aux oubliettes) que je vais essayer de gérer via l'objet array.

J'essaye actuellement de gérer correctement ces histoires de sprite attaché servant de masque de collision, dans un mini jeu que j suis en trin de faire rapidement. C'est un bon moyen pour se faire la main. Je m'attaquerai aux arrays d'ici peu pour pouvoir avancer sur mon jeu.

Donc je risque fort de revenir très bientôt avec des questions pointues que j'exposerai avec un évident manque de vcoabulaire.

[PumpkinHead]

bonjour à tous, et merci de nous avoir fait découvrir ce soft qui à l'air effectivement très puissant.

J'ai deux petites questions concernant la gestion des ombres, étant donné que pas mal d'entre vous semblent calé sur construct :

- après avoir un peu bidouillé, j'ai l'impression que l'ombre projetée ne prend pas en compte l'alpha des sprites ( la transparence, avec un .png dans mon cas). Du coup mes ombres sont toujours rectangulaire... Quelqu'un aurait une idée pour remédier à cela ? EDIT : c'est surement très noob comme question et je m'en excuse d'avance

- Impossible aussi de trouver un event permettant de gérer la collision d'une ombre avec un autre objet, pour par exemple, un jeu d'infiltration, dans lequel le joueur caché dans l'ombre serait moins détectable. J'ai l'impression que cette option n'a pas été prévue dans le plugin de shadows, mais peut être existe t'il un moyen détourné ?

Je tiens à préciser qu'il n'y a pas de projet concret derrière tout ça, j'ai juste voulu voir ce qu'il était possible de faire avec les ombres et voila

[LaVaBo]

- après avoir un peu bidouillé, j'ai l'impression que l'ombre projetée ne prend pas en compte l'alpha des sprites ( la transparence, avec un .png dans mon cas). Du coup mes ombres sont toujours rectangulaire... Quelqu'un aurait une idée pour remédier à cela ? EDIT : c'est surement très noob comme question et je m'en excuse d'avance

C'est pas très clair. Tu essaies d'utiliser un png pour les ombres. Ce png contient une silhouette (l'ombre portée) entourée de pixels transparents, or ils sont affichés en opaque.

C'est ça ?

T'es sûr de la "couleur transparente" de tes pixels transparents ? Par exemple, pour paint, c'est du blanc, alors que game maker voulait du noir.
Le mieux étant d'utiliser paint.NET ou gimp/toshop pour avoir la gestion de l'alpha dans l'éditeur.

[Tyler Durden]

Nan je crois qu'il parle de la gestion des ombres en temps réel de Construct. Le truc c'est que j'ai pas testé plus que ça et que je peux pas te renseigner tout de suite.

[LaVaBo]

Nan je crois qu'il parle de la gestion des ombres en temps réel de Construct. Le truc c'est que j'ai pas testé plus que ça et que je peux pas te renseigner tout de suite.

OK je visualise.
L'ombre doit représenter la silhouette du sprite (sprite qui est un .png), or le calcul n'est pas fait sur les valeurs alpha du sprite mais sur les contours du png.

Si c'est de la 2D (utilisation d'un sprite), pourquoi ne pas reproduire les png en retournant verticalement l'image, puis en noircissant les couleurs ?

C'est un workaround, ça ne répond pas vraiment à ta question, mais si jamais tu ne trouves pas, ça peut te dépanner.

[PumpkinHead]

L'ombre doit représenter la silhouette du sprite (sprite qui est un .png), or le calcul n'est pas fait sur les valeurs alpha du sprite mais sur les contours du png.

voilà c'est exactement ça, un petit tour sur le wiki m'a eclairé :

Currently shadows are cast from the bounding box of the object only. If you use different shapes, you may need to use several smaller, invisible objects for casting shadows.

Donc, la gestion du canal alpha des sprites n'est pas encore reconnue, tant pis !

Lavabo, effectivement ça peut me dépanner ta technique, merci !

[TastyKool]

Hum...à vue de nez comme ça je te propose d'ajouter un sprite, genre un gros cercle, que tu "fixeras" à ton sprite en permanence, tu le mettras "invisible on start" afin qu'il ne soit pas visible par le joueur. Ce sprite-ci représentera le "champ d'action" de ton sprite. Ainsi, dans ton event sheet, tu fais quelquechose dans ce goût là : Si Joueur "overlaps" Champ d'action -> Sprite en mode attaque.
Je pense que ça donnerait le résultat voulu.

Kikoolol les copains.

J'ai essayé cette technique dans une petite maquette (vu que le mécanisme me servira pour mes cases: en leur attachant un sprite plus grand qu'une case, recouvrant les cases adjacentes, j'ai un moyen pour interagir avec les pions des cases adjacentes grâce aux évènements "on overlaping object")

Seulement voilà, ça marche très bien pour un ennemi. Mais quand on créé plusieurs instances d'ennemis, si j'entre sur la zone d'action d'un de ces ennemis, TOUS les ennemis attaquent.
L'action semble s'appliquer à toutes les instances du même objet, alors que j'aurais besoin qu'elles agissent indépendamment les unes des autres.

De plus, je cherche à les faire se déplacer de façon indépendante.
Pour l'instant mon modèle pour les déplacer est mauvais: il consiste à faire toutes les 1000 milisecondes un remplacement d'une variable globale nommée "MOVE" par la valeur Random(4). et pour chaque valeur de Random(4) (donc 1 à 4 si je ne m'abuse), j'ai des évènements (déplacer de -32 sur l'axe X par exemple).
Souci N°1: toutes les instances se déplacent en même temps (même problème que plus haut, les actions s'appliquent à toutes les instances en même temps)
Souci N°2: les déplacements comme je les ai paramétrés font que les ennemis parfois traversent les murs et tombent hors de l'écran (moyen, n'est-ce pas ?)

[PumpkinHead]

Je pense qu'il faut que tu fasse une Private variable pour tes ennemis, pour que seul l'ennemi concerné réagisse, non ?

[TastyKool]

Je pense qu'il faut que tu fasse une Private variable pour tes ennemis, pour que seul l'ennemi concerné réagisse, non ?

Ca fonctionnerait pour le mouvement, en effet, de choisir une variable privée, mais pas pour le fait que lorsque j'entre dans la zone d'attaque d'un ennemi TOUS les ennemis attaquent en même temps.

Ou alors c'est comme ça que ça marche ? Quand il faut faire quelque chose à une seule instance, il faut lui déclarer des variables privées dans lesquelles on stocke tout ?

[Tyler Durden]

Pourquoi tu créés pas tous les ennemis de manière unique? Quitte à établir des règles plus nombreuses ? Tout dépends de ce que tu cherches à faire.

[LaVaBo]

Pourquoi tu créés pas tous les ennemis de manière unique? Quitte à établir des règles plus nombreuses ? Tout dépends de ce que tu cherches à faire.

Si la position de chaque ennemi est instanciée (sinon ils seraient tous au même endroit), bases-toi dessus pour stocker les variables d'attaque et de déplacement de façon instanciée aussi.

Ca c'est un désavantage des logiciels très graphiques et user-friendly, pour demander de l'aide : pas moyen de balancer le bout de code qui pose problème.

[Voltrek]

J'ai essayé cette technique dans une petite maquette (vu que le mécanisme me servira pour mes cases: en leur attachant un sprite plus grand qu'une case, recouvrant les cases adjacentes, j'ai un moyen pour interagir avec les pions des cases adjacentes grâce aux évènements "on overlaping object")

Pour info, pour la détection de proximité de Sprites, il y a en fait un behavior qui est fait pour ça : Line of Sight. Il suffit d'ajouter le behavior aux sprites de tes ennemis et lui donner un angle de vision de 360° et une portée. Il peut même gérer les obstacles comme des murs. Ceci dit, si ta méthode marche, c'est pas la peine de tout casser .

Seulement voilà, ça marche très bien pour un ennemi. Mais quand on créé plusieurs instances d'ennemis, si j'entre sur la zone d'action d'un de ces ennemis, TOUS les ennemis attaquent.
L'action semble s'appliquer à toutes les instances du même objet, alors que j'aurais besoin qu'elles agissent indépendamment les unes des autres.

A priori, dans l'évènement collision, quand tu sélectionnes le sprite 'ennemi', c'est bien l'instance concernée par la collision que tu sélectionnes et uniquement elle. Donc ça devrait marcher. Le problème doit venir de la façon dont tu changes le comportement de tes ennemis. Il faudrait que tu nous donnes plus de détails sur cette partie. Comme le dit PumpkinHead, l'état (attaque ou repos) de chaque ennemi doit être mémorisé dans une Private variable. La règle c'est que toute information susceptible de varier d'une instance à l'autre d'un même objet doit être mémorisée dans une Private variable de l'objet en question.

De plus, je cherche à les faire se déplacer de façon indépendante.
Pour l'instant mon modèle pour les déplacer est mauvais: il consiste à faire toutes les 1000 milisecondes un remplacement d'une variable globale nommée "MOVE" par la valeur Random(4). et pour chaque valeur de Random(4) (donc 1 à 4 si je ne m'abuse), j'ai des évènements (déplacer de -32 sur l'axe X par exemple).
Souci N°1: toutes les instances se déplacent en même temps (même problème que plus haut, les actions s'appliquent à toutes les instances en même temps)
Souci N°2: les déplacements comme je les ai paramétrés font que les ennemis parfois traversent les murs et tombent hors de l'écran (moyen, n'est-ce pas ?)

Quand tu sélectionnes un objet dans ton évènement périodique, Construct n'a aucun moyen de savoir de quelle instance en particulier il s'agit (contrairement au cas de la collision). Du coup il considère que tu veux sélectionner toutes les instances en même temps et il fait une seule fois le random pour toutes. Pour appliquer l'action séparément à chaque instance, il faut utiliser la condition For Each Object.
Pour éviter que les ennemis traversent les murs, je ne suis pas tout à fait sûr, mais il me semble qu'en donnant l'attribut Solid aux ennemis et aux murs on peut empêcher ça.