Unity Ren'Py Unity or Ren'Py?

[timanuk]

Hi, i want to create a game (like Big Brother and Lust and Power) and i see two suitable engines – Unity and Ren'Py.

Which of them to choose?

Ren'Py for visual novels.
Unity for everything else.

 

[Cyan]

You can do with Ren'py absolutely everything you can do with Unity. And when I say "everything", it include real time 3D rendering, since

You must be registered to see the links

proved, with its small game engine, that Python is suitable for this usage. Obviously, Unity will always be faster and so Ren'py isn't the right choice for too complex real time 3D, but there's somewhere here a demo of a VR game using 3D real time rendering in Python, and it's really not bad for an indie project.

You seem to be saying, that because blender uses python, and ren'py uses python, they can do the same things and have the same uses as each other. That's a not really an accurate statement; Blender's API is in python, blender itself is not. Ren'py however, is made completely in python.

Even if they were made completely the same, it would only tell you what Ren'py is theoretically capable of creating, not what it's reasonably capable of creating at this moment. I have yet to see anyone create anything outside the bounds of a visual novel style game using ren'py. I would be extremely interested to look at that code if someone pulled it off.

 

[anne O'nymous]

That's a not really an accurate statement; Blender's API is in python, blender itself is not. Ren'py however, is made completely in python.

You seem to imply that Python is 100% Python, which is completely false. A lot of Python modules are just an API between Python and the related C library. PyGame, which is the core of Ren'py, is only partially in Python and Ren'py itself rely on (I'll assume C for most of them) libraries for a lot of things, like its OpenGL support by example.
Note that it's the exact same libraries than the ones used by Unity. Ren'py add a delay because of the API, but once the process is started, it will work as fast with Ren'py than with Unity. Like most of the time it's instantaneous, when not atomic, Ren'py will obviously be slower in the end. This because of the constant round trips between Ren'py <-> PyGame/Python <-> the library. But depending of what you do, most of the time with modern computers no one will perceive it.
Like I talk about this, the demo I forgot the name in my previous message :

You must be registered to see the links

I don't have the knowledge to do it, since I haven't touched a compiled language during the last 15 years and suck at practical 3D programming, but I know enough about Ren'py to assure you that it can be ported as an add-on to Ren'py. Which lead to the core of the problem :
The main difference, apart the interpreted Vs Compiled thing, between Ren'py and Unity is the number of guys behind the project. The author of Ren'py works alone, so the engine come with what he slowly add and what cross his mind.
Like for Unity, the sole limit of the game engine is the capabilities of the game creator.

I have yet to see anyone create anything outside the bounds of a visual novel style game using ren'py. I would be extremely interested to look at that code if someone pulled it off.

You must be registered to see the links

have an old school 3D part , honestly they can have made it better.

You must be registered to see the links

have a pong-like game, and like a lot of games in Ren'py a "Big Brother"-like interface.

You must be registered to see the links

have a (simple) combat system which works like the one used by RPGMaker and three differents kind of user interface.
All them do it natively, without the need to add an external library or a Python module. And you can also look at any games made directly with PyGame. Like I said, it's the core of Ren'py.

Once again, like I said, it's not because there isn't many people who use Ren'py otherwise than a Visual Novel engine, that there isn't a lot more that can be done without even the need to extend the actual capabilities.

 

[Rich]

For someone who is just beginning, I would recommend Ren'py because it takes care of a lot for you. Assuming that your game is at least something like a Visual Novel. That doesn't mean that you're stuck with only a visual novel approach - if you're willing to dig into the Python, you can do just about anything in Ren'py. But things that are at least vaguely similar to a VN are certainly its sweet spot.

Unity is intended to be much more general purpose. As a result, out of the box it comes with less "pre-done" for you. So there's more up-front work to set up your skeleton, etc. But you're also a little "closer to the processor," meaning that you have a bit more in the way of options if you're doing something performance-intensive or that's just "different." Not that you can't make well-performing games in Ren'py - far from it. And 2D games rarely tax performance too much.

From a pure programming point of view, there are some differences that are worth discussing.

First, because of the way that Ren'py uses Python, it means that pretty much everything is in the global namespace. This means that things like your labels and other names have to be unique across your whole game. That can be a challenge if your game gets large. A language like C# allows you to do a bit of structuring that's harder in the type of Python that Ren'py uses.

Now, for a lot of gamers, that's not going to make a huge difference, since the games don't tend to get huge enough (or the teams large enough) that it really can't be controlled. But you don't get the encapsulation that C# gives you. (Note that this isn't a criticism of Python - not at all. Python as a language has these same features. But when you're coding in Ren'py, you're not really coding in Python - at least not mostly - you're primarily coding in a pseudo-language implemented in Python, and it's that pseudo-language that introduces those limitations.)

MUCH more important, IMHO, is that Ren'py gives you the appearance of a procedural language. In other words when you have a character 'say' something in Ren'py, the game logic behaves is as if everything stops until the player acknowledges, then the next line after the "say" executes, etc. etc. (The actual "under the hood" is far more complex, but we won't get into that.)

Unity doesn't give you that at all - basically you have to understand event-driven programming, callbacks and a bunch of similar stuff that Ren'py pretty well hides from you, at least if you're going to code your game in C#. Thus, from a purely conceptual model, Ren'py is a LOT easier for someone who's comparatively new to programming to pick up.

Now, there are a variety of Unity plugins that can help get you around this and make it look far more Ren'py-like. There are VN plug-ins for Unity, but from what I've seen, they've kind of atrophied, probably because Ren'py is just more popular for VN's. There are things like Fungus that give you state machines and Lua inside Unity. Great if that's the way your mind works.

The bottom line is that here is no "one best solution." The important thing (again, IMHO) is to pick an engine that you're comfortable with, and then to spend the time learning how to get the most out of it. It would be a pretty rare 2D game that you could do in Unity and couldn't do in Ren'py. OK, maybe a platformer or something like that would be tough in Ren'py, anything that even vaguely resembles a VN (in which category I include Big Brother, Summertime Saga and a lot of other games floating around here) can.

Just my $0.02.

 

[Cyan]

You seem to imply that Python is 100% Python, which is completely false. A lot of Python modules are just an API between Python and the related C library. PyGame, which is the core of Ren'py, is only partially in Python and Ren'py itself rely on (I'll assume C for most of them) libraries for a lot of things, like its OpenGL support by example.

I apologize, I should have been more specific. I wasn't saying python didn't have the capabilities to be like blender/unity, I was saying ren'py didn't have the captabilities to be like blender/unity. If we have to create all the custom modules and framework to turn ren'py into something comparable to unity or blender, I'm not sure I could still call that game engine ren'py.

I suppose on some level if you want to say ren'py does have the capabilities because it too is created from PyGame, then I suppose you'd be technically correct; I just wouldn't like the comparison since that kind of functionality doesn't come native.

I don't have the knowledge to do it, since I haven't touched a compiled language during the last 15 years and suck at practical 3D programming, but I know enough about Ren'py to assure you that it can be ported as an add-on to Ren'py. Which lead to the core of the problem :
The main difference, apart the interpreted Vs Compiled thing, between Ren'py and Unity is the number of guys behind the project. The author of Ren'py works alone, so the engine come with what he slowly add and what cross his mind.
Like for Unity, the sole limit of the game engine is the capabilities of the game creator.

Now that's what I'm really interested in seeing. Again there was a failure of communication on my part, I should have mentioned 3D specifically in my last post. (Though it's still super interesting to see code in Ren'py for what could be an RPGM style-game).

As for the interpreted vs compiled thing, a number of years ago I was developing for Unreal Engine, and it used a interpreted scripting language of some form, similar to c++. (I couldn't tell you if they still use it or not, I haven't used Unreal Engine in quite a while) But as I recall there were a number of issues that we kept running into, especially on large-scale scenes and multi-player games. It makes me wonder if blender suffers from those same types of issues, since it relies heavily on python. (Of course that wouldn't really be a problem for a VN either way)

MUCH more important, IMHO, is that Ren'py gives you the appearance of a procedural language. In other words when you have a character 'say' something in Ren'py, the game logic behaves is as if everything stops until the player acknowledges, then the next line after the "say" executes, etc. etc. (The actual "under the hood" is far more complex, but we won't get into that.)

Unity doesn't give you that at all - basically you have to understand event-driven programming, callbacks and a bunch of similar stuff that Ren'py pretty well hides from you, at least if you're going to code your game in C#. Thus, from a purely conceptual model, Ren'py is a LOT easier for someone who's comparatively new to programming to pick up.

+1

For the game I developed in Unity, I tried as hard as I could to make the dialog/scene creation code-section resemble that of Ren'py, since it's so intuitive to use. Of course that begs the question "why not just use ren'py", but that's besides the point

 

[anne O'nymous]

Edit: Sorry, it's late here and my English skills are clearly already asleep

If we have to create all the custom modules and framework to turn ren'py into something comparable to unity or blender, I'm not sure I could still call that game engine ren'py.

I understand what you say, but look at it this way :
What make Unity what it is ? Its template for this, its add-on for that ? Is it more Unity because the template/add-on is made by Unity Technologies, or is a template/add-on made by a tiers still Unity ?
Natively, Ren'py is more limited than Unity, but in the same time, Ren'py have less hours of works behind it than the version 1 of Unity had. The first version of Ren'py came out 13 years ago. How many people have worked and for how long, to make the first version of Unity ? Probably more than 13 and for at least a year... So compared to a lot of other game engines, especially the more professional ones like Unity, ren'py is years behind them.

If the initial comment bother me, it's not especially because it show Ren'py under a wrong angle, but because it force Ren'py to stay at its initial "visual novel engine" state. As long as people will think that Ren'py can't do it, it will simply never do it.
This because it's an Open Source project, and also because it's an easy to understand game engine. It need our help both with tutorials and how-to, and with add-ons. But, why write a tutorial for this, or even directly an add-on, if "it's impossible, Ren'py is too limited" ? Still, it clearly seem that it's what the author expect from us, since Ren'py come with a full mechanism to extend its own language.
Imagine new statements like "defineCharacter", "defineAttackTable", "addToAttackTable", "addOpponent", "addToTeam", "startBattle" and the help of a "battleResult" variable. Suddenly more games with battles in them, because it become easy to do it. But no one, not even my, do it. What a shame...

[...] (Though it's still super interesting to see code in Ren'py for what could be an RPGM style-game).

The problem is that there's so many people saying that, "it can't be done in Ren'py", that nobody try. No one will come and say, alright, it can't be done, but I'll still pass two months thinking about how it can be done in Ren'py, then one month doing the sprites, and once again one month writing the code with the ren'py language, just to be sure that it can't be done...
Because of this, I can't show it to you. But I know (and not just thing) that it can be done. You can read arbitrary files, so a map file. You can place as many pictures on the screen that you want, and you can place them at the exact position you want. You can even use fully dynamics "name" for the pictures and you can display just a part of a picture. So, you can have maps based on tiles (like RPGMaker) or old school RPG maps ; a single picture way bigger than the screen, that you scroll according to the player moves. You can bind a function to any key you want and you can react to any click you want, knowing their position relatively to the map (so the tile the player clicked) or relatively to the screen (so the position on the picture). And finally you can place any picture you want on top of what's already seen.
All this natively, and like it's (almost) all you need...

Spoiler: Basically speaking it could be this

You don't have permission to view the spoiler content. Log in or register now.

As for the interpreted vs compiled thing, a number of years ago I was developing for Unreal Engine, and it used a interpreted scripting language of some form, similar to c++. (I couldn't tell you if they still use it or not, I haven't used Unreal Engine in quite a while) But as I recall there were a number of issues that we kept running into, especially on large-scale scenes and multi-player games. It makes me wonder if blender suffers from those same types of issues, since it relies heavily on python. (Of course that wouldn't really be a problem for a VN either way)

The problem is partly what I said before. Whatever if the libraries themselves give atomic result, you'll still have to do round trips between the interpreter, the API, then the function inside the library. It's not a problem if it add few nano seconds to the process... until the moment you find yourself with thousands of these round trips each second.
That's why I can't assure that what I said above about making a RPGMaker map system in Ren'py is really efficient or not. Ren'py do a lot of predictions, so I fear that it will try to predict too many possible maps and that it will slow it down. Same, if the tiles are too smalls, there will be a lot of round trips because each time ren'py will need to display so many little things.
But it's just a question of optimization. It would need some refactoring, some try and error for the better tile's size, but I'm really sure that it can be achieved.

For the game I developed in Unity, I tried as hard as I could to make the dialog/scene creation code-section resemble that of Ren'py, since it's so intuitive to use. Of course that begs the question "why not just use ren'py", but that's besides the point

Oh, I know the answer to this question: Because you're a coder
It's the problem with us, we are stubborn. Once we adopt something, it's hard to make us change. We prefer to adapt/extend what we love than using something which can do it, but that we love less. For you, it's making Unity works like Ren'py for the dialog, for me it's trying to motive people to make Ren'py as great as it should be, and trying to do it myself.

 

[Rich]

It's the problem with us, we are stubborn. Once we adopt something, it's hard to make us change. We prefer to adapt/extend what we love than using something which can do it, but that we love less. For you, it's making Unity works like Ren'py for the dialog, for me it's trying to motive people to make Ren'py as great as it should be, and trying to do it myself.

LOL. Old adage: "When you're holding a hammer, everything looks like a nail." Nothing conceptually wrong with trying to adapt the tool with which you're comfortable to the task at hand - it's human nature.

And commendable to attempt to improve something that's already good, or to take it in different directions. Applause.

 

[DSSAlex]

The idea of making a platformer in Ren'Py is off the hook and insane. Hell, a few weeks ago I was speculating about how to make a Wolf3D clone in Ren'Py. I can kinda see the big sweeps of how to do it. Unfortunately there's no way I'd be able to monetize such a thing and my time is stretched thin as a motherfucker.

 

[anne O'nymous]

Hell, a few weeks ago I was speculating about how to make a Wolf3D clone in Ren'Py. I can kinda see the big sweeps of how to do it.

Why speculating on what already exist ? Winged cloud did such a thing, and it was their better game :

You must be registered to see the links

 

[Hentami]

RenPy all feels the same 'mechanics' wise to me. Only different levels of artwork and story. Winged Cloud.. makes over 25,000 a month. so not a fair comparison.

RenPy is great for making a VN. Unity is great, for adding more then that. Creating your own engine allows you to do - anything. Coding your own engine is the most powerful thing you could complete - but also insanely time consuming. I find myself spending more time on coding as I keep thinking of new mechanics.

Best wishes and you can always do both! Work on your custom engine and use renpy to flesh out the story!

 

[polywog]

You must be registered to see the links