Chev

Speaking as a software dev, it may sound silly but it's a matter of choosing your battles. Non-plastic skin is actually surprisingly hard to do, while basic jiggling breasts pretty much are the Hello World of physics engines, to the delight of programmers everywhere.

Basically it goes like this: there are actually two rates at play here. Let's call one the frame rate, the rate at which the images on your screen change, and the other one the update rate, the rate at which the game state changes (ie the one that actually affects gameplay). Technical interlude: Non-devs don't necessarily know the difference because historically on consoles they've been coupled, though on PC they haven't. Having a fixed update rate is a highly desirable property for various math and gameplay-related reasons, but getting reliable timing out of CPUs used to be pretty tricky. Consoles solved that through vsync, vertical synchronization: since all TVs had a fixed frame rate you'd use the vertical retrace (the start of a new image) as a timer. Used to work fine except for the NTSC/Pal differences (pal TVs have a different frame rate and so the games are slower unless they've been programmed to compensate). So one frame = one update. That does mean if you unlock the framerate the game will be too fast. But on PC, where lots of monitors already had different frame rates, that couldn't be used. At first they just assumed operations took a given time and based their updates on that but that produces the problem of old games running too fast on faster computers. So they eventually went with a different approach, variable update rate: each frame "knows" how much time has passed since the last update and integrates it in its math. They just hacked away at the timers to get that elapsed time until it worked and it was good enough (and eventually reliable timers were created). This has the advantage that it works no matter what the rate is, so it's not dependent on your CPU or frame rate and again you can just vsync it. However math can go to hell, because for example two 16ms updates are not mathematically equivalent to one 32ms update, for reasons related to numerical integration. Well, devs put in compensation algorithms to keep the math under control. If you unlock the framerate, the game will update as often as it can and be more fluid. Anyway, because for some features (like physics engines) or genres (like fighting games) a fixed update rate was desirable, which leads us to the eventual solution used in them. TL;DR Fighting games like Xrd used a fixed update rate, variable frame rate approach. So whenever people are talking about frames as far as gameplay goes, they're actually talking about updates. The updates are timed to go at a rate of 60 times per second, and the GPU just grabs the latest game state whenever it needs to render a frame. So if the GPU is slower and renders at 30 or 40fps, your game will be choppy but still technically fast enough (if the CPU is too slow that's another story). If your GPU is perfectly timed (through a 60fps vsync) you'll get perfectly fluid gameplay. and if our GPU is rendering twice as fast at 120fps, well, you'll still get 60fps in practice because that's how fast the game updates. The GPU just renders each frame twice. So framerate unlockers don't make much sense for that approach. It's much simpler to talk about frames and FPS than update rate and UPS or whatever, and for practical purposes updates are virtual frames so we still use that word and it works fine.

I for one am pretty intrigued about this. I find the lack of multiplayer to be a bit disappointing but I like the overall look and I'm curious to see how well they'll adapt the LoL model to fighting games.

Super late answer, but yes and no. The theoretical answer is Yes because if you want to allow rollbacks up to, say, ten frames, then the function you call each frame, which should be one frame update, will effectively need to be able to fit one full state load, ten frame updates and one full state save. So that's at least twelve times as many things to do. The practical answer is No because, in a fighting game, frame updates and saving/loading state are really simple and fast operations (keep in mind frame updates and drawing the game on screen are separated so the graphic complexity doesn't play a role) thanks to the simple hitbox-based nature of fighting game collisions. Network-wise exactly the same amount of info needs to go through for rollback or delays so that doesn't play a role.

Since it's got a T rating, it only covers minimal blood and bloodless violence, and the description on the ESRB site indeed mentions only blood as an aftereffect of violence. Having blood spurts during gameplay would have a real risk of bumping it into the M category.

A merciless but necessary rule of netplay is that to keep synchronized your game has to slow down the same number of frames as you opponents - otherwise the delay would go up as both sides progressively get out of sync. So yeah, when playing on PS4 against a PS3 user it's quite possible you may be slowed down by them during graphics-heavy moves.

I think they'd go with reusing the existing lighting and it'd be quite acceptable. Faces are where the precise lighting is most needed and those probably wouldn't change much. A new mesh goes a long way, look at dragon install, which reuses normal animations but looks pretty different. Beyond that it's all the morphing bits that require work so I guess it'd depend. Like, even doing classic Milia costumes wouldn't be too much of a bother because they could reuse the hair, or for Zato they can change Zato and keep Eddie the same, but on the other hand something like classic helmetless Potemkin would require new facial expressions. So I don't think it'd be herculean but I do expect them to be more expensive than palettes.

Personally going from the description I think anti-aliasing would be the most likely culprit rather than load times, because it is a really easy thing to toggle and one that may have some impact on speed on PS3, but it isn't very clear at all.

They have to run at the same framerate to allow for crossplay anyway, so it'd be weird for one to have 60fps and not the other.

Thanks guys! That interview mentions buffering so I'd say it's probably gonna be BB-like, yeah. In fact as far as buffering go it's certainly possible to tell from the PSN demo (which I don't have).

A bit of a late answer, but I'd say rather than Whitesnake, White Lion could be an even more direct candidate.

Hello, I'm Chev, you may vaguely remember me as the guy who translated the Xrd graphics articles on the polycount forums. Also a developer, although not a game developer outside of hobbies. I can answer that. 2D or 3D doesn't matter for GGPO-like netcode. In fact GGPO's big thing (rollbacks to hide latency) finds its roots in FPS netcode, which is about as 3D as you can get. Rendering complexity doesn't matter either, because if your developer's a good boy his rendering and gameplay code are separated. And they sure as heck are in UE3! What matters is how fast you can make a save state of your gameplay, and how fast you can run your gameplay (well, the number of players too, but that's a non-issue here). That is because what a rollback does is restore the state of the gameplay back to when the late input was supposed to have occured, and then fast-forwards back to the present frame. The rule of thumb for both is: how many things are there running around that matter for gameplay? For fighters, not that many. Usually two to six fighters, their projectiles and weird things. Maybe fifty objects tops, a hundred if you wanna go crazy. That makes it a good genre for rollbacks. What 3D affects would be collisions and physics, but there are nowhere enough things on screen for it to be a problem (and for that matter even in fully 3D fighters physics are kept simple for gameplay reasons). And, well, you can actually go pretty high, arcade bullet hell shooters can be rolled back without a sweat. So, though some remodeling would be needed in UE3's netcode (because it has a form of rollback but not exactly the kind you want for fighters) which they'd do anyway since they'd obviously be at least using Blazblue-like netcode, there's no inherent technical hurdle.