Lemma Soft Forums

Now that 6.11 is all but out the door, I've started to think about the next few directions I want to take Ren'Py in. In no particular order:

Maintenance

The goal is to get maintenance releases of Ren'Py out on a monthly or bi-monthly basis, as necessary. I don't want another huge gap.

Open up the project

I'd like to start to get Ren'Py to the point where it's a more open project. Not being able to do so has been something of a problem of mine, as I'm not the best at working with other. But I think it's time that changes. I'm looking for people to contribute to the Ren'Py project in the following areas:

- Core Development - Helping with the core parts of Ren'Py, including speed optimizations and porting to new platforms.
- Displayables - There are several new displayables I'd like to add to Ren'Py, including draggable things.
- Themes/Interface designs - The default Ren'Py look could really use a facelift.
- Frameworks - Ways of helping users begin their projects.
- Tools - Like better editor support and so on.
- Documentation - We could always use documentation writers and editors.

And of course, please suggest anything else you're serious about working on. Core development is perhaps the hardest of these tasks, as the core isn't very well documented. But having someone work on it with me is the only way that will improve.

I've bumped this forum up to the top page to reflect this as a new priority.

Documentation & Tutorial

My goal is to write a section of documentation a week until the manual is entirely in the new format. I'd also like to finish updating the tutorial eventually.

Performance Improvements

Before I can port to mobile platforms, I want to increase the performance of several parts of Ren'Py. My current plan is to accomplish this by rewriting portions of the rendering code in cython. This should improve algorithmic efficiency and raw performance. I'd like to get things to the point where having a few hundred transforms is a sensible way of doing effects. This will also get normal-case rendering to the point where I'd feel happy with it on a mobile platform.

Automatic Update

I'd like a system that can automatically update Ren'Py, only downloading the files that have changed. As the previous thing will require compiling binaries for some otherwise-simple changes, I want to be sure there's a good way to get those on the system. (For 6.11, a lot of testers downloaded a lot of relatively large Ren'Py releases - I'd like to avoid that going forward.)

Of course, compression and cryptographic security will be a part of this. I did some work on this today, to the point where it works sans-gui.

SpriteManager

I'd like to implement a SpriteManager class, that provides a convenient way to manage a large number of Transforms, as they are used as sprites. This is intended for use as raw material for frameworks and the like.

AlphaDissolve

This will be a displayable that takes 3 displayables: Old, New, and Mask. Where mask is transparent, Old is shown. When it's Opaque, New is shown. The idea is to provide a tool that's similar to, but more general than, ImageDissolve, and one that can leverage ATL and the like.

Text

I need to eat my peas and rewrite Text, which is quite hairy right now, and needs some performance improvements.

Unique Persistent Names for Say Statements

This is a more obscure feature, but one I think will be useful to the top 10% folks. I'd like to give each say statement a unique identifier based on its text and the preceding label. When a say statement occurs, the character will be able to retrieve the identifier, and use it to control display.

Although it won't be enough on its own, this is a necessary bit of infrastructure to make things like automatic voicing and floating frame director-style vns a reality.

Website

The Ren'Py website needs a redesign, badly. We're working on it.

Anyway, these are my thoughts about where Ren'Py will immediately be going. Android is in the cards, as is native client when it comes out - but this is probably where I'll want to go before them.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

This will be a major turnabout Just say a word and will help, and I bet there are many more folks out there, that would be happy to contribute personally to Ren'Py in one way or other. Seeing such things in the morning makes me happy.

Regular maintenance could become something really useful, as it might eliminate any possible future bug occurences. To much new versions in a short time is a bit of an hassle, but bi-monthly updates would be great, and they are possible. With strict maintenance, there's always a bigger chance less errors will get pass and any that will, might be able to spot before they undergo any more serious "mutations"

Opening the project will propably be the biggest and most important decision made so far. Ren'Py surely could use some more help outside, and because it was always free and open to begin with, there's only a need for dedicated individuals willing to put effort to improve it. I'm not a good programmer myself, but I have experience in GUI/interface design; I've made few site designs and I'm a computer graphics artist, so I could posibly lend a hand in themes and their design, as far as there will be not much hard coding. I can also write documentations and help files, it's nothing new since i'm doing this in my work all the time I hope you'll find someone as good as you, that would be interested in helping with core programming. Along with any performance improvements, this might help Ren'Py not only to become a tool for amateurs/hobbyists but also serious developers.

