Feature: Multi-Layout Editor

[quote:xm9gwe48]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.

One problem I can think of that the Room object would fix theoretically would be this;

[quote:xm9gwe48]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.

Because room objects would effectively turn off all other parts of the layout, memory overload and performance issues on extreme layouts would be a thing of a the past. But that's an educated-guess at best.

I think that at best, it works as it's supposed to provided its well thought out and implemented, at worst it has the countless problems you mentioned and have more work to do.

Technically those other areas wouldn't even exist until you're in or near them, so it's not an issue. You can still use multiple layouts, anyway.

For example, a Zelda overworld could be one layout with many room objects...but a dungeon or castle is another layout with its own room objects.

As for memory/filesize, the editor I linked to earlier broke it up into chunks. Notice each cel has "Mines_14, Mines_15, Mines_16, etc." over it...each one is a separate file. Not sure if Ashley wants to do something like that though, especially since the cels/rooms in this case would be whatever shape or size the user wants.

Also other pros are that developers could see a vast majority of their playable game in fewer or even one layout, I can also imagine there being less loading screens to visit since it would be possible to put the game on one layout.

I can see how this would be useful but can certainly live without it. I'm sure there are higher priorities on the list.

You can say the same thing about Construct 2 itself and a lot of other things, no point in saying it though.

Well, I hear what you say Nesteris, but I guess my contribution to the discussion is as valid as any. If we all kept quiet Ashley would have little idea what features are important to those of us who are using Construct 2 and discussing potential developments in this forum. I'm just getting used to the software and am noting my own list of features that I could really do with and this one would be way down my list.

Ok so start a topic requesting them. There is no point in downplaying ours just because you don't find them particularly useful. (Gee a new feature or two to make entire genres more feasible in C2, who needs that?)

I mean, I don't care one bit about any mobile/browser/marketplace stuff that makes up at least half of C2's updates but I'm not complaining. Loads of people will greatly appreciate that stuff and I might use them somewhere down the road, so whatever.

Thanks for the suggestion Tokimson. I'll do that soon.

The magic of arrays and strings may solve some issues.

An array can hold strings of "room" information. Object id's locations, size scale rotation, you name it. Anything an object can do can be stored as a string and interpreted with comparing those string values.

Rooms can be loaded and unloaded as needed.

Player.X>500 && Player.X < 1000

Load room[2]

parse that string data as needed and viola. You can create those objects. Do with them as needed. destroy them. have at you.

Easy? No. I doubt it. Possible? Sounds like it, I cant see why it wouldnt work.

I prefer that type of system with array based room data over what is being proposed.

I feel too much control is lost if we define rooms and let construct do magic. How can I determine logic happening in this non-loaded room? What if I want that room loaded without being inside it?

What happens when the player is in room 7, pushes a button and you need to make a change in room 2. But room 7 and room 2 have no reason to be both loaded?

These are things only array based/ string based level design/rooms can overcome.

-----------

The issue seems to be a visual and code/data disconnect. People want an easy visual, yet high level of control. At least not from what I have read and see. What is proposed does not make this possible.

An easy visual solution just cant give the control needed for the instances where the proposed tool would even be useful. Not in a basic sense of keep these rooms loaded. Don't load these rooms. All of it is one layout, etc etc. It seems to miss the whole point of wanting rooms, and I cant see it being useful from what I have read so far.

----------

If this "room" object instead stored all room information in a way that we can access it anytime, and visually place the objects into it, maybe this would work. Nothing would need loaded, but we would have easier access to the "room" and object data than if we use arrays/strings ourselves.

Essentially turning the "room" object into a visual array.

And any object in the room, gets placed into that "room" objects events. An object would act like a behavior to that room.

This is just the ramblings of some1 up too late.

And the proper people to be notified: Tokinsom Ashley Nesteris

Tylermon

First of all, this would not replace anything. It would be an addition. You'd obviously still be free to build rooms using Arrays, nobody is going to stop you.

[quote:16luby6v]I feel too much control is lost if we define rooms and let construct do magic. How can I determine logic happening in this non-loaded room? What if I want that room loaded without being inside it?

No control is being lost, Room Object would NOT replace Array or anything else. It would simply make things easier.

We have player platform behaviour in Construct 2 yet it's amazingly simple to remake and highly customize, but it's still there.

[quote:16luby6v]What happens when the player is in room 7, pushes a button and you need to make a change in room 2. But room 7 and room 2 have no reason to be both loaded?

What happens is what you want to happen. Theoretically that part of the layout is reset and frozen in place using a time scale, so if you used a global variable or object you could change what you wanted. It's still part of one layout and the same engine. Construct 2 isn't going to be turned into something from The Hills Have Eyes.

[quote:16luby6v]If this "room" object instead stored all room information in a way that we can access it anytime, and visually place the objects into it, maybe this would work. Nothing would need loaded, but we would have easier access to the "room" and object data than if we use arrays/strings ourselves.

Essentially turning the "room" object into a visual array.

You can access it any time, you just described how we described it would work.

