Using arrays for level building over regular global object spawning

Arrays are best for loading levels because they can easily be mapped to a grid system if it's tile based. Even if it wasn't tile based, you could use the array like a glorified list object saving data of every object in a level including positions, alterable values, flags, etc. All you would need to load your level is to use a few fastloops to go through the array to read the data and load all the objects.

The background objects don't have to be actives. You can use the "add backdrop" action to place an active as a backdrop, then destroy the active.

The main use of arrays is also to save and load the levels externally as arr files. So you can quickly build levels using a level editor and instantly import them into your game.

As a level editor example file, having the first frame the editor and the second frame the testing frame, global objects could work. But in your actual game that's not how it's going to work. You won't have the editor in your game. You'll just have one frame that loads data from your levels externally using arrays. So there's no point in using global objects in your actual game.

The whole point of using arrays for loading is that you read the data externally so you can cycle between levels easily. If you're already going to build the levels in Fusion regardless then there's no need to have a separate level editor frame and a game frame if you're not going to save the levels externally. The only difference for you being that you wouldn't have to copy the code between levels, since the main engine code would be in one frame? But you would still need to have separate frames per level if you make multiple levels.

So the main difference between an array method and your global object method is the number of frames in your game. An array method only uses one frame and will load the levels reading data from external array files. Your global object method would be copying objects from other frames into your game engine frame. However it wouldn't be a single frame so it's more complicated. Also having multiple levels using the same global objects could get messy, especially with instances of objects. It just seems like more of a hassle that way when you go past one level.

Arr files aren't easily editable like text or ini files. From what I've tested they only really work in Fusion apps that use the array object. So for added security you could encrypt files with the Blowfish object to make sure no one can easily edit them further.

The array method has only one copy of every object in your game frame which keeps resources down to a minimum and will only create an object when needed.

If you created a layer for each level, it will add all of the objects for each level together within one frame so you will eventually hit the object limit of 20,000. It would also be a waste of resources. I don't think you can edit the "create at start" property within the event editor so all objects would have to be created at start which messes with your global objects being ported to the next frame. There's not much control.

A major thing to consider is that you lose the functionality of copies or instances of actives. While in a normal level it would be easy to quickly copy ground objects in a row as instances so they reference the same active object, you can't do that if you want their alterable values to be unique if they record their positions. So that means your object count will quickly get out of hand if every wall and floor object has to be a unique cloned object.

You can run some tests yourself having multiple global objects on different layers on the same frame. Try adding instances and clones to see if there's a difference. To me though it seems like a roundabout method for loading levels when arrays can already streamline the process with a single fastloop for loading if you use the mod function.

I think the example you are referring to is using a simpler setup so a new user isn’t overwhelmed by more complex approaches. It is a pretty proven method to load levels from arrays. You are only making more work for yourself if you avoid them. Of course, this is only in the context of games that use tiled levels.

TBF though, the example you've posted here:
Please login to see this link.

Is incredibly simplistic. You're not actually loading the level from anything, you're just manually setting the positions of the keys and doors through code.
While you say "The level data is stored in an active object" it's not, most of it is manually setup in your "Load Level" code group.
This is fine for something as simple as this, but what about if you wanted 3 types of enemy, collectables, different obstacles etc?
If you're manually going to place all those with code, it's going to get very hard to visualise what's going on, and very hard to bug fix and so on.

I'll be straight up, over the years I've often tried to find quick workarounds to avoid having to make a level editor/level loading system, but the simple fact of the matter is, you'll spend ages trying to build workarounds, when what you should just do is build an editor that saves and loads data from CSVs, Arrays, inis etc etc.

Your each-level-on-a-different-layer-in-a-single-frame method is going to rapidly get messy (what if you need more than one layer to have foreground/background), and is going to be super inefficient as your game grows.

The alternative to writing a custom level editor, it to use Fusion's frame editor as your level editor. I'm explaining this method in the second part of the ChocoBreak HD tutorial. It can be found in Fusion's Help or online here: Please login to see this link.

[MENTION=5136]Olivier[/MENTION]

Thats a really nice method for making a level editor in the frame.
Might actually give that method a go on the next project.
That said, with regards to the original topic of this post, you're still basically using a Save/Load method, it's just saving from the Frame.

Correct me if I am wrong, but having unique frames inside the same mfa as the "engine" frame where you load your game data is going to cause serious file bloat. It is probably always a better idea to keep these frames with your level building in a different mfa (or delete them before building). Unless Fusion has a way to exclude frames at compile time?

[MENTION=12441]butterfingers[/MENTION] yes you are correct, the level data is still saved to/loaded from a file.
[MENTION=7170]mobichan[/MENTION] you can tell Fusion to exclude frames with the frame property "Don't include at build time".

[MENTION=8318]N64Mario[/MENTION] There are a couple options for this. For one, you can create the object a X=0,Y=0 and then set the X and Y coordinates to the ones stored in the level file. This all happens on the same frame so it's invisible to the player. Alternately, you can use the "Create Object by Name" extension, which not only lets you set the coordinates of the created object based on an expression, but also create a specific object by typing out its name instead of using the object selector. I know, I was shocked when I found out about it too, and it changed my whole world.

The Lag in the example (and the player falling) is because the game runs the level loading code and the player code from the start of the frame.
This could be simply fixed by putting the code into 2 groups.
1 for Loading
1 for Gameplay.
You then default the Gameplay Group to be OFF at the start of the frame and only activate it when the level is loaded.

Quote

I was looking at these examples. They use array, but I can not understand any of it.

The top link of the 2 you've posted there doesn't use an array at all, it just saves all the object positions to an ini file and then loads them back again.
It's literally making a file with a really big list of all the items in the level, then it uses a fast loop to read through that list and load all the items on it back into the game scene.

I'm not trying to be patronising, but I'd strongly suggest that you read up on fast loops, ini files and arrays a bit. The 2 examples you've posted there (especially the top one) are incredibly simple ways of building a game in the frame editor, if you have a basic grasp of fast loops and save/load from ini, you'll see how straight forward they are - and that they would be exactly what you need to make a MegaMan style game.

The following are pretty helpful for FastLoops:
Please login to see this link.
Please login to see this link.

And this is perfect for Ini:
Please login to see this link.