Random Blaster from Amazon

Last week sometime, Jammer found an Amazon listing for a blaster by Simply Addictive Games, that they're calling CALL OF LIFE. It looked suspiciously similar to the Lightstrike gear of days-gone-by, and I bought a pair of them to sate my curiosity.

Advertised setup:

• 4 weapons in each blaster with different sounds/damage amounts
• 4 teams, no friendly fire
• Single sensor, facing forward

They came in today, and it really looks like this is a heavily cost-reduced version of another product, whether it was Lightstrike or something else. There's a transparent piece on the top side of the blaster where they could have put additional sensors, and a floating piece on the back of the top with a fake display that was probably originally supposed to be a real LCD.

They don't exactly promise much, but they do deliver on the features they talk about, and there's also a rumble motor that gets used when firing and I assume when you get hit that they don't mention on the Amazon listing.

Now, onto the juicy protocol details!

Despite looking suspiciously like a Lightstrike recase, it's got an incompatible protocol.

Probably a bit hard to see in there, but it looks like there's five different time increments involved in this protocol. There's a ~1.65ms SYNC pulse, and then different long and short pulses for the active and inactive side of each cycle after that. It looks like both the active and inactive sides are used for data.

SYNC: 1.65ms
Inactive short: 0.33ms
Inactive long: 0.73ms
Active short: 0.45ms
Active long: 0.85ms

I don't actually know what the tolerance of these signals is, so I'm just cutting it off at hundredths of milliseconds after averaging a bunch of the various timings I see in the signals I captured.

I'm going to assume that both of the "shorts" are 0s, and both of the "longs" are 1s.

So decoding the various shots this way, you get...

Blue team, pistol: SYNC/00000000 10101010 00000001 00000001 00000110
Blue team, shotgun: SYNC/00000000 10101010 00000001 00000010 00000111
Blue team, submachine gun: SYNC/00000000 10101010 00000001 00000010 00000111
Blue team, missile launcher: SYNC/00000000 10101010 00000001 00000011 00001000

Green team, pistol: SYNC/00000000 10101010 00000011 00000001 00001000

Red team, pistol: SYNC/00000000 10101010 00000010 00000001 00000111

White team, pistol: SYNC/00000000 10101010 00000100 00000001 00001001

I didn't do an exhaustive capture of every combination, but I think this is enough to pull out the pattern.

The 5th byte looks like a checksum. 3rd and 4th bytes added together plus 0x04 looks to match these examples. The 1st and 2nd bytes are probably just extra syncing stuff, though it's odd that they don't have any examples of the active long pulse in there for clock adjustment. 3rd byte looks to be team, 4th byte looks to be weapon type.

Seems simple enough. The high nibble of the 3rd and 4th bytes could hide more features, but I'm going to guess at the moment that they don't. Maybe at some point I'll poke at it some, and see if I can generate some oddball signatures to throw at it.

Second hand stores

I love going through second hand stores. I find all sorts of neat trinkets and toys from years ago. Most recently, I found a Skannerz toy, from sometime in 2000. Still works, and it even had batteries in it.

I got to playing with this, and I got to thinking... Nothing really similar has been done lately, to my knowledge. With smartphones booming, the majority of them including cameras, there's no reason you couldn't do everything this toy does and more with the hardware that people are already carrying around.

And so an idea was born. I love when this happens.

I know there's barcode reader apps out there for Android, and if I remember correctly, you can take advantage of those apps from other apps. So I don't even need to write the barcode reader side of things. That's a huge portion of the work gone, right there.

So now we need a way to get a monster out of an arbitrary barcode. The first thing that came to mind is just using the numbers in the barcode itself. But then I remembered that those barcode reader apps also do QR codes, and NFC tags are starting to become more common. So we need a way to do it from not just an arbitrary barcode, but an arbitrary string, of arbitrary length and content.

New plan. Hash whatever data we get, so we get a fixed length and a fixed set of characters, and then use that hash to do your monster generation. Easy enough. MD5 has a fixed length, and is hexadecimal, and has been around long enough that there's implementations is pretty much every programming language out there.

Now, we need a way to get a monster out of that hash. MD5 isn't collision proof, but for what we're doing, it might as well be. This means we can't just use the raw MD5 hash to say "hey, this is monster". We need a way to make collisions happen. So we start dividing up the hash.

