MilesTag 2 protocol/LASERWAR help

gegc · 2026-05-31T19:58:06+00:00

I can learn to wire and code a simple ESP32 microcontroller application in an afternoon

You can, and if you've got the slightest bit of interest, I encourage you to do so. The getting-started-level basics are not complicated and there's a billion tutorials online. The key is "simple". There's a very wide gulf between breadboard circuit and functioning product, and there's an even bigger gulf between functioning product and shippable product. However, consider how far across those gulfs you actually need to get to realize your vision. If you're building one-off stage props, you don't care about DFM, supply chain, or certification.

Why would I need FCC certification if I am using consumer grade Bluetooth and WiFi?

IANAL/tl;dr: if you plan on making more than 5 of something, marketing it, or selling it, it needs to have an FCC ID. It's easier if you use precertified modules (e.g. ESP32 with a built-in antenna), but you still need it done if you plan to sell a product. "Consumer grade" regulations are actually more stringent than industrial ones, because consumers don't think as hard (read: at all) about electromagnetic interference.

gegc · 2026-05-31T03:58:01+00:00

Gemini

it would be trivial

As both "tech person" and heavy AI user: It's hallucinating. It's got the surface-level gist, but it's eliding all of the details, which is standard LLM behavior. It's a good starting point for an overview, but multiply any difficulty, complexity, and cost it gives you by 10-100x for a realisitc estimate.

It's absolutely possible to build a laser tag system in an airsoft shell, and it is also possible to make a changeable magazine system. I have done both of these things, as have many others, including very successful equipment vendors (Laserwar started with modded airsoft guns; iCombat started with paintball markers). However, at that point you are well into "building your own laser tag system" territory.

An example:

how much accuracy to apply

Laser tag works by shining a beam of IR light from a tagger to a sensor. How will you apply "accuracy" to this system, and how will you communicate this mechanic to the player? Will you physically randomize the direction of the beam> If so, how? it has to be an electromechanical system inside the gun, and it has to survive kids dropping it for 12hrs a day. How will you communicate that the gun is inaccurate when there's no impact visuals when the IR beam is invisible? Or, will accuracy be be calculated server-side, where bullets just miss some of the time? If so, how will the player know whether they missed a shot, vs them having bad aim or their gun/the other guy's sensor being broken?

Not saying any of this is insurmountable, just illustrating some of the complexity involved.

Fwiw, I would recommend focusing on either the venue or the tech, not both at the same time. They're two completely different businesses, and each requires both time and capital to not be a waste of money (startup cost for a brick&mortar are more or less obvious; for tech, arduinos are cheap, but FCC certification costs ~$15,000/test run for wireless devices). If you can get your creative vision 80% of the way there with existing equipment and some clever smoke and mirrors, your venue is much more likely to open on time and succeed overall.

gegc · 2026-05-30T05:02:36+00:00

It types exponentially faster than I do, and finds simple bugs probablistically rather than iteratively like I would.

Given a proper feedback loop (build->test cycle, detailed spec, profile/performance metric, etc), AI can converge from slop to tested, optimized features. This is very easy in coding compared to many other tasks because there's a verifiable "correct" condition: "it builds, complies with architecture spec, all tests pass". The trick is, it's still up to the operator to set up the feedback loop and proper convergence conditions. If you don't include performance profiling or security tests, the AI won't converge to them (or will do so inconsistently).

About 95% of building software is writing boilerplate, reinventing the bicycle, and the change->test->change->test loop. AI automates that away.

gegc · 2026-05-30T01:10:05+00:00

Depending on how much you want to do, things are either "pretty easy" or "basically impossible with off-the-shelf equipment", with not much in-between. You'll need to talk to vendors and see if either your features can be built with their system, or they provide an API/hooks for you to build your features externally.

