Feature: Multi-Layout Editor

Discussion and feedback on Construct 2

Post » Sat Nov 15, 2014 8:27 pm

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).
Scirra Founder
B
400
S
237
G
89
Posts: 24,549
Reputation: 195,525

Post » Sat Nov 15, 2014 9:44 pm

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!
B
79
S
13
G
8
Posts: 1,977
Reputation: 9,947

Post » Sat Nov 15, 2014 9:52 pm

@QuaziGNRL
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.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Sat Nov 15, 2014 9:53 pm

@Ashley I think @Tokinsom said

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;

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 :D

Also thanks for being active with the community!
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Sat Nov 15, 2014 10:27 pm

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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Sat Nov 15, 2014 10:46 pm

@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.
B
79
S
13
G
8
Posts: 1,977
Reputation: 9,947

Post » Sat Nov 15, 2014 11:31 pm

@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.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Sat Nov 15, 2014 11:46 pm

I'm not trying to prove it to you, but if i have time ill make you a simple example.
B
79
S
13
G
8
Posts: 1,977
Reputation: 9,947

Post » Sun Nov 16, 2014 9:07 am

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.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Sun Nov 16, 2014 2:53 pm

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.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 11 guests