When does an array risk being too large?

I haven't run into any issues with this yet, but I am concerned I might in the future and want to address this earlier in my project rather than waiting until it becomes a problem.

So, I'm using a seed generator to procedurally generate dungeon rooms. These rooms are connected to one another, but are separate layouts. This mostly works right out of the box, but there is of course the issue of tracking changes made to the seeded rooms, specifically Enemy Health, position, and state.

I've addressed this with a 3D array that records those values for each enemy whenever you leave a room, and then loads them when you enter it. It works great!

But the array is by far the largest I have ever worked with, clocking in at 24,000 cells. Most of these cells are empty (there is an X column for every potential room in a dungeon, with a potential maximum of 96 rooms in a dungeon) and these cells mostly just store integers, though a handful do store small strings.

Do I run the risk of this being too large? If this is too vague, what would be a good rule of thumb regarding array size?

I don't know about array size limits, but is it really necessary to have rooms in the array since most of the cells would be empty? Why not having an enemy array, which would be 2D, with X for enemies and Y for attributes, and checking only the enemies which are in the loaded room?

For instance, the array would look like this:

enemyArray = 
--[
----[roomId, enemyX, enemyY, enemyLife, enemyState],
----[roomId, enemyX, enemyY, enemyLife, enemyState],
----[roomId, enemyX, enemyY, enemyLife, enemyState],
----[roomId, enemyX, enemyY, enemyLife, enemyState]
--]

I have used much bigger arrays without any problem.

I read somewhere that javascript uses an average of 9.7 bytes per cell, so a 24,000 cell array would use less than 240K of memory. You could quadruple the size and still be under a megabyte.

graphics take up way more space!

brunopalermo's suggestion is good, and would be slightly quicker to search through, but I doubt you would actually see any difference.

brunopalermo That's a much more efficient idea, for some reason I had it in my head that because it's possible that a dungeon uses all 96 rooms, I should build it for that, but the changes of a dungeon actually building out all of those, and that a player explores all of those rooms, and that all of those rooms contain the maximum number of enemies is fairly slim.

That said, I usually just look up array values based on an XYZ locations related to other values, I haven't looked up an array value based on an ID stored inside a cell, I'll hafta look into how I should do that.

AllanR Thank you! That is great to know, in that case I won't implement Bruno's solution since mine already works and based on your information, doesn't have a large enough impact to actually hinder my games performance.

I haven't run into any issues with this yet, but I am concerned I might in the future and want to address this earlier in my project rather than waiting until it becomes a problem.

So, I'm using a seed generator to procedurally generate dungeon rooms. These rooms are connected to one another, but are separate layouts. This mostly works right out of the box, but there is of course the issue of tracking changes made to the seeded rooms, specifically Enemy Health, position, and state.

I've addressed this with a 3D array that records those values for each enemy whenever you leave a room, and then loads them when you enter it. It works great!

But the array is by far the largest I have ever worked with, clocking in at 24,000 cells. Most of these cells are empty (there is an X column for every potential room in a dungeon, with a potential maximum of 96 rooms in a dungeon) and these cells mostly just store integers, though a handful do store small strings.

Do I run the risk of this being too large? If this is too vague, what would be a good rule of thumb regarding array size?

FYI> an Array with 24,000 cells does have an effect on the Game performance.

Yeah I only read from the array once per relevant object at the beginning of the layout, and then write to it only once per relevant object at the end of a layout, or when an object is killed, so I don't foresee any of that being an issue. Thanks for the additional information!