OniArtist
patreon
Rogue-Like, programming and stuff
🕑 Added 2015-12-30 23:17:10 +0000 UTC I thought it would be fun to briefly discuss programming, and how it's working in Rogue-Like at the moment (and why certain bugs appear). There have been a number of bugs in the more recent build that trace back to a common flaw, and that has to do with control flow. Basically, in Renpy, you call out a section of code by using "labels." If you say "jump" and then a label name, then the game will stop what it's doing and go to that new place. It's a one way trip, there's no easy way to get exactly back to where you left when you use a "jump."The second method is to use "call" followed by the label name, and this method has the benefit of being able to use "return" to go right back where you called from. Now, where this can become a problem is when you get too complex in messing with these call and return stacks. If you call, call, call, and then return, return, return, then you get right back where you started, but what if you want to skip some steps? There are ways to do this, some simple, some complex, but you basically need to prepare for any options you give the players, so that you can get them back where the interactions started without skipping more steps than actually happened.
So that's what's causing some of the current errors, that I have situations where I let players call 1, call 2, and then a return sends them back to "1," when really the intended action is that they get ejected to before the first call, OR I let them call 1, call 2, and I intend them to get sent back to 1, but they instead get booted past it. A lot of this should get fixed by the next build, I've overhauled how a portion of this works, specifically in the "shift actions" commands, and I'm continuing to try and piece together where these bugs might continue to pose a problem.
Just thought you guys might enjoy some insight as to how these things work under the hood. Let me know if you have any questions on the subject.
Comments
Oni
Thanks, I'm more self-critical than anything, because I know my own limitations in this. I'm just happy to have found something like Renpy, because my previous programming experiences with things like C++ were always so unsatisfying, because I could get it to do math or print a line of text or something like that, but making it actually spit out moving images was months or years of learning down the line, whereas with Renpy you can make a game that actually works within the first few minutes. It might not do much, but it throws pictures around, and you can tweak it from there. ;) As for additional characters, I've been planning ahead on that as best I can, and I don't think it'll be that hard, really, from a technical perspective. Some of what I was doing over the past few months was just rewriting how certain systems work so that they would be more flexible to having multiple characters around. At the first stage, I can just copy/paste all the work I've done on Rogue and rename all the variables to relate to the second character. This would only take a few minutes work and would (once the sprite is set up), be a playable second character, but of course it would be pretty lame since she would still talk and act like Rogue. So then I'd go in and redo as much dialog as necessary, tweak how the stats shift around, add some new scenes, but nothing there really involves coding, just changing what the code affects. Now what will take some new effort is that I intend to add the actual girl/girl interactions, both friendly and more-than-friendly, as well as threesome elements, so those are whole new scenes that will have to juggle having multiple characters moving around the screen without too much weirdness. Now, once I have that work done, the next character would get even easier, since again I can just copy/paste/tweak, and then I would already have the threesome tools in place (a foursome would get a bit complicated), so when the time comes, I plan to also work on some new general purpose interactions and that sort of thing, to broaden the options available. Now it will still take a lot of work in making the art, writing the new story elements, but most of the heavy lifting on coding is out of the way at this point (unless I decide to completely rebuild some other systems). ;)
Wasn't criticism of your work, the fact it all works under the constraints is extremely impressive. It's very easy to underestimate how much work has actually gone into its current state, and a lot of it is very elegant. At the end of the day what works for the author is the correct tool. Adding another character may take rather a lot of effort. So best of luck ;)
Oni
Yeah, I actually caught the bugs you're describing earlier and fixed them more or less how you described (the "Length" variable was already "len(Options)-1"). Thanks for the ideas though, it's nice to have options. And yeah, my coding is not particularly great, I don't have a ton of experience with it and certain methods of coding just make my head spin, but the way I'm using Renpy and Python make sense to me and I can typically find a way that works for accomplishing my intended task. ;)
Renpy is great for somethings, and absolutely terrible for others. A lot of people have built things with it I considered way beyond what it was intended for (including this endeavor), but some of the coding it causes / promotes is frighteningly bad. Python itself of course is plenty powerful. The problem you're mentioning showing the two models aren't all that compatible, but in most cases you can fix a call stack issue by reversing the calls and settings state (in your example call 2, which then calls 1 if required). I think the two larger bugs in the latest build have some easy fixes. The auto returning bug on sleep over is caused by the "if" being >3 and <3 which means if falls through (entirely to the next label) when the count gets to 3. (alter one check to >= 3). The other is probably a typo of Count2 to Count3, but what you're doing in the code isn't required. Since random 1 to Length, will always miss the first and require a clamp (where the error is), since python arrays are zero based. Just do Random(0,length -1) and both will work fine.
