VN Ren'Py Abandoned The Sexy Cosplay Cafe [v0.30] [Novus]

[NovusPeregrine]

Overview:
It’s the summer before you start college, and you’re moving to the city a few months early in order to get away from your family. You love them, but most of them are a bit too…normal, for you. Thankfully, you know someone in the city and she’s promised she’s got a job lined up fro you. With a job, scholarship, and the promise of being able to crash at her place, you can't wait to get there... Plus, knowing Alice, whatever job she has for you won’t be boring...

Spoiler: More

You don't have permission to view the spoiler content. Log in or register now.

Thread Updated: 2019-09-20
Release Date: 2019-09-20
Developer: Novus -

You must be registered to see the links

Censored: No
Version: 0.30
OS: Win, Mac, Linux
Language: English
Genre:

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

Installation:

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

Changelog:

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

DOWNLOAD
PC:

You must be registered to see the links

-

You must be registered to see the links

-

You must be registered to see the links

-

You must be registered to see the links

Mac:

You must be registered to see the links

-

You must be registered to see the links

-

You must be registered to see the links

-

You must be registered to see the links

​

 

[User_23654]

Edited and moved.

 

[Genji]

wow

 

[goatwhisperer3]

Well, there is a cafe and there is some kind of cosplay... 2 out of 3 is decent rate for a 0.1 ( ' -')

 

[popober]

From the first look alone, I'd say the art isn't bad although floating models are almost always immersion breaking. Those eyes, though... they are kinda... "soulless" is one word for it, I guess? The sixth picture makes it seem like she's reliving some 'nam flashbacks as she's about to take a dump.

Other than that, I quite like the character designs because they're thicc in all the right places. Although the shading/coloring(?), combined with the faces, make the art seem more amateurish than it should. Currently, it's like it's trying to strike a balance between western and animesque styles but unsure of where on the spectrum it should fall on.

I haven't delved too much into it so far, but the tutorial seems to confirm what you'd expect from reading the overview; the gameplay is a trainer/management sim with you having to manage the girls in order to manage the cafe as a whole. It seems that'll only last for about the game's "first half" according to current plans, however.

The demo also has unexpectedly proper diction; I'm so used to games with hand-drawn art have some kind of thick engrish in it if it isn't outright incomprehensible.

Overall, I'd say the game has potential; improving the artwork for the models(mostly face-wise) would fix one of it's biggest flaws right now. Trainers also seems to usually come with brain stem liquefying grammar, so one where I actually enjoy the dialogue is welcome. Adding this to my watch list.

 

[Frylock]

I like the blend s vibe I get but cant fap to this art tho.

 

[deathmog91]

this is a good start for the game but the art need to be improved

 

[UnDeaD_CyBorG]

And just now I did a manual search after some tags, and this comes up fresh from out of nowhere.
I guess I'll actually have to look at this right now.
Edit: After a cursory glance, it looks like this game is definitely done the right way.
The developer seems to have a plan, and there's systems in place without noteworthy content yet that will probably be filled later without incompatibilities or the need of too many new, as of yet uninitialized variables.
The Turorial changed names once, that was mildly entertaining.
This certainly looks promising. Time will tell if it actually is.

Edit2: Regarding the tutorial, why not do the time tutorial in the protagonists room when he actually gets there? Which is 15 seconds after the tutorial, atm.
3: I got the "no one is currently working" when alice was in the cafe. Said one should report that.
I do think the time system a bit off, btw. Spending an entire timeslot going to the park or mall means it will be really inefficient once there is more content. At the very least, time shouldn't pass if you go from where you are to where you are.
I'd reccomend either an extra slot per day, or one free move per timeslot between "adjacent" locations.
4: Opening the relationship screen should probably block out the rest of the UI to prevent visual glitches. Also, in the Cafe, when it says you're alone, you can click until the grey bar disappears, upon which the description replays.
Edit5:

Spoiler: Exception

You don't have permission to view the spoiler content. Log in or register now.

 

[Gabaw]

Should really be called "The Cosplay Cafe". Sexy might come in a future build but it isn't here that's for sure...

 

[Lao-Shan Lung]

The art is a Turn off for me. Please improve the art.

 

[NovusPeregrine]

