The way I interpret this: The platform movement behavior is a black box and you really aren't given any definitions for how it should behave under any circumstances. You might even say it's undefined. Therefor it's perfectly legitimate for any particular use of that behavior to make demons come out of your nose.

Yeah, it's a weird behavior you've shown here and there isn't really any particular reason to think it's intentional, but it's not necessarily a bug. If you don't want weird inexplicable crap to happen, you have to program your own behaviors in a way that you can understand.

Tested it (the RNG) on my PC with Chrome. I'm not observing any particularly abnormal patterns.

EDIT: Part of the problem is that you are allowing the event to execute multiple times in a single jump. This can happen multiple times within a 10th of a second period, so if the event procs twice (which it does often) and the boost value is already set, it's going to spawn multiple times for the same random value.

EDIT2: By the by, it helps to add audio cues to test this sort of thing. The reason I was able to figure out that it was doubling the events on single hops is because I made it play a sound whenever it created a fruit.

EDIT3: Fixed it so that it can't execute the event multiple times without multiple landings.

filedropper.com/fixedit

Make sure you remove the sounds if you ever use this for a commercial project. They aren't free to use and doing anything commercial with them is a no-no.

I'm more interested in the behavioral side than the thematic side of platform enemies myself, but here is something I made back in MMF2 to give you an idea behind the thought process:

youtube.com/watch

State 0: Patrol state (entering mode sets state timer to 0)

1 - increase the state timer by 1 each frame until it reaches 60 (1 second)

2 - every frame move X pixels in the direction faced

3 - If the state timer is >= 60 and the player is in reactive area (space in front of the plasmole) then enter attack prep state

4 - After 200 pixels have been traversed, switch directions. (monster pauses for roughly 20 frames before turning) and continue traveling

State 1: Attack Prep State (state timer set to 0 upon entering)

1 - every frame increment the state timer until it reaches 40 (2/3rds of a second)

2 - point weapon at player every frame

3 - state timer >= 40? Switch to Attack State

State 2: Attack State (state timer set to 0, gun_angle_base set to whatever the gun angle is upon entering)

1 - every frame increment the state timer until it reaches 90 (1.5 seconds)

2 - every frame set the gun position to... some magnitude * trigonometry function (sin I think) of the state timer + gun angle base.

3 - every 3 frames generate a puff of fire which will travel out of the gun at whatever angle the gun is pointing out.

4 - when 90 frames have elapsed, switch back to patrol state

Destruction State:

generate flying gun piece. Apply velocity.

spawn an explosion sprite which will just vanish when it is done animating

destroy the object

Flying gun piece:

add gravity each frame.

after some number of frames, make it spawn an explosion sprite as above and get destroyed

fire puff:

Proceed in direction of velocity

After 60 frames vanish (vanishing lasts 10 frames. Fire is not collidable while it vanishes)

You can create your own layering system pretty easily in GM you know. Construct 2 isn't better, it's just different. And it's also in a much lower state of maturity right now. Also if you understand the scripting language, you can usually throw stuff together much more quickly than with an event driven system. They both of their merits.

It's true C2 lacks a lot of freedom for modular elements and teamwork. Other than a small team where people make assets and provide them for a developer, it would be rather difficult to work as a team. But, on the flip side, it is much easier to make big progress as a single person or small team than in a lot of other tools.

