Sonic Superstars: A New 2D Sonic Game (Fall 2023)

I feel like speculation on the game's development should take into account that the only other next-gen game Arzest worked on is Balan Wonderland.

Every other game they made was on the 3DS or mobile phones. So it's possible they just don't have the experience or assets to create a more polished game atm, because I feel like the game's issues wouldn't be corrected with more time like Frontiers' would.

 

This game is not pushing some absurd poly count or fidelity outside of their scope of experience when it comes to assets.

 

The fact that it is not outside of their scope is exactly my point.

Performance and stability wise the game runs really well. In terms of graphics, it's not impressive, which is where the fact that they mostly made 3DS games come in. The multiplayer is significantly more flawed but that is outside of their scope as small-time, single-player developers

My ultimate point is that the problems of the game's presentation wouldn't be inherently fixed with more time and budget, though if the game DID lack those elements, they should definitely have them next time. The game seems closer to what Arzest/Sonic Team wanted compared to other Sonic games.

 

One week post-release aggregate update:

Opencritic: 74 "Fair", 57 reviews, 64% of critics recommend

Metacritic (PS5): 75 "Generally favorable", 50 reviews

Will do another update either next week or by the end of this week.

 

But a lot of the game IS polished, some part are less polished than others and where "rush" seems an evident point for why it's that way, Balan had better storytelling than Superstars, so it's not that they can't or that they didn't have experience for it, but some parts of the game just seems outright missing and not finished

Little things like "why in Cyber station stage, when the characters are pixelated, it gets undone when they use their emerald powers", that's not a lack of experience or asking them to make some earth-shattering graphics, that's just basic oversight, or them not having enough time

At any case, this is the best game they have done and it looks really nice in general with few exceptions, the art style is strong enough

 

Hedge's speculation is about bloating the game towards the end of its production involving feature creep to pad out the game and justify the price. Presentation wasn't even part of the speculation. There isn't some void of technical information lost in translation when jumping from 3DS hardware to current hardware in terms of asset development. If anything, they would have had a smoother experience since the limitations from the hardware are far more relaxed than their 3DS days. Asset development would have been the least of their worries here. Personally, I don't think the game is that awful looking either so that's the least of its problems.

A 4 player mode, developing an entirely separate gameplay mode with its own multiplayer logic involving splitscreen, an online component and all the networking woes that come with it, a seperate campaign for a new character. Time and money would have absolutely help in the development in those areas.

 

Exactly. I actually think the base game, and especially the early stages, were competently and well designed, and I think the visuals on 4K platforms are even solid (though not perfect). The game looks much better on full, high end hardware and actually seems more targeted to it, IMHO. Is there evidence that they didn't have as much experience with higher end visuals? Sure. But I don't think that's the primary way in which the game was rushed.

The inconsistency of the OST, the sometimes placeholder sounding music, unbalanced difficulty, severe co-op bugs, and rushed and poorly telegraphed story in the latter half are all typical symptoms of a game that went through development crunch for a deadline it wasn't ready for. It frustrates me BECAUSE the first half of the game is exceptionally well designed with clear intent, actually, regardless of the visuals. I'm looking at this from the POV of a map designer and tester, something which I have some experience in. It's even more obvious when you track the other Sonic titles SEGA has recently released and sponsored. Even little things like the poor, awkward implementation of EGS on steam (which they quickly took steps to somewhat fix, even) point towards a very rushed product.

Given the track record of Azrest, incompetence is certainty not an impossibility (maybe they themselves overpromised and underdelivered), but I see the core game as strong enough to point to some actual strength on their part as a developer. The ideas behind the bosses are solid. Again, the actual stage design in the main campaign is deliberate and well planned out for the classic style, with a few, more rare, less fun spots (all in the second half).

A game that literally gets progressively less fun to play for most of the audience is almost certainly a rushed, crunched game.

Heck, even Mania was pushed out in a somewhat incomplete state given things like the weirdly missing level transitions. Encore mode may not be the best addition, but that year of extra dev time really allowed for some nice upgrades in the free patch.

