This guide was made to be useful by everyone!It has good advice for beginners and people with years of experience too.
If you think part of it is really stupid or something, please make a comment here; I'm very open to input, although I did think about all of this pretty thoroughly and I'm pretty certain about almost all of what I wrote here.
If you'd like to see another topic covered, I'm very open to ideas. Begging for them, in fact. I'm releasing this now pretty much because I'm out of ideas and think it's polished enough.
I'm currently considering adding a chapter with a 2-3 individual map breakdowns, but I'm hesitant for... some reason. I'd like to know if people think that would add much substance to this or not. I already use a lot of examples when I'm talking about certain topics, afterall.
I'm sorry about this, the admins made me paste it in here. Further updates will be kept on google docs, but probably not here because I'm only putting it here to spread it around, not to help this site.
Prelude:Before someone complains about this, everything in this document is a generalization. If I say something very assertively and use the word “always” or something to that effect, I actually only mean that for the general case. However, if you are making a map that goes against many/critical parts of this guide, you are probably making a novelty map. Novelty maps are the equivalence of movies that are so bad that the script makes fun of itself.
Chapter 1: Gameplay Concepts
And opinions you didn’t ask for.
Difficulty:The entire concept of difficulty in auto-bhop is tough. In fact, it’s hard to identify what really makes maps hard in the first place for me, still, despite it being one of the first questions I really wanted an answer to. For our purposes, bhop is a single-player platformer game, but there’s leaderboards chucked in.
First of all, consider people’s motivations when they’re bhopping as opposed to playing literally any other platformer in existence. For other platformers, the player’s goal is generally to just play the game and progress. In bhop, the goal is generally to beat other people on the leaderboards, or to improve your skills to compete with other people, or what have you. The point is that bhop is a competitive game by nature, and virtually all common long-term goals revolve around competition, not completion. As an aside, that is a part of why all of the people going around saying “auto bhop takes no skill” make no sense. That’s like a speedrunner running Portal saying that Portal takes no skill even though their personal-best is 45 minutes but the record is less than 8 minutes.
Anyway, because of this, I believe it is best practice to make the baseline difficulty for your map generally unchallenging. My reasoning is that the baseline difficulty is all you have control over. The upper bounds of difficulty in every map is a construct of the competition between players. So, whenever you decide to make a section “harder,” you’re changing your map in a way that ignores why most people are going to be playing it in the first place. Of course, if you make things too easy it becomes a very bland and unengaging experience. If your map is hard enough to engage players on a casual run, your map is probably actually hard enough. Any further difficulty and your map risks becoming more annoying to play casually, all while it probably has completely no meaningful effect on people who are running the map more seriously.
It is important to consider your options wisely when you are looking to add more difficulty to your map. The most direct way to adjust difficulty is to make a section need the player to be either more precise or more consistent. A map’s flow can also be nudged around to make a map less intuitively playable and thus harder in a sense. More precision would be appealed to by adding things like small pegs as opposed to large blocks, and consistency would basically be by adjusting how long a checkpoint is or something like that. There’s not much to say about precision other than avoid going overboard. People don’t like to hop on spikes, for example (I think it is safe to say that you should literally never use spikes). You can also go overboard in the opposite direction. Pcpie maps are generally a good example of maps that don’t require enough precision. Large platforms can be used effectively though, with bhop_epiphany being a pretty strong example. As for consistency, shorter checkpoints are generally favored over long ones. Making checkpoints too long makes your map fatiguing to play by causing unnecessary stress. Bhop_sqee is an example of a map with checkpoints that are far too long. As usual, there’s a balance that you have to find, because checkpoints that are too short may make the player feel like they aren’t accomplishing much by failing less (that is to say there’s not enough of a reward for being more consistent).
There are other ways to nudge around difficulty by getting creative. They are often simply annoying, though. For example, the section in bhop_badges where you fall through the hole. New and maybe even interesting: sure. Annoying and frustrating: absolutely. Even ignoring the fact that there’s a spike underneath, that’s still a very annoying section that exhibits difficulty with mechanics that aren’t really relevant to bhop_gameplay. This isn’t even a very strong example, but I wanted to use something everyone would recognize on a map that made an actual attempt at being high-quality.
Platform size:The size of your platforms or “blocks” can end up dominating the way your map is played, especially in the stages where speedgain is an important factor (i.e. after the player has been stopped from a teleporter, or the beginning of your map). I actually like large blocks in maps, but they are very difficult to use correctly, so I’d generally advise against using them when in doubt. The trouble is that large blocks are un-obviously taking routability and rewarding factors out of your map. Take this diagram for example:
There’s a few key things to note about the left and right side: we kept the new platforms roughly restricted to where the old platforms were, and what was previously the most obvious (and optimal) place to land has been removed for a player going this speed. On the left, the red route is basically the only sensible way for this player to do this section. On the right, the red route is still all that the player can currently accomplish, but the green route is not far out of their range, so now there is a goal. Slightly better players will also be able to do the green route to begin with, so there’s more route diversity from the map’s epoch too. What is especially important is that the section was more or less a straight line before, no matter how good or bad the player is. Now players can be rewarded by this section for being better, and a decision needs to be made by players who are coming through this section for the first time; judgement is now involved. That is all despite the fact that the player in question could only utilize their skill to its fullest on the left side, which is what makes large blocks unintuitively bad: we have effectively increased the level to which we are restricting the player’s freedom to get to the finish line as quickly as possible, yet the section got better instead of worse.
Maybe I’ve gone on about this way more than I should, but people keep on doing this to their maps and I can’t think of why other than they don’t see how it’s less fun.
Fixed points:A fixed point in a bhop map is a place that must be landed on in order to complete the map. Entire platforms are what will be considered a fixed point rather than the exact point a player lands. The most common way fixed points end up in maps is when a vertical booster is required to reach the next section. Fixed points are generally a boring addition to maps, because everyone has to do the same thing once they come to one. However, if you don’t use fixed points too often, no one will mind them popping up on occasion, and they can be used to improve the overall feeling of your map or to make the layout more interesting, et cetera. Still, a fixed point should always be placed carefully: they can interrupt the ability for players to improve their route, sometimes quite drastically. Basically, this happens because if a player wanted to, for example, stretch their route out in a flat section to save time, no time will actually be saved unless they save an entire jump before the fixed point is encountered. It is good to leave a decent amount of playing time between two fixed points in order to prevent the entire space between the fixed points from becoming completely inflexible in terms of meaningful options.
Cohesion in gameplay:In this context, cohesion is referring to a single checkpoint. Each checkpoint should pretty much have a gameplay theme for it. Bhop_sqee is an example that violates this idea. As a result, if you’re playing through the map casually and you’re not particularly good at not falling, then you’ll have to go through many attempts completing the first part of one checkpoint before you can be good enough at it to get to the second part only somewhat regularly… but now you have to learn the second part and go through the first part every time, and you don’t even necessarily know how many different “parts” there will be to this one checkpoint. Someone could spend a very considerable about of time dealing with one part of a checkpoint and then fail only because it’s their first time seeing the next part. If that can happen, there needs to be a checkpoint between those two parts. This design pattern is meant for more casual playthroughs, obviously. A sub-6-minute run of sqee definitely wouldn’t care about cohesion, but anyone else does.
Predictability and flow:I definitely don’t want to say “make your maps predictable,” because that thought process is likely to make your maps bland, but you need to understand that some level of predictability is crucial to the experience of someone playing your map for the first time (or even the first few times), and it will play a role in determining if optimized runs of your map come off as entertaining or boring. For a smooth experience, players need to be able to play through your map based on what they see while they are playing.
That’s not really what predictability within bhop maps is all about though: an experienced player going through your map for the first time is constantly planning ahead so that they can move through your map effectively. What this actually looks like in practice is that the player should be able to plan at least one jump ahead of them at all times, usually two, sometimes three, and beyond that will usually be a gray area to the player. The player will still try to make route considerations in that gray area though, and as they should; what the player does now will have an effect on what they can flow into even three to five jumps into the future. In this sense, your map should be partially predictable. An experienced player shouldn’t be consistently caught off guard by what your map presents in the near future. A simple way to sum this up is to say that your map should have a natural flow to it.
In a way, this is just different wording for the previous section on cohesion, but I’d say this is still a distinct subject. Cohesive sections can definitely have bad flow. I think that bad flow is usually created on purpose, it’s just that the mapper doesn’t realize that that is what’s making their map kinda-really suck, and it isn’t an effective way of being unique or different or whatever they were trying to achieve.
Chapter 2: The ProcessThe meta-process, anyway.
Identifying challenges:Bhop is a unique game/game-mode, to say the least, and it brings unique challenges with it. What makes maps good in virtually any other game doesn’t apply here. Even other speedrun-based games lend little insight, including surf. There’s a meta-challenge here that arises from the incredible skill ceiling and also the incredibly low skill floor: mappers often times don’t have experience being part of their entire target audience, a very good map will be fun in ways that not everyone can appreciate, and reward skills that not everyone has. Few people have played the game enough to cover all of the bases that can be covered in bhop, and even fewer of them go on to make maps, and yet fewer care if their maps are fun in all of those ways, and so on. The most useful thing you can do is develop some questions to ask themselves to prevent skimping out on some design aspects. I’ve come up with a list of things that you should consider. If you can think of more things to add to this list, please make a suggestion. Some may seem obvious, but it’s better to be too comprehensive than not enough.
Your map should:
- Be fun regardless of the skill level of the player
- Be rewarding for players that have higher skill levels
- Require a reasonable time investment to pull off a reasonably optimized route
- Not have the optimized route as the easiest route
- Provide alternative routes in the first place
- Make good use of space
- Not incorporate gameplay elements that are uncontrolled by the player
The Checklist:I should have really already said all that needs to be said on every point in the checklist. This section is just to be very clear on what I mean by each entry, what is relevant to it, and to tie together chapter 1.
#1: Your map should be fun regardless of the skill level of the player.
This isn’t generally a problem, as more skilled players will just blow through whatever you put in front of them, but this does go back to the difficulty discussion. When you are designing a section to be fun to go through as a skilled player who might be coming out of the last section with quite a bit of speed still, you just have to keep in mind that not everyone will be doing what they are doing, and provide for those people accordingly. Similarly, when designing a section to be fun casually, you need to examine how well it scales for people that will be grinding your map.
In general, it is safer to design sections to be played casually first, then make considerations for grinding/speedrunning later.
#2: Your map should be rewarding for players that have higher skill levels.
I don’t think anyone intentionally makes their maps boring to run as a high-skill player, but anti-patterns for this point are everywhere. Basically, you need to be careful about narrowing the skill gap. If you add something and this is the result, it might be a bad idea if not used carefully. For example, starting your map off with a surf or booster makes your ability to gain speed quickly irrelevant. Everyone starts the map with a high amount of speed, so the player’s ability to utilize their skills has been diminished. Again, Pcpie maps frequently do this.
Fixed points are also an important factor here, and yes Pcpie maps abuse fixed points in terrible ways.
#3: Your map should require a reasonable time investment to pull off a reasonably optimized route
I can’t help but point another finger at Pcpie here. Frequently with his maps, a player is capable of achieving their best route within the span of 15 minutes, with some crazy number like 40% of the records being within a few seconds of the world record. His maps were old news within a few hours of their release. This is a product of his maps being too easy, and also violating the next two points on the checklist, pretty much whenever available. If your map fails this check, it’s usually from a combination of other deficiencies that you might not have noticed.
#4: Your map should not have the optimized route as the easiest route
This should be an easy one to pass, but for some reason some people can’t wrap their heads around it. When you add something to your map that provides an alternative way to complete a section, or something, then it should be harder to do if it saves time, and easier if it doesn’t. In this case, requiring planning can be (and often is) a substitute for making it harder.
#5: Your map should provide alternative routes in the first place
This is more important to look out for on a per-section basis than it is for your overall map, because that’s where it will tend to get you. This issue is most apparent on strafe maps, or stages that feature little more than a sequence of blocks, but it can creep up elsewhere. You basically need to make sure that sections are actually reasonably improvable. Using large blocks can be an anti-pattern for this (see platform size).
#6: Your map should make good use of space
This mostly affects the feel of your map rather than any actual gameplay. Unused space can easily make your map feel cheaply made and give off the impression that it wasn’t designed very deliberately. We’ll explore this topic more later in the Volume section.
#7: Your map should not incorporate gameplay elements that are uncontrolled by the player
This means don’t do anything that is what many players would describe as “RNG” (it isn’t actually RNG though, usually). For example, when a player is trapped between a low ceiling and a floor and they jump, they end up jumping many times per second. On its own that is fine, but if you make it so that this section ends with the floor and ceiling both going away at the same time, the player cannot know beforehand if they will be falling or jumping when the section is over. An instance of this is found in the yellow stage of bhop_screelee. Elements like this end up punishing players that have done nothing wrong, which is unacceptable.
Testing your map:Specifically, getting useful feedback from other people who are testing your map before its release. The first thing is that testers almost always need a bit of guidance in what to actually look for, so tell them what you want to hear about. As a mapper, the number one thing you need them to test for is flow. Flow is hard to test for on your own because you can’t erase the fact that you, the mapper, know where everything is before your first playthrough. Difficulty is also an important area because of how subjective it is. Make sure that your testers understand what you even mean by flow and difficulty. This is also when you should ensure that your map performs well on different setups, and try to get in touch with someone that has an accurate monitor to test lighting (more on this in Misc).
Handling reception:Community feedback isn’t useful unless you’re willing to be completely honest with yourself, because the layperson does not know how to give feedback, and they probably struggle with putting these thoughts into words too. You probably released your map on gamebanana and half of the reviews rated it very highly. That doesn’t matter. First of all, most people use a rating philosophy in which they start at 10/10 and then deduct stars as they identify mistakes. That would at least be semi-useful if the average person knew how to critically analyze a map. Few mappers know how to do this, let alone some random player. Even experienced players simply do not understand the nuances of map design, because no one takes the time to try, so when a map is just average they won’t know how to backup a rating that says your map is average. The next step in their thought process is likely “Since I don’t know what’s wrong with it, it must be nearly perfect. What more can I ask for in a map that I can’t find the issues for in the first place?” You have to be very aware of people who rate maps like this, because these people generate at least 90% of the feedback you will get.
So the first thing you should do is pay no attention to the overall rating of your map. In fact, all you should really do is look for detailed reviews that fully explain themselves.
Chapter 3: Graphics
Lighting:Lighting is probably the most important thing that determines how your map will look and be perceived. Many new mappers make the mistake of thinking that since their map isn’t fulbright, and all lights were added and adjusted manually, the lighting should be good enough for the community. That is a terrible assumption. One thing you should strive for is having every light used have a source that can be located by the player. What I mean is that light isn’t produced from thin air in real life, and it shouldn’t be in your map either. Having lights in places simply because you need it to not be dark and then not adding an associated physical source leads to the illusion of fulbright, and players thinking about why your map looks so generic won’t quite be able to put their finger on why that is. You are working too hard lighting your map to allow players to not really notice that it isn’t fullbright. Take a look at bhop_chalenjour_v2 for an example of a map that had far too much effort put in, but ends up feeling cheap mostly from poor lighting (that map has other visual issues, just focus on the lighting right now). On the flip side of this are maps by Tony Montana: bhop_lego2 and bhop_interloper are incredible examples of proper lighting, among other things..
Volume:This is more or less an extension of #6 on The Checklist. Bhop_challenjour_v2 is an example of poor use of volume, too. There’s lots of open space where nothing is going on except for the walls, floors, and ceilings. There’s just nothing there. In all fairness, the creator of this map says he hit the brush limit or something, if I recall correctly. But still, rooms shouldn’t be big just for the sake of being big. If you’re doing that in an attempt to create a massive sense of scale, that is the equivalence of saying your painting has a large sense of scale after putting some lines in the center of an otherwise blank canvas that takes up an entire wall. Massive scale is awesome, but a giant and nearly empty cube will not usually achieve that. Think about open world games that try to achieve large scales. If it was a barren landscape, it wouldn’t feel very big at all; it’s the fact that there are details laid out extensively that leads to the game feeling large, not simply that it is, in fact, large.
It’s also important to avoid cramping the player. Players typically want enough space to move comfortably because, well, that’s how bhop is played. Environmental details are essential to a visually appealing map, but obstructing gameplay with them is a nuisance and makes your map play awkwardly. That’s not to say that details can’t be within the playing field, or that restricting movement can’t be used effectively, you just have to do well in deciding if you’re being annoying or not.
Textures:The most important thing to be said here is to train your eye for detail. The details you should be looking for are tiling issues and compression artifacts. Compression artifacts are pretty easy, really, it’s just a pattern (or patterns) you need to learn to identify. This site is a nice little tool that lets you compare different lossy formats so that you can see exactly how it affects the image. Once you can easily spot compression artifacts, it’s basically like opening pandora’s box and now you’ll always be frustrated by jpgs if quality is your thing. If quality isn’t already your thing, you need to at least pretend like it is when you’re mapping. Bhop_lego2 is probably the most notable slip-up in texture quality, especially the map is otherwise excellent. The map still manages to look great despite the incredibly obvious compression artifacts. It’s doubly disappointing in this case because the textures could have been easily improved with some simple editing due to the simple nature of the subject (you know… legos).
Tiling problems is when a visual pattern occurs after a texture is tiled over and over again on a single surface. What looks normal in a single instance of the texture can create a grid pattern after tiling, and this is a frequent problem in modded textures/maps in all games, often even in AAA titles too. Tiling is generally a difficult thing to deal with while also being a very obvious blemish. If you’re not making your own textures or willing to get dirty with what you’re working with, I believe your only option is to basically randomize the orientation of the texture so that it will look like a reoccurring feature instead of careless mapping. Make sure you view walls from some extreme angles to bring out any patterns that might not be noticeable if you just look at it head on.
Bump maps! You should definitely make an effort to use bump maps. If lighting is most important for look and feel, then this is probably second. This is what takes your map out of the 90s and into the future. For performance reasons, you probably shouldn’t use bump maps on anything that the player won’t get reasonably close to. It’s probably a good idea to make a non-bump-mapped version of textures for things that will always be far away. If you have a texture, but no bump map for it, you can probably create one on your own, the process of which is covered in the link in the next paragraph.
Finally, consider texturing on your own. The worst that can happen is you give up, but you’ll probably just have fun or something. Path of Exile developers put together a nice run-down of their process for making pseudo-realistic textures a while back, and it’s a good place to get started. It’s more of a technical process than an artistic one.
Chapter 4: Misc.
Basically a list of terrible ideas.
Do not theme sections around a color to the point where blocks share the same tone as lighting. Notable example: most maps by m4dara. This is ugly, low-hanging, uninspired visuals. I’d even say it’s fatiguing to look at because your eyes have to strain to be able to pick out rapidly moving patterns of what is really a bunch of the same hue.
Avoid highly saturated lights in general, especially if they are being used to light a room. Saturated lights can be used to add visual appeal if they are secondary to what makes a room visible. Subtle colored lights that meet surfaces at sharp angles can make the bump maps pop, and otherwise bring out the features of a room.
Please do not use solid textures for everything. Solid textures have their place, but it isn’t everywhere in every map. Yes it is easy and it looks pretty okay, but it is so old at this point. Solid textures have been used to build surreal environments in the past (especially when mixed with natural environments, such as in bhop_0), but please try to find another way if that is your goal. For example, bhop_interloper achieves a surreal environment by integrating the unnatural geometry inherent to bhop into an ominous and otherwise apparently natural formation. The key to a surreal theme is to make the players ask themselves “what is this place,” and solid textures are no longer effective for this.
Do not test your map with non-default brightness settings. Almost all maps require the highest brightness settings in order to be visible at all in parts that are supposed to just be dim. Even then, monitors that use IPS panels produce color more faithfully than TN panels (which are more popular in the bhop community due to their ability to refresh faster), and your map likely looks even darker on standard monitors. Due to this, many maps are too dark, even when played as brightly as possible on de-facto standard monitors. Test with monitor gamma at 2.1, and on an IPS if possible.
Avoid placing targets off-screen. For example, do not place the next block around a corner. This does not introduce difficulty, it introduces annoyance, and nearly guarantees a fail regardless of skill. However, do not consider optimized routes with this advice, as it’s really all the same to them, and it’s not likely to improve your map in any way.
Do not double-prefix your map. That means don’t use kz_bhop_* or bhop_kz_* or anything like that. First of all, very, very few people who play auto bhop want to play kz as well, and vice-versa, so if your map includes any notable amount of kz, it is just kz and not bhop as well. Some people are still upset that kz isn’t just called bhop, but that’s just a semantics argument and they need to get over themselves. Double prefixing has been used to convince server owners that they should also have kz maps on their bhop servers, probably as a means to push kz back into the view of people who don’t want to play it. So yeah, don’t do that, because it makes you an asshole.
Double prefixing also has implications on how your map will be supported on momentum. If your map has a bhop prefix in it, game settings will be reflective of that, plus prefixes might be a deprecated convention eventually.
Boosters that launch you into the air, if destined for an elevated platform, should boost you the same height above the target platform as any other boosters that also target an elevated platform in the same map. This makes it so that the player can identify where they’re supposed to land based just on how high they were put in the air. Doing otherwise will not just make that impossible, but it will also deceive the player.
Do not use mpbhop triggers. For the uninformed, mpbhop triggers reset you for standing on platforms for too long. There’s a lot of downsides and no upsides for this feature. First of all, hardly anyone stops on a platform in order to finish the map. Second of all, even if they did, they still had to stop to do it, so who cares? They punished themselves for not being able to do the map without stopping. But even then, that kind of situation is rare on an auto bhop map, the kind where it’s at all beneficial to stop and prestrafe instead of just strafing in place for a while. The ultimate sin with these triggers is putting them on a slope that people need to jump on: going too fast on a slope causes a surf, which makes this type of map broken, not just bad. There is no reason to use these outside of kz.
Map music should stop permanently when snd_restart is used by the client, which will also allow it to be blocked by the client all together while not disabling all sound. I don’t know anything about adding soundscapes to maps and why some maps satisfy this suggestion while others don’t, so I guess I’ll leave that to you to figure out.
Ladders are a questionable addition to your map at best. Think very, very long and hard if you’re considering using them for anything other than transportation. It’s subjective and all, but ladder strafes are just disgusting if you ask me.
Avoid checkpoints that are likely to throw the player back into a previous checkpoint if they fail. You could do this by somehow stopping the player when they are teleported back, by arranging your checkpoints in such a way that you’ll be thrown somewhere else, or putting the tp location so far ahead of the last checkpoint that you won’t be thrown far enough (this will only work in certain map types). Another increasingly popular solution is to change the teleport location of the previous checkpoint’s trigger upon hitting a new checkpoint, and resetting all the triggers to their initial state when you go back to the start of the map. This works very well in practice, but it’s a pretty brute-force method, which will hopefully be streamlined by new entities in momentum so that it can be used on more casual mapping projects as well.