I had this dream ....

Ashley said:

[quote:31ghzvf3]No they're not - I've read and I think I understand your suggestion for them, and they wouldn't make eventing more flexible. They'd be purely for organising your events in to different places. None of the things you have mentioned sound difficult, let alone impossible, with ordinary events!

And i closed my eyes, imagined life without toilets, jumped with a scream and returned back to topic.

uhh .. i mean ...

Lets dream about cloning a pac-man in construct, and lets dream it has private event sheets.

Pac-man has 1 pac-guy and 5 scary ghosts.

Should be possible in 4 evenings after work.

Evening 1.

Play pac-man on the net. To see see how it reacts, how it works, whats important.

Search animated sprites on the net (after all we just clone)

Make some screenshots of existing games. Find out the math behind the grids. Make the maze and its sprites.

Evening 2.

Bring the sprites into construct.

Construct the maze.

Develop a collission/tracking system

Make all the events for the pac-guy.

Evening 3

Re-use the pac-guys tracking system for the ghost.

Start with Ghost01.

GIve the handle-object for ghost01 a Private Events Sheet.

All private variables in that sheet get adress as .variable, just like there is .x

Global variables are still global.variable.

It has to chase the pac-guy, also that goes in the private events sheet.

Test the game with 1 ghost and 1 pac-guy.

Make the conditions for when who is eating who.

Evening 4

Clone the Ghost 5 times.

This will copy allso all behaviours, private variables, and the private sheets.

Since the private variables gets adressed as .variable, everything works and is in place.

Just the animations have to be replaced. But the animation structure is there allready.

Test game with 1 pac-guy and 5 ghosts.

Do the level stuff, the end of game stuff, and the start of game stuff

Evening 5 ...

take a look at the forums, and there is a new version, with multiplayer support.

Ohhhh lets try that with oure pac-man thingy.

Move the events for the pac-guy into a private events sheet.

Copy it to represent player 2

Make a flavor in the animations to tell differend between the players.

Link it to the multiplayer plug in.

Find opponents.

Oh boy !!!

And now i go back to my .cap in reality.

clone the Up/right/left/down objects that make up the collsion system that keeps the ghosts in the maze, and helps them to decide to choose a direction thats not taken by the maze.

Clone the handle object.

Clone the object thats helps the ghost to track down the pac-guy. Re-give it a turret behaviour. Regive the turret all the right settings.

Bring in the sprite for the next ghost, give it all the needed animations, give it image points, give it all the private variables needed.

Copy ALL the events/action that make the ghost alive and die.

Change every reference from ghost01 to ghost02, including the references to private variables, including all the expressions.

Change every reference from handle object01 to handle object02

Change every reference for up/left/down/right objects to the new ones.

Change every reference for the tracker to the new tracker.

Copy the events that link the pac-guy with the ghost, and change the references.

Test,

of cours i forgot a detail somewhere.

Debug, and track the problem down.

Yeehaaaaaa .. only 3 more ghosts to go.

Xcuse me for the sarcasme, its in my genes, not meant as evil, just hope you see my point if i force you to "picture" : )

I am not demanding too.

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.

Ah but Captain you do not realise that we have a "private events system" in place and working fine allready.

Because after all, if u break down the concept of plugins and behaviours,

thats what they are,

no more then (hardcoded) "private events sheets",

only some one made them for you,

you can not see "the code",

but your inner eye should see them as such.

Now one day you will realise that, no matter how many plug ins/behaviours,

they can not fullfill your needs.

And one day you will realise that a lot of the events you write are addtions on the existing plugins,

or even your own behaviours.

Lets take the ball behaviour as example.

Its extremely well done, and even better with Ashley's recent improvements.

Still, it lacks a "on collission" event, that works as a trigger.

(the ball has only a filled TAB when accesed in the actions)

Since the events sheet and 'the private events sheet" of the ball behaviour run OUT OF SYNC ...

Collision dedections made in the "general" events sheet will miss "collission" moments between the ball and objects. Althought the "private events sheet" of the ball movement will not miss one. In other words it will always bounce. (if bounce of solids is set).

