Log in
Location: Home  Community Forums  General  On Styles, Exclusivity, and the Dangers of Guidelines 
On Styles, Exclusivity, and the Dangers of Guidelines
Page: 1 of 1
Post Reply  0 Observer
On Styles, Exclusivity, and the Dangers of Guidelines 2018-02-15 17:26:46  
I never tag a style on any of my courses. I’m sure I could pick something if I really wanted to, but it would never feel quite right. On ManiaExchange, there are 9 styles to pick from (10 if you include the catch-all “Race” style). Most of my courses tend to feature a large amount of different corners, so “Tech” would probably best describe my maps. I’d love to tag them as such, but they aren’t quite tech. They aren’t designed to fully test the player’s ability to handle the vehicle and its varied techniques. My maps are usually just trying different things and trying to be fun to play.

But maybe I’m misunderstanding what “Tech” really is. Unfortunately, “Tech” is a very nebulous term. At what point is a map considered a tech map? Do they need to exceed a certain number of corners per minute? Do they need to use at least X different technical skills? Even then, when does it transition from tech to speedtech? The problem with categorizing maps is that there isn’t any empirical definition for any of these styles. What defines a tech map changes as time passes and builders come and go. This goes for all styles. We, as a community, subconsciously define what makes a map fit a particular style.

Unfortunately, this can lead to differing opinions. We can’t just point at a definition and say “This, truly, is what makes a LOL map a LOL map!” Sure, we all know the basic elements of what goes into any given style, but the line at which a map is part of or not a part of a style is drawn in wildly different places sometimes. To simply call any map claiming to be a particular style as not that style is a faulty statement because, to the builder, that map IS that style. But this doesn’t make the driver wrong; they just happen to have different standards for the style than the builder does. I don’t think this is something that needs to be fixed, I just think that it’s something to think about if you’re about to judge whether a map is or is not a particular style.

Standards brings me to another topic: guidelines and rules. TrackMania has been around for over a decade, and ever since its inception people have been crafting their own unique maps for the host of environments. As time passed, builders learned what made the good maps fun and what made the lesser maps boring or annoying. Some of these concepts are fairly abstract (such as a map having “flow”) while others are more concrete (if your course is respawnable, then have the respawns facing in the right direction).

These concepts are not bad to abide by. These guidelines keep us from making insanely stupid mistakes when making otherwise fine maps. However, there is a danger with guidelines that we may forget: there will ALWAYS be a time where an exception can and should be made. You have likely heard the phrase “Rules are meant to be broken.” At first, this seems like a terribly faulty statement; rules are there for a reason, after all. However, I think this phrase is meant to make us think about that. Rules have a reason for existing, but rules in and of themselves aren’t the reason they exist. If abiding by a rule does not serve its purpose, then you might as well ignore the rule entirely.

Let me give an example. One “rule” of good trackbuilding is this: Never use a reverse booster. This is a very simple rule, and one that makes sense. Reverse boosters generally indicate that the author is incapable of creating a route given the player’s current speed. A good builder can decelerate the player naturally, using elements like corners, slopes, and stunts. A reverse booster feels unnatural, especially in Canyon or Valley; when one of those vehicles hits a boost, the effect lasts for multiple seconds. If you’ve ever played a late Turbo map, you understand how weird it is to drive while under the effects of a reverse boost. Besides this, if a player is at too low a speed, they may be unable to pass the reverse boost. I know I don’t like it when a map blocks me off because of a couple minor errors.

Despite knowing all of this, I made a map that uses a reverse boost anyways. It is a low speed boost as well, meaning that one mistake could turn the booster into a wall. This map features the CanyonCar, meaning that the boost is in effect for multiple seconds. By definition, this reverse boost should be a terrible piece of map design. Should the map be in competition, such a travesty would surely burden the map, right? This map of mine is MTC - Phoenix Dive. It ranked 2nd out of the 10 maps in the MTC it was submitted to, and multiple voters noted that the reverse boost was actually quite an enjoyable element in the track.

So why does this particular instance stand out as good design despite convention? It’s simple: following the rule would not serve its purpose. In this case, I needed the player to be REALLY slow before a drop; go too fast, and you’ll jump past the downward chute to miss both the fun experience and the necessary acceleration. Even putting the start right before this drop wasn’t slow enough, and this was before MP4 brought the speedy starts. In this case, it was not my incapability to cause the player to decelerate naturally so much as it was a near impossibility. Likewise, the lingering effect was used to enhance the course; it gives a sort of tension as you slowly creep to the edge, the effect ending as you get onto the slope and begin a violently fast acceleration into the meat of the track. Being blocked by the booster is still a fair concern, but since it’s right at the start it won’t ruin an otherwise alright run. While the rule to avoid using reverse boosters is certainly a good one to follow, this particular instance was one where ignoring the rule by understanding why such a rule was in place resulted in a far better map than arbitrarily following said rule.

This is the danger of restricting ourselves to build within certain constraints. If we do not understand WHY a rule is in place, we can never hope to find the instance where it would make more sense to ignore the rule. This goes back to why I do not assign a style to any of my maps; by building a map specifically for a style, I may end up arbitrarily restricting myself to a certain set of rules without recalling why those rules are in place. By thinking of styles in a more fluid sense, I can instead make a fast-paced map featuring tech and dirt elements while also putting an emphasis on the mediatracker to create a more dynamic feeling map. It might break some rules here and there, what with some odd, bumpy transitions and whatnot, but that’s part of what makes trackbuilding fun. We’ve been given an editor with nearly infinite possibilities, and I’d love to see what can be done by breaking down conventions.

This video talks about video game genres, but pretty much goes over what I’ve talked about in more detail: https://www.youtube.com/watch?v=Lx7BWayWu08
MTC Host
MTC Host
Location: US
2018-02-20 13:51:35  
If a reverse booster is used well, the player wont even notice it's there. So that's a kinda silly "rule"

Overall, screw the rules. Build what you want and never ever let anyone tell you how "a track should be."
Take constructive criticism, of course, but always do what you want. That's what makes the editor so wonderful.
There is no end to what you can do in it. Limiting yourself because someone says this or that aint right is bad.

On the flipside, if you do build tracks for something specific, then there is a certain expectation on how they should work. ESL and the like. (Not that I ever really took that much to heart either.)
Quad Bike Racer
Location: NO
Beetle Racer
Location: DE
2018-02-26 17:04:36  
That wholly depends on what is after the antiboost on the road. Can easily be made uncutable.
Quad Bike Racer
Location: NO
Page: 1 of 1 Post Reply
© ManiaExchange (mania-exchange.com, mania.exchange) 2024. • Terms and ConditionsPrivacy Policy Top  •  Report a Problem