Bullet time

Je suis sur un projet de jeu de cowboy en ce moment et j'aimerais ajouter la possibilité de ralentir le temps, au moins pour les duels et au mieux avec une touche à n'importe quelle moment du jeu ( à la red dead redemption )

room_speed aurais pu faire l'affaire mais ça donne plus l'impression que ça lag donc je cherche un autre moyen, j'avais déjà fais un prototype de bullet time juste sur le mouvement d'une balle avec une variable global qui influence la vitesse de la balle mais le problème c'est que là en fonction de cette variable le personnage saute plus ou moins haut et donc c'est gênant

Je me demandais donc si il y avais pas un moyen d'ajouter cette fonction, peut être une méthode miracle ?

Merci d'avance !

Une screenshot du jeu pour les curieux

****** ces graphismes T_T

Alors, je pense que la meilleure solution est de créer une variable global.timeSpeed, par laquelle tu multiplies les valeurs que tu intègres. Exemple :

Code:

xAccel = 1; // supposons qu'on appuie sur "droite", le perso accélère vers la droite.
xSpeed += xAccel * global.timeSpeed // première intégration pour la vitesse
x += xSpeed * global.timeSpeed // seconde intégration pour la position

Si coder toi-même ton moteur physique te fait peur, n'hésite pas à demander, mais cette méthode est largement la plus simple ;)
Pour la gravité, utilise simplement une accélération constante vers le bas.

Merci je vais tester ce que tu m'as dis, pour ce qui est du moteur physique ça devrais aller par contre j'ai fais un prototype du jeu et j'aimerais bien recevoir des conseils pour améliorer ma façon de coder, pour l'instant ça ressemble plus à du bricolage et pour les projets avec pas mal de contenu ça deviens vite ingérable

ça serais cool si tu pouvais regarder, merci ( D-z ou n'importe qui d'autre d'ailleur)

Lien du fichier gmk :
http://minus.com/mxqPfjKP1/

Edit : J'ai fais un test pour le ralenti, en mettant comme valeur de gravité la valeur de global.timeSpeed(vitesse du jeu)
et ensuite j'ai ajouté ça :

Code:

x += xSpeed * global.timeSpeed // seconde intégration pour la position

et ça marche, je suis tombé dessus par hasard, mais en tout cas la hauteur du saut varie pas, donc c'est plutôt cool.

Ma foi, c'est propre et clair :)

Petites remarques tout de même :

- Tu mets beaucoup de scripts, ça m'étonne un peu pour le perso, a priori il serait plus simple de les mettre directement dans les events. Décomposition à outrance :D
Pour les scripts imbriqués qui sont mieux à part dans leur fichier, veille à leur donner un nom explicite. Les grouper par dossiers peut aussi beaucoup aider (même si GM ne permet pas de désigner un dossier dans le code). Là j'ai des script_create, des script_step, mais je ne sais pas à quel objet ils appartiennent.

- Syntaxe : un if ou un else suivi d'une seule instruction ne nécessite pas d'accolades. Un if est lui-même une instruction, donc :

Code:

if sur_echelle
{
    script_deplacement_echelle()
}
else
{
    if monture != 0
    {
        script_deplacement_cheval()
    }
    else
    {
        script_deplacement()
    }
}

se réduit en :

Code:

if sur_echelle
    script_deplacement_echelle()
else if monture != 0
    script_deplacement_cheval()
else
    script_deplacement()

- Astuce : si tu veux commenter temporairement une portion de code, utilise :

Code:

/*
code
code
code
//*/

Ainsi, tout le code est décommenté si tu doubles le premier slash, ça va plus vite que de virer les deux /* */ :)

- Factorisation : tes contrôles sont définis dans plusieurs objets. Mieux vaut les isoler dans un objet principal et en faire des variables globales. Tu peux même créer des scripts retournant vrai ou faux pour chaque touche, ainsi si tu veux plus tard gérer des joypads tu pourras simplement modifier ces scripts :)

- Répartition des tâches : l'action "monter sur le cheval" n'est pas définie dans le héros (celui qui la fait), mais dans le cheval. C'est une mauvaise manie d'éparpiller ainsi les évènements ! Tu peux faire exactement la même chose avec un event "collision avec le cheval" dans ton héros :

Code:

if( monture == noone && vitesse_v > 0)
{
    monture = other.id;
    sens = other.sens;
}

