Discussion: How would you design loops in SRB2 levels?

[FuegoDeCera]

With 2.2 (hopefully) around the corner, it is safe to say that the potential of the slopes and revamped momentum in this game will be a giant improvement on the level design, which can now resemble the Sonic series more accurately than ever before. That said, I am much more concerned how Sonic Team Jr., as well as the many experienced level designers among us, will tackle one of the most iconic staples of the Sonic franchise: the Loop.


Ever since its introduction in 1991, there have been many takes on its design, from both official and fan-made projects, on both 2D and 3D perspectives. Sooner or later, once it's possible to create the loop (and Sonic Team Jr. changes their opinion on this matter, which is unlikely understanding their valid reasons), amateur and veteran SRB2 level designers would be more inclined to use it on future creations.


The question is, what are your preferences when it comes to creating or running through loops. Would you prefer them slim to observe the rest of the level ahead? Or maybe wide to include more objects to interact with? Would you prefer them with automation to prevent coming to a halt? Or without automation, relying only on your momentum to keep going?


The purpose of this discussion is not to declare the best and worst loop designs ever, but to express our experiences with Sonic games to come up with a healthy opinion on why we would choose a particular loop design.
Let us discuss!

 

[Lliteqiel ꙮ]

So I wanna bring up a major issue that comes to me the most often in terms of discussing loops in SRB2 and that would have to do with the sheer... number... of sprites required.

Spoiler: kinda big image

The picture is presented here to give a visualization of just how many sprites are needed for loops to make sense in this game's 8-direction format. Multiply this by the amount of walking and running animations too, and it equals absolutely every spriter discouraged from making a character ever. You can actually cut a little bit from this, as in, the potential "standing still" sprites, because it doesn't make sense to stand still within a loop unless you're Sonic 4, but still. (Yeah there are MD2s being a thing but shut up)

If loops are to be in this game, they'll be nothing but mere decor or an aesthetic in a level. Provided the previous information, nobody's gonna be running through them... and they're only really useful in 2D anyway. You can just jump in the center of them to skip all of that. Getting the proper physics for them to function correctly is also just a coding conundrum. Maybe, a wizard or several can forge loop code within the next few milleniums, but I doubt it. And I know people that doubted slopes, but figuring out loops is an actual whole other dimension.

(i think the best loop designs are uh... non-automated, and in the shape of a circle)

 

[Zwip-Zwap Zapony]

- That said, I am much more concerned how Sonic Team Jr., as well as the many experienced level designers among us, will tackled one of the most iconic staples of the Sonic franchise: the Loop. -

I don't have any source to back the following claim, but if I recall correctly, Sonic Team Jr. has said that they won't use loops as obstacles/gameplay pieces in the vanilla levels of version 2.2.

