Cave and the slowdown

[Udderdude]

Scenario #5: There's actually tiny little elves inside the ROMs who deliberately slow the game down to a grinding halt when there's a million things on screen.

I'm gonna have to go with this one. Also explains why more recent Cave games haven't been emulated yet. Emulating tiny elves is HARD.

[Casey120]

They did a pretty good job in Mame on Esprade and Gunwange using DDR Ram Pixies so i call bullshit !

[nikkos010]

Okay, first of all calling out a possible gameplay issue is NOT an attack on the programmers themselves. Second, just because a game is programmed, tested, etc. does not mean everything is intentional.

In this instance, based on the generality of the claims being presented, I disagree.

Ever do any QA testing? Doesn't have to be game QA, could be for any software or firmware application. There are several possibilities as to why an issue exists in a current release and it doesn't always mean it's a bug, nor does it always mean it's always intended to be there. Consider the following: (snipped for brevity)

Yes, Cellular handset hardware and software.

QA testing on a multi-featured software platform is generally much more difficult due to the myriad of different ways the consumer may use a product. I've seen issues on a handset where tapping here, there, and holding the "7" key could cause a catastrophic failure resulting in a bricked phone. As complexity increases so does the chance of software issues.

The software we're talking about is very linear, programmed for specific hardware, and as a result really not that complex. In fact, more time is likely spent on the graphics and design than the actual coding. Once the initial design and coding is done, it's then applied to the hardware for testing. Considering we're talking about embedded programming, where the hardware is present while programming, something like processor overload (slowdown) becomes apparent immediately.

If you were to apply either scenario #2 and #3 to this particular instance, (processor overload due to number of on-screen sprites) you are saying the coders decided it was a design issue and/or not important enough to fix. Again in this instance, I find that extremely hard to believe because the issue itself would have existed very early on (before it was even submitted to a QA team) and exceedingly trivial to fix (reduce the number of on-screen sprites)

Occam's Razor applies here. There are so many thing to have been ignored and/or missed at so many levels that to suggest that slowdowns at specific points in specific games on multiple platforms are in each case "bugs" instead of intentional use of hardware limitations seems just a smidge unlikely

Do CAVE games have bugs and/or exploits? Yep, they sure do. The 1st boss exploit in Progear is an excellent example of something that would be missed by a QA team. How many people over how many years played the game how many times before that particular trick was noticed?

[Shatterhand]

I think some guys at this point are attacking RHE based on his DUX/Last Hope posts, which is unfair.

There's nothing wrong with what he's saying IMO. Being a programmer for some time, I agree with him that's much safer to have a controlled environment than let the hardware limitations say how fast or slow the game is supposed to run.

If you control the speed via software, you can *always* get the intended speed if it's well programmed. If the speed is determined by hardware limitations, an unexpected behaviour may happen. If the slowdown is purely on the hardware side, you may have a slower game when you have 2 players on screen shooting, and a faster game with just 1 player not shooting. The game may get faster just because you quickly destroyed an enemy that was supposed to shoot lots of bullets on screen....

If the slowdown is intentional and its "hardware controlled", it's hard to not think it was a bad way to do it.

[gray117]

There seems to be a massive mess over good/bad practice and intention.

Sure it may be bad practice to work in this way... but it can be cool to make things break! I've no doubt this originated from a frustrating limitation - but I believe this limitation quickly became a fun feature. Whether this is a software/hardware/middleware thing being broken doesn't really matter if the game is still fun. Of course, the ideal of a genuine product, genuine intent, is inevitably part of the fetish - the idea that even the hardware is part of the game again adds further to that attraction

Of course, specifically these cases its not that something breaks, but it is kind of bent, beaten, restricted, teased and tickled before being released... some people like a bit of this, and others like it so much that they will happily pay a lot of money for that genuine pleasure...

... Finally there are those who are perfectly happy with sudoko.

[undamned]

Where's that great Recap thread about this?
-ud

[BIL]

This one?

[msm]

There's nothing wrong with what he's saying IMO. Being a programmer for some time, I agree with him that's much safer to have a controlled environment than let the hardware limitations say how fast or slow the game is supposed to run.

If you control the speed via software, you can *always* get the intended speed if it's well programmed. If the speed is determined by hardware limitations, an unexpected behaviour may happen. If the slowdown is purely on the hardware side, you may have a slower game when you have 2 players on screen shooting, and a faster game with just 1 player not shooting. The game may get faster just because you quickly destroyed an enemy that was supposed to shoot lots of bullets on screen....

If the slowdown is intentional and its "hardware controlled", it's hard to not think it was a bad way to do it.

i sort of agree with this but wonder if anyone has actually tried it both ways to see which works better as h/w and s/w can be strange at times.

