Tom Rothamel on Ren’Py

Hello, and welcome to Podcast. In it, the podcast about Python and the people who make it great. You can subscribe to our show on Itunes, Stitcher, or TuneIn Radio. You can also add our RSS feed to your podcatcher of choice.

You can follow us on Twitter or Google plus with links in the show notes.

And please give us feedback. Leave us a review on iTunes,

send us a tweet, send us an email,

or leave us a message on Google Plus. You can also leave comments on our show notes at our site at pythonpodcast.com.

I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

For details on how to support the show, you can visit our site at pythonpodcast.com.

I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of podcast.init.

Use the link hired.com/podcast

init to double your signing bonus.

Linode is also sponsoring us this week. Check them out at linode.com/podcast

init and get a $10 credit to try out their fast and reliable Linux virtual servers for your next project.

We are recording today on October 19, 2015, and your hosts as usual are Tobias Macey and Chris Patti.

Today, we are interviewing Tom Rothamal about Renpai.

Tom, could you please introduce yourself?

Hi. I'm Tom Rothamal. I'm the lead developer of Renpy, which is a visual novel engine that people use to make computer games.

That's my

side project.

By day, I am a embedded systems engineer,

and by night, I work on computer games.

Very cool. So, Tom, how did you get introduced to Python?

You know, I was trying to remember that, and it was about

2, 003. Can I remember Python 2.3

was the first Python version

I used seriously?

I was a grad student back then and I don't recall how I came across back on the first time. I remember seeing

the enumerate and the zip operations

and seeing how they worked with the way of decomposing

tuples in a 4 statement

and I realized like that's actually elegant out of simplicity

I've been used to seeing a bunch of languages that had aggressively

more and more complicated type systems

and Python here, you know, suddenly tries to be, you know, simple and beautiful and easy to learn.

And so, you know, I became a fan of it very quickly since I think programming should be easy enough that

people can access it. So that's how I found out about Python.

And for those in the audience who haven't come across it before, can you explain what Renpy is and what your inspiration for starting it was?

Sure. Well, Renpy is a visual novel engine.

It's used to make a very specific genre of computer game,

visual novels. Visual novels are

they're kind of like interactive game books. We present pictures. We present words. Often a very long written story,

music, sound effects, animations,

videos

and often choices to the player.

By using this, they're able to pick which direction the story goes,

to get a story that often feels more interactive than if you're simply reading in a book.

Renpy is

multiple things. It is

a series of domain specific languages that allow you to do things like write the script of a game in a matter similar to a movie script.

There's other ones for making the user interface, another 1 for defining animations and transformations,

and, of course, you can embed Python in it. Renpy is also the engine which is written in Python

that lets you go ahead and interpret all of these different languages and presents the game

to the players.

And I noticed that Renpy supports a number of different styles of gameplay. Can you explain the differences between interactive novels versus kinetic novels versus RPGs?

Sure.

Interactive novels or visual novels is basically a term we use. It's a game in which

we present, you know, the whole thing, the choices to the player. But usually visual novels don't have very much, if any looping back to where you once were.

So if you think of it as as reading like a chooser an adventure book something like that, You would never go back to the same place multiple times.

So a visual novel, you know, it has the menus. It has choices you get 1 of multiple endings

you don't go back kinetic novels

is a subset of visual novels.

The terminology comes from actually a brand name for games of this type that we kind of adopted and genericized in which there actually aren't any choices, and we simply use the other portions of the medium.

The presentation of the visual novel format to present a non interactive story.

Somebody simply clicks through from the start to the end.

Oftentimes, you know, because this is a visual medium, you do get more than just simply reading book, but you don't get the interactivity.

There is a fraction of people that is actually would question whether a kinetic novel

is a game at all because there's no choice

in it.

I'm pretty agnostic on that issue.

And lastly, RPGs

and other, let's call them life simulation games, are more game like. You like, in most games, you often will have, like, a central loop in which you do something repeatedly,

be it, you know, in an RPG walking from town to town or in a life simulation game scheduling your day,

things like that. So for example, the a good example of simulation game

is 1 called, Long Live the Queen in which you play,

the life of a

a, a queen

of a country

and you have basically apparently, this is really really hard suited

to.

1 thing tries not to be is suited to.

1 thing tries

not to be is an answer to

every single possible gaming question. Although, you know, you can force Renphie into genres

that it isn't meant for. I think 1 of the big advantages of Renphie as a tool is we've chosen to embrace a particular genre or set of genres

and make decisions that make those

that affect those genres directly

as compared to trying to be something more generic that could apply to everything,

but doesn't give

you very much despite that.

So if you think of it, it's almost like like uh-uh a web framework like something like you know, Django, which is meant for

specific types of websites

and can handle a lot of different types of websites

well. But once you get beyond what it was designed for, you begin having to fight the decisions it's made for you. Ren'Py is like that too. If you want visual novels, kinetic novels, simulation games, certain types of RPGs were a good solution.

If you don't want those formats, there's often better tools and we'd almost rather you use those because,

you know, we wanna make certain types of games easy.

So so it's interesting. That makes perfect sense that that there would be, you know, a lot of discussion around,

kinetic novels being games versus not. I mean, on the face of it, I would think if there's no choice, then it's not a game because it being a game requires active participation

on a more

involved level, but I but I can see where it's a slippery slope.

Yeah. I mean, I can go either way because I think that's a perfectly valid point. At the same time, if you have 2 teams sitting in rooms next to each other and 1 designs

