just wanted to drop in with a status update.

going by the current state of the software, and the speed things are working, this next version will be the last major update before 1.0. This will also mark the upgrade from alpha to beta status, and should be feature complete. From there it be correcting any bugs, or taking small requests to enhance the ui.

I'm going to be adding a number of features over the next week, and then I'll try to give you a better time estimate than "soon".

thanks for your patience!

also 1st link uses most of the same info from 2nd link, which is about 8 months old.

I doubt nothing has changed since May last year

yeah, I only got a chance to turn it on for a minute to get a basic peek, not really enough to comment on gameplay.

but as far as initial presentation, my critz are I don't like the weird nonwindowlike window in the center of my screen I can't drag around or hit maximize, or hit Esc - then choose go to full screen. and the pointer that stays visible, but doesn't seem to serve a function. and the game over screen that lasts a few seconds, but you can't skip.

it does look cool though, the mix of retro and effects is interesting

bought my copy!

I've seen how much polish you put on your regular hobby type caps and minigames, can't wait to see what you do for a commercial title. I'm not going to be able to play until later tonight though. have to finish up my commercial project, as well.

that's possible, but I suspect the native c2 xml would be the most simple, rather than exporting first to html5, given that xml is made to be a markup language that focuses solely on documents and arbitrary data structures, and in the c2 caps that's how it looks, just the information you'd need for a runtime to interpret, and a little info about the editor settings, whereas the html5 will have alot of implementation specific commands to contend with.

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.