Discussion :

[N_I_C_S]

Bonjour à vous,

Je viens de metter en ligne sur itch.io la démo d'un petit concept pour lequel je serais curieux d'avoir quelques retours.

J'ai fait ça il y a un an et, en y rejouant, j'ai pas trouvé ça si mal haha ! Ce serait une sorte de jeu à scoring du style geometry wars en FPS, et l'idée que je voulais tester est une configuration spatiale particulière, une sorte de "double espace en boucle".

Par ailleurs, le moteur maison utilisé étant le même que pour un plus gros projet, ça me permettrait d'avoir des retours sur les problèmes possibles, donc n'hésitez pa à m'incendier si quelque chose déconne !

Quelques screens :





Lien :
https://n-i-c-s.itch.io/wire-killer

Merci à vous.

[Guntha]

Salut!

J'ai bien aimé, avec quelques maps supplémentaires et un peu plus de variété ça pourrait devenir un jeu culte!
La 2ème map rappelle Dusk, c'est toujours sympa (mais je me rappelle que sur un de tes anciens projets, il y avait déjà des maps avec un style un peu similaire, à l'époque je l'aurais sûrement comparé à Quake III, dans tous les cas c'est des bonnes références ) mais ça veut peut-être dire que le style graphique des maps a besoin de se démarquer un peu?

Je n'ai pas compris le concept tout de suite (que c'était une arène qui se répetait en boucle quand on s'en éloignait, et que les ennemis revenaient sans arrêt). La lenteur et le nombre des ennemis losanges qui se rapprochent donnent une ambiance assez oppressante :p

Première remarque en lançant le jeu: la musique était plutôt forte, et il n'y a pas d'option pour changer le volume directement dans le jeu :p
Je n'ai pas eu de problème technique, le jeu tourne bien (sur un Core i7-4790K avec une GTX 980) . Juste un détail mais il semble ignorer le Alt+F4?

[N_I_C_S]

Merci pour tes remarques,

Ah Dusk, quel level-design !
C'est vrai que j'ai naturellement tendance à reproduire ce genre d'ambiance, c'est ma manie des églises, je trouve ça classe dans les jeux alors il faut toujours que j'en colle une, ahah !
Bon, je vais surement reprendre tout ça pour en faire un vrai petit jeu.

Bien vu pour le volume général, ça ne serait pas de trop.

Pour le alt f4, tiens je m'étais jamais posé cette question (je ne le fais jamais), il faudrait surement associer explicitemnt un algo de fermeture à la fenêtre java...

[LittleWhite]

Bonjour,

Je n'ai pas encore testé. Pareil pour la pâte graphique, je reconnais là un style que j'avais déjà vu, il y a longtemps, sur le forum. Peut être le dégradé dans le fond .

[N_I_C_S]

Salut LittleWhite, oh lala je ne repasse par ici que maintenant, désolé...

Haha, oui ces skyboxes sont un vieux relent de mon truc procédural isotröma, elles sont calculées à la volée, rien de spécial mais ce qui est étonnant c'est qu'il suffit d'une petite résolution pour que ce genre de dégradé rende pas trop mal (128 px de côté pour celles-ci je crois).

Sinon j'ai pas avancé sur ce jeu, j'ai passé les 2 derniers mois à enfin faire un éditeur 3D, tourné au max sur les décors, par-dessus mon petit engine, dont ce projet-ci devrait bénéficier aussi en vitesse de fabrication de contenu (oui, un jour je finirai un jeu !).

Je vais d'ailleurs surement présenter cette petite merveille ici, avec des imports/exports standards peut-être pourrait-elle être utile à des gars comme moi qui n'ont jamais trouvé un modeler 3D avec lequel ils sont à l'aise...

