2010 Year in Ren'Py

[PyTom]

(last year's post)

Since it's traditional that the first thing I do in the new year is to look back at the old, It's time for my new year's post.

First up, interest in Ren'Py, as measured by hits on our website and downloads, has steadily increased since year. We had a quarter of a million visits, and Ren'Py was downloaded more than 19 thousand times. This data had a few drop outs in it, so I don't want to be more precise than that - but it looks like interest in Ren'Py is staying steady.

I've totally lost track of how many Ren'Py games have been released. The games.renpy.org website hasn't really taken off in terms of people adding things to the site. (Perhaps because it requires registration?) There are also games being released from outside the LSF community. So, in general, I have no idea how many games came out this year. This is something I want to address going forwards, but I'm not sure how.

There were four releases of Ren'Py in 2010. One was a major release, and three were bug fix releases. In general, the Ren'Py development in 2010 had two directions. The first was a focus on supporting new hardware. OpenGL support was added to Ren'Py, and Android support is all but done. The second was the addition of a screen system, which makes it easier to customize the look of the game.

As I joked on Twitter, at the start of 2010, the problem was that all Ren'Py games looked alike. Now the problem is that nobody knows that they're playing a Ren'Py game. I think that's a far better problem to have. I'd like to thank everyone who's figured out how screens, ATL, and the new customization abilities have worked, and have spread that knowledge to the community.

2010 marked the beginning of a rewrite of the Ren'Py manual. That's going to be a very long process - but especially after the progress of the last week, the new manual is becoming progressively more useful. Several other people are putting together tutorials that explain how modern Ren'Py programs work, so as we go forward, we should be getting some really good examples.

The 6.12 release is coming together nicely. This release will add Android support, and a host of other improvements supporting it, such as improvements in OpenGL drawing performance, and improvements in the prediction system. I don't have an ETA on 6.12, other than "soonish".

Once 6.12 is out, I'm going to change the release process to become more agile. I think it's currently a major problem is that I'm not getting improvements to Ren'Py out on a timely schedule. The reason this is a problem is that changes to the engine can be really helpful in getting a game made - but even if someone suggests an improvement, by the time it's qualified and out, the person is done with their game, and can't benefit. So this needs to improve.

At least part of the problem is the current major-release, minor-release distinction. On at least one occasion, I wound up delaying a feature (OpenGL support) for a couple of months because I wasn't sure it was major enough to justify a major release. This is even worse for minor features - which have to wait for a major release to show up. I think I want to come up with a development process that tries to keep a current releasable Ren'Py around at all times, and then have more frequent (perhaps monthly or month-and-a-halfly) releases.

With 6.12, the 2010 themes of hardware support and customizability will be be pretty much where I want them to be. For 2011, I want to focus on improving the experience of the person making visual novels and story-centric games. I need to look at these games, and figure out ways in which the maker's experience can be improved by improvements to the Ren'Py language and tools. While I don't think any of this will hurt simulation games, at the same time, I don't think those will be a priority in 2011.

I think part of the problem has been that I've become a bit disconnected with the game-making community. In prior years, I was part of the team developing a number of visual novels, including having directed a few of them. That hasn't happened recently, and it's hurt Ren'Py, as much of the recent stuff (ATL, SL, etc) has been based on theory, rather than practical experience.

So I'd like to find projects where I can participate as a team member, during the development process. Even though that might take some time away from Ren'Py development, I think the improvements to Ren'Py will justify it. I also need to play more games, from both the English and Japanese communities - as games are what really motivates me.

I find myself really enjoying working on Ren'Py. I've come to regard it as my contribution to the world, both the software itself, and the community and art forms it's fostered, which will hopefully outlast it. Not like Ren'Py is going anywhere - I enjoy working on it, and incredibly varied range of challenges it offers.

Special thanks go to Incendium, for the new Ren'Py website, and Sake-Bento, for taking over some of the forum moderation duties. Not having to worry about the forums as much has been very liberating, and that has let me focus on Ren'Py when it needs it. So that's a huge improvement to feve

Finally, it's really the community that makes Ren'Py what it is. Ren'Py is neat as a technical challenge, but there are a number of those - what makes Ren'Py special is the art it enables. To everyone who reports a bug, answers a question on the forum, provides art or music for people to use, reports a bug, or provides thoughtful comment on a game --- everything you do, big or small, is an important step in helping that art come into existence. So be proud of even simple things. To the incredible community of makers, keep making --- what you do is magnificent, and I'm so glad to to to my small part.

Everyone, thanks for letting me keep making (faster, more portable, easier, and better) paintbrushes.

[jack_norton]

While I don't think any of this will hurt simulation games, at the same time, I don't think those will be a priority in 2011.

What about RPGs?
Jokes apart, with the latest screen languages and once drag&drop is done, I really think won't feel constricted in any way by Renpy when making my kind of games. Since to make them you must use mostly python and screen language anyway. I think you're making a good move to improve the story-based games, even if honestly I don't know what you could improve! Perhaps if nothing else comes to mind, you can always start porting it to more platforms
Thank you for making such a great tool!

[Samu-kun]

Good job getting everything done this year and I'm looking forward to what next year will bring!

[sake-bento]

Despite the fact that it was created based on theory, I love ATL. I think I'm getting the hang of SL, too, and I'm pretty sure I love it. Thanks for all the support. Here's to another great year.

[SleepKirby]

I just started using Ren'Py in the summer of 2010 (oops, almost wrote "this summer"), and it's also been my first experience with helping development of a full-fledged game.

In programming, it seems really tricky to strike a balance between user-friendliness and flexibility (I guess in this case, having different Ren'Py games look different), but Ren'Py has hit this balance quite well. Multiple people on my team have participated in writing our game's script; and in the meantime, our menu screens can accommodate nearly all the features we can think of, thanks to screen language. (And we're just finding out the fancier bits of ATL!)

The community reflects this balance as well. Not everyone here's a hardcore programmer - not even close, in fact - and game makers of all levels can ask for help without being embarrassed. I think that's a wonderful thing. And of course, the forum's so much more than a simple tech support Q&A board.

The Ren'Py language itself isn't perfect, of course, but I'm so impressed at the rate that it's improving! I can't wait to see what will come out of another year of development.

[DaFool]

I've totally lost track of how many Ren'Py games have been released. The games.renpy.org website hasn't really taken off in terms of people adding things to the site. (Perhaps because it requires registration?) There are also games being released from outside the LSF community. So, in general, I have no idea how many games came out this year. This is something I want to address going forwards, but I'm not sure how.

This has been occupying my mind for a while now, but the fact of the matter is that it's impossible to keep track now, simply because the 'niche' for visual novels has expanded. When we're talking about visual novels we're no longer just referring to just translated Japanese eroge (the traditional definition) nor small poetic works (e.g. al|together 2005/2006 games and the kinds of games that defined these forums from 2005-2009). Thanks to a few pioneering commercial and independent game makers, visual novels are 'encroaching' more and more into the casual gaming space, as well as the retro indie scene (see the success of games like Air Pressure and Digital: A Love Story). Casual games in particular, while right now must contain simulation and/or RPG elements, might be more accepting of more narrative in the future, especially with tablet PCs.

Just this past Christmas a visiting nephew expressed his desire to port children's books by local publishers to iOS for the iPad. I said why not Android and wait for the handheld tablet market to reach mass market prices (as of this writing the Samsung Galaxy Tab still costs as much as a full notebook computer), when school-age children can use them like their DS? Now that's a business opportunity made possible by Ren'Py.

We can blame the recent splintering of the community on politics or whatever, but visual novels have come to mean more than our narrow definitions, so it's no surprise to find that the specific types of games we liked are only a small subset of the larger genre. It is imperative for game makers to research their target market thoroughly so they know who exactly their audience is. Does their game suit DLsite? Tigsource? The casual portals? In hindsight, the creation of the separate GxB subforum was one of the wiser moves of 2010. It's essentially advertising to all the teen girls on deviantart: "Hey, instead of just drawing, why not make a game?"

For 2011, I want to focus on improving the experience of the person making visual novels and story-centric games. I need to look at these games, and figure out ways in which the maker's experience can be improved by improvements to the Ren'Py language and tools. While I don't think any of this will hurt simulation games, at the same time, I don't think those will be a priority in 2011.

Ren'Py is no longer just a visual-novel making tool. It can now be considered a full game-maker's IDE:
http://forums.tigsource.com/index.php?topic=15713.15

I've been waiting for the longest time for someone to make a battle/walking framework such as Jake's battle engine, and now with drag n drop I can make my dream game.

2009-2010 may have been tumultuous times in terms of shifting audience, expectations, as well as big changes to the engine. But it also marks a big expansion of the audience, and Sakevisual can be credited for almost all that.

But I promise you that this year of 2011 will be the best year in Ren'Py yet. I fully expect almost all the long-term projects on Planet Renai to conclude before the end of this year. They'll of course never match Katawa Shoujo which is also slated to release this year, which is probably the only game to meet the standards of the hardcore Japan-centric community, who also now have plenty of quality full-length Japanese visual novels to play. In fact I'd rather that the stigmatizing term "OELVN" would just die. Instead of 'OELVNs' we'd have casual games, GxB games, simulation games, tablet games, interactive stories, experimental games. Most would fall under 'anime-style games' made by non-Japanese. JVNs would be the real niche.

[Aleema]

With 6.12, the 2010 themes of hardware support and customizability will be be pretty much where I want them to be. For 2011, I want to focus on improving the experience of the person making visual novels and story-centric games. I need to look at these games, and figure out ways in which the maker's experience can be improved by improvements to the Ren'Py language and tools. While I don't think any of this will hurt simulation games, at the same time, I don't think those will be a priority in 2011.

Naturally. Ren'Py is a story-telling engine and until you've exhausted yourself improving that experience, catering to every genre of game is impractical. Though, the VN style of story-telling has been commonly paired with all styles of gameplay, significantly the sim and the RPG. And if I were making Phoenix Wright, for instance, the majority of the game is them talking, so I'd choose an engine that does sprites talking very well, over an adventure engine for that brief part where you find clues. Sim games are just "push button, show stat" anyway, and you provide ample support for that already. RPGs would need the real help, but I don't know of anything you could do, engine-wise, that would do anything that the programmer shouldn't be doing for himself anyway. If I could hope for anything, it's for better mini-game support. While making my mini-games, I constantly run into walls where I'm just "so I can't do two things at once!?" and such that discourages it heavily. But since you allow Pygame integration, I suppose that's already done. ^^; (I can dream though, can't I?)

ATL and SL were big additions to Ren'Py that had me salivating back when they were theory. In use, I fumbled with them, but now I think that's just because they were something I had to completely relearn. I still need the old Animation widgets to work, because some code that I use needs variables to equal animations than setting them as images. ATL also takes up a HUGE amount of space since everything has to be on separate lines. Outside of that, the potential for it is enormous and I've already used complex animations successfully (they just scroll for multiple pages from length ... -_-). SL liberated us from one set configuration for screens, which is awesomeawesomeawesome. Before I would've scratched my head endlessly on how to rebuild the save screen, but now I can do it and add custom preferences to the options screen and yay. I've yet to really use it for minor screens in the game because I haven't coded a new game in the recent releases yet. But I hope to in the future and hopefully it will be easy to use.

I also want to throw in that 2010 (summer) was the beginning of the GxB boom. Before then, there were only a handful of otome games, and even fewer female developers. Can't wait to see the future of it all~

In fact I'd rather that the stigmatizing term "OELVN" would just die. Instead of 'OELVNs' we'd have casual games, GxB games, simulation games, tablet games, interactive stories, experimental games. Most would fall under 'anime-style games' made by non-Japanese. JVNs would be the real niche.

Agree. And "OELVN" takes too long to type, too. xD
We should be growing up and becoming independent any day now ...

[PyTom]

While making my mini-games, I constantly run into walls where I'm just "so I can't do two things at once!?" and such that discourages it heavily. But since you allow Pygame integration, I suppose that's already done. ^^; (I can dream though, can't I?)

For minigames, Ren'Py really wants you to program in an event-driven style, using UDDs. I think that UDDs can do everything pygame can, and often faster and better.

ATL also takes up a HUGE amount of space since everything has to be on separate lines.

That's not right - as long as a block isn't involved, you can separate statements with commas. So something like:

image foo anim:
"a.png", 1.0, "b.png", 1.0, "c.png", 1.0, repeat

should work.

Agree. And "OELVN" takes too long to type, too. xD
We should be growing up and becoming independent any day now ...

I've been using EVN, as necessary now, such as in the title of Planet EVN.

[Aleema]

Thanks for the reply, Tom! I'm glad I'm wrong about ATL, and I will happily condense all my animations now. I assumed it had to be comma-less, separated by break lines because that's what every example and documentation I saw looked like. ^^;

For minigames, Ren'Py really wants you to program in an event-driven style, using UDDs. I think that UDDs can do everything pygame can, and often faster and better.

Perhaps it is just a logic flaw on my part, so I'm just telling you how I felt when I decided to sit down and code some mini-games, as I'm sure many other developers would like to do. If ATL could support imagebuttons, that would certainly solve some parallel problems. I will read up on UDDs right now, however.

[jack_norton]

Aleema for minigames I think the new screen language is powerful. Combine that + ATL and you can have crazy stuff running (see Planet Stronghold hehe). I honestly never used a UDD except for the tooltip in any Renpy games I've made! I noticed Planet Stronghold combats are a bit slower sometimes, but maybe because of all the amount of stuff that's going on on the screen ^_^;

[Aleema]

Mini-games are 100% possible, yes. With my limited knowledge, I had to abandon any mini-game that required multiple displayables to be shown at staggering, overlapping times (like my Elite Beat Agents clone I almost got working ... Or my Guitar Hero attempt. -_- yes, they're for my music game). If it's possible to do SL+ATL to accomplish these, then I need to get back to work.

[jack_norton]

Real time stuff is a bit tricky but should be possible using classes (I never tried that honestly). Maybe even with timers, but I think classes would be a better approach (see the Sprites class pytom documented recently).

[shim]

I have used ren'py to create a visual novel and a minigame so far. I chose ren'py over all other options for one specific reason: its superb provisions for one-click cross-platform distribution (without the need for owning all these platforms). For me this is ren'py's killer feature (together with it being written in python - my favourite language) !!

For the future I hope to see improvements in:

- minigames: bounding rectangle based collision detection; some framework support for integrating animations in minigames (for things like walk cycles and explosions - maybe anim.State could be useful in that context, but unfortunately it's deprecated now); a good general purpose 2d vector class (now I basically implemented all this stuff from scratch; I just learned that there's a sprite manager now which may ease some of these issues already...) I realise that ren'py was never meant to be a completely general purpose 2d game engine, but it's so close to being one already it almost hurts

- sound: have a kind of STL (sound transformation language, which would allow to gradually pan sounds from left to right speaker, or to dynamically apply audio effects like "echo") - sound effects imho until now have been treated as somewhat of a second-class citizen in ren'py.

- networking: I've successfully included python's xmlrpclib in my minigame to communicate with a google app engine hosted hiscore table which adds an element of "competition" between different players of the same game. Luckily xmlrpclib is a single-file pure-python library, so it was easy to add and keep everything cross-platform. Unfortunately it is rather buggy in versions of python prior to 2.7. This also requires a hiscore table web application capable of processing xmlrpc requests (which may be out of the scope of the ren'py framework but it's almost trivial to make in a web framework like web2py (see http://web2py.com))

- cookbook and tutorials: to give practical examples of all the cool stuff in action. Hopefully I can contribute something more there myself I'm afraid I may already have reimplemented stuff that was easier to accomplish with existing elements. Without cookbook recipes one may never think of using existing elements in a certain way.

Having complete freedom to extend the existing framework is incredibly useful.
Many thanks for the splendid framework that ren'py already is!

[jack_norton]

I agree with you completely. One click build install for 3 platform is something that I don't think ANY other engine (even commercial ones) has. The only downside is that probably renpy games cannot be distributed in the new mac appstore, but after all, who cares about it?
And being based on a powerful (probably THE most powerful) cross-platform language like python makes working with it a real dream, since you can easily do thing like you describe, which would take WEEKS of work using C/C++ or would require the purchase of network libraries.
I agree also on the sounds. A pre-caching of sounds for example would be useful. Also during Planet Stronghold battles I noticed sometimes the sounds/music scatters a bit, I wonder if is because renpy doesn't use HW accelerated sound hardware?

[Klawzie]

2011 is the year I've promised myself I'll get off my bum and stop procrastinating, intimidated by the coding necessary to tell the stories I want to tell.

I chose Ren'py over other possible engines because of the combination of the least intimidating interface I've looked into, cost (free as opposed to the only other engine I heavily considered which is meant to have an even less intimidating interface), heavy documentation, and active, friendly, helpful community. Actually, the community is pretty high up there. The fact that the creator is still active in the community and active in improving how the engine functions is also a huge plus.

I'm not active enough in this community (or the game-making/visual novel community in general) to give you any insight into what discourages people who make people who create games using the Ren'py engine not want to share them on the site. The only thing I can figure is that they don't want the potential competition or distraction of their players looking to other game-makers. But that's pure speculation with absolutely nothing to back it up.

But if someone could point me in the direction of an explanation of the "By Gameplay" section, I'd appreciate it:

By Gameplay

Visual Novel
Kinetic Novel
Role-Playing Game
Simulation
Other

I'd love to know what the differences are as I apparently don't play enough of this sort of game to have any idea. Perhaps that intimidates those people who don't know either? I'd hate to misplace my game and have the hardcore developers/gamers look down on me for not being aware of what the difference between one and the other are. So many lines blur sometimes. I swear I've looked everywhere on the site to define the differences. ^^;

I hope people don't feel I've wandered off-topic into dumb n00bville.