Syntactic Sugar

[mikey]

Well, my reason for 0 is basically pragmatic. Ren'Py actually IS simple enough, *maybe* the BASIC music statement could be simplified (play intro with fade), but to be honest, how much simpler can it get? You really can get away with a handful of simple commands and often the simplicity debate will be just a developer who makes every excuse NOT to try his hands on it. It's been rightly pointed out that Ren'Py is not WYSIWYG, and so, people will have to put up with a certain learning curve - while I think it's good to make Ren'Py user-friendly, I don't think that it should respond to each and every whim and whine of people who are unwilling to open a notepad or find it too difficult to copy/paste or to whom syntax highlighting isn't helpful. You have great tutorials by SolarSnake and eclipse, a helpful forum... the list goes on. Because I'm getting the impression that somehow the thought is there that it's the engine's fault if people don't try their hands on games, but with this kind of simplicity, it's just laziness in disguise.

[monele]

Mm... it's true that all the *basic* functions have a simplified form except for music and sound. Whatever else might be seen as advanced features. There has to be a limit. At some point you have to pull your sleeves and get in the grease

[Jake]

I'm surprised that there's so much resistance to the higher-numbered options.

I'm not, really... I heard about a "Game Design" competition recently at the university I went to, and saw the forum thread that followed; some of the people discussing it were proposing a "developed in C++ bonus" for the judging. Some of the entries had been written in C++, some in DarkBasic or BlitzBasic or something similar, one in Java... their excuse was that this was "the language that people would have to code in if they were a professional games developer", and that "real coders don't use DarkBasic", but they seem to have lost sight of the point that it was supposed to be a games design contest, not a games development contest. Programmers are quite often snobs, basically, and better programmers are often worse snobs. Doing things the 'proper' way is seen as a good thing, even if it's more complex or harder to understand. I can confess to being just as bad myself at times...

