On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit) (+1)

Great game, its like INK except its my blood instead :L

I kinda get why you have the character do the first run blind but I think it would help rather than hinder the gameplay if you flashed it on screen and then let people do their first run otherwise it feels like I'm having my time wasted for the hell of it, I could plan a pretty good path just based on the level layout but that's not a perfect system.

Also, if you're going to make the player chain jump combos like this then you should be using an input buffer on controls imo. Otherwise players end up pressing the jump button at what looks like the right time to them and then fall down... this is what people actually mean when they complain about games having 'imprecise controls' even though code is actually TOO precise. The game can still be made hard by having a very short input buffer like 2 frames and feel so much better to control. Its only prominent on wallhopping from left to right and vice versa though so it was manageable.

Visuals are great, the music fits well but can get a bit repetitive after a while and I love the weird little character creature, the blood stains to serve as a visual aid was a really good idea as well

Overall really good job, I had fun playing this (apart from the level above).

P.S if you want to see a working example of input buffering then let me know, I use it in my game to solve a completely different problem with blend tree animation

Wow, thank you for this!

 Haha. 

Yeah you're right. Otherwise its like "die once to start playing". 

Ohh the good old walljump, i think that feature hits my rating right into the face haha. I was used to the walljump, so i didn't realize the bad behaviour. I think for the input buffer i could simply add a courotine which sets the "walljumpbool" after a certain time (after leaving the wall) to false. But of course i'm interested to see a better variant :)

Thanks for your words. Never got such a detailed feedback.

(+1)

It may not be the best way but what I use is a list of previous inputs I want to track, in my case it was vector2's up to 4 frames prior because I wanted to know directions, but you could do it with bools for input received etc:

List<bool> _prevInputs = new List<bool>();

and then inside each Update() (or method called inside Update):

 if (_prevInputs.Count > 4){ 
               _prevInputs.RemoveAt(0);
 }
_prevInputs.Add(input);

The same implementation can be used to check if we were grounded x frames ago to allow the player to coyote jump.

Your way may be better depending on what you want to achieve or there may be even better ways to achieve this that is more performant that what I've done, this is just simple and works for what I needed.

Deleted 3 years ago