decides to put choices into the project and 1 doesn't, but everything else they're doing is the same, is it right to say 1 team is a team of game developers and the other 1 isn't?

Right. And there's the slippery slope.

So I noticed that Renpy has clearly been around for a while. I noticed some of your games for OSX have are power PC binaries, which definitely dates them by a few years.

What problems have you encountered maintaining such a long lived project and keeping it current?

Well, there's lots of problems. I mean, starting from just the most basic 1 which is that, you know, everything has changed out from

underneath me. I mean, even Python,

Renpy uses

a keyword with,

which is used to introduce,

transitions from 1 screen to the other,

like, with dissolve will dissolve the screen from 1 screen to the other. Well, we had a function that was available through the Python API run py dead width. That doesn't work anymore. That's now a keyword.

Right.

Yeah. We've had to port RenPy and oftentimes,

other parts of the stack like Python itself and SDL

to,

to platforms that didn't exist when RenPy started like Android.

You know, we we did the part the a port of Python and SDL to Android or at least, you know, got the Pygame stack working on Android.

Other things are just simply, you know, it's not enough to simply keep the run pyron. Since run py is a tool, you know, it is a programming language.

And not only is been around for I believe it's 11 years now.

We've had individual

games in development

for

about half of that time. So, Kitaui Shochu took about 5 years to develop.

Break chance memento, which isn't out yet, is is getting pretty close to there. And then there's a few others that are that long development cycle.

So you kind of have to balance changes you make in the engine

with trying to make sure that the games

that are under development

don't have to constantly be rewritten to match the updated engine.

Right. That makes perfect sense. I was thinking as you're mentioning with, that must have been kind of a pain when they added that feature to the language.

And did it did, Python 3 bring any additional challenges in that way?

We haven't actually updated to Python 3 yet. So, I mean, that's something that has been on my schedule.

We actually took a solved a lot of the problems Python 3 had, like, for example, Unicode support. Renpies solved it at its own, like, the scripting language level,

a bit before Python did.

But, you know, at some point, I have to, you know, Python 2 is on its way out. All my new code has been written in in Python 3. But I haven't actually had a chance to update to Python 3 yet.

And that's something I hope to address in the next year or so,

but it is, you know, certainly a very big challenge.

Yes. Particularly

given that the

project is so long lived. I'm sure that there's a lot of design choices that you made that were specific to the Python 2

releases

and some of the new updates in Python 3, I'm sure, will simplify some of the internals. And so it's a matter of, do you just

do a 1 to 1 port and get it working with the new syntax? Or do you actually take advantage of some of the new libraries to

refactor and redesign some of the internals? That's always

a challenge. Or do you do the 1 to 1 port and then do the refactoring afterwards?

Yeah. That's made actually difficult too by the fact that we have many long lived projects.

And I prefer not to make them have to go through the Python 3 transition if they don't want to. So result is I have to maintain the Python 2 version

through the scope of the, you know, through the scope of these long lived projects. So probably what I'm gonna do is maintain parallel branches

of renpy, python 2, and renpy, python 3,

for at least 2 to 3 years to let these projects get a chance to be released and get out there.

So that's interesting that you're planning on doing maintaining 2 separate releases rather than doing what a number of other people have done and trying to create a unified code base using perhaps the 6 library to abstract away some of the differences?

Yeah. That that's actually what what I'm considering doing. But I probably would brand it as 2 separate releases just for the sake of not confusing people. Understood.

And so

on the subject of libraries, what libraries does Renphie leverage? And how did you go about selecting them to allow for cross platform development and deployment? And then also given the longevity of the project, selecting them for continued maintenance to make sure that they wouldn't disappear out from under you?

Yeah. Renpy,

is not very dependent on things at the Python level. We

we depended a lot on various,

c libraries like the SDL

family of libraries like SDLSDL

image, things

like that. There are a number of other, like, little libraries

that,

there's 1 which I forget the name of that does

literatureization for Arabic,

and things like that. We use FFmpeg

or libav depending on the platform

for video playback.

And for the longest time, we use the pygame project,

but they haven't really ported over to SDL 2 yet. So recently,

we had to reimplement,

the pygame API on top of SDL 2

in order to be able to move to the underlying

SDL base library.

SDL 2 base library, which is necessary for iOS and really improved our support for Android.

I know that the Kibbe library has recently ported their underlying

architecture to using the SDL 2 libraries. And I know that they're working on

eliminating Pygame from their dependencies.

And so I'm curious if you've considered

trying to take advantage of Kivi or if that would just be too much of a breaking change in terms of how the overall project was constructed for the people who are actually using it.

Yeah. I mean, I think that that would probably

be too much of a change.

It's also like when you're in the games area, you know, oftentimes

and especially in something like a visual novel where you're presenting text at people and, you know, the interface

can often be an important part of how games establish

things like, you know, how they look, how they feel, you know, emotionally.

Mhmm. So trying to leverage

more standard GUI kits

seems like it could often,

like, it's something that I'm I'm not that interested in doing just because I I suspect it would require

making,

sacrifices in terms of how much it has been customized.

It could be customized.

At the same time, you know, we have used

some of the code maintained by Kivy, like, Pyobjus and PyJNIS,

which are used on the Apple platforms and on Android and and, I guess, other Java platforms. The Android is the only 1 we run on,

to make calls to objective c in Java code respectively.