A Note From the Developer (Namely Me) regarding the art:

The game's art is a little inconsistent in quality. Patrons already know this, but non-patrons might not...I taught myself to draw from scratch, purely for this game. Which is why it's been in development for so long (8-months from square one, though several of those were for the learning-to-draw step).

As I'm still rapidly getting better, the art I made earlier on is lower quality than the stuff I made later. Eventually, once I reach a level I'm completely happy with, I'll replace the worst of the bad art. Also note that many of the backgrounds are currently stock placeholders, but ALL pieces of character art, as well as ALL the art for the Café itself, are completely my own original creations.

I don't mind people saying that the art sucks (though I think some of it is at least fairly decent), but understand that I'm pretty much going to ignore you, since it's an issue I can't just snap my fingers and fix. It will be better in time, as I myself get better(or I get enough support to commission the art), but that's literally all I can say or do.

-------

Now for some specific replies:

From the first look alone, I'd say the art isn't bad although floating models are almost always immersion breaking. Those eyes, though... they are kinda... "soulless" is one word for it, I guess? The sixth picture makes it seem like she's reliving some 'nam flashbacks as she's about to take a dump.

Other than that, I quite like the character designs because they're thicc in all the right places. Although the shading/coloring(?), combined with the faces, make the art seem more amateurish than it should. Currently, it's like it's trying to strike a balance between western and animesque styles but unsure of where on the spectrum it should fall on.

I haven't delved too much into it so far, but the tutorial seems to confirm what you'd expect from reading the overview; the gameplay is a trainer/management sim with you having to manage the girls in order to manage the cafe as a whole. It seems that'll only last for about the game's "first half" according to current plans, however.

The demo also has unexpectedly proper diction; I'm so used to games with hand-drawn art have some kind of thick engrish in it if it isn't outright incomprehensible.

Since you has specific things to say about the art, I'll actually address them, despite the first bit of this post . There isn't much I can do about the floating model thing, unless I want to make each piece of art usable only once, at a specific location. It's why you see it so often in VNs, even professional VNs. The note about the eyes is...maybe useful? To be honest, I have problems with eyes that I just haven't figured out how to fix yet. I'll keep trying to make them better. The shading/coloring...well that's fair. I am an amateur . 7 months ago I was barely a step above stick figures. I'm glad you like the designs overall, though, and the quality should improve as I do.

As for the diction, I'm actually an freelance writer as my 'real job,' so it should always be decent (hopefully :noexpression. Though it almost certainly needs another editing pass at this point. Thanks for noticing .

Edit: After a cursory glance, it looks like this game is definitely done the right way.
The developer seems to have a plan, and there's systems in place without noteworthy content yet that will probably be filled later without incompatibilities or the need of too many new, as of yet uninitialized variables.
The Turorial changed names once, that was mildly entertaining.
This certainly looks promising. Time will tell if it actually is.

You're 100% right about the systems. I put a lot of the backbone systems into the game from the base build, specifically to prevent having to tack them on awkwardly later on and making a mess of the code as a result. Right now that means the world feels fairly empty, but within a few updates that shouldn't be the case. And...ooops about the tutorial name thing! It was one of the very last things I did, so I'm not surprised I screwed up something. I'm planning a bugfix build in a couple of days, once people have gotten a chance to play it...and break it.

3: I got the "no one is currently working" when alice was in the cafe. Said one should report that.
I do think the time system a bit off, btw. Spending an entire timeslot going to the park or mall means it will be really inefficient once there is more content. At the very least, time shouldn't pass if you go from where you are to where you are.
I'd reccomend either an extra slot per day, or one free move per timeslot between "adjacent" locations.
4: Opening the relationship screen should probably block out the rest of the UI to prevent visual glitches. Also, in the Cafe, when it says you're alone, you can click until the grey bar disappears, upon which the description replays.
Edit5:

Doh! Thanks for reporting the error with Alice. I found the issue in about 10 seconds and fixed it in my copy. It'll be in in the bugfix build I release in a few days. You're not actually missing any art, since Alice doesn't have a peeping scene for the changing room, it's just a text line saying she must change in her office.... As a result, I'll hold out on fixing it until the bugfix build .

