[Food for thought] (ISAWHIM)

[ISAWHIM]

WARNING: The following contains MY OPINIONS and observations. I am not interested in rubbing egos or impressing anyone. Nor is it my intention to upset anyone. The intention is to open discussion for something that I believe is worth discussing.

ALSO: TLDR

Yes, I said "RenPy X", because the up-coming Version 7 is essentially going to be this version with a major hammered-out bugs-fix. There is really no new features that can be implemented, with any importance, without complicating this build even further. {We can argue that point all day, but it is irrelevant to the topic.}

The reason for saying "RenPy X", as stated above, is not something that is a "set in stone" suggestion. The "X" being symbolic of using standard "objects" that can be "anything", along with the adoption of "Python 3" code-base/functions. This may be more apparent in the following considerations and observations. This would NOT be compatible in any way, with any prior releases. If you wanted classic functions, you would play with the outdated, but still supported, older version. It does what it does and it does it all differently. It is bound to Python 2.x and the old help-files, which is adding to the confusion too.

Why Python 3?
- Python 2.x is essentially expired. "The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release." Source: Python https://wiki.python.org/moin/Python2orPython3
- Python 3.x is the "face forward", simplified younger sister. It has been cleaned-up, standardized, put into a new dress and pushed into the streets... And it is making money, instead of consuming it. Almost everything is a "function", or an "object", which makes it more manageable and requires less effort to figure things out.

Why "X"? {This is not a version. This is a core-design, redesign.}
- Because "X" = (a crossing) = (a variable x, as anything, as everything) = "OS X" = "Windows 10{x}" = linu[X] = (a multiple 2x8=16, "x" = "*") = (four-way, inward or outward) = (Four corners... of the earth)

Observations:
1: There is little "up to date" documentation that is understandable to a non-programmer, and almost every aspect of RenPy demands programming knowledge. (Specific to, respectfully, the confusing but powerful Python-2 language.)

- NOTE: I realize this is due to the MANY large changes and expansions, with the creators limited time-frame, ability and/or desire to cater to those with lesser knowledge of programming. However, the forums help to alleviate many of those shortcomings, to a point.

2: There are many inconsistencies and confusing cross-information areas that stall development and make it seem as if "things are not working correctly", when they are, but there is nothing to identify, clearly, why some things work and others do not. (I could do a whole post with the many things like this, but some are variations of the following.)

3: There are many duplications of functions, both in RenPy and Python, which only adds to the confusion. Some are for cross-compatibility, reverse-compatibility or just specific-variations without a need or explanation of the specifics use. (Like the use of the word "hide", in "hide ______" and "______ hide", doing two specific and indifferent, but similar things. Again with the use of terms that can not be inferred and are not intuitive, like "menu" and "renpy.display_menu" as equivalents, as opposed to "renpy.menu", as many other things are equated.)