So I see there's, you know, a decent amount of

opportunity for sharing

on that level.

But at the same time, like, I think trying to rewrite

and probably restructure majorly to use a different GUI toolkit

probably isn't the most efficient way to go about developing a project. You know, it's just that I think we're in in a very different

area than than what Kivya is good at.

And you mentioned using Pyobjus and PyGenius. And I'm curious if you abstract away

those libraries from the people using renpy or if you actually expose those capabilities.

Like many other parts of renpy, the answer is both.

So we tend to have high level

wrappers for the sorts of functionality we expect people to be using a lot. So for example, there there's a pie up just binding there's a thing,

in in app purchase library that's used on the mobile platforms. And and on iOS, we use pyobjus to call into

code that's written in objective c.

But from, you know, our user's perspective,

you know,

they just see you know IAP dot purchase whatever.

But

if they ever were to want to import, I just and access code that they've written directly or access something that we simply haven't wrapped yet,

they are welcome to do that. I consider the availability of that to be a portion of of, you know, the run by API,

which means, in general, that's actually that sort of, like,

ability to both work at a high level,

but also to have tools available

in case you do need to import underlying libraries

or in case you need to extend the way run py is implemented and things like that. It's something that I really like about using Python as an implementation language.

Since by having the engine

written in the same language as the scripting language that's used by the engine, it really does lend itself to being extended and meta programmed and all sorts of other things.

Absolutely.

Tobias, maybe you can help me out with her last name. But when we interviewed Jessica about the Python community and the talk she gave a number of years ago, I do remember pardon me? Jessica McKellar. Yes. Thank you very much, Jessica McKellar. Jessica, I apologize

for forgetting your last name. You are awesome.

We she talked about how

she felt like, you know,

ease of packaging for Python mobile game developers was was like a key

aspect to the platform. And it just it just strikes me having talked to the Kibbe folks and now Tom talking to you about Renpai.

You know, people are doing this stuff and it's like if if there's so much pain around this,

why don't we take these technologies

that are enabling, you know, Renpy and Kivi

to make

mobile games,

available fairly easily?

Why aren't we making that, you know, those technologies more

accessible slash widely available,

you know, and make Python a first class mobile game development platform.

It's just kind of strange to me because, I mean, Tom, you're talking about how

Renpile already runs

on Android

and iOS and all the desktop platforms. It it's just I couldn't help but remember her the discussion around that with her, and I feel like this is a missed opportunity on the part of the Python community.

Yeah. I I think that that's actually 1

having solved that problems at least for a specific application, a specific genre of game, is I think 1 of the reasons why Renby has been so successful.

I'm pretty proud that Renby has 1 click distribution for the desktop applications

where you click a button and it creates either a single zip file or 3 zip files for Windows, Mac, and Linux.

Android is a little more involved because it has to go and download some extensions to run py then download,

then download the Google SDK.

You have to have Java installed on your system already, but it will download everything it needs to package for Android

and then it's 1 click to down to build to install on your device and run the device.

IOS is still a bit of a pain point because, you know, you need a Mac, you need it set up with Xcode and all of that.

There isn't a good way to just go and and build and run on the device that I've been able to figure out yet.

But, I I do think that, you know, really

1 of the things that has let Renpy become very successful in its area is just that, you know, we've spent a lot of effort solving

the packaging problem for Python applications.

I do want to at some point and it's, you know, it's kinda hard to find the time to this with, you know, all the other stuff, you know, all the things that people report our own buying and so on. But to try and take our packaging tools, most of which are at least fundamentally

built around packaging arbitrary

pie game or really pie game STL 2 applications

and make them, you know, extend them such that you can

package those arbitrary applications

rather than simply being limited to builds of run by itself. So potentially taking,

the Renpy launcher

and maybe setting it up in some way that it you can build things that aren't Renpy games with it. The other end is I also think very important, which

is getting people who aren't programmers for which this is, you know, their first language

and getting them set up with everything they need to develop. So another thing I've done with Renee

is I've gone ahead and set it up such that it can automatically

download

you know, relatively small but programmers editors,

that have syntax highlighting and things like that all set up for you. So, when you download the Renpy SDK,

it'll ask, you know, would you like editor or would you like j edit as your editor? And you can pick from 1 of those

and

it'll set it'll set that up for you. And then when you click a file in the launcher, it'll open it in the editor you chose.

So I think, you know, tools like that, you know, getting that out of box experience. It's extending like Python's battery included philosophy.

To

you know the build environment and the editing environment and everything else you need to make software in a practical manner.

Absolutely.

So building on what you just said, because I know you already mentioned pygame SDL 2,

what underlying Python graphics toolkit does Renpy use for display, and how did that choice affect Renpy's design?

Renpy really implements its own,

graphics toolkit.

It uses, originally, pygame for about 10 years, now pygame STL to,

to do the basics

of, like, opening windows and and, you know, collecting input and and that sort of stuff.

But beyond that, we just use, Open GL

if it's available,

direct x via the angle library if it's not available.

At least for the time being, we can we can fall back to the software renderer

if it's not of if, you know, there's nothing available, although that will start giving warnings and doesn't give you complete feature parity at this point.

But we don't really use an existing toolkit mostly again because

as a game engine, we like it when, you know, customizing the interface is an important part of how you present yourself to the users. So you you kind of have to implement your own toolkit to get the level of customization that people want.

That makes perfect sense, and that's kind of interesting.