D'ailleurs puis-je profiter de l'occasion pour discuter d'une petite notion technique : dans mon "système" les positions des objets sont basées sur des valeur entières, donnant un repère local dans lequel on a la position classique (en float), comme un code de Morton. Ainsi on évite les trop grandes valeurs et les erreurs d'arrondi pour les calculs physiques, se calculant dans l'espace des différences entre entiers. Ca permet des espaces gigantesques mais le problème c'est qu'on casse la récursivité d'une gestion de scène classique (matrices parent/enfant...).
Quelqu'un saurait-il si je me prend la tête avec un problème bien mieux résolu ? (c'est le flou artistique...)

[LittleWhite]

D'ailleurs puis-je profiter de l'occasion pour discuter d'une petite notion technique : dans mon "système" les positions des objets sont basées sur des valeur entières, donnant un repère local dans lequel on a la position classique (en float), comme un code de Morton. Ainsi on évite les trop grandes valeurs et les erreurs d'arrondi pour les calculs physiques, se calculant dans l'espace des différences entre entiers. Ca permet des espaces gigantesques mais le problème c'est qu'on casse la récursivité d'une gestion de scène classique (matrices parent/enfant...).
Quelqu'un saurait-il si je me prend la tête avec un problème bien mieux résolu ? (c'est le flou artistique...)

Pas certain d'avoir tout saisi. Juste en utilisant des coordonnées en entier, n'avez vous pas des soucis (des à coups) ?
Après, cela pourrait ne pas se sentir, si l'échelle du jeu est grande et n'a donc pas besoin des floats. Autrement, les floats marcheraient très bien, pas besoin de les éviter non plus.

C'est vraiment sympa et nerveux !

[N_I_C_S]

Merci !

Oui, ma question était quand-même incompréhensible...

En fait il y a 1 ou 2 ans j'ai programmé comme beaucoup un petit système de terrain infini en voxel, dans lequel on assigne aux "chunks" une position/place en entiers, comme des noeuds d'octree. Ca amène à gérer cette même place pour la camére, qui dit en gros dans quel chunk elle est, et sa position "classique" en float désigne sa position locale dans ce chunk.
Par exemple pour des chunks de 256 de côté, si la caméra a comme "entiers" 0, 512, 512, elle est implicitement dans le chunk 0, 2, 2, et si sa position floats passe de (254.5, 100.0, 100.0) à (258.6, 100.0, 100.0), on met à jour ses entiers à 256, 512, 512 et sa position à (2.6, 100.0, 100.0), etc...

Pour aller vite, ça permet la même précision de calcul, affichage, etc... qu'on soit à 0, 0, 0 ou à 10000000, 20000000, 50000000 car tout se fait relativement à la différence entre les entiers des objets (qui n'ont pas d'erreur d'arrondi).

J'ai généralisé en gros cette surcouche dans mon petit moteur, c'est tout bête mais je me demande si c'est comme ça que font les "vrais jeux" pour gérer des positions dans des très grandes maps...

[LittleWhite]

Je pense que l'approche est parfaitement correcte (après, je n'ai pas grande expérience sur les techniques pour les terrains infinis). De plus, je n'ai aucune idée de comment font les autres . Bref, à première vue, cela me semble bon.

[N_I_C_S]

Ok, merci, bizarrement il me semble que c'est une question forcément incontournable pour beaucoup de projets (avec les open worlds, etc...) mais qui semble ne jamais être abordée...

[mathieu]

par exemple minecraft utilise des coordonnées entières pour se positionner avec une limite qui dépend du processeur du serveur et des clients :
https://minecraft.fandom.com/wiki/Ja...on_hard_limits

donc on se rapproche de l'idée proposée par N_I_C_S.

[N_I_C_S]

Sympa ces pages techniques sur minecraft, en effet c'est bien les mêmes problématiques, ça fait plaisir.

ça me rappelle que quand j'avais fait mon generateur de terrain, j'avais hésité à partir sur des entiers 64 bits, mais il fallait déjà ~= 1 an pour atteindre le bord, je me suis dit que 32 ça devrait suffire ... Mais des distances sur 128 bits, c'est des malades !

Bon, je vais auto-valider que je ne fait pas d'hérésie, que c'est l'approche valable y-compris pour les jeux plus "généralistes".

Merci pour le doc !