You know, I haven't exactly tested this myself yet, but I'm pretty sure C2 is actually quite capable of being used for a more collaborative type of project, especially compared to Construct Classic, old versions of Game Maker, and any ClickTeam product. The event sheets and layouts are all XML so that should have no trouble working with something like subversion and you should even be able to work collaboratively with multiple developers being able to handle merges of eachother's work in place as long as the placement of blocks in the XML don't change arbitrarily (and I don't see any reason that they would).

Alright, update time. Here is an example of some simple collision mask collision using C2's built in array object. This is the simplest type of mask collision which is really just a straight array of layout x by layout y and it's pretty suboptimal as far as performance expectations go, especially since everything is buried under C2's function calls which are kind of slow compared to what you could expect out of something specifically coded for the task.

filedropper.com/arraycollisionmask

Actually the news is pretty good. In this manner, up to 450 pixels per frame could be tested on my machine before framerates dropped below 60. This might not seem like a huge amount, but when you consider that you can usually get by testing 8 or so pixels for the primary character collision against terrain and usually less than that for other entities, it's not half bad. Performance would probably go up significantly if something were written to handle this more properly in javascript too. And it's much faster than what I was seeing when using a canvas of the same size and checking rgba even when it wasn't obscured behind as many layers of events.

Sorry for the simplistic geometry in this example. I didn't want to spend all day coming up with a method for converting sprites to pixel mask points. I have an idea of how to do it by using a temporary canvas, but it shouldn't take away from the purpose of the demonstration regardless of that.

Deep recursion can commonly cause a stack overrun and it should be avoided in favor of loops whenever possible. I did notice something that could possibly be a problem though.

I couldn't reproduce the 50/50 behavior you described with Chrome. With a value of 500, on average it would work for 4 clicks and then on the fifth and above it would continually produce a minimum call stack size exceeded error. Lower values would do the same, generally requiring more clicks. It sounds like each subsequent call to the function is pushing deeper into the stack and that doesn't seem like something that should be happening.

I'm not a javascript programmer, so I don't how much of a problem this really is.

EDIT: There seems to be a specific cut off for me where the problem simply doesn't happen and where it happens unconditionally somewhere around 408 levels deep. I don't think this is an issue until you hit the critical point.

Gave it a look. Conceptually, it's very similar to what I'm thinking with this. The only problem is the canvas assigns (I'm guessing here) 32 bits per pixel and it probably has a full buffer for the entire canvas all the time. I can't just copy an entire 20000 x 4000 level into the canvas and call it a day. The memory needs are pretty large. I might be able to get around that by creating lots of smaller canvases as needed. I'm not sure how workable that is.

I think we just need a more targeted solution for this. Ideally we could have something like an array of 64x64 (or whatever resolution. Maybe even make it user-specifiable) patches which could be all empty, all full, or point to a 64x64 mask so that when you are checking for collision at a spot, you would do the following:

*pardon my silly pseudocode*

a 64x64 mask has the following values:

collision_type - enumerated from ALL_EMPTY, ALL_FULL, MIXED

collision_mask - NULL if ALL_EMPTY or ALL_FULL, a pointer to a 64x64 binary array if MIXED

int collision_at_point(int x, int y)

this_64x64mask = all_64x64masks[x / 64, y / 64];

if (this_64x64mask == ALL_EMPTY)

    return 0;

elif (this_64x64mask == ALL_FULL)

    return 1;

else

    return this_64x64mask->collision_mask[x % 64, y % 64];

That way areas with no collision to worry about and areas with big spaces all contained within collision wouldn't be a significant memory burden.

Pretty impressive little plugin though. It'll be a good start for some of the experiments I'm working on right now.

EDIT: Performance testing using the canvas is less than promising. Using the same method as the Mario mask against a 1280x720 canvas, I was able to test about 10 points per frame and still maintain a 60 frame rate with webGL off. Meanwhile using the same conditions with sprite collision, I was able to keep full frames while checking over 1000 triangles each frame against 7 identical objects with a 30 point collision mesh with concavity. I don't think canvas is going to work for these needs. Also for some reason WebGL just kills the performance of all my tests... not sure why and doesn't really have anything to do with this topic.

link to test capx

filedropper.com/testcollisionvscanvaspoint

I guess you're right about curved/complicated geometry - it would be useful to have automatic pixel-perfect collision masks for that. But I'm still not convinced Javascript is capable of managing all the processing. Perhaps if we compiled the collision engine with asm.js, but then it's even more complicated... are you sure you can't work around it by assembling lots of polygon sprites together? Hopefully a well-coded engine will still manage OK with curves made from lots of small straight lines. I think most physics engines more or less treat that as a curve if the error is small enough.

Well yes, to some extent all curves are just a series of straight lines, particularly when you are dealing with pixel art. There are a couple problems with using lots of smaller polygonal sprites though. For a platform game along the lines of what I'm thinking (and we are talking small resolutions for the visible frame right now... 320x240), level sizes routinely end up being somewhere in the neighborhood of 14000x4000 pixels and can come in much larger sizes. In order to achieve the kind of curve density that is appropriate with simple approximations, we would probably have to divide them into much smaller chunks (somewhere between 8x8 and 32x32, and those are a pain in the butt to work with in levels of that scale). It's a huge sprite explosion anyway and I have some concerns about the performance in that case. The worst thing about it though is how much additional strain it puts on getting art into the game. Generally we prefer for people to be able to work with 128x128 terrain pieces, but for something of that size you can expect to have somewhat complicated geometry that has a few notable problems:

1. The automatic collision mesh generator fails to create something resembling what it should be.

2. The amount of points needed to map the whole terrain piece vastly exceeds the recommended limits given by C2 (probably not as significant of a problem since these recommendations are more likely intended for small standalone and numerous sprites).

It's also common to have over a hundred different set types of 128x128 blocks each needing to be set up separately for collision... so for this type of game the problem is really compounded.

To sum it up bluntly, no, I don't think that approach would work.

Collision masks are really the most proper way I can think of to do this. I think you are misunderstanding something about the problem though. The real-time processing component of this is very small. The simplest (IE extremely expensive as far as memory is concerned) variation of this is a boolean array of x by y where x is the x and y are those dimensions for the scene. Figuring out whether you have a collision at a single pixel is just a check against one element in the array (array[x][y] where x and y are where you are checking) to see if it's true or false. I don't think it's actually possible for any kind of collision to be computationally cheaper. It only gets expensive if you need to check a large number of pixels (which I think is why you are assuming it's so expensive). Most behaviors only need to check a handful of points. And consider how this is done with polygons... if you want to know significant details about how an object has collided with another, such as whether it was a front collision, a top collision, etc. you have to use numerous objects anyway, so the additional checks still have to be done just like they would if you were checking pixel collision at numerous positions. So for people who need advanced knowledge of the collisions there really aren't any perceivable savings using polygonal collision solving... at least assuming polygonal collision is more expensive than checking a single value in a boolean array for truth.

Forgive the intrusion, but for a looping, like in sonic, I would do it using events, and not collisions.

Maybe this year I release one sample with it, but the behind scene of a looping is something like getting their diameters, and doing the trajectory manually, using events, and doing all the exceptions, like the player releasing keys too.

Loop-de-loops are a very small piece of the puzzle. It's also one we've hit from several different angles over the years.

The problem with trying for individual math-based approaches to solving it is how varied the loops are in the first place. They aren't all perfect circles. Some are ellipsoids rather than circular. Some taper off in places. Others are just plain irregular curves that can't be solved with simple trigonometry. Even if this weren't the case though, you still have to consider that there are ways to hit them that don't involve moving through them smoothly. You still have to have the collision in place for them even constrain yourself to just loops that could be solved with simple math. What you are suggesting has been tried before back with old Click n Create engines and the results have always been unsatisfactory and hard to apply with any versatility.

It's much simpler and you'll achieve better results in the long run to just have the loops as normal geometry. Things look better when the movement always follows the same basic set of rules anyway.

You might have the port blocked by something which could prevent your server from listening on port 50000.

The netstat tool might be able to tell you if this is the case. Then you can use the PID of whatever process is blocking the port to forcibly end the process.

support.microsoft.com/kb/281336

I'm not sure if Windows firewall is capable of blocking anything on localhost, but that might be worth a peek as well.

Forget about video drivers or HTML5 trouble. From what the browser is saying it's clearly a networkish problem.

Tekniko: I was under the impression that C2 ran entirely on HTML5 and javascript without having to use JRE at all.

Your inkling is correct. You could have just read my profile though <img src="smileys/smiley2.gif" border="0" align="middle" /> . I was involved in creating one of the more popular pivotal engines used by the community (not chiefly, but involved) back when I was in school and part of my interest in this topic is because this is a feature that I consider necessary for porting the engine from MMF2 to Construct 2. Well, strictly speaking we could work around it by creating tools externally to create the collision masks and then loading them from a text file into an array or something... but the intention is for anyone to be able to pick up the engine, throw some sprites in there for level geometry and then run it without having to muck about too much with collision and the closer to the core that functionality is, the better.

That said, if it were only something needed for the purpose of one particular type of game which is itself a clone I wouldn't be suggesting this as that would be kind of selfish... so give me a little time and I'll throw together some nice examples.

I agree that this would be a significant investment of time. I don't think it's the collision itself that would be the problem here though. The hardest part would be figuring out how to generate those collision masks in the first place. I don't think it's something you should even begin to support the platform movement behavior with. It's clearly a feature that would be geared towards people rolling their own behaviors.

Sometime this week I'll try to convince you why this is compelling with examples within Construct 2. It's mostly a factor in platform games that feature lots of irregularly curved and sloped terrain which requires complicated collision meshes to adequately suit the form of the visuals that it represents. For now though, think about a game like Worms where the terrain is just an absolute mess of elaborate geometry or Robot Unicorn Attack which is all kinds of curvy. It's not only computationally expensive to have elaborate collision geometry with polygons, it's also a serious drain on making art usable in game.