Have you ever thought about I know you mentioned it with regards to the launcher. Have you ever thought about sort of packaging up some of Renpy's

graphics capabilities and exposing them as a library, or does it just not make sense? Are they too

custom tailored to Renpy's uses to have that make any you know, be leverageable enough for other projects.

Yeah. I think it's it's the latter just, you know, plus, you know, the sheer work of of extracting them,

out of Renby. Plus, you know, I mean, there's a lot of graphics libraries

and, you know,

I think it makes sense to maintain it as part of the Renby project because it works with our styling system. It works with the screen language and things like that. But but I think, you know, once you start leaving, you know, the Ren Pye way of doing things, you're probably gonna get options that are just as good. There's also a certain extent where,

you know, the visual novels and the sort of games I'm talking about don't need the complete set of functionality that a more arbitrary GUI toolkit could easily provide

people. So while reading through the quick start in the documentation,

I noticed that there's a special DSL that you've created for defining the dialogue and the narratives. And I'm wondering if you can explain how you created the DSL

for building those storylines

and any inspirations that you may have drawn upon during that

creation?

Sure. I mean, Renbai has,

it's called the script language, and it's this the basic DSL for writing things like dialogue

and writing, you know, show this image, show this transition, play this music,

things like that.

Coming up with it was, you know, I mean, it's just it's it's inspired by English. It's designed to be quite readable and and fairly easy to remember fairly easy to write. At the same time, like, I wanted a relatively high degree of abstraction

because somebody who's writing a long game,

you know, you know, over a 100000 words is is not unheard of and some some are even significantly bigger than that.

You know, you're gonna be typing this a lot, so I wanna make it, you know, easily typeable. So we do have a decent amount of abstraction to make that easy.

The,

so the original version of renpy was actually written

as a more standard Python library. This was renpy 1,

which wasn't released at the time originally,

but I eventually released about 5 for the 5th anniversary of Renpy.

But it was actually simply trying to make a game as just a series of Python function calls.

And that's something I had to abandon because there wasn't any really good way of saving in the middle

of a Python function.

So in order to solve that, you know, I need to be able to save and jump to any arbitrary point in the code.

I had to go and implement the,

you know, the first version of the DSL for renpy.

Probably nowadays, you could use something like stackless Python and and, you know, who knows if you would need it. I think in practice, the DSL provides a nice advantage because it gives you

the ability to it gives you a more readable language for code for script code than Python. It's also interesting that it's 1 of the very few

unstructured programming languages

designed in in the past, let's say, few decades,

and that's just

and because of the

the fairly specific domain that Renpy targets.

Structured programming languages, you know, 1 with, you know, a lot of work done to scope variables and and loops and things like that make a lot of sense for more traditional programming. And, you know, you couldn't write, you know, most code in it. But in a visual novel, you very rarely would show the same block of dialogue twice in a single playthrough.

So all the constructs of structured programming

that provide that sort of scoping and information like that just aren't particularly

relevant to the visual novel format. That's an example of trying to be good for 1 kind of game

but,

you know, while sacrificing suitability

for

types of games that are outside of our main.

I can imagine that having that DSL also greatly simplifies some of the maintenance, particularly for maintaining compatibility for some of those long running game projects because

the people who are implementing the games aren't tied to any particular

features of the underlying programming language. So they can simply

operate within the DSL without having to worry about that being modified from point release to point release of Python itself.

Yeah. I mean, that isn't a huge issue. But with statement change, you know, if we had been using

Python as the actual script language, that would have been us. But yeah. And, you know, certainly it's going to simplify the transition of Renpy from Python 2 to Python 3

that, you

know, non Python code,

won't have to be modified at all. So having that level of abstraction certainly is quite suitable.

And so can you explain a little bit about how you actually implemented the DSL at a code level? I know that Ruby is very popular for creating DSLs just because of the ease of metaprogramming.

But I also know that Python has its own metaprogramming capabilities. So I'm interested to hear your experience with creating a domain specific language.

Yeah. We don't actually do very much in the way of meta programming

directly.

It's a fairly

straightforward like they would teach you to compilers course on how to implement,

you know, the the the first few steps of a compiler.

We parse it using a recursive descent parser

that was originally

written in a parser generator called TPG.

And 1 section of runpy syntax, which is a use of dollar sign to introduce a line of Python, is actually completely stolen from at least an early version of tpg.

After a while, just for various, you know, error handling reasons, I wound up rewriting the the parser just in terms of of just pure Python recursive descent parser code.

That builds up in memory and abstract syntax tree such that each statement is

is implemented

using a Python object.

And then we simply do a walk over that tree of Python objects

to find, you know, what is the next thing we wanna execute. Each each object in this tree just has an execute method

that gets called, and that's how Renpy

does its basic, you know, script language execution.

1 really nice thing about using Python though is that many of the portions of the script language

are actually Python

either

just completely straightforwardly Python or Python in disguise.

So 1 example of code would be, you know, the say statement, which is how

you say a line of dialogue. A character would couldn't speak to you. And so while you can put a character name as a string,

you can also use a Python variable as a character name, which is the way it's usually done. But you could also use a function that returns a character name or any other arbitrary piece of Python code

in there. That isn't used by say 90% of run by programmers, but we have people who actually do figure out reasons to use the most sophisticated code available. And by embedding Python, So

it

So it feels to me like Renpy was heavily inspired by the JRPG genre.

