Cloning layout doesn't copy events.

New releases and general discussions.

Post » Thu Nov 22, 2007 11:06 pm

Yeah, Dines' idea is leads to most "logical" and structured system. Actually, I was going to suggest something like this too :D. First, I didn't like that the system is so strict that you actually can't include layout-specific event sheets to anywhere else, I just wanted a system which makes the structured arragement and management of events and event sheets easy; now the "additional" event sheets are like hidden in project's properties, which they shouldn't be.

Now that I think it, including event sheets from "just" another layouts (not from the "centeral structure") is kind of bad habit, like GOTO in program code. So, I think that Dine's system is pretty good. It has it's benefits, it kind of forces users to use more structured and effective ways.

Now, only thing that concerns me, what kind of UI would be good? I didn't fully get the Dines' picture... :P. Is the upper panel the Project bar? Maybe those funky words, pretty and groovy are just messing my thoughts... so groovy... :D

And btw, what's the purpose of Resource bar? There surely is some resources, but it feels somehow only half-necessary... I think that Resource bar could be integrated to the Project bar. Under the "Application" main node, there would be the layouts, as a part of the project and other resources.

Yup. Whaddaya think?
B
3
S
2
G
5
Posts: 263
Reputation: 2,201

Post » Thu Nov 22, 2007 11:17 pm

Lol, it's basically exactly the same as construct now, just with an extra box on the 'Project' panel.
B
4
S
1
G
5
Posts: 48
Reputation: 1,546

Post » Fri Nov 23, 2007 1:09 am

Hm, I thought Dines' system some more. I realized it lacks some flexibility - if the included event sheets are specified in that additional box, you can't arrange how the includes are in the layout main code. In some situations the run order of the events does matter. However, the events separated into different sheets don't usually have too much relations, so does the order matter so much?

As you might read from my previous post, I had some kind of vision of "unified" Project bar. It could have the layouts, the resources and the "general" event sheets there. And event sheets could be included in the event editor, like now. Maybe there could be a restriction, that the layout-specific event sheets couldn't be included, I dunno about that.

Edit: Oh, and I have a questions for Ashley: Is there need for global objects? (Or, what I really want to ask, is there need for non-global objects :D) What they actually are in Construct? How they differ from normal objects? What I'm thinking, global objects are some kind of relic of "thinking in MMF", I think that every object should be "global" so that there wouldn't be hundred and one types of objects which actually are the same, copied to different frames.

Or is it only my who is thinking in MMF :D? What does globality mean in Construct?

Edit 2: Apparenly, it was only me :D. Did some testing and in two different layouts it considered copyed sprite as the same. So objects are global in a way. But what does the "globality" in Construct mean then?

And is there some GUI for inserting objects from the other layouts, except for copy&paste? And what about objects without "body", like Keyboard and Mouse?
B
3
S
2
G
5
Posts: 263
Reputation: 2,201

Post » Fri Nov 23, 2007 12:27 pm

One idea may be that for the project panel, you could simply have folders like this:

Layouts
- Jungle Madness 1
- Jungle Madness 2
- Street Rage 1
- Street Rage 2
- Create New...

Event Sheets
- Loader
- Player Movements
- AI - Monkey
- Create New...

Objects
- Player - Default
- Player - Cool
- Player - CyberSuit
- MY MONSTERS
-- Bullfrog
-- Lizardman
-- Chinese Person
-- Polish Martian
- BACKGROUNDS
-- NORMAL
--- Grass
--- Sky
--- Tree 1
-- SNOW
--- Grass
--- Sky
--- Tree 1
- Create New...

Subfolders, etc, would be created by the designer. So it'd be up to the designer to determine how things are organised internally. But perhaps subfolders could be changed at runtime? So an event to find all textures in 'Backgrounds\Normal' and change the active path to 'Backgrounds\Snow' would instantly load the snowy equivalent?

This idea's only rough, but at least it'd help organise stuff. At the moment, I think it's too heavily centralised on the Layouts.
B
4
S
1
G
5
Posts: 48
Reputation: 1,546

Post » Fri Nov 23, 2007 4:08 pm

i second dines idea, it's actually more organized that way. in addition to allowing developers the option of creating custom folders have an option to create default common folders as well.
B
2
S
2
G
5
Posts: 293
Reputation: 2,236

Post » Fri Nov 23, 2007 4:43 pm

I really like this idea, but I should mention a few things. Firstly there are still a lot of bugs in Construct, so a fairly major thing like a new bar should probably wait until after 1.0, no matter how good an idea it may be (I do want to take event sheets further).

Secondly, the original plan for event sheets was:
- Each layout has an attached event sheet. You can see this in the layout properties (eg. Event sheet: Layout 1).
- Adding a layout adds a new event sheet so the layout has its own attached one. This is a metaphor for "private" event sheets, but you can freely choose in layout properties which is the attached event sheet.
- In application properties you can freely add more event sheets for things like global events, collections of functions etc. and include them where needed. Eg. you could have a 'Menu events' sheet for your menu layouts, and a 'Game events' sheet for your levels.

I think this system can achieve everything you need to do with event sheets, just instead of private sheets, layouts have a default sheet.

I like the project bar integration idea best over a separate bar though, Dines' idea is good: under 'Application' would be 'Layouts' and 'Event sheets', listing both.

In response to Drasa: Construct is designed solely on a global object system. Every object is actually global. You can't have two different objects named 'Sprite' on two different layouts. But by default when a layout ends all its objects are destroyed - ticking 'global' in object properties just stops it being destroyed, so it's still in the next layout, and is still affected by any events the second layout is running. Also when you clone a layout, you should end up with more instances of the same object types on the second layout - this fits in nicely with the event sheet includes, because you only need to write events for one set of object types (families also work correctly across included event sheets).

Finally I didn't actually write the event sheet system, and it's too broken to be useful right now, and the devs who wrote it have as you know bailed out, so I'm a little stuck - I'll try to do my best though.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,518

Previous

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 1 guest