The easiest way to do this is to just grab specific characters and look at those. But that still leaves us with way too much room to work with in some ways, and not enough in others. My current thinking is that I'll grab a few bytes(MD5 results in 16 bytes. I'm thinking groups of four.), add those bytes together, and modulo 256 that result. This gives us much smaller numbers, and gives us a few "fields".

I'm thinking the first field would be a "type" or "group"(Or "expansion set") thing, so you could have different groups of monsters, items, etc.. Second field would be which actual item/monster that one is. Third field could be a "variation"(Think shiny pokemon). Fourth field could be a seed for a random number generator, for battle stats and things like that. This gives you room for expansion, down the road.

The problem here is that same expandability, though. The way I see it, there's two options here. You either leave a good chunk of hashes useless at the start(If you managed to fill out 64 full groups, you're still only using a quarter of all possible hashes out there. That's a lot of failed scans.), or you start out "wrapping" the hashes, and when you expand it later, some of your previous scans no longer lead to the same thing...

I don't really like either of these options. The first one leads you to a lot of failed scans(That using 64 full groups example? That's 16,384 items/monsters.), and the second one leads to confusion when you release the expansions, 'cus all these barcodes people had found don't necessarily point to the same thing anymore.

One option is to reduce your expandability, so there's less failed scans. This is probably a good idea, 'cus I really don't think you're going to use 65k item/monster slots(Even pokemon hasn't gotten that far yet). But there's still the problem of not maintaining a consistent successful scan rate, or causing confusion when all your barcodes change meaning with new expansions...

This is where I'm at at the moment. I'll need to think on this more.

Back to Tag

I haven't posted much here lately, but things have been happening.

TagFest came and went, and with it the first public hands-on(Well, second. That one was under an informal non-disclosure agreement, though, so not exactly public.) with the shiny new LTAR.

While there, we got to play with the first 12 production-model LTARs off the production line. It was a blast.

While others have already posted their thoughts on this tagger before, I'd like to put mine out there as another set of datapoints.

Game Design Log - Entry #14 - Final

Got the highscore stuff done. When you land successfully, if you beat the best time, it says "New highscore!". If you didn't, it shows you what the best time is. Either way, it shows you your time.

This isn't exactly fair, though, as the random terrain generation lets you just keep going until you get one that's straight down and not very far from your starting point. But, it'll work.

The code is at http://code.meldaire.net/lunarlander. I don't have the current version up at the moment, but when I get home, I'll make sure and push it up there.

Game Design Log - Entry #13

Whoops. Forgot about this again...

The game is functional now. It generates a random landscape(Which is guaranteed to have a flat section on it), starts you in the top center of the screen, and lets you have at it. When it sees that the ground is within a 1-pixel boundary of your lander, it runs a bunch of checks to see if you can land successfully at that moment. If yes, you win. If no, it changes the lander graphic to an explosion, plays an explosion sound, and you lose.

The only requirement I haven't met is disk access. I'm not familiar enough with C# to do things the way I want to, and I haven't had the time this last week to familiarize myself with the bits I need. Or think I need, anyways.

Attached is a scan of the explosion graphic.

Game Design Log - Entry #12

The last few weeks have been crazy. I've started work on several projects in addition to what I'm doing for school, and a lot of stuff has been going on besides that... But, things are still progressing with the game, and I think I'm in the home stretch now.

The current state of the game is that most of the "required" things are there. The controls work, there's enough feedback from the HUD to be able to finish the game(As soon as the game can be finished, anyways), and I've got a working way to detect when I hit the ground.

All that's left(I think) is to do the game logic for when I hit the ground, a few graphics tweaks(Have it show something when the engine is firing, an explosion when you crash), some kind of options thing when you start it up, so you can change difficulty stuff... And I think that's it.

Of those, the only one that seems even remotely difficult at the moment is the options thing. Mostly because I have no idea how to work with multiple forms. We'll see if that happens.

Game Design Log - Entry #11

Today, so far, has been spent playing with GraphicsPaths. I've got my Lander designed, and all the points plotted, and put into an array of points, which then gets added to a GraphicsPath. I can draw this path, and as far as I can tell looks correct. The only problem is, it's tiny. Oh, and I haven't figured out how to move it around the screen yet.

There's functions of the GraphicsPath class that lets you apply transformations to the path, but I haven't quite figured out how they work yet. Once I get that going, I should be able to resize it to be more easily visible. It might also let me move it around the screen.

Attached is a scan of me sketching the lander, and plotting out the path to draw it.