4: There are way too many specific "objects", with conflicting names that defy function and/or interfere with other functions, and/or aid to the confusion with specific named objects, internals, or other pre-fab names of RenPy and Python content. (Like the use of the term "window" and "screen". Compared with the standard use of "full screen" and "windowed" and a programs "window" or "display", or the screen's "display", and "displayable".)

5: Variables, for some reason, are scoped (isolated), between the RenPy and Python layers, when they do not have to be. (Perhaps that was once an issue, but that honestly should never have been one.) This requires a complex and lengthy set of redefining and rescoping, unwanted duplication and extra things to remember and manipulate, just to get things to function between RenPy and Python "clips" of script. Both at the block-level and inline-level. (I know that Python-3 addresses many of its own shortcomings there, where Python-2 was the "reason" for that being an issue.)

---------------------------------------------------

With just those few things listed, I will continue with my intended purpose for the post. The above things are not a topic for discussion. They have been discussed in thousands of posts in the forums already, without resolution, often being told to "deal with it", as a solution to the issues.

Before going into the detailed overview of what, I believe, could help make "RenPy X", supercharged into simplicity... I want to mention a few of the considerations which I have thought about.

1: There are only five actual "object" types, that need to be specified.
- Image: Any raw image file, or a "blank" image container. (JPG, PNG) are the only two formats "needed", for various reasons.
- Video: Any raw animated image-container, which may also include sound. Not going into the formats. I am sure that will change.
- Sound: (AKA: Music, Audio, Voice) Any raw audio stream container, devoid of video/images. (OGG) is the only format anyone needs.
- Text: (AKA: Vector format) Specific to "fonts", which currently makes provisions for image-fonts too. (TTF) is the only format needed.
- Container: (AKA: Screen, Window, Vbox, Hbox, Image, Video, Displayable... etc...) Simply a specific "containment area", for a specified "object" to be "displayed and/or manipulated". However, this honestly includes non-displayable objects, which are intended to "capture input" or also "isolate groups", such as layers. It is, in essence, an object of an object, without any specification, or adopting specification from the contents within the object. Thus, a "container". (If the sole contents were an image, it would be an image object. However, it would also still be a container which could hold more images or a video or become a layer. As opposed to an image-object, which is just an image-object, which is a sole item within a "container".)

NOTE: You could create real specific "other objects", but the point is simplicity, not confusing diversion, for the sake of "because I can do it, lets do it!" It doesn't need to be done, so don't do it. (EG, Button, Image button, Text button... How about just a "Button", a "container"... Where is the "Video Button" and the "Sound Button" and the "CheckBox Button", and the "Slider Button"... More "functions" which all need more documentation written, and surely won't have standard values between them.)

2: There is an annoying use of mathematical (X and Y, and Z), which there is no actual standard for, but a wide-use, which RenPy does not use. Instead, it actually uses, LEFT, BOTTOM, and Z-Order... With the addition of LAYERS, which is just a group of Z-Ordered, Z-Ordered items. (Depth) Make a standard, without conflict, which reflects the specific uses of the user.
- Use these standards, {Bottom-Left}, {Top-Left}, {Bottom-Right}, {Top-Right}, {Top-Center}, {Center-Center AKA:Middle}... Selectable by the user, as a setting. This being the "default", (0,0) for our alignment of everything.
- Use alias names, within code, to allow us to write the way WE THINK, in stead of damning us to the way some programmer at Python thinks we should think, because he/she thinks that way better.
- These specific "types", being universal to every item/container/object/value. Such as "anchor", and "show", and "scale"... etc...

3: Universal/Global variables, assumed "local", only when needed. Which can be accessed from both RenPy and Python script, as needed.
- Novel concept, the old "basic" variable was $MyVar. That is still easy to identify, should not conflict with anything, and is still a functional standard in almost every language, except Python.
- $MyVar will never be mistaken for a function, or a name, or an object... (Though it is honestly just a pointer, and can be a function, or an object, etc... But WE know that WE OWN that word, that "variable", and it can be accessed by any code, at any time, as it is written.)

4: The use of "label", for a function/subroutine/gosub is wonky, unpredictable, and breaks the whole system when you have to remove, add and edit them. Not to mention the word "label", makes no sense in the use as a "goto". Sure, we have created a label for the "goto" to locate, but that is redundant and the word "label", usually refers to something "displayable", which identifies something that should be seen by the user of the program, not the programmer.
- MyWord: is all that is needed. What is it? Obviously, it is a location to jump to... How do you know? Well, it is a single word followed by a block-entrance ":". This should be a one-way entrance. A "goto", without a return. Might as-well follow standards and say "goto MyWord", since we are not jumping in virtual-space, which is a human action we do in the real world. Something that requires "legs", and something to land on... Which requires "land". But RenPy doesn't use "jump to MyWord", and "land on MyWord". I have never jumped at a label in my life. I thumbed through a few labels on things. I peeled labels off cans. I labeled my shelves... But I never jumped to/at a label. (Non-intuitive, demands explanation and senseless wasted memorization, and prone to oversight.)
- MyWord(): is obviously either a function or a subroutine. Having a "Return" within is not needed. What is the difference? A function returns a value, a subroutine does not. So, have it return "Empty", or "Null", or "Nothing", or "", unless they set "MyWord() = $MyVal". No need to be specific and isolate a function and a subroutine, then have to explain why to use one and not the other, when there is no need to have anything more than a standard function for both.
- When RenPy sees this, it should be compiling a standard "Python Function", which is obviously addressed by the $MyWord() variable. Which, here, we see it is not a "variable", but a "function", by the addition of "()". Which is NOT "$MyWord", the actual "global variable" which it returns with. Thus, saying "$X = $MyWord", would not trigger a function, just take the last known value within $MyWord. As opposed to "$X = $MyWord()", which obviously fires the function and returns the new value. Easy to explain and show, and use.
- Now "label", can be used for... Well, any object/image/video/container... which needs, or has a "label", and identifying display for the user to see, in the game/novel. (Usually labels are shown or used for images and buttons, for the blind text-to-speech to read, or for identification of them, like a buttons "label" is the text you see on it, or a mouse-over label.

=====================================

So, in short...

Make everything an object.
Give "object", a standard universal set of attributes, which is applicable to all.
- Scale, Align, Anchor, Alpha, Depth, Color, Shade, Background, Border, Padding, Margin, Rotation, Parent, Children, etc..
- Mouse-Over, Mouse-Out, Mouse-Click, Hover, Click, Outline, etc...

Give those attributes, common, and alias, value-sets...
- X, Y, Z, Top, Left, Bottom, Right, Center, Middle, ScaleV, ScaleH, Scale, North, South, East, West, Up, Down, Sides, Vertical, Horizontal, etc...

If it is applicable, it does something, if not, then it does nothing. It's just that simple.

Same would go with the transitions and transforms. (Assume they are all visual transforms not audible, for the sake of the following.)

If I apply a transform to an individual image, it should have the same ability to do that to an object, which contains 40 images. Those 40 images, (within a container), are treated as one giant image, processed with the same transform, and redrawn with the transformation. At the same time, I should be able to transform 20 of those same images, within that container, which are individual or grouped into a sub-container, with another transform. (Now you are opening-up some potentially complex stuff here, rather simply, with just object manipulation. Bones-animations, 3D simulation, layer-manipulations, fast-motion-actions...)

Not to mention that, since these are objects, we can append attributes directly to them, without complex code. Keeping those on the border-line of "using only RenPy function", remaining on the border.

- Thus, no specific "____ button", you can use anything like a button. (If you give an object "mouse-over" function, and "click" function, then it is now a button. No need to create a specific "button" object with specific functions, internally.)

- No specific "image", anything can contain an image. (The image is simply an attribute of an object. The "type" is only specific to how it is loaded, identified, located and used for transformations.)

See where I am going with this? You only need a super-short help-file, showing what each attribute does and what it will actually impact. (Eg, "Resize" or "Scale", not having any impact on a "sound". Well, it could be an alias, but that would interfere with "video", which has sound, and you would expect to be changed by "Resize" and "Scale". Resize of a sound could potentially be a distortion, as scale would also be... But that would only aid in the confusion. There are better standard words for sound-effects that can be used in sounds and also in video, without conflicting with visual deformations or attributes.)

The selectable {top-left}, {bottom-right}, etc... could also be used for setting orientation format of objects. Meaning, the display order being like windows, "top-left", or classic RenPy "bottom-left", or Asian formatting which is any of the four-corners. Universally, with those attributes applying to all objects, and everything is an object with orientation. Screen rotation is rather easy to manipulate with one line of code, or one simple setting. (For both testing and for use.)

The biggest thing will be the removal of confusing words that already have common names for other things. Like the use of the word "window", which is essentially abused by being a specific "function", a specific "identifier", the actual screen "window", and also specific "object", all at the same time, with global and local scopes, conflicting with Python's use of a "window", which is also every programs use of a "window", which is not RenPy's use of a "window", but it is...

I could extend upon this, but I am sure others will chime-in.

I would be happy to throw-out how some things should function, or be "named" for less confusion, and to follow standards. Even if some names must be non-standard and unique to "RenPy"... They can be non-confusing as a kind bonus. (No camel-hump formats and frog-skin, or slippy-velcro, or fruit-loops names.)

After all, the point of RenPy is to simplify "visual-novel creation", but face-it, visual-novels are not just static images with words and little shaking pictures anymore. Those can honestly be done, faster, with an image slide-show tool. Few are that simple, and almost all have some kind of "game" element to them.

Adding those elements seems to turn RenPy from being something simple and easy, into a confusing nightmare of development-stopping limitation of those who are not programmers. Rarely are good programmers also good artists/creators, and it is the same in the other direction, because they both use opposite halves of the brain. Those in the middle, still struggle on the code-aspect, with things the way they are.

You have an army here to help, again... Thanks to the explosive reach of visual-novels. (Not all are RenPy creations, but many are.) Take advantage of that situation, like we are.

[trooper6]

Um. This is not a Question--there are no questions in this post at all. This is a discussion of how you want PyTom to develop RenPy.

This should be in the Renpy Development forum not here in the Questions forum.

[ISAWHIM]

I have no problem with this being moved there... Though I am not "developing"... I was sure there was several questions in there, but they are not about a version of RenPy that exists. (So I get your point.)

It says "Discuss how to use the Ren'Py engine to create visual novels and story-based games."

I am never sure where exactly to post my questions.

[trooper6]

Also, you have very specific ideas of what you want and are clearly a very experienced programmer. Have you thought about creating your own VN engine? Then you could have exactly what you want they way you want it.

[ISAWHIM]

Also, you have very specific ideas of what you want and are clearly a very experienced programmer. Have you thought about creating your own VN engine? Then you could have exactly what you want they way you want it.

Yes, I have done so... But I eventually gave-up, when I switched to the use of a website for universal display. (PHP, MySQL, Javascript, HTML, CSS) Making "programs" was too-much of a hassle and my "language died" {VB6}. Making them work on every system was more of a hassle. Making them work offline was a nightmare. (Which is why I revisited RenPy after four years. Due to the GUI overhaul.)

I don't like being bound to web-hosts and the stupid limitations they impose on creative freedom. Individual programs don't have that limitation. I gain back my rights to publish with "free speech", without fear of losing my investments. (Like what happens on a web-host when they disagree with your "publications".)

I still believe RenPy is superior to most other alternatives. Seeing what it is capable of, with lots of dedication and love poured into it.

However, I feel it is still stumbling on "old ways", with that sticky-glue being Python-2.x and co-dependence on forum-helpers in a forum that is not clearly identified as existing unless you really dig-in to the home-page or depend on google. (Which shows more wrong answers from the past of older RenPy and older Python, but directs everyone to new-python code that just doesn't work with RenPy. Then it directs to the new documentation, which... well... keeps everyone in the forums asking the same questions over and over.)

RenPy has the foundation to be much more accessible to more minds, but remains trapped within four walls of reverse-compatibility and software limitations of a confusing predecessor.

[PyTom]

I don't believe this thread is particularly useful.

I will point out that backwards compatibility is very important. We have projects that have lasted 5 years, and we need to have an engine that will support their code for 5-10 years more.

[Imperf3kt]

And in 5-10 years, games that began today, need 5-10 more years of support, during which time, yet more games crop up, requiring 5-10 years of support. load vicious-circle

I'll admit that I don't understand 80% of this thread, but it seems to me that, whilst important, there comes a point where you need to force an update.
Split off and make "classic Ren'Py" for finishing and editing ols games, and make a new Ren'Py exclusively compatible with projects started in 20xx and later.
Its basically what Microsoft has been doing for several decades, seems to work for them.
The automotive industry is facing this challenge right now with fuel vs electricity.

[indoneko]

I agree with the post above me. If Isawhim and many other experienced programmers are willing to help, maybe we could have two version of Renpy developed in parallel. Sadly I don't know much about programming to be able to help...

[trooper6]

I thought PyTom was planning on migrating to Python 3 at some point? Anyhow, I just want to tell PyTom that I appreciate all of the work he does (for free, by the way) for this community and that I trust him to know how to develop the engine. You get lots of criticism and little thanks. So, thanks!

[ISAWHIM]

Reverse compatibility is not important for new games. They continue using the platform they are comfortable with. The functions don't change, only the way they are coded. There is no reason to upgrade an old game to a new development platform. They would continue to use the old one, if that is what they are proficient at. This would not be a "version update". This would be a whole new platform, in essence.

This is about "new creations", using "up-to-date" software and less confusing and less-complex code.

I am not talking about making this any time soon. That would be counterproductive to the existing work on this "style" of RenPy.

Let me give you an example of what I am thinking. (Sorry, but I am going to use HTML, CSS and Javascript as some of the example.)

In HTML, you can make any form of "object" be any type of object. In a way, you can do that here too, with the variables.

Code: Select all

<G ID="MyObject">Some Text</G>

That can be "displayed", as whatever I want... a "block", a "table", an "image", a "video"... Whatever I set it to, in CSS or with Javascript/CSS styles. I can hide it, move it, change the text, align it any way internally and externally, shake it, make it a link, make it respond to mouse-input, make it a receptacle for text-input, turn it into a checkbox...

However, when you do something like this in RenPy, it only ever has the specific set attributes of the object that you tell it to be. Each seeming to have special ways to alter them, which isn't the same between object types.

One object may require you to type code using python-like alterations, which do not have the same "wording" as the attributes that RenPy-like coding requires for that same attribute to be changed. (One specific attribute was mentioned above. The "menu", being Renpy access to the object, and the Python version being "renpy.display_menu", and the "renpy." is actually redundant and could be assumed. While many other attributes are "thisword" and "renpy.thisword", respectably, which IS understandable and requires no memorization.)

EG... If all attributes were like that, you would not need many pages to indicate EVERY "Python equivalent". But you do now, because they are not self-intuitive.

If EVERY equivalent was simply "someword" equates to "renpy.someword" for python... Then your help file and memory would only have to be...

"To access an object or attribute in Python, simply use the "renpy._______" format."

Poof, a single line help-page that requires no further explanation, beyond the knowledge of knowing what the "______" objects or attributes are. But, because it isn't standard (the same for everything), we now have to try to find the "mystery command", buried in the help-files, or ask about it in the forums, when the obvious doesn't work.

Granted, there are only a FEW items like this... but it only takes one item that defies standards, to warrant a need to write a help file for every single possible scenario where that is not the case. (Because if you wrote it for only that one non-standard variation, no-one would know where to find it. Oddly, writing it for every variation makes it almost impossible to find and provides the same confusion.)

So, standards... Every item uses the EXACT same format and wording and "attributes" as all other objects.

A "container" is set to have...
- A "background image". ($X.BgImage = $MyImage)
- It is set to have a "background color" which shows through the image-alpha. ($X.BgColor = $MyColor)
- It is set to have a mouse-over/hover attribute. ($X.Hover = $MyHoverStyle) <- Is actually another "container" like this. With an image and background-color and an outline.
- It is set to have text displayed across it. ($X.Text = $MyButtonText)
- That TEXT has a style, not part of the "=" value. ($X.Text.Style = $MyButtonStyle)
- There is a click-style and action. ($X.Click = BgImage($MyImageClicked), Action($MyButtonClickAction)) <- Using function/attributes which all have the same exact names as the actual attributes, so they don't need more than one page of "help" to show how they work, instead of hundreds of pages showing how each individual one is worded and functions and what it needs.

But wait... I want to alter this in another way... Since each object has a "Style" attribute... I could put all this into a "Style" section, and just say...

$X.Style = $MyButtonStyle <- All of the above, either formulated or literally typed in another location, like a "styles.rpy" file.

Styles using "with" style blocks...

Code: Select all

with $X:
    .Text = "This is a test", Align("Justify", "Top"), Color("#FFFFFF", "#000000-50") #<- That is foreground/background-alpha(50%)
    .BgImage = $MyBackgroundImage
    .Image = $MyMidlineImage
    .FgImage = $MyForegroundImage
    .VAlign = "Middle" #<- Or "Center"
    .HStack = True
    .CustomValue = MyExplodeEffect("Up")

The point being that each specific "attribute" and "object" follows the same exact internal standards, including the matching "functions" (Which they all are anyways... The "words" are just short-hand replacement variables that the compiler replaces with the actual function, when used.)

Code-wise... For "RenPy"...

You don't have to program every individual "type" of objects attributes... Like Images, and Video and Text-boxes and Input-Boxes and Check-boxes... They are all "objects", you only EVER have to write code once for "object", since everything is an object. The "types", simply have to be programmed to "do something", with each of the potential "attributes", that are available. They either do something, or they are not programmed and thus, they do nothing. If we "make-up" an attribute, then we tell that attribute what to do. (Even if it is one that isn't used, by default, for that object-type. (Like telling it to distort the sound if we use the attribute ".scale" on a sound, which has no actual default code for ".scale", because ".scale" is an attribute for a displayable object.)

Transforms would work the same way.

Honestly, "built-in" transform functions should be limited to the raw translations. Extra "prefab translations" that are specific, like "shake and slide-out", should be "modules" or "selectable plugins". No code editing, we just select that effect/transform for the project, and activate it. (At that same screen, there should be an option to rename it too. Since it may conflict with our code.)

The whole code for that plug-in "function", is editable, accessible without having to go into odd and "needing of help-file explanation", chunk of code that is appropriately placed for operating in any compiled visual-novel. Eg, at the unreachable lowest level, as if it were actually a "built-in".

However, if we never need it, it isn't included, and bloating our builds. (I am not sure if RenPy built-in's are "use aware", and if they are excluding them from "builds", if they are never used. I was just saying that the "plug-ins", would absolutely do this, without need to think or evaluate about what is or isn't used.)

[PyTom]

I'm going to lock this thread now.

You're not really discussing Ren'Py anymore, or something that's particularly sensible. I'll note that Ren'Py is a registered trademark of myself. You're free to fork the code under the terms of the MIT license, but you'll need to call the fork something else to prevent confusion. Feel free to discuss this - under a non-Ren'Py name - in the Other Engines section.

I'm willing to entertain improvements to the design of Ren'Py - but I feel that the current design is battle proven, and that we need to evolve incrementally to ensure we keep the benefits of a proven engine.