Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

CleverCrumbish

22
Posts
1
Topics
5
Followers
8
Following
A member registered Nov 12, 2016 · View creator page →

Creator of

Recent community posts

Yes, as long as you have DS4Windows. Otherwise you can map it with Steam Big Picture but that might not be as easy.

The game does support gamepad, but only Xbox-based pads by default. Steam big picture or DS4Windows should function as a middleman without needing to change any settings though.

Ah sorry, just realised what I said could be misinterpreted. What I mean is "If you are using DS4Windows, it is not necessary to custom-bind buttons to keys. Bloodborne PSX has native controller support that DS4Windows' default spoofings map to perfectly."

I'm investigating this cause I'm also experiencing it and I think it has to do with loading screens? Try dying in the same area as the lantern you respawn from (if it's the Central Yarnham lantern there are enemies at the bottom of the ladder), and see if that makes a difference.

It should not be at all necessary to bind keys to use a ps4 controller through DS4Windows. The game has native controller support that can be spoofed to.

The trick weapons are available on the steps in the hunter's dream like in the real game. You can't activate their trick until you get inside though (which requires 1 insight)

(2 edits)

Lilith just tweeted them:

SOCKEM - unarmed gets a small damage boost
TOPHEAVY - big head mode
YESYOUCAN - pet dog mode
CONVOLUTED - alter time with the right stick
SPLATSILVER - paintball mode
ICHANGEDMYMINDTO + [text] - change your name
WHATIFITWAS + [text] - change 'you died' text

Just went back in, died in an easily accessible area, went back, killed all enemies there. No bloodstain, and all the enemies gave the normal number of echoes on kill. For whatever reason bloodstains are straight up not working in my game.

Haha yeah, only local MP back then.

{ Sinister Bell resonates with another... }

{ Adversary Your_friends_19yo_brother_down_from_upstairs has arrived }

(1 edit)

The latter. I've never seen either a bloodstain in either form and I died many times in my session in areas I could easily return to and would know where to expect to see it. I don't expect (real or faked) online-only features lol that'd be such a scope bloat for poor Lilith!

(1 edit)

Really fun experience, properly invokes both Bloodborne itself and the PSX aesthetic that is my sweet spot for nostalgia and that I'm thrilled to see more people beginning to embrace in their retro projects, but having played for a couple of hours I have to say that I think removing the bloodstain mechanic was a mistake. I take the point that a "pan-life" mechanic like soulsborne bloodstains might be a little "out there" for PSX-era design sensibilities, so removing it is probably authentic, but it's only when you lose it that you really realise how critical to the design formula (and definitely to Bloodborne specifically, which otherwise encourages aggressive and risk-taking play through mechanics that have been retained) it is. Respawning and knowing my lost echoes are gone for good discourages me from returning to where I died, which in turn over a long enough play session discourages me from committing to any single thing or having a coherent direction to play, which starts feeling unfun after a while.

I also think analogue stick support would probably be a fine accessibility addition (later PS1 games did have it, after all, so it's not completely inauthentic) but I don't know that I require it personally. Aside from that, this is everything I'd hoped it would be.

So it seems like this behaviour is a bug, and I think it has something to do with loading screens. I wasn't able to get a bloodstain to appear until I reached the Great Bonfire lantern, which has enemies in the same area as it. Dying to those enemies caused a bloodstain (or rather a blood infusion of one of the enemies) to appear, but dying in a nearby area one loading screen away caused there to be no bloodstain. This isn't consistent, it seems, since I was able to get a bloodstain a loading screen away in another case, but I never got bloodstains while working from the Central Yarnham lantern, which (as long as you're not going back down the ladder) requires you to go through a loading screen before encountering any enemies; and I died many times to those enemies.

Fixed it! Not Raylib's fault at all, my weird game loop structure was to blame. Update incoming.

In theory? I don't think you could use it as a while loop condition the way it is by default because I had other problems in this project that suggest key capture granularity isn't that specific and would fail to have the intended effect, especially in long game loops, but there should be a way of doing it. Maybe you could do it with a boolean that checks if the escape key is currently held down and blocks a surrogate variable that a conditional checking WindowShouldClose() would otherwise set... To be honest, it may be another problem in my own code causing this, since the raylib devs' recommended examples on github issues specify unbinding Escape with SetExitKey(0) the way I've done with no further loss of functionality.

I might actually muck around and try fixing this problem specifically, because you've made it intrigue me and obviously any future raylib projects would have the same problem. I'll see what can be done.

(1 edit)

Hi Colin!

All good suggestions, though I'm afraid in each case the reason for the problem is "I ran out of time in the jam".

The X button not working was actually a deliberate call I made based on what I have to presume is a bug in raylib. The "WindowShouldClose()" function in the basic window example on the site is actually in the game code, but captures the escape key without ever passing it to developer code and uses it to quit the application. There is a function you can use to remap or disable this behaviour, but (unexpectedly and I think incorrectly) it also disables WSC()'s ability to capture the X button. If, as in my case, you don't have time remaining to reimplement WSC()'s X button behaviour from scratch, you must then make a decision as to whether it is more problematic for the close button not to work or for a single no-feedback keypress to terminate the entire program. I chose the latter, but I agree it isn't ideal.

I agree that having a mechanism for increasing difficulty would be good, and I even considered the one you suggest during the jam, however it would require the way the game spawns obstacles and collectables to be completely reworked - currently, each 32px row can only have one item (wall or DBloon) on it - this is to prevent object generation having to take into account where other objects spawning at the same time are, but also more importantly to prevent the game generating a scenario where progression is completely blocked off by obstacles (technically this can still happen, but the chances of it happening, at least at game start, are (0.0125^24)%, which I considered acceptable odds). I could do this, but not in the time allotted, as it would require a more complex system for managing row spawns, and one that would probably need to be abstracted into a game state structure of the kind I spent the entire day on Wednesday implementing before ripping it out on Thursday morning when I realised I wouldn't be able to fix the circular inheritance issues it introduced in time.

In theory you could keep the current system by simply changing the probabilities of each encountered object on a row as the game progresses, but this would cause a weird difficulty deceleration behaviour if, as you suggest, progression were tied to score, as DBloons spawned less often. In that case I would probably tie it instead to total distance fallen.

Ultimately I don't think I will be returning to this project. Most of my associations with it are frustration and lack of sleep, and I don't think it's anywhere near as strong an offering as my game from last year. I have thought about rewriting that game in raylib or another C++ library, however, so I will take your criticisms on board for that potential project.

Yes! Together those would solve most of the frustrating issues with large builds I was having! The only other things I found myself wanting were the ability to fly in edit mode, and the ability to change the player's size with functions even with sizes disabled, to allow for Alice in Wonderland style "Drink me" business; but those were a bit more fanciful desires.

(1 edit)

Really love the aesthetic and (most of) the jankiness, but found too many kind of important features missing just at the moment- most of them are "nice to haves" and some might even be bad ideas given the foundationalist, non-polished aesthetic, but the lack of a group function or tiled duplication, or really any way of propagating lots of the same prop in a structured way except meticulously placing them one at a time after duplicating them with the move tool, really killed any ability I had to follow my imagination to build like, actual spaces or environments. I can see an update is forthcoming and I'll wait for that to see what new toys we get to play with.

Ah, unfortunately no new testing data here. But thanks for playing anyway!

Absolutely. Well done. Can I ask what OS you were playing on?