Juding the mojon twins games

Ok, first, these games are awesome, incredibly well done. Great work with them.

That said, I'm having trouble figuring out how to rate them, and thought I'd see if others have advice. Basically, I played the first one alphabetically (Cheril), and thought it was amazing. Great graphics, great engine, etc.

Then I played Lala. And it's amazing, but so similar. Many graphics felt similar (those bats!), the same engine -- felt like a variation on the same game. (which is fine, but makes it hard to judge properly)

Individually, either game would get incredible ratings. But I'm not sure about rating them both at the same level, since one feels so close to the other. But then, in that case, which would get the higher rating? Would I rate one highly and the other low? But one isn't clearly that much better than the other.

I don't have any intelligent answers, but thought others might have good input about how to best rate these great games.

(I'm not including Wo Xiang Niao Niao here, it didn't feel as similar)

I think Lala had better music, better cutscenes.

I don't want to sway the voting in any direction, so i'll try to keep this as short as possible:

I think the issue with judging you're raising might be a consideration for the "originality" score if you deem it so*, but not the other scores.

Thought experiment: Say a person or team submitted two hypothetical games - let's call them "pocket animals blue" and "pocket animals red", which was absolutely the same game sans different in-game collectibles. Would one or both of the games have worse art and sound for it?

*ultimately, you're part of the jury. You have the mandate to decide whether it matters to you or not.

In order to be a better developer in the future, I'd like to know which things make both games so simmilar, because I thought they were different enough and I was obviously wrong.

They use different engines, and different gameplay mechanics. Goddess is about exploration and mild puzzle solving, with lots of backtracking. Lala is more lineal. In Goddess you have to use the superpower ability in the key moments. In Lala the gameplay is based upon creating platforms mid-air to progress - although you don't have such ability in the first level, maybe you didn't get to the sky palace?

Of course they are both platform games, in which you basicly run and jump.

So, any suggestions for the future?

Thanks.

I dunno what the rules say about it, but if an entrant can only win once (i.e. only their highest entry gets prize-ranked) it might be a non-issue, and everyone could just rank both as if the other didn't exist.

-Both are action platformers
-both have a similar 'feel' (music, jumping, avoiding bad guys)
-both are inside a dark castle with puzzle elements
-both have a main objective of finding a key, opening a door, and finding other objects

Fair enough, both are action-adventure platformers, but I thought that the different gameplay mechanics (the gameplay in Lala is centered around creating magic platforms mid-air and timing your jumps) and level advance (exploration & backtracking vs. going forward as fast as possible) made them differentiable enough. I was wrong, it seems. I'll try to avoid entering more than 1 game of the same genre if such a thing seems to detract from them.

Is the code similar enough that they could practically be made into a multicart sharing most engine code?

No. As I noted before, they don't use the same engine.

Lala is flick-screen oriented, albeit it uses two nametables and scrolls accross them just modifying the registers. Goddess has true scrolling with arbitrary horizontal size. Of course both are coded by me so you'll find routines which look simmilar in both games, but are otherwise unrelated. Data is organized differently.

I made Goddess available at github and commited while I was developing it https://github.com/mojontwins/GoddessR
You can gran Lala's sources from https://github.com/mojontwins/Lala

Having just played Lala, I see where the impression comes from. The jump curve is exactly the same, the screen transitions look the same, and some enemy sprites appear the same.

I liked Lala much more than Cheril, though.

My apologies then. I stand corrected.

Like calima said, the jump curve, the screen transitions, the similarity in the header setup, the similarity in enemy movement and how death is handled, all made me think it was the same engine. I'm impressed that you had time to churn out another engine for this competition!



Even though the mechanic or gimmick for each is different, the things I mentioned above made them feel really similar to me. The player movement, and style of vulnerability and enemy movement is what did it. The basic challenge of avoiding the enemies "felt" the same in both.

Either way, I don't want to come across as being negative. Both games are extremely high-quality.

You didn't sound negative, no worries! I just want to learn from my mistakes so I can make better entries next year.

This is a learning process. I've learned quite a lot about the NES from Lala (which was finished in late summer) to Goddess (finished on Jan 31st), and that's what counts.

Thanks!

@na_th_an

First, i was going to wait with further comments on projects until after the judging has been done, but since you seem to want a discussion now, would it be ok to post a few (rather subjective) points?