I guess this is redundant by now, but someone needs to talk with SEGA about rushing their projects to meet pre-holiday or anniversary deadlines. Origins Plus could've been a big holiday title on its own if they did something like put it up for 30$ in November/December and let it appeal to the mass market. Frontiers DLC3 could've helped push more units too. The 2 games on sale at 30$ each would've driven sales to the mass audience just fine and still hit a 60$ price total and sold enough units to make a solid profit.

As the game is, I think it will detract more people from buying it than it otherwise should have. And that really is too bad.

 

Not that I agree that the developers who made Sonic Superstars are unable to grasp modern development because they previously worked on 3DS games, but this isn't true. The 3DS has no programmable fragment shaders, which is where the vast majority of modern graphics development occurs. The 3DS's graphics pipeline is half of what the modern programmable pipeline has been going all the way back to the Xbox 360. The modern programmable pipeline requires a vertex shader and a fragment shader -- the vertex shader is where you transform vertices to their real world position (the 3D equivalent of plane scrolling hardware) where the fragment shader is where literally all special effects come from, it's what determines the final pixel output. Every modern graphical effect occurs in the fragment shader. That the 3DS doesn't offer any form of programmable fragment shader is indeed a major difference from all other modern graphics hardware and, assuming that was *all* you knew, you would indeed have a lot of trouble coming up to speed.

Modern Assets aren't just, like, textures and models. What people call "materials" are actually a combination of programmatically generated uniform buffers (memory in CPU space to "control" your output), vertex buffer objects (data baked directly into the vertex object), and fragment shaders. Fragment shaders are where basically all the magic of modern assets happen. They are, for lack of better terms, "special effects."

To be succinct, the 3DS's fragment pipeline is fixed function. We left fixed function pipelines like 20 years ago. Fixed function knowledge doesn't translate to programmable pipelines. Everybody complained when modern openGL occurred, because for a lot of people, it meant starting over. It's like the difference between a video display *controller*, and a video display *processor.* One is a bunch of knobs and dials you turn and then press the "go" button, the other is an actual program you write and compile and is executed in steps.

But, again, I very much doubt there are graphics programmers out there who have never touched a fragment shader before, because, again, this has been the graphics industry standard for going on multiple decades now.

FWIW I think Superstars looks incredible, especially at 4K 120hz.

 

Very cool info. Learned a lot. Thanks for that Cooljerk.

Arzest definitely isn't lacking in experience with modern standards and they be foolish if they didn't bother to brush up on modern standards. They've worked on projects outside of 3DS hardware so I don't think inexperience is to blame. I think we're all in agreement here that the game doesn't look bad nor is the main source of the problems people have with the game.

Speedstrat Video Dropped



I thought Knuckles jump height was the same as everyone else in this game?

 

Oh man, the more I replay the normal stages, the less happy I am about the implementation of emerald powers.

I think it was @foXcollr who mentioned how centralizing Bullet was, and this is really a symptom of what I now think is one hell of a disappointment. They're just challenge skips at this point, and they're so clumsy about that, too. They're Get Out of Jail cards when you don't want to be bothered with something, and only ever work in speficic ways. There's just so little contingency to it, and lock-and-key is very much alive here. For whatever Superstars does, it's not a wrong approach, but... it's boring. All in all, it's boring.

Bullet is centralizing because it's the only one that is potentially useful in all stages, can reliably be used without a fixed goal in mind and isn't a puzzle solver. Yeah, the game will tell you to use it sometimes, but it's more of an indicator that there is something above than anything else. You still have to find out what it is. The others, though? Water only even works in like three out of eleven stages; Ivy is poor man's Bullet when you want to go up (or when the game tells you to), and doesn't work as well; Avatar is basically a "oh fuck this I'm done" button for bosses; Slow does see more use outside when it would have been just a key, but it often actively works against you after it helps you with whatever it was, and you have to wait it out; Vision does nothing outside the areas the game tells you to use it; and Extra... I like the individual powers it brings, but they are basically combat abilities? You don't get much pervasive use out of them -- or, at least, I haven't.

