notamment le fait que si le joueur clique très prêt du point de pivot du personnage, celui-ci bougera très légèrement... sans pour autant marcher !
Il n'y a pas moyen de bloquer ce comportement? C'est à dire que si on clique trop près du perso de fait que le sprite se déplacera légèrement sans lancer d'animation, le sprite ne se déplace simplement pas? Tu me diras que cela peut poser des problèmes lorsque le perso doit rejoindre une position précise pour jouer correctement une animation en rapport avec le décor: il faut parfois pouvoir autoriser de petits ajustement de la position du sprite sans passer par une animation de marche. Toutefois normalement ces cas particuliers sont identifiables, et alors on peut recalculer l'ombre que dans ces cas précis.
Tu ne peux pas sinon lier le clique et le recalcule de l'ombre?
Enfin bon... pour de vrai... je crois qu'on chipote!
Si ta boucle perpétuelle est effectivement dans l'absolu, et tout particulièrement dans l'esprit d'un codeur, non optimale, ce qui compte au final c'est le résultat! Si avec ta boucle initiale ça fonctionne sans soucis et sans entrainer de pb de performances, et bien c'est juste parfait!
Tu as à mon avis mieux à faire pour ton trsè beau projet que te prendre la tête avec ce genre de détail. (--> allez hop, à tes pinceaux! ^^)
Et si tu finis par rencontrer, au bout du compte, un problème concret lié à ta boucle perpétuelle, et bien on en reparlera alors.
Et pour ceux qui veulent discuter le bout de gras sur des vision plus conceptuelles de l'optimisation de code, ya qu'à suivre le lien juste au-dessus ;).
J'y ai réfléchi et j'ai créé une zone de 100 px autour du hotspot du personnage.
Si on clique dans cette zone, le personnage ne se déplace pas.
C'est plus réaliste et ça résout mon problème.
Merci pour l'idée !
Du coup, j'ai réussi à créer une boucle qui ne ne recalcule la position que quand celle-ci a changé.
Au début de chaque scène (si j'ai besoin d'une ombre), j'indique l'orientation de l'ombre, son opacité et sa couleur :
Et ensuite le script miz_shadow.script fait le travail tout seul sans que j'ai besoin de m'en occuper.
La grosse différence avec mes précédentes tentatives, c'est que j'ai créé 2 variables CheckSetSprite et CheckDirection qui ont pour rôle de bloquer des portions du code quand celles-ci n'ont pas besoin d'être utilisées.
C'est fonctionnel et j'ai fait un test en ajoutant un bip sonore aux endroits sensibles du code (quand il est demandé d'afficher une image ou de recalculer sa position). Le test est encourageant : pendant le jeu, le bip ne retentit que quand le personnage se déplace et/ou change d'orientation.
J'ai appris beaucoup de choses dans cette discussion. Merci à tous pour votre aide !
Pour l'instant, il n'y a que quelques captures d'écran et une présentation des membres mais ça s'étoffera peu à peu !
Ah, et j'ai une question ! Peut-être pouvez-vous m'aider à y voir clair sur un problème que j'ai rencontré :
Il y a une scène en scrolling vertical dans le jeu. L'image d'arrière plan fait 1920x2416px.
Sur mon ordi, la scène passe sans problème mais sur l'ordi de mes parents, l'image ne se charge pas. Il y a un fond noir à la place. Je l'ai coupé en 2 et c'est bon, elle s'affiche.
Mis à part ce problème, le jeu tourne à la perfection sur cet ordi, même s'il est un peu ancien (environ 10 ans).
Je suppose que c'était un problème du genre "la carte graphique n'accepte pas les images au delà d'une certaine taille". Vous en pensez quoi ?
Savez-vous quelle taille d'image il vaut mieux ne pas dépasser pour éviter ce problème sur la majorité des ordinateurs, même un peu anciens ?
Merci d'avance !
Très sympa ce site, à l'image du projet!
Pas d'idée en revanche pour ces histoires d'images trop grandes... Une limitation mémoire possiblement, mais ça ne reste qu'une hypothèse vague. Seule certitude: sur les vieille bécane, l'affichage "standard" a longtemps été de 1024x768 ; au moins si tu fragmentes tes plans en parcelles de cette dimension, ça devrait être supporté même par des Pentium 1ère génération (voire des 486! ^^). Mais surement que tu peux te permettre plus grand sans soucis, sauf que de là à savoir jusqu'à quelle dimension exactement, je n'en sais rien.
C'est la grande peur du développeur, celle qui le réveille trempé de sueur en pleine nuit : le jeu qui s'avère ne fonctionner que sur l'ordinateur de son créateur.
J'espère qu'il n'y aura pas trop de problème de ce genre...
En attendant, je me sers de ce vieil ordi comme machine de test en espérant que ça suffise.
Pour patienter avant la sortie du jeu et vous faire découvrir l'univers ensoleillé de The Coral Cave, on vous prépare une courte bande-dessinée.
L'histoire de la BD se déroulera avant celle du jeu et sera l'occasion de suivre Mizuka dans l'une de ses minuscules aventures.
Vous y ferez connaissance avec les habitants de l'île, vous pêcherez des coquillages dans la mer cristalline et vous enquêterez sur une étrange créature.
Un aperçu de la page 1 crayonnée, avant la mise en couleur à l'aquarelle :
Excellente idée cette bd! Y'a plus qu'à patienter... bon courage!
"Voler est d'une simplicité biblique, si tu ne sais pas comment t'y prendre. C'est le truc important : ne pas être du tout sûr de savoir comment on s'y prend"
Il n'y a pas moyen de bloquer ce comportement? C'est à dire que si on clique trop près du perso de fait que le sprite se déplacera légèrement sans lancer d'animation, le sprite ne se déplace simplement pas? Tu me diras que cela peut poser des problèmes lorsque le perso doit rejoindre une position précise pour jouer correctement une animation en rapport avec le décor: il faut parfois pouvoir autoriser de petits ajustement de la position du sprite sans passer par une animation de marche. Toutefois normalement ces cas particuliers sont identifiables, et alors on peut recalculer l'ombre que dans ces cas précis.
Tu ne peux pas sinon lier le clique et le recalcule de l'ombre?
Enfin bon... pour de vrai... je crois qu'on chipote!
Si ta boucle perpétuelle est effectivement dans l'absolu, et tout particulièrement dans l'esprit d'un codeur, non optimale, ce qui compte au final c'est le résultat! Si avec ta boucle initiale ça fonctionne sans soucis et sans entrainer de pb de performances, et bien c'est juste parfait!
Tu as à mon avis mieux à faire pour ton trsè beau projet que te prendre la tête avec ce genre de détail. (--> allez hop, à tes pinceaux! ^^)
Et si tu finis par rencontrer, au bout du compte, un problème concret lié à ta boucle perpétuelle, et bien on en reparlera alors.
Et pour ceux qui veulent discuter le bout de gras sur des vision plus conceptuelles de l'optimisation de code, ya qu'à suivre le lien juste au-dessus ;).
J'y ai réfléchi et j'ai créé une zone de 100 px autour du hotspot du personnage.
Si on clique dans cette zone, le personnage ne se déplace pas.
C'est plus réaliste et ça résout mon problème.
Merci pour l'idée !
Du coup, j'ai réussi à créer une boucle qui ne ne recalcule la position que quand celle-ci a changé.
Au début de chaque scène (si j'ai besoin d'une ombre), j'indique l'orientation de l'ombre, son opacité et sa couleur :
Et ensuite le script miz_shadow.script fait le travail tout seul sans que j'ai besoin de m'en occuper.
La grosse différence avec mes précédentes tentatives, c'est que j'ai créé 2 variables CheckSetSprite et CheckDirection qui ont pour rôle de bloquer des portions du code quand celles-ci n'ont pas besoin d'être utilisées.
C'est fonctionnel et j'ai fait un test en ajoutant un bip sonore aux endroits sensibles du code (quand il est demandé d'afficher une image ou de recalculer sa position). Le test est encourageant : pendant le jeu, le bip ne retentit que quand le personnage se déplace et/ou change d'orientation.
J'ai appris beaucoup de choses dans cette discussion. Merci à tous pour votre aide !
Juste une mini update : on a ouvert le site du jeu.
thecoralcave.com
Pour l'instant, il n'y a que quelques captures d'écran et une présentation des membres mais ça s'étoffera peu à peu !
Ah, et j'ai une question ! Peut-être pouvez-vous m'aider à y voir clair sur un problème que j'ai rencontré :
Il y a une scène en scrolling vertical dans le jeu. L'image d'arrière plan fait 1920x2416px.
Sur mon ordi, la scène passe sans problème mais sur l'ordi de mes parents, l'image ne se charge pas. Il y a un fond noir à la place. Je l'ai coupé en 2 et c'est bon, elle s'affiche.
Mis à part ce problème, le jeu tourne à la perfection sur cet ordi, même s'il est un peu ancien (environ 10 ans).
Je suppose que c'était un problème du genre "la carte graphique n'accepte pas les images au delà d'une certaine taille". Vous en pensez quoi ?
Savez-vous quelle taille d'image il vaut mieux ne pas dépasser pour éviter ce problème sur la majorité des ordinateurs, même un peu anciens ?
Merci d'avance !
Très sympa ce site, à l'image du projet!
Pas d'idée en revanche pour ces histoires d'images trop grandes... Une limitation mémoire possiblement, mais ça ne reste qu'une hypothèse vague. Seule certitude: sur les vieille bécane, l'affichage "standard" a longtemps été de 1024x768 ; au moins si tu fragmentes tes plans en parcelles de cette dimension, ça devrait être supporté même par des Pentium 1ère génération (voire des 486! ^^). Mais surement que tu peux te permettre plus grand sans soucis, sauf que de là à savoir jusqu'à quelle dimension exactement, je n'en sais rien.
Merci pour ta réponse !
C'est la grande peur du développeur, celle qui le réveille trempé de sueur en pleine nuit : le jeu qui s'avère ne fonctionner que sur l'ordinateur de son créateur.
J'espère qu'il n'y aura pas trop de problème de ce genre...
En attendant, je me sers de ce vieil ordi comme machine de test en espérant que ça suffise.
Pour patienter avant la sortie du jeu et vous faire découvrir l'univers ensoleillé de The Coral Cave, on vous prépare une courte bande-dessinée.
L'histoire de la BD se déroulera avant celle du jeu et sera l'occasion de suivre Mizuka dans l'une de ses minuscules aventures.
Vous y ferez connaissance avec les habitants de l'île, vous pêcherez des coquillages dans la mer cristalline et vous enquêterez sur une étrange créature.
Un aperçu de la page 1 crayonnée, avant la mise en couleur à l'aquarelle :
A suivre !
J'accroche complètement à cette idée de BD pour mettre en contexte l'univers du jeu. Hâte de voir le résultat final !
Je vous souhaite encore plein de courage pour la suite !
Excellente idée cette bd! Y'a plus qu'à patienter... bon courage!
"Voler est d'une simplicité biblique, si tu ne sais pas comment t'y prendre. C'est le truc important : ne pas être du tout sûr de savoir comment on s'y prend"
Content que l'idée vous plaise !
La BD avance bien : on a fini de dessiner les 20 pages et la couleur est entamée !
Une nouvelle case pour vous donner une idée :
Nous inaugurons également notre boutique avec cette illustration que nous vendons sous forme de carte postale.
L'image est imprimée sur un joli papier Rives texturé 300g et au dos, nous avons appliqué un tampon fait-maison pour l'emplacement du timbre.
C'est disponible ici, pour ceux qui seraient intéressés :
http://thecoralcavestore.bigcartel.com/product/the-coral-cave-postcard
Voilà pour les news (sans oublier notre nouvel article pour indiemag).
A très bientôt !
Oh c'est super sympa comme idée
L'image est super, et j'ai hâte de lire la BD ! 
Trop de stress pour un si petit renard.
Pages