Ren'Py Roadmap

[Wintermoon]

EDIT: I recommend the following

Code: Select all

darkPerson says:
   Haha...
   I will hurt you all.
   Eat candy evildoer!

I prefer the following:

Code: Select all

darkPerson:
   Haha...
   I will hurt you all.
   Eat candy evildoer!

"says" is wrong on two counts. It's redundant, and it's not a non-imperative verb used as a command.


That said, I don't have a problem with Py'Tom's monologue syntax.

[delta]

The only problem with what you propose is when you have speakers changing too much. I may not use as many quotes but I'll be writing "@speaker" waaaaayy too much. I'd rather type two quotes than type that every time.

That is because you assume that every game is in ADV mode, like apparently the vast majority here. For NVL blocks, where you have scene long monologues, this becomes useful very fast.

Okay, if @speaker is too much, how about having a special control character that basically means "speaker"?

Code: Select all

@e
This is the first say statement.
This is the second say statement.

@
This is a different say statement (spoken by the default "narrator" character).

@darkPerson
Haha...
I will hurt you all.
Eat candy evildoer!

;show eileen happy #etc.

Basically, in this example, "@" would be an alias for ";speaker ".

[Counter Arts]

Yeah... one character is fine. You don't really need the "says" part in the syntax. That's just flavour to attract programming-averse people to how english-like the syntax is. You can make it optional.

Remember... think of the non-programmers! And nothing is stopping you from aboslutely just using one character only if this path is taken.

EDIT: Also having indented blocks just let's you skip adding the ";" before each thing that happens.

[PyTom]

I still like the quotes/newline based approach I gave before. For one thing, it means that scripts that are currently valid remain so, in all non-pathological cases. I also like the quotes because it feels appropriate as a way of indicating that the person is saying something, in the same way dialogue is quoted in books.

[F.I.A]

While I admit my tinkering with nvl-mode is somewhat less(A little in Winter Shard and stuff), I don't see the hassle it takes to include quotes on texts. It is pretty much common in writing dialogues as PyTom stated.

