Why there is no loop physics in SRB2?

For example, you could add 3 extra running sprites, or 5 sprites or even 7 sprites!
 
I honestly don't know. There are so many things that SRB2 added that Doom didn't have to begin with. SRB2 does what Doomn't, pretty much.
 
Then... why would you claim "Advanced movement, that wouldn't take extra work" and double down on it when you are unable to back the statement? :oh:
I never said nor did that. I said making rotating sprites is easy.
 
That wouldn't look good, not in a 3D space, nor in a multiplayer scenario.

Rotating sprites through rollangle would be limited to a 2D space - The screen's - and the result would look extremely weird if you were facing the loop and the looping player from the front or the back (or you were playing with chasecam off).
Post automatically merged:

I never said nor did that.
But... you did (last sentence)? Then you doubled down (first sentence).
Or were those responses to something else?

I have highlighted exactly how that particular topic went. Just as a refresher.

saga.png
 
Last edited:
Probably the easiest solution is to just program them in as a 2D mode exclusive and rotate the running sprites accordingly, though I do still feel as though there's potential to the idea of simply reusing rolling sprites for while on 3D slopes. It's not the most elegant solution, but it is (at least on paper) visually consistent and works around the problem of needing to make new sprites. This would probably need to be triggered by some sort of flag to use spin state sprites without actually being in spin state, and could also provide confusion as to whether the player is allowed to touch badniks without taking a hit, but it's a starting point at least.

I'm more concerned with how the loops themselves would need to be programmed, and the potential for this same programming to break sections of levels that don't actually have loops. Would there need to be a special loop flag to tell the game to apply loop physics within a certain area to prevent loop physics from applying when they aren't intended? Then there's always the potential for seemingly unrelated bugs to pop up and things that used to work breaking because of the new code, and it can easily lead to worries of a spaghetti code situation.
 
Probably the easiest solution is to just program them in as a 2D mode exclusive and rotate the running sprites accordingly, though I do still feel as though there's potential to the idea of simply reusing rolling sprites for while on 3D slopes. It's not the most elegant solution, but it is (at least on paper) visually consistent and works around the problem of needing to make new sprites. This would probably need to be triggered by some sort of flag to use spin state sprites without actually being in spin state, and could also provide confusion as to whether the player is allowed to touch badniks without taking a hit, but it's a starting point at least.

I'm more concerned with how the loops themselves would need to be programmed, and the potential for this same programming to break sections of levels that don't actually have loops. Would there need to be a special loop flag to tell the game to apply loop physics within a certain area to prevent loop physics from applying when they aren't intended? Then there's always the potential for seemingly unrelated bugs to pop up and things that used to work breaking because of the new code, and it can easily lead to worries of a spaghetti code situation.
That's impossible, no offense.
 
I don't get how making new sprites is tedious, I really don't. It takes some time, but I'll be satisfying to see it in action after all.

Spriting well takes an insane amount of time, work, and the skill to make it as great as it can be. Games with paid staff don't put this much effort into drawing this many sprites. And you're really telling us to go back to putting Xtreme Sonic or UglyKnux-style placeholders to put in something as barely intractable as a shuttle loop gimmick? The only way to make this any useful would be to make a full-on wallrunning gimmick, and not only would that require even MORE sprites to do, it'd require a whole engine overhaul because the Doom Engine just does not work like that. Knuckles' wallclimb and Wildo's wallrun are more-or-less hacks with very specific purposes. And even if you did, then you would need to redesign levels again to add wallrun or even shuttle loop segments. And if loops are all you want, those dont work in 3D space very well because you can just jump through them and get through it faster, unless you put a dumb wall or gap in it, which makes the loop feel artificial. A loop in 2D can be a brief speed obstacle, or a cool rollercoaster moment for a rolling segment, but in every loop you see in a 3D Sonic game, it wows once, but is super shallow and artifical due to the hoops the game has to go through to make it work. Wallrunning would not be worth it to implement, and shuttle loops even then so.

You have no idea how much you are asking for, and how little of worth it ultimately is. Plenty of other games can offer "real" loops if you want them, but this game lacks them for plenty of good reasons. The team focused on what actually mattered, and shuttle loops do not matter.
 
Last edited:
I do think SRB2 could use more short setpieces. It's the biggest thing that's missing from SRB2's levels compared to the classic 2D games. There are a handful of the them throughout the game (the springs at the beginning of GFZ2, the big hill also in GFZ2, the giant spring across the map in CEZ1, etc), but it could use more of them. They're good for pacing and for creating memorable moments in levels.

Creating fully interactable loops is a total waste of time, but hacking something together (with zoom tubes?) to transition between level segments could work well.
 
One way to not have the sprite toll would be to use software sprite rotation while forcing the camera angle to a side view. This would probably not work well for all use cases though and it might break in multiplayer.

If the huge number of additional sprites were to be made though, the only way to do that without hair splitting would be to automate the process with 3D rendering (but 3D software use does not come naturally to all people).

The other major solution would be to finish OpenGL, make it the sole render engine, and use 3D models for everything instead of sprites, but I know Blender at least does not have an SRB2-ready .md3 export addon that works with the latest version (and Mischief 3D is outdated). It would be a lot of work regardless and you won't find a lot of developers who are just waiting for an invitation to work on a project such as this.
 
While I can accept loops as being very low on the list of priorities and even an overall end decision to not include them, I usually disagree with the specific mentality of "This thing is very simple and easy to skip so it shouldn't be included at all". There are a great many of things in the game that can be simply skipped, such as a majority of badnik encounters as well as a number of springs, entire pathways, etc. Sure, you can simply just jump through the middle of a loop to not take it and get to the end goal faster, but that's the player's choice. If you were speed running the levels then yeah, that would probably be the correct way to handle them most of the time.

What if you aren't speed running though? What if you are unconcerned with how long it takes you to reach the end goal? If a player is simply playing through the levels for exploration, spectacle, just for general fun, etc. then is it wrong to take the loop anyway just because you can? What about gameplay modes that provide incentive for collecting rings such as score/ring attack or maintaining your super form/collecting 1-ups? Loops could have more rings placed within them to collect that would be quickest and easiest to collect by taking the loop.

There are definitely reasons to take into consideration why loops shouldn't be considered a priority or even ultimately shouldn't be included at all, such as the physics and even the code potentially causing problems and being a lot of work to properly implement in addition to the work burden of redesigning stages to accommodate them, but personally I don't consider the ease in skipping them to be among these.
 
Well guys, if you are in the SRB2 Discord you may have seen that loops are a thing now.
It looks like it works by manipulating gravity. If so, it differs from a proper loop in that you don't need to gain momentum to use the loop, it simply just flips gravity when your speed drops below a certain amount. Depending on how it's used in level design, the difference might end up being negligible however.
 

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top