Doug Tudeap in: The Ore Gone Trail

Starting with the title screen!

The font and title itself are of course references to the Apple ][ edition of Oregon Trail. I'm actually very happy with the lettering here, and this title screen as a whole. Graphics in ZZT have never been my strong suit, and I mean, the font is basically just stolen, but I also like my little "Press P" sign which is meant to look like planks of wood nailed to the wall.

I've become very fond of horizontal bands of black on my title screens in recent years (essentially starting with Ruins of ZZT). I think squishing the actual title area of these screens works better when you're cramming a ton of text on the board. There is a long running trend in ZZT games to actually include instructions about pressing "P" to play which is pretty much nonsense? I mean it's right there on the side. Part of me wants to call it an aid to newcomers to ZZT, and as a child it definitely took me a bit to notice that there was a button for the editor, but it's really frivolous. Perhaps one day I'll be powerful enough to not mention it on a game meant to be played by non-ZZTers.

It's also the introduction to the name "Doug Tudeap", a pun that I came up with pretty early into development, like when the game was going to start in Dwarftown.

Lastly, one of the final changes to the title screen was to embrace "Mower Quality Games" as a ZZT company. The name doesn't even appear in the game itself, but I finally decided to slap a company on one of my releases (despite not daring in the least to include the splash screen). And wow, I didn't even realize that the guy chasing the lawnmower on that board matches Doug Tudeap. That's a connection for sure.

Those who are really paying close attention might even notice the inconsistent title! I actively debated on "Ore Gone Trail" versus "The Ore Gone Trail", opted with the former, and then proceeded to include a "The" on the Museum database and game's text file. I can't even stick to canon for 48 hours.

And then we hit the menu and things immediately get interesting. The thing with ZZT is that it has so many weird quirks and nuances that somebody unfamiliar with ZZT will be very hard pressed to comprehend on their own. There's trouble from the main menu. Anybody new to ZZT is going to have to come to grips with the idea that the "menu" is a facade and that they're just moving a player around. In retrospect, it might have been better to do just that to help drill into players that you are controlling a smiley face, and even when you're steering a minecart you're doing so by controlling a smiley face. Instead I tried to make it behave like a menu in a more powerful medium to the best of my ability.

I absolutely should have had some objects appear to highlight the selected option. I think I originally did even, but got a little too clever at one point and realized I could use blinking colors to create the illusion of a moving track by having alternating rectangles of black-to-brown and brown-to-black solids. I liked the look of it quite a bit, but even I was getting disoriented with lining up which option I had selected with this in place and reverted to a less visually busy screen.

The help screens also had some big changes. Originally it was much more interactive, asking the player if they've played ZZT before, trying to discuss some of the limitations like how you control the smiley face regardless of how the game actually plays, but I scrapped it once I realized that this game is going to take maybe 10 minutes to play at most so there's really no need to add 5 minutes of tutorial. While this was a good call, I think it really demonstrates that while ZZT is a fantastic tool for creating games, it's far trickier to convey to a player unfamiliar with ZZT what rough edges are the limitations of the engine rather than the developer doing a subpar job. These days with source modification as an option you can make an argument that not doing something about the rough edges of the engine itself are the developer doing a subpar job, but when you've got a 48 hour time limit I suppose it's a bit more understandable.

The fourth bullet point on the list should have been all I needed to realize the engine still needed to be more usable to a ZZTer or not. The "compass" is cute thematically, but betrays that the object you control can move non-intuitively. It's another instance of cycle 1 being perhaps too fast as well. You really don't have time to confirm that the cart will turn the way you want it to at a three-way intersection.

I had other ideas for movement, and if I had time to actually experiment with them the game may have turned out differently (and probably for the better). I considered letting the cart be steered manually with Tudeap leaning on a side to force a turn, possibility with some interaction with speed to cause it to slow you down or crash if you lean for too long, but never got to even begin implementing such an option. There's always hope of a sequel: Doug 2Deap.

Oddly, despite trying to keep the player pinned for the main menu to make it feel more like a proper menu in other game engines, here I just let the player walk around freely? I don't know why I didn't just surround the player with passages on this board. Like, I even had the thought of "better explain what a passage is" here!

Speaking of weird decisions, "Here's a reminder about saving, but please don't". The game is so short that if I had made a modified ZZT, I'd have gutted the save system entirely.

If your game needs a bare-bones story to give justification to the gameplay, may I suggest anti-capitalist messaging? I mean, this is just Robin Hood but they're a non-binary dwarf. That's another pro game making tip: if your character's name is a pun that requires a traditionally male name, just make them use they and you get to keep the pun without being the 10 trillionth male protagonist in a game where the protagonist's gender doesn't matter or get brought up. Doug's pronouns are used solely on this board and the ending for a whopping total of two pronouns.

With more time there would have been slightly more to the story. The early idea of having to exit a level manually before a time limit expired was intended to be getting out of there before the royal guard arrives. I wouldn't have minded Doug clowning on the guard and eventually the king.

So far I had gotten away with just writing text on a board rather than doing text via objects, and the credits board was going to push that to the limit. There are too many urls, too many people, and too many tools to fit on one board. I thankfully had the foresight suggest looking at the text file instead. By putting it in an external file, I'd be able to more freely edit it after the submission period. Not that I did.

Finally it's time to play the dang game!

And you know what? I'm not that happy with it in the end. Ultimately it comes down to time, and every hour spent improving the engine would be an hour not spent making fun content that uses it. I'm not beating myself up over it. Half the point of a game jam is to get something out there as a learning experience, and the other half is to prototype an idea and see if it has legs. In the game's final version it really doesn't.

The timer for every regular stage is set to 29 seconds. What a weird number. That's because it was originally 99! It took about one attempt of playing the first stage to realize that 99 is way too long. Obviously later levels would be more dense. I initially scaled it back to 59 seconds, but even that had its issues. The first stage is the only one designed to be "solved" with a pretty clear path to be taken. For game with five stages, this honestly feels kind of cheap now, but at the time it was really meant to be a gentle introduction.

Designing stages for this engine is a nightmare. I have a distinct memory when the first Mario Maker was released of realizing that making a Mario level is incredibly easy, but making a level that has life to it is the real challenge. With engine based games like this, it's very easy to produce content. I can carve a path for the cart, scatter some gates, and line walls with gems and have a stage made in a few minutes. In an hour I could probably make 15-20 stages, but you wouldn't get anything out of them. There's a difference between level design and thoughtful level design, and I really wanted to avoid brainless levels. I already did that 16 years ago with Aura. (And upon writing that sentence my ancient body disintegrated into a pile of dust.)

The real problem though is that I don't know how to make a good level for this engine. There wasn't time to really experiment. I have no cut levels to showcase here. The only changes that ever got done were "well maybe I'll sprinkle a few more gems here" or "it's really hard to get down this corridor, let me just put a gate in the way". I'm still confident there could be a worthwhile game here, but given the time constraints I was unable to find out exactly what that looks like.

There was at least one good lesson learned with the first level and the 99/59 second time limit. I did implement a check on how many of the ores were collected in order to end the level shortly after picking up the final piece, though I think this first stage is the only one where it's actually possible.

I also should've reconsidered the control layout. I genuinely don't know why I went with object that are directly touched by the player rather than the more common arrangement where the player moves adjacent to an arrow to activate it and then the arrow pushes them back. These kind of inputs typically introduce minor delays in handling, but that can be averted with smart usage of #walk commands.

Heck it could've ran entirely on player clones and left the actual player to just stomp around in a tiny cell. That would've been a lot friendlier to newcomers than requiring them to step into the controls.

The first level's purposeful neglect of the acceleration mechanic probably opens up a better concept for the game to begin with. Focus solely on opening/closing gates and you're able to follow a more linear main track where having a mispositioned gate causes the cart to skip some gems before returning to the main track. Again, I feel like there are ways to improve what's here and get something cool out of it, it's just finding out exactly what that is.

But at least there's this!

I love this end of stage message, but even it is a good reminder of the importance of knowing your audience. I was quite happy with this art which fits perfectly with how a message window initially opens. No scrolling needed. It looks great. Until I got a comment on the game from somebody who couldn't figure out how to advance to the next stage. I couldn't figure out what kind of bug they must have ran into to break things. It's only now that I write this that I realize they likely saw "Move right to descend" and began hitting right. Moving right with the scroll window still open meaning nothing would happen!

Admittedly, they'd have needed to hit enter to close the opening "About ZZT" message, but that message has controls listed at the top. The game itself only uses arrows and the spacebar and there's no closing a window with those...

One stage is a tutorial, but next I had to make something with the understanding that the player wasn't going to be completely lost. It's only been a few weeks and already I couldn't tell you what my thought process was for this. About the only distinct feature to me is that if you start in reverse you can collect a bunch of gems that give a large amount of points.

What little design was here was trying to come up with a way to have some harder to reach area with more valuable ores, but that's rather difficult to actually do more than one turn ahead. Even those gems designed to be easily collected by starting the stage in reverse are just as easily reached by heading east to the edge of the level and then letting the cart steer itself around and to the west. Sure you have to flip a few gates, but it requires little thought on the player's part. Much of the gameplay feels less about "how can I route this" and more about "how can I avoid crashing". Which again, that could have been the core mechanic of the game!

But it's not so you kind of just get to ride around and hope you did good. Perhaps another alternative could have been to make the game more of a puzzle where there was a minimum score and a way to reset the boards. The objects for the ores conveniently don't even remove themselves when collected. The minecart's initial position would be the only work involved to reset a board to try again. I don't know if I'd have had the confidence to let the player fail and have to redo these stages potentially several times in a row to find a correct answer. It doesn't sound all that fun, but could have been something to throw together and see.

As if I were realizing the problems with the game as-is, I wanted to let myself bend the rules I had committed to with the creation of a bonus stage. I was constantly debating with myself if this was a good use of my time at this point, only having two levels and instead making this. The bonus stage is a fully linear path with the cart automatically accelerating to full speed and the level ending as soon as the cart crashes.

Most of the work was gutting various functions rather than adding new ones, but there were some unexpected issues and cut content here. Firstly, the cart was originally going to leave a rainbow trail behind it. I liked the idea of a more colorful board, but when this was implemented I wasn't satisfied with how it was coming out and scrapped it. (The mechanic was that the cart would put some colored water behind it and an object would palette cycle the water.) Secondly I managed to hit the stat limit! The final version here is at 144 stat elements. Originally there were ores on both sides for most of the track. Lastly, I hadn't considered the audio buffer when doing this. It would really fill up and just result in and endless stream of sounds the kept playing long after the cart had passed them. To deal with that I wound up just muting the source objects for half the gems. It still runs long, but not nearly as much as it originally did.

Confession: I've never gotten a perfect on this stage. It should be possible? I even thought about adding one last ultra special white diamond gemstone at the end for an absurd amount of points, but since the game was going to be about chasing high scores I didn't want perfecting the bonus stage to make or break a high score attempt and removed it as well.

And in stage three, again trying to grapple with how to design levels for this system. This one shifts the focus from the gates to the cart. You'll have to turn around, and with the limited amount of time it's clear that you can't collect everything in the stage. This is a sort of a test on your braking ability in particular. Really it's probably the level I'm happiest with in that it feels parse-able as you play. Since each tunnel is a dead end, as soon as you enter one you can begin thinking how you need to navigate the cart to another tunnel. The placement also offers some hints in putting the lowest value ores in the easiest to access tunnel. I've had runs on this stage where I've just barely managed to pick up everything except that center tunnel, but it took a few attempts to be able to reach that point. Perhaps chaotic grids weren't the best approach and something like this was a smarter way to go.

Stage four: Chaotic grid.

Really it kind of went without saying that whatever the last level was going to be, it would be loaded with a million gates. With the first two stages, I went with creating a layout and placing a few gates, trying out the level and seeing where additional gates would be helpful or hindering and slowly increased. With this one, I just went ham from the start. There's an incorrect association where the challenge comes from more gates, but really all that does is makes the player more likely to focus on not crashing and less likely to focus on how they're going to navigate the stage. Pardon the pun, but if you're stuck focusing solely on a line from the cart to the next obstacle rather than taking in the whole stage, you've got tunnel vision my friend.

About the only real thing I had figured out by this point was that the outer perimeter of a stage should only have lower tier ores. It's easier to get out of the "maze" than it is to get back in which requires cooperative gates. A good example of this is on the leftmost wall. If the cart is circling the perimeter and moving along it from south to the north, the gates along that wall will either keep the player on the outer perimeter or cause them to crash. Gameplay-wise I think this is a smart idea, to have mistakes push the player away from where the better gemstones could be acquired and making them try to get back to an inner loop.

Really it would all come down to having the time to better experiment with level concept and figure out what actually works. So much time was spent on the engine that I could just never afford to scrap a stage if it wasn't clicking with me.

How many stages to shoot for was a question I was constantly asking, and one where as I got more stages complete I kept feeling less and less confident that I could hold a player's interest for very long. I believe I was shooting for ten originally, and there was nothing stopping me from carving some more paths and making ten stages, but I've played enough mediocre ZZT worlds by now to know that a mediocre game that's short is vastly superior to a mediocre game that never seems to end. Ten quickly became six, and six became five (counting the bonus of course). Thanks to an old Ruins of ZZT play-through by David X Newton I can quickly check that that game clocked in at about half an hour of playtime, and received comments from other Ludum Dare entrants that were surprised at its length. Having now played a dozen or so other entries to this Ludum Dare, I can say that the 5-10 minute playtime is a lot more expected.

The advantage to ZZT for these things is supposed to be that you can just start making content, which I threw out by instead making an engine based game. Oh well.

But calling it quits at this point wasn't getting frustrating and giving up. It was admitting to myself that I didn't have time to truly fix what the game was lacking. Instead I could give it a little polish. The ending was itself pretty hastily made by using KevEdit's flood-fill gradient tool to quickly make a mountain and some incredibly basic shading to draw the rest of the board. Earlier on I had the idea that the ending would be some flashy escape where the minecart gets to go off a ramp and soar through the air, little bits of treasure flying out all the while. I wasn't confident in my ability to portray that with the time I had left and had to settle with a picture and some text. I even watched the ending to Thelma and Louise on YouTube in preparation! I... do not think I would have captured its energy nearly as well.

Instead a little animation of the cart riding down the mountainside and into the town for Doug Tudeap to redistribute the wealth they acquired before riding off towards new adventure leaving with the inspirational quote of "I'm here to pickaxe and chew bubblegum".

If you've played the game yourself, you may have wondered why this score tallying screen hadn't been shown when everything else was going in order board by board. The reason for that is simply that it was added to the game at the last minute! This board was actually quite a lot of work to implement properly. Again Speed Racer X comes up as inspiration with its "pit stops" after every four races to tally up the time spent. I decided to break things up so that there were tallies for each stage both for ores collected and points gained. A more complete project with better balance in its levels and replayability would have benefited from this screen the most with the ability to take a screenshot of a 100% game. I was unsure about actually including the point totals at first as they might imply that every level could be completed perfectly.

This one ate up a lot of code too! I knew the only way it would be able to fit would be for the objects to #bind to each other for each digit in the tallies. After finishing a stage a flag is set that an object detects on this tally board to begin calculating. The numerous digits don't immediately bind to the calculation objects, but instead run a loop to see which part of Doug's path down the mountain lit up. Then they bind. In addition, the objects that they're bound to need to not execute code themselves, but the bound copies do need immediate execution! This was handled by setting the instruction pointer for the source objects to -1, which is what ZZT sets it to when #end is called.

Over the years people eventually realized that when trying to zero out a counter in ZZT that the most efficient way is to take decreasing powers of 2, but that wouldn't play nice with populating digits one at a time so instead things are handled by figuring out the thousands, then hundreds, then tens, and finally ones. It's slightly slower but still only takes a handful of cycles to complete. Once the ones digit for points is dealt with a door opens for the path to the next stage. Here I was sort of stuck with just having the player walk from one passage to another instead of messing with clones and board edges or duplicators. I needed this board to be ready to go multiple times and the slightest mistake of letting a player clone linger could result in the player being warped to a completed stage. If this wasn't a Ludum Dare game intended for non-ZZTers, I'd be quite happy with the layout of this board. I think it looks very clean and organized.

In addition to score counting and showing progress on the mountain, I also included some goofy phrases for guiding the player to the next level about Doug "boldly bounding" or "delving deeper" as a Jill of the Jungle homage.

I did make one fatal mistake on this board though, and that was relegating the total score to the ending screen. One final tally would have it made it possible to simultaneously share your individual level scores and your total score in one place! The ending screen even gives the player back all their points to enter a high score, so I can't believe I didn't cram it in here, even if not as a nice on-board representation, then as just giving the total points back so it would be visible in the sidebar.

The Results

Whoops, I did not get enough ratings to actually get a proper ranking. That's fair given how the system suggests your game the more you rate and comment on other games, which while I spent some time doing I didn't get to spend enough time doing.

I still have score averages though, which tell the story you'd expect them to.

Which pretty much validates my own thoughts that while there's potentially something here, the execution as-is doesn't pull it off.

Final Thoughts

I hope I didn't come off too negative here! Luckily the only feelings I can hurt are my own.

Am I happy with Doug Tudeap? Well, that's kind of a difficult question. The game has quite a lot of flaws to me. I did not accomplish my goal of having thoughtfully designed stages. I didn't get to use ZZT's quick development times to create a game of impressive size. I didn't manage to hide ZZT's limits in menus, textual displays, and board transitions like I would have wanted. The game itself never found a voice. I'm not sure if the idealized game is one about manipulating gates, steering a cart, racing a time limit, routing a level, or some other combination of those things.

But shoot, it was a really good learning experience in a way that Ruins and Quickhack weren't. This game did succeed in getting me to better think about what sticks out about ZZT to newcomers that can make it feel awkward and unintuitive, especially in the context of an engine based game. There are plenty of flaws that I think I should have been able to catch and fix (forcing the player element to have to walk into the controls, the whole "Move right to proceed" text). I can't help but think there's still a good idea somewhere in this mess, and I certainly shouldn't beat myself up over not managing to find it within 48 hours. As a kid I lived for 24 Hours of ZZT competitions, I remember constantly planning to stay up all night and really be at a computer with the ZZT editor open for as much time as possible to max out the quality of whatever I could accomplish. They felt like monumental events, and while I never actually came close to putting in the hours I hoped I would, I can at least say that I prioritized healthy habits here. Besides, if I was fretting about my stage designs to begin with, I don't think making more of them at 4 in the morning would have benefited the game any.

What I did get from Doug Tudeap is exactly what one should hope to get out of a game jam. The opportunity to create something and have it be played by others. It's a brief exploration into a game concept and seeing what parts work and what don't. I may not have found what makes Doug Tudeap a good game, but I left with several examples or what don't work. I'm confident enough in the idea even after the various disappointments and mistakes here that while I don't have any plans to develop it further, I don't think it would be a bad idea to return to it someday.

As for the Ludum Dare, I think I'll stick with the jam next time, or more likely take a look at some of the kinds of jams that a ZZT world is better suited to. The Ludum Dare is kind of overwhelmingly huge and probably isn't the best jam to use to nudge people to look at ZZT. Something smaller in its applicant pool and more generous in its time restrictions (not to downplay the lessons that can be learned from such tight time limits!) would certainly work better for me and my potential audience. I could've had an entire month to submit to DOS Games Spring Jam 2021 which I'm sure would have an audience more prepared for ZZT's quirks.

So you won't be seeing Doug Tudeap topping the charts, but it's always nice to actually get to create with ZZT instead of just writing about what's already been created.