(And I thought Ren'Py is made of python anyway?)

[Jake]

(I will just note that the indentation/education anecdote PyTom linked to goes totally against my experience with teaching various different people programming and the kinds of questions people come up with when learning Python/Ren'Py, but since he's dead against changing it it's a pretty pointless thing to discuss anyway.)

I don't see the hassle it takes to include quotes on texts. It is pretty much common in writing dialogues as PyTom stated.

It's not used at all when writing scripts for performance, though; plays, screenplays, comics, whatever - none of them use quotes. And that's a common advertisement for Ren'Py's ease-of-scripting: "it's just like writing a screenplay". Quotes are used for dialogue in prose, but nowhere else that I can think of off-hand.

And I thought Ren'Py is made of python anyway?

And as I understand it Powerpoint is written in some dialect of C, but you don't need to even know that to create Powerpoint scripts, let alone know any C programming conventions or syntaxes. Just because Ren'Py is built on Python doesn't mean people have to have Python inflicted upon them where it's totally unnecessary.

If there is a thing wrong with Ren'Py which prevents it from being easy to pick up for newbies, it's the same problem that Novelty had which made it so hard to add a dialogue text box - it tries to be too generic for 99% of uses, and the genericness intrudes too far upon the most-common use case.

PyTom:
If you're coming up with a new RPY format, which isn't used by default unless you explicitly switch it on, then surely you can do what you like with monologues in that format and all existing scripts will still work fine, because they'll be parsed using the old rpy-(or 6, or whatever it is in truth) parser? (I don't see why introducing a 'speaking' block or whatever would mean the parser would no longer be able to read old scripts anyway, but that's somewhat beside the point...)

Secondly - if you're changing the format, isn't sticking a switch in the script file/options.rpy a really clumsy way to choose between one format or the other? Why not just make .rp2 the extension for new scripts and parse by one parser or another depending on what the file extension is?

[F.I.A]

It's not used at all when writing scripts for performance, though; plays, screenplays, comics, whatever - none of them use quotes. And that's a common advertisement for Ren'Py's ease-of-scripting: "it's just like writing a screenplay". Quotes are used for dialogue in prose, but nowhere else that I can think of off-hand.

Perhaps my memory is rather blurry, but I don't recall I am drawn to Ren'Py with that sort of advertisement.

And as I understand it Powerpoint is written in some dialect of C, but you don't need to even know that to create Powerpoint scripts, let alone know any C programming conventions or syntaxes. Just because Ren'Py is built on Python doesn't mean people have to have Python inflicted upon them where it's totally unnecessary.

Problems with this comparison are that Powerpoint is the one that has built-in user friendly commands, while you cannot really just make some games with a few clicks using Ren'Py( The template does not count.)

And while we can pretty much make a simple game using Ren'Py without much knowledge on python, experiences tell me that more complicated scripting require some knowledge of it.

If there is a thing wrong with Ren'Py which prevents it from being easy to pick up for newbies, it's the same problem that Novelty had which made it so hard to add a dialogue text box - it tries to be too generic for 99% of uses, and the genericness intrudes too far upon the most-common use case.

This is from a guy who cannot do something decent on most engines he came across( Be it 3D Studio Max, MUGEN[ Not that "supposedly" handsome long haired], Flash Macromedia. The list goes on). And as far as I can tell, Ren'Py is simple enough not to make me pull my hair. Not only that it has a rather complete wiki to refer to, its creator is also one that is helpful.


======================================================================

Code: Select all

speaker e:...
...This is a different say statement.

And from what I see, such approach will only mean one problem - More indentations. Example stated below( If I am to code):

Code: Select all

label start:
    if start1:
        speaker e:
            This is the first say statement.
            The second.
            The third.
            The fourth.
            The fifth.
        if lucy:
            speaker e:
                Lucy was here
            jump lucyroute
        else:
            speaker e:
                Jump to first route now!
            jump eileen1
    else:
        speaker e:
             You haven't come across 'start1'.
             Now you will.
        $ start1 = True
        $ renpy.full_restart()

Know what I see? Eyesores. I for one thing do not enjoy too many indentations on my script. Give me the usual any day please.

Code: Select all

label start:
    if start1:
        e "This is the first say statement."
        e "The second."
        e "The third."
        e "The fourth."
        e "The fifth."
        if lucy:
            e "Lucy was here."
            jump lucyroute
        else:
            e "Jump to first route now!"
            jump eileen1
    else:
        e "You haven't come across 'start1'."
        e "Now you will."
        $ start1 = True
        $ renpy.full_restart()

[Jake]

Perhaps my memory is rather blurry, but I don't recall I am drawn to Ren'Py with that sort of advertisement.

Maybe not, but it's a thing which has been said about Ren'Py, and it is the case that the script more closely resembles a screenplay than anything else.

Problems with this comparison are that Powerpoint is the one that has built-in user friendly commands, while you cannot really just make some games with a few clicks using Ren'Py( The template does not count.)

I think you're missing my point - just because Ren'Py is written in Python doesn't mean that it has to follow Python conventions or syntax. It does so for convenience, and specifically for the convenience of PyTom and of people wanting to do advanced things with it.

But most users won't be doing advanced things with it, and most people doing advanced things won't actually typically be spending more than 10% or so of their script doing those advanced things, so from a usability point of view it's silly to make that the primary driver for the way the scripting language is put together.

If the integration with Python wasn't so fast and loose, it would be an order of magnitude more feasible to write a GUI tool which allowed you to edit Ren'Py games, making it just as easy as Powerpoint. The main technical problem with writing such a tool is the parsing of the script files, and Ren'Py script is a very limited and easy-to-parse language compared to full-blown Python. The fact that Python can be interleaved with Ren'Py - and needs to be, in some cases - is the main thing stopping the creation of such a tool, as far as I can see.

And while we can pretty much make a simple game using Ren'Py without much knowledge on python, experiences tell me that more complicated scripting require some knowledge of it.

Sure. But anyone doing more-complicated scripting is going to need to learn how to program anyway - I'm not talking about them.

And from what I see, such approach will only mean one problem - More indentations.

Why is it not possible to allow both forms at the same time?

[F.I.A]

I think you're missing my point - just because Ren'Py is written in Python doesn't mean that it has to follow Python conventions or syntax. It does so for convenience, and specifically for the convenience of PyTom and of people wanting to do advanced things with it.

Pretty understandable. This I will agree...

But most users won't be doing advanced things with it, and most people doing advanced things won't actually typically be spending more than 10% or so of their script doing those advanced things, so from a usability point of view it's silly to make that the primary driver for the way the scripting language is put together.

As for this one, while this could be applied for most vns around here, there are still genres like simulations which will involve some amount of gameplay enough to benefit from the scripting engine.

If the integration with Python wasn't so fast and loose, it would be an order of magnitude more feasible to write a GUI tool which allowed you to edit Ren'Py games, making it just as easy as Powerpoint. The main technical problem with writing such a tool is the parsing of the script files, and Ren'Py script is a very limited and easy-to-parse language compared to full-blown Python. The fact that Python can be interleaved with Ren'Py - and needs to be, in some cases - is the main thing stopping the creation of such a tool, as far as I can see.

I guess that is what Novelty is trying to achieve - to have a GUI tool of sort for easier game making...

Sure. But anyone doing more-complicated scripting is going to need to learn how to program anyway - I'm not talking about them.

Agreed, however, if I am to give comparison between Ren'Py and python, Ren'Py is the processor I can make things with as long as I know how to, while for python, I still need to build that processor from scratch first.

Why is it not possible to allow both forms at the same time?

This is more of PyTom's decision, though I wonder if more choices will actually complicate new users more.

[Counter Arts]

I think you're missing my point - just because Ren'Py is written in Python doesn't mean that it has to follow Python conventions or syntax. It does so for convenience, and specifically for the convenience of PyTom and of people wanting to do advanced things with it.

I believe PyTom said along the lines of "They did research studies about how to make Python as easy to learn as possible." So I guess he's just been using similiar python conventions because the research has already been done?

If the integration with Python wasn't so fast and loose, it would be an order of magnitude more feasible to write a GUI tool which allowed you to edit Ren'Py games, making it just as easy as Powerpoint. The main technical problem with writing such a tool is the parsing of the script files, and Ren'Py script is a very limited and easy-to-parse language compared to full-blown Python. The fact that Python can be interleaved with Ren'Py - and needs to be, in some cases - is the main thing stopping the creation of such a tool, as far as I can see.

Well here's the thing... the user doesn't need to be as visual unless he is doing the advanced stuff. Powerpoint is far more visual than creating a visual novel. For the basic stuff it is all text and putting the right files in the directory. I think writers are generally used to heavy text files in one form or another. They probably know and are used to using the "Home" "End" "Ctrl+arrow" keys and clicking around a gui runs the risk of being clunky to them. "How do you insert something inbetween these two other things in the order of events?" wouldn't be asked for example.

[EwanG]

My .02 worth on this bit is that having programmed with Flash (which is about as visual a tool as you can get to build VNs and other games), using PowerPoint frequently at work, and using RenPy on an almost daily basis now - is that of those three tools I find RenPy the easiest to use as a game platform. I wouldn't try writing my "Santa Slays" program with it, but for non-arcade games, it's the best.

Why? Because I can write the dialog, and be 3/4 of the way to having my program done - particularly if I have some graphics already setup so I can add in the cut and paste of the show or scene. While PowerPoint and Flash make it much easier to put things on the screen and arrange them the way you'd like, the reality is that most games are about storing and manipulating state (where am I, what branch am I on, what are the values of things I need to know) rather than showing visuals.

Yes, I'm interested in certain things that I'd like to see added to make my "job" (I hope someday) easier. But that is going to be somewhat based on how each of us comes to the tool, and our past experience. Personally, I'd love for RenPy to add the ";" to show the end of the statement. But I know better than to ask for it because the reality is that the use of it is a habit from Java and C, not something that would actually add much to the usefulness of the language.

I wonder if, having gotten a fair number of suggestions by now, if it wouldn't be best to run a poll and have folks vote with their electrons for the things that are most important to them. I suspect that some of the things we're discussing are useful, but not that important.

OK, I have writing to do, so I'll get back to it.

P.S. - Finally broke down and ordered an iPod Touch 2nd Gen (8 gig) today. So if PyTom needs another tester for the future version on the iPhone...

[Jake]

there are still genres like simulations which will involve some amount of gameplay enough to benefit from the scripting engine

Seriously - I'm not advocating getting rid of Python altogether. Not at all.

I'm advocating getting rid of in-line Python, formalising the interface between Python and Ren'Py code, such that it's entirely possible to write a 'normal' Ren'Py script without writing a line of Python and such that the Python code is mostly separable from the Ren'Py code. You'd need assignment and arithmetic in Ren'Py script at the very least. This wouldn't hurt the programmer's ability to write simulations or other advanced Python-based code... in fact, you should be able to do a simulation entirely in Ren'Py script if this got done, albeit without a fancy UI.

I believe PyTom said along the lines of "They did research studies about how to make Python as easy to learn as possible." So I guess he's just been using similiar python conventions because the research has already been done?

Actually, I get the distinct impression he's using Python conventions because Ren'Py was originally just a Python API for writing VNs with, scripts were written entirely in Python, and it's only evolved its own scripting language over time. But I could be wrong.

Python might be a fine language for learning programming, but 90% or more of all VN use isn't going to need a fully-fledged programming language, it just needs enough functionality to do menus, jumps to different parts of code based on variable values and displaying text and images. It's a different use case to Python, so there's no sound reason to presume it has the same best solution.

Well here's the thing... the user doesn't need to be as visual unless he is doing the advanced stuff.

Not at all.

Firstly, most people who aren't programmers far prefer - nay, even expect a GUI to create things with. Photoshop, Word, whatever - they're all graphically-driven, nobody except programmers expects to do things in a text editor any more. Hell, even web designers get a suite of graphical tools.

Secondly, people who aren't programmers often think programming is hard, and these people are frightened by scripting languages, even simple ones. Present the creation of a menu as a series of indented text lines with colons and jump statements, and a lot of people will shrug, turn away and presume that Ren'Py scripting is too complicated for them. Present it as a UI with an "Add new menu option" button and drop-downs to select where the player gets taken after making a choice, and more people will be comfortable using it.

Thirdly, the advantage of a GUI development tool isn't solely in terms of interface - it also means you have a script which is guaranteed to run without syntax errors or unintended indentation problems or whatever. If you create a menu with a hypothetical Ren'Py GUI, you can be sure that the menu will display properly and take you to the right point in your VN when you click the choices. We get a steady stream of questions in here about how to script basic functionality, usually stemming from syntax errors or typoes, so it's undeniable that this would help some people.

The existence of such a tool wouldn't stop us from writing scripts for Ren'Py in a text editor if that's what we preferred, it would just give more people the opportunity to create VNs in Ren'Py.

[jack_norton]

The existence of such a tool wouldn't stop us from writing scripts for Ren'Py in a text editor if that's what we preferred, it would just give more people the opportunity to create VNs in Ren'Py.

Well that's fine. I would leave renpy as it is. But adding a GUI for non programmer is fine. Non programmer could indeed just use that and stop.
But renpy as it is now is great because I can mix VN with my own python stuff and create interesting stuff like RPGs hybrid (see science girls or my spirited heart) or even adventure stuff (in my upcoming bionic heart).
I think is cool to be able to do more than a simple VN, and that's why I think pytom doesn't need to change anything of current renpy language (but adding extra tools is fine, if he has time).

[delta]

I think the general trend should be to get away from the idea that scripts have to be written to be parsed in Ren'Py as easily as possible.

Write a specification for a generic, , logical, simple, and feature-complete VN scripting language, and then let engine makers implement that specification.

But renpy as it is now is great because I can mix VN with my own python stuff and create interesting stuff like RPGs hybrid (see science girls or my spirited heart) or even adventure stuff (in my upcoming bionic heart).
I think is cool to be able to do more than a simple VN, and that's why I think pytom doesn't need to change anything of current renpy language (but adding extra tools is fine, if he has time).

I'm sorry, but if you use Ren'Py only as a GUI toolkit you are willfully using it for things it's not specifically designed for, and as such your opinion should not be driving the development of said core functionality. Ren'Py should try to be the best visual novel engine first, and anything else second.

[jack_norton]

No I don't use it only as GUI toolkit, I program in python. Renpy has lots of useful additions to pygame (mostly GUI and dialogue system), that's why I use it instead of pygame.
I have no problem with improvements to the VN part: but if improving the VN part means cutting out all possible other things you can do with the actual system (think about the card engine pytom made for example), it isn't a good thing IMHO. I think it's possible to improve the VN with a visual building system without the need to cutting out features from the actual engine.