Of course. Go ahead!

I've had problems with the jumping routine. Lala felt the most responsive. The other two felt unprecise, floaty, and unnecessarily hard-to-predict to me; in slightly varying ways, and with different effect because of the different environments and goals.

Replaying Cheril, i find the main culprit to be that it seems to be using accumulated acceleration when jumping, just like when running. This leads to an exponential rise curve, which could work great for rocket propulsion or hovering or maybe a mid-air jump/float function, but feels unreliable and wrong during a standard off-ground jump. It's as if the gravitational pull is switched between above and below depending on the phase of jumping. As an side effect, jumping becomes hard to predict, a feature which gets worse with one-hit deaths and abundant risks of falling to another screen and having to climb your way up again.

I'd set up upwards momentum as a one-shot set CONST at the condition "jump button pressed = true". Then, i'd possibly have timer (A) count # of ticks before gravitational deceleration starts eating away on the momentum. To get some control, i'd let timer (B) count down from the effective max length of the jump button being held. If [jump] is released, timer B is set to 0. Both need to be 0 in order for deceleration to start (essentially your standard falling procedure). A has a shorter time setting than B. Alternately, with a different conditions framework, the timers could be baked into one timer. The set value of these two timers + the value of CONST + the rate of deceleration/gravity + max gravity can then be tested back and forth with different values until jumping feels more precise and predictable, relative to the stage layout and enemy placement. Note that being the developer and having played the level time and time again obscures how the game mechanics feel for the target audience. It needs to feel good without having routines, prior knowledge, muscle memory and so on, which can be tricky as a one-person team to estimate.

If time is on the horizontal axis and movement on the vertical, it looks something like (1) or (2) but should probably be more like (3):

In the case of Wo Xiang (according to my memory), the inverse-gravity/accumulating momentum is double trouble, even if the "floaty" effect felt a little less pronounced than in cheril - precision is key when you position yourself to bounce off an enemy, yet i have difficulty getting the timing right positioning myself, because it takes me too much time to get there, and time to fall down. It doesn't feel responsive to me. The way i'd have it would be the jumping to be quick enough to make bumping enemies in the beginning a relative piece of cake without too much practice or having to think about a hard-to-pinpoint delay in the jumping scheme, and then progress the difficulty in the form of enemy speed and/or maneuvers. A sharper turn from jumping to bumping may help define the movement. Additionally, i feel that pressing down should be a complementary mode of bumping; though that's a minor side note.

I think the TLDR of it is that 1) the base difficulty shouldn't come from the jumping mechanism itself, but rather from what level/enemy design challenges the mechanism is meant to surpass, and 2) Jumping momentum should be a uniform curve, unless there's special circumstances.

These points are from a personal user perspective, of course. And all that said, the platforming challenge gets fun to me after a while, when i've taken the time to adapt to the controls. But that's possibly an if, because that's a threshold you need the user to get over on the first play. Had it been cartridge-only times, you'd bought a physical copy and would feel the need to get the most out of the game by adapting to the physics, but in download free to play-times in a sea of entertainment, controls that take some time to adapt to are accompanied by the risk of losing audience based on the first minute impression.

Edit: I hope this is helpful, and not just critical. I'm aware i have the maybe too common trait of being able to bring up things i percieve as a space for improvement, but have a harder time bringing up the stuff that i percieve as good to equal proportions.

Another way to do variable height jumps is to do it in the style of Joust, where whether or not the Flap (or in a general case, Jump) button is held modifies some coefficient to be applied to acceleration due to gravity.

That's similar to how Haunted: Halloween '85 and The Curse of Possum Hollow work. The move subroutine for walking actors (player and others) adds a constant GRAVITY to the actor's velocity every frame. But if the actor's move routine is passing the "fast fall" flag in the control word, the walking subroutine instead adds 4 * GRAVITY. The player's move routine passes "fast fall" while in a jump frame and velocity is upward and A is not held.

Interesting.

The jumping mechanism is as follows:

- Every frame, vy is added to y.
- G is added to vy.
- When A is pressed, jumping starts. vy gets a negative boost. Such boost is applied to vy in a decreasing manner as long as time passes during a maximum of 16 frames.

It doesn't have to do with your vx at all - well, partially. Inertia is inertia and you'll get horizontally farther if you are running faster.

