Ren'Py Roadmap

[delta]

There is too much stuff gluing my palm firmly to my forehead to comment on it all, but this...

I forget whether I commented on this already or not, but I'd love to see auto-merged whitespace go away. (In large part because I'm picky about grammar and like to doublespace after periods.)

This is incorrect, though. Most sources seem to agree that it's correct to leave one space after a period:

MLA: http://www.mla.org/style_faq3
Chicago Manual of Style: http://www.chicagomanualofstyle.org/CMS ... Two02.html
US GPO Style Manual: "A single justified word space will be used between sentences. This applies to all types of composition."
Microsoft Manual of Style for Technical Publications: "Use only one space after a period in both printed and online content."

Common English Errors: http://www.wsu.edu/~brians/errors/spaces.html

http://howmanyspacesafteraperiod.com/

What's next, automatic in-engine conversion from British to American English? Stop forcing your idea of how things are supposed to be done on people via your engine. Fine, keep control over the scripting language, but actually trying to influence the content (and design, see also: readback) is arrogant to the maximum.

[Guest]

[quote="DaFool"]
Even if Ren'Py is the shittiest piece of software out there (and it's not), in the hands of skilled people the results would be impressive. I aim to be that driver who pushes a Yugo or a Daewoo to perform remarkably, as opposed to a douchebag hiding in his Ferrari.

And for the record, I'm not PyTom's bitch. In fact, The Question was partially the result of his rejection of the artwork for the demo game he's always wanted. It just so happened that mikey thought "Shit, we can release this." Without The Question, there won't be any The Answer, nor will there be The Fucking Question. See, things always start small and shitty, then eventually snowball into awesomeness.
/quote]

"I'd rather push something lame and flawed to maximum performance than have a solid, quality base upon which to build?" This is everything wrong with LSF.

And for the record, the way you are ready to roll with whatever PyTom is going to do and go "lol he can do whatever and I'll adapt" means, yes, you are. I don't know what your example is supposed to prove other than that mikey has low standards for releasing something.

[Jake]

There is the other sentiment that because Ren'Py is so easy, unskilled people are able to release unskilled games. (So the recommendation would be to keep it less user-friendly.)

Frankly, it's a stupid sentiment, since programming skill and drawing or storytelling skill are pretty much totally unrelated. Comments about donkeys are pretty unhelpful, since the skills which needed to make a VN good - artists, writers, composers - are totally unrelated to the skills which are needed to make a well-made Ren'Py game - understanding of precise, non-obvious syntax and programming structures. If Ren'Py is going to encourage people to make good VNs, it needs to encourage the people who can make good VNs, not the people who can make good programs.


