What type is b?  I don't know.  It could be any type that it convertible to bool, OR it could be any type for which operator == is defined for bool.  It could even be a type with both, in that case, which one takes precedence?  What actually happens here?

This is a good point, but what you are (unwittingly?) doing here is making a case against various ill-advised features of C++.

<applause> 

Jitter can be very tricky to remove. It arises naturally from the use of quantized time in the physics model. Try reducing the bounciness of your objects, maybe?

Try comparing a boolean to true or false in a job interview and you'll get laughed out of the room.  That is extremely bad form.  Not having to do that is the whole point behind a boolean data type.

If I saw someone had done that I'd most likely hire them (unless there was something wrong with the rest of their code). It may be less elegant than using the boolean value directly in the test, but at least it deviates from that in the direction of increased clarity. That's a good fault to have.

You know this + my true = false debacle is making me look pretty stupid.  It's like I'm FIVE YEARS OLD.

Not at all. Five year olds are extremely alert and don't make those kinds of errors much. It's more like you're 105.

I tried just making all images scale 2x, but the game ran extremely slow... I have no idea why

It's because Flash is clever.

<pause for comic effect>

No, really! The thing is, whenever some particular rendering feature is available but isn't being used, Flash switches it off for efficiency. Scaling is one such feature. Setting the scaling to x1 is a lot more efficient than x2 (assuming no rotation) because it doesn't need to calculate pixel contents at all, it can just copy them.

(That said, I wouldn't expect extremely slow, but it may be something to do with your machine's power level or the way you've implemented your game.)

Also, because someone has to say it: there are typically a hundred people with game ideas or basic art skills for every one competent programmer. For this reason they can be quite hard to find!

My number one tip for going commercial would be to make sure you're not relying on the income you hope your game will generate. That way if it underperforms you can learn from the experience and come back and hopefully succeed with a subsequent game.

Flash games do need hundreds of thousands of hits to make money, but that's not actually very much. If you can't write a Flash title at least that successful you'll be in for a hard time in the commercial PC downloadables market and probably won't be able to get onto XBLA or Wiiware at all.

That's not to say you should pick Flash. Pick what you're good at. And good luck!

Possibly I'm just confused, but that doesn't seem like the same thing. Flint is using the filter to fade every pixel, not just the particles themselves.

There may be a better way to do it, but I'd expect performing a per-pixel operation on your entire visible region to be at least somewhat slow. 100ups may be rather optimistic unless you're working with a small screen size or there's not much else going on.

[.exe]

Action application/x-httpd-php "/php/php.exe"

Really? Are you sure you mean ".exe" there? Or is your server running some sort of Windows OS? (Apache-based servers are typically running Linux, where the ".exe" extension is never used.)

@Xion - That monster slaying picture is superb!

Now if only I could get it to parse the parameters individually as arguments rather than as a single array...

Try using Function.apply().

However I'd like to point out that compromising game quality for file size is unacceptable.

Maybe for downloadable games, but where Flash games played on websites are concerned a 50MB game would be excessive. It would annoy most players and could cost you significant amounts for hosting bandwidth if you got a decent number of hits.

But still, what do you all think?

Top-middle girl appears to have a banana stapled to her ear! Other than that, all good. I particularly like the facial expression top-left dude is sporting. He means to make trouble, I have no doubt!

There needs to be another node in the middle labelled "OMG, this looks completely impossible!". Or is it just me?

And as a piece of general advice: never believe what you read in a Flash thread without checking it for yourself, particularly people telling you things are slow and/or not supported!

With respect to masks, Flash in fact contains very powerful general-purpose masking support for vector graphics in the form of the mask property of DisplayObject.

Is it slow? Only if you think vector graphics in general are slow, which of course they are compared to manipulating BitmapData directly... but then they don't do the same thing, so you should use each technique only where appropriate.

Also it can run a SWF as a server, which might simplify development of your game logic.

That's a pretty interesting feature. Not so much for simplifying game logic, but because it makes it easier to adapt the game to run on the server if you want to support serious competitive play.

This depends if Flash loads the whole resource because of the Class definition (using "[Embed]..MyAsset:Class", or if it just does so when calling "new MyAsset".

Although in the case of "new MyAsset" you have to think about where it might be getting the data from. Supposing we're talking about something like an image then the data will be in memory whether or not anything creates an instance. The only way to avoid this is for it not to be downloaded until it's needed, which you can't do with resources embedded in a SWF (hence "embedded"). (There is a sort of exception in that you can embed stuff in later frames which aren't downloaded until they "play", since Flash is a streaming format... but that's not generally useful for games.)

If you were going for a smaller-scale flash thing, I would suggest looking into Stratus, which doesn't require XML stuff.

Good tip, thanks!

I was assuming I'd have to run my own RTMFP service to use client-to-client, but apparently not assuming this system stays free after beta. Hurrah!

Sorry to be a douchebag but... isn't XML-over-sockets a bit blunt? Maybe a more compact transfer could be beneficial.

You're not being a douchebag at all, it's a reasonable point.

But no, it doesn't actually cause problems. Network speed issues are all due to latency, not data volumes. Which is just as well, since Flash only supports XML sockets. (You could probably roll your own almost-binary format if you cared enough... I certainly don't need it.)

Recently I've been playing around with a side-project which involves multiplayer gameplay. I felt like implementing the system I proposed in this thread, partly because I was intrigued by how smooth Street Fighter IV's online play is and wanted to see how close I could get to that. (Answer: quite close!)

Anyway, back to the plot... I've been using Palabre as my socket server. Apart from being virtually undocumented it works pretty well. The trouble is I'm running into some problems which I'd really rather not solve on such an experimental system (like, for example, zombie player logins). If I tried to do so I'd soon find myself up to my ears in socket server code and spending weeks on it. For a side project, that's not really OK.

So I thought it would be worth asking here: is anyone aware of a Flash socket server that Just Works (TM)? Doesn't have to be completely free, so long as it's affordable. Doesn't need to scale to tens of thousands of players, but should be capable of handling hundreds. (PS. Don't just go and Google search right now and post the results here. Not helpful!)

Failing that, is anyone here any good with Palabre?