One of the reasons being that it would either force the player into a curled up ball (visually bad) or require every character to have an additional set of all sprites drawn (bad for the artists and all custom character creators) for being on 45-degree and 90-degree slants, with all 8 rotations of that (which may be drawn as just 5, 3 of them then being mirrored to the other side afterwards), of course. (See the image in Llitechiel ꙮ's post.)

The closest that you'll get might be a "hacky" setup simply featuring reverse gravity on the upper half (combined with rolling through it, not running), as seen specifically in an April Fools' thing from 2017.


Custom levels may feature sloped loops with "automatically move around in a set path" "tubes" around the loop for players to appear to roll through the loop, as has already been done at least once for 2.1, maybe earlier too, even before slopes were introduced. But actually running through them with proper physics, let alone proper visuals, will probably not happen (outside of "simple" proofs-of-concept, likely in 2D mode (which allows rotating existing side-on character sprites without having to draw new ones) rather than 3D... also as has been done at least once for 2.1).


And gameplay-wise... I'd honestly rather not have loops, due to how they'd interact with the camera in 3D and how it'd just be slower to go up and down them than just skip past beside the path.

 

[Lach]

Loops will not be any more possible in 2.2 than they were in previous versions of SRB2. The existence of wall transfers makes existing setup methods easier and more visually appealing, but that's about it.

Unlike most 3D engines, our game treats floors and ceilings as entirely different structures from walls. We have so much code that makes assumptions based on this distinction that we would probably need to freeze all production of any other features or levels to restructure it enough to just allow for proper loops, and that's before taking into account the monumental changes that it would likely necessitate for our maps, renderer, camera, etc. This is not really desirable as our game is very content-oriented. Introducing slopes delayed 2.2 for years—imagine how long you'd be without new vanilla content for if we shifted our focus to making even more complex engine changes.

 

[clairebun]

Even if our engine was well-fitted to handle loop de loops, I have yet to see an execution of the gimmick in 3D that impressed me. In the vast majority of 3D Sonic games, loops are scripted or automated to a point where there is minimal interaction with the loop. Where they aren't scripted, you usually have the choice of just hopping in between the loop rather than circling up and around to the other side. In the classics, you at least had to aknowledge the loops by building up enough momentum to get through them, but in 3D space that dynamic is lost.

There is one instance I can think of where a loop would provide compelling gameplay, and that is if there was a fence or something in between the loop de loop that extended half-way up to the loop -- that way you'd have to travel up the loop in order to get above the fence. But then you can also use half pipes and the sort to accomplish the same thing, so....

 

[Rumia1]

Before I start this wall of text I'd like to say that this is purely what I believe would need to happen from a practical standpoint so that animators wouldn't have to tear their hair out if the addition were to ever occur.

In terms of the rotations image above, I think that that is slightly confusing and misleading. We can easily cut it down. Not every sprite needs as many rotations as in the picture, as you're not going to be standing (or maybe even walking) on a diagonal slope. I think you could simply make it so that you can only run (or force running frames) up a wall or a slope greater than what the game can currently handle, or spin up one if you're going faster than your runspeed. Since you can simply mirror sprites in order to handle most rotations, and we can simply limit rotations to 90 degree angles because that's easy, then allow me to make a new image based on what would actually be needed. We should definitely skip drawing frames that look at the player's feet because nobody is ever going to see that unless you do some crazy transparent textured FOF slope shenanigans, and nobody wants to do that. With that, our reference for needed rotations looks something a bit more like this:

Doing it this way would add another 24 run frames to the already daunting task of making at least 177, assuming we stick to the standard four frame run, which doesn't sound too bad, but it still is a burden nonetheless. Perhaps if we ever got native sprite rotation code it would also make it easier to rotate things on diagonals as well, making the transitions look a bit more polished without creating extra work.

...Or we could just switch to 3D models and put every spriter on the forum out of the job or force them to take up a new one, and I'm fairly certain nobody wants that.

 

[Mystic]

This is all kinda a moot point because no matter how many times that GIF is reposted, it's just a silly reverse gravity trick. Essentially it's two half-pipes on top of each other, and the top one uses reverse gravity. Here's what it looks like when you aren't just spindashing through:

Could this design be used in a stage with reverse gravity someday as a gimmick? Possibly. It's not a classic Sonic loop, though, and I think everyone here is vastly underestimating just how much of the game treats floors/ceilings and walls as entirely separate things that do not mix.

 

[Panda.]

Well in my Sonic Heroes remap, I have been trying to make the player land safety on the ceiling loop slope and switch angle too but I was finding this impossible because of this physics' abuse, the player will never touch the ceiling after being on ground (thrusting to the opposite speed <deactivated in GIF> because if the player is walking and not running then he must be fallen from the ceiling loop) even if both heights are the same parallel.

 

[clairebun]

This is all kinda a moot point because no matter how many times that GIF is reposted, it's just a silly reverse gravity trick. Essentially it's two half-pipes on top of each other, and the top one uses reverse gravity. Here's what it looks like when you aren't just spindashing through:

Could this design be used in a stage with reverse gravity someday as a gimmick? Possibly. It's not a classic Sonic loop, though, and I think everyone here is vastly underestimating just how much of the game treats floors/ceilings and walls as entirely separate things that do not mix.

Theoretically speaking, I think it's possible to convert this into a classic loop through hardcode by creating a flag or variable which registers the player as upside-down, but not in reverse gravity. Ideally it'd basically treat the player as if they're glued to the ceiling whenever they touch a ceiling slope, but apply the same slope physics that would occur if the player was right-side up (slow when moving up ceiling slopes, speed up when moving down). Controls would be inversed while upside-down in order to allow for seamless movement from floor to ceiling, and if the player slows down too much, falls off, or moves back into a floor slope, the flag is unchecked and the player gets flipped right side up again.


While my comments about loop de loops being a not particularly useful structure in 3d still applies, this type of code behavior would be useful for creating level segments where the player is expected to build and keep enough momentum to run on ceilings, a la vertical half-pipes, or the sloped ceilings in Sonic 3's Carnival Night zone. In the future I think this might be behavior worth looking into.

 

[Rumia1]

I would say try to replicate the quadrant method explained here but in 3D.

Basically, when the player meets a wall and the slope he's standing on is within ~15 degrees of verticality, transfer them to the wall and move them vertically, applying gravity towards the ground (pulling Sonic down towards the floor unless he is running fast enough to overcome it) and then flip the standard rules when they run onto a ceiling, making the player drop if they aren't going fast enough (probably 3/5ths of Sonic's runspeed, play with this value a bit though), and then they can transfer to a wall again if they run into a wall within 15 degrees... yada yada yada you read the previous wall explaination.

I would reccomend forcing flipcam in these situations if not gravflipped so the player can retain control and their momentum. Adding a slight bit of automation so they keep running at the same angle when they first flip onto the ceiling would help mitigate the need for complex camera maneuvering.

 

[SSNTails]

I have some code for this, both from Wizard/Roly Poly Putt and from about a year ago when I was experimenting with real slope & kart physics in SRB2Kart.

Problem is, not only would there have to be major changes to the source code itself, there should also be big changes to some of the modding features to make it happen. Instead of XYZ and 'angle', you'd have four vectors, one for player position, and three for orientation (up, side, and forward vectors).

Also, as I very much discovered in Kart, levels would have to be changed as well to accommodate this new movement pattern.

But hey, you can always dream!

 

[glaber]

The way I'd attempt to do it would require a force spin sector going in and out for going through both ways, a gravity flip set of invisible intangable fofs that leave enough space for a spinning player to get through, possibly a teleport sector to turn the player around (needs testing), and 2 gravity flip sectors that use dissapearing invisible intangable fofs to limit the flipping.

if the loop is in the open, invisible intangablefofs that restore the gravity woould be needed all around the loop.

 

[tabu]

i think cobalt hit the nail on the head. as in that loop de loops just fundamentally don't make as much sense in 3d sonic as they did in 2d sonic. even when you integrate them properly, with all the different angles and directions the player has to work with in 3d, they can just easily subvert the momentum-based challenge they force onto you in 2d

imo a more fitting way to have the same sort of gimmick in 3d would be something like that first big ramp in palmtree panic in sonic cd where it transitions into a wall that sonic runs up for a good while. something like that but more gameplay-oriented where the player would have to build up enough speed to get sonic or whoever to run all the way to the top without losing momentum and slipping back down. obviously that'd require wall-running physics and new sprites so you can see the top of characters as they run but i think it's still a less tall order than full integration of loop de loops would be

also wall-running would just be a cool mechanic anyway lol

 

[Augus]

Classic-style loops are kinda an iffy prospect even in games whose engines aren’t actively fighting against their existence. A loop isn’t really an obstacle in 3D the same way it is in 2D because...well, you can just walk around it or hop through the middle. And having the camera stay behind Sonic’s back as he goes upside down is disorienting, you lose your place in the level which is a big issue for a platformer.

 

[azoo]

Loops kind of lose their initial purpose in 3D to an extent, but I'm gonna be real: I just like them because they look and feel cool. lmao

I really like what CobaltBW is talking about, and would be interested in seeing that.

 

[SamVision]

Loops like Sonic 3D Blast that force you into spin.