Tu noteras aussi le monture == noone que j'ai rajouté. Tu aurais eu des problèmes avec plusieurs chevaux, car tu pouvais en monter un sans descendre de l'autre avant ! "noone" remplace ta valeur 0, ça ne change pas grand-chose puisqu'aucun objet n'a l'ID 0, mais c'est l'équivalent de "null" dans d'autres langages, et représente spécifiquement la notion objet de "rien".

- Objets liés : une question complexe, comment traiter une monture ? Tu as choisi de conserver l'objet cheval et l'objet héros, et de lier le second au premier. Si cela permet de garder les deux entités, cela peut en revanche causer pas mal de tracas lors des gestions de collisions et tutti quanti. Si à aucun moment tu n'as besoin de savoir lequel, du héros ou de sa monture, est en collision avec un autre objet, il sera plus aisé de simplement déspawn le cheval lorsqu'on le monte, et de changer le sprite, le mask et les variables physiques du héros pour le "transformer" en héros à cheval, traité ensuite comme un seul objet.

- Sprites et masks : tu peux assigner un sprite à ton héros tout en gardant le mask, cela ne changera strictement rien à l'exception que tu placeras bien un mec et pas un carré jaune dans l'éditeur ;)
Si ton masque est rectangulaire (ou ellipsoïde, ou losange), tu peux à la place configurer la bounding box directement dans le sprite (bouton "Modify Mask").

- Hiérarchie de parents : il n'est pas utile de créer un objet parent_bloc. Place simplement l'objet bloc en parent des autres, et teste les collisions avec lui ;)

- Appartenance : l'arme ne se sépare jamais du perso, et ne contient aucun code (si ce n'est suivre la position du perso). Quelques variables et un simple draw suffiront ;)

- Précision des calculs : déplacer ton perso par pas de 0.1 est une perte de temps processeur. Il vaut mieux arrondir ses coordonnées, et faire des boucles à pas de 1.

- Astuce : crée tes nuages aléatoirement plutôt que de t'embêter à les placer :p

Il vaut mieux écrire

Code:

if sur_echelle
{
    script_deplacement_echelle()
}
else
{
    if monture != 0
    {
        script_deplacement_cheval()
    }
    else
    {
        script_deplacement()
    }
}

plutot que

Code:

if sur_echelle
    script_deplacement_echelle()
else if monture != 0
    script_deplacement_cheval()
else
    script_deplacement()

Ecrire en compact n'apporte aucun avantage, et est beaucoup mois facile pour se relire/pour que les autres comprennent le code.
Il vaut mieux prendre un peu plus de temps et garder une certaine rigueur dans son écriture.

Citation :

- Tu mets beaucoup de scripts, ça m'étonne un peu pour le perso, a priori il serait plus simple de les mettre directement dans les events. Décomposition à outrance
Pour les scripts imbriqués qui sont mieux à part dans leur fichier, veille à leur donner un nom explicite. Les grouper par dossiers peut aussi beaucoup aider (même si GM ne permet pas de désigner un dossier dans le code). Là j'ai des script_create, des script_step, mais je ne sais pas à quel objet ils appartiennent.

Je trouve ça plus rapide de changer un script plutôt qu'un morceau de code dans l'objet, par contre les dossiers ça peux être cool

Citation :

- Syntaxe : un if ou un else suivi d'une seule instruction ne nécessite pas d'accolades.

J'arrive pas a m'y retrouvé sans les accolades ^^"

Citation :

- Astuce : si tu veux commenter temporairement une portion de code

Pratique j'y penserais

Citation :

- Factorisation : tes contrôles sont définis dans plusieurs objets. Mieux vaut les isoler dans un objet principal et en faire des variables globales. Tu peux même créer des scripts retournant vrai ou faux pour chaque touche, ainsi si tu veux plus tard gérer des joypads tu pourras simplement modifier ces scripts

J'ai toujours peur de mettre trop de variable global du coup j'en met jamais xD mais effectivement c'est une bonne idées, je vais faire ça

Citation :

- Répartition des tâches : l'action "monter sur le cheval" n'est pas définie dans le héros (celui qui la fait), mais dans le cheval. C'est une mauvaise manie d'éparpiller ainsi les évènements ! Tu peux faire exactement la même chose avec un event "collision avec le cheval" dans ton héros :

Ouais, je sais pas pourquoi j'ai mis ça là.

Tu noteras aussi le monture == noone que j'ai rajouté. Tu aurais eu des problèmes avec plusieurs chevaux, car tu pouvais en monter un sans descendre de l'autre avant ! "noone" remplace ta valeur 0, ça ne change pas grand-chose puisqu'aucun objet n'a l'ID 0, mais c'est l'équivalent de "null" dans d'autres langages, et représente spécifiquement la notion objet de "rien".