I already see many interesting features, that Ren'Py surely could get good use of; automatic support, which many nowaday programs have, draggable objects could possibly make Ren'Py far more powerful and allow the games to look more beautiful, give better gaming experience and even allow to make very complicated interface designs. With new ATL this could enable people to write incredibly looking games New tools would be also great. I like both Scite and Jedit, it would be intersting to see some new useful ones, maybe content managers and string renamers that could help ease the work for people with far more bigger game assets. It's still propably far to early to talk about those, but originally inlcuded support applications could prove useul. I'm sure there are people, who already know what could be done with that.

Spritemanager would be neat, as well as the refreshed Alphadissolve fuction, but:Ohmygod. you're joking, right? Floating frame director-esque games, curtesy of LittleWitch - this would be damn awesome. I've already gave a few thoughts and somehow managed it would be hard to make such an engine without anything that could point to the each dialog cloud, as it has to have some coordinates, and with earlier versions of Ren'Py this propably wouldn't be possible without much hardcoding. As we talked earlier, something beggining along the lines of: e (x, y) "Hello, world." would be neat. For those who don't know, I'm talking about this:With OpenGL support, it would be posible not only to easily render such frames, but also scale and make them look anykind we would only like. This would work perfectly along with screen scaling. I'm really interested in that, since I would like to pass from the traditional textbox and use such newer and more dynamic story presentation methods instead. Anyway, textbox has to be available anyway, because you can't manage to show everything with such floating frames, and they work the best only in generic scenes, when we have interaction beetwen more than two characters and want to show their sprites on screen.

By the website, you mean a total redesign to give it another look and possibly more clarity & functionality? Does this mean you're planning to leave the wiki engine and possibly make the site on different site management system, like joomla or wordpress, or even rewrite it manually from scratch? Or did you mean only layout and content redesign? It would be nice to give the site a more open designation, and add new possibilities.

Also, don't forget about the forums, because like it or not, it's our home and place where all of us gather together. It needs tweaking, badly and by that I mean changes on all the levels (I don't mind the original PhpBB look, but forums could use a new, neat look resembling the one from main Ren'Py site). I remind that, while the forum could just go as it is, it would surely benefit more from such cleaning; it is inevitable and has to be done, in order to maintain everything in a proper manner. Restructuring LSF, along with a new group of moderators and community helpers, as well as some rules would be the best choice to go on with.

Anyway, I'm really looking forward to all of this. If you have a bit of time on hand, could you precise what has to be exactly done/what would you like to see done by the others? I can contribute, just say whats need to be done, as freedom is greatly appreciated, to much of it can screw things out.

_________________
http://www.visual-novels.pl/ - Polish visual novel translation and development community
------------------------------------------------------------------------------------------------------------
Wise men search for answers. Don't be foolish, use the force.
Join us on official Ren'Py IRC!

Even though I don't have enough technical knowledge to understand most of what Tom said, I am glad that the OpenGL powered renpy is going to be released soon. Great, nice timing. Then I can program Homeward with OpenGL support from the very beginning. I'm looking forward to finally being able to add bigger and more complicating particle effects and, gasp, resizing the window. *_*

Now the only major feature I need to wait for is to make the text fade in as it scrolls. Then Homeward will have all the graphical features that I want... Ufufu...

_________________
"A piece of warmth you can return to"
Discussion thread [18+]

Follow on twitter for updates

One Story: All ages version

Development updates on Tumblr