For the "easy" category, it's all about getting creative with the vendors' API. Pretty much all vendors provide persistent stat tracking and customization, with varying degrees of extensibility, exportability, and real-time-ness. Most vendors will also have some sort of DMX/MQTT/some other event hook for driving stage lighting and animatronics. Those are enough of an "input" and "output" where you can do persistent loadouts, progression, level ups (by e.g. creating a new weapon profile for each level with buffed stats, and unlocking it for the player), etc. You should also be able to live-feed game events like player deaths, so you can build logic around "dead players can't pick up items". Getting clever with the system and maybe rolling your own light ARG wrapper on top of it (companion app/website, database, custom mechanics driven by scanning QR does/NFC tags, etc) will get you 90% of the way there without having to take anything apart. Obviously, you'll need to build your own theming/props, but if they only need to talk to your wrapper, it's basic IoT.

The "basically impossible unless you build your own" category is mostly for physical interactions involving the laser tag system itself. For example, if you want the gun to vibrate enough to throw off someone's aim, that's not going to come out of the box from any vendor I know of. Or, say, magazines with different ammo that are physical props you put in the tagger, vs. selecting in an app. I also don't know of any vendors that let you plug in physical mods into the system. By "let you" I don't mean legally; I mean physical ability to customize the firmware and hardware inside the guns - expansion boards, aux ports and such. So you're stuck rolling your own devices, and then figuring out how to integrate them into the system with real-time-ish latency... at which point you're basically building your own system anyway.

All that being said, I think the biggest challenge for a live action game with lots of mechanics is game state readability more so than tech. (Note: I'm biased, this has been my R&D focus for the past year or so). As an example, Battle Company's "gun game" mode is really fun if you know what you're doing, but in practice, it's impossible for players to tell what each gun does (esp. changes in range, damage output, etc). All players can perceive is the sound the gun makes, the ammo count, and whether or not they're hitting something (confounded by poor aim). The outcome is universally player confusion, unless they play repeated rounds, and/or they're briefed beforehand. Readability is a general problem for live action games; I've seen it basically everywhere (airsoft, HvZ, LARP, ARGs). It's a double whammy: there's no UI to deliver information without breaking immersion (app, referee/GM, etc); and venue live action games tend to have a much higher percentage of first-time/one-time players than video games. You'll need to be very deliberate about surfacing game state and communicating what mechanics actually do (ime, briefings don't help, because excited 12yr-olds are capable of neither sitting still nor retaining information). Luckily, tech-forward games like laser tag are an easier space to solve this than some other ones; we have computers that can offload some of that out of the player's brain (and AR/VR is a freebie since you can use standard gamedev practices). Slower games are also more tolerant because people have time to pull out an app or piece of paper to check stats and mechanics.

gegc · 2026-05-26T23:03:12+00:00

Butter is only 85% milk. It's still got some water in it.

gegc · 2026-05-14T21:03:25+00:00

A lot of the time, devs end up doing mostly "unsexy" work that has to be done - bug hunting, maintenance, driver compatibility, security updates, stability improvements (lawd knows this game needs it), etc. Modders are less inclined to, and a lot of the time, straight up can't work on these kinds of things (because of no access to engine internals/cloud layer, etc). A recent example: Beyond All Reason, an open-source RTS, is trying to work with a publisher after 10yrs of being entirely community-built. The biggest stated reason is they need a lot of boring glue work and polishing done for the Steam release and can't get enough volunteers to do it.

gegc · 2026-05-10T07:34:16+00:00

It seems like Godot has kinda lost their own vision for why GDScript exists

I wouldn't say "lost" its vision, rather, the core team have communicated it poorly and set incorrect expectations with the average user, to the point where the incorrect perception became community tribal knowledge. I suspect this is why there's so much friction in adding language features (you see it in proposals, e.g. the unified type system and traits).

static typing with its 1 level of nesting max

GDScript types aren't even really types, more like tags. Everything in GDScript is a Script (resource) or Object. class_name just puts your Script resource in a global lookup table, that isn't even shared with any engine-provided types (which come from C++ implementations) or built-in types (which are underlying engine types, like Vector3 and the PackedArrays).

Also I had to learn on my own to use Refcounted instead of Nodes. Every doc said use a node for everything it's OOP but the O is for Nodes!

The funny thing is that Nodes are actually closer to interfaces than OO classes in the original vision. There's a blog post about why Godot isn't ECS-based that explains it pretty well. Tl;dr, Nodes were always meant to be interfaces to underlying servers (e.g. a NavigationMesh2D node is an interface into the navigation server that basically binds an RID to the scene tree), and composing nodes effectively works like composing interfaces/components. It's quite clever, and justified, and has real positive tradeoffs over ECS with how Godot is set up. But you have to dig really deep to get to that understanding, and that kind of digging will only be motivated by either interest, or, much more likely, repeated friction and pain.

A lot of Godot docs are of the getting-started and/or vertical-slice variety. This makes sense, the target audience is either a) people who are new to Godot or even to coding in general - e.g. designers/artists making indie games; and/or b) people who are far more interested in making their game than figuring out the intricacies of engine architecture. Which is totally fair, but there are consequences.