It also lacks support for "bouncing of defined objects"

Currently it will bounce of solids, or not bounce at all.

To correct this, you will write events, that run out of sync with the ball behaviour.

You will even write your own bounces.

And yet you dont have the flexibility included in the concept of "applying a behaviour" and

the ease of use, and the accuratie that is there because the ballbehaviour is in fact nothing more

then a "private events sheet"

And no matter how nicely the plug ins/behaviours get coded, they will never fullfill all your needs.

While you indeed could code a lot of it yourself in "private events sheets"

One day someone will make a "maze movement" plugin. With as starting arguements:

Maze Grid (x)

movement grid (x)

key up (x)

key down (x)

key left (x)

key right (x)

family thats not intrudable (x)

but till then, you just write it yourself, but you can today not apply it as beening a behaviour.

wich you can if you have "private event sheets"

the function object is a great thing,

but unusable when ...

running a loop,

and based on a condtion set a variable to "true" or "not true"

in fact any loop should not be in a function call (i think now, but that can change)

hope u see what i mean,

and this is not about behaviours,

i just used them as a litte stair to step up and explain whats under it.

j0h

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.

Dude, take all the time you need.

And with respect to your opion.

Its a yes/no situations now. I gave all my arguments !! .. lol ...

Guess we stay at oure "private" opinions for now.

But i am sure, very sure, that this topic will return at one point.

And nowwwwwwwww i gonna eat mah pizza !

*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?

[quote:di6mleih]Events explicitly tied to objects, carried between layouts and with process priority over the main event sheet.

Eggggggactly !!

** yells eureka** ducks for the girls evil eye** cuz messing up the bathroom***

But you still dont see the endless posibiltys : )

And yes most of it can be done allready. WIth hard work, more sweat, and patience.

And i never said you are wrong. Its ok to have differend looks at the things.

Another easy example.

Imagine oure warrior can fire 4 differend projectiles.

1 that has a big splash damage, but little damage in the heart of the explosion.

1 that kilss only air thingys

1 that kills only land thingys

1 that kills over a range located arround a long line

Now how easy would it be ?

To make 4 bullets with special animations in the layout editor ..

Give each bullet (lets say in the layout editor, but it can be a new editor too) ... an individual (private) events sheet.

The events tell the bullet what to do and when to die.

Now all we do is spawn the object in the "general" sheet.

Aim it ..

And thats all ..

The bullet just does what it has to do .. no need to be in sync with the "general" sheet ..

We dont have to watch it in the general sheet.

Dont have to kill it.

nothing.

Just spawn it and, and let it do what its told to do in its "individual" sheet .. Exactly like the behaviours do.

And this in every layout.

And we can keep spawning the bullets over and over.

And none of the bullets run in sync with each other. They run individual, unattented, automatic.

And on top, should be saveble to disk.

And now we have Snippets !!!

We can give them to each other.

And they are usable in every general events sheet.

Once i get you to see, to feel, you will know that not having this is a downer : )

That's actually pretty brilliant. ... Kind of like a better version of the Event Grouping available in The Games Factory. Ashley's Construct app is good an' all, but it Really could do with more Organisation.

TGF actually goes another route in regards to this. It allows you to cut and paste any section of code within the event editor and even put events into groupings, so they can be easily moved and manipulated and referred to with values. And when you need to copy a single object from one level to another, you can do so easily and even take the events associated with that object automatically if you want to. If there was a product with the Interface of TGF and the options offered in Construct (it looks like there's some nice things from 360 degree to all kinds of built-in gravity choices) ... and if it was fairly priced, then I would buy it in a heartbeat.

The idea you have suggested here could help some with the Organising aspect needed.

Construct currently is a fun toy to play around with, but in order to become a serious game creation masterpiece, a few organisational efforts like this should really be implemented to gain the ease of use and speed of development that every click style interface strives for.

To be honest with you j0h, I really didn't understand what you meant until after having read this thread here. But now that I understand, I see that it really could save quite a bit of development time.