Engine Advice

[Kristovpher]

I'm looking to one day make a game along the lines of Degrees of Lewdity and am looking at which game engine to learn to make it. I've started looking at Twine and Sugarcube, because I believe that's what was used to make Degrees, but I have also seen some impressive stuff done with Ren'py.
So I was wondering which would be better suited and easier to learn as I have never programmed before.

Thanks in advance for any advice.

 

[Saki_Sliz]

To make a game like Degrees of Lewdity, its all about learning 'state management' and every engine and language is a little bit different. Mainly its about organizing your game and code, and what organizational tricks you can use depends on the engine.

I too want to make a degrees of lewdity like game, but I'm getting tired of 'planning' and want to move on to 'making.' I've wanted to use Twine with sugarcube as because as you mentioned, seems to be how DoL was made, and it has the advantage of being HTML thus universal to play everywhere without even needing to download the game, however as far as I've been able to tell, twine is good for story telling, but its a bit cumbersome to get to the programming part and actually make the game.

I too recently looked into renpy and am now feeling the need to develope a game using ren'py instead. As someone with a main focus in C# programming, I am more used to creating code that performs 'state management' and then making my main game making code clean and slick. However that takes time to build a framework. looking into renpy, the way I would describe it is how most programmers would describe python, it 'feels' dirty, but its super quick, its still very powerful, and you can focus on 'making' rather than 'designing'.

As I mentioned, I'm getting tired of 'designing' and just want to 'make' so I'm giving renpy a try, as well as changing how I approach game making, being story and art focused first and worry about gameplay later. I tend to have all these cool demo, but never wanting to make assets for the game because its simply to big and complex and feels like a job rather than a hobby.

Note: the reason renpy feels dirty
it sounds like you may not be a programmer (yet), but basically, you are doing coding right inside of the actual story writing. Thats nothing different or new, its like formating 'strings.' where it gets dangerous though is that you can call any variable, manipulate any variable, and you have to manually instruct the code when and where to go, with the hope that you understand what the coding will behave and return as expected. All programming is like this, but with more OOP languages you can make the flow rather modular and due to OOP paradigm, you can't do bad programming because it limits what you can do (ie, can't manipulate character data in code that isn't for the character), so when coding with other languages you are often making code that makes it so you can code safely, and making ways to be 'official' about how to manipulate state data. but with renpy, everything is technically in the 'global' space meaning you can do anything. you are free and unrestricted, which means you can possibly make bad and hard to debug code (to many scripts changing the same variable causing conflicts, like maxing out a characaters stat or something), which programmers have been 'programmed' to be scared of, but if you ignore the fear it does allow for a little bit of coding to be just as powerful as deveolping dedicated systems.

 

[MidnightArrow]

I too recently looked into renpy and am now feeling the need to develope a game using ren'py instead. As someone with a main focus in C# programming, I am more used to creating code that performs 'state management' and then making my main game making code clean and slick. However that takes time to build a framework. looking into renpy, the way I would describe it is how most programmers would describe python, it 'feels' dirty, but its super quick, its still very powerful, and you can focus on 'making' rather than 'designing'.

I have similar experience to you (more Java than C# though) and my experience with Ren'py has been slightly above waterboarding on the fun meter.

In Ren'py, everything is compartmentalized into different areas that all have their own domain-specific languages that barely work together. You try and implement something as a CDD only to find out there's no way to run ATL code to use the "choice" statement, so you need to delete it and start over as ATL. But then you find ATL can't run conditionals like CDDs, so then you need to pour over the manual and find DynamicDisplayable, which requires you to define a Python function to check the game state. So now you have some CDDs, some ATL, some Python functions, and of course you need screens to hold them, alongside the main Ren'py code. That's five "sections" of code with four different domain-specific languages (Python, Ren'py, screen language, and ATL) and a shitload of poorly-explained API functions tying them together. Beyond that, the documentation sucks since it doesn't list the superclasses, the subclasses, or the data types for any of the function calls, so you need to hunt around looking for the part where PyTom vaguely explains if image is a subclass of displayable or vice versa. And then you get to the part where the engine's basic inner workings (like what an "interaction" is) only get explained in blog posts that don't come up in the search results even though they're on the fucking Ren'py website.

