The source code link goes to github's 404 pages, is the repo private by any chance? Also no Linux or web version sadly.

I played a bit of the start but I can't figure out what the dash button is? I pressed a lot of keys on my keyboard but nothing triggered a dash :O

@pschichtel didn’t know for the source code and as for the web version I’m working on it in a panic ;) (edit repo should be working)

@straw Yeah sorry couldn't make a proper control list but for anyone reading the controls are
L/Right click for dash
M/Left click for wall climb
As for all the other physics interactions it's a bit more complicated but it should resemble (As close as my sanity allowed me) Celeste's mouveset

This is a really solid effort for your frist ever gamejam, and I love the handcrafted assets and writing as well! I will say that I wasn't able to progress past the first level since it crashed every time I tried to load the level (I tried like five times D:).

I'd also prioritize having the tutorial be a little more fleshed out to make sure that players don't have to leave the game to check the description or post-submission comments; you might lose a lot of players immediately because they might not have the patience to go hunting for control schemes.

I just wish I could have seen all you guys had to offer, this seems like such a fun little game!

Going to limit my comments to the visuals - they're wonderful. I didn't get to play anything after the tutorial, as the game crashed each time I hit the level transition. Regardless, congrats on what you've done here. This is mighty impressive for your first jam!

This looks very interesting, though there are several bugs preventing me from getting very far in the game. When I touch the sign to move out of the first area, the game freezes completely. Sometimes it is stuck on the screen touching the sign, sometimes I can see a glimpse of the next level, but everything is frozen. Even the music stops playing. Also, moving left at the start finds a hole in the floor. I also tried the downloadable version of the game, and it crashed trying to move past the sign as well. Though on one attempt I saw a glimpse of an ice level instead of a grass level.

To go over what is playable, the move set is very fluid! It really does the Celeste style very well. I like how even the feather on the cap indicates the dash has been used. The two conversations I can have are funny, and the visuals are very well done. I do hope you can fix the scene transitions so I can play some more of this game.

@innominev3945 Thanks a lot!! we really want to keep adding to it later but for now any bug fixes and qol stuff is gonna have to wait as all three of us are in mid-term exam week :/ but still looking forward do doing more of these :3

@glassmoongames Ahh the crashes, maybe adding a thousand custom spike sprites to make them look slightly better wasn't a great idea

@toppervideogames Thanks a lot i'm having a lot of issues with exporting this project as its my first time doing anything like that. Still trying to fix everything tho!

Cool game, especially the visuals, but the boost jumps killed me.

I am sure this is a great game, I like the design and graphics But sadly I could not get a hang of the controls. But I am also terrible at playing with keyboard controls.

@hansflyingturtle Yeah have no clue how to add controller inputs as of right tbh but ill keep in mind in the future!! also tried to make the game a bit more accesible!

Cool, i was able to finish it after a little while!!

This is pretty well done, really like the art and sound effects. I think the controls work as expected if i compare it to eg Celest but I can't honestly judge it cause i am terrible at Celest and sadly couldn't get very far here either.

But it still very well done!

One bug I think is that for me using Left and Right mouse button does nothing so i had to use m/l for dashing and climbing

The design of the graphics is particularly excellent, especially the scene construction. I really like the visual presentation of this game.

The art is amazing and gorgeous, congratulations on getting this much done in such a short jam - I'd say this game is absolutely worth a post jam polish to squash some bugs.

The art is amazing!

Great looking game but I'm really struggling with the controls, sorry!

@skiddings sorry to hear that, we are working on control settings for the post-jam version!

Pretty cool Celeste vibes. I liked the pixel art and the first song in the game reminds me of the old pokemon games :). I feel like the game would benefit for playing with a gemapad. Overall I liked it, I spent quite some time playing but I didn't get as far as I liked to.

Some suggestions:
* Make the dash along the current movement, sometimes I died because of a miss click and instead of going in the same direction as the character if I have not direction pressed the character goes to the right.
* If you miss, click dash while you are climbing, you lose the dash without doing it. I will be more permissive here and avoid losing it.
* Inform the user about the hat mechanic, which shows if you have a dash available or not. I realized because I played Celeste, but other players could not be aware.
* I think the difficulty curve is too steep at the beginning, I would present some forgiving levels to get used to the controls first.