And as such, there were games where sex plays a prominent role. I noticed dimension of hentai in the docks,

which is less readily accepted in the west. Have you ever encountered any pushback on this issue?

I actually haven't. I mean, we're going ahead. There's actually that that mention is actually in the,

the example game that shows you how how you can

make a game, that, you know, if you look, it actually does give the game itself gives you a little bit of pushback if if you pick that choice.

But,

but we actually haven't had any sort of pushback from any sort of outside entity or anything like that.

I think, you know, part of it is that people see visual novels. I mean, Revvie has tools used to make visual novels,

but visual novels are medium and mediums can be used to make all kinds of games

and while you know a lot of them in Japan are adult, a lot of them aren't and even you know the the adult games that they had in Japan, you know, many of

them would inspire, for example, television series that didn't have any of that content in them. So the stories

were long enough and complex enough and and, you know, good enough to to stand pretty much aside from that.

With the western community which which where Ren'Py is is most popular,

that really doesn't come up very often. I actually took the liberty of looking today and it's about 6% of games have adult content in

them,

which, you know, is isn't a particularly high percentage.

But, again, you know, Renpy is open source. People can use Renpy for whatever they want,

and, I think that's a good thing. You know, open source says no discrimination against field of endeavor. And I think

that's great because it means whatever people wanna make with it, they're allowed to.

I think that's a really good thing too. I mean, I just have to say, you know, forgive me for soapboxing ever so slightly.

I feel like here in the West, here in United States in particular,

we are way, way, way, way over puritanical.

Like, you know, sex is bad, but, you know, watching people get their guts blown out in graphic detail and having, like, innards flying across the screen, that is groovy tubes. No problem at all. We, you know, can have that all day long. So I think we're kind of neurotic about it, and and I I was actually kinda happy to see the mention in the docs even if it's in sort of a a a tongue in cheek way.

And, yeah, I mean, I'm sure it is only a small percentage of the gaze, but it just I I had to chuckle. So, I mean, I I think that's great. I think, as you say, it's a creative medium, and I think being so parochial about it is just

needlessly censoring

what could potentially be some really interesting or great art.

Yeah. I I mean, I think it's also important

to realize that, you know, traditionally, western games are they're actually somewhat of an an anomaly.

Like, if you go to a bookstore, you know, Barnes and Noble's or something, there's a large romance novel section in there. And what do you think those books are about? So I actually got a chance to look it up and and they sell I believe it's about 13% of books

fall into the romance gen so

it's potential that games you know are are in fact the outlier in in Western media that you know due to a whole bunch of you know games are for kids, you know, Apple App Store game censorship, things like that, you know, you're missing things that other mediums people take for granted, you know, parts of the human experience that are just

there in other mediums.

So I noticed that some of the games that were created with Renpy are available on the Steam platform. And I'm curious what elements of the Renpy project lend themselves to producing games with enough polish to be published on such a mainstream platform. And also

as a secondary question to that, I'm curious if you have any sort of dual licensing on the project as a means of

getting some

remuneration for games that are actually turning a profit by using Renpy?

Okay.

First of all, I can take very little credit for the

output of the RunPipe community. We have some incredibly talented creators.

And, you know, at best, I can simply bask in in the reflected glory of those people. I mean, I I I make the joke a lot that, you know, if if they're Michelangelo, I'm the guy who makes Michelangelo's. It's paintbrushes.

You know, I can't really give you credit for anything that he did, but at the same time, it's great to know that my tool is being used for all this incredible work.

I do think Renphai

because it's a visual interactive fiction medium. And visual levels in general are but they're both interactive fiction, but they're also visual in a way something like a text adventure or, you know, a twine game

really isn't. I I think that that, you know, lend itself that, you know, you can fairly easily go into an app store. You can see a beautiful screenshot.

You know, the gameplay is now something people are quite familiar with. And, hence, you know, people are able to polish Ren Pie to make it look very good. And so I think that that leads to a lot of success on, Steam and and know, Itch and other stores like that.

As for remuneration,

right now, I've been doing ren pie just as a side project.

I haven't been asking for money, but we had some really generous people in the community

who have done things to support it.

We've had we've been the beneficiary of a humble bundle at 1 point.

Several of the other,

2 of the organizations have decided to donate money to the RemFi project.

So that's gotten it through

through, you know, 10 years and just, you know, being

you know, it's just it's been something, like, I found interesting enough, and being able to be part of these projects has been enough for me. I am considering

going ahead at some point and probably implementing some higher level tools, like a visual directory, directive director

tool that lets people insert pictures into their games interactively.

I'm leaning towards making that as sort of free for free games,

but pay for pay games

kind of model there.

It won't be particularly expensive, but, you know, it might bring something, some money

in. I'm not really in this to make money. I'm in this, you know, I really did like visual novels as a medium. I saw some incredible stories I found in visual novels.

I didn't know how to,

you know, do anything else useful other than program. But thankfully, I'm kind of good at that, I guess.

So,

so I was able to make Renpy and let the creative people

do that. And I wanna make sure that, you know, Renpy is used by a lot of people who have been traditionally

underrepresented

in gaming and programming

and similar things.

Last time we did survey,

renpai

was 60 percent women. We're also quite popular in in, you know, Southeast Asia. Our 2nd largest community is in Russia, where, you know, being able to transfer them in the United States is difficult. So I think it's very important

that Renphai

remain available for people in those countries

who

