Lemma Soft Forums

I'm getting a sense that some people think Ren'Py is a little too difficult, and that it might be better if there was some syntactic sugar as part of it, to make certain tasks easier. So I've come up with some ideas, and will try to make my thinking a bit clearer about this.

Idea 0. Do nothing.

The current system isn't overly broken, IMO. So it's not clear to me it's necessary to do anything at all... and I'd rather not do anything until I'm happy with what I'm planning to do. So the null option is certainly on the table.
Idea 1. Simplify names.

Some of the names may be longer then they need to be. Why write renpy.music.play when music.play would suffice? So we could shorten some of the function names... which makes them look a bit nicer.
This is compatible with the other remaining ideas, so I'm just assuming for now it will become part of the language.

Idea 2. Allow function calls and assignments in Ren'Py.

By allowing function calls and assignments at the top level of Ren'Py, we can eliminate most uses of $.
Idea 3. Parenthesis-less function calls.

Somehow allow functions to be called without parenthesis. While properly allocating arguments. We'll ignore the character declaration for a second, as I don't think that'll get any easier then the previous, and focus on these new functions. I have two syntax ideas:
or
There is an ambiguity problem here with character objects, that it's not clear I'll be able to solve. This approach might also make syntax highlighting hard, as I wouldn't want any of the words here to be treated as keywords... or maybe I do. I don't know for sure.

Idea 4. Special Syntax.

We can also add a new statement type for each interesting command. For example, we could add a 'music play' statement, a 'music queue' statement, and so on.
The downside here is that we have a special statement type for each statement, which is inelegant from my perspective. Unlike the other approaches, all statements need to be built into Ren'Py, rather then being defined by the user. So I don't particularly like this option very much.


My Thinking

Right now, I'm leaning towards 2 or 3b. I don't like 4 as it would seem to make user-defined statements impossible, and I don't think that's a good thing. (I could see stuff like "voice" and "voice_sustain" and "nvl_clear" all becoming user-defined statements in the future.)

A problem is that 4 and 2/3 are incompatible, so there's that. And I'm not sure 3 is practical, implementation-wise. Also, it's not clear that I could properly syntax-highlight things for option 3.

Of course, this is a very difficult design decision. So while I'd like people's input, I'm not sure I'll be making these changes anytime soon. I want to be _sure_ before making the changes to the language.

(There's also the problem that I see option 2 as the cleanest of these options, a position I'm sure many disagree with.)

I'm personally "into" option 0. Now, that probably comes from having a programming background to begin with, and so learning RenPy has generally been a case of learning a new syntax.

But I think for the truly casual user, or the author/team that wants to build a game and not have to even "see" something like a program, none of these is going to be "enough".

Many years ago I worked with a product that I "think" was called SQLWindows. What was great about the product was that it had a Visual UI, and a source window. So you were able to drag things onto the screen, place them where you wanted them, add buttons that you could right-click to set the property of where they went, and then if you wanted to tweak something you could go into the source window, make your tweak, and see the effect over on the Visual UI window.

I would get excited enough by something like that to be willing to start over. However, I don't see enough additional help or functionality in the other options that would make the effort worthwhile. In fact, I'd probably make several backups of 5.6.4 just to insure I had a working copy, and then ignore the new version.

Again, these are all IMNSHO, and should be taken with an appropriate grain (or box) of salt.

FWIW,
Ewan

I like 0, 1 and 2... Basically, slight simplification or just leave it as it is.
I don't *really* mind the other things but hm... I'm not entirely sure it will help by removing that much syntax (but hey, who knows, maybe some people will like it) and I just don't want anything to *force* a change. New syntax is good, as long as zee old coders can keep old coding :3.

Just to clarify, all options on the table would preserve backwards-compatibility with existing Ren'Py code.

I like Option 0 and 2, and only those options because I'm still confused whether to use the $ or not.

As for the rest, its more important to keep calls uniform and consistent rather than easy on the eyes.

For my own use, I like option 0 - if anything, I'd like to learn more of how to use Python calls to do things (like character speech) which I only really know how to do via the existing sugar. But then, I've been coding for years and years, since I was a kid playing around with his rubber-keyed Spectrum, and these things just make sense to me.

I also think that for general use, option 4 would be the way to go. Despite having carelessly named the first character sprite I ever drew for use in Ren'Py 'Music'.

The dots and the parenthesis both scare people. It's not confusion, because there's nothing to be confused about; I'm fairly certain it's just outright fear. People see programming-esque syntax, freeze up, think "Argh! Programming! Programming is hard!" and give up. :/ It seems to me that it comes down to whether you want to aim Ren'Py at people like me, who are already at-least-competent programmers, or people who aren't programmers and don't want to be - I get the impression that mikey falls into this kind of category, for instance. Given that Ren'Py already has lots of screenplay-esque forms, I'd have expected that the latter audience was the desired one... us programmers can fit around them, but they can't fit around us so easily.


