dobu gabu maru Posted May 21, 2018 Finished constructing the Tower of Hanoi! Hooray! For all those who don't know, after seeing my vinesauce map mechanic, Linguica suggested that I make the Tower of Hanoi puzzle in Boom, a task I initially chuckled at but later took upon myself for my next zekhmet map. Turns out I was in over my head... waaaay in over my head. The Tower of Hanoi is as follows: The two rules are: 1) Move only one block at a time 2) A larger block cannot be placed on top of a smaller block. The goal is to move the entire tower from one pillar (hereby referred to as a "zone") to another. So in Doom, I set up a zone for each block tower, and three switches corresponding to each block: Large White, Medium Green, Small Red. Hitting a switch would tell that particular block to move to the switch's zone, and if it couldn't, the block would remain where it was. Each block is tied to a dummy sector, so for instance when the Small Red block at the top of the tower lowers, it descends into the Medium Green block. That way, the objects remain "solid" blocks instead of rings, which would allow for the player to platform across them. Sounds simple enough, right? No. No it was not simple. There's three parts to this puzzle that make it a pain in the ass: 1) The voodoo dolls need to know that only one block moves to one zone at a time. 2) The voodoo dolls need to know when not to let a block enter a zone. 3) The voodoo dolls need to know when not to let a block leave a zone. Numbers 2 & 3 sound like they're really just a single problem, but it's two and I'll describe why later on. For now, let's look at problem #1. Initially, I set up 9 linear conveyors, one for each switch—makes sense, yeah? Hit a switch, it'd open a door, scroll the voodoo across lines that tell the other zones to lower their blocks, and the switch's zone to raise its block, and problem solved. But no, it wasn't really solved, because it needs to tell the zone the block is leaving to move to the zone corresponding to the switch. Which means that one zone needs to remain entirely unaffected in the transition, which is why the linear system failed. For example: In Case A, it works properly, because hitting the Small Red switch at Zone 3 will cause the red block to raise there and lower all the others, but in Case B the system breaks because hitting the Small Red switch at Zone 2 will cause the red to lower at Zone 1, which will place the block within the Large White at the bottom, instead of the Medium Green (due to the dummy sectors). This means that if the player tries to move the red block over to Zone 1 afterwards, it will only raise up to Medium Green height, making it look like nothing has happened So! Instead I developed a branching path system, which are those upside-down "Y" conveyors in the first pic. With only 1 voodoo doll in each colored column of conveyors (1 for Large White, 1 for Medium Green, 1 for Small Red), it now simulates where the blocks are currently located. Hitting a switch will open two doors in a column, corresponding to the zone the block moves to. So the doll starts in the top conveyor to symbolize that the Small Red Block is at Zone 1, and hitting Zone 2 Small Red switch will open the Zone 2 doors in the conveyors, which will adjust the blocks accordingly and teleport the doll to the Zone 2 row. YIPPEE! But now, problems #2 & #3 need to be addressed: in our current system, any of the blocks can be moved to any zone (albeit one at a time). To lock them down, we need both to make sure blocks cannot enter a zone unless they've been given clearance (Problem #2), and we need to make sure that blocks cannot leave a zone if they have a block on top of them (Problem #3). For instance: In Case A, we need to tell Zone 2 that it cannot accept any other viable blocks while Small Red is there (Problem #2). In Case B, we need to tell the blocks below Small Red that they cannot move (Problem #3) So! Tackling Problem #2 is pretty simple—what we do is create a separate (primary) conveyor system for all 9 switches (seen to the left in the first pic), and these act as gates for the (secondary) "Y" series of conveyors (as in, they block the secondary voodoo dolls from moving unless they give the OK). When the Small Red block moves to a new zone, the zone its at gets its primary conveyors locked off, which means that the secondary voodoo dolls can never get the signal to leave and enter that zone. We do the same thing for the Medium Green, except we don't block off any of the primary conveyors for the Small Red switches. Problem #3—not allowing the blocks below a smaller block to move—is more complicated due to a single block combination. My initial setup was easy enough: place gates in the secondary "Y" series of conveyors that only open when a voodoo doll within that row leaves. For instance, when the Small Red voodoo leaves the Zone 1 to go to Zone 2, it opens up movement for the Medium Green voodoo in Zone 1 and closes it off for Medium Green Zone 2. And we do the same thing for Medium Green with regards to Large White. But here's our problem: When it's just Small Red atop Large White, it doesn't stop the bigger guy from moving! So then I thought, "Well okay, make Small Red gate off both Medium Green and Large White from moving". But then once Small Red leaves, it will allow Large White to move, even when Medium Green is on top! Now as I'm writing this, I realize the smart thing to do is to apply 2 gates to Large White—one for Small Red and one for Medium Green, but oh no, I had to be a massive moron and choose the more complicated task; I put in a switch system for Medium Green in the secondary conveyor system, so once Medium Green leaves it, the Small Red for that row gains access to the "gating Large White" tertiary conveyors (it's the whole C/O conveyor system at the right [C for "Closed", O for "Open). Of course, this means that I had to also remove the Medium Green triggers from the secondary Small Red conveyors and put them into that system as well, so now it's a disorganized mess to follow. Here is the map if you wanted to test it out (it doesn't use the zekhmet texture pack so the colors are different). I still need to rebuild the secondary conveyors so they move much faster, as well as eliminate the tertiary conveyors since they're unnecessary, oh and if you hit switches too quickly the system will definitely break somewhere. Might not work in every port, but it shouuuuuuuld work for the most part? 27 Share this post Link to post
Fonze Posted May 21, 2018 Awesome job Dobu! I love your work with puzzles and boom mechanics; it's a huge inspiration to see stuff like this come together. <3 2 Share this post Link to post
kb1 Posted May 22, 2018 @dobu gabu maru I absolutely love these insane voodoo doll/switch/conveyor logic engines! Other than the spped issues you mentioned, do you think you've nailed the logic in each case? (I haven't checked it out yet). I think I would have cheated, and make the switches into silent teleporters, and just teleported the player to a complete copy of the puzzle, pre-arranged for each combination, which would have been a very inelegant solution. Your solution is much more interesting! 0 Share this post Link to post
dobu gabu maru Posted May 22, 2018 8 minutes ago, kb1 said: Other than the spped issues you mentioned, do you think you've nailed the logic in each case? (I haven't checked it out yet). I think the logic in each case is pretty solid—though deleting the tertiary system and implementing another door for Large White is like, a huge leap towards simplifying the redundancy I have in place with Problem #3. What's neat about this is that the methodology can be easily expanded upon if the player wanted to add more blocks—just add another secondary column for a new color for Problem #1, attach another door to it for Problem #3, and give every the secondary conveyors 2 linedefs for the new primary doors for Problem #2. Simple and easy to replicate—I might make a 5 block tower just to prove it can be done. The silent teles are a clever way around trying to make the puzzle work mechanically, but in the map that I'm making it for, everything is in the same room—so it'd require me to copy & paste the map several times over, especially since each zone can hold 8 separate tower configurations. That kind of thing just isn't tenable beyond 3 blocks, so it's easier to just work out the puzzle mechanics. 2 Share this post Link to post
Jon Posted May 22, 2018 This is awesome, but further confirms a theory I've had about doom modders. This kind-of stuff is one of the few places that it makes far more sense to use WadC (or something similar) to handle the labour, because you can scale up logical constructions so easily. (I re-implemented fraggle's binary ripple counter in wadc as an example). So the theory goes: no matter how much more sense it would make to script, the frontier of insane-doom-not-acs "scripting" will always be expanded by maniacs who do it all by hand in a traditional editor. 3 Share this post Link to post
Catpho Posted May 22, 2018 You are insane dobu, and thats why i like you <3 Experiments and discoveries like this just makes the limitations seemingly vanish, and a very helpful wall of text you wrote there, should be a ton of use for any aspiring voodoo scripting wizard. This is so-awe inspiring i had to comment! 1 Share this post Link to post
dobu gabu maru Posted May 22, 2018 10 hours ago, Jon said: This is awesome, but further confirms a theory I've had about doom modders. This kind-of stuff is one of the few places that it makes far more sense to use WadC (or something similar) to handle the labour, because you can scale up logical constructions so easily. I just want to clarify that me doing this wasn't just to simply prove that it could be done in Boom, but an exercise in puzzle solving for myself via the editor. I also have no experience with programming, and learn things best by working through it myself. 3 Share this post Link to post
Dragonfly Posted May 22, 2018 (edited) I thought you were more mature than this Dobu. Spoiler heh 2 Share this post Link to post
dobu gabu maru Posted May 22, 2018 It's a spaceship! YOU'RE SEEING WHAT YOU WANT TO SEE! 3 Share this post Link to post
kb1 Posted May 22, 2018 2 hours ago, dobu gabu maru said: I just want to clarify that me doing this wasn't just to simply prove that it could be done in Boom, but an exercise in puzzle solving for myself via the editor. I also have no experience with programming, and learn things best by working through it myself. Well, like it or not - this *is* programming. Maybe not in a traditional sense, but it has all the same elements: variables, logic, state management, and probably a few more I can't think of. Good stuff! 0 Share this post Link to post
dobu gabu maru Posted May 23, 2018 ^ Oh yeah I totally recognize that, I just mean in the sense that Jon was suggesting that WadC would be better suited to handling labor, which—while true—doesn't help me in my case since I don't even understand how to use WadC on a basic level. 0 Share this post Link to post
Jon Posted May 23, 2018 13 hours ago, dobu gabu maru said: I just want to clarify that me doing this wasn't just to simply prove that it could be done in Boom, but an exercise in puzzle solving for myself via the editor. I also have no experience with programming, and learn things best by working through it myself. I apologise for my tone. I don't want to detract from your awesome achievement. Not using WadC isn't a bad thing, you're in very good company :> 10 hours ago, kb1 said: Well, like it or not - this *is* programming. Maybe not in a traditional sense, but it has all the same elements: variables, logic, state management, and probably a few more I can't think of. Good stuff! True. 1 Share this post Link to post
Grain of Salt Posted May 23, 2018 wrt WadC vs manual cl9 stuff: I think sometimes it's more time-efficient to do something the inefficient/brute-force way than it is to sit down and work out the most efficient way. WadC would be a great way of doing stuff like this if I could actually get my head around using it :/ All the stuff I've done with WadC in the past has been learning how to do one fairly simple thing and then basically spamming it. 0 Share this post Link to post
Jon Posted May 23, 2018 4 hours ago, Grain of Salt said: wrt WadC vs manual cl9 stuff: I think sometimes it's more time-efficient to do something the inefficient/brute-force way than it is to sit down and work out the most efficient way. WadC would be a great way of doing stuff like this if I could actually get my head around using it :/ All the stuff I've done with WadC in the past has been learning how to do one fairly simple thing and then basically spamming it. I think something I've failed to really appreciate properly is how steep the learning curve is. I forget that I've been using it, on and off, for nearly 15 years, and even so, the map I started in 2006 I still haven't finished (although I did finish one real actual map in the mean time, and several tech demos. Still, not many!) 2 Share this post Link to post
kb1 Posted May 24, 2018 9 hours ago, Jon said: I think something I've failed to really appreciate properly is how steep the learning curve is. I forget that I've been using it, on and off, for nearly 15 years, and even so, the map I started in 2006 I still haven't finished (although I did finish one real actual map in the mean time, and several tech demos. Still, not many!) I think it's a right-brain vs. left-brain thing. Mapping can be an artistic thing, but to get there in WadC, some thoughts on the geometry is required. I've been wondering how to bridge that gap, like with some automation, maybe. You have an awesome, powerful thing there, yet it's so far removed from drawing lines with the mouse - it's even difficult to describe. I am bummed that I haven't been able to devote serious time towards figuring it out. It's on the list, you know? 0 Share this post Link to post