I wonder if we could even throw in encapsulation? Eg. variables only accessible by the object that owns them. Would that be useful in the real world? And polymorphism...

Well for once, you wouldn't be able to pick which family variables go in and which not (that in itself is weird to me). All vars from the family go in. When defining the family you would have to decide which variables (attributes) it has and their default values. These could be changed without having to touch the objects inside that family.

Encapsulation could be in the form that you could define an attribute (aka family variable) as private, and it wouldn't be accesible unless you were refering to the object via its family. Protected doesn't make sense in this context, as Construct's "methods" (behaviors) cannot read from other objects... can they?

Polymorphism... mmmm well for inheritance you could add families as members of other families, that would be nice. For polymorphism you'd have a family or object that's a member of several families (which is possible right now). What to do with an object that belongs to several families that have attributes with the same name? I'd say just forbid it and show a warning. It's a nightmare in any other way.

PS: I tried the familysubevents.cap but it's saved in a newer version and I'm not updating until I finish my current game =)

that's because PHPBB sucks

and you never know where she's been....

XD kidding of course

okay then.... feel free to do everything the hard way while everyone whizzes past you and finishes several games

I know I've been there and I was speaking from experience. You're free to do as you please, I've already explained myself for whoever reads this far =)

Because it doesn't teach the... erm... "player" about events

There is this misconception in development that you should do everything the "hard" and "true" way. That is not true at all. If you're looking to learn then yeah you should go learn events. If you want to get something done, then the easy way that works is just as good.

I assume you meant "the creator" and not "the player", as the player doesn't need to know (and shouldn't know) anything about events.

[quote:geydqowe]

Additionally...

-is it faster at run time?

-It's not exactly hard to write those couple of events

-what's wrong with teaching players about physics at the same time as Construct?

-Its faster as the plugins are C++, not interpreted events. It probably doesn't matter, though, at this scale.

-If it's not hard to write the couple of events... then why the fuzz about it? why do more work than needed?

-what is wrong is teaching people to always take the longer road to a destination bad practice!

Custom movement would also be a good idea, it has gravity(by way of force) too IIRC

I don't think this is a very good way to learn how to use Construct well.

why not? it's faster in both design and execution and yields the exact same numerical result.

Families and objects are somewhat analogous to object orientation and inheritance. Perhaps you should seek inspiration there.

OpenGL doesn't provide any sound or controller support though... You'll have to use something for that.

Perfect inmaculate purity does not exist in real life. It's a mental construct.

then again I don't care much. If food falls to the floor, I pick up and eat it. And I have dogs in he house, so... yeah. As long as it doesn't make me sick, I'm good. I have defenses.

no positioning or stretching or rotating or filtering setting should EVER yield a diagonal discontinuity in mapping.

This is either a Construct issue or a driver issue.

you could also use platform behavior, set ignoring input on create and set vertical and horizontal speeds.

Make sure to set air deceleration to 0 in the platform behavior options.

this could be related to the anomaly seen with the scanlines effect, when you use a number of scanlines bigger than half the vertical resolution, a diagonal line can be seen where coordinates are different. I have an ATI. I'll update drivers and try again though.

I suspect a sub-pixel difference in each triangle that can be magnified under certain conditions.