itch.io

Ran this at an indie rpg club meeting for halloween. I loved it, and I think the other players had a good time. The one player who chose the Nihilist drive struggled, though, and it was mainly because we couldn't really figure out how that drive is supposed to work-

• Do you gain 2 thirst every moment no matter what? That seems bad because it means there are moments where your approach and conception of the scene do not matter because you'll need to immediately break off the moment for reaching 5 thirst. That's not fun and it disincentivises the player from engaging with creating a moment they know isn't going to matter. Playing it this way really made the Nihilist player very disheartened because we had a limited number of moments in the time permitted and she was conscious that for a given one of those moments her input into what the moment should be basically did not matter at all because her character would have to leave immediately after arriving.
• Is 2 your thirst "floor"? If so, does the Nihilist vampire always reset to 2 thirst when they break off? Or do they progress in thirst normally but have 0 or 1 thirst replaced with 2 for the purposes of moments?
• Do you always start a moment with 2 thirst regardless of your previous value, and can only ever be made to break off by a +3 thirst roll outcome? This would be very cool, and fit with the characterisation of a vampire who doesn't restrain themself in the way others more concerned with ambition do, but it's not really well-conveyed by the text and we couldn't really justify that being what was meant.

I know this game was released a long while ago now, but that was more or less our only big problem with it and I really enjoyed it, so I would love some clarification on how that drive in particular is meant to work.

Ran a MYNT game for my kickabout pickup indie RPG club. Everyone at the table enjoyed themselves, but we all agreed it was seemingly more through our own shared ingenuity at setting building (we ran a cyberpunk heist with horror elements involving generative AI) than the game itself.

First, the good: I like the actual MYNT rolls. I was worried that good "standard" spreads wouldn't be easy to remember, but very quickly they started to be. A 4:1:1 for something proficiently attempted but nevertheless risky, a 3:1:2 for something achievable and more likely to go weird than go wrong, etcetera etcetera- these crystallised in my head extremely quickly and came very naturally to me. It's a good idea and it was fun and cool to be able to say three digits in succession and have my players nod understandingly. An efficient way of communicating stakes. I love it.

The bad (technical): The sheet divides Wants and Needs into Implicit and Explicit categories, but the book doesn't explain what these actually mean or indeed mention them at all- instead it talks about Instrinsic and Extrinsic motivations and categorises all wants and needs into Intristic. I know what all four of these words mean in English but I don't understand what the game wants me to do with Extrinsic Motivations or the Implicit/Explicit Wants and Needs split, so we just kind of ignored all that.

The bad (fuzzier): This is a game that offloads a lot a lot of the busywork onto the GM. A big part of that busywork that I did not care for concerns managing your players feelings for them. The Aspects system is good for quickly rolling up characters and I like that it works in a FATElike "stuff affects the rolls it affects" kind of way, but therein lies the problem- since MYNT spreads are decided entirely by GM fiat, but aspects are supposed to affect the balance of the spread, your choice as the GM is either to hope that your players just trust you're doing this and pull three numbers entirely out of your ass every time, which has diminishing returns because eventually they're going to start feeling like their aspects don't actually matter one way or the other; or to carefully walk them through your reasoning for every single spread and what you took into account to get there, which wastes time and is boring. There needs to be a better implementation that either mechanises the inclusion of aspects, or at least makes that inclusion more intrinsically visible to the players outside the GM just thinking out loud.

Additionally, although every aspect is supposed to have both positive and negative effects, in a game with 3+ players the GM more or less has to trust the players to steward their own sheets and be honest about their own aspects. I can definitely imagine an emotionally mature player mentioning a downside to one of their aspects on a roll that currently has stakes so good it bores them, but I would trust them less to mention it when the odds are already stacked against them. I certainly couldn't keep track of my players' aspects- even if I could have seen their sheets I couldn't read the handwriting on two of them, and it seems impractical to keep my own separate record of everybody's aspects when they can gain additional ones and have them disabled through combat.

The twist die was also exhausting. I found myself rolling it less than I probably ought to have done just to avoid having to think of things for it on top of all the other work I was doing, especially given how vague and yet still sometimes inappropriate the tiers of twist were. I think, however, if responsibilities for the GM were reduced elsewhere in the system, this would be less of an issue.

The bad (petty): The entire game could do with an editor pass. It actually reads like it started to have one, but some areas got left out. Every so often an otherwise very articulate paragraph descends into this weird impulsive conversational cadence, which is not difficult to read, but difficult to understand in terms of relating to game mechanics.

MYNT is far from the worst implementation of this rules-light, D6 by default setting-agnostic kind of game, but it's hardly the best either, and all three of my players said that much as they'd had fun, they wouldn't be in a hurry to play it again. Unfortunately I think I agree.

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)

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 }

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!

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.

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.

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?