Extracting Ren'Pys scripting language

[_rhetorik_]

As far as I can tell, the only argument you brought to support that is that more people are familiar with HTML + JS. I give you that, it is true. IMHO, that does not outweigh the advantages of Qt. You first need to create something that can attract a community before modder preferences become significant for your project

You don't need to get rid of Qt. In fact you would still need a background gui toolkit (Qt,Wx, Gtk, ...) to make the window and the browser ui to it. The HTML would be just the game ui. In C++ you can do what i am suggesting in Qt using QtWebView probably the same using python. The replacing i mentioned was just for modding and the "in-game" ui.


I undertand very little about Dojo, but it is a web thing isnt it? There is nothing about client/server in this architecture. If you really want to see some client/server in it you can think of JS scripting as a client and python application that embeds the browser as a server ... But i think that is a little way off.

Is the advantage you see that HTML + JS is usually distributed as source, while other languages are usually distributed in compiled form? If so: the same is possible with Python. I already do that for event scripts and I will probably do it for the whole application once I have fixed some errors I made during early development.

Yes, that is good. But if i give you a text in aramaic it won't be that helpful, right? (Assuming that you doesn't know how to read aramaic...). There is a difference between changing the game code and changing the game resources.


You say that changing the game is easy because it is python and i am saying that changing the game resources is more friendly. This way the ui can be made a resource and  the game code can be kept as a single version.


But anyway, i ve seen the game progress and it is looking really nice


Hoping to play it soon .... Whatever way you use to make it !!

[DocClox]

Thanks! Although I should probably point out that there are two developers for two different games here.  I'm making wmac and rudi's project is Pytherworld.

I can't see me changing the Dev platform now. I did consider qwebview and is - for Perth much the reasons you outline. it's a bit late to be changing things at that level though. which isn't to day I won't include some sort of modder friendly scripting. I'm still pondering on the pros and cons of that one. (sending this from my phone BTW so please excuse any weirdness from the auto complete

@rudi: regarding security, use case I have in mind is scripting girl encounters as in vanilla wm. the potential attack vector is if some unscrupulous individual posts a girl pack and scripts it with a malware downloader or spam relay or some such.

obviously I'll check anything I distribute, but I can't check everything. so I'd sooner not make it easy for the had guys to subvert my game.

so yeah, sandboxing is a consideration.

which I'd about the only advantage of JavaScript over Python or rps. but I think it is an important one.

[rudistoned]

But if i give you a text in aramaic it won't be that helpful, right? [...] There is a difference between changing the game code and changing the game resources.

Declaring files containing code as "game ressources" instead of "game code" does not make it easier to modify them at all In both cases you need to be able to understand the code.

Any javascript coder should be able to understand the following example code from wikipedia:

Code: [Select]

function LCMCalculator(x, y) {
    var checkInt = function (x) {
        if (x % 1 !== 0) {
            throw new TypeError(x + " is not an integer");
        }
        return x;
    };
    this.a = checkInt(x)
    this.b = checkInt(y);
}
You are telling me the following Python code would look like aramaic to him? Really? I'm not buying it.

Code: [Select]

class LCMCalculator(object):
    def __init__(self, x, y):
        def check_int(x):
            if x % 1 != 0:
                raise TypeError(str(x) + " is not an integer")
            return x
        self.a = check_int(x)
        self.b = check_int(y)
That code even uses language features I've never needed nor used in my projects (nested functions)! A lot of code will be simpler to understand than that.

This way the ui can be made a resource and  the game code can be kept as a single version.

That has more to do with separating the game logic from the UI code than it has to do with the language the code is written in, don't you think?



@DocClox
Okay, but do you really think plugging one hole will stop a criminal individual? I don't know all that much about IT security, but usually there are a lot of different ways you can attack any software. What if the malicious code is not in the code part of the girlpack, but embedded within one of the images? What if the criminal just provides a mod that changes the Python part of the application? What if the attack is not delivered via a mod but via some sort of utility, like a girl pack builder/viewer? Or a launcher that customizes parts of the game people want do mod but you chose to keep away from them? I honestly don't think you can get a hobbyist game into a secure state.

[DocClox]

Rudi, I can't even secure my house!

There are people who could pick the lock on my front door, there are pick guns and diamond drills... if the bad guys want in, they'll get in.

Nevertheless, I still lock my door at night.

I can't make the game bullet proof, but I still feel I have a duty to take reasonable precautions.

[edit]

Corrected some of the atrocities committed by my phone's predictive text function...

[_rhetorik_]

Declaring files containing code as "game ressources" instead of "game code" does not make it easier to modify them at all In both cases you need to be able to understand the code.

That has more to do with separating the game logic from the UI code than it has to do with the language the code is written in, don't you think?

From the Dev perspective i slightly disagree. You can separate logic and ui in your code. If you consider your UI as a resource, you dont need to "recompile" if you are working on a compiled "environment". On a script, the difference still holds although more subtle.


From a user perspective the diference is big. Your user don't need to sniff through your code to find the UI and make changes. It can just edit an extern file. Btw, Whoremaster does it with XML files and had to implement its own "browser" using SDL.