also someone has probably already said this but most game developers seem to want a game to look as nice as possible/have as much going on as possible so choosing to let the h/w control the slowdown should allow them to get some nicer graphics/more action, as opposed to taking the s/w slowdown route that would mean they have to make sure the h/w never comes under enough strain to slow it down - as this would compromise the 100% s/w slowdown thing.

[Shatterhand]

Yes, this makes sense.

But the question is, why is this discussion all that important? The games are pretty good either the slowdown was intended or not, arent they?

[Kaspal]

Yes, this makes sense.

But the question is, why is this discussion all that important? The games are pretty good either the slowdown was intended or not, arent they?

yes they are... in fact, i dont visualize them w/o the slowdown, cuz lets admit it, there are certain patterns that w/o the slowdown would be sure death... alas, w/ it, you can train your hand-eye coordination to overcome such wall of bullets that comes to you.

[captpain]

The slowdown is intentional, it obviously works for gameplay, and only the most insane recluse soul-crushingly pathetic nerds on earth would care about HOW the slowdown is implemented.

Go outside and maybe breathe some fresh air in a local park. Christ.

[ncp]

no u

[Matsunaga]

The slowdown is intentional, it obviously works for gameplay, and only the most insane recluse soul-crushingly pathetic nerds on earth would care about HOW the slowdown is implemented.

Go outside and maybe breathe some fresh air in a local park. Christ.

Good point.

[emphatic]

Christ.

Blasphemy!

[EPS21]

The slowdown is intentional, it obviously works for gameplay, and only the most insane recluse soul-crushingly pathetic nerds on earth would care about HOW the slowdown is implemented.

Go outside and maybe breathe some fresh air in a local park. Christ.

People want to know more about their hobbies and the processes of what goes on underneath the hood? It may be nerdy yes, but for a mentality of that being "soul-crushingly pathetic" I fear for future generations if that is the current mindset. It's kind of along the lines of "I don't care how our government functions, as long as it works" which is making George Orwell roll over in his grave so much he's drilled a hole to China.

[antron]

"I don't care how our government functions, as long as it works" which is making George Orwell roll over in his grave so much he's drilled a hole to China.

that would be quite ironic.

[captpain]

The slowdown is intentional, it obviously works for gameplay, and only the most insane recluse soul-crushingly pathetic nerds on earth would care about HOW the slowdown is implemented.

Go outside and maybe breathe some fresh air in a local park. Christ.

People want to know more about their hobbies and the processes of what goes on underneath the hood? It may be nerdy yes, but for a mentality of that being "soul-crushingly pathetic" I fear for future generations if that is the current mindset. It's kind of along the lines of "I don't care how our government functions, as long as it works" which is making George Orwell roll over in his grave so much he's drilled a hole to China.

It's fine to care about that stuff, but what I'm trying to say is that Cave's approach is so clearly effective that it just looks childish to nitpick the actual mechanism, and to extrapolate this idea to the point of attitude towards national government is beyond fucking crazy.

[EPS21]

Yeah that was a bit of a stretch, and although Cave does manage it well and I still love their games the same, sometimes it being unintentional has detracted the experience a bit, for example in futari, the BGM will melodically change as you approach a midboss, however depending on how much you waiting you've done to fill the screen for bullets, then kill something to clear them all for score, it causes more slowdown than if someone were just playing for survival, thus the song is not in sync with the midboss encouter. It is nitpicky, especially for some who don't care much for the BGM, but it does make the game that much less polished IMO.

I just find it hard to believe that with today's hardware, and with all the 3D games with more and more amazing graphics (but not really better games), you'd think no matter how many bullets or effects and whatnot in a 2D game would be completely trivial to power, yet apparently arcade hardware is still maxed out and slows them down. I wish it could all be intentional slowdown but there are probably many forces I don't know about that makes it makes it difficult and very inconvenient for developers to realize that end.

[undamned]

This one?

Indeed. Ass-tastic!
-ud

[dmauro]

I can't believe I read this whole thread. Failure on my part.

There's nothing wrong with what he's saying IMO. Being a programmer for some time, I agree with him that's much safer to have a controlled environment than let the hardware limitations say how fast or slow the game is supposed to run.

If you control the speed via software, you can *always* get the intended speed if it's well programmed. If the speed is determined by hardware limitations, an unexpected behaviour may happen.

I think what you guys aren't getting is that when they program these patterns, they are just plugging in algorithms (with a good idea of what's going to happen), and then they test that pattern to see how it plays (that French shmup documentary has an interview where this is hit on). They don't need to have a fancy software system in place to change the slowdown because if they think that pattern is too hard, they can just toss out some more bullets to slow it down. It's like you guys think they are coding the entire game and not testing and editing it as they go along.

I bolded the last part because, unexpected behaviours are often how the best innovations come about.

[emphatic]

I bolded the last part because, unexpected behaviours are often how the best innovations come about.

QFT.

