Ren'Py Engine
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
- PyTom
- Ren'Py Creator
- Posts: 16096
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Ren'Py Engine
For the past week or so, I've been working on a new visual novel engine. I'm calling it Ren'Py, as it's written in the Python language, and uses PyGame to manipulate the screen. Today, I've finished a short demo using it, which I'm ready to release to the public.
The demo consists of Blue Lemma's Miko explaining the features of the engine, and how to write new scripts for it. So it's not much of a game, but it does at least feature multiple endings.
You can get it at:
http://renpy.onegeek.org/
(Warning: The demo is perhaps the least interesting visual novel ever written, more of a visual manual. Play it if you're interested in the engine, rather than expecting a good story.)
One of the big goals of Ren'Py is to make writing visual novels easier. It does this by featuring a script language that makes showing images and dialogue very easy. The script language also breaks the game up into small fragments, which makes saving and resuming at any point in the game easy.
I'm releasing the current version so that people can give me comments that will guide the future evolution of Ren'Py. It's my hope that having an engine like this will help creative people to make more games, in the same way that engines like TADS, INFORM, and ADRIFT have made writing interactive fiction easier.
While capable of running reasonably-sized games, there are still a few features missing from Ren'Py. There is only one save/load location, and it doesn't check that you have saved before you load. The error messages when bad scripts are used could also use (a lot) of work.
Right now, the only documentation that exists is the demo itself, which should walk you through the basics of writing, or at least modifying, a Ren'Py script. If you have any questions, please post on this board or email me, and I'll be happy to help.
I hope to eventually release an actual visual novel game based on this engine (I'm not yet sure where I will get the art from), but I wanted to make the engine public in the hopes that it will be useful for people considering making their own games.
The demo consists of Blue Lemma's Miko explaining the features of the engine, and how to write new scripts for it. So it's not much of a game, but it does at least feature multiple endings.
You can get it at:
http://renpy.onegeek.org/
(Warning: The demo is perhaps the least interesting visual novel ever written, more of a visual manual. Play it if you're interested in the engine, rather than expecting a good story.)
One of the big goals of Ren'Py is to make writing visual novels easier. It does this by featuring a script language that makes showing images and dialogue very easy. The script language also breaks the game up into small fragments, which makes saving and resuming at any point in the game easy.
I'm releasing the current version so that people can give me comments that will guide the future evolution of Ren'Py. It's my hope that having an engine like this will help creative people to make more games, in the same way that engines like TADS, INFORM, and ADRIFT have made writing interactive fiction easier.
While capable of running reasonably-sized games, there are still a few features missing from Ren'Py. There is only one save/load location, and it doesn't check that you have saved before you load. The error messages when bad scripts are used could also use (a lot) of work.
Right now, the only documentation that exists is the demo itself, which should walk you through the basics of writing, or at least modifying, a Ren'Py script. If you have any questions, please post on this board or email me, and I'll be happy to help.
I hope to eventually release an actual visual novel game based on this engine (I'm not yet sure where I will get the art from), but I wanted to make the engine public in the hopes that it will be useful for people considering making their own games.
-
- Eileen-Class Veteran
- Posts: 1153
- Joined: Mon Jul 07, 2003 4:57 pm
- Completed: Elven Relations, Cloud Fairy, When I Rule The World
- Tumblr: alextfish
- Skype: alextfish
- Location: Cambridge, UK
- Contact:
Cool!
Wow, that looks really cool!
I've seen several people with plans for ren'ai visual novels who're looking for an engine to write them in. There hasn't been any decent recommendations up till now, except perhaps for that text-adventure engine that could just about be twisted to the purpose of a visual novel. But this looks excellent!
I particularly like the way you can run arbitrary Python commands using $. That's got a lot of power.
I've done a bit too much work on programming Elven Relations to adopt your engine for ER now, but I can honestly say if that weren't the case I'd be strongly tempted. And I'm a programmer! The combat system is pretty much the only bit of ER that couldn't be done straightforwardly in this Ren'Py (and even that could probably be done, with a bit of twisting). I guess to make Elven Relations stand out from the masses, I'll have to wow people with the story, characters and romance... ...oh wait, that was my plan anyway
On the feedback side, things you'll definitely need to address are having multiple save slots (maybe just serialize everything and save it to a file on disk selected from a normal file requester), and storing all the referenced data files in some encrypted form so that pokers-around can't just see all the graphics (and text!) Otherwise all games will come with a built-in walkthrough: the script file... -.-;;
But overall, great work so far, and great stuff providing it to the public!
I've seen several people with plans for ren'ai visual novels who're looking for an engine to write them in. There hasn't been any decent recommendations up till now, except perhaps for that text-adventure engine that could just about be twisted to the purpose of a visual novel. But this looks excellent!
I particularly like the way you can run arbitrary Python commands using $. That's got a lot of power.
I've done a bit too much work on programming Elven Relations to adopt your engine for ER now, but I can honestly say if that weren't the case I'd be strongly tempted. And I'm a programmer! The combat system is pretty much the only bit of ER that couldn't be done straightforwardly in this Ren'Py (and even that could probably be done, with a bit of twisting). I guess to make Elven Relations stand out from the masses, I'll have to wow people with the story, characters and romance... ...oh wait, that was my plan anyway
On the feedback side, things you'll definitely need to address are having multiple save slots (maybe just serialize everything and save it to a file on disk selected from a normal file requester), and storing all the referenced data files in some encrypted form so that pokers-around can't just see all the graphics (and text!) Otherwise all games will come with a built-in walkthrough: the script file... -.-;;
But overall, great work so far, and great stuff providing it to the public!
-
- Forum Founder
- Posts: 2005
- Joined: Sat Jan 25, 2003 2:32 pm
- Completed: ToL, Shoujo Attack!, Lemma Ten
- Projects: [RETIRED FROM FORUM ADMINISTRATION - CONTACT PYTOM WITH ISSUES]
- Contact:
- PyTom
- Ren'Py Creator
- Posts: 16096
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Replying in reverse order, since I feel quite contrary today.
In response to Blue Lemma:
I'm not really a Windows guy, but I believe that WS2_32.dll is the
Winsock 2 dll. Python probably requires it, since the exe file
contains a complete python interpreter, even though networking isn't
used at all.
From what I understand, Winsock 2 ships standard on Windows 98 and
above. There does seem to be an update for Windows 95, but it also
comes with an upgrade to dial-up networking. I don't know enough about
Windows to recommend it.
Ren'Py was developed on Linux using cross-platform tools like Python
and PyGame. I only put together a windows binary at the last minute,
since those tools aren't standard on the windows platform.
In response to Grey:
"I wouldn't like to try and write a program to...let people
easily write programs."
Hm... writing programs to let people easily write programs... that's
about as good a description of my day job as any.
In response to Chronoluminaire:
I'm glad you'll recommend the engine.
I didn't really have writing combat in mind when designing Ren'Py. In
my latest batch of changes to the code, I'll be exporting more of the
script functionality to python code, so it'll be possible to
programatically pop up dialogue and menus. They'll also be better
support for large amounts of python code, probably by letting users
pull in their own custom modules.
Of course, the script language will always be the primary way of
writing a game, and that's heavily intended for the visual novel style
of doing things.
My current code base (as of this morning) has multiple save slots, and
a simple way of selecting between them.
How important do people thing encryption of game data is? My current
idea is that the script and game data should be kept in something
simple, like a zip file. This should be enough to protect it from the
casual observer, especially if the file is renamed with a different
extension.
In response to Blue Lemma:
I'm not really a Windows guy, but I believe that WS2_32.dll is the
Winsock 2 dll. Python probably requires it, since the exe file
contains a complete python interpreter, even though networking isn't
used at all.
From what I understand, Winsock 2 ships standard on Windows 98 and
above. There does seem to be an update for Windows 95, but it also
comes with an upgrade to dial-up networking. I don't know enough about
Windows to recommend it.
Ren'Py was developed on Linux using cross-platform tools like Python
and PyGame. I only put together a windows binary at the last minute,
since those tools aren't standard on the windows platform.
In response to Grey:
"I wouldn't like to try and write a program to...let people
easily write programs."
Hm... writing programs to let people easily write programs... that's
about as good a description of my day job as any.
In response to Chronoluminaire:
I'm glad you'll recommend the engine.
I didn't really have writing combat in mind when designing Ren'Py. In
my latest batch of changes to the code, I'll be exporting more of the
script functionality to python code, so it'll be possible to
programatically pop up dialogue and menus. They'll also be better
support for large amounts of python code, probably by letting users
pull in their own custom modules.
Of course, the script language will always be the primary way of
writing a game, and that's heavily intended for the visual novel style
of doing things.
My current code base (as of this morning) has multiple save slots, and
a simple way of selecting between them.
How important do people thing encryption of game data is? My current
idea is that the script and game data should be kept in something
simple, like a zip file. This should be enough to protect it from the
casual observer, especially if the file is renamed with a different
extension.
-
- Forum Founder
- Posts: 2005
- Joined: Sat Jan 25, 2003 2:32 pm
- Completed: ToL, Shoujo Attack!, Lemma Ten
- Projects: [RETIRED FROM FORUM ADMINISTRATION - CONTACT PYTOM WITH ISSUES]
- Contact:
It won't protect it from the casual observer of this forum now!PyTom wrote:How important do people thing encryption of game data is? My current idea is that the script and game data should be kept in something
simple, like a zip file. This should be enough to protect it from the casual observer, especially if the file is renamed with a different extension.
Surely the demo explains just that...just ask Miko about how to write scripts, and follow what she says, while looking at the code to see how things are done sucha as showing text, background etc.mikey wrote:Is Ren'Py free to use, and how do I do it? Since I myself have no programming skills and all... Say if I wanted to use it for my next project, what would I need? A guide? The Python? PyGame? PyTom's permission? Judging from the demo, it is just the thing I would need.
Once you feel like playing around with it then copy all the files with demo in their name (demo.py, demo.exe, demo.rpy, and demo_config), and rename them all to some other name (test.exe,test.rpy etc), then modify the copied and renamed demo.rpy to get yourself familiar with it like changing text, pictures etc.
- PyTom
- Ren'Py Creator
- Posts: 16096
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
In response to mikey:
Ren'Py is licensed under the MIT license, which basically says you're free to use it as you wish, but that I take no (legal) responsibility for it. I picked the most liberal license I felt comfortable with, to encourage growth of the genre. I only ask that I get a copy of the finished product, but that's just a request rather than a legal requirement.
If all you're interested in doing is playing around with what we have now, I'd recommend starting by just making a copy of the whole install install directory, and then modifying demo.rpy with your new text.
Unfortunately, the name demo.rpy is hard-coded in a few places, so simply renaming everything isn't likely to work in the current build.
Demo.rpy tries to walk you through the demo.rpy script file, to give you a taste of the language. If this is what you want to use for your project, let me know and I'll post up a newer release of the software, which allows loading and saving to be mostly controlled by the script, and will probably have support for game directories.
I'd recommend a game developer have python 2.3.3 and the newest release of pygame installed on their system, but I don't plan on requiring them to run the finished product. Interim code drops will just be easier if I don't have to go through the pain of producing a windows executable with each release.
If there's something unclear, you find a bug, have a feature request, or you need help in any way, don't hesitate to let me know. I have the somewhat selfish motivation of wanting to play these games, and so want to make it easy for people to make them.
(I also want to make my own game. But given a complete lack of artistic talent, I think the best hope of that happening is for me to ... um ... borrow art from an anime using a rotoscoping technique.)
Ren'Py is licensed under the MIT license, which basically says you're free to use it as you wish, but that I take no (legal) responsibility for it. I picked the most liberal license I felt comfortable with, to encourage growth of the genre. I only ask that I get a copy of the finished product, but that's just a request rather than a legal requirement.
If all you're interested in doing is playing around with what we have now, I'd recommend starting by just making a copy of the whole install install directory, and then modifying demo.rpy with your new text.
Unfortunately, the name demo.rpy is hard-coded in a few places, so simply renaming everything isn't likely to work in the current build.
Demo.rpy tries to walk you through the demo.rpy script file, to give you a taste of the language. If this is what you want to use for your project, let me know and I'll post up a newer release of the software, which allows loading and saving to be mostly controlled by the script, and will probably have support for game directories.
I'd recommend a game developer have python 2.3.3 and the newest release of pygame installed on their system, but I don't plan on requiring them to run the finished product. Interim code drops will just be easier if I don't have to go through the pain of producing a windows executable with each release.
If there's something unclear, you find a bug, have a feature request, or you need help in any way, don't hesitate to let me know. I have the somewhat selfish motivation of wanting to play these games, and so want to make it easy for people to make them.
(I also want to make my own game. But given a complete lack of artistic talent, I think the best hope of that happening is for me to ... um ... borrow art from an anime using a rotoscoping technique.)
-
- Newbie
- Posts: 1
- Joined: Sun Feb 08, 2004 7:34 pm
- Contact:
Not bad at all 4 such a short time in dev , I've messed around with it a bit and I'm impressed. My own engine's script system is pretty similar to your own, but with more focus on stat/global variable checks; though your gui looks nicer Only thing i don't like is the size of the exe file, but thats just me.
I'd advise some form of scrambling system that you can run your scripts through, that should stop ppl from messing with it. For pic protection, I'm still working on a little proggie that merges the pics together and can be extracted to memory during the game - sure they can be ripped pretty easy if u know what you're doing, but it'll stop most ppl.
Not a bad starting point at all for the non-programmers looking to make their own games.
Hmm... a very good point, when I first started making my engine, I really didn't care, but as it's improved (slowly) and I talked with various ppl, I discovered that most ppl wouldn't want their pics/scripts to be easily available to the average player. (At this time though my graphics amount to little more than a few pics of Miko, that were generously provided on the site)How important do people thing encryption of game data is? My current
idea is that the script and game data should be kept in something
simple, like a zip file. This should be enough to protect it from the
casual observer, especially if the file is renamed with a different
extension.
I'd advise some form of scrambling system that you can run your scripts through, that should stop ppl from messing with it. For pic protection, I'm still working on a little proggie that merges the pics together and can be extracted to memory during the game - sure they can be ripped pretty easy if u know what you're doing, but it'll stop most ppl.
Not a bad starting point at all for the non-programmers looking to make their own games.
Currently working on Project H (New unnamed h-game) visit : http://www.geocities.com/greaterghoul987/
-
- Regular
- Posts: 39
- Joined: Mon Feb 16, 2004 11:11 pm
- Contact:
If you want to encrypt your stuff so that the average person can't read your script or look at your pictures or sound, compile EVERYTHING to a .dat file.
For the script, for the commands, just have a byte (as long as you can't have more than 256 commands, otherwise use an integer) represent each command. I.e., 0 is Say, 1 is Show (for like showing images), 2 is Set Background, 3 is If, ect. That way the average reader can't figure out the flow of the game just by looking at the file.
If you wanna encrypt the dialogue as well, add a number to the ascii value of each letter so that they can't just open up the dat file and read the text. I.e., add 4 to everything, or choose an inverse.
Example of adding
A + 4 = F
Z + 4 = ^ (It's the character that the ascii value 4 after Z is, look at any ascii chart to verify this).
If you wanna be really diabolical, add 70 to everything so that the resulting bytes aren't even letters, making it harder to decrypt. Obviously decrypting for you is easy, just subtract whatever it is you added.
Example of inverse.
A = Z
B = Y
C = X
ect.
A simpler encryption really, I prefer the first one better. As with all strings, a 0 value is a good value to figure out when it's ended... I wouldn't encrypt that.
As for pictures and sound files, just copy them into your data file byte for byte, with whatever header info you need to identify them.
The result is you have one file that contains all of your info and is unreadable by the average person. They can't look at your pictures, they can't hear all the moans, they can't cheat on the dialogue, and they certainally can't edit the game themselves. Obviously any hacker with a hex editor will be able to figure out what's going on, but trust me on this, you are not going to be able to keep everyone from reading your stuff anyways.
I suggest making a game editor that normally works with the files all out in the open, then compiles it to the dat file for the actual game to use. Even if you prefer to work with scripts, making a compiler and decompiler is probably a good idea, as I don't think you want to try and do it by hand:p
Don't make it a format other people can look at easily, such as a zip. Make it your own format, or else people will just go, "Oh a zip file eh? I'll just grab winzip here". Plus it's easier to design your own format lol.
For the script, for the commands, just have a byte (as long as you can't have more than 256 commands, otherwise use an integer) represent each command. I.e., 0 is Say, 1 is Show (for like showing images), 2 is Set Background, 3 is If, ect. That way the average reader can't figure out the flow of the game just by looking at the file.
If you wanna encrypt the dialogue as well, add a number to the ascii value of each letter so that they can't just open up the dat file and read the text. I.e., add 4 to everything, or choose an inverse.
Example of adding
A + 4 = F
Z + 4 = ^ (It's the character that the ascii value 4 after Z is, look at any ascii chart to verify this).
If you wanna be really diabolical, add 70 to everything so that the resulting bytes aren't even letters, making it harder to decrypt. Obviously decrypting for you is easy, just subtract whatever it is you added.
Example of inverse.
A = Z
B = Y
C = X
ect.
A simpler encryption really, I prefer the first one better. As with all strings, a 0 value is a good value to figure out when it's ended... I wouldn't encrypt that.
As for pictures and sound files, just copy them into your data file byte for byte, with whatever header info you need to identify them.
The result is you have one file that contains all of your info and is unreadable by the average person. They can't look at your pictures, they can't hear all the moans, they can't cheat on the dialogue, and they certainally can't edit the game themselves. Obviously any hacker with a hex editor will be able to figure out what's going on, but trust me on this, you are not going to be able to keep everyone from reading your stuff anyways.
I suggest making a game editor that normally works with the files all out in the open, then compiles it to the dat file for the actual game to use. Even if you prefer to work with scripts, making a compiler and decompiler is probably a good idea, as I don't think you want to try and do it by hand:p
Don't make it a format other people can look at easily, such as a zip. Make it your own format, or else people will just go, "Oh a zip file eh? I'll just grab winzip here". Plus it's easier to design your own format lol.
Woot
- PyTom
- Ren'Py Creator
- Posts: 16096
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
My current plans are to allow the script data structure to be stored as a serialized python object, which will then be obfuscated further, probably by applying raw zlib compression to the resulting file. This should lead into a script that's obfuscated enough that, if a person is willing to go through the effort of writing the code needed to read it, they deserve to.
Ren'Py scripts are represented as a higher-level series of objects, so it doesn't make sense to create a bytecode like you suggest. Creating a formal bytecode would be the equivalent of writing a second script parser, and it's not necessary when Python as serialization support built in. The good news is that objects can be placed in any order when serialized, which should make it harder to decode the final script.
I think that this should probably enough to stop anyone but a dedicated programmer from figuring out the script. But that's the case everywhere.
I haven't decided what I'm going to do with images, but I'm leaning to just putting them in a custom file format. The game I'm writing right now will probably require this anyway, as it uses anime screenshots (which suggest jpeg compression) with added alpha information (which jpeg doesn't support).
Such a file format wouldn't be viewable in normal image viewer programs.
I think I originally underestimated how important game authors find this. Personally, I've never been a big fan of protecting people from themselves.
I think my current standard is that I want to stop a casual guy with standard tools from easily getting at the file. If a person is a programmer, all bets are off. I don't think that anything I can do, short of not releasing the game, will be enough to stop a determined attacker who's a skilled programmer.
Ren'Py scripts are represented as a higher-level series of objects, so it doesn't make sense to create a bytecode like you suggest. Creating a formal bytecode would be the equivalent of writing a second script parser, and it's not necessary when Python as serialization support built in. The good news is that objects can be placed in any order when serialized, which should make it harder to decode the final script.
I think that this should probably enough to stop anyone but a dedicated programmer from figuring out the script. But that's the case everywhere.
I haven't decided what I'm going to do with images, but I'm leaning to just putting them in a custom file format. The game I'm writing right now will probably require this anyway, as it uses anime screenshots (which suggest jpeg compression) with added alpha information (which jpeg doesn't support).
Such a file format wouldn't be viewable in normal image viewer programs.
I think I originally underestimated how important game authors find this. Personally, I've never been a big fan of protecting people from themselves.
I think my current standard is that I want to stop a casual guy with standard tools from easily getting at the file. If a person is a programmer, all bets are off. I don't think that anything I can do, short of not releasing the game, will be enough to stop a determined attacker who's a skilled programmer.
-
- Regular
- Posts: 39
- Joined: Mon Feb 16, 2004 11:11 pm
- Contact:
I was talking on a more general basis (think c++) actually than Python since I don't know python (I was kinda assuming the other questions were dealing with encryption in general), but that process doesn't hide the pictures any does it? Or can you high level object the pictures too? It's too bad you can't have more control over files with python, but oh well.
Edit: Nevermind, I just read the thing about the custom format for file images. You'll need to include some kind of image conversion program I guess if you are going to have a custom format. I guess that could work:)
Edit: Nevermind, I just read the thing about the custom format for file images. You'll need to include some kind of image conversion program I guess if you are going to have a custom format. I guess that could work:)
Woot
- PyTom
- Ren'Py Creator
- Posts: 16096
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Well, Python actually has decent control over files. But at the same time, I don't really feel like writing two parsers as part of this project. I probably could include the images in the serialization, but that's not what it's intended for.Blackstream wrote:I was talking on a more general basis (think c++) actually than Python since I don't know python (I was kinda assuming the other questions were dealing with encryption in general), but that process doesn't hide the pictures any does it? Or can you high level object the pictures too? It's too bad you can't have more control over files with python, but oh well.
Since Ren'Py is an open source engine, anybody can take it and run with it. I hope that that'll be a good thing, encouraging people to make their own games, even if they aren't programmers.
At the same time, Ren'Py being open source means I can't keep any secrets from people who are really interested in finding them. I can obfuscate things, and I can use weird file formats. But at the end of the day, if someone skilled enough wants in, he'll get in.
Oh well, back to writing my game. 248 dialogue segments done so far, along with 17 or so menus. (Not everything is story-related.)
Who is online
Users browsing this forum: Amazon [Bot], Bing [Bot], Google [Bot]