Of course, it was I who fooled myself believing they would have different effects depending on the situation. I'd have loved Water to prevent crushing deaths by turning you into a puddle, or to change how Sonic interacts with a surface according to how that surface interact with water; I'd have loved Ivy to spawn different kinds of plants depending on the surface or biome on which you activated it; I'd have loved Vision to allow you to see a whole-ass level around you, of which you can only ever catch a glimpse -- even if it came at the expense of background/foreground switching. In short, I'd have loved discovery, ingenuity and contingency to be a key part of their usage. A sense that you will never get enough of them -- there will always be a new way to use them. I would have even loved to see passive effects that completely alter stages you've been through before. That would have been a worthwhile addition to classic Sonic gameplay.

But oh well, Superstars isn't that game. That's not what it set out to do, and the problem-in-itself ends up being mostly about balance in the challenge-skipping function they have.

 

One weird thing about Nintendo's graphics chips for a long while was they conceptually traced back to the Gamecube. The gamecube also didn't have programmable shaders, it had a fixed function pipeline. But it did it's graphics on a separate chip called the TEV unit. The TEV unit was a fixed function pipeline, that was more flexible than other fixed function pipelines, because it exposed a number of control points that you could use to "tune" your final output. It wasn't programmable, but it was controllable via parameters. So you couldn't outright invent new effects, but you could tweak the existing effects to do newish things.

The Wii continued using the TEV unit, and the WiiU used a similar concept, and the 3DS's fixed function fragment shader is conceptually very similar. It wasn't until the Switch that Nintendo finally came on board with the full, modern, programmable pipeline.

Over on Microsoft's side of things, they've been doing things the modern way from the very beginning. The Xbox was the first console with a fully programmable modern pipeline. It's kind of like the model of all modern game consoles.

Sony for a very long time did the opposite of all of this. They had powerful math co-processors devoted to vertex transformations, but the main secret of a lot of Sony's machines is the combined CPU memory and VRAM. Normally, in modern architectures, they are separate, so your GPU can touch VRAM, and your CPU can touch system memory, but having your CPU touch vram was slow. So you rely on your GPU to do all the graphics separate from the CPU, the CPU can't actually do the calculations on your VRAM output. The PS2 and PS3 were completely the opposite. Since they shared VRAM and system memory, the CPU itself could touch the buffer that holds the final pixel output for the screen with no penalty. So while the PS2, for example, had no programmable shading pipeline, it didn't need one, because you could run actual programs on your normal CPU that could touch the buffer just like a GPU. That's how they designed the PS3, in fact. The original idea was it'd have no GPU at all, everything would be handled by the CPU directly affecting pixel output in memory. You'd devote cores of your CPU to become GPU-like. Obviously, given the way the PS4 wound up being designed (normal programmable pipepline), Sony's CPU-driven model didn't win the war.

Today, everything works like the original xbox did. Nintendo, Sony, Microsoft, Valve, Apple, etc. They all use the modern programmable pipeline.

 

You make a good point, but this begs another obtuse question: why not eagerly recompile shaders rather than than "just in time"?

Starting this task right after saving changes to graphical settings and checking for invalidated shaders during time spent in a menu just seems intuitive. I'm not saying "it's the obvious solution", but more that it seems like the lowest-effort solution. If I were feeling lazy and just wanted to ship something so I could go home to my wife and kids, it seems like the fastest way out the door before rush hour traffic: write a single C function (e.g. recompile_old_shaders) which iterates through the entire list of shaders and recompiles if the config is different, then add it as an event hook on game pauses/main menu/loading the next scene/pretty much wherever you feel like it. You could even store timestamps in SQLite to avoid opening a file an extra time for each shader (a very expensive syscall for thousands of small files).

I should stop here before I get any deeper into "if I were Nikola Tesla this is how I would have designed my 3-phase induction motor", but lazy algorithms usually take more effort to write than eager algorithms.

 

