That's exactly what the autotile behavior does.

I've used it in some of my project - it works great, and it's hassle free!

No support for it in the arcade though.

1,2,5 are good, ditch 3 and 4

Forget md5, that algorithm has been abandoned. Even sha1 - vastly superior to md5 - is considered "weak".

md5 should only be used for legacy purposes, and you should NEVER implement security unless you're absolutely sure of what you're talking about. Even though I have the required expertise to build a fairly secure scoring system, this is exactly the kind of stuff better left to Ashley.

Ashley, are you sure it's a bug?

If a family uses a behavior, and then an object in that family uses the same behavior, only the one behavior should be added, and the parameters of the instance (in other words, the more specific) should override the parameters of the family - I think this gives enormous flexibility that's very hard to achieve otherwise!

Unless of course that's what you mean by "fixed".

My turret behavior has exactly that. If you don't mind using third party plugins, it can be a great way to achieve that without thinking too much or complicating your code, and it can be added to multiple instances.

check it out

You should post this in the "website issues" forum.

That's even better than my method.

something must be wrong on your end, I'm getting a solid 60 FPS and my computer is nearly 6 years old.

I'm also on a 64 bits win7 ultimate

It's actually pretty easy if you stop to think about it.

The guy is checking the distance from each object to a master object, therefore he gets a circle, since they're 300 pixels away from a point in every direction.

Your case is even more straightforward: instead of checking for distance, check whether objects are within a set of X and Y coordinates.

for instance, object's X position is greater than 0, less than 640, and it's Y position is greater than 0 and less than 480, you just covered a 640x480 rectangle in the top-left corner.

Easy isn't it? Rectangles and circles are the easy part, it gets a lot more complex once your area is some weird concave irregular polygon, but it appears you won't be needing that.

If you're planning to make a CCG, I advise you to move the card images away from the client. Leave the UI, the card outlines, effects and that stuff in construct, but try to create an engine that is flexible enough to be able to download and interpret new card mechanics, display new card images, and make a cache system using localstorage.

This gets you two benefits: players don't have to download cards they don't use, and you can keep adding cards without forcing players to redownload the whole game.

If you do implement downloadable card mechanics (attributes, skills, effects, cost, whatever), make sure to build in some sort of cheat detection/prevention system - hell, you'll have to implement it either way.

Kyatric, there's no mention of "UDP" or even "datagram" in that spec, there's only a mysterious "reliability mode" flag on the connection, and no explanation given regarding what it does.

In addition, we can see that the working draft in 2008 was discussing UDP, including registering ports for it, but it seems strangely missing from the current draft. Where are the discussions happening? Why was support dropped? Why did chrome suddenly drop it's own experimental extension (the only thing that had UDP support)?

I don't see game devs making noise regarding this stuff. The HTML5 standard gets thinner and thinner, and comments like this make me lose a bit of faith on the future of multiplayer with HTML5 - will we have to wait 10 years like the flash guys?

I mean, it's either that or resorting to evil black magic (suck as coercing your javascript to interact with a udp java applet).

As for your method of "kicking the user out" when he/she switches tabs, I could do that, but what if my game had to transmit a fair bit of state before he could join?

This would mean that people couldn't even alt-tab to check an instant message, or answer a skype call, since a minimized window counts as "suspended" - I can't expect anyone to take my game seriously if I say "this game is played in 30 minute sessions - do not minimize or switch tabs at any time during gameplay or you will be disconnected" - it just doesn't work like that, especially considering that some events may force your window to minimize.

And I'm not even touching the issue of the additional overhead of having to create the rejoin code, which is non-trivial.

I used juantar's excellent plugin (based off Zack0Wack0's) to create my prototype, and also followed juantar's tutorial to make my node.js server.

It was very disappointing because I was getting huge lag spikes and desyncs in localhost, with only two players in separate windows, and it's not an issue with my server code or my logic, since I redid the prototype in MMF2 (while keeping the server written in node.js). The lag issues there were still present, although a lot less due to it being raw TCP sockets instead of websockets. I was able to compensate for lag with some dead reckoning in MMF, and the game appeared to be completely playable even with ~300 ms latency once I put in UDP.

Construct is a lot more enjoyable to work with, especially since you can hook up debuggers and inspect traffic flow without having to resort to wireshark, and the fact that you can jump straight into the code (thanks to the SDK) if you need something more complex.

The issues don't appear to be construct's fault, though I have a slight feeling that socket.io "message received" events either aren't triggers (I haven't checked) or triggers are affected by chrome's policy of slowing down inactive tabs.

In any case, multiplayer of any kind seems like a no-go in HTML5, since even having a window pop-up in front of chrome causes it to suspend your thread and make the player lose sync.

Artillery claims to have made a playable air-hockey game, which would be ideal, however they seem to have ran into the same issues regarding the lack of UDP support. Researching the web I've found some people who claim to have solved the problem by round-robing two, three or more instances of web-socket objects to prevent the entire game from choking on a lost packet, but so far I've seen no working examples.

If anyone has any comments on the issue such as success stories, links to further resources, research papers, prototypes or even wild ideas, I'd be happy to hear them.