In Java or C#, it's so easy to create interfaces to make a single class pull double-duty as both a screen and an image, encapsulate helper functions inside it, use the built-in observer class to communicate between objects, etc. Ren'py just cuts the functionality into pieces and smears them all over the global namespace.

All in all, I'd only recommend Ren'py if you stick to basic, top-level Ren'py visual novel language. Anything more complicated and you're really better off creating your own framework in C# or a dedicated game engine, since Ren'py's architecture isn't capable of anything except visual novels.

 

[Saki_Sliz]

That's five "sections" of code with four different domain-specific languages (Python, Ren'py, screen language, and ATL) and a shitload of poorly-explained functions tying them together.

Good to know.

from what I've scene, while it is possible to make complex games with renpy, but that kind of development is more about forcing renpy to work the way you want it to, something you can only do through experimentation and a good amout of prior renpy experience, not something you can start worknig on right away.

I guess a better way to describe my interest, something for the OP to consider, is I'm looking to ren'py because I want to use it as a prototyping tool just to encourage me to focus or story driven development, rather than mechanic driven development, just to give me different experiences and see if I like the process or not. So I'll be focusing on renpy's core functionality and features, not doing something as detailed as DoL which is all about state data, tracking character clothes and stats.

 

[MidnightArrow]

from what I've scene, while it is possible to make complex games with renpy, but that kind of development is more about forcing renpy to work the way you want it to, something you can only do through experimentation and a good amout of prior renpy experience, not something you can start worknig on right away.

That is absolutely 100% correct, although I would change the last part to "not something you should start working on ever."

Maybe if it got a proper IDE with a WYSIWYG editor to handle the hundreds of transforms and styles and ATL statements you'll need for a complex game, maybe. But until PyTom adds one of those, just use a better program.

Technically you can access SDL through Ren'py, so you can do anything you could do with SDL, but why bother? I'd rather just code the whole thing in C if I wanted to use SDL. At least C has static typing.

I guess a better way to describe my interest, something for the OP to consider, is I'm looking to ren'py because I want to use it as a prototyping tool just to encourage me to focus or story driven development, rather than mechanic driven development, just to give me different experiences and see if I like the process or not. So I'll be focusing on renpy's core functionality and features, not doing something as detailed as DoL which is all about state data, tracking character clothes and stats.

Ren'py would be a good fit for your use case.

