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.

Game Design Log - Entry #10

Right, supposed to be doing a log thing...

So, motion is pretty much done now. I've got gravity as you'd have on the moon, and the lander itself is using numbers from the Apollo lander for it's mass and engine power. The only thing I don't have is limited fuel, because I couldn't wrap my head around that particular equation...

Using the numbers from the Apollo is interesting, because the engine is throttle-able to a point where(at least as I'm using it), you're at 40% throttle before you can even push the mass of the lander. I'm not sure if this is something I'm doing wrong or if that's actually how it's supposed to be, but I need to work on other things. It's workable, and as long as I include something on the HUD to show the the amount of thrust you'll actually be producing, it should be fine...

Speaking of HUDs! I realized that I can just draw strings on top of the game, and it'll work. I'm actually using this for debug purposes, currently showing the lander's rotation, throttle level, and potential delta-V with the throttle at that level.

Next up is graphics. I've taken to calling this "rocketbox" for now, as that's basically what it is. I'm just drawing a box on the screen showing where the rocket is at the moment. Doesn't rotate or anything(Hence why I have the rotation shown in the debug HUD)... So yeah. That's what I'm looking into at the moment. Currently looking into an array of points, and what can be done with that... If my thinking's right, I can do vector-like graphics, and get graphics and collisions with the same array of points. We'll see how that goes.

Game Design Log - Entry #9

AHAHAHAHAHA! SUCCESS!

I took a break from Thrust calculations for the last day or two, and skipped ahead a bit to actually adjusting the trajectory with the results from the thrust calculations... Kinda backwards, but I wasn't getting anywhere with the thrust stuff.

After spending a day and a half going in circles trying to figure out what I was doing wrong(Believe it or not, all the references I could find online were wrong in some way...), I finally asked a friend, and we found two problems. One, I had the wrong operation in one place(I needed ArcTan/Atan/Tan-1, and I had Tan), and two, I was putting it into my calculator wrong.

In my LanderMotion structure, which contains just about everything relating to the motion of my Lander(How about that name, eh?), I'm storing things as polar coordinates. I didn't know that they were polar coordinates when I was setting up my structure, but now I do and that's what they are. Now, I had never worked with polar coordinates before, just cartesian. Polar coordinates, to me, seem better suited for things like this, as you're applying force in specific directions and amounts, which is exactly what polar coordinates are, direction and magnitude.

The fun part came when I got to adding multiples of these forces together. There's three forces acting on the course of the lander -- momentum, gravity, and the engine. Gravity is always in the same direction, down, and for this game will stay constant through one "game". The engine is variable -- You can change your rotation, and the throttle of the engine. Momentum is variable -- It's the result of your previous motion, and is also what the result of your trajectory calculation is calculating.

Now, to get the net result of these forces, you simply add them together. "Simply". Anyways, to add these vectors together, you have to convert each one to cartesian coordinates, add all the cartesian coordinates together, and then convert it back to polar coordinates. Converting polar coordinates to rectangular coordinates is easy, and I had actually already been doing it in my ballistic trajectory stuff(Which I just realized is horrible misnamed in my game as it stands... It's not gravity at all...). Let's walk through it real quick.

For a given vector, there's two components to the polar coordinates for it, the radius and the polar angle. The vector we're going to work with has a radius of 15 and a polar angle of 180. To convert this to Cartesian coordinates takes two calculations, one for each the X and Y axis.
To calculate the X axis, take the cosine of your polar angle, and multiply it by the radius.
To calculate the Y axis, take the sine of your polar angle, and multiple it by the radius.

Easy, no? The part I had problems with was going the other way, cartesian to polar. This is more difficult, and the best way that I can think of to show it is to link to the code that I ended up with.

See here, starting at line 69.

Rtheta is the polar angle, Rmag is the radius, Rx is the cartesian X coordinate of the rectangular coordinates you're converting, and Ry is the cartesian Y coordinate.

Quite a bit more complicated, no? After I got help and figured out what was going wrong with my calculations, this got cranked out in less than half an hour, but I spent just about two days going 'round in circles on the 'net.


So things are moving along. Next up's back to thrust calculations. Also, I should have mentioned before now... My code's being put in a Git repository, accessible at http://code.meldaire.net/lunarlander. Not much to look at yet, but it's very much a work in progress.

Game Design Log - Entry #8

I spent a lot of time today beating my head up against a wall, trying to figure out the equation for delta-V. Turns out I had been missing the unit on one of the sub-equations the entire time, and was misinterpreting "ln"(loge) for "1n"... Now that I've got that figured out, I think I'm almost done with the "motion" part... Hopefully.

Game Design Log - Entry #7

So I finally felt comfortable enough with how it would work in my head to actually start programming it, and I found out that I was missing quite a few pieces of the math involved.

I think I've got it mostly figured out again, but I've spent a lot of time just reading through all this stuff making sure I'm not missing any other big pieces. Little progress has been made on actually writing code, so far.

Game Design Log - Entry #6

I've spent the last week arguing with myself over how to lay out my classes... I've got a good idea of how things should work in the end, but C# doesn't seem to let me lay things out the way I want.

For collision detection, I want to be able to get everything as close as possible as far as function calls for checking whether things collide. I have a feeling there's a way to do what I want, I just don't know how to do it. With C++, I could do this with multiple inheritance, and have a "Lander" class inherit both my "sprite" and "gravityObject" classes. C# doesn't have multiple inheritance, though. I don't want to have objects of the "sprite" and "gravityObject" classes inside my "Lander" object, 'cus then I'd have to do lander.sprite.rect.intersectsWith(), which would be different from all the other calls to intersectsWith()...

Maybe I'm just being too picky.

Game Design Log - Entry #5

I've been doing some more looking into what I can get to with C#. The display's DPI doesn't seem to be one of them, so I can't set my scale that way. If I can't do it that way, that leaves me two options that I can think of.

The first option is to set a static scale. For example, 1 pixel equaling 1 meter. This makes sprites rather difficult, though. The Apollo's lander module was 5.5 meters tall. That'd put a similar sprite at 5.5 pixels tall. 1 pixel = 0.5 meter would get me an even 11 pixels, but that's still a tiny sprite. The next "easy" step is 1 pixel = 0.1 meter... 55 pixels tall. 7% of the height of my screen(1366x768). Acceptable, I think.

Assuming a 1024x768 screen, this gives us 102.4m(252 feet) vertically and 76.8m(336 feet) horizontally to work with. More than enough, I think.

I need to actually start implementing this, now, I think. I've got enough that I can start laying out my functions, even if I can't completely fill them in yet.

Game Design Log - Entry #4

All about Gravity

For the purposes of this game, gravity is a constant force pulling you down at a given speed. This will affect both your trajectory and your velocity. If your trajectory is anything but straight up and down, gravity will alter your trajectory until it's straight down. If your trajectory is taking you "down", gravity will increase your velocity, until you reach terminal velocity. If your trajectory is taking you "up", gravity will subtract from your velocity until it is 0, or your trajectory is taking you "down".

Earth's gravity pulls you down at 9.81m/s^2. To gain any altitude, you need to supply enough thrust to be able to push more than your craft's mass straight up. Should be as simple as calculating the force of gravity pulling you down(9.8m/s^2 * mass?), and subtracting it from the force of the rocket upwards(Which will either be a static number or scale based on how long it's been on). Fairly simple for straight up and down.

The tricky part comes when you add in horizontal movement... I believe you'll only need four 'major' variables, though. If I'm correct, you'll need to track the rotation of your craft, the force provided by your rocket, your current heading, and your current velocity. From your current heading and velocity, assuming no intervention of the player firing of the rocket, you should be able to calculate where you would move in the next game tick. THIS should be sufficient, I think...

If the player /does/ fire the rocket, though, things get more interesting... I'm not sure of the math involved, but you'll be altering the current heading and velocity based on that math and the ship's rotation and rocket's thrust.

Still have a lot of reading to do to get a complete understanding of this, but it's getting closer...

Game Design Log - Entry #3

I've been trying to sleep for the past hour, but things keep coming to mind... Figure I should write them down before I lose them.

Physics is the name of the game for the Lunar Lander game I'm making. It needs to work well, and (to my mind) it needs to be accurate. This is going to take at least a few things, that I can think of.

First up, I want/need it to have a consistent scale. I remember seeing something about DPI while poking around in C# earlier. If I can get the DPI of the screen the program is running on, I can set a scale(Say 1 inch = 10 meters), and have it generate the movement offsets based on that to always have 1 inch be 10 meters. So long as I have a consistent way to get to this, it should work without too much trouble.

Next up, ballistic trajectories and thrust. This is going to be the difficult one. With my rudimentary knowledge of physics, getting this right is going to be interesting. I'll need to set a mass for my ship, and the amount of thrust that my thrusters will provide(Possibly factoring in a "spool up" time to get up to full thrust), and do all sorts of math that I'll have to research based on those to be able to get my trajectory for which direction to move and how far in a given timeframe. So long as I set a framerate that it can keep up with, and base my math on that framerate, this should be doable. So far my experiments have been running at ~58 FPS, which means I'll need to set up my trajectory math to come out with meters per second divided by 58. Ideally I'd figure out how to set up the framerate so that it works out what that particular computer can handle dynamically, but I doubt I'll get to that.

I'll need to keep track of what angle I'm moving at(degrees) and what speed I'm moving at(m/s, probably), as well as which direction the ship is facing(degrees). If I do a spool-up time for the thruster, I'll also need to keep track of how long the thruster has been on(Probably in ticks, not seconds).

These are the major things that have been going through my head as I try to sleep tonight. Now that I've got it written down, I'm going to go try to sleep again...

Game Design Log - Entry #2

Over the weekend, I've mostly been reading through some of the example C# code, familiarizing myself with the language.

The Lunar Lander/Solar Jetman game is still the "major" idea in my head. Depending on how difficult it ends up being to have my player-controlled sprite collide with a dynamically generated line, I think I've mostly got randomly generated levels figured out... I'll have to do some math/experimenting and figure out ranges for everything, but I think it's doable.

As for everything else in the game...

Graphics shouldn't be too hard. Since I'm wanting to do randomly generated levels, I'm probably going to go with a wireframe look for most of it. That'll make drawing the ground easy.

Music... I'll need to play around with it, see if I can come up with something fitting. Chiptunes, if I can manage it. Thinking along the lines of VVVVVV for music.

There'll only be a few sound effects, that I can think of. Your engine firing, your ship exploding, opening/closing the airlock, and an "item get" sound...

Gravity's going to be fun. If I'm doing randomly generated levels, I might be able to have the gravity randomly generated, too. I'd need a HUD to display the amount of gravity, so that it didn't seem "odd" that the controls were different every time you loaded it up... I'll need it for fuel anyways, though. Maybe score, too.

I'm not sure what to do in the way of disk access. A high-score leaderboard is all I can really think of, if I can figure out a way to score it...

Mostly thinking out loud again, but I think I'm getting closer to nailing it down.

Game Design Log - Entry #1

Hope nobody minds -- I'm gonna take a sidestep on this blog for a while. I'm taking a "Game Programming/Design" class at the local college this quarter, and part of it is keeping a log of what I'm doing for the game we're supposed to be making. I figure my blog's as good a place as any, and people might comment on it and help refine some ideas.

The assignment for the first week is to come up with some ideas for the game we'd like to make. So far, I've got two ideas. The first is a platformer of some sort. Been done to death, but it does cover a good deal of the "basics" of designing a game. This particular idea hasn't been fleshed out much.

The other idea I've got is a mix of "Lunar Lander" and a little bit of a platformer. You have to land your ship on the "moon", then get out of the ship and go gather a few things(Artifacts that have been located on the moon, ship parts... Something.), then return to your ship and take off again. Kinda like Pikmin, only without the pikmin.

This second idea is the one that keeps coming back to me, and is probably the one I'm going to end up going with. It needs some more work(What is it you're retrieving, and why... Where are you going when you take off again(Which brings with it, what happens after you take off again)... I know there's other questions that need to be answered, but those are the ones that immediately come to mind.), but I think it could make for a decent project.

It would need gravity(Landing/taking off, jumping), collision detection(Landing/crashing, collecting items, possibly spikes or something after you've left the ship...), might be able to work in a random number generator for level creation(Probably not for the "surface" segment, but for the landing segment it's definitely possible)...

This is mostly just thinking "out loud". This will become more and more detailed as I go on, probably.

Anyways. This is Entry #1, on 4/4/2012, right around noon.

Light Strike Technicalities, Part 2 - ITS

So yeah. Picked up some ITSs a few days ago, and finally got around to capturing the signals they send out. Let's get to it.

Mode	Decoded signal
ITS, Blue team, Sentry mode	00000111000000000000111100001000
ITS, Red team, Sentry mode	00000100000000000000111100001000
ITS, Yellow team, Sentry mode	00000101000000000000111100001000
ITS, Green team, Sentry mode	00000110000000000000111100001000

Not much interesting going on in Sentry mode.

Mode	Decoded signal
ITS, Blue team, Bomb mode	00000111000000010000111000011000
	00000111000000100000111000011000
ITS, Red team, Bomb mode	00000100000000110000111000011000
ITS, Blue team, Bomb mode	00000111000001000000111000011000
	00000111000001010000111000011000
	00000111000001100000111000011000
	00000111000010000000111000011000
	00000111000010010000111000011000
	00000111000010100000111000011000
	00000111000010110000111000011000
	00000111000011000000111000011000
	00000111000011010000111000011000
	00000111000011100000111000011000
	00000111000011110000111000011000
	00000111000100000000111000011000

There's something interesting going on with Bomb mode that I don't understand.
Look closely. It's counting how many times it's been activated.
There's no way to see this on the tagger. It's a previously unused section of the shot signal. It doesn't reset when a different team activates it. What were they planning with this? I can't come up with anything...

Mode	Decoded signal
ITS, Blue team, Medic mode	000001110000000000000110000000100<SYNC>00001000000000000000100000000111
	000001110000000000000110000000100<SYNC>00001000000000000000100000000111
ITS, Red team, Medic mode	000001000000000000000110000000100<SYNC>00001000000000000000100000000100

Here's another interesting one. The part before the <SYNC> is the shot that activates the medic. The part after is the medic's response.
Look closely at it. Here, I'll even copy it around for you so you can see it easier...

Red team, Laser Strike	000001000000000000000110000000100
ITS, Red team, Medic mode	00001000000000000000100000000100

That's right. The medic's response is one bit shorter. I captured it a couple times to make sure.

I can tell that the last part of the medic response is the team that it's healing. The rest of it's a mystery, as it doesn't match the rest of the stuff I've seen.

I'm curious to poke around with some of those unused high-end bits, now. If setting the bit that the medic uses up there can let the tagger recognize a shorter packet, I wonder what else is hidden up there...

Light Strike: A Breakdown, Part 2

So it turns out that I ended up getting some of the other Light Strike accessories. While cleaning out the local stores of the targets(We figured that at $4, the parts in them would probably make them good for mod fodder), we saw the "Intelligent Targeting System" for a whole $4.50 and picked up a pair of them. These will probably become something interesting down the road, though they're going to be fun building a new board for... These things are crazy on the inside.

But anyways. This device is intended to add some variety to the gameplay. It can be set to one of three modes, Sentry, Bomb, or Medic.

Each of these modes starts out about the same. You pick the mode with a three-position switch, and turn the device on with another. At this point, the device is on in the mode you picked. If any one team shoots the device five times in succession, it becomes captured for whichever team shot it those fives times, with varying effects depending on the mode.

In medic mode, after you capture it, every time you shoot it after that will cause any teammates in the device's cone of fire to gain health. In bomb mode, shooting it after you've captured it will, after a short countdown to "arm" the bomb, cause the device to spin and shoot anybody that is not on the team that has captured it for a short time. In sentry mode, after you have shot it the fifth time, it will start spinning and shooting at anybody not on the team that captured it. Any opposing team can shoot it four times to make it neutral again, and then shoot it another five times to capture it for their team.

In addition to the mode and power switches, there's a volume switch, a rotation speed switch, and a button. The two switches should be rather self-explanatory, and the button lets you choose whether the device is always rotating, or only in the cases mentioned before.

All in all, this is a neat little device. It'd be neat to have the sentry mode set up in your base from the get-go, guarding a flag... Though I think at that point, it would devolve into more of a "Flush out the people keeping the sentry active" than anything else... This might get turned into a sentry for LTTO, once the new gear comes out, since they're bringing back IFF beacons(And with a vengeance this time!)...

I'll probably have info on the signals it sends later.

Battle Tag, In Memoriam

Battle Tag was brought up in a recent conversation, so I figured I would write up what I liked and didn't like about it, as I did with Light Strike, before I forget everything about it. I've never owned any of this gear, but I did sit down with it for a few hours last year, long enough to run it through it's paces.

Battle Tag was yet another newcomer's foray into laser tag, this time by Ubisoft. Announced at E3 in 2010, this system was billed as more of a "shooter come to life" than a laser tag system, but most of us saw it for what it was.

The base Battle Tag set included two taggers(Called "T-Blasters"), two sensor vests, two ammo packs, two "bases", a "UbiConnect", and an installation CD.

Design

The actual design of these taggers is quite good. The blasters feel good in your hand, and don't feel like they're going to break. The sensor vests are comfortable, though I question where they had the wire come out to attach to the blaster. The connection between the vest and the tagger did seem a bit flimsy, and I seem to remember hearing that it was easy to break that connector.

Tagger Details

As I remember it, there were two major buttons on the tagger, a trigger and a button on the back that cycles your display through it's different displays. There is a third one on the bottom of the barrel, but that's not intended to be pressed by hand. As I said before, this tagger feels good in your hand, and it looks rather good, too. There is a display on the rear, which shows your health and remaining ammo by default, if I remember correctly.

The display is rather clunky, as it relies on a few icons to tell you what it's displaying, rather than text. It took me a while to figure out what it was actually displaying, and even then it was not easy to just glance down at it and see what it was showing me.

These taggers also look to have been designed to be expandable, though no expansions were actually released or advertised. The black "shell" of the tagger comes off(Push it forward), revealing a... 6-pin, I believe it was, port. I didn't own the gear I was experimenting with, so I didn't feel comfortable putting an oscilloscope on it to see what was there, but my guess is that this was intended for expansions down the road.

Sensor Vest Details

There is no sensor on the gun, unless I'm not remembering correctly. This system is reliant upon an external sensor vest, which connects to the bottom of the tagger. The computer will remind you to plug in the vest if you try to start a game without it plugged in, and will not let you start the game until all the vests are plugged in. This is a nice feature, and it shows that they were thinking in the right direction of doing their best to prevent cheating.

These sensor vests are comfortable. A lot of different people were trying them out when I was playing with them, and I don't think it didn't fit on anybody. I don't have a good picture of it handy, but it goes "around" one arm, across the back, and over the other shoulder and snaps back into itself. The vest felt secure, and didn't limit my range of motion very much, if at all.

These vests also give a decent amount of feedback to the person shooting you, as well. Each of the...four, I think, sensors has red lights in it that light up when you get hit. I don't remember if it was just the sensor that got hit that lit up, or all of them, but the lighting up was easy to see, and it was quite nice to know when you were actually hitting somebody.

Unfortunately, the actual sensors on this vest are rather disappointing. While they have very good coverage, and you can take a hit from almost any direction, the range at which you can take a hit is dismal. In the shade, you can get 100-200 feet, depending on how well you can aim(Did I mention that the taggers don't have any sights?). Step out into the sun, however, and you're lucky to take a hit from 20 feet. This might have been a fluke, but it did not bode well, to me.

Ammo Packs and Bases

These are some of my favorite features of this system. Included in the starter set is two "Ammo Pack"s and two "Base"s. Your tagger can only carry a limited amount of ammo, which I believe was configurable. After that runs out, you have to find an ammo pack, and swipe it across a button on the bottom of the barrel on the tagger. The taggers include an RFID reader behind that button, and the ammo packs have an RFID tag in them. Swiping the ammo pack refills your ammo, and if I remember correctly, you can set it up so that you have to alternate between different ammo packs, or you can only use each one once. This feature is REALLY cool, in my opinion.

The Base works much the same way as the Ammo Pack, except I don't remember what they do. Sorry, this is the problem with doing a review almost a year after having played with the gear. :)

Software and UbiConnect

These taggers are designed to be used with a computer. So much so that they're useless without one. Included in the starter set is a ring-shaped "UbiConnect", which connects to your computer via a USB port. This is a radio transceiver, and each tagger communicates with it constantly throughout the game. This is one of the biggest limitations of this system, as you have to stay in range of the UbiConnect throughout the entirety of the game. If you wander out of range, you've got approximately 5 seconds to get back in range before it drops your tagger from the game with no way back in. And the range is not very large(Approximately 200 feet, if I remember correctly), especially for people like me, who are used to wandering far and wide to come up behind people and catch them unaware.

That said, the software is rather nice. You can assign a name to each tagger, and configure how much health and ammo you have, and there are several different game types included. During the game, the computer/software plays a steady stream of audio clips telling you things about the game(Including telling players that haven't shot or been shot lately to get moving, which I found great), and shows the current score on the screen, as well as an event log of who's shot who, and who's used the ammo pack/bases lately. All in all, the software's pretty neat, and rather pretty while it's doing it.

There is one other problem with the software or the UbiConnect(I'm not sure which one is the limitation). You're limited to 8 players per game. I'm not sure how many teams it handled, but there was a hard limit of 8 players total per game. Compared to LTTO's hosted-game limit of 24 players, and almost any system's non-hosted unlimited players, this is quite a small game.
Behind the scenes, if you dig into the software a bit, you find that each game mode is controlled by a lua script that looks to get uploaded to each tagger. Unfortunately, it looks abstracted enough that there's not a whole lot that you can do, and the actual scoring is handled by something that I didn't find while I was looking. But still, it's rather neat that they're uploading a script to the gun which actually controls how it works during that particular game.

Final summary

Things I liked:

• Real-time scoreboard
• Computer connectivity
• Ammo packs/bases
• Being able to take a hit from any direction
• Good feedback when you hit somebody

Things I didn't like:

• Tagging range
• The display on the tagger
• Very little leeway in going out of range of the UbiConnect
• Having to stay in range of the UbiConnect
• 8 player limit

Similar to Light Strike, this system had some neat ideas, but had enough problems in it's implementation that it just wasn't feasible for the majority of people that are really interested in playing laser tag. I loved the computer connectivity for setting up and scoring games. I didn't like how it dropped you from the game if you strayed out of range for more than a few seconds. In a system like this, there's no reason why the tagger could not be functional, if even only at a basic level(Say, sending and receiving tags. Need to use an ammo pack? Head back to radio range.), when out of range of the UbiConnect. I can see that they wanted the real-time scoreboard, but it would not have been hard to buffer the major events into the tagger's memory and transmit them later when it comes back into range. Somewhat more complicated, yes, but in my opinion, they would have had a much better product for only being slightly more expensive.

This system seems to have met it's demise already, though it never really made it fully to market. They did a "soft launch" in a few test markets as well as online, and it never made it farther than that. Their forums and website have gone down, and it is no longer available in their online store.

This is another system I would have liked to see do well. We really do need more competition in the laser tag market, and UbiSoft had some good, new ideas with this system. They just fell a bit short of the mark, unfortunately.

Light Strike Technicalities

Since I have the Light Strike gear, I decided to do some poking around with the signals it sends. Using the OpenBench Logic Sniffer, a 38kHz IR receiver, and a 5V power supply, I captured most of the combinations of team and weapon. What follows is a dump of my notes while I was at it.

---

Seems to use the off time for data, rather than the on time, as all "on" pulses other than the initial sync one are the same length(880uS).
I'm guessing that the 880uS off-times represent a 0, and the 3300uS off-times represent a 1. Seems like an odd rate to be sending stuff at...
Has a 6780uS "sync" pulse at the start, launches immediately into data.
Looks to be capable of carrying 32 bits of data.

Going by the above guesses, "default" shot(Blue team, Laser Strike) decodes to 0b00000111000000000000010100000010, in the order it's transmitted in.

Decodes following above guesses.
Orange rifle:

Team/weapon	Data
Blue team, Laser Strike	00000111000000000000010100000010
Blue team, Stealth Strike	00000111000000000000011000000010
Blue team, Pulse Strike	00000111000000000000011100000011
Blue team, Rail Strike	00000111000000000000100000000110
Blue team, Sonic Strike	00000111000000000000100100001000
Red team, Laser Strike	00000100000000000000010100000010
Red team, Stealth Strike	00000100000000000000011000000010
Red team, Pulse Strike	00000100000000000000011100000011
Red team, Rail Strike	00000100000000000000100000000110
Red team, Sonic Strike	00000100000000000000100100001000
Yellow team, Laser Strike	00000101000000000000010100000010
Yellow team, Stealth Strike	00000101000000000000011000000010
Yellow team, Pulse Strike	00000101000000000000011100000011
Yellow team, Rail Strike	00000101000000000000100000000110
Yellow team, Sonic Strike	00000101000000000000100100001000
Green team, Laser Strike	00000110000000000000010100000010

Though not completed decoding all team/shot combinations, I'm fairly certain that bits 7 and 8(Starting at 1, on the left) are the team, 21-24 are the weapon ID(Or something related to the weapon used), and bits 29-32 are the weapon damage or something else related to the weapon used.

29-32 does not make sense as a weapon ID, as both the Laser Strike and the Stealth Strike would have the same ID.
Seems rather strange to have two different weapons do the same damage, though... Maybe the stealth strike takes more ammo instead, to balance it out?

I'm guessing bits 1-6 are something related to what "type" of thing is sending the signal. All of my shots seem to be 0b000001 in those spots. Actually, let me grab the other style...

Yellow rifle:

Team/weapon	Data
Blue team, Laser Strike	00000111000000000000010100000010

Nope. Doesn't identify which tagger sent it. Could still differentiate between pistol/rifle, though. Don't have any pistols to test this.

Might pick up some of the accessories at some point to look at those signals. There's still a lot of bits unaccounted for.

---

All in all, they looked to be planning quite a ways ahead with their protocol. A good chunk of the data it's sending isn't accounted for in the shot signals, so there's probably a lot of capabilities hidden away. This further reinforces my thought that WowWee could have been a real competitor, had they put a better sensor setup on their tagger.

Light Strike: A Breakdown

NOTE: My camera seems to have gone missing, so there's no pictures in here. I'll go back and add them when I can...

I picked up a pair of Light Strike rifles this week on clearance, the orange one(G.A.R.-023) and the yellow one(S.R.-143). Though it may be on it's way out, now, I would like to go through this gear feature-by-feature, in an attempt to set the record straight, as I've heard a lot of conflicting stuff about this gear.

Light Strike was designed and built by WowWee Group Limited, who also made the PaperJamz line of paper/plastic guitars. These laser tag units quite obviously follow the same paper/plastic design.

To give a bit of my background, and to show what bias I might have, I have been playing with Hasbro/STM's LTTO line for... 6 or 7 years now, I think. I love most of the many features the LTTO line offers, and that gear has set my standard for both outdoor range and features.

//Put picture of both rifles and sensors here

Impressions of the Light Strike rifles (before batteries)

• This stuff is built well. While obviously plastic-looking, they are quite solid-feeling, with very little flex or give anywhere.

• The accessory slot covers look to be well-designed, and don't feel like they're going to snap off or get stuck.

• The battery cover is a bit difficult, as if you don't make sure it's straight, it is entirely possible to tighten down one screw and not be able to screw in the other one.

Ergonomics

• Orange rifle: While obviously designed for smaller hands than mine, this rifle is quite comfortable. It also has a nice weight to it. Though not exactly "heavy", it not really light, either. I haven't actually been running around with this, but having fiddled with it for a few hours, I didn't notice anything particularly uncomfortable about the design.

• Yellow rifle: After only a few minutes of playing with this one, the bumps on the back of the grip were digging into my hand. I didn't spend much time with this rifle, as the grip hurt enough that I wouldn't want to use it for more than a few minutes. //Put picture of yellow handle here

Now, before I get much farther, I should note that there are three different pistols and three different rifles in the Light Strike lineup, one pistol and one rifle of each of three colors(red, orange and yellow). Most of my experience with this gear is with the orange rifle, but so far as I can tell, all the functionality is the same between the three varieties of rifle, just the button layout and sounds are different.

Buttons and switches

As I said before, there's three rifles in the lineup, each with it's own sounds and button layouts. The actual buttons are the same, they're just in different spots. Each rifle has a power switch, a trigger, a reload button, and six "touch-sensitive" buttons that control various functions.

//Picture of touch panel on both

As you can see, there is a "shield" button, a "weapon select" button, a "single/rapid" button, a "volume" button, a "team" button, and "fingerprint"/"I.D. Scanner" button. I'll go through these one by one.

Shield

The shields on these units is quite a bit different, compared to what I'm used to from the LTTO line. These shields, you press the button once, and for the next 15 seconds or so, you take half damage from enemy fire. After those 15 seconds are up, your shields turn off and take about 3 minutes to regenerate before you can use them again. You cannot turn your shields off early, but you can still shoot while your shields are on, so this isn't really a problem, unless you think you might need your shields again fairly soon.

While this is quite a bit different from what I'm used to, I do like the way it works. You're not completely immune, but you're not helpless, either.

Weapon Select

One of my favorite features of this line, is the fact that each tagger functions as not one, but five different weapons. Pressing this button will cycle you through five different weapons, each one having unique sounds, refire rate, damage amounts, ammo usage, and some of them do not allow switching between "semi-auto" and "single fire" modes(Which is covered in the "Single/Rapid" button section).

The five weapons are Laser Strike, Stealth Strike, Pulse Strike, Rail Strike, and Sonic Strike. I don't have any numbers for any of these, as the manual is very on details. I will take quotes from the manuals to describe these.

Laser Strike is your default weapon. It doesn't have much firepower but it blasts super fast.
Stealth Strike is similar to laser strike but its muffled blasts let you sneak up on enemies.
Pulse Strike packs more punch. It's best in semi-auto mode but uses ammo faster and has a longer delay between blasts.
Rail Strike has a ton of firepower but goes through ammo fast and has a longer delay between blasts.
Sonic Strike is the biggest weapon in your arsenal but goes through ammo quickly and has the longest delay between blasts.

All of these weapons share the same ammo bin, so you can't use up the ammo on one and then switch to another to keep shooting. I think the idea here is that all of these are energy weapons, and you're using the same battery until it runs out. Not a bad way of doing it, really.

Single/Rapid

This button is...strange, to say the least. If the weapon you have select allows it(The Rail Strike and Sonic Strike don't), this button lets you switch between "Semi-Auto" and "Single Fire" firing modes. Only these names really don't make sense. "Single Fire" is more akin to full-automatic, in that if you hold the trigger down, it will keep firing until it runs out of ammo. "Semi-Auto" is a three-round burst, followed by a delay, and this pattern repeats for as long as you hold the button down until you run out of ammo.

Ignoring this odd terminology, the button itself seems rather pointless. Your ammo bins are large enough that you can keep up full-auto("Single Fire") for about 5-6 seconds with the Laser Strike/Stealth Strike, and reloading takes about 2 seconds. I can't think of any situation where you would really need/want to slow down your firing with the "Semi-Auto"/three round burst mode.

I'm going to chalk this one up as part of the gimmick side of these.

Volume

This cycles the volume level of your tagger through three levels. Not a whole lot more to say, really. You can't turn the sound all the way off with this button, but there is also a headphone jack on the rear end of the gun which will turn off the audio to the speakers. I like the ability to use headphones with the tagger, though I question the fact that they mention doing this in the manual to "use your tagger in stealth mode"...

I can't say that LTTO doesn't fall into the same trap, though. Though the LTTO manual doesn't outright suggest using the ability to turn off the volume to hide, you can turn the sound off by holding one of the buttons. I will admit that I myself have used this to my advantage in some games, though it is typically frowned upon if/when it comes to light.

Team

//Picture of front panels with various team colors

There are four teams available in the Light Strike gear, Blue, Red, Yellow, and Green. Holding this button down for a few seconds at any point in the game will move you to the next team in the cycle, changing the color of the front several light panels to the color of your team.

No, there's no limitation on this. If I remember correctly, it was even noticed in the commercials for Light Strike that at least one player switched sides mid-game to be on the winning team in the end... While I like the method of identifying teams with the color panels, there REALLY needs to be limitations on when you can change sides. This is one place where I'm of the opinion that either everybody should be able to shoot everybody, or the teams are pre-set and once the game starts, cannot be changed.

While this could be set in place by the group that's playing's rules, I have dealt with many people who care much more about winning than they do about playing fair to trust this method of changing teams.

"Fingerprint"/"I.D. Scanner"

The thing I love about this button is that you never have to train it whose fingerprints are allowed and whose aren't. When you first turn the unit on, it will make a little powering-up noise, and then sit there cycling all the lights through various colors. If you press any button besides volume or the "Fingerprint scanner", it beeps at you and tells you "Fingerprint required". Once you press this button, your tagger is ready to go. Once your tagger is armed, you never use this button until you turn the tagger off and on again. This is entirely a gimmick button, and serves no other purpose.

Trigger, reload, power switch

There's not much to say about these, so I'll just combine them into one section.

The trigger is rather nice. You pull it back part of the way, and there is a nice resistance just before the button actually engages. The orange rifle has a much weaker resistance before that final click than the yellow rifle, but it's still there.

The reload button is a long button on the button of the tagger. The one on the yellow rifle has a bad habit of the rear-most end getting stuck pushed down due to the shape of the button and the case around it, but the orange rifle's button works well.

The power switch is on the top of the tagger. The orange rifle has it recessed at an angle in a dip in the case, and the yellow one has it sticking straight out the top of it. The orange one seems like it would be somewhat difficult to flip accidentally, and the yellow one seems stiff enough that I don't think you're likely to flip it if you did bump it.

Transmitters/Receivers

A very important part of a laser tag unit is how well it can send and receive tag signals from other taggers.

Light Strike is rather disappointing in the receiving aspect. It has only a single sensor built into the gun, and it's in the very tip of the barrel, facing forwards. Try as I might, I could not get them to take a hit from the side or rear.

As for transmitting, I don't have a particularly accurate measurement, but I would guess that I was starting to have problems hitting the other tagger at about 150 feet away, as the sun was setting behind the tagger I was shooting at.

This is not a particularly bad range, but having come from the LTTO gear which gets 300-400 feet in broad daylight, it's not a particularly good range, either.

Lights

//Picture of lit-up taggers, blue team

There are a lot of lights on these taggers. While each variety of tagger has it's own arrangement of them, they each have nine lights.

Three of them are treated as the "barrel" of the weapon, lighting up in the color of your team when idle, flashing when you shoot, and lighting up in the color of them that shot you when you get hit. These ones are blue in the picture, but as I said, change to show which team you are on.

Three of them are used to show how much ammo you have left, with a solid bar being 1/3 of a magazine/clip, and a flashing bar being somewhere between 0/3 and 1/3. These ones are always green.

The last three show your health, in the same manner as the ammo ones do. These ones are always red. When you run out of health, it plays a sound, you can no longer shoot, and your tagger starts flashing in a rainbow of colors. It's really easy to get back into the game, though. Hold the shield button down and pull the trigger, and you're back in the game. It plays a sound when you do this, but it's rather quiet. Nowhere near loud enough to let other players hear that you respawned. Both Laser Challenge and LTTO make it quite obvious when you respawn, with a very loud sound, and a 10-second audible countdown, respectively.

Sounds

There are also a lot of sounds on these taggers. There are three taggers. Each one has a different voice for it's spoken things, such as weapon names, the fact that it "recognized" your "fingerprint", when you turn your shield on, when it runs out, and when it regenerates, and the names of the two firing modes.

The actual weapon sounds are the same across the taggers, though I didn't realize it at first. The yellow rifle seems to have better audio quality, as the bass in the Rail Strike shot sound is much more noticeable. Whether intentional or not, these slight variations in sound quality did make me think for a while that each variety had unique sounds for everything. It would be neat if they did.

Accessories

The only accessories I have for these taggers is the "SOUND FX TARGET" that each rifle came with, which does nothing more than light up with the color of the team it was shot with and play a hit sound. Other than target practice, the only way I can think of to use these would be to buy a few extras for each player(They were $10 each, I think, before they went on sale? I might be wrong on that, I didn't really keep track of them.), and rig up a harness on each player. If an enemy managed to light up all of a player's targets in their color, you either join their team or are tagged out of the game. This would rely entirely on the honor system, however.

There are many other accessories for this line of taggers, but I don't think I'll be putting any more money into these, so you will have to look elsewhere for how those change the system.

I do know that there was another sensor setup that was a vest that you "paired" with your tagger, which turned off the sensor in your tagger and the vest took over the health-tracking. This might handle taking hits from the side/rear better, but there's a major problem with this: it was sold separately for $40. $50 for the rifle and another $40 for a sensor vest to be able to take hits from any direction other than straight ahead? And then you realize that you need a second pair for a second player... This system would get expensive fast.

Summary

Usable range: ~150 feet
Cheatability: Medium-High
Would I buy more: No.

Things I like, in no particular order:

1. The lights. Nice and obvious which team you're on, and it lights up which team you were just shot by. It tells you what you need to know, without being too explicit about it.
   
2. The fact that there's three varieties of rifle/pistol. While they're functionally the same, the bit of variety they add to the choice of taggers is rather nice. And you get your choice of grip styles, too.
3. The design of the orange rifle. I like the feel of the orange rifle. If I ever gut these for putting other taggers into, I'd do it with the orange rifle, not the yellow one.
4. The fact that it is expandable. Though I didn't put any money into the accessories, I like the fact that it does have the capability for it.
5. The "multiple weapons in one" idea. This is something I've been thinking about how to accomplish in my "dream laser tag" system that I've been writing down ideas for for a year or two now, and they pulled it off rather nicely.
   

Things I didn't like, in no particular order:

1. How easy it is to switch teams mid-game. I have dealt with many people trying to cheat their way out of losing fairly, and this system makes it entirely too easy for them to do it and not get caught.
2. The design of the yellow rifle. The grip is quite uncomfortable, even for short periods, to me. There are odd protrusions on it that dig into your hand that make holding the weight of the tagger hurt.
3. There only being one sensor on the front of the tagger. I come from a system that has a sensor dome on the tagger that allows almost 360-degree coverage. Only being able to take hits from the front just doesn't cut it for me.
4. The firing modes. The names don't make any sense, and there's no reason to switch between them anyways.
5. The "fingerprint" scanner. The only other thing you can do when you first turn the tagger on is change the volume. Why not just throw people straight into the game? It's not going to change much of anything except reduce your cost a little bit.
6. The layouts of the touch-sensitive buttons. I don't mind that they're different between varieties of taggers. I do mind that they're all impossible to use without looking at them. The firing mode button on the orange rifle is just above the trigger, but you can't quite bend your thumb up far enough to touch it.

Final comments:
With a few refinements, I really think WowWee could have a much better contender for the laser tag market. A better sensor setup in the tagger itself, the elimination of a few mostly useless buttons, and a better layout for the buttons, and I would have no problems seeing this as a viable step between the advanced features of the LTTO line and the bare-bones system that is Laser Challenge.

The sensor setup is the major one, to me. It shouldn't have cost more than a dollar or so to add a pair of sensors, one on either side, and it would be more than good enough as a step up from Laser Challenge.