Hopefully this should be an immediately obvious problem, since the presumably-important callback code simply won’t be executed. But the fact that this can happen so easily (from a simple typo), and results in a hit to performance every frame, as well as a small hit to memory… well it’s not ideal.

I suppose the best solution would be to provide an additional parameters, of how many frames to keep waiting for, which would default to something like 10 and which could be set to -1 to wait forever. Maybe someday I’ll make this addition, and work it into MovieClip.prototype as Krilnon suggested, and post the code (and working examples, a gotoAndPlayAndThen copy of it… etc). When I have time.

Will have to look into it more, but so far it does sound like it might be an even cleaner way to do this. Thanks for the tip!

For instance, the iPhone. Flight Control was my game of 2009, straight up. Added it to the list.

Which reminds me that my game of 2005 would probably be similarly surprising for some: Urban Dead, a browser-based MMO. What can I say, it was an extremely fun, surprisingly addictive text-based MMO based almost entirely around PvP of some form, and in which you could roleplay a zombie. How is that not awesome? Added it.

(I never came close to finishing Ico, though I know I really should – in any case I don’t feel like I can honestly put it on my list.)

Of course the biggest “risk factor” of the design would be the question of whether these “bricks that talk to each other” is even technically possible, and then whether it’s financially viable. As I’m actually not an expert on microchip technology, I have no idea whether or not that would be the case.

But in theory it’s certainly sound. Each brick contains a chip that identifies itself (probably a unique GUID for that particular brick, as well as an ID for what type of brick it is); and which can also connect to every possible connector on the brick. (On a standard 2×4 brick, it would have 16 connections: the 8 pegs on top, and the 8 possible places where pegs can fit on the bottom.) The USB piece could connect to any of these and perform a “ping”; this would cause the brick in question to send a simple “identity ping” to all 16 of its connections; the connected bricks would then identify themselves with an ID that both uniquely identified that particular brick AND defined what type of brick it was. Finally this first brick would send back a ping response that would contain its own ID; and, for each of its active connections, the ID of the connected brick (as well as which connection on that brick mapped to this connection). E.g. “I am brick ‘2_4_12345′, my peg #1 is connected to brick ‘2_4_00012′ on its slot #9.”

Then it would do a “full ping” of all the bricks that it was connected to; they would do the same query and send it back, and the original brick would pass it along. Most likely we would need one more piece of functionality for each brick-chip: each distinct “ping” (initiated by the USB device) should have its own ID. When a chip gives a full “ping response” as described above, it would save off the ID of this ping; when it was later queried again as part of the same ping, it would remember that it had already responded and wouldn’t respond again.

So the ping would be sent out recursively throughout the entire structure; each brick would be queried, each brick would provide a full set of the data about itself and how it was connected to the other bricks, and each brick would provide that data only once. All of this data would make its way back to the USB device, which would then have all the information it needed on what the lego structure was: the type of each piece, and exactly how each piece was linked up.

I hadn’t thought of using all this to send messages *to* blocks. I know that there are already Lego AI kits and so on. It sounds like you’re suggesting we make it so that the computer can give the lego creation the ability to go find and attach itself to other bricks? That sounds like a whooole ‘nother game.

One idea that I didn’t mention was: what if you mix and match these “smart bricks” with regular lego bricks? The game should probably provide some way to tell the user, “oh, there’s a brick in this structure, but it’s not a smart brick so I can’t tell what it is… can you identify it? Here’s the ones that it seems likely to be based on the physical shape of it I can infer from the bricks it’s connected to.” Of course that’s a lot of extra work for a feature that basically equates to saying “let people play *without* having to buy all the more expensive blocks”, so that feature probably isn’t justifiable on the business side of things.

Yeah, the “porous-ness” of the virtual world and the real world in this idea is definitely interesting. Maybe some of the “smart bricks” can do cool things like light up or make noises (talking about the “physical version” here)… but that functionality isn’t unlocked until you “level up” your in-game creation several times. So as you level-up your spaceship in-game, both the physical and the virtual versions of that structure keep getting cool functionality.

I have no doubt that the “physics” idea would need to have some amount of fudging for the sake of fun; although how much even that would be possible when the user can literally make anything they want!

With a proprioceptive lego set, you might even eschew the video game part entirely and build actual lego “entities” that play with your friends’ entities. The cool thing is, you could actually do game and real-world either separately, together, or meshed, which effectively becomes AR, which would be flippin’ sweet!

Also, I read about the developer’s process with BK:N&B, and they actually had to damp out out the simulations on balance, center-of-gravity, etc. because their primary focus was fun, not fidelity. Food for thought.

… ANYWAY, I should consider cross posting my gameconn.blogspot.com blogs to Gamasutra as well.