Cafe Enchante thoughts

I finished playing Cafe Enchante for Switch a while ago, but my sister-in-law just blitzed through it. Also I found this article half-written and thought I’d better just force something out.

First note: Aksys advertises this as “the Hallmark movie of otome games.” Someone on a Discord server, I can’t remember who, said this was only true if in the Hallmark movie the Christmas trees ate people. The advertising and the trailer are happy lighthearted things, and due to other VNs, readers are conditioned to think of cafes as places of deep navel gazing and inner truths.

And there is some of that here, but there’s also far more action than I was anticipating. Also tragedy. I went through a lot of tissues reading this, and I didn’t even get to any bad endings. I’ll put the marketing miscalculation on both Aksys and Otomate- the opening movie is far too cute.

the box art

The good news for those who enjoyed Code: Realize is that this game has the same writer and narrative structure. There’s a long common route with lots of clues in it (eight chapters), and each character route has 4-6 chapters. I’ll let you read synopses elsewhere. If you don’t like long common routes, this may not be for you. Each route has a good ending and one or more bad endings, and the bad endings don’t add anything to the story. So I would skip them, you’ll get plenty of sadness anyway.

Unfortunately, the translation is not good. There are typos everywhere. If that bothers you but you want a similar experience, I’d play Code: Realize instead.

What stood out to me in this game is the heroine, Kotone. She’s feminine, with a quiet but unshakeable strength, which is something I don’t see a ton of in otome. She understands her shortcomings and the role she can play in each story. She doesn’t go rushing into danger. If you’re looking for an action girl, she is not it. But she pulls off something in the common route that is every office drone’s fantasy, and she does some brave emotional deeds for her love in each route.

The love interests are all good men, and I do adore that. The side characters all get to be plenty involved. I do wish there was more than one other female character Kotone really got to talk to. It felt a bit harem-y otherwise. There is also Vennia, who Kotone calls he but is nonbinary. I would have liked it if the team had stuck with “they” pronouns. Also, we have adorable mascot critters: a narwhal demon beast thing, and a clay doll.

shady assistant
I am sure there is nothing shady going on with this side character.

I loved all the routes. They managed to make a tsun I liked. Rindo’s route emotionally affected me in a way that VNs rarely do, because I have asked a lot of the same questions of my future as he did. The final route goes places I did not expect. The story in general goes some pretty dark places. No sexual assault or anything like that. But there’s plenty of existential despair, loneliness, and real danger for those who like to have their heart stomped on by their VNs. The final ending was not strictly happy. The couple ends up together, but the circumstances are not convenient for them. They have to pay for their happy ending.

these side characters, on the other hand, are probably the real heroes of the story

For me, the game was a fantasy that was just real enough that it holds a special place in my heart. I hear this game can feel slow-paced to some readers, especially with its long common route. If that’s usually a concern from you, I might pass. There’s also nothing too spicy that will make your grandmother clutch her pearls here, besides a tongue-kiss CG. If that doesn’t dissuade you, then I’d recommend Cafe Enchante.

welcome back

to blogging!

I’m working on programming a UI for Melow’s upcoming game Colors of Fate. I’ve learned a bunch and am happy to share it…once my code is finalized.

I’ve also realized that people like otome recommendations. Personal curation isn’t something you can always get from Steam or VNDB. So I’ll do some spotlight of games I recommend. These are not precisely reviews. I don’t like giving scores or grades.

So I’ll see you around again now that it’s 2021. Here’s to a better year than last.

when does Ren’py think I’m in the main menu

n.b. This information is accurate to Ren’Py 7.3.x and should also work for versions 7.0.x, 7.1.x, and 7.2.x. It will most likely not work for versions prior to 7.

Screens are often the biggest programming component to a VN. There’s a ton of ground to cover there, but here’s a gotcha specific to the main menu that I thought I’d highlight first.

how the heck do I know if I’m in the main menu in the GUI?

Ren’Py’s engine always has a ‘store variable’ set for its main menu- that is, it keeps track of whether it’s displaying the main menu or not.

This allows you to display other screens differently if you have the main menu up. All you have to do is check the main_menu variable to see if it’s true or false. It can’t have any other value.

Example code:

        if main_menu:

            textbutton _("Start") action Start()

        else:

            textbutton _("History") action ShowMenu("history")

            textbutton _("Save") action ShowMenu("save")

This is code from within the base code’s navigation menu.

