Myask wrote:You know Z1 had the dungeons mingled in mapspace, such that for all 9 dungeons, only two 8x16 maps were used? (Just, different portions.)
It's not really a huge issue, the game uses an area index to figure out which room to load, based on the player's X,Y on the local map. No "map space" needed. It's all indexed.
Myask wrote:Rogue itself was one-way. (Consider the difference between SMB3 and SMB1.)Nethack-alikes would be devilishly hard, because its addition to the genre was saving the entire dungeon, not just the floor you're on.
I have a solution to "storing" the floors, actually. I was studying how several games encode/decode their password data, and I could apply an offset to the generation seed, whenever the player goes up or down a floor, using a shift byte. Seed generation can create the same data, if done properly.
Speaking of--
The seed will be displayed on-screen to the player, on dying/completing the game.
Because a community playing rogue-likes and exchanging difficult map seeds, is something I miss dearly.
Myask wrote:"fully-functional" could mean a lot of things, unfortunately.
In the case of my rogue-like, by fully functional, I mean that it will use seed generation, and the entirety of floors will be generated by the seed.
Room "patterns" (pre-built rooms) will be used very scarcely. Mostly for shops and such.
No "same 3 rooms in a row", as is common in, say, Rogue Legacy.
Myask wrote:Don't forget to allocate screen space for status.
Didn't get around to that part, yet.
Myask wrote:But really, so long as you don't allow geo-mod (or rationalize "dungeon fixing-crews"), you only need to store ONE thing about each level's layout, to remember the walls (and stair-locations): the seed. (You'll want to have the monster, loot, etc. generation separate, in this case; though traps might be desired to be left in.) Then, you just have to store some number of monsters/objects per dungeon level. Now, you can trim monsters down a bit by assuming they heal up when you leave, but if not, X/Y/HP/ID; items would similarly be in X/Y/quantity/ID. As long as you don't have splitting/breeding monsters.
The seed will be capable of generating the entry/exit locations. Rooms are created based on a set of rules, location, number, min/max size, and potential for treasure/traps.
Splitting monsters would be handled the same way scrolling an enemy on-screen works in most other games, the game may place one, and it may freely split when taking damage, but only if there's a sprite slot available for it.
Myask wrote:Of course, what WILL be likely-to-be-stored in a roguelike is a "seen" map...this can be cut down if we have discrete rooms, to just a few "did they see this room" flags. A maze, however, one can simplify to "did they visit this intersection", to get a 4x or better reduction...
Huh... I hadn't considered intersections! I just made a note in the project file. Thanks for the suggestion! I have an idea, based on something I wrote for Cat Quest's engine.
Myask wrote:side note: cq4.nsf has been playing in the background for a while and I took no notice. Seems good and unobtrusive and exploration-esque.
It's funny you've been listening to cq4, specifically. As I've been listening to that song, whenever I work on the overworld screens!
Myask wrote:As for dungeon graphics, 32 tiles is a good number; because it'd be a neat bankable slice, once you leave NROM's non-mapper behind. Mind, doors don't seem to be present, as far as common dungeon objects go...
Didn't get around to doors, and trap graphics, quite yet. A few may also be "invisible" depending on the player's stats/class.
...Why would I leave NROM?! O_O
Extreme restrictions, are so much fun! =D
Update on Dragon Slayer clone:
I worked on some outdoor locations, and I was stingy as hell with the tiles, when possible.
I have 66 BG tiles left, and I've only drawn a few sprites so far.
I intend on fleshing out that cave background, later.
