Player final state after hitting different types of obstacles

Not sure if I’m going crazy, missing something, or if I found a bug…

Please consider state at round 6:
round_6

Player one choose RIGHT, so will be hitting, in this order:

  1. WALL
  2. MUD (end block)

So I would expect the state of the player to be HIT_MUD in round 7, because that is the last bad thing we hit.
And, indeed, it is actually HIT_MUD.
round_7

Well and good.

Ok, so then fastforward to round 33 (of the same game).
round_33

Player 1 is again choosing RIGHT.
So it will hit, in this order:

  1. WALL
  2. BOOST
  3. MUD

It ends on empty block.
So given the stuff we hit, I would expect the end state to be HIT_MUD.

However, we then see this:
round_34

Final status is HIT_WALL instead.

So what am I missing here?

I think the answer lies in this piece of code:

If the player hits multiple types of obstacles the precedence of the final state is wall, oil and then mud (from highest to lowest)

Thanks @kobus-v-schoor , I figured initially it was something like that.

But, then how do we reach the inconsistency between Round 7 and Round 34?
I would expect both to end up as HIT_WALL (if status is decided based on some precedence as it seems from above).

But instead, one is HIT_MUD (round 7) and the other is HIT_WALL (round 34), even though both hit the same obstacle types, in the same order (ignoring the boost hit going to round 34).

Think I’ve found it, the last block that the player lands on and the “middle blocks” are processed separately:

In your first example the last block the player landed on was mud, so that was the final state since that got processed after the other blocks. In the second example only the middle blocks are special, so then the precedence kicks in. I think this separate last block logic is probably for the “lizarding”, but not entirely sure.

Hhmmm… probably related to implementing this “lizard” jumping thing, since in that state only the final block effect are applied.

Ok, thanks again @kobus-v-schoor - I’ll scuttle away and see about applying that logic :slight_smile:

I feel like I’m missing something. Why does this state matter ? Shouldn’t your only concern be the speed you lost ? (or does this state affect score ?)

For me - it’s my pedantic paranoid side.
My state representation is not matching what the current engine is doing. That makes me worried, because then I start questioning what else am I missing?

1 Like

As explained by @kobus-v-schoor, indeed there is an implicit precedence in the code, being MUD/OIL/WALL. The state will reflect the hit item in that priority.
An inconsistency arises from updating the engine to handle the final block separately to the middle path.

It’s unfortunately one of those problems where we are trying to simulate continuous moment discretely, where every solution has it’s own pros and cons :thinking:

1 Like

What!!??
Are you trying to tell me there is no one-size-fits-all silver bullet perfect solution that fixes everything for everyone??!!

Sir, that is PREPOSTEROUS!!!
I will speak with the management of this establishment immediately!

:stuck_out_tongue:

1 Like

Follow up question though @pierre.roux - what happens when a player drops oil spill on a mud tile?

I’m starting to suspect the oil spill is simply ignored in that case?

There is no stacking effect that i’m aware of, so I believe the previous explanation about precedence will still be valid. So yes the mud effects will be applied

1 Like

Am I missing something? Shouldn’t the car’s speed be 0? Drops to 3 for hitting the wall then decreases speed state again for the mud?

The game engine currently prevents the speed from dropping to 0.