As for the time issue. *sigh* Yeah, I kinda found it annoying when I ran through a playtest. Unfortunately, I built the entire code structure of the game around the way time advances during travel. I think I've figured out a way to fix that (originally, when I made the time system, I didn't track where the player actually was. As I hadn't figured out how to do that yet. I fixed that later, so I think I can redo it...I think), but it's going to be a fairly major code change. So it likely won't be in the bugfix, but rather in the first full update.

The other error you found.... O.O. I have no idea why the heck it's triggering that line. The actual exception was for a miss-named variable (MiraWorkChat4_1 is supposed to be MiraWorkChat5_1), so that will get repaired in the bug-fix build. As for the repeated clicking calling it up in the first place...no idea. Going to have to actually dig for a while to find that one, I think. Thanks for reporting it!

 

[UnDeaD_CyBorG]

I believe the repeated cafe description is because you can keep clicking - at some point, the dialogue is done, and you're just in the cafe. So having no other status makes the system assume you just arrived.

 

[NovusPeregrine]

I believe the repeated cafe description is because you can keep clicking - at some point, the dialogue is done, and you're just in the cafe. So having no other status makes the system assume you just arrived.

Well, yes, that's how it's supposed to work. ALL of the locations are loops that will continue to reset to base values when you end dialog. They have to be, since it's the only way to realistically get location-specific game loops in Renpy (which is very much NOT made for object-oriented programming, much to my personal frustration). I think I misread your edits, linking 4 to 5. I thought you were somehow getting the error from edit 5 by repeatedly clicking in 4.

The description is actually supposed to loop, since eventually there will be more options for things to do after-dark and it's mostly there to alert you to the fact that the cafe is now closed... I suppose I could try to make the description go away after a single iteration on each after-dark visit, but with the way the location-looping works it would be extremely cumbersome. I'd basically have to add a variable reset to the AdvanceTime python function, so that the description only occurs once per visit. But I hate adding global variable resets to a function that gets called everywhere, all the time. Technically, renpy is so lightweight that doing so wouldn't really effect the speed of the game at all, but it's still terrible coding practice -_-.

 

[UnDeaD_CyBorG]

I would actually prefer to just not be able to "click away" the description, or at the very least the empty grey that appears after I do. It feels kinda sloppy that I can click it away, then click again, and it restarts everything there, even though there is no gameplay difference.

 

[Ozzice13]

Those drawings look like the type of stuff I would do when I was 11
I know that not everyone is an artist, and I appreciate the that the dev is learning to do drawings, but bottom line for me: If your art is not good enough, (and you know so yourself) don't use it in a game.

There are alternative ways of doing this, alternative forms of art you can use, collaborate with other people who can do the art you want. Or simply work on your skills until they're high enough to actually use in a game before actually making the game.
The way it sits now it's going to put a lot of people off from playing the game and in the end you'll just end up with a product you can't really be proud of.

 

