Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Genuinely if you look at my code its going to look like hot garbage to anyone who knows what they're doing. I really would appreciate having a set of helping hands to guide my hips because while I know what I want to do, its translating that will into the game's code itself. But that in itself might be a huge undertaking past anything in the realm of  "Hey do you think X would work?"  given my orkish understanding.

Honestly I wouldn't be able to tell you given I'm  akin to a, young capuchin monkey trying to design and run a nuclear reactor. 

(1 edit)

In your defense, the majority of RenPy game code looks like hot garbage.  Massive if-then chains, monolithic scopes, magic numbers; the works.  RenPy is definitely enabling non-developers to dev but at a cost.

A friend of mine is developing a game in JavaScript, and after the third update, they started to realize just how awful not understanding programming architecture is.  As projects grow they become more and more unmaintainable.  Debugging can easily consume all of your time.  Art and story are already crazy time consumers.  Development can easily grow exponentially on that front.

Kudos though.  I've tried starting games and I can't get past the engine phase.  I always want to do things from the ground up and I eventually get bored and move on.  Or demoralized by my awful "dev graphics."  It doesn't matter how great your engine is, graphics are the ultimate seller.  And my art skills are absolute trash.

On a final note, RenPy violates one of the core ideas of code, which is using a library and not writing within in a library.  The whole dynamic parsing infrastructure they have is painful to look at.  If possible I'd rip all of my code out of the rpy files and put it into py files so it can be properly digestible by intellisense.  Even if I have to pass the vars in I'd rather bite that bullet than deal with a parser on top of a parser.

All that aside, I think I'll poke through your code and see if I can automate it a bit.  Also look around and see if I can find an extension or something to help with RenPy.  Either way, I liked your game.  It was cute and fun.  I enjoyed the "more on the realistic side of things" lol.

Oh I've got a long list of failed games under my belt lmao, the most demoralizing for me was "Cube proof of concept" because it just, fell apart so hard when I thought it'd be so simple. But now, with what I know, I could very EASILY remake it in renpy.

Aaaah some fair warning I was in the middle of streamlining my files so my "script" file, the one renpy reads first, is still very messy, next release will have a lot more digestible and compartmentalized pathing with layered images slotted in their own category.  I hope its not /too/ disgusting to sit through, again its really my first time getting this far and a lot of my knowledge is brute forced , I know there are more eloquent ways to call things like the kids and if I could I'd make it so renpy made a new "child" each time the birthing process happens. 

Sssadly I can't seem to parse that logic in my own head. The only thing that gets me is the actual generation of a new character-instance. If it were in unity it'd be a simple value update with their variables matching what I want them to. .  .not sure how to add "npcs" dynamically though. 

Anyways long nervous rant aside I just hope my insane pathing makes sense!

I poked through the files for a while and eventually threw in the towel.  That's a lot to absorb.  If there was a "Go to declaration" feature for variables/functions/labels it would make things so much easier to digest.  Full blown programming languages do that and it helps a ton.

A new child would be potentially be a simple matter with the right data structures.  Essentially you have a child class, and each character has a dictionary of children.

class child(): [etc]

class character(): [etc, children = {}]

character.children["CHILD_NAME"] = child("CHILD_NAME", stuff, ..., etc)

You could then randomly generate children based on the character models.  All of the data would be stored in the character.children attribute/property.  And then stored locally however RenPy handles all of that.

You could even take it a step further and put age into character.  Then the children are actually just character objects but based around the age value.  character.children["CHILD_NAME"] = character("CHILD_NAME", AGE, stuff, ..., etc)

Unfortunately, all of this increases the complexity of your code.  At a certain point the logic management becomes a pain.  If age == young and is Poppy_Child and not Mitsuki.pregnant and etc etc etc.  The conditional flow of your program can get overwhelming.  Not to mention changing your data layout during a release is bound to create bugs

All big issues for game development.  Thankfully RenPy keeps things mildly manageable.  It's when you go wanting to add random objects like kids into the mix that you start poking into the heavy dev-end stuff.

I could toss you my discord or something if you ever wanted help or to talk deeper on possibilities.  Automation through code data structures is typically what I do in my professional day-to-day.  I'm more than glad to share the knowledge.

Sure thing! Drop me a PM on twitter with your handle and I can help explain my spaghetti code a lot faster than on here. More reliably as well. Heres a link to my twitter https://twitter.com/voimond