Best way to make Castlevania map?

Yes, it will be a (very) long process - that's unavoidable.

Global values are generally best avoided where possible. It's usually better to use object alterable values (if for no other reason than to keep them organised) and arrays. For tracking which areas of the map have been unlocked, there are loads of possibilities - it doesn't much matter how you store that information during the game, but when saving the player's progress you'll need to include it in the same array as other information like the player's location and health.

For any game that's even remotely close to the scale of CSotN, you will want to create your own custom level editor - the time saved by having a good design tool tailored to your specific game (instead of the generic and clunky frame editor that is built-in to CF2.5), will easily outweigh the time it takes to create one.

It's going to be easiest to have the entire game (minus the main menu etc) run in a single frame, but only load one "room" at a time, from an array (do not use one frame that's the size of the whole map, and do not use a separate frame for each "room").

Obviously if you're just making a really tiny game (fewer than 10 rooms maybe), you can do things any way you like.

[QUOTE=MuddyMole;766081(do not use one frame that's the size of the whole map, and do not use a separate frame for each 'room').[/QUOTE]

What is the reason to not use a frame with the size of the whole map?
Is it very demanding for the cpu/gpu, or is it even noticeable to run a map that is much larger than the level itself?

The reason I'm asking is that I'm curretly building all my levels in one frame that is loaded in "chunks" at start of level, so every object is not there at the same time but the size of the level is the same, and it's somewhat large (15168x8256), but I haven't noticed any slowdowns yet.

Quote from vSv

The reason I'm asking is that I'm curretly building all my levels in one frame that is loaded in "chunks" at start of level, so every object is not there at the same time but the size of the level is the same, and it's somewhat large (15168x8256), but I haven't noticed any slowdowns yet.

To my knowledge, this technique you're using should be fine. "Chunking" levels and loading them on-the-fly is a pretty standard game technique, used in all sorts of games, ranging from Zelda, to Grand Theft Auto, and probably most famously Minecraft. But notably, these games "stream" the chunks in as needed (only the chunks that the player is in, and the ones immediately around them). Loading all the "chunks" in at the start of the level kind of defeats the point of chunking it up in the first place.

But if you haven't noticed any slowdown so far, you're probably fine.

It might be good idea to find someone with a 10 year old low-end laptop (or if you have one yourself) to do some "limit testing" for your game. You'll get a better idea of what things cause slow down on a slower machine.

One thing I learned in general is that video games are not built on "perfect code" but "good enough hacks" that no one will really notice. One of my favorite little "tricks" was in Mario Galaxy -- they needed to have a certain door in a certain level make a text note popup. But instead of programming a new object that Mario could "read" they just hid an already programmed Sign Post object behind the door.

Please login to see this link.

Quote from JimJam

To my knowledge, this technique you're using should be fine. "Chunking" levels and loading them on-the-fly is a pretty standard game technique, used in all sorts of games, ranging from Zelda, to Grand Theft Auto, and probably most famously Minecraft. But notably, these games "stream" the chunks in as needed (only the chunks that the player is in, and the ones immediately around them).

The part you left out is that also they dispose of the previously loaded chunks to make way for the new ones - if you leave an area and then come back to it, usually enemies etc will have respawned, because the game has had to regenerate that section of the map again. In fact, if you don't do that, then loading the map in chunks has little benefit over loading the whole thing at once - it will mean that the game loads slightly quicker to begin with, but then there is the added risk of a brief lag during the actual gameplay, as a new chunk is loaded, which is far more annoying to the player.

CF2.5 can "de-activate" objects when they get too far away, so it doesn't waste time applying events to them, but it must still be storing all their properties in memory, which could perhaps affect performance if you have enough of them (probably more so than the physical size of the map).

These days, computers (and especially graphics cards) are so powerful that you can "get away with" a lot. Whether that's the case for a low-end Android smartphone, or an old unplugged laptop in battery-saver mode, I don't know - only testing will tell you. It's good to try and do things as efficiently as possible anyway though, within reason...

Each room would be its own level, you build and save them to an array and then load them when the player hits certain trigger points. There are examples in forums if you search for "array based level editor".
Can be complicated if you havent done it before.

Good point Muddymole. Yeah, just loading in new chunks without ever un-loading old ones, would just eventually cause major slow down and fill up your RAM. But to be able properly mange that and unload areas, you'd need some sort of direct access to the memory. And to my knowledge, Fusion handles the memory allocation all on its own behind the scenes, so you don't have to deal with that stuff. In most cases, this is great because it allows rapid prototyping and less "micro-managing" from us. But for large data sets like that, yeah it can be an issue.

One neat trick that I've found: you can sort of create your own "RAM" management, by using a finite number of objects with an ID alt value, and re-order them based on context. This way you always have the same number of objects loaded into memory at all times (no lag, because Fusion isn't constantly creating and destroying new objects, thus having to constantly add/remove things from RAM).

An example of this would be: let's say that your character kicks up a little dust cloud particle every time they walk. And after about 1 second, the dust cloud particle fades away and would normally be destroyed. So using normal create/destroy method, you'd be creating (and destroying) a new object every 1 second. And let's say that this dust particle is only kicked up 4 times every second (according to your character's walk animation). This means that at most, there will only ever be 4 particles in existence at once.