If you haven’t started or loaded a game yet, you’ll be in the main menu as the first screen. Ren’Py knows that you can’t look at your conversation history or save your game when no game is loaded yet. So instead it gives you a button to start a game.

So here’s a gotcha when designing a GUI- if you have elements that link back to the main menu, you can run into an error if you call action MainMenu().

Here’s an example:

textbutton _("Main Menu") action MainMenu()

This code is from a Preferences screen somebody coded. When they tried clicking on the text button, sometimes Ren’Py would crash.

The problem occurs when a game hasn’t been started or loaded yet. Ren’Py thinks it’s still in the Main Menu even when you bring up the Preferences screen. So it crashes when it tries to return to the Main Menu, because it thinks you’re already there.

When you’re in the Preferences screen before you’ve started a game, the Return() action will take you back to the Main Menu screen. To make sure the button executes the correct action, you can check the main_menu store variable.

if not main_menu:
     textbutton _("Main Menu") action MainMenu()
else:
     textbutton _("Main Menu") action Return()

tl;dr: Ren’Py considers you to be using the Main Menu screen until you’ve started or loaded a game.

The Main Menu screen has some other unique traits I’m curious to explore. Next up: playing videos in the Main Menu, and how other screens use the Main Menu.

how do I change the opacity of the dialogue box in Ren’Py

This information is valid for Ren’Py 7.3.x. I believe it should work all the way back to Ren’Py 7.x. The names and values I use for the variables do not need to be yours.

This tutorial’s going to reference the last one a bit. We’re going to use the Preferences screen with persistent variables again. Only this time, we’re playing with a slider and transforms. The goal is for the player to adjust how opaque they want the dialogue background (but not the dialogue), because it can increase readability in different circumstances.

Open up your script editor and define the persistent variable, probably in options.rpy or wherever you have other persistent variables stored.

Screencap of code, defined below

Below’s where I put the code, in between the stock gui.about variable and the game’s short name:

define gui.about = _p("""
""")

# additional persistent variables begin here
define persistent.dialogueBoxOpacity = 1.0
# end extra variables

## A short name for the game used for executables and directories in the built
## distribution. This must be ASCII-only, and must not contain spaces, colons,
## or semicolons.

We’ve named the persistent variable dialogueBoxOpacity, but you can name it whatever you want. We set the default value to 1 because that means completely opaque.

Next, we figure out where on the Preferences screen you want to add the slider that will control the opacity. Your Preferences screen is probably defined pretty far down in the screens.rpy file, in the screen preferences() function.

screen shot- code is below

In this case I’ll put it in a new column (vbox). Here’s the code for the menu setting:

label _("Dialogue box opacity")
bar value FieldValue(persistent, "dialogueBoxOpacity", range=1.0, style="slider")

The label value is what you want the user to see headingwise. The bar is a Ren’Py object that is used when you want more fine-grained control of your variables.

In the parentheses, persistent means we’re setting the value of a persistent variable. The next string should be the same as the persistent variable name you used above.

The range=1.0 statement defines the max value of the bar, which is something we can set to correspond to the values we want possible for the opacity setting. All bars have a minimum value of 0.

That wraps up our work in the preferences screen part of the file.

Now, this is a bit more complicated than the style refresh we used to change the background of the dialogue window. Since there isn’t a predefined style for the opacity, I don’t know how to just inject that.

Instead, I put a transform for opacity in the Say screen. Every time this window gets rendered, it will check the opacity of the dialogue box and render that before it renders any text (so the text is always opaque).

The Say screen is traditionally defined about a hundred lines in to the stock screens.rpy file.

Under id “window”, we’ll add the following line:

window background Transform(Frame("gui/textbox.png",xalign=0.5, yalign=1.0), alpha=persistent.dialogueBoxOpacity)

window background Transform, uh transforms the window background. Frame is used to define a window that has a background. We need to specify the background being rendered, which is traditionally saved as textbox.png in the gui folder.

xalign=0.5, yalign=1.0 puts the window at the bottom of the screen, centered. You may have different settings in your custom GUI, in which case you should change these values to whatever you have defined in your style window: block.

alpha=persistent.dialogueBoxOpacity applies an alpha transform to the window. Here, the code consults the persistent variable to determine how opaque your image will be.

You should be good to go. Any questions or things I should clear up?

Further notes