What strikes me the most is that you claim they seem different - as, in this case, I'm using the same code in the Y axis in the three games:



Also constants seem to be the same:



My games have always been praised for their jumping mechanics so I thought I had got it right

I have plotted a simulation of the curve and it looks like there is something weird happenning during the first 3 frames and maybe that's what's disturbing the curve. It looks almost like 3 but it is definitely slightly 2 during the first frames.

Thank you for taking your time. I will work in my jumping curves further

Playing wo xiang again; you must be right and my memory was wrong. The curve feels the same as in cheril. It has different implications, though, due to the different core premise, connection to other mechanics, go to the right progression, and level layout.
I feel it is off/odd the same way i remember it, though; probably the thing you detected while plotting.

Setting emulation speed at 50% helps showing where the slight velocity change happens. A frame by frame advance + calculating and sending the velocity (compare pixel+subpixel position of previous frame to current) value to an observable place in ZP and watching RAM might help pinpoint it? I'm sorry, i'm terrible at code analysis.


Speaking of layout, this area here:


It's a functional passage, but i wonder what it is suposed to be? A house or ruin? A heap? A tunnel?
Looking at PPU viewer in FCEUX, it is tight, but there seems to be room for one more 16x16 block since i can identify 8 characters that look the same. Could it perhaps be used to give the non-solid background some visual cues? Or perhaps another already existing block in another palette set could help do the same?

A technical "issue" in the same scene: if you have clothes on and run into that sneaky person running in the middle corridor while she is moving towards you, you get slammed multiple times against the ceiling. It might be a quirk, but it was also awesomely brutal.

Playing a bit more... On non-autoscrolling levels, maybe the camera could be corrected with a shorter delay? I noticed this time that i wait around for the camera to be adjusted to the right.

Another note: if bumping went faster (not just turning the momentum around faster like suggested before; but also when falling), you'd be able to catch fish on their way down. Right now they have the same speed as the player character falling. It's a slight change of game rules, but i think it just might be slightly for the better.

. This got me confused a bit. Was there something in my previous post which had with horizontal movement to do? I must've written something poorly.

This what makes your jumps 'floaty'. They should have a single large velocity impulse.

My preferred method of ascension control is to make releasing the jump button clip VY: if the player is moving upward faster than a certain threshold, fix VY to that threshold. Exactly what threshold to use takes a bit of tweaking, but it should still be an upward movement. Because it applies the moment the player releases the jump button, it feels 'responsive'.

Another alternative is to lower gravity while the jump button is still held. This is not an upward acceleration, but rather a reduction in downward acceleration. Releasing still has an immediate effect, but since it changes acceleration and not velocity, it's more subtle. This is the method used in the Mario games, and I honestly hate it, but millions of people would disagree with me, and it's heaps better than what you're doing now.

Another tip for better platforming: slightly slower horizontal acceleration. A single tap from my clumsy old thumb is enough to overshoot a one-block platform. Either slow down or stop forcing me to land on such small targets, especially across screen boundaries. Make sure you don't decrease deceleration as well! You should always stop more quickly than you start.

Yet another suggestion: use a single upward collision point, rather than two. Let the top corners of the player's bounding box, especially the trailing one, stick into the ceiling slightly, and push them out sideways instead of downwards. This obviously depends on how your collision code is set up, but it's a big frustration-reducer for jumping in tight spaces.

I'm going to shut up now or I'll end up writing an entire essay on platformer physics.

Am I the only one who enjoyed the floaty jump mechanic?

I think the games are really great as they are and the 'problem' of the games being too similar is a bit surprising to me considering they all come from the same developer.

Thanks for the insight, I will study the possibilities. I taught this stuff myself via discovery, so I may have some points wrong. In my way to job I was thinking about the gravity reduction possibility, precisely, so I might apply that.

It's interesting how people who come from different gaming backgrounds have rather opposite preferences: in my country, most children played to home computers rather than consoles in the 80s, and faster acceleration times are prefered. Whenever I use lower values, the feedback is that controls are slippery, even though deceleration is usually twice the acceleration, even more. I think I should tally the values depending to the game. Fast action in autoscrolling levels in Wo Xiang Niao Niao surely do benefit from the faster horizontal acceleration.

@rikami: thanks for your words. That was part of my own thinking, at least art-wise: of course graphics and music are simmiliar as they are made by the same people Glad you enjoyed the games.