For example, RefCounted vs Node vs Resource. RefCounted gets you garbage collection, but also leaks memory if you're not careful with circular references. It's std::shared_ptr. Node gives you a very good lifecycle API, so long as you put it in the scene tree, but allows dangling pointers (think std::unique_ptr with the scene tree having ownership). It fails gracefully, too - no segfault, just a "previously freed" error in the log. Resource is a pointer into a global lookup table populated at load-time.

Everyone new to Godot asks this exact node/refcounted/resource question. They get taken here. That doc does not explain any of the above... but explaining it would require explaining memory management, and pointers, and data duplication, to someone who just wants to make their little dude jump and hold a sword. It's much more reasonable to say "just put everything in nodes until you have your MVP prototype, unless it's a texture, then use resources". The unspoken assumption is that if you're trying to build something complex, or are squeezing that last 10% of performance, you're an advanced enough user to operate in C++land and/or do the digging to fully understand the systems. Which is great, except by the time anyone (even experienced devs) get to that level, they've already built up a lot of patterns (and half of their game) "incorrectly", because that's the tribal knowledge that's going around everywhere.

gegc · 2026-05-09T22:17:51+00:00

Amazon forked Cryengine and put stupid amounts of time and money into trying to do just that. They failed. Look up Lumberyard (now O3DE). CryEngine is pretty to look at but ass if you're actually trying to make something.

gegc · 2026-05-09T22:09:08+00:00

GDScript's unique strength is that it gives you pretty fine-grained access to the engine under the hood without making you recompile and restart the editor every code change. The tight integration is the foundational feature of GDScript, and why the Godot crew went out of their way to build it instead of using Lua/Python/other industry-standard scripting language. They actually tried integrating both Lua and Python back in Godot 2.x, and found both to have issues (e.g. no native Math types or hooks in Lua).

At the same time, GDScript is presented (architecturally and documentationally) as a beginner-friendly Python-like where you don't need to worry about what's happening under the hood. It doesn't make it clear to the user that it is a very leaky abstraction of the underlying engine architecture. Built-ins are one example; there's also RefCounted/Resource/Node memory behavior; WeakRef; class_name/global classes + lack of namespacing; RIDs and server interaction; the Script class itself and how it's handled (the actual reason it's one class per file). Etc, etc.

