I think my previous replies still explain what all the fuss is about for most people tokinsom, but I just now realized a possible reason why you would think it was easier not use them. when you made minitroid, and possibly other games, you had a clever level editor so it was much more convenient to have the level editor load the level, create a generic object and assign it all the values it needed right then and there. That makes sense why you'd find it a hassle in that type of situation.

on bullet collision with enemy

(subevent)Enemy.value=Goomba

------ Do anything a goomba would

(subevent)Enemy.value=Koopa

------Do anything a koopa wouldquote]

on bullet collision with koopa

------do something with koopa

on bullet collision with goomba

-do some goomba thingquote]

This single enemy object could contain every behavior that could be activated/deactivated depending on what the enemy variable is. Animations could be set like

-GOOMBA_Walk

-GOOMBA_Squished

-KOOPA_Walk

-KOOPA_Squishedquote]

enemy - play animation - enemy.value&"_Walk"quote]

enemy - play animation - "walk"quote]

Then when the enemy dies? More sub-eventsquote]

+Enemy dies

--- do something for any enemy

(subevent) If it's a koopa

   --- do this

(subevent) If it's a goomba

   --- do thatquote]

enemy dies

---do something

koopa dies

---do this

gooma dies

---do thisquote]

find that easier and more convenient than making totally different objects and putting them in the same family. Hm.. it's not like you must like families, but personally, in all the above examples, the family version seems much cleaner and readable. Also the icons make it much easier to read the event sheet as well.

edit: also to emulate multiple families on a single object would make things a little messier still

like Koopa could be in the 'enemy' family and the 'ground creature' family and the 'all character' family

I understand that you don't need more objects, but having multiple objects is visually and conceptually useful

I this assuming 'badvulture' and 'evilsmiley' are in the 'enemy' family

every tick

--badvulture - move slow

--evil smiley - cackle maniacly

on bullet collides with enemy

--destroy enemy

i think that's how it should read, and making the events was effortless. the most elegant equivalent without families either involve some naming convention, private variable comparing, or some clever functions, or just rote memorization of animation names and such.

I don't want to have to call functions, or use naming tricks, or remember what animation and what logic goes to who. I want the event sheet to have different icons of different enemies, or the single family icon, so it's easy to see what actions apply to who without reading anything. I want enemies to be able to collide with eachother, without having to check a name or a PV and some other workaround for multi-objecttype picking. And conceptually, I want the actual eventing process to align with what's going on in my head, which is separate types that share some common functions.

it sounds like you're saying there's an advantage for not using them? is this to save memory?

I agree with telles0808. even though it's possible to do as you said with single objects, but what about objects with animations? that would definitely be very annoying without families. or if you wanted totally different logic for each enemy, or ui element.

something simple like:

On playerprojectile collides with Enemy -

-----subtract (playerprojectile.strength-Enemy.defense) from variable Enemy.energy

where 'playprojectile' can be all the projectile in the game, from arrows to lasers to machine gun pellets. 'Enemy' can be everything from walking soldiers to flying birds, to turrets. If your game has 30 projectile weapons types, and 50 enemies. without families that would be quite an annoying task to copy paste those to each enemy, and unthinkable to do some sort of animation frame based family equivalent. with families it takes a few seconds.

simple functions like enabling and disabling, creation and destruction, positioning can apply across a broad range of objects. The readability improvements alone make it worth it, but it can shorten the cap length drastically, and certain tasks that would be annoying or infeasible with some other workaround are as effortless as any single object logic.

I don't know where the mess comes in. The use would be that if you want physics effects, like physics controlled hair, or antenna, or the as the OP asked, the ability to push or drag physics objects without having to make your character controlled by physics, then you can have both. If you want a fully physics controlled character, then platform movement doesn't enter the picture

Python has its special cc rules and quirks to get used to, and its less limited than events. you should be able to do everything you can with events and more.

You can combine physics with other behaviors, just set physics to immovable object, and expect the object to behave as if it has infinite inertia.

yes, you'd have to make a runtime for the plugins, but what I'm saying is even just sprite with only position actions and expressions and box collision, text, and touch, 2 or 3 basic system actions, and no behaviors would be useful. that was about what I made in android last time, so I definitely know it's possible and of a manageable workload. I don't mean to make an exporter that gives you complete ready to use files, but gives you files you can load and have ready to compile in the target language, like a cap translator.