I've changed the jump physics in Cheril the Goddess applying the techniques described here:

- Once you press jump, the "jumping" state takes 16 frames, maximum.
- When you press jump, an initial instant boost is given to the vy in the negative direction (upwards).
- If you depress jump before the 16 frames have passed, vy is clipped to a lower, fixed value.
- During the jumping state, gravity is for times less.

It may be the placebo factor, but I find it quite controllable and visually the curves are more bell-like.

Any thoughts?

I think it feels much better.

I like the change - the jump feels reliable and direct.

Another thing i found:
I noticed looking at the map resets enemy and moving platform positions. It has gotten me killed a few times, and i've also used it to cheat.

Oops - I didn't take that in account! Thanks for pinpointing that issue, I'll try and find a solution.

I found a weird bug at the extreme right edge of the map, just past a recharge point with a green bat right next to it, where a statue and two solid blocks got replaced by glitched tiles. I flew up and got stuck on the screen above, where there's one-way platforms with no way out above them.

I didn't think to take a screenshot, and when I came back later everything was normal.

I'll look into it, thanks.

Aside from the gravity alteration, that's pretty close to what I do in my current project.

• Start of jump sets an immediate upward velocity.
• Gravity is added to velocity each frame, velocity is added to position each frame.
• Releasing jump clamps upward velocity to a lower value.

The result is a normal parabolic arc for a full jump, and a "broken" two-piece parabolic arc if the jump button is released before the clamp threshold is reached.

I am not entirely sure how your lessened gravity applies, but I'm guessing it makes for a slower ascent and an additional continuity change in the parabola where it switches off.

If* you would want the breaking off to be less sharp, you could perhaps gradually 'roll down' to the clamping value over the course of a couple few frames, maybe four or six? It's a very minute change few will notice on a conscious/cognitive plane, given the short time span, but it might be felt. Ie current_clamp = TARGET_CLAMP + n, and decrease n by 1 or 2 or something until 0. the const TARGET_CLAMP may need to get adjusted a little bit to compensate for the rolling off for the short jump to not lengthen itself.

*maybe being sharp is a good thing, principially or in some environments.

No, I wouldn't want to do that. Not in my game, anyway.

The 2nd derivative discontinuity provides a slight feeling of immediate response to the release. Trying to soften this would take away that feeling, which I think is very important to have.

The remainder of the arc above the release point already provides an "easing off" which continues in a perfect parabola from that point. The shape of the parabola is identical to that of the full jump from a lower height, so that part of it remains consistent for all jumps, and by switching immediately to it, we get the maximum amount of time spent on its familiar, predictable path.

There's a balance between smoothness, responsiveness, and predictability that results from various choices. I don't think it would be appropriate for my game, but maybe you're making something that needs more extreme smoothness.


FWIW, I though the original version of Cheril's jump was unusual, but acceptable. The slow start to the jump is strange, but it doesn't seem to detract from the game, for me. In Lala, there's a few jumps out from narrow gaps where it might even be an advantageous shape. The most important thing to me is that the level design and challenges of the game are based around the jump, so I don't really understand the desire to change at this late point in time. (I do enjoy the discussion of various types of jumps, though.)

I have a different question about something that happens in both Lala and Cheril, though. How does the game choose a respawn point when you get hit? It feels like it returns you to a "safe" place from a few seconds prior. How did you implement this?

It seems to choose the point pretty well. I never had a moment where I thought it put me in a bad place (though the temporary invincibility really helps with that), but I also was never sure exactly where I'd end up restarting from. How does the game decide where to put you?

If you have time, I'd be interested to see your essay on wiki.nesdev.com.


In other words, apply increased gravity until the upward velocity is below the clamping value. With a clamping value of zero (the peak of the jump), this produces the jump behavior in the Haunted games.

changing a core mechanic in the game at this point raises the need of further playtesting and hypothetically, perhaps also marginal corrections of the level layout, which could potentially be time-resource costly. But if one is willing to do that, and if there's a good enough purpose, i see no hindrances. The max reach of the jump seems to be the same, which should make the window for new-upcoming layout trouble small enough to handle. In any case, i think it's a productive discussion.

