I’ve decided that whenever I come up with a game design that I know there’s no chance in hell will ever get made, I’ll throw that idea up here, in order to prove how awesome I am.
In this case I also get to prove what I’ve long complained about: I come up with every good idea about 5 days before someone else does.
It was around August of 2007 that I was walking my dogs and I said: to myself “Lego MMO.” Then, I burped. Then, the design below sprung into my head. It was kinda painful.
5 days later, NetDevil announced that they were making that game. When I heard about it, I fell to my knees and cursed the heavens – which got me some odd looks at work.
But of course I was frustrated – they weren’t doing the most interesting part of my design, which so far as I can tell is substantially different from theirs (and of course, infinitely more awesome)!
Here Is My Awesome Design
The elevator pitch: “Webkinz meets ‘Banjo-Kazooie: Nuts and Bolts’ meets MMO meets Lego”. Here’s the design that makes that sound less like a train wreck of unrelated ideas:
- Special (physical) Lego bricks would be manufactured. They would have tiny microchips inside them; these microchips would hold an identifier of what kind of brick it was, and could also be able to connect to other such microchips. The bricks would have tiny electric connections on all the places on the piece where that piece could connect with other pieces (e.g. on the pegs of a brick, and on the slots on the bottom of a brick where pegs fit in).
- A special piece of equipment would be packaged with the game: a USB connector that had a standard Lego peg on it, and could thereby be connected onto any Lego piece.
- So. Let’s say you buy these special Lego pieces, and you then build a spaceship out of them. Then you buy our game; you can simply set that spaceship next to your computer and plug the USB piece onto it, and the other end into your computer. Special software then sends a signal to the USB piece, which queries the microchip on the piece you plug it into, which then queries all of the pieces that it’s connected to, and so on, recursively building a data tree of every single piece type used in the spaceship and where they are connected to each other!
- This information is sent to the computer, which recreates the spaceship on the screen with virtual bricks! Every piece is replicated, and in its proper place, in your software. You can view the spaceship in 3D, perhaps even modifying its color (charging for ‘paint buckets’ seems it might be good Microtransaction material).
- And now, here’s the part that’s so awesome it will blow your eyeballs clean out of your face. Some of the pieces (say, a spaceship engine piece) are functional in the game world! If it has an engine piece on it, then the spaceship can actually fly around. If it has a laser piece on it, then you can actually fire lasers. And it’s all in a true physics engine – the weight of the pieces, the center-of-gravity, etc. will all have a huge impact on the movement and handling of your ship! All very similar to Banjo-Kazooie: Nuts & Bolts – if that game was an MMO, and let you actually have a physical copy of your creations!
It looks like the actual Lego MMO might be doing some of #5, though I’m skeptical. As Jesse Schell pointed out in his Dice 2010 talk (which I finally watched yesterday, and found that it was very interesting up until the very end, which was oddly the part everyone talked about), people are currently extremely “into” virtual elements that have a solid real-world connection: WebKinz, the physical guitars in Guitar Hero, etc. This game has that in spades. I played with Legos a ton as a kid – and there’s nothing I would have enjoyed more than finishing my awesome little creation, walking over to my computer, plugging it in, and actually playing with it in a game world, where suddenly it could fly around, the lasers actually fired, etc.
And of course financially speaking, this design is incredible because there are about a billion ways to make money from it. Don’t have a piece in the real-world? Buy it in-game. Making people pay for individual virtual Lego bricks is like a corporate wet-dream, right?
Oh, of course I’m a little sketchy on what you can actually do with this stuff in-game. Actually upon reflection the game doesn’t even need to be an MMO, though I would say that making it multiplayer in some way that allows you to play with your friends is incredibly important. (That would also help with “time to cock” issue that would be so prevalent in a kids’ game with user-created content.) In fact, this could actually be a Wii game that used friend codes… can you imagine flying your self-created spaceship around by holding up your Wiimote like a paper airplane and tilting it this way and that? That’s even more of the kinetic, real-world element that kids would love.
As you can see this design is a bit “hazy at the edges” and starting to become a bit vague – because I’m not going to take the time to think it all out, because it will never be made. But though the edges are hazy, the core is solid – I’m sure a great game could be made around this core idea. It’s a game I would have killed to play as a kid, or even now for that matter. Too bad it will never be made!
2 Comments
Interesting ideas. A few questions: how would the pieces be able to tell orientations? I suppose if each top-connector and bottom-connector for each lego were enumerated, you could determine the orientation through some matrix math. With a single point-of entry, the USB key, how do you handle the exponential number of messages coming from the furthest-away blocks? can you “traverse” the tree, or send messages to a specific block? If you have this framework, it seems like a very short distance to lego objects that build, replicate, modify themselves, given they can find lego pieces to “consume”.
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.
Good questions Jer!
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!