Re : Platformer 2D

Merci,

Pour l'histoire,j'en suis encore très loin mais le perso est déjà choisi et l'univers pas encore,1900 ou 1930,zombie ou alien?j'aimerai bien un peu de survival (R-evil)ou il faut réfléchir avant d'agir avec peu de munition....cela me trotte depuis longtemps.

Il y a encore plein de truc que je dois tester..Peut être aussi du Aiming pour le mode de viser,la physique a incorporée,l'inventaire etc...

Le héro sera plus fin et détaillé que Conrad..

Bien la démo !

J'ai réussi à dénicher un bug (pas facile à trouver) :D

Lorsque Conrad effectue un saut en longueur pour s'accrocher à une plateforme, il suffit de maintenir haut et de "relâcher" la touche maj lors du saut, juste avant la phase d'accroche.
Ce dernier se téléporte alors en contre-bas et freeze, en gros aucune action n'est alors possible.

C'est tout pour le moment. Good job !

effectivement petit beug concernant le saut long arrivé accroché, chez moi ça fait un truc un peu different mais pareil, ça teleporte.
il suffit de toucher la touche haut quand on est accroché pour mettre a jour le beug

Bien joué,vais le fixer.. ;)

hello,

Nouvelle version envoyée..version 0.0.17.3

Bug corrigé sur le longjump + accroche..si vous en avez d'autres,dite le moi..

Fichier bien reçu  ;) , par contre ton OS c'est quoi ? Windows linux mac ? 32 ou 64 bits ?

Windows 64bits..

Fichier bien reçu  ;) , par contre ton OS c'est quoi ? Windows linux mac ? 32 ou 64 bits ?

Je te demande ça car j'ai windows xp 32 bit, et j'ai un message win32 non valide

Ptiseigneur a un Windows 64.


[quote]Bug corrigé sur le longjump + accroche..si vous en avez d'autres,dite le moi..

J'en ai un  autre !  :P
Dans la toute première scène un bas à gauche, il est possible de passer à travers le mur invisible (donc de gauche) et quitter la scène... grâce au "long jump".

Sapristi....

J'en ai un  autre !  :P
Dans la toute première scène un bas à gauche, il est possible de passer à travers le mur invisible (donc de gauche) et quitter la scène... grâce au "long jump".

Fixé!...;D j'attends le prochain.

Nouveaux mouvements..

Choc wall.



Le lancer..(mode gun)

Le lancer..(mode gun)

C'est quoi comme lancé ?  :bravos lancer de gun ?  Conrad qui jette son gun car il en a marre :P

Ensuite j'aurais des questions, est ce que tu utilises le grid ? Car avec l'object de mouvement plateforme il cohabite pas ? Ou alors tu utilise l'objet de direction avancé avec celui du mouvement de plateforme.

Tout ça pour le faite du déplacement par 32 pixel ou 16 je sais plus.

[quote]

Ensuite j'aurais des questions, est ce que tu utilises le grid ? Car avec l'object de mouvement plateforme il cohabite pas ? Ou alors tu utilise l'objet de direction avancé avec celui du mouvement de plateforme.

Tout ça pour le faite du déplacement par 32 pixel ou 16 je sais plus.

[/quote]

J’utilise un custom mouvement,il est composé du grid (pour la localisation du widget mouvement ) et d’une mécanique d’animation pour le déplacement et les actions..après pour le pixel,on peut choisir,4,8,12,...32,48 etc....

Je voudrais savoir un truc, c'est quoi la différence entre quand c'est écrit en rouge ou en vert ?

L'ordre des conditions peut influer sur l'exécution des évènements. Le rouge est une indication de mauvaise priorité.

Il est certain que l'ordre des évènements a son importance, notamment dans "l'éditeur de liste d'évènements" (qui, lui, n'affiche rien en rouge si c'est "mal hiérarchisé" pour un bon fonctionnement du programme). En revanche, pour la succession des conditions comme dans l'exemple, j'ai toujours pensé que le rouge représentait plus une perte de temps dans l'analyse de conditions moins spécifiques et utiles dans leur tri.