(I'd rather not see concessions allowing people to get away with omitting the dollar on some lines but not others, I think that would just lead to greater confusion, really...)

Having thought about it for a while, I'm for option 0.

I'm rather new to all of this; both programming and game design in general, but I'll add my $0.02 anyways

The reason many people find Ren'Py hard to use is because they're looking for some kind of drag-and-drop answer that makes a beautiful game for them with almost no effort. When I heard about Ren'Py, I was kinda hoping for a GUI that would allow me to create a game, kinda like flash, but without all the extra vector graphics bells and whistles. Now, just because Ren'Py doesn't have that doesn't mean it's a difficult engine to use, it just takes a little bit of patience to get use to it.

Now that said, I think simplifying the language wouldn't change much. Ren'Py is very easy to write in as it is, and anyone who thinks it's "hard", is probably just being lazy, IMO; and they will probably continue to think that way until someone invents a way to plug their brain into their computer and allows them to drag-and-drop their game directly onto their machine (and even then, they'll probably say it's to hard to actually drag-and-drop).

So, I'm for option 0. Leave it alone; unless you're feeling up to the task of creating a GUI for people (which I doubt you are, and I wouldn't blame you ).

Taters wrote:many people find Ren'Py hard to use is because they're looking for some kind of drag-and-drop answer that makes a beautiful game for them with almost no effort.

I agree quite a bit. It might be some people are rather looking for a tool that writes the story for them, not one that enables them to transfer the story to a medium.

Jake wrote:The dots and the parenthesis both scare people.

True. If we could show that it is possible to make a simple three-line game without any "init" sections and without renpy.do.this.and.that variables... ... that might be an argument for some people to use Ren'Py because it can't get simpler than this. The drawback is that PyTom would have to build in some kind of interpreter to transform these simple commands into Ren'Py syntax internally. On the other hand, we are just talking about three commands here (for graphics, music, text), because anybody wanting to do more (fancy effects etc.) would anyway need to put some effort into reading the docs and programming.

So maybe adding these three commands as a bait for newbies would be a good move.

I think 3a would be the most appealing as = is a pretty comfy sign for people to use and just makes sense.

Personally I'll stick with 0 just got my Python book through the post today seen as the dead rat also uses it alot I may aswell learn some more about it. Thing is though once you get past the argh that looks complicated, it really isn't all that bad.

Option 3a is tempting - it gives syntax very similar to classic Visual Basic, which many people still associate with "easy" programming.

(Option 4 would be slightly better still. Does it really require commands to be hardwired? I would have thought it could be implemented as syntactic sugar merely by recognising when the first two words on a line identify an object and a method of that object, i.e. first trying to parse the line with an implicit "." after the first identifier and then trying again without the implicit "." if that doesn't work. But maybe Ren'py isn't designed in a way that would make that easy to implement.)

3b is indeed appealing for the newbie, but imo the gap from the syntactic sugar to the real code would be too important. Once the newbie start a basic VN, he will always want to add advanced feature that would require proper (and Python) coding and then would still get stuck.
Also as we don't have a WYSIWYG VN engine, I am not sure the creator audience Ren'py have would have real difficulties with the current code once basics are reached. If he can go past parenthesis and dollar, then I don't see a use to remove them (maybe for time saving though).

0 or 1. I dont like VB renpy is good as it is now

I'm surprised that there's so much resistance to the higher-numbered options. I think one of the appealing aspects of Ren'Py is the executable scripting metaphor. While I think embedding a full-fledged programming language into the script is a cornerstone of extensibility, it's not obvious that we should require people to learn python to make a simple game.

(Of course, it's not obvious that

$ music.play("foo.ogg")

is learning python.)

Still, I think making the scripting less foreboding is important. The goal is not to teach people to be good programmers, it's to have people make visual novels. I'm thinking a more-script-like syntax could help with that.

haeleth>>> Well, right now the parsing of scripts is a two-step process. We first break the script up into statements, and we then parse the statements to form an Abstract Syntax Tree, which we execute.

While I could do a trivial parse into object and method, that would have to occur before the init code is called, and we don't totally know what the objects will exist. There are also some ambiguity problems that would occur.

What I'm thinking about is having another pass, which occurs during and after the init code, and handles parsing things out more correctly. Well, I'll figure something out.

Or else I won't. I'm still not sure if any of this is a good idea. (I'd be interested in why the zero supporters are going for that choice... seeing as how the old syntax won't change.)

PyTom wrote:(I'd be interested in why the zero supporters are going for that choice... seeing as how the old syntax won't change.)

What I fear more than a steep learning curve or a new alien programming language is ambiguity.

It's like there's an offer to learn Japanese Lite Streettalk which enables you to do the basics of getting around Japan fairly competently.

But then you think, wait, eventually you'll need to actually carry conversations with the people, so you'll eventually need to learn Hardcore Japanese anyway.

So in the end, you just bite the bullet and go with a solid Japanese language course, knowing that while Lite Streettalk is easier, the original will get you farther in the long run, since the conventions have been around longer.

This is just an example. Not that I actually took any Japanese classes (yet.)