don't click here

Sonic the Hedgehog (Prototype)

Discussion in 'General Sonic Discussion' started by drx, Jan 1, 2021.

  1. Lithium

    Lithium

    Member
    16
    6
    3
    Japanese version also has this behavior. Even early Sonic 2 prototypes carries this spike behavior.

    I think it was a design choice to make the game harder, but a cheap tactic. So they removed in sequels. If it was a bug they would definitely fix it when they fix invincibility power up.
     
    • Agree Agree x 3
    • Like Like x 1
    • List
  2. SuperSnoopy

    SuperSnoopy

    I like Sonic Advance Member
    1,778
    740
    93
    Lyon, France
    Slice of life visual novel, coming soon...?
    What I meant by "later revisions" wasn't post Sonic 2 rereleases (with the spindash) but stuff like REV01 that were released before Sonic 2.
    It seems I was wrong however :V I just remember reading online a few years ago that Japan got a patched version of Sonic 1 that fixed the spike bug among other things.
     
  3. DigitalDuck

    DigitalDuck

    Arriving four years late. Member
    5,338
    412
    63
    Lincs, UK
    TurBoa, S1RL
    So was it a design choice to make the Ice Cap Zone spikes have the same behaviour?
     
  4. Nova

    Nova

    Member
    3,755
    178
    43
    Bear in mind that they may not have even been aware of it by that point. I'm not saying with 100% certainty that this is the case (because despite me saying 'may not' somebody will still think I'm claiming this to be the truth :rolleyes:) but remember, this is a time without the Internet. Without social media and mass acknowledgement of bugs and glitches like this. Of course, there may have been myriad other reasons why.
     
  5. Lithium

    Lithium

    Member
    16
    6
    3
    You need to use a scrolling glitch to access those spikes in Ice Cap. It's normal for them to be overlooked. Sonic doesn't encounter them in a glitch-free game.

    However, someone who plays Sonic1 & Green Hill zone for just five minutes can realize that the behavior of the spikes is different than the other hazards in the game. I still think this behaviour deliberately left so the game could be harder to beat.
     
  6. Laura

    Laura

    Brightened Eyes Member
    I guess I was wondering if there was concrete proof if the spike 'bug' was intentionally coded that way or not. But from what I'm gathering from the responses, they operate definitely from other hazards, but we just don't know if it was intentional or not?
     
  7. Nova

    Nova

    Member
    3,755
    178
    43
    I don't think it's really worth discussing because, without definitive proof either way, it's just going to be two camps of people who firmly believe one side or the other, trying to get theirs canonized as 'factual'. The wiki article on the subject is fine as-is as it covers both possibilities, so let's just say - we don't know.
     
    • Agree Agree x 3
    • Like Like x 2
    • List
  8. Inferno

    Inferno

    Member
    36
    71
    18
    Sonic 1 Definitive
    You're thinking of RevXB/RevJP2, which is actually the version used within Sonic Mega Collection, IIRC. It was never released seperately.

    EDIT: YES, Sonic Jam also had a fix, but I didn't consider it for this since that's not a revision of the ROM itself and is a source port, IIRC.
     
    Last edited: Apr 16, 2021
    • Informative Informative x 2
    • List
  9. Black Squirrel

    Black Squirrel

    no reverse gear Wiki Sysop
    8,543
    2,465
    93
    Northumberland, UK
    steamboat wiki
    I played Super Mario World years after release and was shocked to find that its spikes caused instant death. Even though Mario has multiple hit states, spikes are treated as pits. Same with things like Mega Man - those games even have life bars, but spikes kill you instantly.

    So it may be old video game logic - of course spikes kill instantly. All games do that. Put it alongside Sonic having a score counter but no high score table.


    As for Sonic 1 spike behavior, it wasn't officially "fixed" on the Mega Drive, but IIRC they patched it in Sonic Jam on the Saturn.
     
  10. Brainulator

    Brainulator

    Regular garden-variety member Member
    Oh, so now you all decide to answer my question from New Year's Day.

    In all seriousness, I wouldn't say these are insta-kill spikes. You lose your rings or shield when you touch the pointy bits, whereas bottomless pits and crushing objects do kill you regardless of whatever protection you have.
     
  11. Stink Terios

    Stink Terios

    Member
    92
    16
    8
    SMW doesn't have insta-kill spikes though. You must be thinking of being crushed to death or lava.
     
  12. muteKi

    muteKi

    Fuck it Member
    7,850
    131
    43
    I've presumed that one of the reasons GHZ has so many spikes is, like with Mystic Cave, that they're intended to mark what would be bottomless pits that may or may not be obvious depending on the state of the dynamic camera boundaries. (Compare to the 8-bit adaptation where some seemingly obvious bottomless pits actually hide secrets) Spikes in places like the bit in GHZ1 past the set of 4 power ups in a row are probably there to more visibly indicate that, no, you shouldn't actually continue that way... Even if they come right after an invincibility monitor. (Hmm)

    Given that the later levels don't have such complex camera height restriction routines, they switched spikes out for actual pits.
     
  13. Blastfrog

    Blastfrog

    See ya starside. Member
    Whether or not it was an intended behavior in Sonic 1, I think that the level design in Sonic 2 assumed it was a mechanic, and made extensive use of it. The behavior wasn't changed until very late (one of the betas from 4-8 IIRC), and there are tons of areas with spikes placed at just the right distance to trigger it. Mystic Cave's pits are a good example, too. We know that actually implementing Super Sonic was very late too (the concept and palette cycling behavior was there from early on, but the actual gameplay changes weren't there until very late), and they probably didn't design levels to take it into account.

    TBH, I actually like some of the tougher elements of the S2 protos, it gives an otherwise very easy game some more challenge (even if it is cheap).
     
  14. DigitalDuck

    DigitalDuck

    Arriving four years late. Member
    5,338
    412
    63
    Lincs, UK
    TurBoa, S1RL
    You misunderstand: the spikes are still bugged in Sonic 3 & Knuckles, where Knuckles can access them normally, without glitches.

    In Sonic 1 Prototype, the spikes hurt you when you are invincible or invulnerable. In Sonic 1 final, they "fixed" it so they hurt you when you are invulnerable but not when you are invincible.

    In Sonic 3 alone, the spikes hurt you when you are invincible or invulnerable. In Sonic 3 & Knuckles, they "fixed" it so they hurt you when you are invulnerable but not when you are invincible.

    I would assume the S3K "fix" was intended to actually fix them and not have different behaviour; this would imply that this is also true of the S1 "fix".
     
  15. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    404
    63
    Japan


    When Sonic is hurt, his routine counter is set to 04 (hurt mode), while in this mode Sonic is flying in the air showing his hurt animation, he is not meant to get hurt again by any items. The "Touch Response" subroutine which most objects (especially badniks) use will not be able to harm him again. When Sonic lands on the floor, even though he is hurt, he is meant to be moveable by the player, but you can only do that while his routine counter is set to 02 (normal mode), so his routine counter is changed, the problem now though, he's no longer in hurt mode and the enemies and so forth can kill him, this is why there's a hurt counter, it allows him to remain in a hurt state even though he's not in hurt mode via the routine counter.

    Sprikes are unique, they are not just meant to hurt, they are also meant to act like a solid object you can stand on or push up against, so it makes sense to use the solid object subroutine calls and detect which side was touched and handle the hurting internally. Had they tried to use both, for a start it's not optimal, and secondly the collision of one may overrule the other, especially if the spikes are moving (the touch response subroutine is done when Sonic has moved but not the object, the solid object subroutine is done when both Sonic and the object have moved, so there's a clash of interest), so Solid only.

    You can see at Obj36_Hurt, they put measures into place to prevent Sonic from getting hurt if he's already hurt, it checks for his "hurt mode" in the routine counter. The problem with this is; it's useless against upright spikes as you will only touch the harmful section just as the subroutines will force you out of hurt mode and into normal mode, only the side spikes are effective (until Sonic touches the floor and comes out of hurt mode).

    If there's any compelling evidence to put this stupid "behavior vs bug" situation to rest, then I do believe the above is more than strong enough. This SCREAMS that they forgot to check the hurt timer.
     
    • Informative Informative x 15
    • Like Like x 8
    • Agree Agree x 4
    • Useful Useful x 1
    • List
  16. Brainulator

    Brainulator

    Regular garden-variety member Member
    This is probably the most compelling argument I've seen yet in favor of the behavior being erroneous and in fact never intended (as opposed to a design choice that was not properly patched out until later). I was thinking of making a separate thread where I would collect all of the arguments over whether the spike behavior is intentional or not so that I could properly understand what it actually is. Even the wiki seems to be unsure, with Spike damage behavior saying it is intentional behavior and Sonic the Hedgehog (16-bit)/Bugs#Spike damage(?) listing it as ambiguous.
     
  17. Lithium

    Lithium

    Member
    16
    6
    3
    I respect your explanation but just because it appears as a bug in the code, it doesn't mean it's a bug. You know, in final releases "bugs" can be kept as intented behaviours.

    While testing the game, they realized that it made the game difficult and decide to keep this behaviour instead of changing it. Most of the old games have odd things to increase the difficulty. The easier you lose a life, the longer it will take you to finish a game. In my opinion, if it was seen as a bug, it would have been fixed in Sonic 1 REV01. A version where they updated many things.

    However devolopers carried this behaviour up until the final betas of Sonic 2. They probably decided to change this behaviour after collecting player feedback from Sonic 1.
     
  18. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    404
    63
    Japan
    To reverse your own statement here, just because it appears as a bug in the code, it doesn't mean it's kept as an intended behavior, it could be... ...a bug.

    Your theory is possible, but after assessing all of the "theories" surrounding this, the theories in favour of it being a bug are vastly more plausible than it being a result of keeping a bug intentionally (for example, just one here, it's more plausible they ran out of time). To use Occam's razor "the simplest explanation is usually the right one".
     
    • Agree Agree x 13
    • Like Like x 1
    • List
  19. Laura

    Laura

    Brightened Eyes Member
    I think Occam's Razor is usually misleading. Just because something seems like the simplest explanation doesn't necessarily mean it is right.

    But I did find your posts really interesting and it was exactly what I was looking for. Someone who knows the inner workings of the game and can explain it. So thank you!
     
  20. Lithium

    Lithium

    Member
    16
    6
    3
    I understand what you mean. However it is obvious that they had time to fix the invincibility power-up spike behavior and they fixed it. If this rest were also viewed as a bug then they would fix it along with it. I don't know if initially they wanted this behavior or it came after a bug, but i believe they kept it willingly.

    In the end it became a disliked design choice among fans and they decide to drop this behaviour in the sequel Sonic 2.