Ren'Py's Public Image

[monele]

Note about the website new design : the little Eileen looks so good there ! I'd totally see this as a perfect logo actualy ô_o... Well... maybe not but, aah... ^^;


To rika-chan : A *lot* of good points. You are where we've all been at the beginning. I don't think we're unfriendly. PyTom is actually always replying to questions, however noobish they can be and wether they're explained in the reference or not. But yea, we need a series of tutorials showing the making of a simple game to an intermediate game at least... something with themes (how to simplify this or that, how to change the interface, how to add style to your dialogues, how to make transitions...). And since we talked about demos, those tutorials should come with a working example probably. Wish I had more time on my hands, because that's something I'd like to do for new people.

In conclusion, don't get mad, just ask here for now. Or search the forums since most basic questions have already been answered. What we should do though, is note all your questions down so we can have them answered in future tutorials.

[Jake]

I think Rika-Chan has made several points. The user manual is a mess, and needs editing by someone who isn't super-familiar with python and Ren'Py. And I/we have been relying to much on support through the forum, rather then simply properly documenting things.

I was wondering about this the other day, actually - I came to the forum to ask a question, did a search to see if I could find an answer that had already come up, and found the answer I wanted in an example written for a question asked a year or so ago. Well, it wasn't quite the answer I wanted, but it showed me what it was I was getting wrong, even if purely by accident.