You can do this. Many games will offer to allow background compiling of shaders, and it's a universal option for vulkan shaders in steam. However, there are reasons why this is not always feasible. The whole purpose of shaders is to be programmable, and dynamic, as opposed to old static graphics pipelines. In the old days, your graphics card had a fixed number of functions it could do, and vertex formats it could read. With a programmable pipeline, everything can be created from scratch by the programmer. In the old days, if you wanted a special effect your card couldn't do, or you wanted to use a vertex format your card didn't support, you were SOL and had to buy a new card. Today, the programmer creates their own vertex formats from scratch by allocating memory buffers on the GPU, and sending data to them, and they do special effects by writing programs that interpret the data in ways they choose. But that flexibility is a double edged sword. You can create cascading effects, shaders which rely on the output of previous shaders. Or you could create dynamic vertex formats that work with dynamic shaders, new information that you didn't expect to work with, that is all handled programmatically. There are instances where you simply cannot pre-calculate all the permutations of shaders, because the number of combinations is infinite. You can only tackle them as they come to you, because it's impossible to predict what data you'll encounter, or how to handle it.

And even if the permutations aren't infinite, they can still be enormous, and could take *hours* to pre-compile. Like, not one or two, but multiple dozens of hours to work through all the permutations. And you're just going through all the permutations, many of which you'll never encounter or need. Imagine downloading a game, installing it, then needing to have your computer sitting around drawing 100% of your CPU for half a day to calculate out gigabytes of shader data that you don't even need. And then you change the a graphics setting in your menu because you don't like the performance, and everything needs to be recompiled again. People wouldn't take it.

Also, again, compiling these shaders eats up your CPU, so everything your cpu does will be slow during those compilation times. You wouldn't just let it run in the background, it'd (ideally) work as fast as your CPU would allow, taking processing time from other tasks.

It's just not feasible.

EDIT: I should note that part of this is specifically due to the way Vulkan and DirectX 12 work compared to OpenGL. With old OpenGL, going through the permutations of shaders was much more viable, because you could write one shader, and have uniform buffers (think of them like dials on a machine to adjust settings) that the CPU could adjust, and it'd be one single compilation. The shader would take the uniform information into account when it's run. In Vulkan (and DX12), to speed things up, every possible tick on the uniform buffer dial becomes it's own shader. You don't have 1 shader with a dial, you have multiple shaders, one for every dial position. The more control and flexibility you have over your shaders, the more permutations. Because of this, compared to OpenGL and old DirectX, Vulkan and DX12 have exponentially more shaders to process. This is why shader compilation stutter suddenly seems like a thing when it wasn't before, there are simply way, way, waaaaay more shaders than ever before, for performance reasons.

the ultimate take away from this is that your GPU is a secondary computer running essentially in parallel from your CPU. It's like in your PC, you have two computers running simultaneously, and they communicate through a very slow bus. The whole purpose of VRAM and shaders and such is to pass off as much of the computation from your CPU to the GPU, so your CPU is free to do other things. Those uniform buffers I mentioned, every time you change them, your CPU had to communicate to the GPU the change, and that communication is very slow. So the fix that Vulkan and DX12 offer is to give the GPU access to every variable combination possible, so it doesn't have to ask the CPU for the information it needs. The information it needs is already there, on the GPU. It just merely has to select the correct state.

 

It's not terribly related to the wider discussion but this is one of the reasons that they don't have lighting effects for bullets in the Metroid Prime remake. What they did initially was something similar to what SA2 (DC) does for lighting effects in Iron Gate and Egg Quarters, just manipulating the fog table gradient for the level to be much brighter based on the distance of the fired bullet. The Switch does have a dynamic pipeline but you get like 4 shaders total, so they didn't have, in effect, any room on the Switch GPU to implement that.

As for 2D graphics analogies, the closest similarity is to paletted graphics and being able to create gradient/motion effects like the waterfalls and lava in Sonic games by manipulating the palettes. The graphics don't actually change but the colors they look up do, and it's significantly less data to transfer to manipulate the effect. I vaguely recall seeing mention of the super sonic effects in RSDK being surprisingly hard to implement simply because the lack of a concept of palettes (vs a high-bit color space that anything in the framebuffer can be) made effects like the glow hard to implement. Fixed-function meant many things were easy to implemnt (and some very easy to do) at the obvious cost of flexibility.

