Ren'Py Question regarding Renpy and sprites

[amaranso]

So Im starting to make a project. My first one. I know how to use Daz properly, how to write a script. Everything is ready but I am confused regarding bringing it together in Renpy.

So Basically the VN wouldnt feature any gameplay elements besides making choices. And I envisioned only a story where you go from render to render making choices along the way that will change the story hence the renders shown. Now I just started learning Renpy and there is some talk about charachter sprites. Do I need this if I would like only to make the novel with renders with charachters already baked in them?

 

[79flavors]

Sprites are a way to reduce the amount of rendering you need to do, while at the same time reducing the overall size of the game.

You render a room.
Then you render a picture of a girl smiling.
Then you render a picture of the same girl frowning.
Then you render a picture of the same girl clearly angry.
etc.

All the pictures of the girl have a transparent background.

Anytime the girl speaks as part of your story, you use one of the "sprites" you have prepared of the girl, against the pre-rendered room. As the girl's mood changes, you swap one sprite for another.
Sprites have the minor bonus of being able to move or animate without affecting the background image.

The downside is usually the lighting or time of day, where you have a very brightly lit smiling girl stood in the middle of a forest at midnight. Then there's the complication of clothing (which I guess is why a lot of anime style games never change out of their school uniforms).

With semi-photorealistic characters, sprites doesn't usually work very well. Better with seemingly hand-drawn style characters.

Sprites work well when you want to present characters like this:


Where each girl would be a sprite image and the room would be a separate background image.

But doesn't really work when you want to do this:


Honestly, using sprites is pretty rare theses days. It's much more common to only use full sized fully rendered scenes with each character individually posed and lit. Since you're talking about using Daz, I think you can fairly safely forget about the idea of sprites.

 

[amaranso]

Alright that was the answer I was looking for. Very extensive, I get it. Rendering times arent really an issue for me I was just worried that I wouldnt be able to work with my renders in renpy the way I thought I could. Like I was worried that I have to break it all down, the enviroment, charachters, and such and not just put together renders that are accompanied with text.

Thank you very much.

 

[MidnightArrow]

So Im starting to make a project. My first one. I know how to use Daz properly, how to write a script. Everything is ready but I am confused regarding bringing it together in Renpy.

So Basically the VN wouldnt feature any gameplay elements besides making choices. And I envisioned only a story where you go from render to render making choices along the way that will change the story hence the renders shown. Now I just started learning Renpy and there is some talk about charachter sprites. Do I need this if I would like only to make the novel with renders with charachters already baked in them?

You can do either character sprites over backgrounds or fully event stills, but the Ren'py language is optimized to use character sprites since that's how most visual novels are made. If you go with event stills only, you'll be fighting against the language and have to come up with a wordy, convoluted file naming scheme to display everything. Plus if you go with only event stills, you'll need to render everything inside an environment, but with sprites you can just pose them in the void over transparency and save your effort for only the event stills that matter.

 

[amaranso]

You can do either character sprites over backgrounds or fully event stills, but the Ren'py language is optimized to use character sprites since that's how most visual novels are made. If you go with event stills only, you'll be fighting against the language and have to come up with a wordy, convoluted file naming scheme to display everything. Plus if you go with only event stills, you'll need to render everything inside an environment, but with sprites you can just pose them in the void over transparency and save your effort for only the event stills that matter.

Ok, so I already have a huge chunk of renders as you put it event stills thinking I had to do it this way. I got resources thinking I had to do it that way. Like functional cameras and all the handy things for a novel. So my only issue now would be to organize it conveniantly for renpy?
Thanks for the response.

 

[79flavors]

Organizing your image names is always something personal. Basically, whatever makes sense to you.
Just keep in mind that you might want to visit the bathroom more than once (so bathroom.png is probably a bad idea).

I've seen people organise filenames around the episode and/or scene number (so ep1_s03_0001.png can be an option if that makes sense for your game). But really... whatever works for you.

Two things though:

• Always use lowercase filenames for at least your images (and almost everything else).
• Avoid filenames with spaces in them.

There are technical RenPy reasons as to why, and like everything else with RenPy - you can break almost any rule if you like. But your development will be so much simpler if you stick to at least those two suggestions.

 

[TessaXYZ]

My unsolicited two cents:
Full renders with characters in the environment simply looks better. It's what I'm doing, and while I recognize it means longer renders times, it's the mark of a higher quality, cinematic VN. Not sure what the other person means by "fighting with the language", as there's no obstacle to doing it this way.

 

[MidnightArrow]

My unsolicited two cents:
Full renders with characters in the environment simply looks better. It's what I'm doing, and while I recognize it means longer renders times, it's the mark of a higher quality, cinematic VN. Not sure what the other person means by "fighting with the language", as there's no obstacle to doing it this way.