En effet, le programme tourne en boucle l'ensemble des lignes en respectant leur ordre. Et si on a par exemple pour une condition d'évènements la succession simultanée suivante dans l'éditeur d'évènements ...
* si le joueur appuie sur une touche
* si l'objet "Afflelou" est visible
* si l'objet "mamie" est en collision avec l'objet "orties"
* si le chrono est égal à 2 secondes (<- en rouge)
... le programme va lire l'ensemble des conditions avant de tomber sur une qui ne convient pas (pour zapper à la suite du "code").
En mettant le chrono en bas, le programme va vérifier des choses qui sont beaucoup moins spécifiques que la dernière condition.


En la remettant tout en haut de la liste en revanche (et du coup elle ne s'affichera plus en rouge) comme suivant ...
* si le chrono est égal à 2 secondes
* si le joueur appuie sur une touche
* si l'objet "Afflelou" est visible
* si l'objet "mamie" est en collision avec l'objet "orties"
... le programme ne cherchera pas à vérifier les conditions tant que le chrono ne vaut pas 2 secondes, ce qui limite considérablement la perte de temps lors de l'exécution du programme. Illico, si chrono différent de 2'', le logiciel passe à la suite en ignorant les autres conditions.

Sur une ligne, ça peut passer encore, mais un jeu a vite fait d'avoir maintes lignes composées de nombreuses conditions simultanées qu'il lui faut éplucher rapidement pour un fonctionnement fluide. Du coup, à mon sens, le rouge n'est pas un conseil pour s'adapter à un ordre précis des conditions afin d'éviter un soucis de priorité dans le programme, mais bien un conseil pour alléger l'exécution du programme en lui permettant de facilement ignorer des conditions dans une succession où la première suffit plus souvent pour zapper à la suite.

Après, je n'ai pas l'expérience de la plupart des membres de ce forum, et je peux faire fausse route, évidemment.

PS : pour revenir au sujet de post, je demeure sidéré par le soin apporté aux moindre détails de ce jeu. C'est là que je réalise que je suis dans l'approximatif le plus dégueulasse dans ce que je fais ^^"

Ok alors en rouge == pas bon quoi ;)

Oui les condition sans couleurs sont testées a chaque itération du programme de haut en bas (si on met 60 frames par seconde les conditions seront testées 60 fois en une secondes) par contre les conditions en vert sont déclenchée au moment de l'action donc la position de cette conditions dans le tableau n'a pas d'importance contrairement aux autres.

Si on compare à un script JS les conditions sont des if dans la boucle du programme et les conditions en vert sont des événements (par exemple on('click')).

C'est pour ça qu'il faut les mettre en début de la condition.

PS : pour revenir au sujet de post, je demeure sidéré par le soin apporté aux moindre détails de ce jeu. C'est là que je réalise que je suis dans l'approximatif le plus dégueulasse dans ce que je fais ^^"

Merci Yazorius,

Si tu veux le tester,dis le moi,je te le MP..

Hello,

Nouvelle version envoyée..version 0.0.17.5

Hotfix:
Fix bug collision wall when animation transition stopruntowalk is running.
Fix bug animation when fall is running and arrow is pressed.
Fix bug jump into the wall.

Toute première zone, en montant sur la plus haute des plateformes et en effectuant un saut en longueur sur la gauche, il est possible de sortir de l'écran.  ;D

si on va completement a droite,qu'on descend le plus bas possible, puis qu'on retourne sur la lonue ligne droite a gauche,le scrolling n'est plus ecran par ecran mais suit le personnage, c'est normal?

si on va completement a droite,qu'on descend le plus bas possible, puis qu'on retourne sur la lonue ligne droite a gauche,le scrolling n'est plus ecran par ecran mais suit le personnage, c'est normal?

(Le mode camera n'est pas fini,je me focalise sur les déplacements)

  :D