The Ren'Py 6 Endgame

[PyTom]

Okay, 5.6.7 includes just about everything I had planned out for Ren'Py 6. So I think it's fair to say we're in the Ren'Py 6 endgame.

There are a number of ways people can help with getting Ren'Py 6 out the door. A big one would be by reading over some of the new stuff in the demo and the quickstart manual, and letting me know if and how to improvement. The quickstart can be edited on the wiki, so feel free to be bold in improving it.

I think I also want the 6.0 release to be a bit higher profile then the 5.0 one. So if people have ideas on how/where to publicize it, I'd appreciate it if you can let me know. If someone wants to help out with this, I'd appreciate that even more, since this sort of thing is the polar opposite of my strong suit.

Also, if you're working on a game and this would take away from that, then focus on your game... I think having really good games is the best advertisement for Ren'Py.

Anyway, the idea is to get 6.0 out the door fairly soon, so we can move on to bigger and better things.

[mugenjohncel]

Uh... this is actually more of a wish list...


Wish No. 1
For Ren'py to have an option to prevent a user from clicking for a specified time...

or

To make it easier for mere mortals like me to prevent a user from clicking for a specified time...

I know I've been asking for this for quite some time now and I really don't have any idea how UI pause works... and I have a very good reason why I really wanted to have this behaviour badly.

