Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

VeryWeirdDev

18
Posts
138
Followers
3
Following
A member registered 39 days ago · View creator page →

Creator of

Recent community posts

(2 edits)

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.

I'm happy to hear that. All of the blame is on me for not making the game mechanics clear enough.

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.

(1 edit)

I will slowly look into it. A lot of stuff is new to me when it comes to this project so things might take time before I figure them out. As always, thanks for the suggestions.

Sounds like a good idea. I just need to figure out how to moderate it. I will make a post the when I create it.

Technically that would be possible. I will at least try to port it at one point in the future.

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.

Saving will have to wait until the game gets fleshed out. I could try adding a save functionality that would store only one run but there is a high chance that the save will break on every version update.

There's a chance though I don't want to promise that.

They are absolutely planned. Though I don't know when will I start adding them. I'm a software developer so game assets are the biggest bottleneck by a large margin.

Debug menu is hidden behind password and it is intended for development only. Depending on general response I might expose the password to Patreon supporters.

Thank you for 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.

I am glad to hear that!