I probably add "save" functionality for current run in case the player is in hub. I don't intend to add "game over" state though. Things that will persist are the already mentioned sandbox map with currency for it, some kind of achievement system and anything else that I think makes sense. These things are similar to tutorial when it comes to implementing it now: it will cost me too much time and effort to maintain them while I'm still creating an actual gameplay loop. So the best thing in my opinion is to ask for patience while I'm searching for ideas that I want to lock in.
VeryWeirdDev
23
Posts
201
Followers
4
Following
A member registered Jun 30, 2026 · View creator page →
Creator of
Recent community posts
Thanks for the long feedback!
To answer your question: I aim to create something like a roguelite game where regular runs reset character progression but allow the player to collect some kind of special currency that will be used for creation of their own map. That map should act as a sandbox where player brings NPCs to have fun with. The idea on how to actually achieve that is still forming so I can't say much more than that.
As you said, this is in early development. Things are only partly implemented because of that. I'm currently working on clearing a lot of mess and creating a gameplay loop where quests will be driving it. The repetitiveness is something that will take time to flesh out. I certainly want to do it but it looks like it will take time before I come up with a nice relationship between randomness, determinism and objectives.
Systems in the game still change a lot so I think that having a misleading tutorial would hurt more than it would help right now. I'm using the excuse of game still being a prototype for this point.
UI is very messy and that is one of the things that I'm cleaning up due to it being poorly stylized. Next update might cover some of your concerns about it but I won't promise anything yet because I'm focused on standardizing UI for now. Tooltips (and anything that requires mouseover) will be removed from the game because they don't work on touchscreen and I want to make a port to android in the future. That would mean that either UI/UX needs to be good enough for players to infer what a mechanic does or the guide needs an explanation for it.
Thank you for letting me know. Tooltips exist for few things right now but I think that I will remove them in the future simply because I want to port the game to android and tooltips aren't really suited for mobile UX. With that in mind I will probably create a very short text guide for things that I'm unable to explain through UI. Since the core mechanics are still not complete (for example: I don't know if I want to keep Focus stat), I'm postponing those changes.
You can cast restoration spells to free parts of your body while in combat. That should help you with 1v2 scenarios. Though bare in mind that the game is still not balanced as new updates will include mechanics that affect combat. Game is still in prototyping phase so I am trying out different things and keeping the ones that look fun. That is the reason why balance is still not something that I work on right now.
You can level up by draining stats from a defeated NPC. To do that just go to bound NPC and interact with them by hitting 'E' to reach UI component that allows it. There are limits on how much you can drain and how many stat points are needed for a level up. I will eventually add a tutorial to the game that explains the intentions better but it is still too early for that.
Glad to hear you like it! I am aware of that bug though it is partly intentional. The idea is that the player poses no threat when they are restrained at over 100 restraint strength which is why NPCs don't care about the player. In the following updates I want to change it so that some NPCs will still want to leash the player regardless of the restraint strength level.
The reason why the player needs to be able to traverse the room while restrained is because the Sub playthrough will require it.
You have to restrain all arm slots and mouth in order to stop the enemy casting spells in current version of the game, not just the wrists. The same rule is applied to the player. So if you are in 1v1 combat the most efficient way to win combat is to go for all arm restraints and mouth. Just bare in mind that stats play a role in turn order and restraint resistance/strength so go for equally leveled NPCs. Though you will probably raise commotion to the max value and all free enemies will rush to you. The commotion mechanic needs updates. There will be a tutorial in the future when the main gameplay loop is established.
I am currently working on an overhaul of the NPC subsystems. With your feedback in mind, I will do something about the difficulty when I finish the stuff that is in progress right now.
I also wanted to make the combat faster so I would appreciate if you could tell me if the pace feels slow.
I like the suggestion of facial expressions...the issue with them is that they require new game assets which I'm very slow and bad at producing. I'm beginning to sound like a broken record when it comes to game assets. I've started reaching out to artists in order to fix that problem.
As for the monetization and FOSS:
Right now my intentions are to keep the game free at least during the development of it. I don't even know if the game will have a complete state. Since I don't intend to be alone on the project right now (I need at least an artist) I can't promise that the intentions will remain the same. I will think about that much more after I talk with my potential future partner. That also partially answers the state of source code, it will be closed indefinitely.
Side note: I immensely respect FOSS even though I never practiced it myself. And a side note to the side note, I like working alone when it comes to programming so I will politely decline everyone who wants to contribute with code for now.
I love your progress and determination.
If you want to take advice then here are some:
- Precise naming is very important as it will become extremely difficult to navigate around the code if variables are not named correctly. Bondage Room is good for now, as is the case with Ground and Wall. They carry all the meaning they need to carry right now. Objects can be ambiguous if there are too many types of them, and if that is the case you should split them by type. Event Object is something that should definitely be renamed.
There is a saying by Phil Karlton that goes like this: "There are only two hard things in Computer Science: cache invalidation and naming things."That saying later became somewhat of a meme but the "naming things" part is true and will always be true.
- This goes hand in hand with naming: project architecture. Grouping everything into one big directory while the project is still small is okay. But things grow over time and to make it easier to navigate your thoughts you should group similar files into subdirectories. Example grouping could be the following:
* Player and future NPC scene could be grouped into Character directory.
* UI component scenes could be grouped into UI directory.
There are no hard rules when it comes to naming or grouping files so make up your own rules. Just keep them consistent.
I hope I wasn't obnoxious with the advice. Your work is amazing.
I am completely alone on this project. The pace is only fast because I am trying out things and accumulating technical debt. I intend to spend some time working on things under the hood now. Refactors and simulator primarily. I am also using that "pause" to look for an artist to work with since I really dislike everything about my current art workflow.
The 15 day (or any interval) idea sounds good when the project grows into something more stable.
As for the DeviantArt I would appreciate any help. Here is my account link: https://www.deviantart.com/veryweirddev
That's the general feedback I'm looking for! Some of the things you said were already planned but others did spur my imagination.
Since you are a developer as well I believe you know that some things take time to create and polish. Thankfully I don't have to explain that any further.
...As for the password security...yeah, that was a duct tape solution which is good enough for now. I am not going to hate people practicing piracy. It would be hypocritical as I have done it so many times when I was growing up. I might make it more secure later though.
The game is still in very early phase. Balancing will eventually come, in fact I am building a simulator that should give me at least some insight into how difficult the game is. I have no idea how long will it take me to make it or how good it will be. Simulators can be nasty thing to make generally speaking. Until then I can only rely on feedback, based on actual human attempts, like the one you just gave me. Thank you for letting me know about the difficulty.
I will admit, putting the debug password behind paywall was a dirty tactic. But I will keep it as supporter only feature since the supporters are most eager to see the project succeed and they want to provide more than the feedback.
Yeah the balancing is currently non-existent...that is something I intend to work on as new features come and people give feedback just like you did. Thank you!
There are already tomes that are put automatically into the inventory when looting chests and defeating enemies. Those tomes teach the schools. Bare in mind that the schools are very far from being complete.