Sunrise
Posté le 22/01/2020 10:39
Bonjour
Je commence à penser à la suite spirituelle de Noon, nommée Sunrise (j'ai trouvé un nom classe, je suis content
).
J'ai déjà commencé à noter ce que je veux que le jeu soit. Il faut que je continue à réfléchir à la façon dont je vais stocker tout ça avant de coder.
Voici les objectifs que je me fixe pour ce prochain jeu :
1. Créer un univers plus grand que celui de Noon. Je veux créer la map la plus gigantesque possible.
2. Faire un jeu qui est un jeu. Avec système d'inventaire et progression RPG customisée (pas de système d'XP, un concept original).
3. Inventaire et stats de joueur.
4. Donjons parsemés sur la carte, générés aléatoirement une fois entrés.
5. Villages, avec indications sur la position des donjons.
6. Un temple central de la map, qui sera très difficile. Destiné au endgame.
7. Durée de vie en dizaines d'heures.
8. Combat tour par tour, encore une fois système original.
9. Mode texte (obvious).
10. Des surprises.
11. Sur le même principe que Noon, il sera recommandé de tenir une carte papier en dehors du jeu pour éviter de ce perdre dans cet univers immense.
Cela risque donc d'être un gros défi pour moi, mais je souhaite créer un jeu qui m'amuse et est intéressant à la fois à coder et à tester.
Étant donné que ce projet est beaucoup plus conséquent que Noon, il reste des points à résoudre :
1. La génération. Procédurale, vaut-il mieux utiliser un système aléatoire seedé (celui d'Alexot par exemple) ou tout générer d'un coup ? Il faudra voir comment ça se débrouille niveau perf.
2. Le stockage. Les donjons seront placés aléatoirement sur la carte et leurs emplacements sauvegardés. La taille d'un donjon en mémoire variera selon la taille de la carte.
Les écrans devront également être gérés de façon légère, l'utilisation de ~NCUT sera obligatoire.
3. La vitesse. Le jeu doit être rapide, il faudra faire un compromis mémoire vitesse.
Il y a sûrement d'autres détails, je préfère tout noter ici pour m'engager.
Si vous avez des idées, retours ou questions n'hésitez pas
Citer : Posté le 22/01/2020 13:04 | #
Wow, effectivement un nom stylé pour un projet stylé.
Je suis 100% dans le délire, je pense que donner une application de qualité à Noon est le moyen d'en démontrer la valeur.
Voilà quelques idées de ma part.
Tout dépend de ta capacité à compresser en mémoire par rapport à la taille de la carte que tu planifies. Pour quelque chose de vraiment immense, les Str ne suffiront pas car 20×512 octets c'est probablement trop petit. Dans les listes et les matrices, on peut compresser mais c'est un peu chiant à cause des problèmes de précision numérique.
Seeder c'est juste une forme de compression très extrême : la décompression est une génération complète. Si tu pars là-dessus, il est probable que tu ne puisses pas trop modifier la carte pendant le jeu (il faudrait stocker les modifications ailleurs et ça commence à exploser assez vite).
Sinon tu peux tenter de trouver un juste milieu de compression entre la taille de carte que tu veux, la complexité des structures que tu veux faire apparaître, la complexité des modifications que tu veux pouvoir faire durant le jeu, et le temps de compression/décompression.
Selon la méthode de stockage tu peux te rapprocher de l'entropie qui ne variera pas forcément beaucoup.
Les Str sont peut-être un bon outil pour la mémoire temporaire (ie. carte actuelle ou je ne sais quoi d'autres). Elles sont rapides, les opérations sont assez polyvalentes, elles prennent peu de places et n'ont pas de problèmes de précision.
Citer : Posté le 22/01/2020 14:06 | #
Wow, effectivement un nom stylé pour un projet stylé.
Je suis 100% dans le délire, je pense que donner une application de qualité à Noon est le moyen d'en démontrer la valeur.
Voilà quelques idées de ma part.
Merci
Tout dépend de ta capacité à compresser en mémoire par rapport à la taille de la carte que tu planifies. Pour quelque chose de vraiment immense, les Str ne suffiront pas car 20×512 octets c'est probablement trop petit. Dans les listes et les matrices, on peut compresser mais c'est un peu chiant à cause des problèmes de précision numérique.
Seeder c'est juste une forme de compression très extrême : la décompression est une génération complète. Si tu pars là-dessus, il est probable que tu ne puisses pas trop modifier la carte pendant le jeu (il faudrait stocker les modifications ailleurs et ça commence à exploser assez vite).
Sinon tu peux tenter de trouver un juste milieu de compression entre la taille de carte que tu veux, la complexité des structures que tu veux faire apparaître, la complexité des modifications que tu veux pouvoir faire durant le jeu, et le temps de compression/décompression.
Je pensais peut-être générer les villages et paysages de façon seedée, et stocker toutes les altérations dans une Matrice (plus rapide à accéder qu'une List et même coût en mémoire). Il est possible de stocker 38 bits de données dans une case, mais les extraire peut-être lent.
Les Str me semblent un bon moyen également, pour l'inventaire et les stats du joueur je les utiliserai peut-être. Les donjons seront assez rares et à position fixes, certains bâtiments auront des modifieurs également. J'aimerai pouvoir générer entre 1000 et 2000 points changeants, à creuser.
Je rajoute aussi que les donjons seront générés au moment où ils sont entrés, et à chaque fois de façon aléatoire.
Ils seront différents à chaque fois, mais leur difficulté restera fixe. (Choix de design.)
Les Str sont peut-être un bon outil pour la mémoire temporaire (ie. carte actuelle ou je ne sais quoi d'autres). Elles sont rapides, les opérations sont assez polyvalentes, elles prennent peu de places et n'ont pas de problèmes de précision.
Je les utiliserai sûrement pour ce genre de choses, maintenant que j'y pense les structures simples devraient pouvoir tenir dans des Str (étages de donjons par exemple).
Merci pour ta réponse
Ajouté le 31/01/2020 à 09:55 :
J'ai pas mal avancé sur le concept du jeu, je continue d'y penser régulièrement et d'ajouter de la profondeur au jeu (en prenant en compte les limitations bien sûr
Voici ce que j'ai déjà fait concernant la génération de carte, si vous avez une meilleure idée n'hésitez pas à en faire part
(Je ne partagerai pas mon travail sur le système de combat et les donjons, je préfère garder ça au chaud.)
La carte sera divisée en régions de 128x128, divisés en carreaux de 16x16.
-> 64 cases par région
La région comportera entre une et quatre villes, constituées de une à 16 cases.
Les probabilité seront de décroissance exponentielle (50% des villes seront
d'une case, 31.25% de 4, 12.5% de 8 et 6.25% seront de 16 par exemple).
Le nombre de donjons générés seront dépendants du nombre de villes, ces
dernières se développant dans les zones alentours.
Le nombre de donjons sera 'nombre de villes//2+1'.
Les maps seront pré-générées quand une région est entrée, par case (64 zones
i.e.). Quand une case est entrée, la case en question est générée utilisant les
paramètres de la génération régionale.
Les noms de villes et temples seront également générés sur base seedée,
sur des bases différentes dépendant des régions (-> histoires différentes).
Citer : Posté le 31/01/2020 10:11 | #
Intéressant. Je pense qu'on peut faire mieux sur la taille des villes; actuellement il faut visiter 16 villes pour en avoir une de taille 16, soit 6.4 régions en moyenne. Puisque chaque région fait 128x128 caractères, ça fait une très grande ville tous les 713 écrans.
Dans Noon, j'avais exploré une région de quoi, 30x30=900 écrans de mémoire, mais j'avais vraiment cherché à pousser et l'exploration allait vite parce qu'il n'y avait pas tant de chose que ça sur la carte. Donc là, ça paraît assez faible comme probabilité.
Sinon l'idée de générer régionalement me plaît, attention aux raccords
Citer : Posté le 31/01/2020 10:22 | #
Les très grandes villes sont censées être extrêmement rares, je pense qu'elles permettront le fast travel (les villes à partir de 4x4 ou 8x8 également, à voir) ainsi que de gros centres de commerce, et je ne veux pas abuser de ça.
Une région fait 128x128 écrans et non caractères, donc oui ça va être quelque chose d'en trouver une
Peut-être que j'en placerai une en génération forcée "près" du spawn.
Les villes ne seront qu'une partie du contenu du jeu, les régions vides auront une probabilité de faire apparaître des points d'intérêt (comme Noon, mais en utile), et les donjons auront une part très importante également.
Je pense également à un système de quête à la WoW, avec des transports à faire de ville en ville ou donjons à clear.
Ça donnerait une grosse importance à la cartographie pour avancer correctement, les villes/donjons étant tous nommés et non localisés directement.
Citer : Posté le 31/01/2020 11:06 | #
Alright, je vois. Cela dit 128x128 écrans par région c'est sûr qu'on en trouvera jamais...
Bon courage, je suis curieux de voir la suite o/
Citer : Posté le 16/06/2020 11:07 | #
Vous ne voulez pas lire ça ? résumé : le projet n'est pas mort.
Je continue le design de Sunrise dans l'ombre ! Je ne peux pas vraiment m'avancer sur les mécaniques sans spoiler le jeu, mais je vais donner ce que je peux.
Je m'éloigne peu à peu de la direction monde ouvert pour partir sur un roguelike tour par tour avec des mécaniques originales et intéressantes à mon goût.
La gestion des villes n'a probablement pas de futur, vu que mon scénario implique qu'il n'y ait pas masse d'humains actifs
Étant donné le genre du jeu, je veux me concentrer sur l'expérience utilisateur avant tout. Vu le langage choisi, je préfère bien poser tout ce que je compte programmer avant de commencer.
Idéalement je commence à travailler en Basic d'ici un mois
S'il reste de la place après la programmation des donjons, du système de combat etc. je prévois une place pour un overworld à la Noon avec des points d'intérêt utiles
Ajouté le 27/07/2020 à 18:52 :
Le projet n'est plus vraiment à jour, j'ai totalement changé de direction niveau game design.
Sunrise devient "Noon II", je me concentre sur la création d'un "meilleur" moteur et sur l'ajout de contenu.
La matrice générée dans ma dernière version pèse 14400 octets pour 120x40 écrans (presque deux fois plus grand que l'original).
J'en reparle dans la prochaine RDP.
Dépôt du projet, que je mettrai à jour tous les jours.
https://gitea.planet-casio.com/KikooDX/noon2
Ajouté le 29/07/2020 à 11:28 :
Jour 3 :
La version d'aujourd'hui est relativement stable, il y a quelques murs qui apparaissent au pif sur la map, c'est normal (pour les tests).
Citer : Posté le 29/07/2020 18:23 | #
Et ça tourne à quelle vitesse tout ça ?
Citer : Posté le 29/07/2020 18:40 | #
Et ça tourne à quelle vitesse tout ça ?
10 FPS en déplacement, transition d'un écran à l'autre rapide. La génération de la map prend 30 secondes environ, sans l'affichage ça descend à 18 (mais on perd l'effet placebo
Le moteur d'affichage n'est pas encore bien optimisé, ce nombre devrait augmenter dans les prochains jours