Since you know exactly how many particles there will ever be, instead of doing the create/destroy object method -- you can just "cycle" through 4 pre-made particles that are always in the frame. When a dust particle reaches the end of it's lifespan, you simply make it "invisible" and maybe store it off screen. If you give each particle object a unique ID (ranging from 0-3) you can just use a Global Value to +1 the "particle index" so you know which is the next particle to "create" (reappear). When loop your Particle Index Global Value back to 0 when it reaches the "end" you simply apply MOD math = "ParticleIndex = (ParticleIndex + 1) mod 4"

If you use this method, you also completely avoid any potential bugs where (for example) you accidentally have a particle effect that continually creates 10,000 objects until your game crashes!
The downside to this method is that there will be a hard-limit to the number of particles on screen - but this limit can be whatever you want it to be, and you simply have to make a good estimate on how many particles you need.

For example, if you have a character that kicks up 4 dust particles per second, with a lifespan of 1 second, you'll only ever need a max of 4 particles objects. If you have 2 characters on screen, you'd need a max of 8 particles. If you want to create a sort of safe "buffer zone" for extra particles, you can just increase the limit a little further than you'd need, (+5) or even just double the limit (16).

---

So a more relevant example of this would be for a level screen. Let's say you know that there could only ever be a possible 100 tiles on screen at once in your game. You could use 100 Actives, and simply reposition them when the screen scrolls, and reload a new "tile" animation. Since there physically can not be more than 100 tiles on screen, you don't need to "create" new chunks. And again, if you wanted some buffer room there, you could increase your limit to 200 so that your game is loading the tiles on screen, and a little ahead and behind you.

To the best of my knowledge, this is how most old SNES-era games worked. They'd use a sort of "array" to manage all the objects and tiles on screen. So when you killed an enemy, or they went off screen, their slot in the array would be "freed up" to load a new enemy. This is how they worked within the memory and sprite limits of the hardware at the time. But using those same techniques on today's hardware also help make our code much more efficient to run.

Quote from JimJam

So a more relevant example of this would be for a level screen. Let's say you know that there could only ever be a possible 100 tiles on screen at once in your game. You could use 100 Actives, and simply reposition them when the screen scrolls, and reload a new "tile" animation. Since there physically can not be more than 100 tiles on screen, you don't need to "create" new chunks. And again, if you wanted some buffer room there, you could increase your limit to 200 so that your game is loading the tiles on screen, and a little ahead and behind you.

One of the examples in my "tile-based examples" pack (the frame called "virtual scrolling") does exactly that:
Please login to see this link.
(although, just looking at it now, I can see it could be optimized a LOT)

To be honest, I think it's probably a step too far unless you're forced into it (as developers for old consoles were). It's complicated, it makes everything else more complicated, and I doubt it's even faster in CF2.5. Like you say though, for particle effects, where you're constantly creating and destroying instances, it would make a lot more sense.

MuddyMole - Awesome work, I've had your Onedrive link bookmarked for a while now from some other thread. There's a lot of great stuff in there to sift through.

And yeah, I agree that for tiles it's probably too much to manually handle them in this way. I just brought this up because it's more relevant to the this topic at hand (Castlevania Map). I'm sure Fusion itself (or the tilemap extension) handle this sort of task much more efficiently than making up an array system in Fusion . But for particle systems, it can definitely be useful to have limitations in place.

