*The spec says 'laser', but that's just because it sounds cool. If 'fire', the MC checks the ammo counter, then 'alive', then fires the 'laser'* if all is OK. If 'reload', the gun MC resets acc (used as an ammo counter). (You might recognize this design pattern from the Team Baron drinking game scorekeeper.)Īnyway. The gun MC tcps and checks for 0 (reload) or 10 (fire), with 1 as the state if neither event is happening thanks to the NOT gate. The vest MC checks if the 'hit' or 'respawn' inputs are active and passes the result on to 'alive' and the gun MC. Which means the vest MC's output has to connect to the vest and the gun MC.Īside from that, it's pretty straightforward. My prototype design had the two MCs separate - but the 'gun' MC does require the player to count as alive before it will fire. This time, the wrinkle I wasn't expecting was mostly because I didn't read the spec as carefully as I'd intended. I've discovered I have a habit of making bold pronouncements about a design before I really dive in. Let's see if we can get two separate circuits working, each with its own expander! With the inputs (and output) regarding player vest state on one side, and the i/o for the player's gun state on the other, this design is screaming 'let two MC4000s handle it'. That said, boy howdy is that a big board! I might have to break my screenshots into pieces just so you can see everything. Laser tag's fun (one might even call it "AWESOME"), enjoyable, and I'm doing meaningful work making the things. I know Carl is disclaiming this, but, like the game controllers, this is a project idea I can definitely get behind.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |