Transition Naming Scheme (Input Requested)

[PyTom]

Right now, Ren'Py has a fairly large number of pre-defined transitions. However, each of these transitions takes a fixed amount of time... and that amount of time varies based on the transition in question. While the game-maker can define their own transitions, this is a fairly skilled activity, and few do it.

What I'd like to do is create a bunch of new transitions, in the most useful time increments. I believe these to be 1, .5, and .25 seconds. Along with the existing name, each transition will have three new names, which can be used to systematically get a variant of the transition that lasts that long.

So the question is, what should the names of these transitions be? Right now, my idea is to prefix the simple transition name with a single character--- s for a transition that takes a second, h for a transition that takes a half second, and q for a transition that takes a quarter second. So one would write:

with sdissolve

to cause a dissolve that takes a full second, and

with hdissolve
with qdissolve

for dissolves that last a half and a quarter of a second, respectively. Of course, one could always write:

with dissolve

to get a standard-length dissolve, which right now takes a half-second.

q and s can also be though of of standing for quick and slow, but h doesn't have an alternative meaning.

What I'd like input on is the names. While these prefixes (s, h, q) are the best I can come up with, I'm not totally in love with them. (I changed them over the course of writing this message.) So I'd like peoples comments on these, and perhaps suggestions for alternatives.

Some ground rules when suggesting alternatives:

- Names MUST start with a letter, and contain only letters, numbers, and underscores. So something like .5s_dissolve is right out.

- I think brevity matters here, to a decent extent. A transition might be typed hundreds of times in a visual novel, so long names like quarter_second_dissolve seem like a bad idea.

[DaFool]

I'm used to using dissolve and fade for standard half-seconders and Dissolve(2), Fade(1.5), etc. for defining otherwise.

Is there a need to come up with all these names, I don't think it will really streamline anything. What I fear is people to confuse semi-reserved words from reserved words.

That's just my opinion though.

On the other hand, I just love transitions, but I have to time them perfectly, and I prefer going to the meta-definitions for those.

[monele]

I also use the no-number version when I don't really care about the time (knowing that I usually redefine the default duration for each game), and if I need something precise, I use the function with parameter.

[derik]

Right now, Ren'Py has a fairly large number of pre-defined transitions. However, each of these transitions takes a fixed amount of time... and that amount of time varies based on the transition in question. While the game-maker can define their own transitions, this is a fairly skilled activity, and few do it.

Why not make it-
with dissolve (.5)
or
with dissolve (3)

Dissolve defaults to 1 second, but you can explicitly set a different time to ANY transition with an optional duration setting after it.

(NO idea how this works codewise. )
Is the answer to 'why not' 'because they're pre-loaded into memory'?

[PyTom]

I considered derik's suggestion, but I don't think it would work. The big problem is with some of the more complex transitions, like Fade, where it takes multiple timings. Also, I think qdissolve is easier to type then dissolve(.5), as there's 1 extra keystroke rather than 6.

Finally, there's a technical reason... pre-defined transitions are already curried functions, and I don't want to change that.

[Adorya]

Some of my own defs name :

Code: Select all

    $ fastdissolve = Dissolve(0.5)
    $ dissolve = Dissolve(1.0)
    $ slowdissolve = Dissolve(3.0)
    $ fastfade = Fade(0.3, 0, 0.3)
    $ vpunch2 = Move((0, 50), (0, -50), 2, bounce=True, repeat=True, delay=0.37)
    $ sweep0 = im.Tile("a0.png")
    $ sweep1 = im.Tile("a1.png")

I don't know if that is useful for the user to have those predefined definition, it really help a lot to learn ren'py when digging into the demo game config files and maybe exemples can be made in the manual or demo instead of having too much of them already in the game engine