Very well done, especially for a first game jam!

I would have liked a little more checkpoints, I ended up having too much trouble near the end of a level (a level in the stone area where you have to jump left out of a platform and dash up without hitting the spikes on the ceiling nor the ones just bellow at the arrival). I also felt the mouse controls where weird, I sort of got used to it (but I kept clicking outside the screen and it paused the game)

The levels were pretty well designs, you sort of got the hang of it through-out the levels, but I think for someone that hasn't played Celeste the learning curve was a little steep, but it was alright for me. Maybe a little "twist" over the gameplay of celeste would have been nice (or maybe there was one, but I just didn't reach it?)

I really liked the controls, it didn't feel like the character was floating nor that it had no inertia. The graphics were also nice, especially the background.

Overall well done, hope you will keep making games

Gorgeous pixel art and atmosphere! I can see the passion behind this — amazing job!

I did it!


First of all, this is *awesome* - It's especially incredible that this is your first Ludum Dare! You should be extremely proud of what you built. I've got a lot of feedback, but that's because the game is already extremely high quality, and the little details are what would really bring it over the top

In addition to being awesome, this was also *brutally* hard lol - It took me about an hour and a half to beat, and I love tough-as-nails platformers

Other folks have already discussed the controls, so I'll just echo that I unfortunately never got used to them - I'm not sure if it's because I'm using a US QWERTY keyboard, but trying to use the arrow keys, L, M, and Space was extremely awkward, as was WASD, L, M and Space. I ended up using WASD, Space, and the right mouse button, while *always* holding down the left mouse button, and this was the only way that I get past the more difficult challenges.

In terms of visuals, I loved the parallax effect in the intro area, and the sprites all individually look very good! My only feedback is that it would feel more cohesive if sprites were drawn with a uniform pixel scale. It was strange seeing background elements with huge pixels alongside foreground elements with tiny pixels, and it was especially noticeable when one element would have differently sized pixels inside of it - One example is this small tuft of background grass - If pixels were all the same scale, everything should be lined up on a 1x1 grid, but somehow things get offset by quarter pixels throughout the grass tuft:


Were you drawing your art in such a way that one pixel in your program of choice didn't represent one pixel of the finished sprite? Generally, the easiest way to create pixel art is to draw at a 1:1 scale, and then upscale it with nearest-neighbor interpolation by 1x, 2x, 3x, etc to fit your target resolution. That will easily give you consistently sized pixels, and sticking to whole number scales will avoid any artifacts from upscaling :)

In terms of level design, there were some challenges that felt great to clear, and others that felt very frustrating - The best challenges were the ones where death was an opportunity for learning, and where nailing the challenge rewarded me with some really fluid platforming to enjoy. The most frustrating challenges were the ones where I had to thread an incredibly tiny needle, and had to very slowly and precisely set up each attempt.


The above area is an example of that second type of challenge. I was banging my head against the ceiling again and again trying to hit the finicky wall jump to get through this gap, and it was really unclear *why* the game was asking me to do this. It wasn't particularly fun movement, and there wasn't an interesting puzzle to solve; it just felt like precision for the sake of making things harder on the player. Whenever you create a challenge, it's best to think about the experience you want the player to have, and build the challenge to provide that feeling. :)

Finally, I did run into one physics bug that unfortunately *really* negatively impacted the game feel: Physics seem to be nondeterministic, and the same inputs can produce drastically different results. This was particularly frustrating to discover at one of the last sections of the game, where I could only make the last dash *sometimes*. I suspect that the issue is that you're updating the player's velocity (or a timer for dash length) during update, but you need to be doing physics calculations like that during fixedUpdate or they will be unstable. The below gif shows what I mean:


Overall though, this is a *very* impressive game - Please don't take this as me disliking the game in any way! It was awesome, and you're already crushing it. I wanted to provide so much feedback because I spent so long with the game! Great job, and very well done!

@koolruz I'm really glad you took the time to finish it! (as a not so good gamer even less for platformers, i had trouble with it too) I can only answer this as the artist:

We had planned 3 levels with a much smaller learning curve (and the tutorial ended up staying as only the placeholder) but with the constraint of time, we ended up designing this singular level with all the difficulties included and without being able to include the necessary custom controls settings T-T

