Feature: Multi-Layout Editor

Discussion and feedback on Construct 2

Post » Mon Nov 17, 2014 12:03 pm

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

Post » Mon Nov 17, 2014 1:39 pm

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...
B
39
S
16
G
6
Posts: 542
Reputation: 7,617

Post » Mon Nov 17, 2014 5:22 pm

QuaziGNRLnose wrote: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.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Mon Nov 17, 2014 5:45 pm

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

Post » Mon Nov 17, 2014 6:10 pm

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.
Scirra Founder
B
395
S
233
G
88
Posts: 24,376
Reputation: 193,842

Post » Mon Nov 17, 2014 6:32 pm

Yeah that's probably for the best. @Nesteris You want to start the new thread or should I?
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Mon Nov 17, 2014 6:51 pm

Tokinsom wrote: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?



Im not talking about your original idea. Never was.
The things Quazi brought up are entirely relevant to to linking your "rooms" together.

Knowing how the rooms interact and what their purpose is, is all I am asking.

Your rooms sound identical to layouts. With all the flaws and all the benefits.
Only advantage of a room over a layout is seeing a little more of the level design at once.

I don't think me asking you to tell/ explain what you want rooms to do, and how you see them interacting any differently than our current system is asking too much.

What I saw a few times is the discussion is a desire of room/layout transitions.

I simply don't think we need "rooms" to do what you guys are wanting. Simply giving my input. I'm trying to be open minded to the room idea... but struggle to differentiate what you want them to accomplish that isnt already done by a layout.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Mon Nov 17, 2014 7:29 pm

The purpose of room objects, how they differ from layouts, and why they're so beneficial, is all over this thread. There is very little left to explain so I don't really know what you want me to tell you.

Perhaps you'll find your answers in the new thread. I imagine it will go into greater detail and be more concise.
Image
B
243
S
30
G
13
Posts: 1,787
Reputation: 18,770

Post » Mon Nov 17, 2014 8:02 pm

@Tokinsom ,
I'll make the new one if you don't mind? I'll put it in Construct 2 General again.
I'll also try and make the first post as detailed as possible regarding the features.
I'm going to go over this thread a couple times and extract the most of what we had down as functions that the Room Object will serve.

Also, other people reading this thread.
For the love of god, Room Object is NOT going to replace anything
or is implementing it if it is implemented going to have other features removed.
THIS IS ONLY AN ADDITIONAL FEATURE TO THE CONSTRUCT 2 ENGINE.
I cannot make that any simpler, thus people saying things like
if that means sacrificing local variables. And removing layout persistency

Will be fully ignored.
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 » Mon Nov 17, 2014 8:14 pm

Edit: Of course, I decided to reply without reading anything...looks like this idea has been mentioned (room objects). However, I will say this was my first intuition, after reading just a couple posts in this thread, none of which mentioned 'room objects'. So... :mrgreen:

I haven't read thru the whole thread, so pardon if this idea has been mentioned, but what about this:

Sub-Layouts

Sub-layouts appear as objects in the master layout. Their size is determined by the dimensions specified in the sub-layout, and cannot be adjusted in the master layout. However, they can be moved around and snapped together, just like other objects.

If you double click on one of these 'sub-layout' objects, it opens in a new tab for editing. When viewing them in the master layout, you see a static visual of the current state of the sub-layout, which updates whenever you change it.

Obviously, there are some limitations. One that comes to mind is that sub-layout cannot have their own event sheets, properties (other than size), or effects. Instead, these have to be applied to the master layout, and then inherited by the sub-layouts.

Thoughts?
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 13 guests