[anne O'nymous]

Please, please, please @NovusPeregrine , take some times to learn the basis of Ren'py The SDK come with a full documentation, also

You must be registered to see the links

. There's many really useful things to learn inside.

You absolutely don't need so many screens. Most of them can be a single screen, and if really you need it you can still use

You must be registered to see the links

(scroll down a little), external variables, or

You must be registered to see the links

to

You must be registered to see the links

. You don't need near to ten screens just to display the record of a girl, one if enough ; in fact you can even replace all the girls status screens by a single screen. But at least having only one by girl will already be an improvement of your own life ; especially if you

You must be registered to see the links

them with the same name since it will make useless tons of your "hide screen".
Your 76 screens can easily become less than 10. Not only it will ease your works, but it will also limit the risk of bugs.

Also, learn the benefits of

You must be registered to see the links

and their

You must be registered to see the links

value. It will remove all the crashes due to endless loop because you are waiting for the player to click somewhere. Sorry, but we have a life. It's not because we are playing your game that we will not stop, whatever it's to play with our pet, answer the phone, go grab something to eat/drink, or something else. "Exception: Possible infinite loop" is not what we want to see when we go back to the game.
Learning about the other

You must be registered to see the links

can also be a big help.

Talking about called screen, you can also

You must be registered to see the links

. Basically, the hundreds of "hide screen" you've wrote could have been a single iteration of them, put inside a label that you call each time you need to clean the screen. But well, like I said above you really don't even need to have more than 1500 "hide screen" like it's actually the case. 99% of them will just disappear once you'll have learned how to define a screen ; this even if you're still bad at defining them.

In the end, just with these few things, the 9565 lines of code that define your actual release can easily be reduced to 2000 lines and probably even less. Obviously, it will also reduce the number of lines you'll have to wrote for each update, and so considerably ease your work.

 

[NovusPeregrine]

Please, please, please @NovusPeregrine , take some times to learn the basis of Ren'py The SDK come with a full documentation, also

You must be registered to see the links

. There's many really useful things to learn inside.

You absolutely don't need so many screens. Most of them can be a single screen, and if really you need it you can still use

You must be registered to see the links

(scroll down a little), external variables, or

You must be registered to see the links

to

You must be registered to see the links

. You don't need near to ten screens just to display the record of a girl, one if enough ; in fact you can even replace all the girls status screens by a single screen. But at least having only one by girl will already be an improvement of your own life ; especially if you

You must be registered to see the links

them with the same name since it will make useless tons of your "hide screen".
Your 76 screens can easily become less than 10. Not only it will ease your works, but it will also limit the risk of bugs.

Also, learn the benefits of

You must be registered to see the links

and their

You must be registered to see the links

value. It will remove all the crashes due to endless loop because you are waiting for the player to click somewhere. Sorry, but we have a life. It's not because we are playing your game that we will not stop, whatever it's to play with our pet, answer the phone, go grab something to eat/drink, or something else. "Exception: Possible infinite loop" is not what we want to see when we go back to the game.
Learning about the other

You must be registered to see the links

can also be a big help.

Talking about called screen, you can also

You must be registered to see the links

. Basically, the hundreds of "hide screen" you've wrote could have been a single iteration of them, put inside a label that you call each time you need to clean the screen. But well, like I said above you really don't even need to have more than 1500 "hide screen" like it's actually the case. 99% of them will just disappear once you'll have learned how to define a screen ; this even if you're still bad at defining them.

In the end, just with these few things, the 9565 lines of code that define your actual release can easily be reduced to 2000 lines and probably even less. Obviously, it will also reduce the number of lines you'll have to wrote for each update, and so considerably ease your work.

Wow, not only are you incredibly insulting, you also only vaugely know what you're talking about. How nice.

1) Most of the renpy documentation is out of date or incomplete. What isn't either of those is needless obtuse to the point of uselessness.
2) You are, I assume, referring to using imagemaps instead of screens. I intentionally did not use them, as they are known to be less efficient (not to mention being less practical) that simply using screens, which despite looking awkward in code format, are actually substantially less processor intensive.
3) There hasn't been a single report of a crash do to endless loop yet, nor did I run into any when I did an exhaustive multi-day playtest (including deliberately leaving the game open overnight). Since I specifically created my loops to have a pause to await input(often even an extra catch just in case I missed something)...it should be physically impossible for an endless loop to occur. Unless I missed it somewhere, in which case I will fix it when someone reports it as a bug.
4) There are a host of very good reasons I didn't use internal variables. While using global declarations is, in fact, sloppy (I actually have a Bachelor's in Software Design, so yes, I'm aware of many of the less-than-perfect solutions I use), with Renpy's screwy lack of proper object orientation, it's the simplest way to brute force a robust system, cutting out the single most common source of your typical bugs by not passing the variable around like a hot potato.
5) Again, I actually have a degree in Software Design. Indeed, it's specifically in GAME Software Design. I'm completely and utterly aware of the numerous places in which I could have used a more-complex, more-error and bug prone, option to streamline the code. Unfortunately, I'm also aware that doing so A) Complicates adding ad-hoc additional code (in other words, it's a terrible idea unless you have the entire game's plan completely mapped before you start, which I don't) and B) The best way to avoid bugs and simplify your life is to keep it simple stupid. Yes, I did, in fact, consider making a series of called labels that would hide/unhide the UI elements. In point of fact, I nearly did that several times. However, doing so would have actually have slowed the overall execution down by including a bunch of hide commands where they aren't strictly needed. Given how light-weight renpy is, it probably would have been fine, but given that it would have also reduced the ease of manipulating a scene when I inject new events, I ultimately decided against it.
6) You are incredibly insulting and holier-than-thou. Assuming, rather than bothering to ask, that I don't have valid, researched and considered (Even, in point of fact, talked over with other Renpy experts and developers), reasons for making my code the way I did, even if it's not how you would have done it. Quite frankly. Go fuck yourself.

 

