"Has anyone thought to use near field tags in games?" Topic

It's a just a thought. they could be used to reveal surprise elements of scenario, so when a unit reaches places x then the tag is used to store and reveal what happens next, reinforcements arrive from the east or units hidden in place x are revealed.

or maybe other things. At the moment we use the tags when we use out phone to pay for something, I have a friend or has one stuck on the washing machine which sends his wife a text message each time he puts a load on.

They're cheap to buy and easy to programme

amzn.to/2UK4Qm5

link

Computer-moderated rules could do that so you could say what unit attacked what, for example. But it wouldn't help with distance and situations on the battle field.

andy

Cool idea

Maybe pop one of the flexible NFC tags inside a 28mm flag and write the units stats and org structure onto it. No more looking stuff up in tables or markers.

Could create an app that updates the stats as the unit takes casualties etc. Again remove markers.from the table

So these are little chips that can be read by an app on a phone or tablet?

So if I put one on a unit, I can program it to show the unit's stats etc. when I hover a phone over it? Seems a pretty complicated way to ID a unit that can easily be done by, for example, something on the base. Also, how do you re-program these once they are in place? My miniatures are used in more than one game/rule set.

As for putting it on the battlefield, could be kinda cool. But not sure how it improves things? Example: when a unit comes within 3" of location X it is ambushed by the local tribe.

So you need to mark X with something. Could be a tree with a note on the bottom, or a tree with a chip. Not sure how reading the chip with a phone really enanhces the game more than a note?

Maybe I'd need to see a good application in practice, but right now it looks like a solution in search of a problem.

@extra crispy – that could be the case, it's an idle thought

- you could put them on units with a programme that says bring up the stats for this unit and allows you to update casualties etc.

I could see them as an alternative dungeon master? You wave your phone over the tag and it offers a random selection of things to move the scenario on>

I know we do all these things very well as people mind!

link

link

Yes, you can erase and reprogram.

NFC is only 3 inches? Correct me if i'm wrong.

rather limited lifespan, though.

Passive rfid have about a 20 year lifespan.
The range a phone picks one up will vary a bit. The limited range is because they are un powered. Your phone powers them via an induction loop.

A common memory size is 504 bytes.
Iirc write once can be cheaper.

Which might sound limiting.
You could just store a unique key such as a guid on each. Use that to look up the data for your game.
Xxx is a pz4h one game and an m3 the next.

I suppose they're potentially less intrusive than a barcode or qi code.

One of the problems with computer moderated tabletop gaming is double entry. You need to tell the computer where everything is. If you had a table with scenery and units all labelled with unique ids and some way of locating them you reduce or maybe eliminate double entry. Maybe nfc chips could be one part of a solution.

Projecting terrain and units to something like hololens still seems more likely to be practical though. Setting aside things like costs etc

A better approach would be to tag your figures and write a url to the tag. Then the app that reads them would be directed to open said page.

So you could change the contents of the pages on the software side. A unit – mysite. com / unit000. htm – could have green stats one game and veteran stats another.

With a little more effort, you could program dynamic behavior into the unit f'r'ex, two hours into the game this unit goes to zero move for a mechanical failure; roll 1d6 and input the answer (or have the page roll) to set the time to repair.

If you wanted to have things dependent on rounds rather than time, you would need a way to input round changes into the system. The best way would be to have a round counter, where you hit a button on the "controller" phone and it advances the round counter that all the pages use. If you have the "controller" application also do something related to the round change, like establish turn order within the round, then it is not an extraneous step.

interesting thinking, thank you. NFC are being incorprate in printed paper – so flags with a tag in them?

I wonder if the cameras and tags used for motion capture could solve the where are units on the table issue? In which case they could also have info about the units coded into them. (meaning nfc doesn't add anything)

You don't need the tags to do image processing to track troops along the tabletop. Since you are taking known entities within a known fixed space and doing known fixed things with them, this is a closed-form image processing problem.

I dislike the "easy .. hard" continuum because difficulty is really a multidimensional thing. Usually, I think we can get away expressing (what I term) the major two dimensions: complexity and level of effort. So processing the image of a wargame tabletop and locating all the units – and why not dice while we're at it – (presumably to feed to an AR app for players or possibly an automated adjudication system) is complexity low, level of effort high.

Lots of grunt work, but not lots of figuring things out.

Depending on how well your figures blend with the tabletop, it will take more or less effort to train a clustering algorithm to find and identify them. (Dice are easy on both fronts, even QILS dice.) This will also drive the minimum resolution (pixels, colour depth) camera you need. I doubt you could find a digital camera today that couldn't handle the speed requirement

One of the other bits you would want is the LOE cost of putting the camera overhead. Otherwise, the tool you are building will have the same "I forgot about those guys behind the building" problem as players.

The biggest part of the overhead work would be slogging through training the cluster algorithm to recognize the troops across the desired presentation set. Orientation may or may not cost a lot of work (LOE for this is also lessened by putting the camera overhead). Effort for dealing with contrasting with different terrain types would be fairly variable relative to the nature of your terrain and figures.

So as you change terrain tables, you may or may not have to retrain the algorithm. This is where the low level complexity comes in … knowing for this set of minis and this set of terrain whether or not you have to retrain the algorithm.

Another bit of this issue is that training for say 10 troop types and 10 terrain types creates billions of combinations. You don't have to train for every possible combination, but the bigger the state space, the bigger the training load. But if you know these 3 will only be used with 4 terrain types, the next 4 with 6 of them, and the last 3 with only 3 of them, the aggregate performance space is much, much smaller. Ten and ten are probably very, very low numbers, so figuring out how to optimize your performance space by subdividing the possibilities could become moderately complex.

Overall, I would say your NFC idea is a more elegant overall solution.

If you are the kind of nerd who would enjoy setting up the image recognition approach (I am) and would consider the training aspects fun Zen work instead of drudgery, it would be fine.

Or you could hire people to build it for you.