Visual novel engines?

Are there any publically usable engines that could be used to run and create something similar to a visual novel?

Er...yep. Short question. Sorry for anybody looking for anything more substantial. =P

[Haeleth]

Dozens.

The most useful resource for you will probably be the discussion forum for fans making visual novel-type games at Lemma Soft - I'm sure the folk over there would be more than happy to fill you in on the various options. Looks like they're plugging Ren'Py at the moment.

If you feel like a challenge, of course, KAG3 / KiriKiri is probably the most powerful free engine there is - it was used for Fate/stay night, for example. But it's only documented in Japanese...

Oh hum. Hey. Thanks. *tosses the Visual .Net disks back into the Pile o' Junk* =P

[JudicatorOmega]

I want to use AVG32... Isn't it possible for me to keep the Kanon executable, get rid of the CG & Sound, and start with a blank scenario file? Surely there must be a tool to convert bitmap images to to PDT files.

I want to make a game where you are a knight living in a large castle area, and you get to date 3 girls. On the side, there would be comedy scenes involving you and one of the cooks in the kitchen who doesn't like you. I want the game to interactive in such a way that you can choose where to go often times. Such as going to the armory to sharpen your sword (even though you never actualy use the blasted thing), or to the infirmary where you somehow find that certain girl, or to a walk in the nearby forest, where you find some little kid who is lost.

Actually, this sounds like it would have legal issues if I ever made and released such a game onto the internet (even if freeware)... I won't like Ren'Py unless I was able to disable the rollback feature, change the font, and use a different type of options menu.

[zalas]

Yeah, I don't see why not (Re: Yukiroids) You might be able to use xkanon for it :/ I don't know if Key has an IP thing for the binary format :/

[Haeleth]

Yes, writing a game for AVG32 would be perfectly possible, and AVG32 is certainly capable of everything you describe. The distribution problem isn't really an issue; AFAIK the binary format isn't copyrightable or patentable, so the only problem would be distributing an interpreter, and you can get round that easily enough by distributing the game without an interpreter and pointing people at one of the many free demos of AVG32 games, as they can just copy the EXE out of one of those and use it.

The only unique problem AVG32 developers face is that the only compiler you'd be able to get your hands on is mine, and it's not particularly user-friendly.

Of course, you'd also face all the non-unique problems all game developers face, namely producing enough graphics, sound, and gameplay to support a game. But if you do decide you can manage it, and that AVG32 is your best option (there are other free alternatives that might be more to your taste than Ren'Py), I'd be happy to let you play with a copy of my compiler...

[JudicatorOmega]

I have not seen or read anything about how these games work. But I am going to take some guesses. Tell me if I'm wrong:

The engine reads the compiled scenario file which holds all of the script and defines which images and transitions to use when called for. There is a background image for the background and a foreground image for the character you are talking to. The story's direction depends on which choices the player makes, using some kind of variable with numbers that add up in such a way that they can't overwrite each other.

So if you ask Nayuki to help you unpack your stuff, then a certain number is added to "nayuki_points" and a bit later in the game, the story will choose to take you home if "nayuki_points" is equal to that certain number. This number is probably that "1|2|4|8|16|32|64|128|..." thing. I think they were called "flags", but I don't really know anything about that.

Well, I got some questions. What is an interpreter -- do you mean the AVG3216M executable? And, what can be so hard about working the compiler? Don't you just choose the files or folder and the compiler grabs up all of the files and spits out a smaller SEEN.txt?

Where can I get a sample of the Kanon or Air uncompiled scenario files? I am sure that if I look and study one of them, I can mimick the way they work and then make my own game. I once learned some C++ by just looking at random source code in Notepad and trying to figure out how to read it and understand it, so I should be able to figure this out.

[Haeleth]

You've got the right idea about the way the game works. In practice, in Kanon what happens is there are a number of variables for each character, which start at 0 and are set to 1 if you make certain choices. There is indeed a variable that's set if you ask Nayuki to unpack your stuff, although it's actually called <tt>int.300</tt>.

The way it all works, however, is slightly more complicated than you seem to realise. The script is actually in the form of what's known as bytecode, which is an abstract representation of the game logic that's easier for the computer to read. For example, the command

grpMulti ('BG001', 22, 'CGAY10', copy)

is actually represented by the bytes

0x0B 0x22 0x01 0x42 0x47 0x30 0x30 0x31 0x00 0x26 0x01 0x01 0x43 0x47 0x41 0x59 0x31 0x30 0x00

The interpreter (which is AVG3216M or whatever) reads those bytes and loads the bitmap BG001.PDT in the background and CGAY10.PDT in the foreground, displaying the result with transition effect 22.

The compiler is what lets you get from the text to the bytecode. It also handles things like converting the nice variable names like "nayuki_points" into the raw addresses like <tt>int.300</tt> that the interpreter requires, converting things like function calls and <tt>if...then...else</tt> structures into the goto commands that are all the interpreter understands, and so on.

The actual source code of Kanon that I'm working with looks like this:

title ('１月　７日　木曜日')
int.3 = 7
int.2 = 1
grpMulti ('BG111', 0, 'BG107', 0)
pause
int.0 = 0
grpOpen3 ('SIRO', 26)
str.1 = 'S_OP01'
int.10 = 27
int.11 = 1907
farcall (501)
unless (bit.1001 == 0) goto @1
ClearSkipMode
ClearCanSkipMode
goto @2

  @1
SetCanSkipMode
goto @2

  @2