[NovusPeregrine]

Those drawings look like the type of stuff I would do when I was 11
I know that not everyone is an artist, and I appreciate the that the dev is learning to do drawings, but bottom line for me: If your art is not good enough, (and you know so yourself) don't use it in a game.

There are alternative ways of doing this, alternative forms of art you can use, collaborate with other people who can do the art you want. Or simply work on your skills until they're high enough to actually use in a game before actually making the game.
The way it sits now it's going to put a lot of people off from playing the game and in the end you'll just end up with a product you can't really be proud of.

....
...
..
.
Have you actually seen the art being used in a lot of games that have quite a bit of support? I have and I can tell you that the stuff I'm using is well over the quality in a lot of them. It's also still better than using 3d models, in my opinion (I used Daz3d for my other project). Perhaps you don't personally care for it, but I actually did run it past a fair few people before I started using it in the game. I also only resorted to doing it this way because the other options were worse. I don't have the money/backing to commission the artwork, I do not know any artists that would be willing to work an an adult project, I refused to work with artists I don't know after having been burned to many times by assholes that never follow through on promises, and I refuse to simply lift art-assets from other games (Not only is it illegal, it also doesn't allow you to customize your game very well).

I appreciate your attempt to be polite. Thank you for that. However, I already considered all other possible options before choosing to go the way I did. I know that it will probably put some people off. But I can't please everyone. Indeed, when I went with 3d art via Daz3d, the single most common complaint was that 'I was using the same models as every other game'. Some people will not like a game regardless of what you do or how well it is made. That's fine and they can simply choose not to play. I am spending god-awful amounts of my own time (and money in some cases), to make games as a hobby. People can enjoy them, or not, though I admit the extreme negativity that I've gotten on this one makes me inclined to simply pack up and go home.

*Edit* That came off more confrontational than I intended (I was still pissed about the the other post I responded to. I really do appreciate the politeness. To clarify a bit more, there is a good reason I pushed the game out as quickly as I could, rather than taking an extra couple of months to clean up the art a bit more. Namely, that I promised the patrons that I do have (who mostly came to my patreon to support my other game, Eros Academy), that I would produce results within a certain time span. It was/is an entirely self-created promise, but I do my best to always deliver on what I promise to them. Many of them were amazing people who stayed with despite the new game limiting the time I could spend on Eros Academy updates, and as such I wanted them to have something they could actually play as soon as reasonably possible. They have also seen the art at every step of the process, and have generally been happy with what I was making, art-wise. Some even saying outright that they liked it despite the limited quality. Those patrons are and always will be the opinions I primarily care about (Rather than everyone else who is getting the game entirely without any form of helpfulness to me. In fact, so far, mostly just insults. Many times from people I doubt actually even PLAYED the game, since they only reference the sample images). And those Patrons, so far, haven't had anything negative to say about it at all.

 

[anne O'nymous]

1) Most of the renpy documentation is out of date or incomplete.

So you haven't even took a look at the "doc" folder that stand in the same directory than the SDK launcher, right ? Because, unlike the cookbook, Thomas update it for each release and it's relatively obvious.

2) You are, I assume, referring to using imagemaps instead of screens.

No, I'm talking about what I said, reducing the number of screens by not uselessly splitting them... By example having a single screen handling all the girls status.
[wrote on the fly, you can write way more efficient screen that this one]