I think you're absolutely right that the sharpness breaking off the trajectory has strong merits. It gives both a more direct sense and a distinct edge to the control; hence the if in italics. As for my slow-progressing-while-learning-to-code roller derby project, cross-fading in order to transition directional velocity in some maneuvers is something i view as important (because of how roller skating works), but that's another context.

This made me realize my wording was inexact and open for multiple interpretations. I didn't specify what to 'roll down' in that sentence.
"you could perhaps gradually 'roll down' to the clamping value" should have been "let the clamping value decrease from a starting value (at [jump button] release) to a lower value over the course # frames"; If that makes sense.

That model is equivalent to "When A is released for the first time in each jump, multiply upward velocity by 1/4."

Say the normal jump velocity is 1000 decreasing to 0 at the peak, and the clamp value is 250 decreasing to 0 at the peak. Then A is released when upward velocity is 600. By that time, the clamp value will be 150.

Don't mind me; I'm just trying to golf down the size of each algorithm's required state. Here, I've reduced it to one bit: "has clamp already been applied since this jump began?".

Hmm.. what i'm trying to achieve by this is analogous to the terms 'hard knee' and 'soft knee' in signal compression.

Would that be the effect of "When A is released for the first time in each jump, multiply upward velocity by 1/4."?


I think it would be beneficial to boil down a list of barebone jumping/physics topologies that are especially useful on the NES and similar 6502 platforms.

This is why it has a strange jump curve, then. When an actor jumps, dy (or vy in your case) is generally set to an upwards (negative) value as a one-shot, and then a gravity constant is added every tick to slow this upwards acceleration until it eventually becomes downwards acceleration. To continuously boost vy upwards would drag the actor upwards, increasingly quickly. That makes sense for something bobbing to the surface under water, or if the actor has a jetpack or other propulsion apparatus, but for a jump it seems inappropriate.

Some Virgin games for Genesis (Cool Spot, Aladdin, Earthworm Jim) jump with this same strange curve, while others (Lion King) do it in a more sensible way.

EDIT: Argh, I'm a page late. Having an unusual jump isn't necessarily a bad thing, but getting the more typical parabolic curve might make it feel more natural to those used to other platformers. As others have written, it is a matter of whether or not it is worth changing the mechanic, then testing and adjusting the rest of the game to match.

It's very simple: it places you where you jumped the last time. It records your position everytime you jump (but not if you jump from a moving platform).

Correction: That's ingeniously simple. Now knowing this, i should say the omission of moving platforms are noticeable (they are percieved as longer, irregular gaps in the timeline). If you wanted to expand on that, you could check for a moving platform collision detection to be true at each jump press, in which case the init position of that platform + centering offset would be stored instead of the actual position. Some additional playtesting involved, but that's much quicker than checking every corner for side effects of altered jumping mechanisms.

Me and my big mouth.

What should I cover? I haven't done any surveys or implementations on the NES, just general algorithms for my PC game engines. I doubt NES developers are going to be interested in the mathematical properties of Euler vs. Verlet integration, for instance, and I'm not quite sure which of the collision detection algorithms I know are appropriate for a 6502.

Ah, neat! Thanks for explaining how that works. I was trying to imagine that you tagged "safe" platforms throughout your levels and were keeping a ring buffer of the last places visited or something, but I couldn't think of a non-complicated way. Interesting how simple the actual approach was.

Well, it's *very* simple and it seems to work in the games I've implemented it, as it is a spot where you won't fall to certain death on respawn, and the timed invincibility grants no baddies will harm you, but it has its limitations:

- As mentioned, you can't respawn on a moving platform. If you are planning for a segment in which you have to advance jumping through a series moving platforms, the respawn will place you far behind and this may seem unfair.
- If conveyors are implemented, maybe the respawning spot is not that safe. Imagine you jump from the edge of a conveyor in the last minute.
- You (as the game designer) don't really have control. It may result on unwanted / exploitable glitches, or unfair situations. Imagine you descend like 8 screens without having to jump, then get killed. Back to top! [*]

@FrankenGraphics, I like your idea. I can detect if the jump is from a platform (in fact, I am using such detection to *not* register a "safe spot"). I could easily save the platform status. I could even take a snapshot of the values of every moving object on screen, and restore it alongside the player position. In fact, I think I'm going to try this on Goddess to see how it works.

I always need to KISS (yet effective) as I'm coding in C and have to cope with the overhead.