wanna use it because otherwise, you know, I I don't what I don't wanna be is a situation

of taking to somebody who can't, you know, who can't give me money and saying, no, you can't use Runpy to be creative since I think that's bad for

the world. Yeah. And it's definitely a very honorable stance to rely on the gratitude of others as a means of providing support to the project and otherwise just having it be a labor of love.

Thanks. And if anybody listening has a large grant, well, I'm not going to say no.

When you were mentioning the potential for a side project for dynamically inserting images,

it raised the question of how

assets

are

packaged together or how you how you manage the assets

while creating a game, and then also how you manage tying together different elements of the story line for the case where you potentially wanted to break it up into chapters or

manage the overall story line across multiple files. I'm curious how Renpy does that.

Sure. I mean, asset management, we pretty much leave up to the creator to decide something that they consider to be suitable.

You simply stick them in in the appropriate directory. You're allowed to use whatever data structure you want. It used to be you had to manually declare images, but in recent releases, run py will now actually do that for you.

And then when you go to distribute it will it will archive them together into just a simple archive file. It's not actually very good protection in practice DRM games, you know doesn't seem to work

in terms of like actually preventing people from getting at the assets

since you know all the information needed to run the game has to be there when you click go.

So you know trying to get on that, you know it prevents people from just casually

pulling stuff out, but, you know, there are tools that exist to pull stuff out. When it comes to scripts, really what we've decide what I settled on was simply

you're allowed to just break it up into multiple files however you deem convenient.

And then Renpy will parse all of those files by default into a single big namespace.

There's a construct called the label construct

which you can then jump to any label in the code.

And we don't care which file that label is in. So you are able to,

just jump between files using the label construct.

That goes back to run py being, like I said, 1 of the few non structured programming languages that are around nowadays.

So if you were just starting out today implementing RenPy, would you still use Python? And if so, why?

Probably, yes.

Pretty much the only serious competitor I could think of is JavaScript.

And

JavaScript actually has a lot of its own problems. You know, I like the fact that Python is batteries included.

Python standard library comes with tons of useful modules

that make writing something like run by and make, you know, rating games inside run by very useful. I mean, thing even things that you wouldn't think of like the zip file module which we use in distributing games

makes that and that's kind of stuff that's very difficult to do

in

in Python.

JavaScript, you know, the 1 appealing thing about that is that it does run-in the browser, which a lot of people want

despite it generally being like a fairly terrible place to play games

and and almost impossible to solve games for.

But, you know, I I don't think, you know, really JavaScript comes from the opposite where it's it's a minimalistic language

and, you know, you're talking about 3rd party libraries

to do it. You're also talking about, you know, well, if you want an actual interface, you have to log along the web browser, which, you know, Redmi competitor

bundles a copy of Chrome in with each download, I believe. That's the sort of thing that seems excessive. So the nice thing about Python is, you know, CPython,

despite the fact that, like, there's no cross compiled patch, so they might have integrated it. I haven't been following too closely on the Python 3 series.

But,

you know, it's it's actually, like, fairly written in fairly straightforward c code that's pretty small and runs just about everywhere.

And that means, you know, with a relatively small download,

like, I wanna say, the libraries we use to parse video, like like to play back video are actually bigger than Python itself. Or if not, it's close and, you know, the unicode tables are what take up all the space.

So,

you know, Python is actually a pretty good choice for

both a powerful language,

you know, 1 that is

1 that is simple enough. You can present it to even relatively unskilled users and they pick it up very quickly and at the same time it's you know portable distributable

a lot of other good things. So, yeah, I I think if I were to do run py again, I would be doing it in Python. Also, if I didn't use Python, I'd have to change the name.

That's that's awesome.

I'll definitely agree that having Python as the

scripting language that's exposed for people to add custom behavior,

I can definitely see how that would be much more user friendly than JavaScript. Because while it does have its own weird edge cases,

from my experience, there are more of them in JavaScript.

And there's more of an agreement in terms of coding style and best practice in the Python community than there is in JavaScript, which seems to

evolve its own styles and practices on an almost daily basis.

Well, and depending upon which camp you're in. Right? Are you a Node dot JS programmer or a or a React programmer or a an Ember or Angular programmer? They're all different.

I just wanna also say that I think it's awesome that you folks

have chosen

the relatively rich

and programming environment that the native platforms

give you.

I I think it's kinda really unfortunate that everyone feels this,

you know, intense drive

to cram the entire world

and every computing experience that we might might even ever want to possibly have

into the confines of a web browser. I mean, I understand it's a really capable platform,

but I feel like, you know, you can do so much with today's compute power on the average desktop or laptop or even mobile device for God's sakes. I mean, it boggles my mind when I take my iPhone 5

out of my pocket and think, you know, how much how insanely much computing power this thing has as compared with my first computer ever, my Atari 400 that I got in, like, 1980,

you know. So

I just think it's it's really unfortunate that that everyone feels like the web browser must consume the entirety of of our computing experience, and I'm glad Renpy is resisting that trend.

Yeah. I also think

1 problem with the web environment,

and it has a bunch of benefits, but 1 problem is simply preservation of games. Like there's a ton of actually very good games that were written in flash. I mean, there's a ton of not very good games are written in flash, but you know.

But and the thing is, you know, now that, you know, Apple is getting rid of flash, now that Adobe is saying, hey, there's a flash runnerability.

We think the best solution is free to uninstall it. You know, it's much harder to play those games.

