While we're at it, what about loops that behave differently depending on whether you're rolling or not? As in, rolling through the loop would break you through the top/bottom/side to an alternate route whereas running would bring you through normally. Or, one could even make ones that change paths depending on how fast you're going? In a more jungle-themed zone, a Loop in the form of a vine would actually unravel and lead you to a different path if Sonic is running around it at a certain speed. Too slow? Behaves like a normal loop.
That could work if there was a tilt in the middle intersection, like the hydrocity zone half pipe tubes or the generic ehz corkscrew. The knuckes route with the top of the player facing the camera while the sonic route is the opposite, with the non run on section facing the camera.
That would be very welcome. I'm also fonde of the idea of "phantom" loops, those that would only exist as long as you're running on them, allowing alternate routes under, above, behind, on the sides etc.
Or what about loops/tunnels that would be completely character specific? Am I the only one who would buy the fact that Sonic would spin in one general direction, while Tails, being slightly smaller, would wind up in another slightly skinnier tube... and Knuckles would barrel through tiles meant for him... seemingly burrowing his own path? I really like how Sparks brought the figure 8 loop to life as well... in that approaching the same set piece in different ways can have completely different results... something like this in character specific routes, where both routes reach the same set piece but branch off in different ways.
An important part of making sure those kinds of loops work would be having some sort of visual indicator or hint that they hide another route. I think Sonic, Tails and Knuckles have the same size rolling ball sprite (about 32x32).
Hot diggity, I -have- to try this and see how well it works. xD The main trick is setting up the layers to work properly. I learned today that you can use loops to seamlessly hide the boundaries of a boss arena. Take this for example: Spoiler The player comes in from the top left. Once they've run through the loop and down to the boss, running back up that same wall will cause them to move around the corner curves instead. Since this particular boss has an attack that covers a wide horizontal area, running up the curves on either side can buy them some time while waiting for the boss to finish attacking. Heck, if you had Robotnik in a similar area and he couldn't be attacked from underneath, spindashing up the wall and dropping down on him would be a viable strategy.
Please do. I must see this in action. I am also thinking of implementing something like this in my project as well. I know this... but Tails "appears" smaller. you could play off that,
So it would seem there are people writing actual academic stuff about Sonic level design. I obviously shouldn't be surprised, since that's something I intend to do myself, but indeed I am.
Definitely an interesting choice for an academic topic. Although I appreciate the idea of studying level design in minute detail from an academic perspective, it seems like it would only benefit someone who wants to be a game designer but is not an avid gamer themselves, or someone who wants to build a game that's far outside of a genre that interests them. You learn far more about game design from being an objective, intelligent and experienced player of said games, and you learn about it faster as well, than if you were to simply read about it in textbooks and articles. (Although sometimes those articles could offer you a bit of insight into something that you didn't think about before.)
I love the diagrammatic approach they take to level design. It's an interesting form of analysis ("cells" and "portals") that I often use in the architectural field, but it never occurred to me to use this technique when designing 2D stages for my own project! There was one other thing that caught my eye: Wasn't this somewhat extended at some point in this thread, (at least in the context of Sonic games) as objects that impede progress, like loops? I remember this being discussed this before.
I like the objective approach and the search for a common language, too. Separating a level in rhythm griups makes levels easier to see through. Although there are, of course, instances with which I disagree quite a lot with some concepts (restricting "obstacles" to stuff that causes damage being one of them).
A decade bump, but I was recently informed that (apparently) people still talk about this thread and use it as a citation in Sonic level design discussions. But by God, I wish they didn't. It's crazy to think I wrote this in 2012; Sonic Generations had barely happened, Sonic 4 had just recently come out, and Episode 2 was just around the corner. A lot has changed in the world of Sonic; Lost Worlds, Mania, Forces, Frontiers, Superstars have all released since then, and have either challenged, downplayed, or outright changed how Sonic level design has approached. I think most importantly though, my own perspective (and no doubt everyone elses) on the topic has changed and grown significantly. With how much our own knowledge of Sonic has grown in a decade, I think re-addressing this topic would be worth the time. There's a lot of stuff I would flat out rewrite and change in the original post, but at the core I think it just needs to be redone entirely from the ground up (it doesn't help that most of the images are broken and I've long-since lost the originals). My question is though... Is this something the forum would be interested in? If anything, I think such a guide should be conjured up as a more collaborative effort, or at the least consulting in its content. I'd certainly like to breathe new life into the topic and bring new perspective to how Sonic level design does work, things to do, things to not do, and add information about how Mania and Superstars approach classic level design (that said, I haven't even played Superstars yet, never played Forces either but I have a feeling its classic levels don't add much to the discussion), but I definitely think I would need help with it. What do y'all think?
I don't agree with much in the opening post, especially with the focus on macro instead of micro (which I'd argue is much more important)... but it's still well-written and well thought-out and I'd love to see it expanded and brought up to date.
I concur. A *lot* of people don't seem to understand the rules of sonic level design the way they might for Mario level design. Maybe exploration of the 3D games' level design might warranted on some level. What makes 3D Sonic level design work and what doesn't? What's the through line between the 2D stages and 3D stages design-wise? I think there is one that hasn't quite been nailed down. If the throughline for Mario is iteration on a single idea to encourage mastery, what's Sonic's?
Personally I'm as interested in this topic as I've ever been, so much so I tried to bring my own perspective somewhere else in these forums recently. So whatever you want to share, I want to read. I recently read through this thread, the discussions in it, and the 3D Level Design ome you made. I think an overhaul is welcome since we have gone through so much in 10 years and our understanding of level design has evolved a lot, but there really should be no pressure. Your thread gets talked about in places you'd never expect (it's listed as an Essential Game Design Article here, for example) because it's pretty much all we have, not only in Sonic circles but pretty much anywhere. There is surely academic output about level design, but what you can find just searching for it is extremely scarce -- let alone with a focus on Sonic. But I think talking about level design is an Herculean task, especially in Sonic, because talking about it means talking about the game in general. So I like that you put the effort to describe what level design elements can or can't do (looping Y axis, springs, elbow ramps etc) and I'd like to see this taxonomy complete. However, and both agreeing and disagreeing with @DigitalDuck here, there's a distinct lack of a framework that's capable of explaining why you think things are the way they are. So the macro isn't properly accounted for yet. Why do we change routes? How do we perceive them? But to achieve that, having another framework that is capable of describing the moment-to-moment gameplay might work better, and analyze things from the perspective of a player. Anyway, I like this thread and I'd love to see it bumped an updated again.