[*] This issue could be solved registering a safe spot everytime the player hits the ground. I could have implemented this but that would result in having to register the safe spot (much) more often, and every cycle counts. Maybe it's a fault in my engine, but usually you are registering a collision with the floor every frame as you walk.

Background hit checks could be resolved far less often (unlike against moving platforms and enemies), because(/if) solid blocks are always aligned to the grid.

Any attempt to move 1px in the wanted direction is called every frame, but:
and #$07 (value as an example) + bne then checks if the incoming value isn't a multiple of 8, in which case the branch goes around the actual detection code to let the movement attempt be. If background solids/semi-solid surfaces always are on a 16x16 grid, you can filter for a multiple of 16 (and #$0E). Either option should save you a handful of cycles.

A game can have different filters/masks for the Y and X axis if the level layout calls for it (not related to this particular game, i think, but one might want to have a different collision grid granularity on the Y axis than the X axis, for example).

Problem is, gravity is always pulling you down, affecting your vy. Vy gets added to y, player moves into the floor, collision is detected, vy is set back to 0 and player put on floor. Continuously.

What would happen if you change that sequence to: Attempt at adding Vy to y (the above condition check + collision goes here)?

My reasoning: In order for the procedure to be more lightweight, something that takes down the frequency of the procedure should be plugged in somewhere, preferrably near the root of causality. If vy isn't added to y because of a check, no movement needs to happen. Though, i think you'd need to keep upwards and downwards y alterations separate for it to work with jumping. (Edit: a state flag should be enough)

You might get a lot more mileage out of just rewriting the collision check in assembly instead of trying to do it less?

In my game a point collision against the background takes less than 100 cycles; it's not inappropriate or a problem to be doing 30 or 40 checks in a frame. If it was taking, e.g. 1000 cycles because it was written in C, it would be out of the question to do that.

No, you misunderstood me. I don't have problems with the collision check, it's *very* lightweight, no need to translate to assembly. I have my data very well organized and calculations are few and fast. My concerns have to do with the fact that:

- Maybe storing the safe spot *when* you are on the floor instead of just when the player jumps would be more fair to the player.
- Storing all the actors positions could take some time.
- Every Nth frame, when you are on the floor, the collision is detected. This happens because the way G affects VY and VY affects Y causes subpixel increments during a couple of frames, so collision doesn't register as it is calculated at a pixel scale. So detecting the transition of "I am falling" -> "I am on the floor" happens very often while just walking.

I don't think I'm making myself clear, sorry, I'll try to use numbers. I am using 4 bits of subpixel precision (1/16th of a pixel).

Let's start with the player on the floor, y_pixel = 32; y = y_pixel<<4 = 512, vy = 0; . Player is standing on a tile (floor).

- Frame 1, vy += G -> vy = 4; y += vy -> y = 516. y_pixel = 516>>4 = 32. No collision.
- Frame 2, vy += G -> vy = 8; y += vy -> y = 524. y_pixel = 524>>4 = 32. No collision.
- Frame 3, vy += G -> vy = 12; y+= vy -> y = 536. y_pixel = 536>>4 = 33. Collision!

In frame 3, collision is registered in the bottom of the sprite (there's a platform there and the lower end of the bounding box is inside such platform), so vy = 0 and y is repositioned just over the floor (y_pixel = 32).

Then back to frame 1.

Notice how during frames 1 and 2 the player is actually falling, in a subpixel scale.

So, is this statement correct? the continous flip-flopping between "is falling" and "is standing" while walking needs to be conditioned into a continous "is standing".

For the record, i think your current checkpoint mechanism works perfectly fine for this particular game and level layout, simply because of the high and relatively stable frequency a player will trig it. Introducing more (and varying reasons for) checkpoints potentially also means opening more gateways to hard-to-foresee glitches, cheats, bugs. And the edge between "is falling" / "is standing" as a replacement for "is jumping" poses the possibility of placing the player in a tough spot. Just maybe. Feels like a thing that needs to be tested for a while. Probably not too bad?

I must have been blind.

If you check the walkably of the pixel right beneath the player (just outside the bounding box), it doesn't matter which subpixel value the y coordinate has. It will detect the floor whenever there's one and not if the player is airborne.

Checking when this variable changes, and then saving the respawn info, plus saving it when the player jumps as well looks like the optimal solution.

But, as you say, saving when jumping is enough for this game. I won't touch it.