the programmer would be required to write a Drawing function for the runtime, and for each plugin, and set up the main loop where the bulk of this copy pasting finding replacing would occur.

you would also specify how something included in the cap file would have to be included in the target language. You would have to create equivalent functions for any ace you will use in your cap. If you didn't care about time delta, you could ignore it. if you needed platform really badly, then you could include only the functions you needed.

I could do alot with just sprite, and no behaviors, and I'd love to have a basic tool like that for android or iphone running natively. I have a few ideas of how the most of the translation process could be generalized for use with different languages, and automated with an app.

Also, it was reading that blog post that gave me the idea. and then after having a look through C2's files, I think it's doable. obviously Ashley knows what he's talking about, and making a complete runtime is infeasible for pretty much anyone but scirra and html5 right now, but a very limited runtime could still be useful, just like c2 was in it's infancy.

it could also be opensourced for people to do what they wanted/could, and if there were even half as many devs trying their hand at it as there are making plugins with js, but just adding features from c2 or specific behaviors, or objects new or old. maybe with some time, a specific platform could even get a respectable feature set.

Edit:

Hmm... interesting idea. What about exporting to something like allegro or SDL? Could then C2 hit Windows, Mac, Linux, iOS and Android with one exporter? Or are there too many differences between the platforms even using a framework like those?I don't know about those specifically, but I would guess most languages, aside from scripting languages, would need at least some platform specific code,

right, exactly, even without an edk, I imagine you could just make a translator from event sheet xml to equivalent functions in the target language. You could even limit the workload by establishing a set of bare bones ACE like Start of Layout, Always, sprite object with movement, resizing, touch commands, and text object with the same commands plus set text. and it could still be useful in many contexts. you could even ignore the edittime, and use the current one (which wouldn't give you any of the benefits of the target platform). Just using the xml and either a parser, or a find replace script, possibly several steps, but doing something like I did with CC and android, I'd imagine you could get much further given how well structured the c2 capfiles are. if/when my schedule eventually opens up, I'd like to try it, at least as an experiment.

I would say that's asking for trouble if you're trying to find loopholes in copyright law. Might not get noticed if the game isn't played much, but when you have as much money as the music industry, you can blur all sorts of legal lines

In the "Why HTML5?" thread in the C2 forums, the EDK was mentioned a few times. For those that don't already know, the EDK is the Exporter Development Kit that Ashley has mentioned eventually wanting to create for C2. I have no idea of the timeframe for it, I imagine it's quite a while away -

but out of curiosity how many out there actually plan on using the EDK when it's released? I personally want to try to make an Android runtime. I dabbled with Android development(java) for a short time, and I enjoyed it. It was very straightforward, and easy to find example code online for anything you needed to learn how to do.

At one point, I had made some android functional equivalents to some basic construct classic system and sprite actions, so you could export a very basic cap to text(simple sprite actions like changing angle, position, and dimensions) do a few find and replaces in a text editor, and it was working android code. It was rewarding work, and I imagine working with the EDK would involve alot of the same things. Once I had time to start on a runtime though, I'd definitely want to at least try to assemble a team.

How many other developers out there plan on trying to do something with the EDK? alone or in a team? open-source? commercial? what platform? etc

I think a good move for Scirra is to release the EDK first, this way they can let users work on the exporters and they can worry about what they think it's more important.I'm not sure how close what Ashley's currently working on is to an EDK. For all we know, writing the edk may be as much work as writing an exporter. But if it is more like the combined time it takes to add 2 or 3 major features like local variables, grouping, and families - then I don't about whether it's a good move for scirra, but personally that'd be the feature I'd most look forward to.

Ashley is probably weighing the potential userbase for the EDK into how much of a priority it is. I know of at least a few people in the forum who are experienced enough with coding they could make a runtime, and there's probably well over 200,000 construct downloads between classic and 2, so there's bound to be many more out there, but there aren't many users who've mentioned in the forum they'd like to use the edk, just the desire for the runtimes people would make with it.

I personally would like to start such a project with android, and hopefully recruit a team. I've worked with android development before, and I enjoyed working with it, and it'd be an awesome platform to be able to make native apps for with c2. I'd be curious to know if there was anyone else who would want to contribute to such a project?