Renpy: The Difference Between Jump and Call

I'm sure that there's a learning curve to any particular programming language. I wouldn't really know - I'm barely fluent in HTML, and I have a very loose grasp on Python as it is.

That said, I've started to get pretty good with using Ren'Py, and recently came across this little tidbit that makes my life so much easier now that I understand it correctly.

Today, I'm talking about the difference between a jump and a call.

When making any project in Ren'Py, you could theoretically place everything into a single file... but doing so is a nightmare in practice, especially when it comes to finding particular scenes. So you split the script up into different files. Not every Visual Novel (or game in general) needs to have a linear progression, but it's usually nice to allow some amount of player agency, or to offer branching paths. Even if it's just something as simple as letting the player choose which scene plays out next, you need to be able to make that happen in the code somehow.

So, you use the jump command to go over to a label. This is telling the code "look for this thing I defined and run it immediately". Most of the time, this works really well, but then sometimes, you need something just a little bit more complex.

Let's pretend that you're like me, and you want a game with some kind of a day planner. Or has a hub menu that you make choices from. You make selections and scenes play out. But how do you get to return to the hub? Well, you could jump to it, but that's not always the ideal way to go about matters - especially if you've got a previously-running script that needs to keep executing (like a day planner). You need some way to return to where you were when executing your code, and a jump command just won't do.

In these cases, you use the call command instead. One way to think of it is putting a bookmark where you just were, so that at the end of your scene you can use the return command to take you right back to where you came from. You could think of it as inserting a new block - whatever is inside runs, and then returns to the previous block (unless you make a new block inside of that one).

So, what happens if you use the jump command, and then end your scene with return? Well, if you do that, you go back to the main menu. This is not the ideal way of doing things, especially not if there's more game planned after that!

The reason is because, as I mentioned above, using the jump command treats everything as though it were running in the same block of code. If you're in the main block, then when you return, there's nothing left to go back to except the start of the game - meaning your main menu.

In a lot of simpler games, jump is more than enough to get you where you want to go. But if you need something a little more involved, call will become your best friend.

Hopefully this helps someone better understand these tools. It's taken me awhile to get this far, but I've got to say it's really rewarding to finally understand these things.

April 2017 Progress Report: Project Cranberry Jam

It has been several months since I last gave any indication as to where we stand for Project Cranberry Jam. This is unacceptable so here goes.

All of the character and background artwork has been completed, though not all of the assets have been converted just yet. Being a one man operation in a lot of respects slows some of that progress down. (Not to mention the attending hardware/OS failures that initially delayed progress, combined with a rather troublesome bug... ugh.)

In what time I've been able to find, work has been slowly progressing on getting the scenes into the engine so that work in other areas can finally begin. The scenes for the demo itself are about 60% completed at this point - the scenes required for Week 3 are about 30% finished by now. A number of them are fairly short, so that shouldn't be too difficult to deal with, provided I have the time.

UI design still hasn't been touched. Again, one man operation, UI work will come after I get the scenes taken care of. Also, no audio has been completed yet - though work has commenced on some of the music. If the stars align, this is something that can be taken care of within another month or so.

There's still a good amount of editing which needs to be done as well. For now, my focus is on getting the scripts into the engine, so that they can be more easily adjusted - I'll have to go through them all again anyways when it comes time to put in the audio.

So as it stands, we're at about 50% completion for the demo, I feel. Getting the scenes all put in is the biggest part of the game - it's the core of the experience, really. Once those are all finished, the demo can be considered about 75% complete - the rest is getting in the audio, fixing any other weird bugs that might pop up, and finishing the UI (and assembling some credits? That's probably important for a full release!).

All told, still a lot of work to be done, and while it's not where I hoped it would be by now, having all of the artwork finished is a huge step forward.

This has been your not-regularly-scheduled break in silence. Back to work.

Jan 8 2017 - Displaying images sanely

I think one of the most difficult challenges I face with not having a strong programming background is not knowing exactly how syntax is set up for different languages.

Case in point: Renpy. You would think flipping an image is a simple thing. Spoiler alert: It is. But figuring out how the heck the engine expects you to do it with the spaghetti documentation that exists is kind of a nightmare in my experience.

I have a picture, and I want to be able to display it facing left or right. This isn't a difficult thing to ask. But there are a lot of ways to do this, some of which are more trouble than others. It's possible to declare the image transforms upon initialization, but when you could potentially be flipping thousands of images, you need a much better solution. Same with exporting duplicates of every image that could be flipped and hoping you remember the naming conventions.

It's a nightmare, and while it might work for a one-off instance, it DOESN'T work for my project at all (or most projects, I'd wager).

Fortunately, there's a much easier solution, one that isn't covered in ANY of the documentation at all.

I present to you the xzoom command.

    scene black

    "This here is just a test scene meant to play around."

    "We're going to play around with some images right now."

    show tzania happy at right:

          xzoom -1.0

 The gist here is pretty simple: By declaring a show command with a colon, you can apply transformations such as scale, zoom, rotate, whatever. It does NOT work like the following:

                 show tzania happy at right with xflip

Despite the fact that the documentation seems to indicate this should work. (It doesn't because it has no idea what xflip is. Or xzoom. Or a lot of other things for that matter.)

So lessons learned once again, and if you ever need to flip an image in renpy quickly, this is how you do it. (You can also use yzoom -1.0, that works just as well but with the other axis.)

I'm sure I'll figure out other ways I can use this to my advantage in the future.