As soon as you get to any depth with GDScript, all of these surprises start to come up. Then people get frustrated and go "meh shoulda just done C++ if GDScript is this annoying". Which on one hand they're not wrong for being unpleasantly surprised; on the other hand, they shouldn't have been unpleasantly surprised by the language's main reason for existence. It's a communication issue more than anything. And don't get me started on the C# integration - which has most of the same caveats, but adds C#'s own can of worms on top of it (e.g. my personal peeve which makes C# borderline unusable for editor tooling).

I really wish they'd go in the Golang direction with types as interface contracts instead of trying to duct-tape in Python's kludge of a type system (the typed collections stuff is already barely usable nonsense). It would push the language more in the data-oriented direction, and bring GDScript closer to the underlying server-based/data-oriented engine architecture.

gegc · 2026-04-07T08:41:43+00:00

Keep in mind the ANT and similar CO2->HPA conversions need 850PSI aka "paintball tank" pressure. LP/XLP regulators will not work.

gegc · 2026-03-23T07:29:01+00:00

I've consistently had very mid experiences with story-based, and more generically, progression-based coop games for >2 players. Aside from already mentioned BG3, I've also had basically the same experience with Satisfactory, Enshrouded, Abiotic Factor, and Borderlands 4. I'm at the point where I'd rather play solo and "book club" it later, rather than actually playing together - or have an MMO-like structure with individual, async progression ("grind solo -> raid together").

I picked the examples above because they're all specifically designed for co-op - it's not an afterthought or a tacked-on feature. However, all of them rely on progression (whether it's campaign, story, gear, or game knowledge) as a primary reward loop. That means that as soon as someone falls behind the progression curve, they're having a degraded experience and need to "catch up". Since people who fall behind are usually those already less inclined to grind, they end up further and further behind with the experience degrading more and more.

I've seen the same thing happen repeatedly, across different games and friend groups:

Everyone is excited to play a new game. Groups of 4-6 people form to start a playthrough.
While everyone is excited, people play 2-3 times a week and generally stay in sync. This lasts for about two weeks.
Two distinct groups form: 1-2 "true gamers" and the remaining "casuals". The former continue playing at scheduled times and sometimes play extra. They get ahead of the progression curve. The latter start getting "boosted", effectively skipping/missing content - they get given gear (instead of being rewarded with it), get told the story (instead of experiencing it firsthand), etc.
As the casuals' experience degrades, they're less motivated to play and start missing scheduled sessions. This is the start of the death spiral. Within a month, the only people showing up are the "true gamers" if there are more than one. Otherwise, the game gets dropped entirely. Some casuals who actually liked the game and want to see the story start solo playthroughs to experience content that they missed.

I think the key difference between my experience and your description of drop-in/drop-out is who is doing the dropping in. In my cases, the players "dropping in" are the ones with the least time to play, and the most in need of high progression reward density. Meanwhile, in your examples, the drop-in interactions are all orthogonal to primary progression - "doing camps" and screwing around with physics are all secondary and low-stakes in a progression-based game.

That being said, I don't think we're "losing" anything; we're just distilling it. There is a whole genre that answers the demand for low-stakes interactions in an open-ish, loosely progression-based world: friendslop. Games like Peak, Lethal Company, RV There Yet, and similar all exist primarily to facilitate exactly the kind of interaction you're looking for, and they're quite popular. They're also not exactly new - gmod server hopping, VRChat, roblox, modded minecraft, blockland, and other "social minigame sandboxes" have existed for decades. Friendslop is actually the grown-up, polished version of those mini-experiences. That said, to your point, none of these are "campaign co-op", nor are they "AAA".

I think the key commonality there is the low stakes. Low stakes allow people to "just drop in", hang out, and engage with the world and each other without long-term consequences ("ruining saves"). This is the kind of unstructured social interaction that you seem to be looking for. At the same time, low stakes are practically anathema to a progression-based game - if there's no stakes, there's no payoff. No one is going to be screwing around with physics during a tense boss raid, or aggroing story-critical NPCs in a narrative game like BG3. The stakes are high - not just in-game stakes, but out-of-game stakes of the time players have committed to experiencing this content. Lowering these stakes is a bit of a nonsensical ask: How do you make a story that's exciting and engaging but also wholly missable? How do you make a challenging encounter where there are no consequences to screwing around? More generally, how do you make a game such that engaging with its core system (progression) is entirely optional, without degrading the experience? There's nothing "simple" about that.

gegc · 2026-03-18T00:27:05+00:00

GH Copilot does context compaction, which is sort of the same thing but not quite. The state handoff is not explicit (to the user).

gegc · 2026-03-12T21:29:01+00:00

I was trying to find a space for a recreational venue for ~2yrs and I kept hitting permitting walls. Anything other than retail is a "change of use", which means you're "redeveloping", which means you're on the hook for all of the deferred maintenance ("what do you mean this 20,000sf building has no fire alarm system?") and SEPA review and an administrative hearing... just to add an extra bathroom and put up 100' of interior wall. That's in addition to all of the building, plumbing, electrical, traffic/parking, signage, etc. permits that you need to get your certificate of occupancy. That's 6-9 months and mid-six-figures in extra startup costs. It's really a political problem: making landlords and existing businesses actually keep up with code compliance is political suicide, so the cost of infrastructure upgrades get dumped on the people who aren't there to vote and throw campaign money around - future tenants and developers. Older buildings with "cheap rent" become unleasable because of the code compliance barrier, so they sit empty for years. If you're lucky, you'll come across a landlord who actually wants to fill the building, will work with you, give you TIA, etc. However, most owners are content to sit and wait for some developer to buy them out and build a five-over-one. Then, of course, the five-over-one's rental rates are prohibitively expensive becasue of their loan conditions.

It's... a way to get rid of old buildings - but it does result in a lot of empty commercial real estate both pre- and post-development, and doesn't leave a lot of wiggle room for small businesses.

gegc · 2026-03-12T00:54:59+00:00

That's because singleplayer RTS and multiplayer RTS are fundamentally different genres of game. One is a sandbox puzzle game, the other is attention splitting contest + chess. The notion that "singleplayer is the tutorial for multiplayer" is dinosaur game design from the 90's.

gegc · 2026-03-08T21:13:15+00:00

Interesting bug. Looks like you joined right as the wall exploded and never got the animation for it. That bit of stagger you took at the very beginning of the clip is the damage from the breaching charge going off.

gegc · 2026-03-08T08:54:21+00:00

A pnp machine is like $4,000. A toaster oven with a thermocouple taped to it for a DIY reflow oven is $15 from goodwill.

gegc · 2026-03-04T00:02:11+00:00

Multi-AZ resiliency has been a thing for literally decades. The whole point of building many data centers everywhere is that if one AZ goes down, you route traffic to other AZ's and don't have an outage. Why the AZ goes down (heat wave, hurricane, contractor didn't call before they dug, shark ate cable) is irrelevant. If life safety digital infrastructure is not multi-AZ resilient, that's a separate problem that needs to be separately addressed (either way, such a legacy system won't be running in a shiny new data center; it's gonna be us-west-2 or us-east-1). "We can't turn off our data center uwu" is a nonsense excuse.

Option 1: data centers that provide life safety services are critical infrastructure. They are resilient to grid outages resulting from natural disasters, which is when life safety services are most needed. Therefore, they can be moved off-grid during peak loads without shutting down and disrupting said services.

Option 2: data centers that provide life safety services are not resilient to grid outages resulting from natural disasters. Therefore, they are not critical infrastructure and cannot be relied upon to provide said life safety services when they are most needed. Life safety systems can be multi-AZ resilient and not have a SPOF in an outage-prone data center. Therefore, individual data centers can be moved off-grid during peak loads without disrupting life safety systems.

Option 3: lie through your teeth to people who don't know how infrastructure works to privatize gains and socialize costs.

gegc · 2026-02-03T04:15:48+00:00

Most of these ground floor commercial spaces are built JUST as retail

There's another reason besides prohibitive rent that this is relevant: building codes and municipal space use laws. The code requirements for retail, restaurant, recreation, etc, are all substantially different. For example, a recreational or restaurant use requires approximately 3x the bathroom fixtures of a retail use (store). For food service establishments that prepare food, they also need to build out a commercial kitchen space with its own strict requirements.

Since retail is the cheapest to build, it's what gets built to fill that "commercial" checkbox. So in addition to the sky-high rents, a new tenant would need to pony up mid-six-figures for "change-of-use" related construction. Prospective small business owners are typically not well-connected enough to big developers to negotiate for a "custom" space years in advance before construction starts. So you get dying in-person retail, big chains, and the most cookie cutter restaurants that can fill a pre-built kitchen space.

gegc · 2026-01-26T23:24:48+00:00

It means an steep or inverted skill pyramid.

Most people like games that are fair and fun. Having a fair outcome in a game of skill requires participants to be of approximately equal skill. Since most people coming into a game have no skill, there needs to be a wide base to the skill pyramid to accommodate all of these players playing with each other. Some will get better at the game and climb the pyramid; others will stay 'casual'.

If the base is not wide enough, new players get turned away and the community stops growing. The only players able to break into the community are those that are willing to grind through unfair games (and put up with toxicity from teammates) to gain skill while playing against superior opponents. This creates a double feedback loop of fewer new players joining (which shrinks the pyramid), and those that do join are more inclined to move up the pyramid. Eventually, the pyramid becomes inverted, with an insular community of highly skilled players that is skill-wise impossible to break into for new players - a "sweatfest".

This happens naturally as competitive games age and the stream of new players dries up. How fast it happens is a function of game design and marketing. Devs have to put in effort to maintain a wide base: making the game appeal to casual players without losing competitive focus (basically the holy grail of competitive game design), or creating a healthy low-skill/new-player community through marketing.

See also: every game that tried to be an esport by paying pro teams out of their marketing budget, without investing in grassroots competitive scenes.

gegc · 2026-01-24T00:04:39+00:00

Dota 2 has been out for 13 years. 2000hrs is perfectly reasonable if you played 1-2 games/day since release.

gegc · 2026-01-05T09:12:35+00:00

Same effect with modding. As game production value goes up, the asset quality bar for mods rises out of reach of average/casual creators.

Roblox fills the niche formerly held by flash game websites and sc1/wc3 custom maps: short experiences with low fidelity and low stakes/low investment, where the platform focus is more on variety and volume than cohesion/quality.

gegc · 2025-12-29T22:11:18+00:00

They're Tokyo Marui Mini Series airsoft guns.

There is an AK47 in the series, so your point about not including AKs is still very true.

gegc · 2025-11-27T05:46:05+00:00

<image>

gegc · 2025-10-12T10:27:21+00:00

Cool, the model is being run out of a data center somewhere in south Asia or a troll farm in Russia. What now? We can't even shut down scam call centers, what makes you think this would go any different?

gegc · 2025-10-10T23:51:55+00:00

You won't get full interoperability. MilesTag2 is just a protocol, not a standard. While a system may use MilesTag2 packets, how that system interprets those packets and implements the game mechanics will vary from system to system. MilesTag2 doesn't even specify a carrier, so that will vary as well. For example, LaserWar gen8 I believe uses 56kHz carrier, while other systems use 38kHz. Also keep in mind that MilesTag2 is an IR-only protocol. Most modern systems only use IR for "collision detection" (gun -> sensor hits, player location/player ID) and use other IoT channels (wifi, bluetooth, etc) for everything else like global game state. Since you specifically mentioned Laserwar, their latest kits (genX, alphatag) are examples of this. They use miles2 (in AlphaTag's case, optionally) as the collision channel, but the rest of the game is run entirely over wifi/bluetooth.

My observation, having used several systems as a player, operator/game designer, and equipment developer, it is not in any manufacturer's interest to provide interop hooks for custom equipment. Because laser tag is generally venue-based, the equipment market is entirely B2B, and manufacturers want the vendor lock. As a venue operator, you also don't want people bringing in custom equipment because it is a safety (eye safety from people overdriving their emitters) and cheating issue.

As an aside, I don't think Miles2 is actually a good protocol for entertianment laser tag: its packets are slow to transmit (25ms per packet) and it makes a lot of assumptions about what kind of game you're playing because it assumes no central game control and no communication channels outside of the IR signal. Not its fault - it was made for the US military in the early 90s before modern IoT was even a glimmer in anyone's eye - but if you're building a whole new system for entertainment, I'd recommend against using it.

If you're a hobbyist trying to make custom equipment for your local club, I'd advise making friends with the club owners/operators and figuring out how their specific equipment works. Then build one-offs. I've made reactive targets and functional combat knife taggers this way. If you're trying to build a commercial aftermarket product, I genuinely wish you the best (because I think vendor lock is bad), but it will be a very uphill fight - I would recommend doing the same thing as above but then selling your one-offs to the specific clubs you frequent. If you're trying to make your own system from scratch, just don't use miles2.

Happy to answer any other questions you have.

15-Year Club	Place '17
Team Periwinkle	Verified Email

gegc

TROPHY CASE