This just in: Small update in Chrome causes disturbances in C2 games and chaos amongst the Scirra Community. Will it be fixed? Who knows. "It's out of my hands. Stop blowing up my inbox" says Ashley, lead developer of C2.

Thanks for watching and tune in next month for the exact same thing.

Yeah Ego's been around for a while. Doesn't do so much these days though. As for Sequelitis, I recommend watching them in order...the first two are informative and educational (although kind of state the "obvious you didn't observe"). The Zelda one was more of a rant, unfortunately. Good videos all around, though. Definitely worth your time.

Tetriser There are literally hundreds if not thousands of fan-games, fan-comics, fan-fictions, fan-albums, what have you...and to my knowledge Nintendo hasn't come after any of them except that Metroid fan-film that was on Kickstarter (BECAUSE it was on Kickstarter), and a Pokemon MMO (even that one is questionable). It just bothers me when someone posts about "the dangers of making fan-games" when there is an entire world of fan-works out there with no problems.

— Sounds unlikely to be honest. If that were true then why does Project M - a SSB hack that Nintendo openly despises, still exist? There are live-streams and tournaments with cash prizes and everything for it. What of Brawl In The Family who actually sell merchandise based on Nintendo characters? What of AM2R? Metroid:SR388? Project Fusion? Metroid: Metal? Zelda:OOT 2D? The list goes on and on and on. Even my own fan-game Minitroid was on numerous major gaming sites and I was constantly being told I'd get a C&D or whatever and absolutely nothing ever happened.

I'm not saying they can't or won't C&D fan-works...I'm saying THE VAST MAJORITY of C&D's never actually happened; the developers just didn't want to admit they couldn't finish the project or lost interest or whatever...kind of like when people say they had a hard drive failure and lost the whole project. Yeah..right...

The way I see it..the only reason Nintendo or whoever will C&D your work is if it affects their sales, or if it is something they are planning on doing themselves, or if you're profiting from it... and if they so happen to be in a pissy mood when finding out about it.

For the record, 99.9% of canceled fan-games were not actually C&D'd...the developers (usually kids or beginners) just say that as a cop out. Also, if they aren't making a profit, or if it's a parody, then there's no real problem. Nintendo actually loves fan-games...it's free promotion and shows the dedication of fans.

Anyhow...honestly this just looks like smash but with crappy art. If they added more original content it could be cool. Props for coding it I guess.

Not sure about this "jittery movement" (numerous threads on it already...usually linked to low resolution, pixel rounding, etc.) but I do occasionally get "performance / lag spikes" in every one of my projects, and they are potentially game-breaking.

Construct Classic had the same problem and I'm pretty sure the consensus was that it had to do with garbage collection.

Uh...the audio plugin can adjust volume you know. Just set it to a variable and add/subtract that every tick.

The sinewave behavior has no place in this mechanic. The solution is actually very simple...

+Player is NOT on floor

+Jump button is being pressed

-Subtract 60*dt from Player.FlutterJump

+Player.FlutterJump < 0

+Player.FlutterJump > -60

-Set Player Y Velocity to Self.Platform.VectorY - Self.FlutterJump

...It will probably need some tweaking but you get the idea. It's a simple counter force upwards.

Yep, CPU lag causes frame skipping but no noticeable difference in gameplay. GPU lag causes frame skipping and significant input delay rendering the game unplayable.

Yeah, well as you mentioned the disadvantage of a cap like 0.02 is a few seconds of lower framerate will run the game in to slow-mo for a few moments, which is disorientating for the player - kind of like randomly varying the timescale during gameplay. I'm not convinced that's a better solution. I think we want to aim for a value that just cuts off the spikes.

I think the game slowing down a little bit is far LESS disorienting (especially since every gamer ever is totally aware of and used to it) than severe input lag, skipping frames, and missing collisions, don't you?

That's just how C2 handles bad performance...it skips frames instead of slowing down which, unfortunately, can cause some major problems. I also would rather have slow down..it's what people expect.

Maybe you can code it yourself using time scale?

Jittering can be caused by a number of things.

-Game resolution

-Player movement speed

-Camera Code

-Parallax Settings

-Project Settings

Only way to get perfectly smooth scrolling in low-res games is to move the player the same speed as the refresh rate..but uh..yeah..y'know. Or you can disable pixel rounding and use high quality fullscreen scaling..but then your graphics move on "sub-pixels" and you risk seams as well.

shinkan Yeah I strongly disagree with Ashley on that one. For example, if you're using a separate object for an enemy's collisions, then you must code both objects to work in perfect harmony which can be a real pain at times, especially when dealing with multiple instances. Suddenly you end up having to do things like set & compare ID's or use containers, position the enemy to the collision object, give the collision object behaviors and variables instead of the enemy itself, make sure both exist or don't exist together, put them in separate families so one does this and the other does that. Then do you use one collision object for every enemy, or do you make a new one for each enemy? I mean they will have different behaviors and variables and properties so...

All of that can be avoided by simply giving the enemy an additional collision mask. One to handle collisions with the environment, and another to handle interaction with other objects.

This is how Super Smash Bros. handles collisions/hitboxes/hurtboxes http://youtu.be/tonqj4rkjIU?t=1m17s

I can't imagine doing anything like that with the tools we have now. With Spriter, maybe, but not C2's standard toolset.

Multiple collision polys would be great for everything, not just fighting games. For example you can have a platformer where enemies have a simple box poly for good collisions with the environment, then a more elaborate one for interacting with your player and such. No code, extra objects, or containers required.