The Ren'py language is designed to make use of reusable sprites switched in and out with the tagging system. It's not meant for hundreds and hundreds of event stills called in a row. If it was, PyTom would've made it basically a video editor like Adobe Premiere, where you scroll through a little window showing all the images available so you can drag them into your timeline, instead of a purely text-based format where the naming scheme gets unmanageable very quickly. That's the obstacle.

Also (much more importantly) spending time making hundreds of event stills get in the way of making the novel portion of visual novel. Reusing the same sprites frees you up to focus more on dialogue and narration, which is why professional visual novels still use sprites.

 

[MidnightArrow]

Ok, so I already have a huge chunk of renders as you put it event stills thinking I had to do it this way. I got resources thinking I had to do it that way. Like functional cameras and all the handy things for a novel. So my only issue now would be to organize it conveniantly for renpy?
Thanks for the response.

When I do it, I end up having to come up with stuff like "ev communication_issues 12 birds_eye". "EV" for event still, followed by the name of the scene, followed by the frame, followed by the camera name. It's not bad if you limit yourself (I learned my lesson there) but if you have eight camera angles you'll sorely miss having a WYSIWYG editor so you can actually pick and choose what image you're looking for.

 

[TessaXYZ]

The Ren'py language is designed to make use of reusable sprites switched in and out with the tagging system. It's not meant for hundreds and hundreds of event stills called in a row. If it was, PyTom would've made it basically a video editor like Adobe Premiere, where you scroll through a little window showing all the images available so you can drag them into your timeline, instead of a purely text-based format where the naming scheme gets unmanageable very quickly. That's the obstacle.

Also (much more importantly) spending time making hundreds of event stills get in the way of making the novel portion of visual novel. Reusing the same sprites frees you up to focus more on dialogue and narration, which is why professional visual novels still use sprites.

I've done nearly 700 stills and 20,000 words in 3 months, along with a full suite of sound effects, music, puzzles... and my VN is all the better for it. I'm not saying it's not faster to do the usual route, but if OP wants to do individual stills, there are definite benefits stylistically. You say it's not "meant" for it, but it works just fine.

 

[MidnightArrow]

I've done nearly 700 stills and 20,000 words in 3 months, along with a full suite of sound effects, music, puzzles... and my VN is all the better for it. I'm not saying it's not faster to do the usual route, but if OP wants to do individual stills, there are definite benefits stylistically. You say it's not "meant" for it, but it works just fine.

It works okay if you know how to manage complexity (most amateur porn game devs do not) and don't mind typing out lengthy filenames over and over and having to compile the whole project and fast-forward constantly to see your changes. But I know for a fact it's meant to make sprite-based visual novels because all of PyTom's example projects use them. It's how he designed the engine to work. "Cinematic" visual novels can be done (with more effort), but it's not the intended method.

 

[rayminator]

So Im starting to make a project. My first one. I know how to use Daz properly, how to write a script. Everything is ready but I am confused regarding bringing it together in Renpy.

So Basically the VN wouldnt feature any gameplay elements besides making choices. And I envisioned only a story where you go from render to render making choices along the way that will change the story hence the renders shown. Now I just started learning Renpy and there is some talk about charachter sprites. Do I need this if I would like only to make the novel with renders with charachters already baked in them?

I have tried what you have tried to do and failed so if you have gotten it to work let me know but it was time of day
https://f95zone.to/threads/how-to-show-character-in-a-certain-pose-by-using-this-code.112489/

You must be registered to see the links

has what 79flavors has said it might not be possible

 

[MidnightArrow]

I have tried what you have tried to do and failed so if you have gotten it to work let me know but it was time of day
https://f95zone.to/threads/how-to-show-character-in-a-certain-pose-by-using-this-code.112489/

You must be registered to see the links

has what 79flavors has said it might not be possible

If you want to position a character at a certain point at a certain time of time, you just create a transform for the position and then assign it based on the state of the game clock. Changing clothes and coloring the figure for nighttime should be baked into the sprite. Ren'py will automatically swap them in and out using its tagging system when you type the names out.

 

[TessaXYZ]

It works okay if you know how to manage complexity (most amateur porn game devs do not) and don't mind typing out lengthy filenames over and over and having to compile the whole project and fast-forward constantly to see your changes. But I know for a fact it's meant to make sprite-based visual novels because all of PyTom's example projects use them. It's how he designed the engine to work. "Cinematic" visual novels can be done (with more effort), but it's not the intended method.

Not sure why you think the filename structure is a problem. My images are all a form of AABBCCC_D. AA = story, BB = chapter, CCC = still for chapter, D = sequences or branches. Easy to manage, easy to track, easy to implement. E.g. I just finished render 0101602. The next render is 0101603. I plan it out in my script and just following my own blueprint as I go.

