Single Frame game using active objects as the backdrops - issues in the long term?

Well, you definitely don't want to try and make it using 962 separate frames. Any time you found a bug or made a mistake you'd need to update all 962, which would be horrible. Though there would be some ways to mitigate this issue. For example, like putting most game objects in a single frame that is the included frame of all the 962 level frames - that way you can change/add objects in just the included frame only and it'll automatically update the other 962.

But if the single-frame way you've done it for 4-5 levels is working well, then it will probably work well for 962 levels too, as long as you're disciplined with your organisation.

The main issue I can imagine cropping up is you running out of RAM, depending on how rich your assets are. A single playthrough that went through all 962 levels would end up loading an awful lot of stuff into RAM, and if the levels are large and/or the enemies/platforms have graphics with large animations, then you may blow your RAM budget. In that case, you may need to build in some sort of mechanism that occasionally (eg. after every 20 levels) jumps to frame out of your main frame then jumps back in, just to force Fusion to purge all the stuff in its RAM from previous levels.

But it all depends on how bit your assets are. The way to calculate how much RAM something will take is: pixel dimensions x 4 channels (RGB+alpha) x no. of frames.

So, if your levels are all 640x480, then the RAM cost of your blockout collisions object would be 640*480*4*962 = 1,182,105,600 bytes, or about 1.18 GB

If your levels are 300x200, then it would be 300*200*4*962 = 230,880,000 bytes, or about 0.23 GB

If your levels were the full 5000x5000, then it would be 5000*5000*4*962 =96,200,000,000 bytes, or about 96 GB (!)

As you can see in the examples above, the dimensions of your assets (including your hero/enemy/npc/platform/background animations etc.) makes a big difference. It's up to you to figure out whether the animations you'll throw at Fusion will break your RAM budget or not.

The problem with arrays is that they're not easily human-readable: the contents sit inside an invisible grid that the computer can see but you can't. It's kind of like cooking a meal with a cupboard full of unlabelled spices, where you can't achieve anything unless you've previously memorised which jars contains which spices. It also doesn't help that the code for using arrays is somewhat ugly and syntax-heavy by Fusion standards. So don't feel bad that you can't wrap your head around arrays - that's normal. The way they're designed means they require an annoying level of cognitive load. And the whole point of a Fusion style of programming is that it keeps the cognitive load low, so that your mind can focus as much as possible on the creative and intelligent side of programming (eg. working out the logic) instead of being preoccupied with the dumb busywork side of it (memorising precise syntax or unlabelled array values)

But arrays can be useful. Not necessarily for this project, but possibly for some future project of yours. If so, then I recommend mirroring your array with an Excel spreadsheet. Arrays are basically the same as a spreadsheet - a grid where you can store info in the cells of rows and columns. So if you make a spreadsheet where you clearly label the rows and columns, it will help you figure out how best to set up the array at the start, and will help you keep track of it down the line.

Oh I know that your levels won' t be 5000x5000 because you mentioned it was all happening on the top left. I just used the full 5000x5000 dimensions as a more extreme example of how important dimensions are to RAM. To show that even though something like 5000x5000 isn't that much bigger an area than something like 640x480, it would end up consuming almost 100 times more RAM.

Quote from Warmachine

Plus the good thing is, i can leave things that will be used actually in frame, away from where any scrolling will be going on as well, so no worries of things getting crazy in terms of losing track of where I am

Unless you are 100% certain that there are certain areas of your 5000x5000 frame that will never be used (and it sounds like you aren't), it might be a good idea to keep things off the frame area to make sure they won't ever get in the way. There's nothing stopping you safely placing everything to the top and left of the frame, which is what I do. Just make sure "destroy object if too far from frame" is unchecked as needed. You can also see in the below screenshot that most of my game objects are little squares. Wherever possible, I make the first frame of my active a 50x50 'icon' that won't actually be seen in-game. This makes things much easier to organise in the frame editor and - importantly - the square shape makes them much easier to read in the Event Editors.

Please login to see this picture.