I've never really seen any modding guides out there even though this is such a crucial part of the ranking process. I've been wanting to do a guide for a while, but was waiting until I got consistent positive feedback on my mods. I hope to make this a thread to point beginner (and perhaps advanced) modders to, even if it's just for refreshing and revising what they already know.
Do keep in mind, despite me doing what I can to remain global about everything, these are still my views. It's fine to disagree with them, and feedback on this guide is welcome. It's fine to point out factually incorrect data as well. What's not fine, is calling my views "wrong" simply because yours differ. That goes directly against the point of this guide.
Another note is that you're expected to have some basic knowledge on mapping before you start modding, which includes having read the ranking criteria.
Modding The Basics
What is modding?
Modding in itself isn't very hard. All you need to do is open up someone's map in the editor, and point out flaws and places where the mapper could improve their mapset. Basically, modding can be seen as external polishing. That is, the polishing of one's mapset by external influence, in this case in the form of verbal advice.
This is, modding summarized. This is what modding is supposed to be. But what do we see in most mods? For me, it's generally a case of people pointing out "This is wrong" "Fix this" "Add NC here" "This looks weird", etc. And in the end this doesn't do much. Most mods are brief - which isn't wrong in itself, but they are lacking as well, and this is a problem. Many people will try to help, with serious benevolent intentions towards the mapper, but they won't know how, or what to look for.
So, if we compare what modding is, in most cases, to what it's supposed to be, we get different results, and that shouldn't be what we're going for here.
So then the next question arises: How can we change our modding, or our attitudes towards it, in order to align with what it's supposed to be? Or, in other words, how do I make my mod useful towards the mapper? How do I get the mapper to accept and apply my mods? What makes one mod "good" and another mod "bad"?
I'll be addressing each of these questions in this tutorial, one by one, and will try to remain as objective as I can. I won't be telling anyone what to do - I'll only be suggesting ways to do it better. Which is one of the most important steps to modding: Approach
What are the "steps" to modding?
Since modding is arbitrary and context-dependent, so should the steps be. So I'll keep it simple. Modding can be broken down to comprise of 7 steps, in no particular order:
And why are these skills applicable in real life? Because, in essence, modding is just helping someone. To help someone you have to use the right approach, you have to be social, you have to be adaptable, friendly and insightful. So even though modding may seem like a waste of time, "it's just a game lel", it can actually help you improve yourself for things that are entirely unrelated to osu, while also helping someone else (and thereby indirectly the entire community) by improving their map in a way that is best for them.
But what if what the mapper is doing is just plain wrong?
First of all - there is no "right" or "wrong". Believing so will ultimately lead you to believe that you are right and everything that doesn't fall within what you consider to be right will be wrong - you can see why that doesn't work.
No, there is no right and wrong, but there is functional and dysfunctional. The difference between these and "right/wrong" is that they're object-oriented, not perception-oriented. Something is functional even if you think it isn't. But something is right only for as long as you think it is. Therefore, we will next be exploring functionality, rather than what's "good" or "bad".
What's important to note, though, is that no matter how "horrible" a map looks, it isn't. A map can never be "objectively bad" because "bad" is just a feeling, it's synonymous with dislike, disgust, and aversion. So when you think a map is bad, it's because you feel aversion towards the patterns in the map, and that says nothing about the map itself. Maybe the patterns are too unfamiliar for you, and therefore they feel awkward. Or maybe you're already biased against the mapper, and nothing they can do will improve your image of their maps. It is very important to step aside from these biases if you want to do proper, clean modding. That is why I look at the map from a functional perspective; by merely asking, "How can I help this map become more like what the mapper hoped it could be, while making it more rankable according to the RC?"
If you do that, then your own opinions will just become useful side tools that you can use to help you in expressing an objective observation, rather than being the objective observation, or attempt at it. You'll go from "this looks weird" to "What exactly was the purpose behind this pattern? Wouldn't it work better if you tried <x>?"
This change in perception, and therefore approach, can be incredibly useful, and it's something to keep in mind as we explore what makes a map functional.Map Functionality
What is functionality?
For starters, let's define it.
Functional: Everything that is consistent with the rest of the map, can be considered enjoyable to play for the map's designated player, matches the music's intensity, feel and rhythm, and does what it was intended to do.
Dysfunctional: Everything that isn't functional.
Designated player: The imaginary player for whom the difficulty has been designed. In other words, for an [Easy], the designated player would be a complete beginner, whereas a 7 star expert would have a top-tier designated player. The purpose of this concept is to make sure that your map is always within human bounds. You should always limit your highest skilled designated player to the highest skilled player in the game.
In other words, this means that everything that is "Functional" works, and everything that is "Dysfunctional", doesn't work. Of course we could define "Work" here and keep redefining it forever, but since modding is done from perspective and is subject to subjectivity, bias and misconceptions, let's just define "works" as "works for you". That's right - there's no universal measuring stick. You measure by your own standards since those are the only standards you have. Remember that.
So, how can we determine whether a map is functional or not?
There are many things to look at - and there are tools to help us look for them.
(AIBat is such a tool, though you'll have to be careful to pay attention to unsnapped greenline warnings (they'll show up even if snapped to 1/12 or 1/16) and bg warnings. The program is outdated but very useful.)
I'll be going through several pieces of a map that one can look for while modding, and mentioning specific questions you can ask yourself while looking for them. You don't have to ask these questions and you're free to look at things your own way. These are merely suggestions.
Inherited timing sections
One of such things to look at is, as mentioned above, also known as greenlines.. They're the sections that can toggle kiai time, change sv, hitsound sample packs, and volume.
Do they have a purpose? Does their purpose fit the mapper's intention? Are they snapped? Is there too much kiai? Could there be more places to add a kiai? Are there any duplicates?
Uninherited timing sections
Another thing to look at, also known as redlines, and these are pretty important. They have to do with the bpm and offset, so they're very important. Personally, even if the offset is off by 1ms, I'll mention it, but I've worked with music for many years now so it's easy to hear when the metronome is off for me, and I don't recommend it to people who aren't experienced either musically or with osu!timing.
Is the offset perfect? Is the BPM perfect? Should there be more redlines? Are there too many redlines? Should the time signature be different?
Rhythm
Now this is very arbitrary and context-dependent but there are still some global things here. Rhythm is the aural and tap-tactile aspect of the game.
Does the map's rhythm match the song? Are the hitsounds fitting? Are the volumes okay? Is there any over- or undermapping? Is there a good reason for such over- or undermapping? Are there any rhythms that would feel better or play more smoothly than the current ones?
Patterns
I'll stop mentioning the arbitrary things from now on - it should be clear by now what aspects of mapping do, and do not depend on context. Patterns are the visual and aim-tactile aspect of the game.
Do the patterns play well for the map's designated player? Are they aesthetically alright? Is there any way in which they could suit the mapper's intentions better? Does the map's feel match the song's feel? Are there any over- or underdone patterns? Are there any patterns that would feel better or play more smoothly than the current ones?
Settings
The map's settings are important too. You can bring them up by pressing F4 or through View - Song Setup.
Do the settings accurately match the map's difficulty? Does the approach rate support the note density within the map? Does the OD properly match the approach rate? Does the HP properly match the OD and amount of combos? Are the combo colours fitting? Does the mapper have any unnecessary options checked? Is the stack leniency fitting? Is the metadata correct?
Spread & Set (QATs love this one)
Is there a proper balance between the difficulties? Is the lowest difficulty beneath two stars? Has there been a fair workload distribution among contributing mappers in accordance with the RC? Are there any unused hitsound, image or storyboard files? Is the mapset too large in size? Is metadata consistent across all diffs?
Audio
Is the mp3 of good enough quality so as to not sound sloppy or fuzzy? Is it between 128 and 192 kbps? Are there any hitsounds that don't meet the RC? Is the hitsound quality alright?
These are all very important things to look for while modding. In fact, if you've looked for all these things in your mod, there's a fair chance you're on your way to creating a decent mod.
However, there are a few last things to consider before just blurting out whatever you think about the map. Let's go back to those 7 steps we mentioned earlier, and get a good handle on what they truly mean. Then we'll summarize this entire tutorial, and you should go out and start developing your modding!An in-depth look on the 7 aspects
To recap, here are 7 fundamental aspects of functional modding, as I mentioned before:
So how do you change your approach? Which approach is "best"?
Sadly, the true answer is that there is no best approach. Rather, there are many best approaches, and it is up to you, as a modder, to decide which one, based on the context of the map, your mood, and the mapper you're modding for.
If you're cranky - don't try and make a cheerful or silly mod. It'll just look forced. But don't take out your crankiness on the mapper either. Being cranky doesn't necessarily mean you shouldn't mod, just use it to your advantage! Cranky people tend to be more attentive towards flaws and mistakes, and that in return leads to them getting irritated sooner. Not a pleasant state to be in, I know, but... It's very useful for modding! You will spot any potential mistakes far easier than someone in a good and accepting mood - however, you may not express this in a very friendly and acceptable manner.
This is where approach comes in. If you know you're cranky, use it to gain more insight on those flaws, but use your restraint to prevent any harshness in your wording, and your adaptability to stay relevant to the mapper. It may cost a lot more effort than simply yelling at the mapper for "doing it wrong", but the precision, usefulness and pleasantness of your mod will drastically increase.
See how all these concepts connect? It applies in any situation. Pay attention to all those concepts, use them to your own and the mapper's advantage. Combine them in a way that will allow you to get the best out of yourself no matter the situation you're in.
Now, I do want you to remember that being capable of modding in any situation doesn't mean you should mod in every situation. Most of you probably won't, but I'd still like to mention this. Don't beat yourself up when you're not up for modding. Know when to say no.
Summary
The essence of modding is to bring the best out of the mapper's map, and to do so you must bring the best out in yourself. The best way to do this is by developing your approach towards it, and learning to adapt yourself. Always remain aware of the context wherein things are happening - because oftentimes this is the only thing that's actually relevant.
In other words, stay relevant, be respectful, be kind, be honest, be insightful, be adaptable, mind your approach, mind your wording, mind the effort you put into being precise and know where to restrain yourself, and you will be an excellent modder in no time.
What I wrote here is basically how I mod, there's more to it and I might edit/add/fix latersince I'm tired but this should give a good basis to any beginners out there. Feel free to ask any questions or give suggestions.
This is an example of how I mod (my most recent one)
Do keep in mind, despite me doing what I can to remain global about everything, these are still my views. It's fine to disagree with them, and feedback on this guide is welcome. It's fine to point out factually incorrect data as well. What's not fine, is calling my views "wrong" simply because yours differ. That goes directly against the point of this guide.
Another note is that you're expected to have some basic knowledge on mapping before you start modding, which includes having read the ranking criteria.
What is modding?
Modding in itself isn't very hard. All you need to do is open up someone's map in the editor, and point out flaws and places where the mapper could improve their mapset. Basically, modding can be seen as external polishing. That is, the polishing of one's mapset by external influence, in this case in the form of verbal advice.
This is, modding summarized. This is what modding is supposed to be. But what do we see in most mods? For me, it's generally a case of people pointing out "This is wrong" "Fix this" "Add NC here" "This looks weird", etc. And in the end this doesn't do much. Most mods are brief - which isn't wrong in itself, but they are lacking as well, and this is a problem. Many people will try to help, with serious benevolent intentions towards the mapper, but they won't know how, or what to look for.
So, if we compare what modding is, in most cases, to what it's supposed to be, we get different results, and that shouldn't be what we're going for here.
So then the next question arises: How can we change our modding, or our attitudes towards it, in order to align with what it's supposed to be? Or, in other words, how do I make my mod useful towards the mapper? How do I get the mapper to accept and apply my mods? What makes one mod "good" and another mod "bad"?
I'll be addressing each of these questions in this tutorial, one by one, and will try to remain as objective as I can. I won't be telling anyone what to do - I'll only be suggesting ways to do it better. Which is one of the most important steps to modding: Approach
What are the "steps" to modding?
Since modding is arbitrary and context-dependent, so should the steps be. So I'll keep it simple. Modding can be broken down to comprise of 7 steps, in no particular order:
- Approach - Your mentality before you even begin modding is crucial. How do you approach it? Helping the mapper, or yourself?
- Wording - The words you use highly affect how the mapper will interpret what you say. How carefully do you pick your words?
- Effort - A mod you only put 5 minutes into can't have much content. How much effort are you willing to put in?
- Precision - Vague and general mods are mods anyone can give. How unique is your mod? How precise is it?
- Insight - You need some level of insight into mapping if you want to make a good mod. How well do you understand mapping?
- Adaptability - You have to be able to adapt to the mapper's style or all you'll be doing is forcing yourself on them. How flexible are you?
- Restraint - You should be capable of holding back something you like to maintain what the mapper likes more. How impulsive are you?
And why are these skills applicable in real life? Because, in essence, modding is just helping someone. To help someone you have to use the right approach, you have to be social, you have to be adaptable, friendly and insightful. So even though modding may seem like a waste of time, "it's just a game lel", it can actually help you improve yourself for things that are entirely unrelated to osu, while also helping someone else (and thereby indirectly the entire community) by improving their map in a way that is best for them.
But what if what the mapper is doing is just plain wrong?
First of all - there is no "right" or "wrong". Believing so will ultimately lead you to believe that you are right and everything that doesn't fall within what you consider to be right will be wrong - you can see why that doesn't work.
No, there is no right and wrong, but there is functional and dysfunctional. The difference between these and "right/wrong" is that they're object-oriented, not perception-oriented. Something is functional even if you think it isn't. But something is right only for as long as you think it is. Therefore, we will next be exploring functionality, rather than what's "good" or "bad".
What's important to note, though, is that no matter how "horrible" a map looks, it isn't. A map can never be "objectively bad" because "bad" is just a feeling, it's synonymous with dislike, disgust, and aversion. So when you think a map is bad, it's because you feel aversion towards the patterns in the map, and that says nothing about the map itself. Maybe the patterns are too unfamiliar for you, and therefore they feel awkward. Or maybe you're already biased against the mapper, and nothing they can do will improve your image of their maps. It is very important to step aside from these biases if you want to do proper, clean modding. That is why I look at the map from a functional perspective; by merely asking, "How can I help this map become more like what the mapper hoped it could be, while making it more rankable according to the RC?"
If you do that, then your own opinions will just become useful side tools that you can use to help you in expressing an objective observation, rather than being the objective observation, or attempt at it. You'll go from "this looks weird" to "What exactly was the purpose behind this pattern? Wouldn't it work better if you tried <x>?"
This change in perception, and therefore approach, can be incredibly useful, and it's something to keep in mind as we explore what makes a map functional.
What is functionality?
For starters, let's define it.
Functional: Everything that is consistent with the rest of the map, can be considered enjoyable to play for the map's designated player, matches the music's intensity, feel and rhythm, and does what it was intended to do.
Dysfunctional: Everything that isn't functional.
Designated player: The imaginary player for whom the difficulty has been designed. In other words, for an [Easy], the designated player would be a complete beginner, whereas a 7 star expert would have a top-tier designated player. The purpose of this concept is to make sure that your map is always within human bounds. You should always limit your highest skilled designated player to the highest skilled player in the game.
In other words, this means that everything that is "Functional" works, and everything that is "Dysfunctional", doesn't work. Of course we could define "Work" here and keep redefining it forever, but since modding is done from perspective and is subject to subjectivity, bias and misconceptions, let's just define "works" as "works for you". That's right - there's no universal measuring stick. You measure by your own standards since those are the only standards you have. Remember that.
So, how can we determine whether a map is functional or not?
There are many things to look at - and there are tools to help us look for them.
(AIBat is such a tool, though you'll have to be careful to pay attention to unsnapped greenline warnings (they'll show up even if snapped to 1/12 or 1/16) and bg warnings. The program is outdated but very useful.)
I'll be going through several pieces of a map that one can look for while modding, and mentioning specific questions you can ask yourself while looking for them. You don't have to ask these questions and you're free to look at things your own way. These are merely suggestions.
Inherited timing sections
One of such things to look at is, as mentioned above, also known as greenlines.. They're the sections that can toggle kiai time, change sv, hitsound sample packs, and volume.
Do they have a purpose? Does their purpose fit the mapper's intention? Are they snapped? Is there too much kiai? Could there be more places to add a kiai? Are there any duplicates?
Uninherited timing sections
Another thing to look at, also known as redlines, and these are pretty important. They have to do with the bpm and offset, so they're very important. Personally, even if the offset is off by 1ms, I'll mention it, but I've worked with music for many years now so it's easy to hear when the metronome is off for me, and I don't recommend it to people who aren't experienced either musically or with osu!timing.
Is the offset perfect? Is the BPM perfect? Should there be more redlines? Are there too many redlines? Should the time signature be different?
Rhythm
Now this is very arbitrary and context-dependent but there are still some global things here. Rhythm is the aural and tap-tactile aspect of the game.
Does the map's rhythm match the song? Are the hitsounds fitting? Are the volumes okay? Is there any over- or undermapping? Is there a good reason for such over- or undermapping? Are there any rhythms that would feel better or play more smoothly than the current ones?
Patterns
I'll stop mentioning the arbitrary things from now on - it should be clear by now what aspects of mapping do, and do not depend on context. Patterns are the visual and aim-tactile aspect of the game.
Do the patterns play well for the map's designated player? Are they aesthetically alright? Is there any way in which they could suit the mapper's intentions better? Does the map's feel match the song's feel? Are there any over- or underdone patterns? Are there any patterns that would feel better or play more smoothly than the current ones?
Settings
The map's settings are important too. You can bring them up by pressing F4 or through View - Song Setup.
Do the settings accurately match the map's difficulty? Does the approach rate support the note density within the map? Does the OD properly match the approach rate? Does the HP properly match the OD and amount of combos? Are the combo colours fitting? Does the mapper have any unnecessary options checked? Is the stack leniency fitting? Is the metadata correct?
Spread & Set (QATs love this one)
Is there a proper balance between the difficulties? Is the lowest difficulty beneath two stars? Has there been a fair workload distribution among contributing mappers in accordance with the RC? Are there any unused hitsound, image or storyboard files? Is the mapset too large in size? Is metadata consistent across all diffs?
Audio
Is the mp3 of good enough quality so as to not sound sloppy or fuzzy? Is it between 128 and 192 kbps? Are there any hitsounds that don't meet the RC? Is the hitsound quality alright?
These are all very important things to look for while modding. In fact, if you've looked for all these things in your mod, there's a fair chance you're on your way to creating a decent mod.
However, there are a few last things to consider before just blurting out whatever you think about the map. Let's go back to those 7 steps we mentioned earlier, and get a good handle on what they truly mean. Then we'll summarize this entire tutorial, and you should go out and start developing your modding!
To recap, here are 7 fundamental aspects of functional modding, as I mentioned before:
- Approach
- Wording
- Effort
- Precision
- Insight
- Adaptability
- Restraint
So how do you change your approach? Which approach is "best"?
Sadly, the true answer is that there is no best approach. Rather, there are many best approaches, and it is up to you, as a modder, to decide which one, based on the context of the map, your mood, and the mapper you're modding for.
If you're cranky - don't try and make a cheerful or silly mod. It'll just look forced. But don't take out your crankiness on the mapper either. Being cranky doesn't necessarily mean you shouldn't mod, just use it to your advantage! Cranky people tend to be more attentive towards flaws and mistakes, and that in return leads to them getting irritated sooner. Not a pleasant state to be in, I know, but... It's very useful for modding! You will spot any potential mistakes far easier than someone in a good and accepting mood - however, you may not express this in a very friendly and acceptable manner.
This is where approach comes in. If you know you're cranky, use it to gain more insight on those flaws, but use your restraint to prevent any harshness in your wording, and your adaptability to stay relevant to the mapper. It may cost a lot more effort than simply yelling at the mapper for "doing it wrong", but the precision, usefulness and pleasantness of your mod will drastically increase.
See how all these concepts connect? It applies in any situation. Pay attention to all those concepts, use them to your own and the mapper's advantage. Combine them in a way that will allow you to get the best out of yourself no matter the situation you're in.
Now, I do want you to remember that being capable of modding in any situation doesn't mean you should mod in every situation. Most of you probably won't, but I'd still like to mention this. Don't beat yourself up when you're not up for modding. Know when to say no.
The essence of modding is to bring the best out of the mapper's map, and to do so you must bring the best out in yourself. The best way to do this is by developing your approach towards it, and learning to adapt yourself. Always remain aware of the context wherein things are happening - because oftentimes this is the only thing that's actually relevant.
In other words, stay relevant, be respectful, be kind, be honest, be insightful, be adaptable, mind your approach, mind your wording, mind the effort you put into being precise and know where to restrain yourself, and you will be an excellent modder in no time.
What I wrote here is basically how I mod, there's more to it and I might edit/add/fix later
This is an example of how I mod (my most recent one)