RPMT

[ErogamiDear]

I need your help on this issue (sorry me if I'm wrong, I'm a good programmer but a completely newbie in the ren'py community) Ren'py don't have a package manager, so the user needs to manually import and manage their plugins and templates on ren'py. And that's a big problem! Think like a non-programmer user trying to import multiple packages in a single ren'py project. It's very hard to mix them together or copying them every time you start a new project. It's also hard to add new ren'py statements (for use in a high level rpy script) and to implement things without modify the renpy core itself (another time, sorry me if i'm wrong).
I'm studying the ren'py documentation and source, and have a long list of projects to do in this program. If you have any question about how works a package manager (i hope not) you can study a lot of managers implemented in other python programs (for ex. Blender, Inkscape or Python itself. That's what free software is made for!). But here is a few tips:
- Set a standard packages folder (fex: renpy/custom_module)
- Make sure to register all modules at some point when renpy start.
- A 'import' or 'plug' statement is needed to use it in rpc scripts. (fex: plug aileen)
- A piece of code to check duplicate statements definitions in custom modules (easy, right?)
- And a tool in the launcher to manage and search updates for the installed modules.
And that's all. Working with packages erases the need to modify ren'py itself. So you can work safely in the core while the community works in plug-ins and a lot of more functionality for ren'py.
See you.

[xavimat]

I'm trying to imagine the utility of this.
Pro:
- For example, you could import in the launcher (from a repository) the DSE, the dungeon crawler, inventory systems, combat systems... and other examples currently in the cookbook section. And then use them in your game without modifying them.

Con:
- I'm not sure if downloading the same thing from the cookbook and copy-pasting the rpy files in my project manually is so difficult for the average developer to justify the workload of the package system. (I mean, do I understand what this package system will do? It simply will download the files and paste them in your project, right?)
- The examples you provide (Blender, Inkscape or Python itself) work on another level. There is a community of professional programmers behind them (only professionals, only programmers, dozens of them), that take care of the updates.
Look at the cookbook: there are a lot of outdated examples, pieces of code made by people not longer in the forum, parts that currently don't work, and code that works but with old conventions supported only for legacy reasons (lots of screens still don't have the parenthesis in the definitions, for example). There are also suggestions made by non-programmers like myself (I can suggest examples for the cookbook, I've done it, but I'd never dare to upload a real "plugin", I'm not so confident in my coding skills).
So, my thought is that the renpy community is not able at the moment to maintain updated versions of the "plugins".
Maybe I'm wrong, but I can offer an example that does more or less what you say: the renpy translations. Renpy comes with a lot of translations, but most of them are not updated. I'm one of the Spanish translators myself, and sometimes help Italian people to translate theirs. It's easy to get some time to translate renpy, send the translation and that's it; but it's not possible currently to ensure that translations are constantly updated. With translations is not really a problem, any non-translated string shows in English, and the developer can solve it. But "plugins" need to be updated more often simply to "work".
What would be the default policy with every new version of renpy?
- Maybe disable all plugins that are not explicitly tested with the new version? (And then, developers need to test and guarantee that they work).
- Maybe let the plugins in the list, even if they could be broken? (so renpy will promise a list of downloadable plugins that don't work and nobody knows).

I'm not saying the idea is not interesting. It is. But I'm not sure if the current renpy community can make it work. How many of the cookbook examples are currently maintained?
Still, maybe I'm wrong and Renpytom thinks it's a good idea.

EDIT: On the other hand, you talk about changing renpy itself. I've never needed that.
Renpy has a very specific purpose; changing the core of renpy could mean that you need another tool for what you want.

[gas]

You miss a point.
What "plugin" are you talking about? Nothing like python independant modules to add.
There are just releases. Frequent releases of the whole core at each improvement as a whole. Go look changelogs.
Got good stuff that fit the core engine? Talk with PyTom and have that stuff released as part of the core.
If they can work with actual core, release them as scripts alone.
That keep the system consistent and give a reference for everyone.
Renpy being an end user app, 99.99% people don't mess or even need to know the core. The one you're calling is a critical change that probably is not working the effort.

[Human Bolt Diary]

A package manager would be a fairly large amount of work. While it would be interesting to download packages and be able to manage versions, I don't see enough people making and updatings add-ons to make it really necessary.

As far as imports or a specific plugin system, it's largely unnecessary due to how Ren'Py scans files. There's also no module scope for .rpy files, so dumping in files without knowing what's in them can lead to unforeseeable conflicts.

However, when there is code you want to use in multiple projects, the lack of any plugin system does mean you need to copy and paste the same files over and over again, with no way to keep them versioned. To that end, I hacked together a lightweight plugin system for the launcher that I've been using for a few weeks with general success. A designated source directory contains subdirectories which are considered plugins. Each plugin can be installed to a project, which just means copying the files from the source directory to a directory called "plugins" in a game. Doing this lets me keep the source directory as a point of truth, and makes replacing out of date files easier. In the attached screenshot, the installed plugins are for a specific game, the available plugins are whatever's in the source directory, and the metadata is a dump of a metadata.json file that's in each plugin folder.

[PyTom]

I think the problem is that it's not completely obvious what packages / plugins would look like.

The problem is that in the Ren'Py world, it's pretty rare to have reusable components, as the components tend to integrate very closely with the game proper. This is different than in python, where you have modules that generally are invoked, and then return. One of the insights that lead to Ren'Py is that unstructured programming is the way to go for a visual novel. Most programs have functions that are called many many times. In a visual novel, that's rarely the case, since you generally want to avoid repetition where possible.

But I could be wrong! I'd love it if there were more reusable components for Ren'Py games. I think it probably makes sense to come up with an informal standard (packages should contain these files), and the packages first. If you take a "if you build it they will come" approach - creating the tooling, and then hoping people use it - I think it's unlikely to get adopted.

[Human Bolt Diary]

In terms of what makes a good plugin, looking at the cookbook there's generally 3 types of posts:

- Tutorials
- Code snippets / Examples
- Additions / New functionality

The difference between an example and new functionality can be vague sometimes, but what seems logical is to define a plugin as an isolated file or set of files that can be dropped into a project.

A metadata file would would be recommended, but optional. Personally, I'd use JSON or YAML as the data format. For the content, a set of common attributes can be defined in some documentation (ie: name, version author, description, license, etc) but should remain optional.

The goal is to provide users with a better way to track what they've put into their project, as well as provide a way for plugin creators to provide information to their user base.

Having a dedicated website to pull plugins from and display them in the launcher as available for download would be neat, but I think focusing on that is putting the cart before the horse.

One interesting thing that comes to mind is how this affects Ren'Py's development. Are features such as the Gallery and Music Room better served as optional plugins? What about NVL mode? Do we define a "standard plugin library" that's downloaded with the SDK, but must be added for each project?

General concerns I have:

- Load order and monkey patching. ie: User wants to call function B in Plugin A inside an init -1500 python block, but Plugin A only defines function B in an init -1 python block. Hilarity ensues.

- When removing the source plugin, what happens to the installed plugin? ie: User deletes Plugin A from their source directory. Plugin A was installed to Game B. What happens to the copy of Plugin A inside Game B?

- Discourage modding the installed plugins. If people start altering plugin files installed to their project, they'll be in for a bad time if they ever want to update. We can't/shouldn't stop users from doing this. The easiest way to discourage them is to have installed plugins exist outside the "game" directory, and only be packaged up when the game is distributed. ie: Place installed plugins in "project_name/_plugins" instead of "project_name/game/plugins"

- Dependencies. Ie: Plugin B depends on Plugin A being installed.
How does the maintainer of B:
- Inform users of the requirement?
- Resolve that requirement?
(Personally, I'd use the metadata as a way to place dependencies, then have the launcher alert the user if they're missing.)

[ErogamiDear]

Ren'Py is a great Visual Novel engine. It has all we need to make Visual Novels, and the CORE is this part. The part that leads Ren'Py to run Visual Novels.
The other part (extensions) are not necessary, but helps the user to do specific things the core does not support (not directly related to Visual Novels.).
For example, RAPT is an extension, because the core don't need it to run Visual Novels (but the user can use it to make android packages).

By default, there are two types of extensions:

- Internal: Required in packages. Works in-game, like screen libraries or minigames.
- External: Not Required in packages. Works in the launcher or doing something externally, like the Director.

Maybe it's normal that you are havin troubles understanding my words. I'm an 16 years old autodidactic programmer, and i've worked before in plug-ins and libraries for Blender, Gimp, Inkscape, Godot, and Python. I'm interested in Ren'Py because i'm making my own games in this engine and see there is a lot of functionality the engine does not support. Some people just say me "Ren'Py is a Visual Novel engine, if you are searching other functionality just kick off and search other game engines", but i don't want to do that!

This is an incomplete list of my (under development) extensions:

Internal - WasDaRend (0.8.0):

A library of render functions to complement the default render abilities of Ren'Py. I start this because an user is asking about a blur feature in Ren'py.

Internal - RenKey (0.6.2):

A Keyframe based animation system. Designed to make layered animations, per frame animation and event timing, and to import-export animations you have created in other programs (like Flash, Godot or Blender). I'm not sure if it's better to append this on the core or allow the user to export RenKey animations as an ATL sequence (a hard work).

Internal - DateSim (0.1.0):

It's a library with a lot of classes and methods (and screens) to implement Dating Sim in ren'py.

External - WISIWIG Screen Editor (0.0.:

A visual tool used to edit and manage screens in a very intuitive way. You can edit the look and behaviours of your screen and export them in a RPY file. Right now, it supports a basic way to make ImageMaps, Buttons and simple Menus. This extension requires comunication with the core, that's why i'm asking this issue.

All of these modules works well on python (3.2). But, actually does not work in ren'py.

If you want so see the source (and docs, if available) of these projects, you need to wait a bit more (maybe RenKey and DateSim are ready for release, but the other two are waiting for some optimization and Ren'Py support before release).

[trooper6]

In case you don't know, Ren'Py is based off of Python 2.7.
That knowledge may be helpful to you.