By contrast,

you know, native apps, it's pretty common you can take a 10 year old native app and just, you know, bring it up especially on Windows and it'll just run.

And even if you can't, you know, virtualization of desktop platform just quite mature.

So I think, you know, interestingly, like,

once a game survives that first, you know, 10 to 15 year window, I think we're good enough at at either both virtualization

and simply backwards compatibility on the desktop

that you're not going to have

I mean, certainly that that games preservation

Is something that

you basically that the games will be preserved after

a certain amount of time, It is important to you know upload them to things like the archive and things like that to ensure that it survives those first 10 to 15 years.

And I think, you know, with visual novels

and games in general being a form of culture and a form of culture that's growing

more and more significant as time goes on,

spending effort to think about preservation now is very important to me.

Oh, I I totally agree. I'm I'm an avid retro gamer and and some of the younger folks that I work with kinda look at me like I'm kind of insane because I'm playing these, you know, Atari 8 bit games

on my ridiculous

high resolution monitor on my, you know, 4 core

Mac laptop.

But but I think that there is something there is a there is a real cultural experience there that is to be had for anybody to go back and sort of play the games that, you know, came that came out 20 years ago. Obviously, for those of us who who are old and old and crusty enough to have been there, it adds an extra dimension of of nostalgia.

But I think for anyone, there's there's

great experiences

to be had there, and I think, like, as you say, it it would be a real shame to have them

lost

just in the in the continuing,

you know, race

for,

I guess, to avoid obsolescence or whatever that technology seems to be stuck in, so that's great.

And I think, actually, the Renphai

project is 1 sort of great bulwark against that because

you folks, as you say, we've already got, you know, renpy projects that have, you know, withstood the transition from

PowerPC

to Intel on the Mac side, and I think that's that's gotta be, what, 7 or 8 years? I mean, what's your oldest project? Do you happen to know?

You mean supported project?

Yeah.

There's

the Moonlight Walks, which was the game I made,

that was, like, the first real game to come out. I've been continually updating it since, since it came out in 2005.

I don't

know what the oldest project that, you know, is still supported is. Just going back to Power p for see for a second, though, I actually have a pretty good story I couldn't resist.

I actually got in a message,

earlier this year

asking,

me to make a new release of the PowerPC

version of Renpy

because, it was a person who had been stuck in like Renpy 6 12, I think was the last version of supported power PC

to,

because, you know, it was just somebody who just couldn't afford getting a new computer that soon. It was a hand me down computer from somebody in in in the family.

So I did the simplest thing possible which was dig through my closet and just send her 1 of my old computers.

That is totally awesome. It seemed easier than than trying to get to figure out how to compile for PowerPC.

Absolutely. That is a great example of practicing random acts of kindness because now, you know, it's not even just Renpy. I'm sure if you're stuck on a platform like that that is no longer widely supported. She was probably running, you know, 10 years ago's version of Firefox

or Chrome or whatever the case may be. And are you even if I don't even know if Chrome produced PowerPC binaries. And so now she has a whole new world open to her, so that's that's very cool.

Yeah. Plus, I get some extra free space in my closet.

It also brings up an interesting point too about you're mentioning that you have a number of users from Russia and Southeast Asia,

and being in areas where

availability

of computers and

modern technology

isn't

as easy or

affordable.

Having a library like RenPy, for instance, that has been maintained for so long and does still

support

older infrastructure, you know, although not Power PC anymore. But having that capability definitely opens up a number of other possibilities to people who

don't have as easy access to those technologies.

Yeah. II certainly think it's it's important to keep the

the requirements of run as low as possible.

Just so that people who you know don't have you know access to upgrade their computer every couple of years.

Can still you know make games and you know make games that people around the world can play.

And so before we move to the picks, are there any questions that we didn't ask that you think that we should have or any topics that you wanna bring up?

No. I think we're pretty good. And are there any particular areas in Renpy that you would like to support on?

Well, I'd certainly like to work with the larger Python community to get some of our packaging technologies

and, you know, potentially try and figure out how to

get things like how we build for Android. How we build for.

Ios and and get that to the point where at least other pie game games. If not, you know, other Python programs in general,

you know, I think it's really important that the run pie launcher, which has this 1 quick build environment,

is able to eventually at some point package other games in in a similar easy manner because there are all these genres out there, why shouldn't we be using Python to make games?

Absolutely.

You might consider talking to the to the Kivy folks because I think they actually are maintaining some of the projects you guys are using. Right? Like, at least on the Android side, if not in the iOS side as

well. You might, you might be able to recruit some some,

potential

allies there or at least get pointers to where you might find them. Yeah. I know that they have a library called Buildozer,

which is their tool chain for

for compiling their applications to run on the various platforms.

That's correct. It's actually based on the very, very now they've done a ton of work beyond this, but I believe that at least originally, it was based on some of the the very old run by Android packaging stuff.

It's interesting how all these things tie together.

Alright. So with that, we will move on to the picks. And for my first pick today, I'm going to choose DJ Logic. He's a DJ who produces sort of a mix

between techno

and instrumental hip hop, and it's just good music to listen to while I'm coding. I find it really useful for sort of listening to as a way to tune out the outside world and focus on the work that I'm doing.

My next pick is a set of command line tools that I came across recently called git tools, which is just a number of different

shell aliases

that

simplify working with git commit trees.

Just found it really easy and useful to use.

