The more you talk about it, the more I'm confused about what you want to do.
Hmm... I thought rather about live preview during coding without need to jump LABEL_OF_ACTUAL_SCENE.
Live preview of what exactly ?
You say that your tool will be in Python 3, what imply that it will be totally independent of Ren'py core, or don't come before probably a year, if not more, since Ren'py is in an hybrid state in between Python 2 and 3. While it can now run Python 3 code, it still can't be ran by a Python 3 interpreter.
Therefore, do you intent to rewrite every single bit of Ren'py by yourself, or do you intent to simply describe what would be shown if the code was ran under Ren'py ? And in top of that have an embedded Python 2 interpreter in order to process the Python code that can be embedded into the Ren'py one ?
I mean, if the code looks like:
Code:
layeredimage annie:
always:
"character/annie/[tatoo]/body.png"
group head:
attribute neutral:
"character/annie/head/neutral.png"
attribute happy:
"character/annie/head/happy.png"
attribute sad:
"character/annie/head/sad.png"
attribute surprised:
"character/annie/head/surprised.png"
[...]
label whatever:
scene livingRoom
show annie neutral
a "Hello boy, what do you want ?"
# Will use the alternate menu screen named "hintMenu", and show it
# in the left on the screen, on the upper middle of it.
menu( screen="hintMenu", x=100, y=500 ):
# The choice will be sensitive only if her /like/ value have the right value,
# but still be displayed in order to show the hint when her /like/ value is
# lower.
"Go to a date"( hint="You need at least 10 like for this", capValue=10, capAttr="a.like" ):
show annie happy at jumpyJump
a "I'm so glad"
jump annieDate
"A blow job"( hint="You need at least 15 love for that", capValue=15, capAttr="a.love" ):
show annie sad
a "Is sex the only think you want from me ?"
jump annieBJ
[...]
What will your preview show ?
Do you intent to rewrite all the layered images code, in order to be able to display them, then to rewrite the transform code, in order to show them, before rewriting all the menu code, in order to be able to handle the optional arguments, and finally to rewrite all the screen code, in order to be able to display the screens as they are effectively designed ?
Or do you intent to display something that will be more on the side of "here, you'll see an image that I can't display, with a transform name 'jumpyJump'", and other, "here, there's a menu that would looks like this if you haven't changed the 'menu' screen and didn't used too advanced features" ?
Therefore, like I asked, what this feature of your tool would add to what Ren'py already have ?
It seem that you didn't understood what I said when I talked about the combination
jump, rollback and
shift +
r.
The key combination turn Ren'py into "automatic reload" mode. This mean that each time a rpy file will be updated (and this update saved), Ren'py will automatically reload the script, letting you show immediately the effect of the changes you made.
This is the live preview of your tool, with the guaranty that what you'll see will be what you'll get, since it's done by Ren'py, and so handle all the features of Ren'py language.
Additionally when developer would want to preview other scene then there would be possibility to select particular scene (from scene list) and click, e.g. button "preview scene".
What they can do, I admit it less intuitively, by opening the console and jumping to the scene. And, unlike with your preview, while they are in the console, they can tweak the variables, because they want to see a particular variation of this scene.
Keeping my example above, they'll be able to test the scene with both a "like" value below and above 10, and a "love" value below and above 15. What, in your tool, would imply to pass by an additional input windows asking what variable have to be changed, what should be its new value, then if the user want to change another value or not.
In the end, it wouldn't be really easier than using the console, just more visual.
For serious, there would be small advantage compared to cruncher - conversion is still the same process but I thought about:
- support for additonal file types from/to convert
What file types, and for what reason ?
2D games don't really need a tool like cruncher ; a whole game is generally smaller than a single update of the average 3D game. And 3D games will have to deal only with PNG and JPEG files.
Hmm... in this example in label whatever( char ): I would be tracking how many times call expression is called and let developer to add nodes to existing blocks from these two call expression.
I think it's the best method (for such complex parts of scenario) because it's very easy to overlook something from perspective of tool developer.
And therefore your flow chart would be at most as intuitive and understandable than just looking at the code itself :/
It would tell what label is possibly called from this place, what can already be known by looking at the code, and tell from where a label could possibly be called, what any grep tool already tell.
Try to think that this would be collection of tools (implemented from scratch, using libraries if needed) merged into single GUI application.
If there's something that my 35 years of coding, among which 25 doing it professionally, taught me, it's that merging tools for the sole purpose to merge tools only lead to hell, loose of knowledge, and final confusion.
It doesn't mean that your tool wouldn't be a good addition to Ren'py, and even less that it isn't needed, but you make me think about this quote of Nicoll Hunt, "the first step of any project is to grossly underestimate its complexity and difficulty."
If I have an advice to give you, it's to forget about a Python 3 independent tool.
What Ren'py need isn't that someone, you this time but you aren't the first, reinvent what Ren'py can already do, but that someone add what Ren'py is missing. And the best place to do this is in Ren'py itself.
Look at Ren'py core, learn its internal. And instead of having an external tool that will only be able to show a rough and raw preview of what would possibly, under many conditions, be what the code do, the user will have a key combination opening a menu-like in Ren'py letting him click on a label name and immediately jump to it for testing.
And by doing so, you'll see a lot of other tools that could be useful. Having access in real time to Ren'py and to the context, you can have a live branching map for the current label. Showing it in a "watch" way ; a list of the labels that can be reached from this label at this exact instant. And I mean the real labels, even when they are expressions. All you need is to learn how Ren'py AST is built, or to tweak the classes that can branch, adding to them a "labelPreview" property you can interrogate at any time, and display their value. The author would have the information in real time, "interaction" by "interaction", knowing precisely at what moment his code goes wild and wrongly changed the name of the label.
A little more work, and you couple that with
renpy.has_label, showing in red all the labels that don't exist, making the author see in real time that "this context" break his game.
Look at the return stack, and you can tell to the author what path led him to "this label", letting him understand what gone wrong even if the said path include labels that branched without interactions.
There would be limitation, user defined statements and renpy equivalents would goes below the radar of your tools. But if someone use one or the other, he's expected to know a minimal what he is doing, and therefore be able to debug his code by himself if it's needed. Anyway your tool would still be useful for 95% of Ren'py users.
This is the kind of tools that Ren'py need, the kind of tools that would really make life easier for anyone who works with Ren'py. And by anyone I include the modders and walkthrough authors.
We pass time loosing our time, by trying to make tools for Ren'py that aren't needed. I don't remember his pseudo, but the guy who's working on the local version of unrpyc, passing time to make it works with tweaked version of the rpyc format in order to counter the obfuscation attempt of some authors... Or me, who made a standalone tool reverting the said obfuscation. All this when we could just branch unrpyc code into Ren'py, and therefore have it working fine whatever the attempt to obfuscate the code...
Same for rpatool, that we tweak to add this or that variation, when we can have, with two dozen of lines, a tool that would works directly from Ren'py, and therefore works whatever the said variations.