Ok !

Citation :

- Objets liés : une question complexe, comment traiter une monture ? Tu as choisi de conserver l'objet cheval et l'objet héros, et de lier le second au premier. Si cela permet de garder les deux entités, cela peut en revanche causer pas mal de tracas lors des gestions de collisions et tutti quanti. Si à aucun moment tu n'as besoin de savoir lequel, du héros ou de sa monture, est en collision avec un autre objet, il sera plus aisé de simplement déspawn le cheval lorsqu'on le monte, et de changer le sprite, le mask et les variables physiques du héros pour le "transformer" en héros à cheval, traité ensuite comme un seul objet.

J'avais prévu qu'il y ai plusieurs chevaux de couleurs différentes ^^" mais j'avoue que j'ai implanté le cheval en dernier un peu à l'arrache donc je pense que je peu améliorer ça.

Citation :

- Sprites et masks : tu peux assigner un sprite à ton héros tout en gardant le mask, cela ne changera strictement rien à l'exception que tu placeras bien un mec et pas un carré jaune dans l'éditeur
Si ton masque est rectangulaire (ou ellipsoïde, ou losange), tu peux à la place configurer la bounding box directement dans le sprite (bouton "Modify Mask").

Ouais effectivement, je vais corriger ça

Citation :

- Hiérarchie de parents : il n'est pas utile de créer un objet parent_bloc. Place simplement l'objet bloc en parent des autres, et teste les collisions avec lui

Pas bête, j'y avais pas pensé

Citation :

- Appartenance : l'arme ne se sépare jamais du perso, et ne contient aucun code (si ce n'est suivre la position du perso). Quelques variables et un simple draw suffiront

Ouais je pense que c'est mieux avec un draw

Citation :

- Précision des calculs : déplacer ton perso par pas de 0.1 est une perte de temps processeur. Il vaut mieux arrondir ses coordonnées, et faire des boucles à pas de 1.

Le problème c'est que si je veux descendre en dessous de 1 en vitesse je fais comment ?

Citation :

- Astuce : crée tes nuages aléatoirement plutôt que de t'embêter à les placer :p

C'étais prévu, surtout que la comme ils bougent, ils vont finir par sortir de la room ^^

En tout cas merci d'avoir pris le temps de m'aider, j'ai appris plein de chose
M@d_Doc : Ok je reste sur les accolades
Merci à vous deux, si quelqu'un d'autre a des conseils je suis toujours prenneur

Dernières questions, dans le jeu il y aura plusieurs armes avec chacune leurs propres caractéristiques ( munition, cadence de tir etc), faut que j'utilise un tableau pour ça ?

Edit : Et aussi, avec le joystick il y a moyen d'utiliser "press" et "released" ?

Pour ce qui est des variables globales, est une variable globale quelque chose qui ne dépend d'aucune entité de ton jeu, mais du programme lui-même. Donc par exemple les touches, la résolution de l'écran... tout ce qui n'est pas affecté par le jeu mais par le programme. Une alternative est de les définir dans un objet représentant le programme, mais il faut te taper nomDeLobjet.variable à chaque fois.

Pour les accolades : libre à toi, hein :p Perso sous Eclipse la coloration syntaxique est suffisamment bien foutue pour que les if / else if soient clairs. Par contre je trouve ça plus joli pour les doubles parcours :

Code:

for( i = 0; i < 10; i++ )
    for( j = 0; j < 10; j++ ) {
        //code
    }

Pour ton problème de vitesses inférieures à 1.0 : je vois ce que tu veux dire... À ce moment-là, plutôt que de systématiquement arrondir les coordonnées du perso, fais-le uniquement quand tu le plaques contre un sol ou un mur.

Pour les joysticks : nope, il faut le faire à la main. Je cherche dans mes fichiers si je retrouve le moteur que j'avais fait il y a un moment qui gérait ça...

Sinon Caly avais fait un moteur pour les joysticks : https://cbna.forumactif.com/t11593-les-exemples-de-caly

Voici : https://dl.dropbox.com/u/30443318/engine.gmk

Les contrôles sont TFGH pour les déplacements, Z pour sauter et E pour le dash. La partie dont tu as besoin est dans le dossier "keys" des scripts, et dans les constantes :)
Le script keys_update() est minimal, il faut rajouter des lignes pour chaque touche dont tu veux tester l'appui/relâchement. Ou alors faire pointer les constantes vers des index de tableau continus, et faire un parcours :)