Blade Visual Novel Engine

[mikey]

Well, the image line only appears once in the Ren'Py game, FWIW. (The syntax is also kinda off.)

Yes, but see how brilliant my scheme was , now we have a corrected direct code comparison with exact codes (I just typed what I remembered, although I did forget the labels, admittedly. And the indentation).

That's 23 non-empty lines for Blade versus 10 for Ren'Py... and I would expect the gap to widen as the game gets bigger. (I don't know how many lines this would take in Papillon's engine... I suspect it's not comparable, since I believe the images are defined out of band.)

Lines of code are only one metric, however... I personally believe Ren'Py is easier to read, since there's less use of magic numbers. (For example, we use "witch" rather then "0" to refer to the "Witch" character.)

(However, remember I'm quite biased here, so take what I say with the appropriate-sized grain of salt.)

Well, it's not like it's a lie. And apart from the less lines, the second argument is also worth a lot - since it's not those scary programmers' brackets, and no unnatural @s in the text. And it's much clearer where you are, you have a better overview and you script the file mostly with WORDS, as opposed to shotcuts and weird signs.

As for the "-quotation marks and indentation, it's the trickiest part of Ren'Py. But it's not so hard getting used to it and it becomes quite natural - plus the internal editor highlights and indentates everything, you have a built-in debugger, so it's substantially easier.

So there you are, at least for me, this is quite a clear proof that Blade isn't simpler than Ren'Py. It doesn't mean that for some people Blade can't be more conveniet of a choice, maybe they find its scripting system more attractive, and that's okay. But I think the code comparison shows a lot, and everyone can decide for themselves.

[Adorya]

Minor news, but HDmake a note about the commercial release of Blade as well as a little reminder of his 2 friends, Onscripter and Ren'py

[RedSlash]

Looking at both examples, I still find ren'py to be very programming language-like compared to Blade.

When a new person, who knows nothing about the two engines (and knows nothing about programming) wants to make a VN and has to choose one engine, they may come across our ren'py site and randomly select a tutorial, for example:
http://www.renaigames.net/dev_renpy4.html
then come across our nice cookbook page and randomly select a tutorial:
http://renpy.org/wiki/renpy/doc/cookboo ... e_and_Load

While I look at these two pages, my first thought is that ren'py is a programming language.

When I read the Blade manual:
http://www.bladeengine.com/BladeEngine/ ... anual.html
The site is hideous, but when I look at how to write Blade scripts, its quite simple compared to ren'py. Most commands follows the format of:
@command <parameters>

and that makes up the basics of Blade engine. Sure, this has its restrictions, but it is simple.

Here is an example of what I would think a newbie would find confusing with renpy. Why must I play a ogg like:

Code: Select all

$ renpy.music.play("mozart.ogg")

and not like

Code: Select all

playmusic("mozart.ogg")

esp since we don't show images like:

Code: Select all

$ renpy.image.show("myimage.png")

The '$' would throw me off when I don't do the same with other commands.

What will turn away the new user is not Blade's cryptic use of names and parameters, but rather ren'py's structured programming-like format.

Is it possible that this is where Blade has its advantage for someone to shell out $30??

[monele]

Hmm... while I have a hard time accepting this (being a programmer), it does make sense :/... Maybe what Ren'Py needs are more "easy" keywords such as there are for images, dialogues (name "text") and showing graphics (show/hide imagename). Not for big complex things, but, as suggested, for music and sounds... since that's one of the things people will look at immediately.
Obviously, once you start modifying the interface and stuff... you just can't expect things to stay that simple though.

[Jake]

Maybe what Ren'Py needs are more "easy" keywords such as there are for images, dialogues (name "text") and showing graphics (show/hide imagename).

As it goes, these things are usually referred to as "syntactic sugar". Which is a wonderful term, in my opinion.

But yeah, I think I agree - having sugars for some things but not others does seem a little odd. And hey, I've been a programmer for years and I still forget the dollar signs at the front of Python lines all the time.

Obviously, once you start modifying the interface and stuff... you just can't expect things to stay that simple though.

On a semi-related note, I've been starting to look at my long-time pie-in-the-sky project of a UI tool to generate Ren'Py scripts recently. Not a programming tool, more of a fuzzy-felt drag-and-drop type affair. Having worked through some of the data structures necessary, I don't think it will be even possible to include much past simple branching-choices-with-a-few-variables VNs without delving into the realms of huge pre-fab chunks. It should hopefully be a useful tool for the absolute beginner, though, and possibly even useful as a rapid-prototyping tool for more experienced users. But that's weeks of work and another long discussion with my employers about code ownership off, though.

[mikey]

Maybe what Ren'Py needs are more "easy" keywords such as there are for images, dialogues (name "text") and showing graphics (show/hide imagename).

As it goes, these things are usually referred to as "syntactic sugar". Which is a wonderful term, in my opinion.

It would probably be nice to have a syntactic sugar for music - Ren'Py has one for text and pictures, music is the only thing that's "missing".

playmusic intro
stopmusic intro with fade=30

...would probably be nice.

Hmmm, anyway, another almost unrelated idea in regard to your UI brainstorming: How about a Blade<->RenPy or simply a Blade->RenPy converter? I don't know how hard it would be to program this, but at least for the general things like roughly transferring your game into Ren'Py it could work. The transitions and effects aside, probably. You could start in Blade and then when you don't think it's sufficient, you could migrate your game and see how it could look in Ren'Py. Well, just a thought in case people are bored.

[Jake]

Hmmm, anyway, another almost unrelated idea in regard to your UI brainstorming: How about a Blade<->RenPy or simply a Blade->RenPy converter? I don't know how hard it would be to program this, but at least for the general things like roughly transferring your game into Ren'Py it could work.

The core capabilities of the two engines are similar enough that I don't doubt it's technically possible to do a faithful Blade->Ren'Py conversion, and it's probably possible to do a good Ren'Py->Blade conversion in most cases, but the problem is that both options would require writing code that automatically totally parses and understands source script/s in the engine's native language, which makes it a significantly harder task than just generating the scripts in the first place.

By way of analogy, if you have a program that has a data structure that stores a set of people, and a set of objects they own, it's easy to have that program write out the English sentence "John has an Apple; Mary has a Tricycle." - just prepare a pre-fab sentence "{0} has {1} {2}" and insert the right values and the right article, repeat as many times as necessary with punctuation between each item. It's an awful lot harder to write a program that could understand every different way people might write those relationships ("John owns an Apple. The Tricycle belongs to Mary").


That said, Blade's script does look at first glance a lot more inflexible than Ren'Py's, and thus probably easier to parse. Personally, though, I probably wouldn't want to do such a thing. While writing code to autogenerate scripts for one engine is just a personal statement about which engine I prefer, writing a converter from Blade script to Ren'Py script feels a little more aggressively partisan.

[SolarSnake]

Actually, writing a Blade -> Ren'Py converter might well discourage people from using Ren'Py. Since if you use Blade and don't like it, you can always change.

I think that the tool that would likely encourage people to use Ren'Py is a Ren'Py->Blade converter. This way, you can try Ren'Py and if you really don't like it just convert it to Blade.

While people don't do cost/benefit analyses explicitly, they often do them implicitly. An A->B converter (which works) lowers the cost of A, since you're removing the lock-in costs.

And, when you get down to it, the Ren'Py community writing a Ren'Py->Blade converter strikes me as less aggressively partisan, even though it would probably have that effect.

[mikey]

Well, I meant it as a technological exercise. Maybe it would have that impact, I'm not particularly good in judging such things, but I use a lot of format converters - having a VN one seemed like a good idea, especially as different engines give you different feels (RPtoB seemed like a good start since the scripts are most similar I imagined). We could see a few remakes - you know, GSK 2007 for onscripter... but as I said, they are just thoughts. I admit, if I had a converter to at least help me with the core work of transferring my older releases from MMB to Ren'Py, I would definitely do it. Now, it's just too complicated for me - and I'm probably going to channel my energy into new projects rather than converting old ones until I have a sufficiently simple solution. Probably keyboard/mouse macros, like I've been doing it before.

[PyTom]

A Blade -> Ren'Py converter is something I've though about for a while, although it's not something I've put much effort into. There are two problems that would make it interesting.

The first is that Blade refers to images as filenames, whereas Ren'Py allows images to be referred to with real names. So there's a question of what to translate these names to when moving them into Ren'Py.

When encountering:

@chr_load A,character01.png

Do I translate it to:

show expression "character01.png"

or to

Code: Select all

init:
    image character01 = "character01.png"

...

show character01

or to something else? Please note this affects how easy it is to work with the generated script.

The second issue is similar. Ren'Py supports showing an arbitrary number of images on the screen, but it's easiest to treat them as a stack, in which images are added to the top of the screen. Blade has 4 layers, which can be treated independently.

Now, Ren'Py can easily emulate Blade this with with the "zorder" clause of scene and show. But that's kinda ugly, so I wonder if there's a better way.

A Blade->Ren'Py converter is something I'd consider writing if someone asked me for it. It would have to be as part of a substantial project, where me writing this is easier them me or someone else doing the conversion by hand. It isn't a priority.

(I'm going to organize my thoughts on syntactic sugar, and post on them later. But until then, how does:

Code: Select all

music.play("rock.ogg")
e "Let's rock!"

Look?) (Hey, a code block in a parenthetical.)

mikey >>> What format is MMB? Is it textual?

[mikey]

mikey >>> What format is MMB? Is it textual?

Unfortunately, no, it's WYSIWYG, object-oriented, something like AGS (adventure game studio), there's nothing text-based at all.

[Jake]

When encountering:

@chr_load A,character01.png

Do I translate it to...

It's kind of tempting to suggest:

Code: Select all

init:
    image A = "character01.png"

...

show A

- just on the grounds that whoever wrote the script in the first place will still be able to comprehend it.

If I were writing such a tool I'd want to make the output as human-friendly and edit-friendly as possible, so the first option would be out - I'd probably end up showing the user of the tool the picture in question and a dialog prompting "What is this character (A)'s name?"...

I guess fundamentally my opinion is that in all cases I can think of Ren'Py's script can be a lot friendlier to read than Blade's, so there's little excuse for an auto-generated Ren'Py script to not be. I only hope I can live up to this expectation with my own efforts.

[PyTom]

Assuming I understand blade correctly, that's not what:

@chr_load A,character01.png

means. It means to load character01.png on layer A, not to name character01.png with the name A. We could later on do:

@chr_load A,character02.png

and the translator would have to do with that.

(Probably, the proper way would be to stick zorder clauses on all show and hide statements.)

[monele]

This conversion thingie is tough... In a way, switching to Ren'Py should mainly be because of ease of use (well, coding)... so, adding zorders everywhere and using "show expression" would lead to a Ren'Py script which is as complex as the original Blade one (kinda...). But obviously, from a simple

Code: Select all

@chr_load A,character01.png

How can you guess what the file represents? What the person would like to call it as an image? The automatic way would be to turn this into image "character01" and have it be the "character01.png" file. But then again, you lose the Ren'Py character advantage.
Maybe it would need a bit more work from the author, answering questions before the conversion?
"Give the name of all your characters", "what pictures represent this character", "what name/mood do you give for each?". It could then do a really good conversion... But absolute automatism just can't do that and you will find yourself coding Blade into Ren'Py, as an author (plus learning the new language and seeing all the good things you can't really use right away...).

Code: Select all

music.play("rock.ogg") [/quote]

I think parenthesis might be what scares people? It's a very coder-oriented concept. Actually, the dot notation is, too.
"image something = 'somefile.png' " looks better and almost like one of the simplest mathematical expressions.

[RedSlash]

I think that the tool that would likely encourage people to use Ren'Py is a Ren'Py->Blade converter. This way, you can try Ren'Py and if you really don't like it just convert it to Blade.

This would not make sense because ren'py does everything Blade can do and more.

A Blade -> Ren'Py converter is something I've though about for a while, although it's not something I've put much effort into.

I also believe this is not worth your efforts. I think it would be better to concentrate on defining more higher level interfaces for a future release of ren'py (ren'py v7, perhaps). This way, you can make ren'py syntatically as simple as Blade, while maintaining the same power through the use of custom python programming.

Code: Select all

music.play("rock.ogg") 

Yes, in terms of designing things for idiots, parenthesis will scare people as a programming concept. So will object oriented names like music.play.

If you stick with the music.play, then the concept should stay consistant throughout the program (i.e. image.show, background.show). Right now, there commands such as

Code: Select all

show someimage

which is inconsistant with the dot format. Therefore, your music playing commands should probably stay consistant with the current renpy format. i.e.

Code: Select all

music rock_music = "rock.ogg"
play rock_music

Another example of inconsistancy:

Code: Select all

$ john = Character("John Smith")
image black = "#000000"
$ renpy.music.play("rock.ogg")

Defining characters are different from defining images which is different from playing music.

I would rewrite as:

Code: Select all

john = Character("John Smith")
black = Image("#000000")
rock = Music("rock.ogg")

or

Code: Select all

character john = "John Smith"
image black = "#000000"
music rock = "rock.ogg"

This also reminds me that the concept of loading stuff into variables also turns out to be very programming like. Therefore, it would be nice to support specifying things directly.
ie.

Code: Select all

play "rock.ogg"
scene "mybg.png"
show "image.png" with dissolve
text "John Smith" "Yoyoyoyo!"

I know that specifying things like that is counter good programming practices, but I think the above code format appeals more to beginners. You can still maintain backwards compatibility for the old people who are used to the current way of doing things.

I think adding more higher level interfaces would be beneficial in making ren'py more attractive for beginners.