to check for collision between two instances of the same object, you would need to put that object into 2 different families (e.g. red and green). you can then use a condition like 'red: on collision with green' and follow that up with subevents managing your behavior:

+ red: on collision with green
    + green('size') is equal to red('size')
        + green('size') is greater than 1
            > bounce
        + green('size') is equal to 1
            > merge
    + green('size') is not equal to red('size')
        > merge[/code:1j1tg4ri]

i don't want to question your design decisions, i just wanted to tell you how i felt; sometimes that is helpful to the author. i hope you don't mind if i try to like your future creations anyway :)

this uses a sprite with a single texture (64*64px, divided into 16 tiles of 16*16px each) and the distort map's texture coordinates to 'animate' the sprite, meaning: showing every tile of the texture in order. very low-fi tech demo, and most probably obsolete (especially with vram controls coming up), but i had to get that out of my system ;)

whenever i dig into a new tool, i usually devour the entire community forum & check for updates at least twice a day. ( i didn't have to be that zealous with construct, though, because it was accessible enough to understand without reading the entirety of all pro-user threads.)

i have since settled for a daily schedule, which is justified by the small size of the community. otherwise, i'd get those nervous tremors again ;)

ashley: a coder i knew tricks his brain by eating a 'debug-tangerine' whenever he gets stuck. it takes his mind off the code and distracts it with something to feel & taste, and usually gets along much better after such a mini-mind-vacation.

i would also like construct to stay the way it is regarding this feature. i've had my fix of that nodey-linkey-paradigm with vvvv. it's pretty cool, maybe you can have a try at it, aritz; but it is just too alien a concept to fit into construct.

that 30 second unskippable 'intro' had me very close to pressing esc before even playing the game. only nerves of steel made me able to endure it two more times.

that looks pretty cool! i like these kind of very simple games; they are so honest about the one thing the game revolves around. they avoid much of the non-gratifying sloth by staying close to their core.

the mining part reminded me of clonk, although that is an entirely different affair. it is more complex, but i always got a similar feeling of accomplishment when harvesting resources & building something from them. it also worked awesome in cooperative multiplayer.

about wasted time: i'm also concerned about wasting time with these kind of games, which is funny, because i don't have that strong a feeling of time-wasting with other, more complex games. arguably, i'm still wasting the same amount of time regardless which one of these i play, right? what do you think of this analogy: i feel less guilty about reading a book that has an intriguing story, an accomplished author, or is scientifically relevant, than reading a book with white pages just because i like the way the book feels in my hands? it's basically the guilty joy of pushing buttons ;)

say, is that the car-behavior or a custom engine?

old school adventure games

m, i guess we could argue rather violently about the good and the bad of olschool adventure game design - let's not! ;)

while i admit that the graphics look okay (for the time, i guess?) and the story & dialogue might be intriguing, playing these kind of games without a walkthrough has had me in dead ends so many times that i can't help but dislike this 'find the needle in the haystack and combine/use it in an arbitrary fashion' kind of challenge.

maybe there is another way of presenting witty dialogue & lush landscapes in an involving and interactive manner that teases the mind?

Can you believe a profit-oriented organization actually shipped that s**t?

like you mentioned in the 'fantastic'-thread, it did not take that big of a company to publish games back then; and you are right about the situation today being similar regarding that people can publish low quality games rather easily. this is why i don't really see the point of bashing old nes games: you could as well grab any random klik&play-abomination and complain about that.

if we really want to investigate the errors of games' designs, we should try to separate between the good and the bad choices & elements that make up these games. jeckyll and hyde does not have that many, it's a bare bones jump'n'run. i guess that

- irresponsive controls are the first big mistake to make with any action game.
• challenging enemies (moving fast & having mean attacks) become frustrating if the player character reacts laggy.
• and the many different enemy types that are thrown at you right from the beginning turn the learning curve into a brick wall.
• enemies are never defeated, only evaded.
• the level is very long.
• the game does not appear to be rewarding in neither its controls, challenges or even graphics.

if the controls were as responsive as super marios, the game would still be difficult, but less frustrating. also, any kind of reward would have been nice. i don't think i saw any indication of the players progress or accomplishment (except the level count and the coins), all the games' displays are for measuring failure. fun times :(

i would argue that, when two nearly identical operations of different scope want to occupy the same semantic identifier, the liability to differ lies with the specific, not the generic. instead of requiring the family variable to be called by Sprite('Foo.Bar') just so we can confuse ourselfs by mistaking it for Sprite('Bar'), one should take care to name the private variable 'MyBar'.

besides introducing another way to confuse yourself, i agree that namespace separation is not a bad idea. but you should not be required to include the family when calling the variable from the family itself. because Foo('Foo.Bar') is exactly that :/

depending on the circle diameter, you'd only have to build the segment that is actually visible; but you're right, piling vertices for smooth edges is a performance hog.

another idea would be to use quarter-circle textures & build a circle out of 4 sprites. that way, you could achieve smooth antialiased circles with a diameter of up to 8192px, given a limit of 4096px square for textures on most graphic cards.

(this won't suffice! its less than 9000!)