screen relation( starting="mira" ):

    default page = starting

    frame:
        if page == "mira":
            add MiraRelPanel
        elif page == "alice":
            [...]

        hbox:
            textbutton "mira":
                action SetScreenVariable( "default", "mira" )
            null width 10
            textbutton "alice":
                action SetScreenVariable( "default", "alice" )
            [...]
            textbutton "close":
                action Return()

        vbox:
            xpos 0.351 ypos 0.22

            if default == "mira":
                text "Relationship Score: [MiraRelScore]"
                text "Chaos Level: [MiraChaosLevel]"
                null height 5
                text "-------------------"
                null height 5
                text "Known Issues:"
                if mira["knownIssue1"] is True:
                    text "Oral Fixation - Gum and Suckers"
                else:
                    text "???"
                if mira["knownIssue2"] is True:
                    text "Out of Character Issue"
                else:
                    text "???"
                null height 5
                text "-------------------"
                null height 5
                text "Known Fetishes/Kinks:"
                if mira["knownFetish1"] is True:
                    text "Oral Fixation - Blowjobs"
                else:
                    text "???"
                if mira["knownFetish2"] is True:
                    text "Oral Fixation - Blowjobs"
                else:
                    text "BDSM - Bondage & Spanking"

            elif default == "alice":
                [...]

This in place of the screens MiraRelationReport, MiraProblemText, MiraProblem1, MP1UnknownDisplay, MP2UnknownDisplay, MF1UnknownDisplay,
MF2UnknownDisplay, MiraProblem2, MiraFetishText, MiraFetish1 and MiraFetish2, and obviously the derived screens for the other girls.
Like I said, a single screen do exactly the same thing than your almost 40 screens. It do it better and divide by more than ten the code you have to write when you want to show the relation screen.

[...] it should be physically impossible for an endless loop to occur.

Still I had it...

Full traceback:
File "[...]\Sexy Cosplay Cafe (the) - 0.1\renpy\bootstrap.py", line 306, in bootstrap
renpy.main.main()
File "[...]\Sexy Cosplay Cafe (the) - 0.1\renpy\main.py", line 513, in main
run(restart)
File "[...]\Sexy Cosplay Cafe (the) - 0.1\renpy\main.py", line 139, in run
renpy.execution.run_context(True)
File [...]\Sexy Cosplay Cafe (the) - 0.1\renpy\execution.py", line 879, in run_context
context.run()
File "game/script.rpy", line 2917, in script
label LocMCBedroom:
File "[...]\Sexy Cosplay Cafe (the) - 0.1\renpy\execution.py", line 58, in check_infinite_loop
raise Exception("Possible infinite loop.")
Exception: Possible infinite loop.

with Renpy's screwy lack of proper object orientation,

Excuse me ? Are you really seriously trying to say that Ren'py, an engine entirely wrote in Python, lack of object orientation ?
Like for Python itself, where absolutely everything is an object, everything in Ren'py is an object. You write "label start", you create a renpy.ast.Label object. You write "define MiraRelScore = 0", you create a renpy.ast.Define object that will create an attribute inside the renpy.store object handling all the variables in the Ren'py global scope.
Yes, Ren'py language don't have a single statement regarding objects... because it don't need them. You can massively use Python code directly inside your Ren'py code. Ren'py API have a function to add any statement you want, writing their code in Python, and it can import any Python module you want...
In short, what you said is the total opposite of the truth.

6) You are incredibly insulting and holier-than-thou.

Said the guy who used his diploma as proof that he can't be wrong...

Assuming, rather than bothering to ask, that I don't have valid, researched and considered [...]

I don't assumed, I knew it, and now that I've read what you had to answer, I even affirm it ; almost all what you said is just false.

(Even, in point of fact, talked over with other Renpy experts and developers)

And none of these "Ren'py expert" told you that define is not to use since it don't make the variable savable, and that you should have used default instead ? Nor told you about the tag screen property, telling you how it could ease your works because you'll never ever have to hide a screen ?

tag
Parsed as a name, not an expression. This specifies a tag associated with this screen. Showing a screen replaces other screens with the same tag. This can be used to ensure that only one screen of a menu is shown at a time, in the same context.

Now the choice is up to you. I tried to help you because I think that the idea behind your game worth it. But well, apparently you never learned to question your own thoughts, and so didn't even took the time to follow one of the link I provided, to discover that there's a whole world you don't know yet.
So, unless you question yourself and accept to learn from people who know better than you (because we are many here), it seem that soon or later it will be yet another abandoned game. Because no one can past a full year copy/pasting tons of junk code without ending bored as fuck. I know it, I past two years being a code monkey after the birth of my first child.

 

