(Wand-to-wand communication is hard!)
Austin Maker Faire is this weekend – on May the 4th. I’ll be showing the wands there, which is exciting as the Dickens. I really, really wanted to have wand-to-wand dueling (w2wd) working by then. I fear that’s not going to happen. Here’s what’s up…
I’ve been working on w2wd off and on for the past few months. I’ve been working it in earnest the last two days. I can get wands to create stable mesh networks with the PainlessMesh library. I can get them to transmit and receive messages. I can get them to act on those messages – even to the point of a receiving wand lighting specific lights in response to a message it receives.
But if I get much more complex – if I add additional light effects or try to read specific gesture sequences as spells – it gets a little unstable.
Ultimately, I need to “level up” my programming skills. I need to really understand how to use multithreading and both cores of the ESP32. So far, I’ve been able to fake it; I’ve relied on that for the limited comms success I’ve had to date. I wish I had more time to buckle down and improve my skills! 🙂
The wand-to-wand limited duel demo I’m coding has no visual or audio feedback to tell you when your wand recognizes that it’s changed position. I need to add that; that’ll go a long way toward telling me how it’s failing. If I can get comms stable (if I can show that user error was to blame instead of comms), I need to add a simple deadline timer for when you get hexed and a simple hit point system (three hits and you’re out). I’m going to refrain from including a mana (magical fuel) system, and defenses will stay up until a hex knocks them down or you cast a new defense.
Simple w2wd demo play sketch:
- Players start with no active defense, no active attack, and three hit points (HP).
- There are four attack spells (AEFW walls) and four defense spells (AEFW balls).
- When you cast an attack, it jumps on the other player’s wand. (Casting an attack when you’re hexed does not make your hex pop.) If your opponent’s wand is already hexed (has an attack on it), the old hex fizzles and your new attack becomes the new hex. <<< This resets their timer; indiscriminately spamming attacks on your opponent is counterproductive.
- When you cast an attack, it sets a “declareAttack” timer for 1/2 second. Your “currentAction” stays set to your most recently-cast attack until your declareAttack timer expires (Expiry changes your currentAction to “nil.”) or you cast another attack (That resets your declareAttack timer and changes your currentAction to your new attack.). <<< The declareAttack timer ensures your opponent receives (hears) your attack.
- When you receive an attack, your wand sets amIHexed to True, sets currentHex to the attacking spell, sets the hex display LEDs to the attack spell’s colors, and sets hexDeadline to current time + 10 seconds. It doesn’t need to check if you’re currently hexed, and it doesn’t need to see if you have a defense. Other routines will deal with that.
- When you cast a defense, it becomes your current defense – replacing any defense you may currently have on your wand. Casting a defense does not trigger attack-vs-defense resolution; that’ll happen during the “hex upkeep” phase.
- Hex Upkeep: If your wand is hexed, check for a defense and resolve accordingly. If no defense, compare the current time to when the hex should explode. If it hasn’t exploded, set hex brightness in proportion to proximity to explosion. If it’s exploded, erase hex, play sound, and remove a hit point.
- Defense resolution: The only perfect defense is an opposed defense (eg: fire vs water, earth vs air). Orthogonal defenses let 1 point of damage through. Allied defenses let two points of damage through. When a defense resolves vs an attack/hex, it removes the hex (amIHexed = False; set hex display LED brightness to 0) and defense.
- Health upkeep: If HP <= 0, lose the game.
That was helpful! Let’s see if I can implement it. 😀