Wish No. 2
I am currently putting a lot of effort on my game and personally wanted to customize my game to have a different look (No not that round thingy and color scheme that kinda reminds me of a blog page.

Since my programming skills on Ren'py is comparable to that of a NOOBIE and documentation on U.I. thingy is still scarce (...if only a tutorial exist on how Mikey does that cool looking menu)... the only option for a newbie like me to make my game unique would be...

For Ren'py to have a Bitmapped based menu kinda like... what that other engine is doing right now (Hint: It's sharp, It has Japanese connections and has Dan Kim on it's ranks)

or...

For Ren'py to support Image Mapping on the main menu... this one is a bit farfetched idea.

Beg for help and let someone (preferably from the forum to do the work for this poor newbie).

Wish No. 3

Better documentation on U.I. functions.

I wanted to implement a sort of graphical stat meter showing how much you have progressed in capturing a girl's heart... yes I know it's been done before but I got... different plan for it.

But no idea how to do it...

Thank you...

Goes back to work...

[DaFool]

Well that other 'sharp' engine won't be able to do anything other than visual novels.

For visual novel / rpg or visual novel / strategy hybrids, there's no other choice but Ren'Py with its python undercarriage.

Do you really need that bitmap menu? Why not just position the menu text in a specific area, then just customize the background to look like it has buttons (although it will just be the text that's hoverable).

EDIT: Actually, I think its best to concentrate on making the core of the game kick-ass. That would do far more to encourage programmers (perhaps PyTom himself) to customize a menu system just for your game. I think it might actually be detrimental to be working on the bells and whistles before the core kick-ass-ness of the game is complete. Just a suggestion.

[Alessio]

(...if only a tutorial exist on how Mikey does that cool looking menu)

AFAIK, PyTom programmed it, not mikey. I'd follow DaFool's proposal on this one - try to get there by using what functions we have. I'm sure PyTom will help you with special wishes once you've finished the VN.

[mugenjohncel]

I'd follow DaFool's proposal on this one

OK... I'll behave for now and do that...

...but I still wish to have a way to prevent a user from clicking or doing anything for a specified amount of time.

Goes back to work...

Edit:

...but I still wish to have a way to prevent a user from clicking or doing anything for a specified amount of time.

OK... I take that back too...

Goes back to work...

[PyTom]

Well, there is a way to stop a user from doing anything for a given amount of time.

Code: Select all

    $ ui.pausebehavior(5)
    $ ui.interact()

This is a fairly antisocial thing to do, mind you. Many players (including myself) like to get all of the endings of a game. This involves playing through the game once normally, and then I start skipping through the game to try to get the alternate paths. The code above will take 5 seconds, regardless of if the user has seen it or not... and that's usually a bad thing.

I'll need to think some more about image-based themes for the various menus. Perhaps the problem can be simplified if I say that the buttons are all of some fixed size, so the images don't need to be scaled at all. This is what blade does (we can mention it here, we're not afraid of it), so it might make sense to have a theme that does that.

Which do you think is better? Imagemap buttons with the text stuck on them already, or a better way of supplying the backgrounds for buttons in the current layout?

[Alessio]

Imagemap buttons with the text stuck on them already, or a better way of supplying the backgrounds for buttons in the current layout?

Supplying the backgrounds, IMHO. It makes translations and font changes easier, and also allows to use only one picture for all of the buttons (thus less files needed, less editing etc.).

If it was possible to assign different images to every button, then even nicely designed menus would be possible... a bit like an imagemap in html. But this is only me thinking aloud, I don't have a need for it. Yet. :)

[monele]

This involves playing through the game once normally, and then I start skipping through the game to try to get the alternate paths.

I don't remember if I suggested this or not but what about forcing the sequence if it's not "read" yet? And on further reads, allow to skip through it. This would ensure that it's seen at least once, fully... and wouldn't bother a player who goes through the other times.

[PyTom]

I just dislike the idea of forcing the player to do anything. You should treat the player as a partner, not a child... trust that the player is not going to skip abruptly through the game, at least on the first playthrough. I just don't think it's necessary to try and infantalize the user by deciding when he can click.

[Alessio]

I agree with PyTom here, as I fear to see a flood of VNs that play as swiftly as Hirameki's non-PC DVDs. On the other hand, what is ethically more problematic: An author who disallows the player to click, or an engine developer who disallows an author to disallow the player to click?

Don't take this one too seriously. ^_^

[PyTom]

I mean, I allow it. I posted the code above, with both functions having been documented for ages. But at the same time, I don't do anything to make it easier, since it's a bad idea, and I don't want to encourage bad ideas.

Most places where people want unbreakable pauses are more appropriately done using the relatively new "with Pause(1.0)" syntax. Using with Pause lets you show a series of screens, and when the user clicks, he's brought to the end of the series.

Realize that my motivation for making Ren'Py is enlightened self-interest. I made Ren'Py because I want there to be more games for me to play. Many of the design decisions reflect my preferences as a player: The default text speed being infinite, a very powerful skip system, unlimited save slots, and so on. As a player, I want as much control as possible over the game, and Ren'Py reflects that.

[Alessio]

I don't want to encourage bad ideas.

Agreed. Besides, by providing a set of common rules how saving/skipping/rollback etc. should work, Ren'Py actually makes VNs more attractive to the player, since their interface behaviour is similar.

Disabling skipping, reducing/disabling saving slots etc. would rather make the player less inclined to play.

[PyTom]

I'm not even sure that it would be less likely to play... I think what's more likely is that someone will play, but be disappointed by the limited functionality.

I think it's important to separate the artistic from the functional, when it comes to this sort of thing. To me, a click advancing the game is a functional thing, that people expect to always work. If it doesn't work, they'll worry that something is broken... arguably, something is, since the game has changed its behavior to something unexpected.

Mugenjoncel, can you describe what you'd want a non-abortable pause for? I suspect there's a better way to do it, without violating the user's expectations.

[monele]

Mind you, I've always disliked the idea too... but since so many creators wanted it, I've tried to find a possible intermediate solution . As you said, though, there are already such solutions, so it should be enough.

[Rika-chan]

I just dislike the idea of forcing the player to do anything. You should treat the player as a partner, not a child... trust that the player is not going to skip abruptly through the game, at least on the first playthrough. I just don't think it's necessary to try and infantalize the user by deciding when he can click.

I mean, I allow it. I posted the code above, with both functions having been documented for ages. But at the same time, I don't do anything to make it easier, since it's a bad idea, and I don't want to encourage bad ideas.

Let's get this straight. You dislike authors forcing players to play a certain way, yet you are controlling how authors can make their games by withholding certain functionality. (Sure, it's there, but it's not "easy.") I could even complain that the default options are set to your preferences, and it takes special programming to change them. Also, not "easy."

PyTom, I know you made Ren'Py for yourself. But it seems to me that you don't realize that people see Ren'Py as a tool for making something other than ren'ai games. Maybe we're asking for these functions not to piss you off, but because we have ideas on how to use them in our games, which may or may not be ren'ai. In other words, you can't conceive of every way that people might use your program. Isn't it a better practice to allow everything, and trust the authors do what is best, rather than treating them like children?