[DocClox]

Btw, Whoremaster does it with XML files and had to implement its own "browser" using SDL.

I should probably declare an interest at this juncture and point out that I wrote the XML processing code for WM, including the XML screen layout code.

Oddly enough, I can remember thinking at the time that it would all be easier with a proper HTML parser and javascript integration. Which is probably what got me thinking about Lua scripting. The problem with Lua and Wm wasn't so much a lack of HTML  for layouts as it was the work entailed in exposing the underlying game. That (among other things) started me thinking about  Clonemaster which would have coded primarily in Lua using the bones of necno's SDL as game the engine. And from there, via Daisy's Otherworld and an extended flirtation with Skyrim, it let me back here to Python and WMAC.

Odd how theses things progress, sometimes

[rudistoned]

I fully agree that having a GUI that is defined in ressource files (like XML) and dynamically loaded at runtime is great. I did that back when I was using GTK and it worked great. Qt can load its GUI from XML too, but I ran into some problems when I tried it, switched to the precompiled variant and never looked back. I might try it again when I seriously start working on Pytherworlds GUI.

I still don't get why reading code in HTML files is less "sniffing through code" than reading code in the ui packages of my application. In both cases the GUI code is located in several files within several directories.


@DocClox
That's exactly my point . You can't make it bulletproof anyway, so trying to make it somewhat secure can happen when the game is more or less done.
To be honest, I lock my door at night because it makes me feel better, not because I think it makes a difference. Anyone who wants to break in won't be deterred by a locked door. People who do not want to break in don't need a locked door to stay out.

[DocClox]

To be honest, I lock my door at night because it makes me feel better, not because I think it makes a difference. Anyone who wants to break in won't be deterred by a locked door. People who do not want to break in don't need a locked door to stay out.

The point is that if you make it a little bit difficult, 99% of would be intruders will go and look for easier pickings. Conversely, if you leave it wide open, people may wander in who wouldn't normally consider doing so. There's a world of difference between "wide open" and "reasonably secure". I'd like to avoid "wide open", personally.

I don't think there are any hard and fast rules here. I'm not saying everyone should worry about sandboxing user mods. But I'm going to keep it as a consideration, for the reasons I've outlined.

[rudistoned]

I see the difference between "wide open" and "reasonably secure".  I just think slowing down development for a gain in security is bad for the project, at least until there is a nice, playable beta. All hobbyist projects run the risk of never getting to a stable, post-beta state, so development speed is IMHO paramount.


Update:
Btw, _rhetorik_, are you aware of Brothelsim? I think that game uses non-Flash web technology.

[DocClox]

I see the difference between "wide open" and "reasonably secure".  I just think slowing down development for a gain in security is bad for the project, at least until there is a nice, playable beta. All hobbyist projects run the risk of never getting to a stable, post-beta state, so development speed is IMHO paramount.

Oh hell yes. I'm not even going to write any test code until I have the game playable. Third party scripts for individual girls is one of the last things I'll look at. I only mentioned it because it is one area (possibly the only area) where I can see a benefit from embedding Javascript in PyQt. First things first

[_rhetorik_]

I fully agree that having a GUI that is defined in ressource files (like XML) and dynamically loaded at runtime is great. I did that back when I was using GTK and it worked great. Qt can load its GUI from XML too, but I ran into some problems when I tried it, switched to the precompiled variant and never looked back. I might try it again when I seriously start working on Pytherworlds GUI.

What is the differece of a XML gui and an HTML gui? The HTML gui is "free"(as in little developer time) the browser already works and it already comes with an scripting language (which is lacking in XML unless you code it yourself afaik). Not sure why you like the XML gui as a resource but you don't like the HTML gui as a resource...

I still don't get why reading code in HTML files is less "sniffing through code" than reading code in the ui packages of my application. In both cases the GUI code is located in several files within several directories.

You just need 1 folder with 10~20 html files. Perhaps another set of .js and a .css file. No inheritance, no need to search through hierarquies where that thing was defined ... nothing too hard for non-developers. Nowadays people make some increadibly powerful gui using HTML5 and libraries like YUI and jQuery and all that is available for "free" (again as in little developer time).

[rudistoned]

What is the differece of a XML gui and an HTML gui?

The widgets described in the XML are the difference
I like the possibilities Qt gives me: Powerful widgets, GUI design with a polished graphical tool,  internationalization support and many other features I have not used so far, but which are there should my requirements grow.
I just do not believe that web tools have caught up so much that they can play in the same league as desktop tools as far as desktop development is concerned.

The HTML gui is "free"(as in little developer time) the browser already works and it already comes with an scripting language (which is lacking in XML unless you code it yourself afaik).

I highly doubt that the GUI of a desktop application can be written faster in HTML than in Qt, so Qt GUIs are at least as "free" as HTML GUIs. Qt works too, just as the browser, so why mention it? Python is also a scripting language, just as JavaScript, so why mention it?
The scripting language this thread is about has very little to do with coding GUI logic. The Ren'Py scripting language is not equivalent to JavaScript, not by a long shot. It is useful to script dialog-heavy ingame events and was originally developed for visual novels. It is not a full-fledged programming language.