[NovusPeregrine]

So you haven't even took a look at the "doc" folder that stand in the same directory than the SDK launcher, right ? Because, unlike the cookbook, Thomas update it for each release and it's relatively obvious.




No, I'm talking about what I said, reducing the number of screens by not uselessly splitting them... By example having a single screen handling all the girls status.
[wrote on the fly, you can write way more efficient screen that this one]

screen relation( starting="mira" ):

    default page = starting

    frame:
        if page == "mira":
            add MiraRelPanel
        elif page == "alice":
            [...]

        hbox:
            textbutton "mira":
                action SetScreenVariable( "default", "mira" )
            null width 10
            textbutton "alice":
                action SetScreenVariable( "default", "alice" )
            [...]
            textbutton "close":
                action Return()

        vbox:
            xpos 0.351 ypos 0.22

            if default == "mira":
                text "Relationship Score: [MiraRelScore]"
                text "Chaos Level: [MiraChaosLevel]"
                null height 5
                text "-------------------"
                null height 5
                text "Known Issues:"
                if mira["knownIssue1"] is True:
                    text "Oral Fixation - Gum and Suckers"
                else:
                    text "???"
                if mira["knownIssue2"] is True:
                    text "Out of Character Issue"
                else:
                    text "???"
                null height 5
                text "-------------------"
                null height 5
                text "Known Fetishes/Kinks:"
                if mira["knownFetish1"] is True:
                    text "Oral Fixation - Blowjobs"
                else:
                    text "???"
                if mira["knownFetish2"] is True:
                    text "Oral Fixation - Blowjobs"
                else:
                    text "BDSM - Bondage & Spanking"

            elif default == "alice":
                [...]

This in place of the screens MiraRelationReport, MiraProblemText, MiraProblem1, MP1UnknownDisplay, MP2UnknownDisplay, MF1UnknownDisplay,
MF2UnknownDisplay, MiraProblem2, MiraFetishText, MiraFetish1 and MiraFetish2, and obviously the derived screens for the other girls.
Like I said, a single screen do exactly the same thing than your almost 40 screens. It do it better and divide by more than ten the code you have to write when you want to show the relation screen.




Still I had it...





Excuse me ? Are you really seriously trying to say that Ren'py, an engine entirely wrote in Python, lack of object orientation ?
Like for Python itself, where absolutely everything is an object, everything in Ren'py is an object. You write "label start", you create a renpy.ast.Label object. You write "define MiraRelScore = 0", you create a renpy.ast.Define object that will create an attribute inside the renpy.store object handling all the variables in the Ren'py global scope.
Yes, Ren'py language don't have a single statement regarding objects... because it don't need them. You can massively use Python code directly inside your Ren'py code. Ren'py API have a function to add any statement you want, writing their code in Python, and it can import any Python module you want...
In short, what you said is the total opposite of the truth.




Said the guy who used his diploma as proof that he can't be wrong...




I don't assumed, I knew it, and now that I've read what you had to answer, I even affirm it ; almost all what you said is just false.




And none of these "Ren'py expert" told you that define is not to use since it don't make the variable savable, and that you should have used default instead ? Nor told you about the tag screen property, telling you how it could ease your works because you'll never ever have to hide a screen ?


Now the choice is up to you. I tried to help you because I think that the idea behind your game worth it. But well, apparently you never learned to question your own thoughts, and so didn't even took the time to follow one of the link I provided, to discover that there's a whole world you don't know yet.
So, unless you question yourself and accept to learn from people who know better than you (because we are many here), it seem that soon or later it will be yet another abandoned game. Because no one can past a full year copy/pasting tons of junk code without ending bored as fuck. I know it, I past two years being a code monkey after the birth of my first child.

Yeah. No. There is a whole host of things wrong with what you just said. But I refuse to get into a reply war with you. I'll look into the exception you apparently found, but that's all. The code I have works, in a way that keeps it simple for me to do what I need without complicating things needlessly. I hate coding and I designed this framework from the ground up to be easy for me to add onto as I want, in a way that's dirt simple to understand and nearly impossible to fuck up, rather than for code efficiency. Shoo.