Never played this game, have no packs or anything downloaded, and even navigating around the main menu is throwing constant errors
not ready for primetime I think
not ready for primetime I think
- Oct 24, 2019
- 1,391
- 1,110
I'm still sticking with None being totally different from everything else and just above the level of using Python to check if a variable is defined. That will catch all of your fat fingering errors.
It may be valid to conflate empty lists, dicts, sets and tuples with False, but that's bad practice. These are always going to be treated differently from scalars because you will be pushing/popping, adding/deleting, iterating over them much differently than scalars. It's much better to use len() to be zero/non-zero on them then to check True/False.
You are also going to want to abstract them away behind class frameworks where you can define getters/setters to check bounds and prevent novices from ruining your day with them.
Rollback won't be good for a battle, but casuals will love you if you let them rollback scum the last move when its that time of the month for the rng gods. Yeah, I can jump into the console and change everything, but it keeps immersion to be able to cheat a bit. One of my pet peeves with bk when I played it quite a while back was the way a training choice could go horribly wrong right away and you had no way to undo it.
SoC actually has a pretty advanced class framework for the buildings and research. They never did quite get it right and then had let maintainability go to pot by spreading data structures around all over the place. The users saw things like the unproductive forge bug getting fixed and then coming back a release or two later. So, I rewrote the building framework as a set of proper subclasses for them and moved their data into the class initialization sections. That new clean framework has been in the last several releases. I doubt they would have done this themselves at any point since they were too busy putting out fires and adding story.
It may be valid to conflate empty lists, dicts, sets and tuples with False, but that's bad practice. These are always going to be treated differently from scalars because you will be pushing/popping, adding/deleting, iterating over them much differently than scalars. It's much better to use len() to be zero/non-zero on them then to check True/False.
You are also going to want to abstract them away behind class frameworks where you can define getters/setters to check bounds and prevent novices from ruining your day with them.
Rollback won't be good for a battle, but casuals will love you if you let them rollback scum the last move when its that time of the month for the rng gods. Yeah, I can jump into the console and change everything, but it keeps immersion to be able to cheat a bit. One of my pet peeves with bk when I played it quite a while back was the way a training choice could go horribly wrong right away and you had no way to undo it.
SoC actually has a pretty advanced class framework for the buildings and research. They never did quite get it right and then had let maintainability go to pot by spreading data structures around all over the place. The users saw things like the unproductive forge bug getting fixed and then coming back a release or two later. So, I rewrote the building framework as a set of proper subclasses for them and moved their data into the class initialization sections. That new clean framework has been in the last several releases. I doubt they would have done this themselves at any point since they were too busy putting out fires and adding story.
Why? It's entirely legitimate to possibly not have something (not because initialisation failed, etc, but because logic dictates there's nothing there, like there being no girl to display for interaction because you deselected her, or sent them all to the farm, or whatever) and to check to see if it's there or not. Python's None is also not quite (just) the same thing as a null value.
Empty lists/tuples/sets are also 'False' and are frequently used as such.
I don't disagree with that (at least in general). I don't recall BK doing either, though.
But '()' is a Tuple? '{}' is the empty set. You're right in that using tuples and lists somewhat interchangeably has bit Goldo in the ass before.
Yeah, like using dictionaries.Ren'Py rollback isn't as robust as you seem to think it is.
How is this even relevant? If the battle is anything like it is in one of these tactical RPGs, you'd be rolling back hundreds if not thousands of steps per battle. Mouse rollback would make you die from carpal tunnel long before you've reloaded even a dozen battles.
Or if you're rolling back every failed check you don't like, it'd be cheating on such a scale that you'd be far more sane to just cheat in Swords of Evisceration +100 for everyone and call it a day.
Last I looked, Seeds of Chaos was mostly a series of classic VN events with some mild RPG stuff bolted on top. Nowhere near as intricate as a management game of any kind. BK's closest Ren'Py comparison is probably the (now dead) Pytfall.
It's entirely conceivable SoC doesn't have complex enough data structures to be mangled by rollback. Or maybe they do and have it solved. Or maybe they're not even aware that these problems exist. IDK. Your post indicates nothing of the sort.
While dynamic typing can have its pitfalls, this seems to be another 'programmer religion' argument waged purely for amusement. I doubt you're going to offer yourself as code cleaner and maintainer for BK. I guess such arguments can be fun, and a bigger project does need common guidelines, but insisting on your style handbook being gospel for someone else's project...
Neither me nor Goldo are programmers, we do these things for our amusement and maybe a little personal education, and and we don't expect anyone else to come after us. BK is a one-man passion project, and likely to remain one until it or its creator die. There are certainly things we could both learn and do better, but I don't think this is one of them. Feel free to make a thread on HHS and prove us wrong. Because I think this thread is cluttered enough as it is, and Goldo will never read it anyway.
- Jun 2, 2018
- 543
- 690
Changelog:
You don't have permission to view the spoiler content.
Log in or register now.
- Nov 26, 2020
- 885
- 1,209
um goldo i think most people had the same issue of confusion as i when i ask on the hhs forum , the Brothel_King-0.2+test2 still need the patch to function with lesser error and actual playable but with the way how you name the file, one would assume the patch is not needed which might be the case for lots of these complains about it not working properly.
Love the concept, but speaking as a professional developer, I fear this project will never be finished or stable.
For a game with so much state, Python is a terrible fit. It's doable, and it's been done before (albeit rarely), but the architecture and code quality should be close to immaculate to avoid a buggy mess. Reading some discussion above, it appears this is not the case.
Forward compatibility is an even greater hurdle. And this is exactly the sort of game where that matters. It looks like a very slow burn which could take dozens of hours (maybe even around a hundred?) to complete a playthrough. Even the small patches have bricked my saves. The odds of any kind of meaningful save compatibility is practically non-existent.
Some of my favorite h-games were made with Ren'Py, but one has to realize that game engines are tools with specific strengths and weaknesses. I hate to say it, but making this specific game in Ren'Py without major programming chops is a fool's errand. Even with said chops, you'd still to some degree be forcing a square peg through a round hole.
My suggestion would be to start fresh in Unity, Godot, or hell, even GMS/RPGM would be a better fit. Ren'Py is the absolute worst choice given the context, and the odds of getting a completed, relatively stable game are not at all good.
For a game with so much state, Python is a terrible fit. It's doable, and it's been done before (albeit rarely), but the architecture and code quality should be close to immaculate to avoid a buggy mess. Reading some discussion above, it appears this is not the case.
Forward compatibility is an even greater hurdle. And this is exactly the sort of game where that matters. It looks like a very slow burn which could take dozens of hours (maybe even around a hundred?) to complete a playthrough. Even the small patches have bricked my saves. The odds of any kind of meaningful save compatibility is practically non-existent.
Some of my favorite h-games were made with Ren'Py, but one has to realize that game engines are tools with specific strengths and weaknesses. I hate to say it, but making this specific game in Ren'Py without major programming chops is a fool's errand. Even with said chops, you'd still to some degree be forcing a square peg through a round hole.
My suggestion would be to start fresh in Unity, Godot, or hell, even GMS/RPGM would be a better fit. Ren'Py is the absolute worst choice given the context, and the odds of getting a completed, relatively stable game are not at all good.
- Oct 24, 2019
- 11,541
- 11,727
uhh .. yeah .. i'll repeat myself i guess O.O
i have 15b ... is this and update for that ?????????????????
Hold off a few days. The announcement of 0.2 release was a bit early at this point. Goldo the main dev released a "release candidate" for being 0.2, but it had not yet been tested, and it is turning out to have a few bugs. Wait a few days for him to fix them.
0.2 has been in the works for over a year and 1/2. Since 0.15b was frozen by Goldo. So, when 0.2 is ready, it will be the next stable release. We're not quite there yet, but we are very close.
Arguing about programming here is pretty stupid.
There is a reason Python is super popular and there will always be Trade-offs.
As for Rollback, did you even try to look at the code? With that much Python there is not a chance.
Renpy is used more like a display system than anything else.
There is a reason Python is super popular and there will always be Trade-offs.
As for Rollback, did you even try to look at the code? With that much Python there is not a chance.
Renpy is used more like a display system than anything else.
- Jan 23, 2021
- 285
- 393
Please let us know which girl(s) caused an issue if you could, so we can verify the errors, contact the creators and/or remove them from the Girl Packs google sheet.
We've been thinking about putting together a download bundle of multiple recommended girls to simplify this process for newcomers.
- Aug 2, 2019
- 431
- 248
I answered it about 2 pages ago that its not an update for 0.15b. You need to redownload the game for it. And apply the patch.
- Oct 1, 2017
- 2,475
- 6,113
No pregnancy is in this game at this point, and it is unlikely to be added. If you or someone else can figure out a good way (as far as gameplay goes) to deal with pregnancy within the scope of a game like this, it's possible it could be added. But so far I've seen no concrete proposals that make it work well.
- Oct 1, 2017
- 2,475
- 6,113
- May 30, 2017
- 1,083
- 1,079
New patch for 0.2 fixing recent bugs:
You must be registered to see the links
- May 30, 2017
- 1,083
- 1,079
0.2 version changelog:
So, what's new in this 0.2 build?
So, what's new in this 0.2 build?
- Girl 'mixes': You can now use the girl mix option from the main menu to create various mixes of girl packs (such as 'real girls' or 'bleach girls', or whatever you fancy). When starting a new game, you can then choose which girl mix you want to use for this particular game. No more moving folders around...
- Girl personalities: There are now 24 fully dynamic girl personalities from the 8 hard-coded original ones. Moreover, there is now more flexibility for girlpack makers who want to introduce their own and the system mixes well with the new...
- Dialogue system: This is a huge change in the way girl dialogue works, and it does basically nothing. Let me explain: All the girl dialogue has been changed from being hard-coded to being fully customizable, according to, among other things, girl personality or personality traits.
You shouldn't notice any difference for now, though, because the dialogue has remained the same... But basically it means anyone can now edit BKdialogue.rpy and add or change whatever girl dialogue they want. (note: there's a thread on HHS forum dedicated to new dialogues writing)
- Achievements: By popular request, achievements have now made it into the game. There are hundreds of them, so it's going to take a completionist a while to get all of them.
- Contracts: Contracts will fill the 'mid-term goal' role. Starting from Chapter 2, Scarlet the job girl will offer a choice of 3 contracts every month. Contracts have requirements like quests, but harder, and a much bigger payout. You have one month to prepare one of your girls and send her on a contract. If a girl matches all requirements for a contract, you might be offered a large sum by a potential buyer... Potentially making selling your girl a good choice, and maybe introduce some girl rotation.
- Difficulty settings: The basic framework for difficulty settings is now in place.
- Easier modding: Items/furniture, traits, perks, postings and spells are now included in their own .rpy file, letting modders change or expand any one of those categories without fiddling with BKstart.rpy (and having each update break their work...).
On a side note, stat names can now be renamed in BKsettings.rpy, making translators life easier too.
- Various bug fixes: Bugs identified in the bug thread should mostly be fixed, however new bugs are sure to come up. Please use this thread to report on them, even if they are 'old' bugs.
Note that when you add a patch remember to delete the old .rpyc files or you might still get errors.