Cool plans! I am especially interested in the auto-update, if could also be implemented/licensed to games (so I'm sure will work better than my own one).
I think also would be nice if people (not you in particular) could produce framework for various game types, sort of what Jake is doing with his battleengine

_________________
follow me on
computer games

I would say that documenting the core should be one of the highest priorities.

There should be more ways to override certain functions completely within a specific project using a self-contained module one would be able to just drop into the project and instantly use in the rest of their script. I basically shouldn't have to ask you to include an alteration in the "say" syntax to omit what_suffix on some lines while keeping it on others, I should have sufficient information to just go and do it myself, and then post the changes as a self-contained module for everyone to use. Right now, I've no idea where one would stick a screwdriver to do it, and even if I would, I'm pretty sure I could not do that sort of thing per-project.

Certain graphical effects would become much easier to do if we had better documented ways to make new transitions from scratch and have non-realtime per-pixel access. An effect like dissolving a blurred image against a non-blurred one is easy to do -- but only if you know for sure where will you need to use it and what objects will be in the scene, and fairly often you don't. If I could actually grab the screen and blur it once, and then dissolve the result in, that would really be sufficient, but you can't grab the screen, or, for that matter, blur it, even if you can code your own per-pixel gaussian blur function -- and if you can, the actual way to do it is not documented, or not documented sufficiently well for it to be recognised as such.

My personal particular pet peeve with the current RenPy is that there are way too many cases where I have to duplicate code inside the actual script to produce a specific effect. If I want the window to always hide and show with an effect during transitions, I have to always use "window hide" and "window show", I can't leave that to RenPy itself to deal with even though otherwise it hides and shows the window when I expect -- which bloats the size of the script and makes it easy to make a mistake. If I want multiline text with quotes around it, and then break it up with a character expression change, or a sound, I have to manually insert the quotes when otherwise I don't. If a certain character always appears on screen using a complicated combination of ATL sprites floating about and multiple dissolve transitions between intermediary character images derived from the original using im.*, called labels with parameters don't really provide sufficient flexibility to do it -- and I have to write code to generate derived images from files, too, as im.* doesn't take image tags like everything else does. There is no legit way to define your own text tag which would be processed in all cases where text tags are processed, you have to write your own tag parser and then you have to manually invoke it in cases where text tags are processed but config.say_menu_text_filter is not called. (Textbuttons in screens would be a current example when it isn't called but probably should be.)

I basically should be able to separate presentation from actual data much further than I currently am, so that changing a stylistic decision midway through the development would not require me going through many thousands of lines yet again.

It is - mostly because I have to start letting go, a bit.



If you could do this, it would be great. Ren'Py could really use some new default themes, so that people have a choice of themes to pick from when making a new game. I'd like there to be themes that are generic enough to be re-used, while still looking good.



Yes. The idea here is that, once we have the ability to give each line of dialogue a unique name. This name could then be accessed by an in-game editor of some sort, which would let you position the frames using draggables.

Now, this is a big project, and I'm not sure I'll be the one to undertake it. But I'd like to at least make sure the infrastructure is there for those who want it.




Right now, the idea is to move some of the first parts of the website to generated pages. Specifically, I'd like:

- The home page.
- The Why Ren'Py? page.
- The download list.
- New download pages.

To be part of a designed website, that reduces the number of options people have right at the start, where they can be easily confused. The wiki will still exist, for things like the FAQ and Cookbook, places where people have done a good job contributing - but some of the more static "announcement" pages will be moved to a format that's easier to maintain.



That's off-topic here - Ren'Py and LSF are quasi-independent.



Again, one of the big projects that can be done, that I don't have the skills to do myself, would be to come up with new default themes/screens for Ren'Py, in a reusable way.



I'll note that OpenGL is only part of the solution. While it's certainly faster now, it now means that there's a CPU-bottleneck when it comes to rendering large numbers of transforms at once. So that'll be what I'm addressing soon.



This can probably be added. I'm considering making this how Text works (as opposed to type-in), as it would improve performance a bit in GL-mode.



I'll need to figure out the details, but nothing will fundamentally prevent it.



Yes - but it's also one of the least interesting tasks to me. Since I am doing this as a hobby, I tend to focus on things that are more interesting - but as people ask serious questions, I'll begin to write up documentation about them.



A longer-term plan of mine is to move the mechanics for things like the say and menu statements into .rpy code, where people can see how they work, and change them. (I'm expecting this to be in 6.12, so somewhat later here.)




What do you want your text tags to do? You can already create custom text tags as styles, and then use {=style}my test{/=style}. As people join as developers, you'll see that a balance has to be struck between flexibility and implementability.



That's probably true, and I think we're already fairly good at this. But we can always be better, within reason - it's hard to anticipate everything everyone will want.

One note to people posting - this thread is for things that _I_ plan to implement, and things that _you_ plan to implement, broadly construed. It's not really for things _you_ want _me_ to implement.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

As for docs, I think the most important thing is code snippets/samples. You can understand a lot more just by looking at working code examples (of any kind, UI customization, some screen language examples, etc).

_________________
follow me on
computer games

I think that's true, and if you look at the new documentation (http://www.renpy.org/doc/html/), there's a lot more snippets of code in there. Of course, if people want to help contribute to the documentation, let me know.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

Well, suppose I have a colour used throughout the text for certain particular type of emphasis, and work it out to be shade #xxyyzz, but it needs to be used in character objects who speak with fonts A, B and C. If I use {=style}, I will need to define three different styles depending on which font is currently in use, otherwise the font will be overridden by the style - I can have three different styles derived from the same one which use three fonts, but I can't derive one style with different colour from all three, so I'd have to also use three different style tags. If I use {color=#xxyyzz} everywhere, I'll have to search-replace it globally if I find that this particular shade doesn't work, because I can't {color=variable_name}.

In the end, I have a primitive search-replace function called through config.say_menu_text_filter that does it for me -- at least it minimizes the actual typing I have to do, and it also handles the unicode typographic glyphs that simply aren't present on any keyboard, but make the text look better. But being able to just hook into the tag parser itself would be better, and screen language commands that output text don't call that filter function anyway.


More and better documentation on the internals in particular would make implementing anything we plan to much easier. Same about more documented flexibility regarding internals.

Is there any way you could offer a tarred-and-zipped file that contains these documents at the end of a convenient link so that we can reference these offline if we want to? There could even be a nightly or weekly or whatever script to do this so that updates are automatic. Alternatively, you could put them in some kind of subversion repository (or something similar) and we could keep ourselves up to date whenever you make revisions. I, personally, prefer the former, but you're the programmer and the distributor; you can make decisions however you want.

EDIT: Oh, and as a Python programmer, I'll happily help with the documentation if you need it.

I ship the documentation as part of Ren'Py, it lives in the doc/ directory. Right now, the documentation is maintained as part of the lp:renpy project - but I'm considering splitting it out as its own project, to make it easier for people to work on.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

I believe I could help with writing documentation and implement some displayables, tools and stuff. I don't think I could help with core development since I've just started learning C, but I could probably help with the Python part.

_________________
「A.RK Programmer•Trying to be a DeviantArtist」


Yep, I'm back after almost dying at PyWeek

There is one feature RenPy's text output is missing, for historical reasons, (Japanese doesn't do this) which I am compelled to petition for...

Hyphenation. Which is particularly important if you use justified text, and which will be doubly important for the Little Witch style text bubbles, because they're by definition quite narrow.

Wait, wait, I'm not asking you to implement hyphenation for all languages under the sun, hear me out.

There is a simple modification to text output function that would enable the authors of individual projects to create hyphenation routines suitable for their language, and that modification needs to be in the core. Once it exists, it would be easy to implement an arbitrarily complex or simple hyphenation routine and share it as a standalone module.

• Text output should treat a specific symbol as a soft hyphen. \u00AD (SOFT HYPHEN) is specifically designated for this purpose by the Unicode standard, so there's no reason not to use it. This symbol should have the following properties when printing text containing it:
  • Line break for wordwrapping should be allowed after it.
  • It should not be printed unless it ended up before the line break,
  • It should not be counted for the purposes of calculating line length unless it is to be printed.
• An extra callback for hyphenation functions needs to pass all text that is expected to be wordwrapped through a user-defined hyphenation function.

It's something to keep in mind when you get around to rewriting Text, and I endeavour to provide hyphenation functions for English and Russian for inclusion into the standard library if that feature is available.

That makes a lot of sense, and will be supported when Text is rewritten.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

Well I found some ways to help with the scripting. Jedit has a macro feature so I decided to create some. I made four like for Declaring Images, Defining Characters, adding scenes and audio. They're based of the add prefix and suffix macro that came with it. I added the color picker cause I knew that would be a useful tool. It's just some of the basics, but if you can give me some ideas that could make macros out off that would help users with their scripts, go ahead and tell me. I like them cause they save what you type into them so that you could pull it up again for future use. I have the four if anyone want to check them out. Just extract the folder in renpy/jedit/macros.