[Ex-Cyber]

It's one thing to get an unexpected behavior "in the lab" and then study it and understand it. It's entirely another for the unexpected behavior to pop up in the field. That's why engineers generally work very hard to confine unexpected behaviors to the negligible background details.

[GaijinPunch]

The software we're talking about is very linear, programmed for specific hardware, and as a result really not that complex. In fact, more time is likely spent on the graphics and design than the actual coding.

Absolutely not. Cave have stated many times that the design team is done first, and work a lot less than the developers. If anything, they are tweaking (or changing altogether) the scoring systems more than anything. They've noted that at least Guwange & ESPRade had different scoring systems throughout development: Guwange having quite a few.

It's like you guys think they are coding the entire game and not testing and editing it as they go along.

I don't think anyone that's ever touched a piece of code would think that, but you never know.

[nikkos010]

The software we're talking about is very linear, programmed for specific hardware, and as a result really not that complex. In fact, more time is likely spent on the graphics and design than the actual coding.

Absolutely not. Cave have stated many times that the design team is done first, and work a lot less than the developers. If anything, they are tweaking (or changing altogether) the scoring systems more than anything. They've noted that at least Guwange & ESPRade had different scoring systems throughout development: Guwange having quite a few.

This would be different than for most games then, as today's modern games generally spend more time on levels, scripts, and graphics than on the engine itself.

However I would point out that scoring systems could be argued to fall more on the design side of things. It's probably more of an issue of definition.

BTW, you have a PM incomming, I want to buy some posters

[Ex-Cyber]

This would be different than for most games then, as today's modern games generally spend more time on levels, scripts, and graphics than on the engine itself.

With today's modern games, the engine itself (or at least the hard parts of it) is often written by someone else and licensed rather than being developed by the company behind each particular game. Considering that Cave still shipped custom hardware until DS2, it's not that shocking to think that they might write a larger proportion of their code in-house than most game companies.

[Ed Oscuro]

Also, having some guy draw some posters only takes so long; custom graphics and sound? Err, on an older 2D system, not that big a deal.

Compare that to trying to compete against some bigger teams that make games for, say, Unreal Engine 3. Yikes!

Thread definitely delivers. I believe RHE & THE gained some valuable ideas from it.

[nikkos010]

Also, having some guy draw some posters only takes so long; custom graphics and sound? Err, on an older 2D system, not that big a deal.

Compare that to trying to compete against some bigger teams that make games for, say, Unreal Engine 3. Yikes!

Thread definitely delivers. I believe RHE & THE gained some valuable ideas from it.

I don't disagree that many companies do utilize 3rd party engines to save time. But even in modern franchises that don't, like Final Fantasy for instance, so much more time is spent on world building and story. Just prior to E3 it was announced that they'd finally finished the script for FFXIII and translation/localization could begin. 85% of the game was done by that point...

You're right though, a linear 2-D shmup isn't going to have as much time put into the graphics, but level design, bullet patterns, scoring, and overall difficulty is a beast to perfect. But don't dis the sprites, that's a hell of a artistic skill.

[toaplan_shmupfan]

In the case of Mushihime-sama Futari (version 1.5), there is a section in Stage 2 where blue objects with what appears to be tentacles are visible and shooting while the player ship is blasting away at large rock-like structures. Not only do the enemy shots slow down, but the exploding and lowering of the rock-like structures also slow down and to add to all that, the player shots have visibly slowed down to almost half speed.

To me, this all appears to be because the hardware is being pushed to its practical limits, an I actually found it annoying to see such a slowdown occurrence in what is otherwise an odd, but well-paced game (at least in the Original mode that I played) because the bullet patterns from those small blue objects did not merit such a slowdown occurrence.

[Jockel]

play the same spot in maniac or ultra to know what you're talking about

[Elixir]

In the case of Mushihime-sama Futari (version 1.5), there is a section in Stage 2 where blue objects with what appears to be tentacles are visible and shooting while the player ship is blasting away at large rock-like structures. Not only do the enemy shots slow down, but the exploding and lowering of the rock-like structures also slow down and to add to all that, the player shots have visibly slowed down to almost half speed.

To me, this all appears to be because the hardware is being pushed to its practical limits, an I actually found it annoying to see such a slowdown occurrence in what is otherwise an odd, but well-paced game (at least in the Original mode that I played) because the bullet patterns from those small blue objects did not merit such a slowdown occurrence.

Dude, they're called jellyfish.

And yeah, that part seriously slows the game down to a crawl. But it's a good sport for milking, since you can just deliberately let them spawn as much as possible, then destroy the ice pillar. I totally welcome any slowdown in Futari though, since Original will end up killing you with some pretty fierce rank anyway.

In regards to slowdown of that kind, I'm really surprised that Death Smiles was ported to the 360 so well, as it deals with the same thing from time to time.