As it is, this code allows you to use only one background. You can have the name of the background be a persistent variable too, but I’m assuming this is not a common use case. If you want to do it, leave a comment.

how do I use different color schemes for my dialogue boxes in Ren’Py

This information is valid for Ren’Py 7.3.x. I believe it should work all the way back to Ren’Py 7.x. The names and values I use for the variables do not need to be yours.

Some readers prefer reading light text on a dark background. Some prefer the opposite. You can make this a user setting, or Preference, in your Ren’Py game.

Ren’Py gives you several baked in Preferences in the default project that you can use, or not. There are a heck of a lot more that are native to Ren’Py. However, they don’t cover everything, and you may want to make some of your own.

Preferences are a kind of persistent variable. A persistent variable is a game setting that stays constant when a player exits a game, and even stays the same across playthroughs. To make your custom settings, you’ll need to define and set a persistent variable.

Open up your scripting files in your code editor of choice.

options file

Here’s a “blank” game created by Ren’Py 7.2.3. I’ve opened the options.rpy file. You can put persistent variables many places in your scripts. You can make a file just for them! In this case, though, I put my custom persistent variables in the options file because it makes sense to me.

# additional persistent variables begin here
define persistent.colorscheme = "lightondark"
# end extra variables

The comments (# lines) are for my own convenience so I can locate the preferences in my files later.

With this statement I’ve added a persistent variable called colorscheme and given it the default value of lightondark (with quotes, so the computer reads it as a text string). In order to make a variable persistent, you need to have “persistent.” in front of it.

Next, we want to add the option to our Preferences screen. Open up screens.rpy and find the screen preferences() function.

This is an example of the default Preferences screen. It makes a layout with vboxes and hboxes. You may have already changed some code in here, and that is fine.

n.b. I have word wrap enabled in my editor. Make sure you put what’s in line 874 all on one line. Same with line 875.

Figure out where you want to position your new option. In this case I decided to stick the custom preference in a new column.

style_prefix radio

style_prefix "radio"
label _("Dialogue box")
textbutton _("Light on Dark") action SetVariable("style.say_dialogue.color","#fff"), SetVariable("style.window.background", "gui/textbox.png"), SetVariable('persistent.colorscheme','lightondark'), style.rebuild
textbutton _("Dark on Light") action SetVariable("style.say_dialogue.color","#000"), SetVariable("style.window.background", "gui/game_menu.png"), SetVariable('persistent.colorscheme', 'darkonlight'), style.rebuild

radio means the user can only select one of the options. The label’s what you want the preference to be called. Here we add two options which display as Light on Dark and Dark on Light.

action tells Ren’Py to do something when that text is clicked. On these lines we’re telling Ren’Py to set some variables and then refresh the look and feel.

SetVariable("style.say_dialogue.color","#fff"),

This will make the text color in the dialogue box white. You can sub in any hex color for #fff.

SetVariable("style.window.background", "gui/textbox.png")

Surprisingly window.background only seems to apply to the dialogue window in a blank project. If you have other windows defined in your UI, though, this line will change the background for them too. Anyway, we’re setting the dialogue box background to be the textbox.png file stored in the gui folder. It’s a dark image, but you can use whatever you want. I don’t think you can define a color for window.background.

SetVariable('persistent.colorscheme','lightondark')

Here’s the variable we defined in options.rpy. Note that this is the same value, lightondark, as the default. That means the Preferences screen will render this as selected.

style.rebuild

We want to make Ren’py refresh the colors/images now according to what the user has just set.

The next line of code lets you define an additional possible background and text color for your dialogue box.

Further notes

You do not need to use these two color schemes. You can have as many as you like. You can also change the font itself, or spacing. However, the more tweaks you want to make, the more you may want to define your own style.

I didn’t suggest defining a style above because we’re just trying to get things to work. That’s something for another day.

why are you going on about ren’py

A lot of indie devs use Ren’Py. It’s free and relatively easy to install and get started. That said, it’s still an engine. Any programming in it…well, it helps a lot if you have object-oriented programming experience, but most people don’t. Ideally, these tutorials will be more detailed than code doc.

There are forums, such as Lemma Soft Forums, and also an adult site (I will not link to because I want this on Safe Search, but it’s eff ninety five zone) where you might find answers to your questions, but searching forums can lead to being unsure about whether the information’s outdated.

I will try to label which version of Ren’Py I used and which versions I think will be compatible with the tutorial.