*Brings more pizza and offers a toast*

Yum pizza! Pepperoni, no sauce. Truce for now, then.

I've been thinking about it all day though, and I'm finally beginning to understand what you mean. When you say private event sheets, you really mean "object event sheets." Events explicitly tied to objects, carried between layouts and with process priority over the main event sheet.

I am still not wrong in saying you can do anything this would accomplish already using Construct's current event structure. But, I see a benefit in my specific scenario to having things the way you described:

Let's say I have a set of level designs I want to be able to call at runtime, based on a user's customization. I have SPACE, OCEAN, and LAND. Right now, I have event sheets for each that are included in the level's main sheet and only activate based on a variable. While this accomplishes what I intended, it means that I have have all the events for those designs included at runtime. What your idea of "Private Event Sheets" could accomplish is saving valuable memory - whether that be a few bytes or several kilobytes of events unloaded from RAM. All I'd have to do is call a control object for that level, and it would bring along with it the events needed to animate that level.

Am I getting close to your vision of this?

Really, what it boils down to here is a tweak to ease of use and some memory micromanagement... I still contend we can do this without private event sheets. But what's the harm in having as many options as possible, right?

One of your other points.. the one about process priority, I'm not sure has anything to do with this. Take an object that follows the mouse cursor on an ALWAYS event. As we can see, even running at a full clip the object is always a few milliseconds behind the mouse cursor. This might have more to do with Construct's internal workings than anything we can create with events. On the grander scale you described, you're right. This weirdness cuts into the viability of user-created behaviors. Maybe Rich can shed some light on it for us?

The unbounded scrolling is your answer. Use that, then zoom your layers using events.

That has something to do with your containers. I can't pin it down yet, but when containers are taken out of the question, your Zombies are not destroyed when a container object it destroyed. That said, leaving the containers in and removing the events to destroy container objects still causes this problem. hmm

I still stand by my assessment of this topic.

Essentially, all you're asking for is a different way to do things you can already do. In my project, for instance, I've created several custom event sheets that some might consider "behaviors" if they were made into plugins. The only difference between Construct's plugins and my custom behaviors is that plugins can be used through the User Interface while mine cannot. I disagree that this is a hinderence.

Much like a plugin, I can call functions from my custom event sheets. I load variables into the math that I can define at any time. To link them to specific objects, I use family groups and yet more variables as a means of picking them, and then deciding what to do with them. Instead of using events stemming from each sprite, I call what I want from the system object. And whenever I want to use these custom behaviors, I simply include them in the parent event sheet. I've done what you've wanted done, and in my mind it's a simpler solution that Construct already supports.

I'm still working on a demo for everyone to play with - one that displays this exact thing and is fully customizable. It will be at least another week, though. I've been asked to work extra hours at hhgregg lately.

Many of the control systems in place are barely even started. Expect major control options to be in place by version 1.0, if not sooner. Stay tuned.

Layer zoom ratios are a cool feature of Construct you might try playing with. You may set them initially per layer property, and at runtime with the system object. Or is this not what you meant?

I think I misunderstood. Sorry.

It sounds like you need to restart your computer more often.

In any case, I don't feel Construct should allow this mismatch. Ashley, would there be any practical use for this?

Take a look at this for Pacman programming resources, including notations of original source code.

I still don't quite understand your concept of "individual event sheets," or more specifically, how it differs from separate event sheets that can be "included" into any other sheet. Also, what you're describing has more to do with function calls and object families.

Instead of copy-pasting events multiple times, you can achieve like behaviors with functions. Make your ghost patterns as functions, and call them using variables to dictate which is applied in different circumstances.

That's really just the beginning, though. In Pacman proper, each enemy has its own unique quirks. Each is slightly different from the other. Using functions, you can build those quirks into your system and call them as necessary without multiplying events across multiple sheets.

Funny.

I'm all for translations into every language. I've been trying to get one of my Japanese buddies to consider lending a hand.

Sweet deal, Ashley! That would be great, especially if you paint clones of objects grid-independent.

On my Vista machine at least, the recently released Service Pack 1 ironed out a lot of speed and stability issues I was having with Construct. Be sure you have it by now, as it's just a plain old good idea to be up to date with your OS. Will it help this problem in particular? Unlikely, but there have been countless alterations to memory management and graphics drivers/directx compatibility.