Simply the Room Object is a re-sizeable box or rectangle that has a local time scale inside the layout and has the ability to reset the part of the layout it overlaps along with the objects inside of it (unless they're say, global).

This way you're able to emulate the function of separate layouts without needing to load said layouts, so essentially the entire game could potentially be loaded into one layout yet not use the parts that aren't needed in order to save on memory and attain better performance.

E.g

You have a layout that has 4 room objects.

Player starts in room 1, kills enemies in said room and moves into room 2. Upon exiting room 1 and entering room 2, room 1 resets and sets it's local time scale to zero making the enemies respawn in place and keep still until the player re-enters it at which point the time scale is set back to 1 and it plays as if it was another layout that had reset.

[quote:16luby6v]What happens when the player is in room 7, pushes a button and you need to make a change in room 2. But room 7 and room 2 have no reason to be both loaded?

Player goes to Room 4 and finds a locked electronic gate, goes back to Room 3 to press the unlock electronic gate button.

Events could be set up like usual e.g.

Player Overlaps Gate Button | Set Gate Button Animation to Pressed

Gate Button Animation "Pressed" Is Playing | Set Electronic Gate To Animation "Unlocked"

So it's really that simple, at least potentially. You could set it up way more complicated or badly evented, use global things. It's only as hard as you make it out to be.

I hope this cleared up some things for you.

People to be re-notified: Tokinsom , Ashley

Tylermon Not the most common scenario if you ask me, but to solve it I would set a dictionary key or something in room 7 to affect room 2 when you get to it. You'd have the exact same problem if using different layouts anyway.

----------

I can't argue that user-made editors and level data aren't more versatile...I used to make my own editors & tools in MMF2 that were tailored to specific games, making things very easy for me and my team...But C2 is not really meant for making editors and tools so I no longer bother. It's more of a playground for building games imo so I actually see this feature as more appropriate.

The amount of hard-code it takes to build a level editor in C2 is insane. You have very little control in the grand scheme of things. You cannot retrieve object names or create objects by name, nor retrieve object variable names, indexes, some properties, etc. You can't add shaders or behaviors or attributes at runtime. You can't really use tilemaps in a custom editor with the way they were implemented. You can't load frames from one object into another. You have a limited selection of control objects, not to mention a single window/application and no tabs or menus or anything. You are limited in the ways to write and interpret the data. You can't undo/redo or create a history tab.

The list goes on and on. But most importantly you'll be attempting to re-create at least half of what is already implemented in C2's editor, and it will most likely be half as good. Would you rather have every single dev who wants to make these kinds of games take on this massive endeavor, or have Ashley add a feature or two and be done with it forever?

----------

Anyway, I feel like some of you are missing the point. Creating Open-world and Metroidvania style games IS possible in C2. A few devs including myself have already proved that using various methods. The problem is that it's very complicated and extremely difficult to manage...I've had devs (level designers) back out of my projects entirely because they were so confused. Even I, the one who designed and created the whole engine and metroidvania system in my game, find it difficult to manage and actually do anything with.

The features proposed here aim to make Open-world and Metroidvania style games more accessible to everyone, and easier to develop and manage.

[quote:2zsiot96]The issue seems to be a visual and code/data disconnect. People want an easy visual, yet high level of control. At least not from what I have read and see. What is proposed does not make this possible.

An easy visual solution just cant give the control needed for the instances where the proposed tool would even be useful. Not in a basic sense of keep these rooms loaded. Don't load these rooms. All of it is one layout, etc etc. It seems to miss the whole point of wanting rooms, and I cant see it being useful from what I have read so far.

As I see it, just the visual aspect itself is important. It's relatively easy to structure a non-linear path between layouts when you have just a handful of them. But what if you have something like a 100 room arrangement and only a right-hand list of layouts to organize them with? There's no visual overview of how the rooms are connected within the editor, which makes things tricky. Of course you can draw the entire map structure out on paper, arrange sections of the map within separate layout folders to keep it less cluttery and so on, but yeah...

I have issues with your 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[rooms] 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.

I feel like these issues were overlooked.

Nesteris

Still, reading this thread again, I honestly feel like you guys are asking for layout transitions more so anything else.

These "rooms" Are essentially their own layout as described. They offer no additional functionality, and arguably take away functionality. If thats the case there is no use for them.

Asking Ashley to recreate the wheel solves very little, although sometimes we have to take a step back to take two steps forward.

I'm only saying this based on how you guys have described rooms. Or have not described them.

I got memory management out of this, but not much else. I like the idea of a layout loading chunks of the layout at a time. This would make open world games possible. Not needing to worry about destroying objects and having too many textures/objects in memory. Is this all too different than the current cell/texture loading though? Also, if that means sacrificing local variables. And removing layout persistency I am fully against the idea. Layouts would be obsolete. And the issue would then be how to make chunks bigger so I can have my persistent chunk. (each chunk would be its own layout? No reason for this.)

The room object as a container, essentially an array of the objects, storing their position,scale,rotation,behavior states, etc is the only way I can see this being useful. It wouldn't add anything new, but it would make things easier to design our own systems. Local variables would be consistent for those that need consistency, and manually reset as needed.

If you want to manipulate objects in a specific room. On the event sheet you select the room object, and it has behaviors/ events that are simply those of the objects it holds.

I feel like QuaziGNRLnose nailed this topic. If you need complex behaviors like this, you are best with your own system. Or a system designed to let you build your own.

Everything Quazi brought up was regarding the original idea of linking layouts together, which we have decided against. We have two entirely different features on this topic now and you guys keep mixing them up...The benefits of this room object are very simple: Allows users to create very large open-world or metroidvania areas in a single layout by loading it bit by bit, and allows users to view/modify all rooms in a layout at once instead of using a simple list and viewing one room at a time with no world reference. It is a godsend for those looking to build these types of games...What is with all the fuss?

Since the thread was originally about supporting editing multiple layouts, why not start a new thread along the lines of "editor features for very large layouts"? It would be useful to me anyway to have these ideas distilled in to a specific set of suggestions, and would help avoid getting different kinds of ideas mixed up.