Even leaving aside re-phrasing the manual (and I'd be happy to help with that, but I don't know if I'd want to do it all on my own) wouldn't it be worth compiling together all the questions people have had answered on the forum into a big FAQ-like document so people can browse them more readily? There's a lot of high-quality explanation there, and it's indexed by real-world problems rather than high concepts. I know that each time I've dipped that far back into the forum history I've found information that has been interesting, but there's too much chatter about other stuff to make it so worth just reading through all the posts since the dawn of time...


(EDIT: The other thing that I was wondering about was the potential for a drag-and-drop, check-the-boxes style VN 'editor' that didn't give you the full flexibility of coding by hand in Ren'Py script/Python but did get the average newbie on their feet and able to churn out a VN with dialogue and scene changes and transitions and all those easily-encodable things. But that'd be more work even than reworking the reference, and harder to do in a nice cross-platform manner. It'd be a relatively trivial, if lengthy, task for me to do, but if I did it'd be a .NET windows application...)

[mikey]

Collecting answers to problems in a thread seems to be a good idea and it definitely wouldn't hurt to have a list of problems in a FAQ somewhere.

I wanted to look and collect such FAQs and common topics for the Game-Makers corner. Then again, I actually believe that questions (unless they have a clear answer) should be asked again and again, for instance the current debate on organizing a game's script. One could point whoever is asking the question to the same old thread, but by starting a new one, it kind of feels fresh and often people will give new ideas.

Anyway... a lot of things could be done... if people just had the time Of course, topic lists and FAQs may also make things more complicated.

Back on topic, Ren'Py Tutorials and documentation... it's a bit of a problem. But I can understand that this part gets neglected - PyTom probably has a lot to do... maybe people are pushing him to work on releasing their game (hmmm...), or he is trying to solve a bug or replying to an immediate question on the forums.

So as a one-man thing, there's just about no way that a re-styling of the Ren'Py image (promo, website, documentation and support) is possible. The only way I see this is if someone other than PyTom really puts some effort into it - othewise it will probably only be doable if PyTom takes a break from adding features and so, basically stop doing everything else for say a month - to be able to freshen up ren'py's image with new tutorials, webpages and such.

[Shii]

I prefer the current website design for the following reasons:
- On a software development page, color schemes and images only distract from the purpose of the page, which is to direct people towards the development resources they need. See http://apache.org/ and http://w3.org/ for good examples of development pages. Imagine how much easier http://emule-project.net would be to navigate if there were no colors or images on it at all.
- On the subject of colors and graphics, the current redesign does nothing to improve the visual layout of the page-- it just makes it more colourful. Actually, I take that back, the redesign makes it harder to read. The text is pastel. Usually that is a recipe for a background color, and I see you are in fact using it as a background color as well as a text color.
- Pardon my French, but the graphics are still hideous.
- There is no need to give a mere paragraph of text (such as the Mac/Linux instructions) its own page. That is especially annoying when the site is slow, your proxy/connection is slow, or you are viewing the index page through a cache and can't get to the other pages.

The only thing I would change about the current design would be to rename "Current Release" -> "Download Current Release" and move it to the top, and to combine the Tutorial and Documentation sections and move them directly below that.

[PyTom]

mikey >>> You're right. I have two games that I'm helping out on now, and there's also the usual development of Ren'Py. So if the site/tutorials/etc are to improve substantially, it will be really up to other people to do so.

Part of this is that I need to let go a bit, and let Ren'Py become a true multi-person project.

the purpose of the page, which is to direct people towards the development resources they need.

That's one purpose. A second is to convince people who are on the fence that Ren'Py is the software they want to use to make their VNs. I think a slick website may help with that, rather then the old-school website we have now.

See http://www.djangoproject.com and http://www.turbogears.org for examples of slick website focused to developers.

Also, the new website would combine several of the pages of the existing website. I'd expect "Mac" and "Linux" buttons to link to
http://www.bishoujo.us/renpy/mac.html and http://www.bishoujo.us/renpy/linux.html , rather then duplicating the single paragraph that links to them.

I'm beginning to think that the blue + roundrect buttons may not be the way to go to the website, and it may make sense to ask people here to come up with alternative ideas.

[DaFool]

I'm a Blade Engine refugee as well, just like Rika-chan. I don't think you guys are clique-ish at all. I mean, I come here and post like crazy and contributed to certain threads going like lightning speeds, preaching like some insane pastor despite not yet having released any VN like any of you And yet you all took it all in good faith.

The thing is, and what brings me back to this forum, is the level of intelligence of the people. Every topic is downright technical, and there's hardly any fluff at all. No -tard posts, which I like very much. There's no need for post deletions. The fact that this is a gamemaker's forum means that people are already committed to the fandom and are willing to go above and beyond mere consumers of the culture. Also (and I'm not trying to suck up by the way), PyTom as a forum admin is more personal and open to people compared the the Blade forum admin. The way the Blade admin posts seems to suggest he's just being paid to browse the forums and he would actually like that there be FEW posts so he wouldn't have to answer all of the complains.

Take it on a most recent thread where the Blade admin stated "I hope this will be my last post on this subject..."
That is no enthusiasm at all. If that is professionalism, I'd rather get help from the hobbyist who really loves what he's doing.

I'll admit though, Rika-chan is right that the learning curve for Ren'py is more like a learning cliff. Let me share you my secret of how I got started. Remember that webcomic that recently got ported over to a Ren'Py kinetic novel? Jake's pxi-script here

http://lemmasoft.renai.us/forums/viewtopic.php?t=1143

I took the 'game' folder of that and placed it inside the Ren'Py distribution after renaming the original folder to 'gameold'. Through trial and error I modified the script and learned all about scene and character definitions, scene transitions, pauses, pans and zooms...basically all I ever really needed since I'm more a KN kinda person!

As for the website, I don't really care even if its a static circa 1997 geocities website (Hell, even Retas Pro -- the professional software used to make almost all anime -- had such a basic website until recently). It had all the info I needed. The only thing was that it was confusing when it was PyTom's or mikey's and they just crossreferenced each other without much consistency.

[Jake]

- On a software development page, color schemes and images only distract from the purpose of the page, which is to direct people towards the development resources they need. See http://apache.org/ and http://w3.org/ for good examples of development pages. Imagine how much easier http://emule-project.net would be to navigate if there were no colors or images on it at all.

I think that the difference of opinion I have here is that this is a fine point of view to take when you're talking about a development resource like the W3C or the Apache website, which are only intended to appeal to people who already know what they are and have the technical knowledge to understand them properly. Ren'Py, on the other hand, should be perfectly usable for someone who has practically no previous programming experience, but designing the website to look like a programmer's resource would quite possibly put them off before they even downloaded it.

A 'comfortable' website for the average end-user means shiny 'professional-looking' graphics and friendly over-explanatory simple text, where a comfortable website for a programmer is one where dense information is available at a single click and there's no showy stuff getting in the way of the content. 'Normal' web users, rightly or wrongly, have been trained to look for links to single-item pages rather than looking for the same title on a multi-item page. Currently, the Ren'Py website looks a lot like a programmer's resource and not very much like an end-user product, which I suspect helps contribute to the apparent image that it's complicated to script for.

(One could argue that people who get scared of programming are less likely to produce anything in the long run anyway, but I'd prefer those people have as many of their psychological hurdles removed as possible, myself.)

(Although really, I've never liked the W3C website, myself...

[DaFool]

Good point, Jake.

I once worked as support for Redhat, and a common complaint I got from desktop / end-users is regarding the website. In fact, take at look at it now:

http://www.redhat.com/

If you're not a techie already, the first thing you might think is WHAT THE F*CK IS THIS SITE?

But if you know what you're looking for, you'll recognize: "Knowledgebase, yep just what I need... Or GFS...awesome...

It's basically the same reason why Windows always ruled over Linux. Sure its crap and has less customization, but its NON-INTIMIDATING.

Now, the question for Ren'Py, do we want to be Windows? Or Linux?

[Jake]

Now, the question for Ren'Py, do we want to be Windows? Or Linux?

If it wasn't for Apple's lousy desktop market penetration, I'd say "Neither - Ren'Py should be like OSX; as accomodating as Windows and as flexible as Linux!".

Curse Steve Jobs and his "high end equipment for aesthetes" marketing strategy!

[mikey]

I agree that the redhat site, while looking nice, is hard to navigate - and had I not known what redhat is, it would take a long time to find out. Very unintuitive.

Anyway, I agree with Shii on the point of simplicity and clarity - the website should be dead-easy to navigate and understand, which is probably what should be our main concern at this stage. I'd definitely think about the structure first and then add some design touches later. Maybe the best way to test the functionality is to make a text-only draft page and when everyone is happy with its navigation style and structure, give it to a designer to style it up.

As a complete non-programmer, I also agree that it should be "friendly", the texts, especially at the main page should create an inviting atmosphere and inspire - show what can be done. A one-click download of the latest engine version and that's all that's needed to awake interest.

However, as friendly as the site may be, I should also point out that Ren'Py in indeed a tool, and you need to learn to use it. I understand if Blade seems easier (even though it doesn't seem easier to me... now), but that's a technicality. You can't expect Ren'Py to generate the whole game for you, so of course you'll have a learning curve.

And I think a lot of the learning will come from experimenting. Changing this and that, seeing what it does. Therefore I think that very simple sample games are the way to go - in many ways they are a quicker alternative to a lengthy tutorial.

Hmmm, slowly, maybe we should get working ^_^.

[Alessio]

Your reference manual is dry and obtuse. Half the time, I barely even know what you're talking about.

That's a good point indeed. I think what the manual mostly needs is examples with real-life data for every parameter (e.g. using the "$" sign and real values) and/or a clearer description of what it really does. That would be a good reference for hardcore techies as well as for non-Python people.

Proposal: What if we copied the current documentation to an editable page (Wiki?) where every user could add examples and explanations? (Speaking for myself, whenever I find out how a function works I'm writing examples down for later reference, and it would require only little effort to add some explanation to a Wiki as well.)

Same goes for a FAQ document - it'd be easiest if (at least in the beginning) everybody is able to add text to it.

Some links would be nice. (...) there's an interesting "Ren'Py Trac" page, but I only found it by searching through the forums, which I guarantee most will not do. God knows what else I'm missing.

I made the same experience. I'm using my own bookmarks because I'm afraid that I won't find some pages anymore otherwise. We'll need an exhaustive link list on the new website.

PyTom finds it easier to answer specific questions on here- then develop a document that will try to address all questions any new comer could have. Currently this works- but only because the community is relatively small.

That's the point - if we succeed in convincing more people to use Ren'Py, there will invariably be an increase in posts. And then it will be much harder to answer all of them. That's why we have to provide a good FAQ and a good documentation.

[PyTom]

I have no problem copying the documentation to a wiki... provided people are willing to actually edit it. I was actually experimenting with that a while ago:

http://lemmasoft.renai.us/forums/viewtopic.php?t=1029

But noone seemed interested in editing it, so it went out of date. There's also the fact that wikis use style-based markup, and I prefer semantic markup.

I'd be happy to work with a group of people who are willing to edit the RM. I'd recommend starting with the HTML version from 5.5.4, as the sources I use are a mess, and deserve to be thrown out. For what is an open question... I tried doing it in trac, and things like linking around are much harder then they should be.

A complementary idea is that an updated RM might be able to link into an updated demo game.

[PyTom]

hmmm... regarding Rika-chan's comment, how about a gui for renpy with buttons and everything that automates writing the game text? or adding simple stuff like music, story branches etc. Sort of like the adrift editor.

This is really hard, as best as I can tell. But I haven't seen the adrift editor, I'll check it out when I get a chance.

btw, from a distance, new Eileen looks like Akari (to heart)

This isn't a coincidence... Akari (from the cover of the To Heart manga) was the character I had most in mind when designing Eileen. Heck, even the names mean the same thing. (But that's also related to the story Eileen was originally designed for... maybe I'll disclose that project some day.)

[Alessio]

noone seemed interested in editing it, so it went out of date.

I was more thinking of the parts from section 24 (Displayables) onwards, since I've noticed that's what I mostly use when trying to figure out how something works. Which part will a newbie be reading mostly? That's what we should probably focus on first.

Updating the documentation will be a lot of long-term work for more than one person, and therefore require a good way to coordinate the efforts, but I see the problem with the Wiki format not being the best one. Ideas, anyone? Especially since schedule-wise many of us may find it easier to add/edit things whenever they pop up/when time allows, as opposed to re-writing the documentation line by line. (Correct me if I'm wrong, just doing some brainstorming here...)

[PyTom]

I was more thinking of the parts from section 24 (Displayables) onwards, since I've noticed that's what I mostly use when trying to figure out how something works. Which part will a newbie be reading mostly? That's what we should probably focus on first.

Um... well, the RM isn't really intended for newbies. (That's what tutorials are for.) But I will point out that sections 2-24 have been rewritten recently, so it's points south that really need improvement.

A second problem with the RM is that it can only be built on my machine at the moment... We really need to make it so anyone can edit it, which may mean reformatting it. At the same time, I'd prefer not to make it so I have to write:

Code: Select all

<a name="Move"></a><table><tr>
<td valign="top" class="funcname">Move</td>
<td class="funcsig">(startpos, endpos, time, repeat=False, bounce=False, **properties):</td>
</tr></table>
<div class="funcbody">

<p>
Move is similar to Pan, insofar as it involves moving
things. But where Pan moves the screen through an image, Move
moves an image on the screen. Specifially, move changes the
position style of an image with time.
</p>

<p>
Move takes as parameters a starting position, an ending
position, the amount of time it takes to move from the starting
position to the ending position, and extra position
properties. The positions are given as tuples containing xpos
and ypos properties. The positions may be integer or floating
point, but it's not permissable to mix the two. Repeat and
bounce are as for Motion.

</p>

<p>
The following example moves a ball from the upper-left to the
lower-right of the screen, taking 10 seconds to do so.
</p>

<pre class="example">
<span class="keyword">show</span> ball <span class="keyword">at</span> Move((0.0, 0.0), (1.0, 1.0), 10.0,
                  xanchor="<span class="string">center</span>", yanchor="<span class="string">center</span>")
</pre>

</div>

Since that seems unmaintainable. (Right now, I write something like:

Code: Select all

<function name="Move" signature="startpos, endpos, time, repeat=False, bounce=False, **properties">

<p>
Move is similar to Pan, insofar as it involves moving things. But where Pan moves the screen through an image, Move moves an image on the screen. Specifially, move changes the position style of an image with time.
</p><p>
Move takes as parameters a starting position, an ending position, the amount of time it takes to move from the starting position to the ending position, and extra position properties. The positions are given as tuples containing xpos and ypos properties. The positions may be integer or floating point, but it's not permissable to mix the two. Repeat and bounce are as for Motion.
</p><p>
The following example moves a ball from the upper-left to the lower-right of the screen, taking 10 seconds to do so. 
</p>

<example>
show ball at Move((0.0, 0.0), (1.0, 1.0), 10.0,
                  xanchor="center", yanchor="center")
</example>
</function>

Actually, for most functions, the documentation is taken from the code... but I'd be willing to change that.

It would be also nice to set up a system of automatic cross-references between the new demo game, and the reference manual. But making the RM understandable takes priority.