The Unforeseen Responses

The Unforeseen Responses

I tried relaxing the format a bit for this episode. I talk about how Adventurous Scenario 1 and The Unseen Forces – Arid Fortune compare to each other and talk about a comment left from the last episode.


  1. If i had to choose, i would say good level design comes first. However, i don’t think you can really favor one over the other, they both go hand-in-hand in making a game an enjoyable experience. If you have a solid level, it wont matter if mechanics are lacking, and vice-versa. I do think that its easier to make a map enjoyable via level design though, because if a level is designed well, it will incorporate the designed mechanics in perfectly, whether or not those mechanics are solid or not.

    One-command tools are a great way to provide large contraptions to the public, very easily. There are no downloads required, no mcedit to paste in schematics, its a very streamlined way to showcase contraptions or share them with others. I cant see how one-command stuff can be used for personal map dev though, as im not the type of person to write all commands down in notepad before putting them into the game.

    1. To clarify, the line “If you have a solid level, it wont matter if mechanics are lacking” i meant that the solid level wont matter much if the mechanics are lacking, not that the mechanics don’t matter due to the good level.

  2. Proper level design because I believe the mechanics can be as obtrusive as possible but if you have proper level design you can teach the player the most complex ideas to work with..

    1. Oh, another question! Here is my answer: I write commands straight into command blocks. I understand the logic much better in the “physical” space and struggle to translate it through text editor. It doesn’t have the same tangibility that command blocks do.

      1. I especially tend to lean on level design because that’s where I started.

        (Remember that saying? the brain sturgeon thinks its the brain, the foot doctor thinks its the foot, etc…)

        If we compare level design to theme, a well-designed level already understands what the end goal is going to be. From there, we can break it down into three stages: safe introduction, now try it for real, and finally: here’s a twist.

        A well-thought out theme caters to the your proposed mechanics. I think of this as a tool to help translate game mechanics for newer players. For example: You have a mechanic where you recruit mindless drones to help protect you. You could frame this easily through depicting a crime-ridden city where you gather up brutish thugs or perhaps you are insect-sized and have power over ants. Very thematically different, but both could work for your proposed mechanic.

        The idea of using theme as a tool to convey game mechanics instead of shaping mechanics to the theme is something I hadn’t thought about before.

  3. If this was a regular game, I would say neither should take priority over the other, but in minecraft maps, I feel very strongly that mechanics carry the experience. This is a minecraft map, most people still don’t regard it as a game and to make it worth it to continue, the player needs some pedigree, like interesting and fun mechanics right off the bat.
    It really doesn’t matter how cleverly you placed the zombies or how your level is amazing at gently guiding the player via visual hints if the person experiencing it won’t notice it because they’re so put off spamming leftclick for 40 minutes.

    1. I think this is a situation where we need a prescriptive definition for what a player-built Minecraft mechanic is and what level design is.

      I believe a mechanic to be any non-Vanilla feature which has been programmed in. This could be as simple as a start button to teleport you to the starting area to something as complex as a fireball which bounces off walls and sets everything it touches on fire.

      What you described is what I consider to be level design. In this case, I’m considering level to be closed-off or gated area with an objective. To cut straight to my point, a level or objective should be catered to the mechanic or ability you’re trying to teach the player.

      Then you design situations as you described–to give your ability or mechanic a showcase.

      In reality, we’re both saying the same thing, but using different terms and perspectives to get our point across. This is because there’s no dictionary for game design we all can agree upon. 🙂

    1. Thanks for the heads up. Proofreading can correct grammar, but not links. I’ll be sure to double-check this next time. Link has been updated. 🙂

  4. It probably depends on the specific map. I’ve seen cases where a map’s focus was entirely on mechanics, with barely any attention paid to level design at all. In some maps, it works. In other maps, it’s unplayable. Ideally mechanics and level design should work together.

    Of course, on the other hand you also have some maps that are almost entirely level-design-based, like vanilla parkour maps. Some people just want to jump around on blocks without a bunch of frills. The only real “mechanics” to be added there would be visual effects, a checkpoint system maybe, nothing major. The level design, on the other hand, is what can make or break a parkour map. Jump difficulty is really hard to balance.

    1. Regarding the second question: I like to have control over my command blocks, but the interface is really stupid for longer commands. I maintain a Notepad++ document with all of the “longer” commands (multi-nested executes, anything with NBT, that sort of thing), and manually paste that into rows of command blocks as needed. I usually use AreaEffectClouds as markers instead of relying on coordinates, so I don’t really need to worry about position much, but it’s nice to have that level of control. Plus, that way if something else breaks the one-command devices (looking at you, “Passengers” tag), I’m not stuck being used to a method that no longer works.

      1. It’d be interesting to see if we could develop a tool that uses the structure files to quickly import code. I’m curious to know the benefits of using AreaEffectClouds over ArmorStands, or are there specific use cases?

        I think we need to define what is a good and poorly designed map. Despite what most people believe, there are standards we can rely on. I believe the best maps start with mechanics and then design the levels or game to teach and test the player in different ways.

        I suppose this stems from my core belief that the best games are ones where you’re constantly learning.

        1. AreaEffectClouds have much fewer associated tags than ArmorStands to be markers (making them easier to create from scratch), and cause noticeably less lag when used in large numbers. In addition, they are invisible even in spectator mode, and you can set them to automatically decay once you’re done using them (or to stay essentially permanently if need be). For markers that do not move, hitboxes can be used to see their locations even in creative mode (which would require an entitydata command for armor stands), and even for those that do, I set up a custom gamerule to create a small particle effect around each one for visibility.

          1. The command I usually use is /summon AreaEffectCloud ~ ~ ~ {Duration:2147483647}. That’s why I like it. It has a single tag, and being int-max it’s a fairly memorable value.

            As for its effects on performance, I set up a simple test in a test world. 120 FPS is the baseline. 2048 armor stands without invisibility or anything brought me down to 1 or 2 regardless of facing direction (as expected). Giving it the standard marker tags sent me to about 15 when looking in the direction of the stands, 30 when looking in a different direction. Spectator mode dragged this back down to the 1 or 2 FPS I had when they were visible (as expected).

            On the other hand, 2048 AreaEffectClouds caused absolutely no noticeable difference in FPS until I turned on hitbox display, at which point it went down to 55 when looking at it and 120 when not. In fact, it took 8192 AECs to cause any noticeable decrease in FPS (went down to 100FPS).

            I can’t measure the effects on server tick rate, but these are obviously pretty significant results for large numbers.

  5. I think intuitive mechanics are much more important than any amount of level design. No matter how good your worlds/levels are, if your mechanic doesn’t work properly, is hard to use, is really confusing to use, or buggy, it will immediately ruin any gameplay experience.

    Let’s say you added some superjump ability, and to activate it, you had to spin in 2 complete circles and then drink a potion. That’s not really intuitive and players will probably not like that a lot. It takes too much time, and is a pain to do and possibly hard to pull off (:P). But if the superjump is activated just by right clicking some item, that’s really easy to do, anybody can do it and it takes no time to learn or even needs to be explained.

    If you can make a map with mechanics that are so easy to learn that you don’t even need to explain how to use them, you have created one of the best possible games there are. Who cares about how the level works (I don’t for the most part). Those sweet sweet mechanics are working beautifully without any hand-holding needed

    1. I think of what you’ve described as a toy. Sure, it’s a lot of fun to play with, but with no direction or purpose, I don’t see the staying power you’ve described. Great level design relies taking toys and instead of having the player create their own fun, you create an environment for them to experiment and learn from.

      I also believe a lot of what you described with the right-click to be handled during user-interface design. I was working off the assumption the mechanic is bug free and without UI issues. Hm, it’s crazy how our perspectives differ. We’re not even talking about the same thing, in reality.

      To be clear, I call it a toy because there’s no ruleset described here (Minecraft being the ultimate toy), and without level design as defined by how a world is laid out, enemies are placed, what the objective is, what the theme is, and many other factors.

      You’ve given me a lot to think about.

  6. The mechanics of the game drive the experience and should be really focused on in development. I was watching a live stream the other day where the map maker was talking about adding in a bunch of maps and a map editor without the core mechanics being done. Mechanics first, Maps second imo!

    1. The more I think about it, the more I believe this was an unfair question. The terms I used weren’t really well-defined, nor were my explanation of them. I absolutely agree with you; the core mechanics should be completed first and tested.

Leave a Reply to Skyao Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.