Feature: Multi-Layout Editor

Ashley

Forget about a multiple layout editor for a second. What if you built a "Room" object into the engine? Imagine it acts exactly like a layout except in the way that it's not a actual layout but a space inside the layout. Sort of like a mini-layout, perhaps the engine could think of it as a sprite or tilemap. That way it could function nearly exactly like a layout except that it's not a layout on it's own.

It could have the follow attributes that are layout-like: Camera is bound inside them and cannot scroll out of them like a layout, they reset like a layout when the player "exits" / stops overlapping them.

That way we could have transitions like Tokinsoms Metroidvania simply by doing a "Set Time Scale to 0" and "Scrollx" event with a single detector instead of all the stuff we have to now with clamps, lerp, time scale, bullet behaviour, detector sprites and whatever else.

Tokinsom

What do you think about my idea above?

That might be even better because you have more control over the shapes, sizes, and connections of the various rooms. By giving numerous "room objects" the same ID, they could act as one, giving you something like this:

(In this example the mouse would be the player. Highlighted rooms are loaded, non-highlighted are unloaded, black space is the actual layout.

You could still handle room transitions and camera stuff however you wanted, as this would merely load and unload parts of the layout based on their distance from the player.

Hell, this would be great even for large-level games like Megaman, Megaman X, Donkey Kong Country, Mario 3, Super Mario World, etc.

Video game levels are more than just big boxes with a bunch of stuff thrown in them. We need something a little more sophisticated here.

It's easy from the outside to see it as "just allow editing the joins of layouts". But the layout view has thousands of lines of code that assume there is only a single layout being edited, and the UI is difficult to change as well. I don't think this is feasible, it will have to wait.

The latest suggestions would only use one layout. All we're asking for now is the ability to load & unload certain parts of a layout during runtime based on a single new object type. Is that really so difficult?

Edit: Could a 3rd party plugin be capable of doing that? Wouldn't it just parse layout data and create/destroy parts of it based on x/y coordinates?

[quote:22io1spb]That might be even better because you have more control over the shapes, sizes, and connections of the various rooms. By giving numerous "room objects" the same ID, they could act as one, giving you something like this

Tokinsom

Glad to be of use.

Ashley

Basically they would be room objects (like sprite objects, they're imported into the layout) within the one layout that reset objects overlapping them (so they act like how a layout resets) and set their local time scale to 0 when the player stops overlapping them / exits (so objects inside the room stop working to save memory etc). Thus emulating the usability of layouts while containing them inside one layout so they're usable with the current generation of Construct (2).

Would that be better/easier to make for current gen Construct rather than layout editor?

Oh, so you'd design a single very large layout, then manage the memory to load sections of it in chunks? That definitely sounds a lot more feasible. But Tokinsom said there was a "laundry list of reasons you shouldn't do that", so I'm curious exactly how far it would go to solving this. I think this would only solve image memory issues (assuming you're not using the same set of textures through the whole level...?) I would prefer to make it possible to design very large gameplay areas in a single layout, but I need to know more about precisely what kinds of issue come up with that and then think about ideas to solve that (ideally in a general way so as many types of project as possible benefit).

It'd be possible as a plugin, but i really think the best way to do it is to make one big layout, and join things edge to edge with boxes on a upper layer defining the rooms for things like camera behavior and activating/deactivating objects in outer rooms.

The truth is that the more complex you want a system the more you'll want control over little optimizations, and little things. Construct makes it far easier to control highly abstract systems through events, and making something like this yourself is the only way you'll get it to be a way you want.

I have issues with you're idea because it neglects to propose any real explanation of how this would work. Do objects in other layouts simply shut off? are those layouts rendered? are the events for those layouts processed/loaded? are the objects preloaded? how are doors defined and the behavior of passing through doors? how does the scrolling work between layouts or at layout edges ? what objects can pass between layouts, how do they pass between layouts? It's gonna be complicated no matter what, and either you have to learn how to manage a complex system, or make a complex system you know how to manage. a room based camera controller is not really an overly complex thing to make, and if you're making a game you'll have to expect to create these kinds of systems.

The prospect of a next generation editor SDK makes me excited tho, i'd love to be able to control the editor like the runtime in a browser, the possibilities!

—

I assume objects that could translate between layouts would be global and they would switch from 1 to 2 at the edge sort of like how it's currently done. Scrolling would work as normal in a single layout. Layouts "shutting off" and getting rendered would be the same as they are now, when not in use they're not being used (I think that's how it currently works).

I'm not sure if you talking about the "Room" object or the multi-layer editor since you're first talking about multiple layouts but then at the end switch to rooms.

I'm sure Tokinsom can explain it in greater depth, I'm not much of a programmer.

Ashley I think Tokinsom said

[quote:1src9ob0]He suggested open-world / metroidvania style areas are created in a single layout. That's what I did for Minitroid, and I have a laundry list of reasons you shouldn't do that.

However, after I spoke forth my idea about the "Room object" this was his response;

[quote:1src9ob0]That might be even better because you have more control over the shapes, sizes, and connections of the various rooms. By giving numerous "room objects" the same ID, they could act as one, giving you something like this:

I think the first time he was saying it was a bad idea because of perhaps performance issues, extreme difficulty programming it to work, maybe it took a extraordinary amount of eventing (setting up events) and/or it hogs the system which caused him to lack features (although this all comes down under performance issues I guess). I'm not entirely certain of all the reasons he said this so it's best if Tokinsom himself explained this.

But then after I suggested the "Room object" idea, the second quote is presented. So I think I can safely assume that it solved at least a large amount of the problems, but again Tokinsom himself will be able to explain it better.

I'm very happy that we're able to talk about this and that we're got a solid idea that is possible to implement into the current generation engine. If you were to give it a try implementing it, would you release the prototype as a regular beta version or keep it private it a little while while you sorted out the kinks? In case of the latter I'm sure me and Tokinsom can help bug test it

Also thanks for being active with the community!

Hum... I wonder how the classic NES metroid handled that situation, I think a similar way would be having a big layout for a part of the maze (by part I mean like , you know, brinstar or kraid's domain), careful scrolling for each room, loading the ennemies only when needed (That part really should not be automatically handled by C2, but manually done the way you want, that is something that you are able to implement with what C2 gives you normally), storing the state of the bonuses could be done with variables, and persistent objects would make bosses or bonuses not reappear (that or handling manually the situation).

The elevators would make the layout to layout transitions (each areas in the classic metroid is accessed via an elevator).

This of course is an exemple and just thinking, but really I see nothing wrong with that way until there is potentially a real way.

Also I tried in the past to save objects of a layouts (their json) , then restore them at an offset to have this (room for each layout thinking), without success. Not sure it was a good idea, but that would have helped with reusing the same rooms.

Edit: server was down, did not see the posts before me.

Nesteris

The issue however, is some people may want scrolling which shows both rooms, sort of like zelda / super metroid, and the logic to place characters in other rooms or pass through doors may work for you, but some people may want transitions etc. It becomes a big headache to have all the features everyone wants, and fundamentally this isn't a complex thing to implement in events, ive done it many times. There's no extreme difficulty, but like anything you can't expect to get something working if you're not willing to invest a little time. With one simple object to control what separates rooms you can make a fairly straight forward system, you just need to build a game with that in mind from the beginning.

QuaziGNRLnose

The room to room transition would act just like normal camera scroll transitions in a single layout, thus simplifying things and allowing a Super Metroid like transition to be made by just adjusting the camera speed and adding a black fade layer, yet the previous room object (part of a single layout) would reset and freeze as if it were another layout.

As for the little time, I've spent around 6 months with no advancement, Tokinsom spent around the same and even more but he got it to work. Now I don't know about you but I don't see any proof, not to accuse you that you're lying but it is easy to just say something.

I'm not trying to prove it to you, but if i have time ill make you a simple example.

Personally I would like additive and removable layouts. While being able to choose where the layout is attached based on the top/left corner.

I would like the option to have the layout load int he background and add when ready. When I remove a layout then the assets of that layout is removed providing another layout is not using them.

I would ultimatly like to make an expansive GTA2 like world with a large distinct sets of graphics for area. However the big issue I had were

A. Memory overload for all the different regions(Downtown, suburbs, forest, ghetto, industrial, water, park, subway....). there is just no way to handle this especially when you then also need to add sounds that are also specific to regions. forest sounds are not needed in the subway... etc. one big layout make this not really feasible.

B. I found that the scrolling in the editor seems wierd at the very large size such as 100,000 x 100,000.

Also the stitching with layout additive and removing can work with say layering. Here is an example.

Player is in car.. vroom.

Player get's out of car.

Player walks into build.... lobby is loaded. while in lobby load rest of floor, basement, floor 1. on floor 1, unload city, region A, load floor 2.

player walks out of build. unload floor 1, and basement.

player drives to subway

player drives into subway

player is in a tunnel undergound. and can traverse the city.

by using additive and removable layouts we can get streaming load/unloading of city components. I have no idea how this would impact the current engine or the requirements. however as seen by the sample 1 layout would not work for urban environments that want to allow a truly seemless world.

There seems to be a bit of confusion here...

Ashley Nesteris was correct in his above post - I meant there's a laundry list of reasons to not make an entire metroidvania world in a single layout with the existing features.

Such as...

-Objects won't reset their positions or states when exiting and re-entering a room or area

-Objects can bleed into other rooms/areas, especially parallaxing backgrounds (bigger deal than you'd think because they can be destroyed or trigger other things)

-A significant amount of events has to go into activating/deactivating objects & timers based on proximity to player/camera or current room, or using spawners instead.

-Bad performance in-game & in-editor, and possibly slow loading times due to gargantuan layout files

-Can't really collaborate on it

...I haven't attempted a single-layout open-world game in a long time so I'm sure I've forgotten a few issues I ran in to.

----------

Anyhow, yes - We originally wanted to link multiple layouts together to solve these issues, but then realized there's a better way to go about it, which was to use one layout and add some feature/object to load/unload parts of it at a time. This way you can, again, make whatever type of open-world you want (seamless, screen-by-screen, room-by-room, etc.) and everyone is happy.

Of course there will be a few kinks to work out but I mean...either you fix a few bugs with this in C2 and no one ever deals with them again, or countless people attempting open-world games run into countless problems and try to fix them on their own every time...and likely fall flat on their faces because it's not easy.