For the visuals, it was my first time working with pixel art, even less for a game. So in the end, yes, all my sprites were drawn at the same pixel size 1:1, but once i got in the game engine i didn't know how to actually proceed so i just worked with loose assets and scaling/placing everything at random until i got a good enough result. That must be where the inconsistencies appeared so thank you for mentioning it, i'll remember it for next time!

Thanks for such a detailed review! and for playing it until the end ;)

@koolruz Love the comment!! Very happy you enjoyed the game and actually finished it. Your information for the physics are actually very helpful and will definitely make their way to an updated version. I was actually thinking of simulating the physics for more consistent results (not sure how to yet but a teacher recommended it to me).

As for the game design I’m glad you were able to find them interesting even with their unpolished nature and again very pertinent comments and suggestions. Btw that little crook jump was a way for me to force the player to go up whilst not using the dash, I know it’s a frustrating one and I will try to make another version that preserves the idea, but (call me cynical) I still find it very funny ;)

Very happy to help! :) I actually just noticed that you have your source code linked, so I took a peek at the character controller to give a bit more specific guidance on making the physics deterministic (Hopefully this is welcome, rather than annoying! I honestly just love talking about techy game stuff 😅)

To explain what I mean when I say to use `FixedUpdate` for physics calculations, `Update` runs every time the game *renders* a frame, while `FixedUpdate` always runs at a consistent 50 FPS by default (you can change this in your Unity Project settings). A player who has a fast computer with the game running at 60 FPS will have `Update` called twice as often as a player on a slower computer running at 30 FPS. This is totally fine for non-physics related purposes, but when you're dealing with physics, a change in frame timing could drastically change what happens in the simulation.

For example, say you're trying to keep the player dashing for 0.5 seconds. If they start lagging when your timer hits 0.49 seconds, and the next frame takes 0.25 seconds to render, that means that they're going to keep moving at their current velocity for those remaining 0.25 seconds until the next frame renders, and dash *much* further than intended. If you were to update your dash timer during `FixedUpdate`, lag would no longer impact how long a dash takes - It would always finish in the same number of `FixedUpdates`, and always give the exact same results.

If you turn the `PlayerMouvement` `Update` function into a `FixedUpdate` function, and swap all references from `Time.deltaTime` to `Time.fixedDeltaTime`, that should get you 90% of the way towards deterministic physics\*, but inputs will randomly get dropped. This is because `Input.GetKeyDown` reads inputs every time a frame is *rendered*, and because `FixedUpdate` happens at a fixed rate, you might have multiple rendered frames between `FixedUpdates`. When that happens, the second update would clear out the `keyDown` before you read it in the next `FixedUpdate`! To fix that, instead of polling `Input.GetKeyDown` directly during `FixedUpdate`, you'll need to poll for inputs during `Update`, and set them into a local variable for `FixedUpdate` to read, which you can reset at the end of every `FixedUpdate`. (You might also want to re-tune your constants to the new framerate-independent physics to make sure that things feel how you intended the game to feel!)

If you're curious to learn more how this works at a lower level, [Gaffer on Games has a great article about fixed timesteps, and describes how one might go about implementing a fixed timestep in a custom engine](https://www.gafferongames.com/post/fix_your_timestep/). But as long as you're using Unity, all you need to know is that using `FixedUpdate` when dealing with physics calculations/timers will give you deterministic results :)

\*Ideally, you wouldn't want to just move everything into `FixedUpdate` - You'd want to split these functions up so that code which doesn't impact physics is running during `Update`, and the code which impacts physics runs during `FixedUpdate`. In this case as a quick fix, just moving everything to `FixedUpdate` *should* be fine (although I may have overlooked something), but I wanted to point out that this is a quick fix, and not a best practice! You generally want to be doing as little as possible during `FixedUpdate`, because you can get stuck in a death spiral of lag if one `FixedUpdate` takes longer to run than the length of time between `FixedUpdate`s. It also gets weird to have certain things locked to the physics fixed update that should be updating during frame renders (eg: animation timing, camera movements, etc), leading to unexpected jittery looking gameplay. This is all a broad-strokes oversimplification, but hopefully gives you a good place to start investigating further!