And my last pick today is a Python library called radon, which is a way of generating a number of different statistics of your code base, including things like lines of code, complexity.

It will show

you a number of different other statistics, like some of the

pilot statistics.

And it's just a nice way of generating a lot of interesting information about your code base. And they actually have a

corresponding library. If I remember correctly, it's called Xenon, which is intended to be run run on your CI server to generate those same statistics.

And with that, I will pass it to you, Chris.

That sounds really neat. I think we have some some, some people at my place of business that'll be really excited about that. Thank you.

My first pick is a,

Netflix original TV series that my wife and I just started watching, but are really enjoying called Narcos.

And

this is a really interesting story of

Pablo Escobar's

rise to power,

becoming the, you know, cocaine king of Colombia.

And what's what's doubly interesting about it aside from the obvious is

how, you know, at least just the way they're depicting it, how he sort of utilized the corridors of power

and how American interests

reacted and why they reacted. It's just it's it's a really good story. I'm really enjoying it, and,

it's it's good good good TV entertainment.

So I my link is to the Rotten Tomatoes review of it, and I think it's it's kinda interesting in telling that the critics give it 75%,

but users give it 91%.

Apparently, it's, it's it's not not highbrow enough for the critics, but we like it. My next pick is the Rust programming language. I have been playing with this, over the last week or so, and it has been kind of a revelation for me in that,

I, you know, I've used C and C plus plus

actually a fair bit through the years, but it never seemed to really stick. I've even done it professionally for a while, but it's never been a real tool of choice.

And Rust, which builds code that executes at or or

very close to C and C plus plus speeds,

is just

it's a joy to use. It it is as pleasant to use as any number of higher level of abstraction languages.

It it takes a really new tack to problems like concurrency

and memory allocation.

And so far, it's just it's a real joy to use. They've really thought this 1 through in terms of of,

building it and designing it, and I think people should go check it out, even if you're like me and you're sort of like, I don't do, you know, low level code like this.

And it's also been integrated very heavily into, you you know, you can you can,

write code you need to perform,

you know, better

in more quickly.

You can embed it in Python programs, Ruby programs, dotnet programs.

It's really it's it's impressive stuff. And it is somewhat early days still, but I think,

people should at least, you know, give the tires a kick. I think you might be pleasantly surprised.

My last pick is a beer,

because I went to a beer tasting festival a couple of weekends ago with my lovely wife and a good friend,

and,

this 1 made the biggest impression on me. It's from, a really small brewery called Kent Falls Brewing, and it's called the

shower beer.

And, what's really kind of unusual about it is it's a goes made with lemon zest.

And you taste this beer and it is a

massive hit of lemon to your face. Like, it's it's seriously pucker worthy. And it's act but it's actually,

kind of also related to a wheat beer, so you then get that sort of, you know,

wheat beer flavor on sort of the on the the the backside.

It's really tasty, really refreshing stuff. I would definitely

enjoy some of this, you know, on a hot summer day after having done physical labor. And, that's it for me for picks. Tom, what do you have for us?

3 things. First off, I just wanna thank the Cython programming language,

which is a language that's used to make Python extensions.

It lets you

write Python style code, but that code can both be called from Python and call Python, but it can also call into C. And also you can add c style type annotations to a language

which lets that code run as fast as c.

What's very useful is actually a feature of the dash a option, which produces an HTML document for each line of your program that lets you see what code it's producing.

And it'll actually color the lines in letting you know, you know, this is adding 2 Python integers together. So it's a sequence of function calls versus this line is adding 2 c integers together, which means that it is very fast.

My second pick is the NPR 1 app, which is a sort of like Pandora for, like, news and other factual content. Basically,

put it on your phone or you can listen to it on the computer and it picks, you know, stories out at random, both news

and, like, other sort of, like, economics and other interesting stories.

And my 3rd pick is the Seinfeld method, which is a sort of life hacky type thing,

which is simply a way of motivating yourself to get things done. You simply decide what you wanna do. You get a nice big yearly calendar or other big calendar. And then every day you do something, you get out a big magic marker and you put an x through that day.

And after a while, you start getting some streaks together

and, you know, the motivation that well, do I really wanna break a 2 week streak of doing something

is enough to,

to get you to, like, get started on something in a day when you might have said, ah, whatever.

GitHub actually has a streaks feature that is also very useful for this

sort of thing. Alright. Well, we really appreciate you taking the time to join us today and tell us all about renpy. So for anybody who wants to follow you and keep up to date with what you're doing and the work on Renpy, what would be the best way for them to do that?

Probably the best way is just going to our website, which is renpy.org,

re npy.org.

There's links there to various social media.

Following me directly on Twitter will let you find that about the latest in Renby, but also let you find it about also to other things I find interesting, which you may not. But, certainly, the Renby website has all the downloads and the announcements and so on. Do you mind giving us your Twitter username for our listeners? Sure. It is, Renpy Tom, r e n p y t o m.

Alright. Well, we really appreciate you taking the time, and I'm sure all of our listeners will be very interested to learn more about renpy and its history. So thank you again, and I hope you enjoy the rest of your evening. Thank you very much for having me.

Thanks. Bye bye.

The Python Podcast.init

Summary

Brief Introduction

Interview with Tom Rothamel

Picks

Keep In Touch

Links

The Python Podcast.__init__

Summary

Brief Introduction

Interview with Tom Rothamel

Picks

Keep In Touch

Links

The Python Podcast.init