bgmLoop ('002')
int.0 = 0
fade (1)
wavPlay ('DR_CLOSE')
'バタンッ！'
pause
'遠くから、勢いよくドアの閉まるような音が響く。'
pause
wavPlay ('ROUKA')
'ドタドタドタ…。'
pause
'直後、板張りの廊下を走るような足音が、冷たい空気を揺らしていた。'
pause

That's mostly so ugly because it's raw disassembled code (you lose all the structure and variable names when you compile code and then disassemble it again), so somebody using the program to write an original game would be able to produce something easier to read...

[JudicatorOmega]

I think I lost my nerve, as this looks more confusing to the eye than I thought it would be. I hope I don't ever have to learn how to read bytecode to become a good programmer. I think I would go insane if I had to read bytes instead of word functions made from English.

Looking at that sample of code, I can kind of tell this is the first morning in the game right? Its probably because I have no idea what farcall & goto do, but the only real confusing thing is:

farcall (501) 
unless (bit.1001 == 0) goto @1 
ClearSkipMode 
ClearCanSkipMode 
goto @2 

  @1 
SetCanSkipMode 
goto @2 

  @2

What is that SkipMode thing? If I draw atleast 2 background scenes and 2 pictures of a character, then may I ask you to help me get started on my amateur game?

[Haeleth]

Don't worry about the bytecode - the compiler handles all that, so it's my problem not yours. ;)

The SkipMode stuff handles enabling and disabling the "Skip text" option in the right-click menu, based on whether you've viewed the current scene before or not. Ideally you'd be writing for a more recent version of AVG32, like the one AIR uses; that handles text skipping automatically, which is rather convenient.

It was slightly unfair of me to post code straight from Kanon, actually. That chunk, if I'd written it myself, would look like this:

// Display date screen
title ('Thursday 7th January')
DateVar = 7
grpMulti ('BG111', 0, 'BG107', 0)
pause
grpOpen3 ('SIRO', 26)

// Display intro text with falling snow 
SnowIntro ('S_OP01', 27, 7)

// Begin January 7th

CheckSkipMode (bit.1001)
bgmLoop (cd_2StepsToward)
fade (fade_black)
wavPlay ('DR_CLOSE')
'-slam!-' 
pause
'Some way off a door closes noisily.' 
pause
wavPlay ('ROUKA')
'-dotadotadota-' 
pause
'The cold air vibrates with the sound of feet running along a wooden floor.' 
pause

Hopefully that will look slightly less scary... ^^;

If I draw atleast 2 background scenes and 2 pictures of a character, then may I ask you to help me get started on my amateur game?

I'm always willing to help people with the technical side of AVG32 or RealLive hacking. So yes.
Just don't ask me to help with anything apart from code - I program for fun, but I doubt you'd want to pay my rates for graphics work...

Can someone tell me why the script is compiled into bytecode? Is it just for obfuscation purposes?

I cannot see any meaningful speed advantage here to simply interpreting the script directly. I mean, the graphics code, simple as it is, would dwarf the time a good interpreter would spend reading the scene...

[Nephillim]

Well, I guess the only possible reason would be to prevent nosy players from spoiling the script for themselves :P

[Haeleth]

Good question. It seems logical to me, but that may be because I've been working with the stuff for so long.

Two possible answers present themselves. One is that while on today's PCs the overhead of interpreting text code would be negligible, things looked a bit different in the mid 90s when they started designing AVG32. The other is, quite simply, that it makes sense to separate the tasks: if you can give one team a compiler to write, and the other an interpreter, you're not actually doing much more work, and you are increasing modularity.

And why not bytecode? Many of the popular general-purpose "interpreted" languages actually work by compiling to bytecode and executing that each time you run the program; I believe Python does, for instance. (The alternative is to parse the code and execute by running through the AST, which is harder to design well, and very hard to keep from being very reliant on the internal memory structures - which is a Bad Thing by anyone's standards.) But if you're going to compile to bytecode anyway, and you're not making easy editing of source code a priority in the same way that Python does, why compile at runtime?

Ahead-of-time compilation is also useful for debugging - it removes the need for syntax checking in the interpreter, for one thing.

I do suspect Nephillim is partly right as well, though - obfuscation is clearly important, or they wouldn't have added the (stupidly weak) XOR encryption in RealLive.

[Nandemonai]

Java didn't REALLY resolve its speed problems until it adoped a bytecode strategy. It was QUITE slow until it adopted just-in-time compilation.

> Two possible answers present themselves. One is that while on today's PCs
> the overhead of interpreting text code would be negligible, things looked a
> bit different in the mid 90s when they started designing AVG32

Maybe. But coupled with an application that has to draw full screen graphics, i can't see the difference being worth it on /any/ specced machine. Oh how frustrating my old DOS days were, realising how much of my time was being taken simply copying to video memory...

> And why not bytecode?

I was not challenging this. Just wondering why any kind of preprocessing was required at all :)

But yes, i had not thought of the idea that it makes the actual game executable much simpler. It was probably a mixture of things... that, and 'oh look if we do that it has these cool side effect also', etc.

Anyway, was just curious to learn if there was a big reason for it. Obviously not :)

One other thing is that you cannot really compare this case to Java or Python. This is much, much more high level and so parsing at run time doesn't have anywhere near as much impact.
It's the difference between a Perl or Python program being expected to run code represented in your source by thousands of lines in less than a second, and the Kanon script seen above where you only have a few lines of code per scene.