It's also the approach I'd recommend for the OP, since they have no programming experience. If you've never programmed before, you don't have the skills to do a stat-driven game. Simple as that. Focus on a basic game using Ren'py (or Twine or Sugarcube) at their most basic, simplistic level until you've gained the experience to learn the math required to do more. (Preferably using a better engine than Ren'py.)

 

[anne O'nymous]

I too recently looked into renpy and am now feeling the need to develope a game using ren'py instead. As someone with a main focus in C# programming, I am more used to creating code that performs 'state management' and then making my main game making code clean and slick.

If this is really the reason why you started your own engine, hmm... Have you looked enough into Ren'Py ?

The

You must be registered to see the links

are really life changing and can turn Ren'Py in something totally different. Want your dialogs to be AI based, well why not a ai dialog SAYER "keywords for the sentence" statement to replace the usual SAYER "dialog line" ? Or why not some variety in the dialogs with:

init python:
   [define the "random dialog" statement]

# Of course it's just for the example, in real use it would need a database of something like this.
define randDials = { "dialog id": [ "sentence 1", "sentence 2", "sentence 3" ], [...] }

label whatever:
    random dialog SAYER "id of the dialog"

And hop, now Ren'Py while randomly pick the dialog lines, and you'll not have more efforts to do to effectively write the game. At least once you've defined the statement and filed the database, but this is works that you also would have to do with another game engine.

Couple this with a

You must be registered to see the links

, that you would have as constant overlay by example, and you can even turn it into a purely event based engine.
Talking about the creator-defined displayable, you can have a pong-like game really easily:
[Really raw code, it's a pure example and wouldn't works as it]

init python:
    class Pong(renpy.Displayable):

        def event( self, ev, x, y, st ):
            if mouse moved:
              self.paddleX = mouse X
              self.paddleY = mouse Y

            if self.ballX == self.paddleX and self.ballY == self.paddleY:
              rebound the ball
            elif self.ballY == upper border:
              rebound the ball
            elif self.ballY == lower border:
              rebound the ball
            elif self.ballX == self.opponentX and self.ballY == self.opponentY:
              rebound the ball
            else:
              ball continue to advance

            update opponent paddle position.

            renpy.restart_interaction()
            renpy.redraw( self, 0.01 )
            renpy.timeout( 0.01 )

        def render( self, width, height, st, at):
            surface = define a width x height blank surface

            surface.blit( ball, self.ballX, self.ballY )
            surface.blit( paddle, self.paddleX, self.paddleY )
            surface.blit( paddle, self.opponentX, self.opponentY )

            return surface

define pong = Pong()

screen pong():
    add pong

It's basic enough to be totally smooth. Just too fast as it because it would update the ball every 0.01 second, but you can perfectly have a counter to only update the ball position every 10 call of "event" by example.

[...] and you can focus on 'making' rather than 'designing'.

As you can see above, it's an error to think this way about Ren'Py. Of course, it's designed to be used like this, but it can also be designed first, and suddenly this change everything.

and you have to manually instruct the code when and where to go,

Are you really sure that it's always "manually" ?

label whatever:
    menu:
        "enter mother's room":
            jump room_hub( "mother" )
        "enter sister's room":
            jump room_hub( "sister" )
        "enter aunt's room":
            jump room_hub( "aunt" )


label room_Hub( girl ):
    # Show the right door as background.
    scene expression girl + "door"

    # Check what scene should be presented.
    call room_checkEvent

    # Branch to the right scene for the right girl.
    jump expression girl + _return


label room_checkEvent:
   if corruption < 5 and time == "morning":
      return "Dressing"
   elif corruption > 5 and time == "morning":
      return "Masturbating"


label motherDressing:
    pass
label motherMasturbating:
    pass
label sisterDressing:
    pass
label sisterMasturbating:
    pass
label auntDressing:
    pass
label auntMasturbating:
    pass

It's a ridiculous example, but it serve the demonstration: You don't necessarily need to manually build anything.


Of course, Ren'Py will never give you the power of modern compiled OOP languages. But it's would be wrong to believe that it's a static BASIC-like.

 

[Saki_Sliz]

Thanks anne O'nymous

trying to reply, I went off topic like 3 times getting into the nuances of project design, advantages and laminations of different paradigms, and trynig to explain how DoL's code works.

I'll have to look into user defined statements some time in the future. I knew renpy can run some python, but I didn't know to what extent. if I continue to use renpy, If I really want to run complex things I was planning to just have it open a port and connect to my C# AI engine, using that to do the complex stuff while renpy is more like the UI engine. I would do something similar with twine if I could, but looking into it I can't, hence why I started looking into renpy more.

Also, really cool to see that sort of modular code format is possible with renpy, very useful information!

 

[Kristovpher]

Whew, I understood maybe 5% of all that, lol. I guess I'll continue learning Sugarcube, it sounds like it might be slightly better. Thanks for all your replies.

 

[Cruxiz]

If this is really the reason why you started your own engine, hmm... Have you looked enough into Ren'Py ?

The

You must be registered to see the links

are really life changing and can turn Ren'Py in something totally different.

[...]

Of course, Ren'Py will never give you the power of modern compiled OOP languages. But it's would be wrong to believe that it's a static BASIC-like.

Very insightful. I too have been thinking of creating a game and been looking at Unity, RPG Maker, RenPy and Twine. Since I lack the artistic skills to draw and animate, my main focus would be story and game mechanics. I didn't want to start a separate thread inquiring some suggestions for this but I might.

The game I'm thinking of creating has you set a multitude of parameters upfront and then generates a story based on it. Think along the lines of characters x and y have properties 1 and 2 and based on those some other flags are generated and a story unfolds. I've kinda tossed out RenPy due to its static flow but I might reconsider it now with this info.