[6502/NES] Remettre le pied à l'étrier... "GOLD RUSH 1849"

[vincent2105]

Salut à tous ! 

Contaminé à nouveau par le virus 6502/NES, je me lance une nouvelle fois dans un exercice qui n'aboutira peut être pas à un jeu complet. C'est plus pour le plaisir de me casser la tête sur des problèmes que j'affectionne et discuter un peu. J'ai tout laissé de côté pendant environ 5 ans, il va falloir dégripper la machine. 

En bref : NES, Assembleur 6502, Mapper MMC3 (utilisé sur des jeux comme SMB3). 

Nom du projet : "GOLD RUSH 1849"... 

Synopsis : Année 1849, on incarne un pionnier qui s'installe dans l'ouest Américain... Il arrive avec un baluchon et plante sa tente sur un lopin de terre. Ses occupations : chercher de l'or, pêcher, chasser, trapper, bucheronner, jouer au poker, chasser des primes, braquer des banques, acheter des terres (à cultiver ou pour le bétail), devenir commerçant. Les hivers seront rudes, les étés suffocants...
Au programme également : des quêtes et la rencontre d'une multitude de personnages créés procéduralement.

Première étape de mon projet : avoir une zone de jeu aussi vaste que possible. 

[vincent2105]

J'ai créé quelques tiles et rempli une nametable de 32x30 tiles afin d'avoir une idée de la taille de la map. Une tile = 1 écran dans le jeu. J'ai donc une zone de jeu de 960 écrans. On peut toujours faire plus, mais il me semble qu'une map affichée sur un seul écran est plus lisible. Et surtout se posera la question des variables à sauvegarder  pour chacun des écrans... Avec le mapper MMC3, j'ai une extension RAM de 8ko. 
On se déplacera d'un écran à l'autre avec un scrolling comme dans Legend of Zelda (si j'y arrive !) .
Tout ça n'est évidemment qu'une ébauche. Je dois maintenant créer les tiles me permettant d'obtenir toutes les configurations de paysages (montagnes, ruisseaux, lacs, etc). 
En fonction de la position du joueur dans la map, l'index de la tile  me permettra d'obtenir le background à afficher pendant le jeu.
Il n'y aura je pense qu'une seule ville au centre de la map, et quelques cabanes par ci par là. La zone de jeu étant relativement réduite, il faudra vraiment mettre l'accent sur les quêtes et les interactions avec les PNJ.
Premier screenshot, attention les yeux ! 

[Albert]

Ses occupations : chercher de l'or, pêcher, chasser, trapper, bucheronner, jouer au poker, chasser des primes, braquer des banques, acheter des terres (à cultiver ou pour le bétail), devenir commerçant.

Bon courage, ça va en faire des trucs à coder

[vincent2105]

Merci 
Oui, ça va en faire beaucoup ! Mais du fait que ce soient des mini jeux, ça sera plus motivant pour moi d'ajouter du contenu au fur et a mesure. 
Une fois la map et les déplacements en place, je pourrai plancher sur n'importe quel mini jeu.

[vincent2105]

En réfléchissant davantage, l'idée de générer aléatoirement la carte me plait de plus en plus. Tant au niveau des possibilités de gameplay que la "facilité de remplir" la carte.  

Je pense créer aléatoirement une map de générale de 16 x 16 zones comportant chacune 16 x 16 écrans. Soit une zone de jeu totale de 65536 écrans. Pour aller d'une zone à une autre, le joueur devra financer la construction de gares (ou se déplacer à pied s'il préfère ! ).

Concernant la mémoire, évidemment je ne peux conserver l'état de chacun des 65536 écrans. Une grande partie de la RAM sera allouée à la zone de 16x16 écrans en cours de découverte jusqu'à ce qu'elle soit "contrôlée" par le joueur. Puis, le joueur devra étendre son influence sur les autres zones.  L'idée, c'est de conserver sur un octet l'état de chacune de ces zones, soit 256 octets pour la map de 65536 écrans.

[vincent2105]

Je poursuis mes réflexions... 

Je songe actuellement à ne pas utiliser le mapper MMC3... donc j'oublie les 8ko d'extension RAM, les sauvegardes, les 256 ko de CHR ROM (pour les tiles) et 512 ko de ROM (pour le programme) .

Ca me faciliterait les choses, mais le sujet me parait plus intéressant en choisissant un mapper NROM, celui qui était utilisé pour les premiers jeux NES (16 ou 32 ko de ROM et 8ko de CHR ROM)... Du coup 2 ko de RAM, pas de pile permettant la sauvegarde, il faudra un code et faire des concessions.