I would presume the low number of available shaders is also why the Switch version of Superstars doesn't have the background depth of field effect.

The general switchover to dynamic pipelines in GPUs happened right around 03-04 as I understand, right around the same time that SADX and Sonic Heroes got PC ports. Why does SADX have the setting for fog emulation? Because, as with Metroid Prime, the fixed pipeline included it and so very new graphics cards might not support it. Sonic Heroes references the change obliquely in saying that some newer GPU drivers may make the game look different from intended. I played the game on some old Dell prebuilt with limited graphics capability and stuff like the water surfaces and ghostly fog (from the end of Mystic Mansion) looked a little nicer than what they do on modern hardware. Playing the game on a more modern computer, a lot of the special effects wind up just kinda looking like erratic line patterns because the implementation of those effects is completely different between the two philosophies of pipeline.

Anybody looking for more info on the subject may want to check out this post, which includes a very helpful diagram of the fixed function pipeline which lets you see where effects like texturing and fog come into play. It's a pretty thorough explainer, though, dedicated to discussing standardization of libraries/implementation in the context of WebGL, and goes into more detail about several things CoolJerk has mentioned as well as lots of stuff not directly tied to them.

 

Minor correction, all of the RSDK games use a palette system with palette cycling.

 

True -- I mean they had to be implemented through software/shaders and weren't 'free' the way they are on older dedicated-for-2D hardware. (In fact, that's why the old mobile port of Sonic CD had weird water effects; it's using a hardware renderer that wasn't suited to the task).

(Incidentally, and maybe unsurprisingly, texture palettes were supported on a number of early graphics cards that were designed to combine 2D and 3D hardware in a single card. There's a handful of games like Final Fantasy 7 that basically require the feature to look right. Because earlier versions of Windows weren't designed with 3D hardware in mind and graphics memory was much more limited than it is today -- basically, these cards existed for the same reason the Saturn was the way it was. As you might expect, some of these cards' support of the various standardized APIs like Direct3D and OpenGL was limited. Compare with the 3DFX cards of the day which only supported 3D, though the Glide API they were built for was actually quite comparable in features to the OpenGL standard.)

 

You might actually be quoting me, and that was a misconception I had since the only version of the RSDK I had looked at was the old old old android version. Taxman clued me in that it's not the case anymore. That old Android version came from a time when most android phones did not have access to modern OpenGL ES, and thus couldn't really use shaders. So what they'd do is render each texture in every palette so they could pick between them.

Every version of RSDK after and including that same version (just not the android port) uses shaders (or perhaps direct framebuffer manipulation) for true palette simulation. There are a few ways you can do this with modern programmable pipelines, but the basic gist is you use what is known as a Texture Storage or Data Texture depending on the glsl version you're using. It is, for all intents and purposes, a texture where each pixel is a just a single color representing the final pixel output color. When you upload your texture to VRAM and sample from the texture using a Sampler2D, the value it extracts from the texture should be in r8 format, meaning only a red subchannel that is 8 bits big. You take this red channel value as an index into the sampler2D to look up which specific pixel color you want to sample, and use that color as the output value. The end result is paletted look up.

You can actually use this kind of indirection multiple times. I.e. have a "chunk" texture, where each pixel is a value that you use to look up into "block" textures, where each pixel is a value you use to look up into "tile" textures, where each pixel is a value you use to look up into a "palette" texture. In this way, you can program your modern GPU to behave exactly like old hardware. Here's an example of me doing just that, I'm rendering Emerald Hill Zone here straight off of a dump of Sonic 2 from my retrode, not changing the data on the cart in anyway, just interpreting it directly from my programmed GPU:



I'm not 100% sure this is how RSDK does it, but I wouldn't doubt it's how it's done since it's very performant.

 

What the actual fuck is Trip's final boss. Who programmed this?

 

I played the whole story mode with my wife. His jump height is exactly the same.

 

6.8 GB patch on Xbox, v1.07, haven't checked other platforms yet. Can't find patch notes. Wonder what it changed?