Ren'Py Abandoned Princess Tower [v0.12.public.3] [Euphemismus]

Euphemismus · Sep 30, 2020

Actually, a lot of my argument against Python stems from personal preferences, rather than objective performance stats or the like. I dislike dynamic typing, I dislike the fact that I'm using dicts with raw strings instead of enums, I dislike how revealing the effects of many bugs is pushed from compile time into runtime, I dislike how I can never really be sure how something works once I've written it (and I dislike the multitude of "self."-s as much as I dislike Java-without-Lombok's endless boilerplate code). So yeah, while one can argue that Python has objective problems when it comes to game design, my own issues mostly come down to preference.

On the other hand, I'm genuinely having tremendous fun developing the game and a lot of these issues are mitigated by renpy's absurdly helpful hotswapping feature.

Oh and Python has functions as first-class citizens, which is probably my favourite language feature ever.

(And thanks for the feedback/compliments, I'm glad to hear that the writing is something that sticks out for at least some players!)

aaaaaaaaa · Sep 30, 2020

text is fine

waffel · Sep 30, 2020

Euphemismus said:
Actually, a lot of my argument against Python stems from personal preferences, rather than objective performance stats or the like. I dislike dynamic typing, I dislike the fact that I'm using dicts with raw strings instead of enums, I dislike how revealing the effects of many bugs is pushed from compile time into runtime, I dislike how I can never really be sure how something works once I've written it (and I dislike the multitude of "self."-s as much as I dislike Java-without-Lombok's endless boilerplate code). So yeah, while one can argue that Python has objective problems when it comes to game design, my own issues mostly come down to preference.

On the other hand, I'm genuinely having tremendous fun developing the game and a lot of these issues are mitigated by renpy's absurdly helpful hotswapping feature.

Oh and Python has functions as first-class citizens, which is probably my favourite language feature ever.

(And thanks for the feedback/compliments, I'm glad to hear that the writing is something that sticks out for at least some players!)

The absence of a pre-compiler and a good testing environment for test-driven development is not a personal preference problem, it's an actual problem

Pre-compilers are a fantastic invention!

Imagine being able to fully test the integrity of every function, and none of that bloat will reach the actual program getting shipped!

Deleted member 1808184 · Oct 1, 2020

You actually can compile python scripts into .pyc file, and ship the pyc files with Ren'Py.

Not only that, but Ren'Py will compile itself in .rpyc files as well.

...Don't expect too much from the python compilers, though. There's a reason why only libraries are compiled by default. (And imho it is always a bad idea to compile things for your users)

There is also Ren'Py Lint program, which will seek for errors and common mistakes and some other stuff, but it was designed for testing a visual novel, so it might not be so useful in handling pure Python.

Ren'Py SDK interface should also allow you to browse functions and TODOs and labels; Again, it is nothing exceptional, but always good to know what you can and cannot do.

Keep in mind that you can use Shift+O to open the Ren'Py console, and inject Python code while the game is running. I used this a lot in the past to find the perfect values for things like speed adjustment etc. - Barring that, Ren'Py also has a hot-reload feature. (Shift+R)

Each language has their own advantages and their own drawbacks. While compiled code is much more efficient, it is also much less portable, because every computer - welp, even every operating system is different from each other in ways which are not always easily compatible.

agregen · Oct 1, 2020

waffel said:
What I mean is games are ought to be programmed procedurally in a data oriented programming manner, so you are able to optimize for the CPU cache flow when you need to do so. Python is locked very tightly to OOP which greatly reduces the amount performance you are able to squish out of it, because it's polluting not only the data cache, but also the instruction cache. A game like Lab Rats 2 is a shining example of this, there's nothing in that game that couldn't be handled by one CPU core with a maximum frame latency of 20ms, but he's throwing cores at the problem and we still see frame latencies well above 300ms, often several seconds which are equivalent to eons in CPU time. The reason is that he is not allowed to program in a way that minimizes cache misses, and that is very important in game programming. It's irrelevant for VNs, but very important for real actual games. C# has the option to program this way, but just makes it very tedious for you to do so, python not so much. Dynamic languages doesn't make it easier to program games, they just make it a lot harder to squish out the performance you need when you need it.

…You are aware that you're not supposed to use low-level intensive computation in a high-level code, right? In case of games, the low-level computation is to be left to the engine (implemented in C or something similarly “close to hardware”), while the game scripting is normally left to high-level languages where maximum performance isn't a requirement. If your script is a performance hit for the game, it's very likely a sign you're doing something wrong.
Same for non-game software, BTW: if you need low-level performance optimizations, those parts are implemented in a low-level language and used as a dynamic library (DLL/SO file) in the main program via FFI and/or DSL in a way that retains the performance advantage (example: batch computation via NumPy).

waffel · Oct 1, 2020

agregen said:
…You are aware that you're not supposed to use low-level intensive computation in a high-level code, right? In case of games, the low-level computation is to be left to the engine (implemented in C or something similarly “close to hardware”), while the game scripting is normally left to high-level languages where maximum performance isn't a requirement. If your script is a performance hit for the game, it's very likely a sign you're doing something wrong.
Same for non-game software, BTW: if you need low-level performance optimizations, those parts are implemented in a low-level language and used as a dynamic library (DLL/SO file) in the main program via FFI and/or DSL in a way that retains the performance advantage (example: batch computation via NumPy).

We are not necessarily talking about low-level optimizations, optimization and cache friendliness are two different terms. It is the ability to program in cache friendly manner that you lose in python. You are still able to do so in both C# and Java even though they make it harder and more tedious for you to do. Cache friendliness is often more than enough, before we talk about low-level optimizations, because of how OP our CPU's are. The problem is that it doesn't matter how OP the CPU is if it is de-facto idle 40-70% of all its cycles, because it is waiting for data or instructions to process, and that is what I'm talking about, and that is a problem that specifically python possesses. That happens because it is very tightly knit together with OOP and have no way of defining traditional not linked list based arrays. So you are essentially putting the pre-fetcher out of action, and the advances done on the pre-fetcher ranks high on the reasons why modern CPU's are so unfathomably fast!

Remember we are talking games, not VNs.

Another problem I think we share is that we are located in different paradigms, and therefore our discussion here is rather incommensurable

Especially since you say, why not write a library for the crunchy stuff, and all I can think of is, if you can do that, then why bother with all the drawbacks of python in game development in the first place

RetrospectiveInsomnia · Oct 3, 2020

Man, this somehow turned into a programming thread lol.
But I'm not complaining, just more of my favorite things in one place. Ragging on python and chastity.
I have to say I love this game so far. Chastity has been a niche fetish of mine and there just isn't enough of it out there. You managed to get it just right. Never have I downloaded a game so fast.
Loving the art as well. Keep up the good work.

Euphemismus · Oct 3, 2020

Yeeeeah, this turned into just about the kind of programming discussion I was expecting. I've long since given up on trying to compare languages or systems on an objective basis because such comparisons require an infinitely knowledgeable programmer, which I'm not. So I just keep my own preferences and work with those.

asdffdsa1 said:
Man, this somehow turned into a programming thread lol.
But I'm not complaining, just more of my favorite things in one place. Ragging on python and chastity.
I have to say I love this game so far. Chastity has been a niche fetish of mine and there just isn't enough of it out there. You managed to get it just right. Never have I downloaded a game so fast.
Loving the art as well. Keep up the good work.

Thanks!

Y'know, ironically, when I was writing some of the first drafts a long time ago, I wanted to get at least some nsfw-level content on screen as fast as possible and... I threw the whole chastity thing in there just so there would be a reason to see Ari's panties right at the start and I ended up running with it.

Can't say I dislike the way it all turned out, though. There's probably going to be an option to have a chastity theme/route going all the way to the end of the game.

waffel · Oct 4, 2020

One thing though, mr. Euphemismus I must say is, that as I have spendt more time enjoying your artistic expression, I have noticed that our little princess has such nice eyes, they are utterly adorable! Makes me smile everytime I look her way

Euphemismus · Oct 4, 2020

EDIT: You know, much later I realize I should have mentioned that this is not a delay, I'm just skipping a release, as if I were going from v.0.3 to v.0.5.

Bad news -