Not sure why you like the XML gui as a resource but you don't like the HTML gui as a resource...

I like both for the fact that you can alter the GUI without altering the code of the application. What I dislike about HTML is that I strongly suspect that its usefulness for desktop GUIs is not up to par with Qt.

You just need 1 folder with 10~20 html files. Perhaps another set of .js and a .css file. No inheritance, no need to search through hierarquies where that thing was defined ... nothing too hard for non-developers.

Technically, I could develop my whole application in a single source file, using only functional programming and builtin classes. No custom classes, no inheritance, only the global namespace and and the local namespaces of the functions. According to your argument that should be really easy to understand, right? Well, it's not. It's easier to see were every variable is defined, sure, but what are they for? Organizing your code in class hierarchies is useful for a lot of reasons and is such a widespread practice that I don't feel I have to explain it.
Placing all source files into the same folder does not make it easier to understand what they do. Again, structure helps to convey meaning.


What kind of GUI modifications are you talking about that you think a non-developer could do with HTML?

Nowadays people make some increadibly powerful gui using HTML5 and libraries like YUI and jQuery and all that is available for "free" (again as in little developer time).

Could you point to some good examples of such GUIs, so I can look at them myself?

Oh hell yes. I'm not even going to write any test code until I have the game playable. Third party scripts for individual girls is one of the last things I'll look at. I only mentioned it because it is one area (possibly the only area) where I can see a benefit from embedding Javascript in PyQt. First things first

I agree with that completely

[_rhetorik_]

The widgets described in the XML are the difference
I like the possibilities Qt gives me: Powerful widgets, GUI design with a polished graphical tool,  internationalization support and many other features I have not used so far, but which are there should my requirements grow.
I just do not believe that web tools have caught up so much that they can play in the same league as desktop tools as far as desktop development is concerned.

This site is a google project to explore HTML5. This a tutorial about defining custom tags in HTML.


http://www.html5rocks.com/en/tutorials/webcomponents/customelements/


Using QtWebView you could add QtWidgets to the web page. They might still support it.

I highly doubt that the GUI of a desktop application can be written faster in HTML than in Qt, so Qt GUIs are at least as "free" as HTML GUIs. Qt works too, just as the browser, so why mention it? Python is also a scripting language, just as JavaScript, so why mention it?
The scripting language this thread is about has very little to do with coding GUI logic. The Ren'Py scripting language is not equivalent to JavaScript, not by a long shot. It is useful to script dialog-heavy ingame events and was originally developed for visual novels. It is not a full-fledged programming language.

I like both for the fact that you can alter the GUI without altering the code of the application. What I dislike about HTML is that I strongly suspect that its usefulness for desktop GUIs is not up to par with Qt.

Python doesn't run from an HTML file. If you can change the logic in the GUI lvl than you can change the entire logic of the app.


There are many companies/applications migrating from traditional ui to this model. Steam and Mozilla Songbird are just a browser with HTML and App Logic as a resource. In fact i guess all the mozilla stuff runs inside a Firefox box (not sure though).


http://html5-demos.appspot.com/static/gdd11-modern-web-apps/index.html#1


http://www.html5rocks.com/en/business/

What kind of GUI modifications are you talking about that you think a non-developer could do with HTML?

Could you point to some good examples of such GUIs, so I can look at them myself?

I expect i non-devs can try their hand on HTML, perhaps even on some basic JS. But i don't expect them to try their hand on python even though it shares some similarities with JS.

http://www.hongkiat.com/blog/html5-web-applications/

[rudistoned]

I expect i non-devs can try their hand on HTML, perhaps even on some basic JS. But i don't expect them to try their hand on python even though it shares some similarities with JS.

Well, that's one point on which we disagree. To be perfectly honest, this is the last time I am willing to explain the obvious.
I don't see how basic Python differs from basic JavaScript in difficulty. If anything, Python is easier because it needs less syntactic clutter. Just look at the simple examples from wikipedia:
 

Code: [Select]

# JS
var y = 2;

# Python
y = 2


Code: [Select]

# JS
console.log("Hello world!");

# Python
print "Hello world!"


Code: [Select]

# JS
function factorial(n) {
    if (n === 0) {
        return 1;
    }
    return n * factorial(n - 1);
}

# Python
def factorial(n):
    if n == 0:
        return 1
    return n * factorial(n - 1)


Thank you for the example applications though
I will have a look at them later.


Btw, Steam: Whoa, that thing annoyed the crap out of me because it just would not work and I needed it for a game I wanted to play. I spent hours fiddling around with it, just so it would run on a regular 64bit Windows 7 machine. Then it ran once and the next day it was broken again. That's what you get for paying for your games 
It got better last year though, installing and updating Steam works for my computers now.

[DocClox]

Lurching back on topic for a moment I've posted a demo of my story widget on the WMAC thread.

It uses a list driven approach like the one I posted earlier rather than RPS. That doesn't rule out RPS in the future, since all I need is a way to deliver events in sequence, and frankly, what I have at the moment is ugly-ugly-ugly!

The source is in the archive, an exe also.