(I dislike VB6 because it has a half-arsed implementation of object orientation, because it encourages programming practices that are dangerous in most other languages and lead to hard-to-maintain code, and because it actively hides understanding from the coder - not because it's simple. Hating things just because they're simple and easy to use is just plain arrogance and elitism, and that's all that's being proposed here, I think. People shouldn't be forced to use a new, simple-syntax method, any more than people are forced to use 'show' over '$ renpy.show".)


I'll happily admit that I personally like option 0 because I like to have total control, and I like to understand the way that the things I'm using actually work under the covers, and calling more renpy methods helps a lot more with that than using sugar. But I'm a coder, and I have been for years, and I have the grounding necessary to appreciate such things.

That said, I never learned C++ (or even C, properly) simply because I found it scary - intimidating, if you will. There are hundreds of "learn C++ in 21 days" tutorials, I can read about any particular bit of syntax and understand it fine, I've used all the same concepts in Object Pascal and C# with absolutely no trouble understanding them... but C++ has '*'s and '~'s and '->'s and '::'s and all kinds of crazy concise and unreadable syntax and it conspires to make it seem a lot more complex and hard to understand than it really is. So I can really appreciate how readily people who aren't programmers in the first place feel about parenthesis and dots... it's not necessarily that they can't understand the concepts if the concepts are explained, or that they're never going to be good programmers in the long run anyway, it's just that learning such things is so daunting that they're put off trying.

Sure, it's easy to shrug it off as laziness and to claim that those people will never produce anything anyway, but... well, I'm to this day still daunted by C++, but in the past I've written, released and maintained tools for wargaming, written a couple of lightweight videogames, written a couple of puzzle games for my mother, written, released and maintained a lightweight web CMS (it's crap, but it's finished, which is the important thing) on my own time, and hold down a good job writing backend code for online HR and payroll... it's not like I'm never going to produce anything worthwhile. I'm just never going to produce anything worthwhile in C++.

And if it were my choice, I would try to avoid people being afraid to learn to produce anything worthwhile in Ren'Py. If I was holding a gun to PyTom's head, he would be coding in option 4. And probably sweating nervously, if he remembers me complaining about accidentally mouse-clicking every now and again.

[Matt_D]

mm pointers and referneces, null pointer exceptions are the things bad dreams are made of, that and oracle datafile block corruption.

I think one of the biggest fears is that in striving for simplicity we lose the power and versatilitie that ren'py offers in its current form. However the way it has been described the simpler script shall just be a bolt on top of the current syntax, so I'd assume things would origonally be made to work with the current syntax and then worked into the simpler syntax.

But I don't think it should really be interpreted as resistance more that the people here are already used to the way it currently works, but all would probably admit that a simpler layout would attract more people and hopefully people of a less technical mind set. So something needs doing if that's the aim, and I still think 3a wins out ^^\/

There is a problem with having on one hand a simplified syntax (?superset?) but also keeping the older syntax. An example my being mild irritation over the fact that dissolve and Dissolve both worked where as I think it was pause and Pause (or one of those commands) didn't leaving me perplexed as to what the rules about case were.

I think it's a good idea to appeal to as large an audiance as possible an it's very true that to create a basic game you shouldn't need to know as much as ren'py initially makes you think you do.

However somewhere else you should look is making a tutorial lite as the current ones are pretty darn bulky and if you arn't into coding they're just a turn off.

[Jake]

There is a problem with having on one hand a simplified syntax (?superset?)

Subset, if anything. Functionality-wise, anyway.

An example my being mild irritation over the fact that dissolve and Dissolve both worked where as I think it was pause and Pause (or one of those commands) didn't leaving me perplexed as to what the rules about case were.

This isn't the same thing at all, though, and is a totally different kind of confusion. 'Dissolve' is a class, and 'dissolve' is an instance of that class with particular data. The relevant line being:

Code: Select all

$ dissolve = Dissolve(0.5)

in ./common/definitions.rpy.

If it were Java/C# that line would be rendered:

Code: Select all

Dissolve dissolve = new Dissolve(0.5);

I get the point - that one has to be careful to not to introduce potential ambiguities which may confuse newcomers - but I hope I've made one of my own; that it's often flexibility and versatility which introduces ambiguity, and I certainly wouldn't advocate getting rid of that.

[Matt_D]

I know it's not the exact same thing, I was just highlighting a potential issue with adding the feature.

Why? Becouse that's what I do, people go "this is the plan" and I go "that could be a problem" and then people either go "o mmm" or "yeah thought of that" or "SILENCE MORTAL". Depending on who they are.

[RedSlash]

As mentioned, ren'py is quite simple to use as it is. If people can't get down to using it, then they are probably lazy. I am also fine with idea 0, but I'm going to point a few things out from a marketing and business perspective.

Right now, ren'py has taken a giant step forward in terms of professionalism after PyTom has taken the steps to enhance the renpy experience with a new demo and website. This is great. Do we really want to stop there?

Here are my thoughts on the 4 ideas.

Idea 0. Do nothing.

If 50% of the people in the world are lazy, then you will prevent 50% of the people in the world from using ren'py by doing nothing. They will glance your website, quickly browse your tutorials, and determine that it is too hard and won't even bother giving it a try. Should we try to capture this portion of lazy people or are is it fine with leaving it for the people who will take the time to go through and learn it the ren'py way?

Idea 1. Simplify names.

Simplifying names is a nice idea. I would like to see more of a standard naming scheme. I don't mind typing long strings of text as long as it is clear and consistant with everything else.

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

This is probably better overall. All main visual novel features should be top level call, while features like os specific system calls can be python. This should make things simpler.

Idea 3. Parenthesis-less function calls.

You better think this one through. Either remove all forms of ( ) from everything or put them all in. I understand that ( ) is a function call, a class, or an instance or whatever. If people understood what that meant, then the usage of ( ) is justified. Otherwise, you will confuse people on when the ( ) are needed in the same way you would confuse people with when '$' is needed.

Idea 4. Special Syntax.

This is generally best overall for the users in the long run. This method will make scripting feel less like a programming language and will appeal to more users (not the ones on our forums), IMO. I understand a considerable amount of work will be required for this step.


Here's a thought. define a high level and low level interface.

Way #1: The newbie way

Code: Select all

scene "mybg.png"
show "myimage.png" with dissolve
write "Hello"

Way #2: The Ren'py way

Code: Select all

image bg = "mybg.png"
image someimage = "myimage.png"
show bg
show someimage with dissolve
"Hello"

Way #3: The advanced way (straight up python, which may be mixed with Way #1 or 2 somehow)

Code: Select all

$ bg = Image("mybg.png")
$ someimage = Image("myimage.png")
$ bg.show()
$ someimage.show(effect=Dissolve)
$ Text.write("Hello")

I think this would appeal to both newbies and pros alike. There may be one point where you will have to break backwards compatibility for the better good, but it will probably be worth it in the long run.

My personal opinion to this issue is that you either stick with ideas 0-1 or go the whole way, all the way to idea 4.

[derik]

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.

Always a safe choice if you have a system that's working.

Idea 1. Simplify names.

Not bad, an incremental change. The same, working, system remains in place, with a slightly less baroque actual markup.

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

I... might cautiously support this, as I always found the $ thing a bit confusing.

Idea 3. Parenthesis-less function calls.

Disagree. The improvement it make in instinctual readability is outweighed by the eye-crossing result of trying to do with with nested elements.
Function calls are part of all programming languages, ever. There's a difference between trying to smooth over awkward points of the renpy language, and trying to smooth over defaults in every programming language. The latter is... kinda outside your pervue.

If you're going to make renpy's language less... programming-esque you'd create a nice, clean, readable scripting language, not a wierd hybrid that serves neither mandate well.

Idea 4. Special Syntax.

Hmm. I might actually support a sort of 'short syntax' where you don't have to pre-declare images and such. Something that lets you set a new background, display a character, and move them around. that's 90% of what people want to do when playing with Renpy anyway.
If you put in an abbreviated version of the character declaration, that might do it.

(Actually, on reflection, you can always just toss the character declaration all together even under current renpy code, can't you? Just explicitly declare the speaker? 'Candi' '"Come on, let's make a sandcastle!"', right?)

...what about a different 'so you're getting started' tutorial that lets people get by with plugging, say, 5 simple commands (label, display, character movement, dialog, jump) in after the existing renpy 'head' (the window size, ui color declarations, etc.)
If you were being really nice, you could ditch the head too, and have renpy make a default assumption of the values in the main init block if nothing is set. (which is a pain, because IMO you only LEARN from having the other model to look at...)
...also, making 'goto' work for jump wouldn't kill you, in terms of making things instinctive.

It means a separate, much simpler, tutorial, but it has the advantage of being SIMPLE. The only thing you're actually changing is making it so you don't' have to pre-declare images- the rest of it renpy already does.

And since it's all one 'version' of the language, when the beginning scriptwriter wants to do something more advanced from the main tutorial, all they have to do is click the editor button, and then crib the code from the main tutorial.


I don't think you have to (or even should) place the full power of renpy's engine int he hands of the novice programmer- but placing basic functionality int heir hands through a few very simple commands (IMO) seems like it'd eliminate a lot of the... "screw this,m it's too complicated"-ness. Make it so someone can open the simple_template project and put together a working scene in 5 minutes.

(Oh, I forgot menus in there, so 8 commands.)


I like #4, but really what I think you want (if I perceive your needs correctly) is this option.

Idea 5. Wizards.

This is what I use for writing HTML.

http://members.aol.com/regenesis0/we30.gif

Webedit 3.0 (written for Window 95!)
It's a text editor. But- it has wizards. You can click the button that looks like a picture, browse for an image file, set the horizontal offsets and such int he GUI... and click 'do', and it places an appropriate block of html where the cursor is.

This approach encourages people to, once they generate the correct code (always right!) go in and start tweaking it by hand, seeing how much more you can do, if you cut and paste bits about. I think it's the best way to code... well, almost anything like this. It makes no real concession for the early programmer on a language level- while lowering the bar of admittance, and encouraging them to write the language properly.

Not GUI or drag-and-drop (which results in awful code) but a sorta halfway-gui like this.

Of course, this means either writing your own editor, or finding an editor project you can write plugins for. ...which in turn means large #'s of man-hours going into writing developer tools, and not directly improving the renpy engine.

I still use webedit 10 years later. (Same version, actually.) I wrote two commercial sites in it in the last 6 months, 1 a microsite for Ulta Cosmetics. Yeah, I write a lot of my code by hand... but I finds it's a lot faster to use webedit's wizards for laying things out quickly to make my hand-alterations.

(of course, I'm prejudiced, because I dislike the current renpy editor, which lacks a 'find in all open documents', is easy to screw up indentations on, and seems to lack a 'go to line' command.)

Lowering the access bar is always good. What is the Renpy launcher if not a tool to make it easier to develop in renpy? I conservatively estimate that the renpy launcher plus the go-to-line button has halved my development time. Developer tools are cool.

So I'm recommending, uh... #4 I think, a conservative version thereof.

[Jake]

Idea 5. Wizards.
...
Not GUI or drag-and-drop (which results in awful code) but a sorta halfway-gui like this.

OK... so I'm mostly interested 'cause I'm in the middle of writing exactly such a tool (and would still like someone who doesn't have the .NET SDK installed to see if the POC runs on their PC, as it goes, between CAS and odd exceptions I've seen in the past it's more of a problem than you might think) - but what is it about GUI apps that means they definitely produce awful code, where wizards don't? Surely both a wizard and a GUI app start with the same data and are writing in the same language, so can produce the same results?

(By extension, I'm interested to hear what you think would be awful about this awful code, so I can avoid it... )

(of course, I'm prejudiced, because I dislike the current renpy editor, which lacks a 'find in all open documents', is easy to screw up indentations on, and seems to lack a 'go to line' command.)

OK, so I don't know of a find-in-all-open-documents, but there's a go-to-line (Ctrl-G, or Search->Go to...), at least.

Myself, I found it considerably easier to get indentation right with its assistance than without, for that matter - just use tab all the time to indent code... the little grey lines show you when you've got it lined up with other indentation. I'm curious - what's confusing about it?

[PyTom]

(of course, I'm prejudiced, because I dislike the current renpy editor, which lacks a 'find in all open documents', is easy to screw up indentations on, and seems to lack a 'go to line' command.)

Actually, some of this exists. There isn't a "find in all open documents" command, but there is the "Search/Find in Files..." command, which could be used to search all of the .rpy files in a game, which I think is roughly equivalent.

There is a "go to line" command, it's "Search/Go To...".

[RedSlash]

but what is it about GUI apps that means they definitely produce awful code,

A well designed complete GUI solution will mask all the coding from the user as the user is not expected to touch the output. Therefore, it will try to optimize the output code to suit the GUI program normally making it unreadable to the user. This is the preferred way of doing things if making a complete GUI solution.

The proposed solution is a half-way solution intended to facilitate the coding of ren'py script. It seems that people will still be working with the scripts directly, but has additional tools to make coding easier.

[Jake]

but what is it about GUI apps that means they definitely produce awful code,

A well designed complete GUI solution will mask all the coding from the user as the user is not expected to touch the output. Therefore, it will try to optimize the output code to suit the GUI program normally making it unreadable to the user.

Mm, but speaking from the point of view of a programmer myself, I can assert fairly confidently that the code output only has to be predictable, in some standard form, not necessarily compact or obtuse or ugly or unreadable. So long as the program knows which order to expect parts in it will be able to read in its own output no matter how many spaces or comments, how well laid out, etc.

(In the case of HTML editors there is even less of an excuse, since they're supposed to be able to load in any old arbitrary HTML anyway, including human-readable hand-coded stuff, so ugly unreadable output is just laziness on the part of developers who expect the user never to actually look at the code generated.)

My point is that I know of no reason that the output of GUI tools has to definitely be unreadable - just because all examples seen so far have been doesn't mean there's a good reason for it.

[yummy]

Here's my two cents opinion.

I can program, but only a little. I still can't get how Python code runs but oh well, I never planned to learn it.
As a creator, I just want my CGs to be shown, my characters to be displayable, text manipulation and transition effects to occur, music and sounds to be played at fixed times.

I learned my limits when I first crashed the engine with a simple string.

When I came with my game planning, I had a storyboard ready but it didn't help because it wasn't compatible with how Ren'Py worked.
Why? Because everything in the script is processed line by line.
You can't have the idea of parallel processing like in flash (which has a storyboard-like workplace), unless you work with sound (which in Ren'Py has a simultaneous start concept, whereas images don't have that feature even with zorder and layers).
That aside (because it's largely off-topic), there are still things I don't understand in Ren'Py, which aren't explained in the wiki or the reference pages on earlier versions.

That is certainly the most frightening thing for novices.

To customize your game, you have for exemple, to modify the styles but there are no clear explanations, unless you're familiar with python coding and familiar with programming objects manipulation (those style.mm_root.background gizmos).
What I just wanted to say about the first idea is that doing nothing just doesn't help the casual game designer who does not want to have to be a hardcore programmer (or depend on a skillful programmer) to create his game.

Simplification is the key.

I think that most of the simplification is already en route in Ren'Py and it rejoices me.
I just think that there are levels in programming, those who are skillful in using that tool can do (or are able to try) what they have in mind.
You already began to simplify the function names, so if you want to continue simplifying them, why not?

I'm not so familiar with programming even if I have some experience (but alas not in python). So when you come with ideas like making function calls implicit or removing parenthesis, I can't really see the difference while trying to code a game.
But I'm sure that what I can't see is actually a big difference

I think the idea of providing different syntaxes according to the programming level might take a long time to code. There are certainly people who can't program as well as Monele or Jake, people who begin to create in Ren'Py, people who have mastered the basics in coding in Ren'Py, but because of that, there is no default level when you program in Ren'Py.
Maybe by setting different levels of function interpretation (or calls or whatever it's called), it might help those who are not so skilled. But I fear about the syntax errors check process...

Your fourth idea resembles scripts from NScripter. These scripts are quite simple, really (but as there's no documentation, no support, trying to create a game with this engine is somehow like trying to figure out how to fly a plane without the how-to-control-the-plane guide).
At least, the scripts are clear: this character says this, that transition occurs there, that music is being played there.
But I don't think it's really a major improvement since most of this is already in Ren'Py.
Maybe one day we might end coding in Ren'Py like that (But that's not going to happen since you seem to dislike that kind of coding).
The problem is, as you said, the script would have to be internally created then run. At least if it's compiled once, it would check the presence of the compiled file then run it but for someone who'd QC the game, it'd become a hell (imagine 5 minutes to compile for only a string).

I think that the engine is good, that simplification is on the way and it's okay. Now what it lacks the most now is a GUI (or wizard), as derik mentionned. Not a launcher/project handler, since you provided it. A GUI like the one Jake is programming.

There is another engine which used a plot tree to create its events which had their scripts and transitions (I think it's still in the designer resources thread). I'm definitively for that kind of GUI because you don't have to worry about the programming stuff and you can concentrate on how you construct your scenes, episodes, paths.

Because I'm more of a casual game designer than an expert in programming (I'm more like "Ah my game should have *that* kind of nifty interface, *that* kind of transitions, *that* way of sound being played" etc etc...) I can't devise on how to modify Ren'Py coding so that it meets a skilled programmer's needs.
All I can say is that I search for something simple, easy enough to manipulate so that my vision about how my story is going to be played is fulfilled.

[PyTom]

Why? Because everything in the script is processed line by line.
You can't have the idea of parallel processing like in flash (which has a storyboard-like workplace), unless you work with sound (which in Ren'Py has a simultaneous start concept, whereas images don't have that feature even with zorder and layers).

I don't know what you mean by "parallel processing" here. When you do something like:

Code: Select all

scene bg washington
show eileen happy

"This is a test."

The images on the screen do not change until the line of dialogue is shown.

I have read your comments, and will take them into account. However, I believe the textual representation of Ren'Py is an advantage. It's much easier to change a textual representation, then to change some sort of gui representation of a game... I think it's for much the same reason that movie scripts are written in a textual format, rather then as, say, storyboards.

Now, I don't mind people throwing together GUIs for Ren'Py... I just don't think that those will be the preferred editing environment, since it loses much of the flexibility of a modern text editor.

[Jake]

I don't know what you mean by "parallel processing" here.

I've not experimented with music-playing in Ren'Py myself yet, but I get the impression from the reference manual that you can - for instance - queue tracks up to be played in sequence regardless of what is happening in the interaction part of the game... 'parallel processing' versus 'line by line' makes me think 'multi-threaded', and it's certainly the case that Ren'Py seems from the scripter's point of view (whether or not this is the case) to be a single-threaded application. I can't to my knowledge - for example - run sequences of transitions to play out a cut scene while I'm waiting for user input, aren't I limited to the one 'show' statement immediately before the interaction with only as many simultaneous transitions as I can cram into that?

(Of course, I've not looked into Python's threading support, presuming it has any, but I'd worry that trying to use that to subvert a Ren'Py script may well have... 'unintended consequences'. I can't even pretend to understand completely enough the way that Ren'Py works on the inside to say...)

I don't think multi-threaded Ren'Py scripting would necessarily be a good idea, mind; I can't think of more than one valid use, given the context, and thread synchronisation is guaranteed to confuse even people who are competent programmers.

I think it's for much the same reason that movie scripts are written in a textual format, rather then as, say, storyboards.

My own belief is that the fundamental difference is that people aren't (unnecessarily?) afraid of writing screenplays. Possibly justifiably, since if one writes a screenplay and does not follow conventional form, it will be read by human beings who can probably work out what it is that was meant, instead of a strict parser which throws out your script entirely 'cause you forgot to leave a blank line at the end or accidentally indented a bit of dialogue too far.

(Studio people may well actually throw your script out 'cause it's not in all-caps and double-spaced, I don't know, but the same people wouldn't let it put them off screenplay writing, they'd just consider it thoroughly unreasonable of the studio to do such a thing.)

Now, I don't mind people throwing together GUIs for Ren'Py... I just don't think that those will be the preferred editing environment, since it loses much of the flexibility of a modern text editor.

While I'm sure this is the case for people who are already programmers, I'm also sure that the same thing was said about by C++ coders when they first saw VB's forms editor. "We don't need a GUI tool for that, you get much more control if you just write the code to build the form yourself, and we can make changes easier rather than having to click through property panels and combo boxes"...

In terms of my own proto-tool it's not the best analogy, 'cause I'm well aware that the finished product will not be nearly so capable as writing your own script would be, but I wouldn't like to suggest that this is definitely the case for all GUI tools ever.