And also not sure what you mean by having to compile and fast forward to see changes. I just have a save file at the start of each sequence. I boot up from renpy and load the save. Takes 10 seconds.

 

[MidnightArrow]

Not sure why you think the filename structure is a problem. My images are all a form of AABBCCC_D. AA = story, BB = chapter, CCC = still for chapter, D = sequences or branches. Easy to manage, easy to track, easy to implement. E.g. I just finished render 0101602. The next render is 0101603. I plan it out in my script and just following my own blueprint as I go.

And the instant you need to reorder anything, the whole thing collapses like a house of cards. Not to mention it's unreadable at a glance, so if you come back a month later and want to know which frame has John holding an item, you'd need to waste time cross-referencing what's in the code with your file system just to figure out where you are, defeating the whole purpose of using a variable (a descriptive, human-readable label for data) in the first place.

In small doses it's not bad, but as code complexity increases it becomes unmanageable.

And also not sure what you mean by having to compile and fast forward to see changes. I just have a save file at the start of each sequence. I boot up from renpy and load the save. Takes 10 seconds.

And then you need to fast forward from the start of each sequence to get to the point where you need to test a transition or a creator-defined displayable, which is exactly what I said. Compare that to having a live preview in a hypothetical editor, which would take 0 seconds.

 

[TessaXYZ]

And the instant you need to reorder anything, the whole thing collapses like a house of cards. Not to mention it's unreadable at a glance, so if you come back a month later and want to know which frame has John holding an item, you'd need to waste time cross-referencing what's in the code with your file system just to figure out where you are, defeating the whole purpose of using a variable (a descriptive, human-readable label for data) in the first place.

In small doses it's not bad, but as code complexity increases it becomes unmanageable.



And then you need to fast forward from the start of each sequence to get to the point where you need to test a transition or a creator-defined displayable, which is exactly what I said. Compare that to having a live preview in a hypothetical editor, which would take 0 seconds.

These are really non-issues for me. The benefit of having a better render vastly outweighs any of the challenges you're posing.

Edit: To really hammer the point home, here's a render from my first VN release. It's important to me and to my storytelling to show these girls all sitting around the table. There's a plot point that depends on one character reaching down for a dropped glass and seeing another character under the table. This would be impossible to convey visually with your sprite method, and it just looks better to do it this way. So what if I occasionally have to put 0101145 before 0101144? So what if I have to hold Ctrl for 4 seconds? I should sacrifice my renders for this? Really?

 

[MidnightArrow]

These are really non-issues for me. The benefit of having a better render vastly outweighs any of the challenges you're posing.

Edit: To really hammer the point home, here's a render from my first VN release. It's important to me and to my storytelling to show these girls all sitting around the table. There's a plot point that depends on one character reaching down for a dropped glass and seeing another character under the table. This would be impossible to convey visually with your sprite method, and it just looks better to do it this way. So what if I occasionally have to put 0101145 before 0101144? So what if I have to hold Ctrl for 4 seconds? I should sacrifice my renders for this? Really?

It's not "my" sprite method, it's how visual novels have been made for the past thirty years, and it's how Ren'py is programmed to make them. The quality of your renders is besides the point, compared to a discussion about how Ren'py works on a technical level.

This is what a visual novel is:

Spoiler: Visual Novel

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

You take sprites, you layer them on a background, you give them dialogue. Every once in a while, you show a unique event still. Ren'py is made with the assumption you're making a visual novel this way. But now people are trying to use it so it's nothing but event stills, and that's not how it was designed to be used.

 

[crabsinthekitchen]

full renders are basically backgrounds with no character sprites so I don't see why that would be a problem

 

[MidnightArrow]

full renders are basically backgrounds with no character sprites so I don't see why that would be a problem

Ren'py is designed so you can easily type:

label conversation:
    scene
    show bg living_room
    show yuki casual
    with dissolve

    "Dialogue."

    show yuki casual mad

    "Dialogue."

    show yuki casual apologetic

    "Dialogue."

    hide yuki with dissolve

    return

and then your scene is done.

Compare having one "bg living_room" to 150 event stills that you need to keep track of, how to name them descriptively, and figure out how to edit them together and when you want to reuse them, and they all need their own transitions and transforms, and you have to keep flipping back and forth to your file browser just to see what they are because Ren'py is text-based.

There's a reason nobody does video editing in a text-based program. It's fucking madness.

I'm making a visual novel that has one hundred event stills for a single scene. And it was a nightmare because Ren'py isn't good at handling one hundred event stills for a single scene. I learned my lesson the hard way, and I'm going to be using a lot more sprites for the next release.

(Well, and also because Daz Studio is shit, but that's nothing to do with this conversation.)

 

[anne O'nymous]

I'm not saying it's not faster to do the usual route, [...]

Then I'll say it for you, because it's not faster to use sprites ; it's the exact same code that is used to display a sprite and a full image.