- Thread starter xןʞ
- Start date
-
- Tags
- 3dcg ahegao anal sex animated bdsm big tits corruption cosplay creampie dating sim exhibitionism female domination footjob groping group sex harem lactation lesbian male domination male protagonist masturbation mobile game oral sex sandbox spanking titfuck trainer urination vaginal sex virgin voyeurism
- Mar 25, 2019
- 64
- 58
good game, keep up the good work!
I still wonder whats going to happen in that 8th room.....
I still wonder whats going to happen in that 8th room.....
I'd like to fill up 12 rooms. But there's no ending in mind yet. It'll happen for each character, but I don't know when that will be yet. If I had to take a rough guess, I would say maybe around 50 friendship is when most characters will end.
I feel like you've probably not programmed a day in your life if you're still making jokes about spaghetti code.
If you have an example of poor code, let me know. I'll try to fix it.
Harem Hotel is my first game, and my first experience with Honey Select, Renpy, and Python. So there is a lot of stuff I made early on that was not the best way to do it.
- Sep 28, 2018
- 4,366
- 23,440
For some reason I am reminded of a saying from another game, "Most women are like spaghetti, straight until you get them wet enough".
Well just because the floor is there doesn't mean that it is necessarily rooms, could be other stuff like a gym or a movie theatre or a potential penthouse (for future MC habitation)
Yeah well, you could have fooled me. Didn't act very professional, acted quite childish.
A real professional would have stated where there was errors if any and provided alternative ways to do things.
Appreciate this. A good start would be switching to an object based model - it makes complete sense for a game like Harem Hotel with many girls and rooms being available that function much in the same way.
A good example of this is with lobby events. Imagine if you could throw one onto a queue once you finish an event rather than having a sizeable number of if statements run every time the lobby is visited.
You don't have permission to view the spoiler content.
Log in or register now.
You could definitely reduce your main file from 30,000 by making your all rooms function in the same way. This can reduce a lot of boilerplate and make sure you don't have to check every possible condition whenever you interact with a door to "Talk" for example. The next event could merely be bound, with an optional tuple such as a condition (e.g. the friendship of another character must be >5)*, at the end of the previous one.
*see: anonymous functions / lambda expressions (they may be differently named in python but I have used them in the past)
This is targeted at reducing the amount of repeated code very similar to this:
You don't have permission to view the spoiler content.
Log in or register now.
Lastly, I'd seperate a lot of the text from your main game logic. This is more a personal preference thing, but it's generally considered bad practice to have one 30,000 line file dictating most of your game. Moving most of the text out to event specific files makes things much easier to develop when you have files with more manageable chunks.
This all comes from a cursory glance through a few files, mainly the main script.rpy, and the only reason I thought to look was the game often seemed to needed a bit more time to travel between areas than other games do.
Great game content wise though, hope this helps!
Yeah, that's the main mistake I made programming that. I just didn't know how else to do it, now I do though.
I actually hit the max file size for HH's script in Atom so I had to separate it into more files, such as clone_events, ash_events, and the newly added lin_events script files. It's another thing I just didn't consider because I was new at it.
I'm not making these mistakes anymore, at least not that I know of. I just don't see a point in fixing something that isn't broken in this case.
I think general optimisations would be a good enough reason, you'd reduce a bit of RAM usage (not a huge issue tbh) and make your game smoother to navigate - but you'd be saved a lot of grief both in debugging and in reducing the amount of bugs you originally have by transitioning to a standard format for your characters and rooms. Obviously it's impossible to know where all your bugs come from my perspective but I feel like this would help a lot. Implementing linear "Talk" events should be a 10 second job once the text and scripting is done for it - then it shouldn't need to any more effort on your part.
Furthermore, from what I've seen most stats are in variables such as "bot_friendship" etc. I'm assuming the stats screens are therefore made new for each character? These could be very easily automatically generated with no effort on your part. This is one example of where your time both in development and debugging could be saved.
Regardless, I'm glad to hear you're getting better, I'm sure any further games you develop will benefit greatly from your skills.
- Sep 17, 2018
- 4,439
- 5,662
Don't bother, nothing speaks against "Spaghetti Code" if it fits the case. And Ren'py tends to have long linear passages, so it fits perfectly.
I think what it comes down to is the fact that his game is patreon supported, and few patrons are going to be happy with a break in the content release schedule so Runey can clean up some code that was working relatively fine as is, ya know?
For example, Summertime Saga is going through something like this currently where they're updating some old animations and character models and a lot of folks are extremely unsympathetic.
In a dev model like this, it seems best to just learn your lessons and move on.
I'd say he's earning enough money to hire someone to clean it up on a different branch and actually end up releasing more content, especially in the long run. The code can be done by any professional developer, the real value is in the creative aspects of the game.
You never know what someone's financial situation is and what their needs are. With all due respect, it's pretty presumptuous on your part to suggest he should have enough for something when you've not seen the man's checkbook. I think you should leave other people's business alone in that regard.
Totally cool to discuss coding but I think you went too far there, friend.