(And it's equally not fair to suggest Ren'Py is lame and flawed - flawed, maybe, but it's still a good piece of software. It's just that right now, it really only shines in the hands of someone who's not afraid of getting their hands dirty in Python code, and apparently PyTom has no intention of changing this regardless of how people feel about it.)

[mugenjohncel]

Current Ren'py GUI is a blessing from heaven... Ren'py has never been accessible and easier until JEdit arrive. OK, JEdit is here to stay... no choice but to accept it. I still have to figure how UI-Button thingy works and hope that someday, someone will make an example/tutorial like... here's a png button measuring 50px by 50px with a "hover" and "idle" state and "animated" and if I clicked on it... the following behaviour is possible...

Go to a label
Show something and Jump to a label
...and so forth

For now, image-maps is the only way I know to achieve this behaviour.

I wish there would come a day where it is possible to assign different hover sound to different Hot-Spots in a single image map... really, it's all I wish for... then release a VN using such feature then I could die a happy man without any regrets!

[Jo'ogn]

It's kind of interesting. Now that grad school is over, I'm beginning to figure out how to balance Ren'Py with my job and my personal life. So that's kinda fun. Although I don't spend enough time cleaning my house. I'll probably need to hire some maids sometime soon.

BTW: That sounds like the beginning of an interesting 'H' Ren'Py Game =D

"It is a question? Is it an answer? No! *tadaa* They are 'PyTom Maids'!"

(And it might even have different hover sounds on different Hot-Spots in a single image map ; )

Comments about donkeys are pretty unhelpful, since the skills which needed to make a VN good - artists, writers, composers - are totally unrelated to the skills which are needed to make a well-made Ren'Py game - understanding of precise, non-obvious syntax and programming structures. If Ren'Py is going to encourage people to make good VNs, it needs to encourage the people who can make good VNs, not the people who can make good programs.

While I agree with you, you might have missed the implication, that pleasing everyone might lead in the end to what a game designer (of the Ren'Py type!) might not want:

A Ren'Py coming in a 1GB+ wysiwyg development package with a 3D hentai doll maker, physics simulator, voice acting synthesizer, a music composer (with an optional 4GB music libary), a cell shader plug-in, a 2D graphics program, a semi-intelligent text writing engine, auto spell checking in 120 languages, auto censoring for minor users, direct connection to paypal, browser plug-in, exportable to SWF and 256 different types of cell phones, Palmtops, tamagotchi, pagers and wireless microwave ovens... Furthermore this Ren'Py will be fully backwards compatible to Commodore BASIC 2.0 and run on any Atari 2600 emulator. Not to forget flashing advertisements in the 30 days trial demo version!

Would all of this stop ppl from having "problems"? How many problems do ppl already have merely to run the OS on their PC? Still! After over 30 years of computer and software development.

[Jake]

A Ren'Py coming in a 1GB+ wysiwyg development package...

Except that is a drastically extreme example, and not really related to what people are suggesting here. We're suggesting changes to the way the language works which wouldn't affect the distribution size at all, but would make it easier/less hassle to create Ren'Py games.

One could use 1GB package-bloat scaremongering to argue against any kind of change at all, if the kinds of changes we're talking about here are a worry in that regard. That kind of thinking isn't particularly helpful or constructive, taken to its conclusion it would suggest that Ren'Py would be better off not having been created in the first place, since people could just use Python to write their own VN engine if they needed it for their particular project.


I seriously doubt that's what DaFool meant - I read it more along the lines of the same "if we dumb down the language to appeal to people who can't program, then people who can program will be constrained by the changes". Which also isn't necessarily the case at all, but hey - people seem to be afraid of change.

[Jo'ogn]

people seem to be afraid of change.

Despite desiring change, yes. Reiterating that what is said isn't helpful isn't very helpful either, how would it be 'unrelated'?

Ppl who ask for change take Ren'py beyond the ordenary VN (me included), or want Renpy to be sth different from what it is. The basic VN syntax is considerably simple - it doesn't seem to be the main obstracle for neither newbie, nor programmer. It's the advanced stuff where users experience obstracles.

How much 'change' does Ren'Py need to become a 'better' Ren'Py, when it can do already a lot of things, but ppl just don't know that it can, and how it's be done?

I encouraged improvement of the wiki documentation, interestingly enough not many users seemed to be in need of more documentation. Maybe the topic should be made a Sticky so that ppl can see it.

I still vote for an increased support of the Renpy documentation in a way that a non-PyTom can understand it too

[Jake]

or want Renpy to be sth different from what it is.

Obviously - the point of change is to make it something different!

The different thing I would like Ren'Py to be is "more accomodating to users who aren't programmers". If anything it's getting closer, rather than further away from the supposed primary goal of Ren'Py - to provide an engine to run VNs.

The hardcore programming crowd extending out past VNs are the ones looking to push Ren'Py away from that goal, and while I'm a programmer myself and don't personally have any problem with the syntax, and while I'm interested in those games as well, I also like stories, recognise that people who write and draw well aren't necessarily good programmers, and don't want to miss out on their stories because of that. I get the impression that Delta also isn't trying to move Ren'Py away from its goal, but rather wants a consistent and streamlined scripting language for the 99% of any VN which is just talking.

The basic VN syntax is considerably simple - it doesn't seem to be the main obstracle for neither newbie, nor programmer. It's the advanced stuff where users experience obstracles.

Actually, given the number of questions we see on things like - say - the menu syntax (complete with indentation issues!) I'd say this statement isn't entirely true. We see newbies stumble over the basic VN syntax all the time, and more than that you also have to bear in mind that a large number of newbies won't even bother asking the question on forums, they'll just presume they're not good enough programmers after banging their head against the problem for a while and give up.

I encouraged improvement of the wiki documentation, interestingly enough not many users seemed to be in need of more documentation. Maybe the topic should be made a Sticky so that ppl can see it.

Not very many people asking for docs isn't the same as not very many people needing docs. The people who give up before asking the forum for help also aren't going to ask for documentation, and people who believe the things they want to do can't be done aren't going to ask for docs because they think their goal is impossible. And a lot of other people just don't feel like getting engaged enough to post in such threads.

(I would agree that the documentation could be drastically improved - I started writing a 'simple' version of the language manual page, but part-way through I started to wonder if it was really the right way to present the information and I'm afraid to say I've not been back to it since. But PyTom's said before that it's something he can't really do, and most of the other people who are knowledgable enough about the way Ren'Py works and capable enough of expressing ideas to write good docs are busy with other things, it seems.)

[Jo'ogn]

The different thing I would like Ren'Py to be is "more accomodating to users who aren't programmers".

Save the world! Offer your suggestion to PyTom how to make Renpy "more accommodating". I am curious too.

[Counter Arts]

I'm almost tempted to make a "Hyperlight Not-Renpy" language and gui that just translates into ren'py code. Or better yet, I could try to make a program that is given the text of a play and translates that into ren'py code.

PyTom knows I've been tempted to make a script converter from onscripter to renpy. Hehe...

Or someone else could do this for fun.

[Jake]

I'm almost tempted to make a "Hyperlight Not-Renpy" language and gui that just translates into ren'py code.

I started work on something like this, once, as well. But I rapidly came to the conclusion that:

i) The UI design was a hard problem, but a surmountable problem.
ii) It would be far more useful to be able to read in projects which had been edited by hand elsewhere, or originally written outside of the editor, which isn't a practicably surmountable problem what with Ren'Py script having its current haphazard integration with Python.

Given the difficulties with ii, I didn't bother putting the effort into i. I didn't like the idea of writing a tool which was only good until you borrowed some code from the forum or the cookbook.

(I considered having a series of plugins which allowed you to add particular functionality in a generic manner, like a CG gallery or readback or whatever, but by that point I'd already more or less abandoned the project.)

Offer your suggestion to PyTom how to make Renpy "more accommodating". I am curious too.

That's what I've been doing in this thread? To summarise:

Primarily, I would like to see it possible to write a VN in Ren'Py - including all 'normal' functionality, moves and variables and character/image definitions and so on - without having to write a line of Python. Currently you need Python to define Characters and to do variable manipulation at the very least. This would be a benefit for new users because like it or not, the distinction between Python and Ren'Py script and when to use $ signs and so on isn't immediately obvious.

Secondarily, I'd prefer to see the Python integration less haphazard, more clearly-defined. If the above ideal were met, then the need for in-line Python would be drastically reduced, and it would be far more feasible to segregate Python methods elsewhere for your user-defined displayables and complex UI code and whatever. If this was realised, then it would be a lot more practicable to write the hypothetical development tool which would help programming-averse users a lot. I'm sure there was another advantage direct to the user but I'm at work and writing this post in between working and I forgot it.

These could both be realised without requiring any change to the Ren'Py distribution size, and without preventing any games which could be written before from being written now. It would be a breaking change, scripts prior to this change would need fixing up to work after it, but Ren'Py's had those before. And in fact, since Tom's talking about a whole new version of the script spec., it wouldn't even necessarily be a breaking change.



As a total aside, I also think that a Theme Editor would be useful, a graphical tool which gives you property-box modification of the various properties and styles needed to make a theme, which saves out as a .rpy file and associated assets. Maybe even an .rpa with everything in it? But that's separate, and for that matter could be distributed separately, before anyone starts worrying about the distribution size.



But then, PyTom's already said he's not interested in any of these changes, because he apparently thinks that the ecclectic mix of Python and Ren'Py Script that we have at the moment is a good thing. I disagree, but it's his project and I can't be bothered to maintain a fork. I also think it would be worth not using significant whitespace, but that's also been discounted.

[delta]

I get the impression that Delta also isn't trying to move Ren'Py away from its goal, but rather wants a consistent and streamlined scripting language for the 99% of any VN which is just talking.

Exactly. The other problem is that I find Ren'Py's performance to be underwhelming. I understand this is a very basic issue issue of using a non-hardware accellerated interpreted scripting languaged for memory-intensive blitting, and this extremely hard to fix, but a flaw with a reason is still a flaw.

Now, a question. How many of you are actually comparing Ren'Py to other VN engines, especially modern ones like KiriKiri? Because while I think that Ren'Py is at the moment the only sane choice for non-Japanese VN development, that doesn't mean it's superior to them in every regard (for the record, I know KiriKiri and ONScripter well and have dabbled in NSS, RealLive, Novelty and Blade). I think as long as Ren'Py isn't as good as any of them in any regard, there is still room for improvement, which is always worth discussing.

[Preludian]

I encouraged improvement of the wiki documentation, interestingly enough not many users seemed to be in need of more documentation. Maybe the topic should be made a Sticky so that ppl can see it.

I still vote for an increased support of the Renpy documentation in a way that a non-PyTom can understand it too

Didn't I mention this a few post back? But nobody seemed interested I remember when I wanted to learn about Assembler on the C64 and had some german books and didn't understand much. Then I found an english book about learning Assembler and suddenly I understood all... and german is my native language.....

Thinking of it, the Blitz3d reference I mentioned before was built up completely from the community. The main reference was added and the users enhanced and provided the examples. Why not with RenPy?

[Jo'ogn]

PyTom's apparently thinks that the ecclectic mix of Python and Ren'Py Script that we have at the moment is a good thing.

I can imagine that a renpy only script language might make it easier to create additional tools on top of renpy without the need to use python - if that's an issue

How many of you are actually comparing Ren'Py to other VN engines, especially modern ones like KiriKiri?

Cannot compare, as I don't know any other engine of that kind. But a need for GUI or simplified input isn't my main issue anyway.

Didn't I mention this a few post back? But nobody seemed interested. Thinking of it, the Blitz3d reference I mentioned before was built up completely from the community. The main reference was added and the users enhanced and provided the examples. Why not with RenPy?

I do think that ppl are interested, but those who are might not participate in this topic, because - as was pointed out - VN developers are expected to be 'artists', 'writers' with no programming experience, or no desire to programm to begin with.

I can understand that those who want to make VNs or games have no intention to contribute extensively to the renpy documentation - admittedly me neither.

BTW some renpy wiki pages were translated into German.

[EwanG]

I told myself I was going to stop commenting in this thread... and then here I go and do this...

Anyway, pursuant to the comment about "having tried other engines". Trust me, I've tried all of them except the one that was just recently released here on the boards. I didn't do Android and Flash (and MovieStorm and GameMaker and the list goes on) development for my health. I did it because I wanted to see if there was anything else that worked "better" for how "I" work.

Yes, remembering when to use the $ or not is a little clunky. But Lint does a great job of reminding me when I forget. Yes, I'd like a background generator and a 2D character generator - but the only packages I've found that do that either are incredibly expensive, or do it using pre-packaged assets that always are missing something I need, and then pulling in your own stuff is next to impossible.

Obviously RenPy can be improved. All software sucks, almost by definition. But as I think I've said before, I have found no other tool that I can write my script, and by adding a couple of formatting rules, have my program almost completed in. It took me two horrible months to port SY to flash, and that wasn't because I did all that much writing. I was able to create CR II in total in just under a month, and that was with 2x the size of the script and still having to create some new backgrounds. For "me", that makes the comparison pretty vivid.

OK, I'm going to get back to the stuff I'm "supposed" to be doing.