That said, the Tilemap extension would be best bet to handle the actual static tiles. But this doesn't touch on the issue of actual Active Objects (the enemies, items, etc in your level). You'll still need to figure out some way of handling how these things should behave when off screen. Should you load them all at once and keep them in memory? Should you create some system to dynamically load them? Should you just let Fusion handle it all by default?

It really depends on what the objects are doing, and how you want them to behave.

I've had some issues before with letting Fusion just handle everything. For example, for items or powerups that have little to no behavior (just a static Active that the player collides with), just letting Fusion deactivate them tends to work fine. But I've had issues with enemies falling through the floor when off screen, or enemies pausing (getting deactivated) in weird spots when outside the screen. So I think how to handle these objects need to be evaluated case-by-case.

seep - Definitely check out the Tilemap object in the Extension Manager. For the actual background tiles, it's incredibly efficient and dynamic.

Personally I would use 2 arrays for a map like that. One array for the general world map & another for the actual tileset placement. Maybe there's a better extension for the tiles, but the default array is cross-platform & would definitely save you a problem in the long run if you plan to release across multiple formats.

I am working on a metroidvania engine right now:

---

(NSFW)

Please login to see this link.

---

My logic is, I have and editor engine that runs together with the ingame engine (This saves a lot of time).

Whenever I save values to the array, for objects and tilesets, they will be saved for the specific array of that room. I have one different array for each room, with different name depending on the room code.

This may seen a bit much, but I think it's dangerous to place everything on a single array for the whole game.

I then load rooms according to specific neutral room passages (pretty much like SOTN).

All this running in a single frame

Why do you think it's dangerous to place everything on a single array for the whole game? Care to elaborate?

Thanks,
Marv

A huge game like SOTN would have tons of rooms and, even though you can spread values to "X,Y,Z" I fell you run the risk of the array size becoming way too big to proper load what do you want.

Also, in the case you are still developing the game, you run the risk of messing things up and mess up the whole single array you are using to load your game. Maybe a good solution for this would be to implement a custom backup array system.

I am more comfortable working with multiple arrays, I can open a single one and check it if I want, and I need to worry less about arrays with huge dimensions.

Quote from PandaExplosion

A huge game like SOTN would have tons of rooms and, even though you can spread values to "X,Y,Z" I fell you run the risk of the array size becoming way too big to proper load what do you want.

Also, in the case you are still developing the game, you run the risk of messing things up and mess up the whole single array you are using to load your game. Maybe a good solution for this would be to implement a custom backup array system.

I am more comfortable working with multiple arrays, I can open a single one and check it if I want, and I need to worry less about arrays with huge dimensions.

Makes sense to me. It's hard to argue that logic.

Thanks,
Marv

Don't forget that for games like SOTN, everything is not on one big map but rather divided into several parts. The cave zone will be on one array, the entrance on another, etc...
For my Metroidvania Games, I prefer to use a single frame for the all game, but divided for each room. I also created a Tool for Minimap, where I sync value with the name of the map :

Please login to see this attachment.
Probably not the best way, but it's worked pretty well.

On the same subject do you guys have a clever solution for "exact minimap exploration"? For instance, currently my map will render both a 256x256 and 1024x1024 sized areas as 8x8 tiles on the map even though the latter should take up more space on the map and not be fully explored the moment player enters the room. It is a bit misleading to the player.

I have a couple of approaches I haven't tried out but it feels like I am re-inventing the wheel here...

Yes I am! Very happy that you enjoy the game, thank you.
Hope you'll be able to make a greater Metroidvania on your side, I'll keep an eye on this!

Quote from chrilley

On the same subject do you guys have a clever solution for "exact minimap exploration"? For instance, currently my map will render both a 256x256 and 1024x1024 sized areas as 8x8 tiles on the map even though the latter should take up more space on the map and not be fully explored the moment player enters the room.

What's the specific issue? It sounds like you just need to represent the 1024x1024 area using a 4x4 tile area of the mini-map?
To find the player's "world" position, you just need to know their room (frame) position, and the position of the top-left corner of the room within the world. The last of those could either be stored in the map array for each room, or calculated by comparing the frame position at which the player entered the current room, and the frame position at which they exited the previous room.

+ player moves from one room to another
-> topleft.y = lopleft.y + exit.y - enter.y
-> topleft.x = lopleft.x + exit.x - enter.x

+ always
-> player.world.x = player.x + topleft.x
-> player.world.y = player.y + topleft.y

...and then obviously you can just divide the world coordinates by 256 to get the mini-map coordinates.