NaNoRenO – Yoshioka ~Day 1~

Yoshioka Aoi is a young girl training to become an idol.
As an up-and-coming rock star, this shining light of a seedy rock scene is noticed by an unproven producer from the idol production company ‘I MY ME’.
Surrounded by doubting smiles from the company’s staff, the two rookies entrust their dreams in one another.

Two years later, as her training period reaches its end, Aoi begins to question the path she’s taken. Why did she choose this path, and where will it take her?
Aoi is a cheerful girl who sings sad songs.
A rock star who finds loud noises scary.
The child her parents always wanted, but never had time for.
The little sister who made her brother run away.
An idol whom all the staff love, but none of them trust.
For two years, this is all Aoi has been…

In the transitional period of this young lady’s life, you—as her Producer—will be the only guiding light that believes in her dream.
Or… maybe she’ll be the one to guide you.

This is a game I was concepting last year as a learning project while following guides and using sample code sourced online… but I managed to program 4 lines in total before remembering I have responsibilities and bigger projects to work on, and I promptly scrapped it all.
But taking everything I’d learned from online tutorials and offline documentation into mind, this is a small game I’d like to make at some point, but with two major projects in the works, it’s not like I’d ever have time to sit down and make something new…
The urge to NaNoRenO is strong indeed; I’m finally feeling well enough to get back into the grind, the new technology I have to work with is exciting, and it’s nice to have an immediately-achievable goal. I’m not particularly well prepared this time around, but that doesn’t matter because—
Well, let’s just talk about the concept…

Aoi is a long-time OC of mine that as of today has little more than a design and a couple tiny bits of fiction to her name.
As an unofficial fan character based in the idol-filled Interlunium universe, she basically acts as an excuse for me to write post-rock music that I’ll probably never get around to actually producing.
But throughout 2022 I did a lot of testing with different mediums and styles, each sample project based on characters I had created in the past, in the hopes of finding a direction for the future… and the one utilizing Aoi got me very excited. The competing projects (one involving pixel art, one involving 3D) were interesting enough, but the plans I’d laid out for Aoi’s involved an unfamiliar engine and cutting-edge technology.
So before the futuristic tools and practices I’d discovered along the way become mundane to the march of time, I’m getting in early.

This is from 2018!

That said, this time around, I’m going small-scale. Smaller than ever.
This project is going to be maybe an hour long at most, and that’s being generous with my expectations.
It’ll have no narration, no internal monologuing, no routes, no choices, no menus… we’re stripping it down to the fundamentals. I won’t be drawing all the backgrounds this time, or making all the music again, or programming day-night systems or branching routes with wildly different endings.
Our singular sprited character will come with one pose (or two, technically… wait and see what that means), a bunch of expressions, and she’ll be fully voiced.
Our background art and music will be mostly free-use material because those aren’t the aspects I want to practice this time.

The goal of this year’s project is twofold: to learn how to use a new engine, and to make a game at a near-commercial level. I want this small little sample of a novel to feel like it was made by an experienced and established company, or as close to that as I can get.

To do so, I’ll be employing the KiriKiri engine, 吉里吉里Z 1.4.0 to be specific. I’m sure different parts of the audience reading this will be more aware of what that means than others, it’s a classic engine after all, but to cut a long explanation short…
It’s a very manual engine that relies on me building every little thing, but it grants me more immediate control over everything as a result. No tinkering around in the backend to break the foundations of the engine into what I need them to be; we’re making this game from the ground up.

For example, let’s say you want to fade the screen to black. In Ren’Py (the engine I used in my last two NaNoRenO projects) this would typically involve writing “window hide” or “window show” to hide or show the UI respectively, and then writing “scene black with dissolve” to fade to black.
If you have custom elements on screen, you might have to hide them too, but it’s a very simple and immediate process.

In KiriKiriZ, before I can start actually making anything, I have to create the commands to hide the window, or fade the screen to black. Honestly, this first day was dedicated mostly to doing that.

So first things first, I created a debug menu full of some general features I’ll need to create and test. Transitions, image movement, and ways to jump around the script so I don’t have to read the entire game to get to where I want to test. Most of it isn’t actually implemented, but priority number 1 is getting these debugging tools set up.

The very first line of my Transition Checking section is the perfect place to explain the feature that 90% of KiriKiri development revolves around: macros.
You can convert any chunk of the game script into a macro, which then acts as a command word encased in brackets.
For a quick example, I made a macro named [eol] that shoves all my end-of-line code (such as waiting for a click to progress the text, clearing the text after the player clicks, etc…) into one short command. This way, I don’t have to type three or four commands at the end of every line of dialogue; I only need to type one.

To go back to the first line of my Transition Checking code, the macro is…
[preamble]

This code basically just sets up all the images I want to use in transition testing: the namebox (on layer ‘message1’), the textbox (on layer ‘message0’), the character sprite (on ‘layer 0’) and the background image (on layer ‘base’).
The namebox, textbox and character sprite are hidden, and the background image ‘kuro’ is just a jpeg of pure black.
I want all of these images to be ready to go, so before every transition test, I want to execute this code… but instead of typing out all of that (or copy-pasting it whenever I need it) I can turn it into a macro titled ‘preamble’ and then simply type ‘[preamble]’ when I need it.

That’s how most things work in KiriKiri: a word surrounded by square brackets that triggers some code you’ve stored somewhere.
Once you’ve written something once, you never have to write it again!

Though KiriKiriZ is available to use freely by anyone, it doesn’t come with pre-written macros for basic tasks.
Typically the actually legit novel game companies would build macros from scratch for their first game, reuse them for the next game, and the next… and in such a manner their library of macros would expand and expand until everything they could ever need has already been written.
Some developers would partner with (or become employees of) production companies that supply these kinds of pre-built macro libraries. Other developers would pay to use ones that other devs have built.
One Visual Novel translation I did the programming work for (the Hokejo English translation) was built in a KiriKiri-clone by a development team named Citrus. While working on it, I discovered that the game repurposed macros and menus from Shuffle2, a game made by the parent brand of Citrus: Navel. Though the developers of these two games are completely different, they’re both ultimately part of the same company, so they shared their macros to speed up development.

Unfortunately I’m not an established company, nor do I have pre-built code of my own to fall back on. If you’re a real masochist, you could spend a few hours googling for macros that vaguely work but that you’ll probably need to modify or replace later down the line… I’ve made that mistake before in different engines. Frankly, the best of that stuff has already been wiped off the face of the internet, so there’s not much good to google.

Thankfully the text editor I’m using, FlashDevelop, has an incredible plugin for handling macros that auto-suggests things as you type. If I wrote “[prea” I could then hit ‘tab’ to autocomplete it to “[preamble]”
For more complicated macros that accept inputs, such as the transition macros I’m about to introduce, FlashDevelop then suggest all the different types of input that macro accepts, so you never forget how to use one and you never have to look things up.
Once you’ve built something, it’s very quick and easy to reuse it over and over again.

So! For the transitions, here’s what my debug script plays like:

It looks simple, but when I first started figuring this stuff out I was stuck fading objects in and out one by one, so the textbox would fade, then the namebox, then the sprite, then the background… it was terrible.

This debug section is written in “fade-in fade-out” couplets as… way too much code to fit on one screen.

But once I know the code is working and I’ve got all my transitions looking how I’d like, I can cut out the debug text, clean it all up, and turn that big brick of code into some tiny little macros…

I’ve set it up so that these macros accept four inputs: bg (background), sp (sprite), vs (visibility) and time.
Typing ‘[fade.all ‘ would immediately bring up a small menu showing all four of these inputs as options, so I can never forget how to use the command.

The use of a mouse is for demonstration purposes. Keyboard control is very speedy.

Now for this project, I’m only going to be using the crossfade transition, so I didn’t include transitions as an inputable aspect of the macro.
With the current scope of the game, I’m only ever going to have one character sprite on screen at once (placed on layer 0), so there’s no “fade one sprite only” command. This may change later, of course.
There’s also no sprite positioning, but you can just set up the image layer’s positioning while it’s hidden as I did in the [preamble] macro earlier.
This is what I mean by macro libraries expanding as you make more games; if I made another game in KiriKiri, I could copy these transition macros and add in a variation that lets you choose to fade in/out sprites based on what layer they’re placed on.

But I know what some people must be thinking…
All that work to fade the screen to black?
Unlike Ren’Py, this stuff doesn’t just work out of the box… I’m not sure you could say anything in KiriKiriZ works “out of the box” though. It’s more of a “build your own box” kit of URLs and downloadable files.
So there must be a payoff, right? Well, it’s all about that second goal: to make a game at a commercial level. What better reference point than the very pinnacle? ‘Mahoutsukai no Yoru’, recently released in English as ‘Witch on the Holy Night’, was created in a branch of an older version of KiriKiri and it looks like a movie.
Granted, they did it with far more time, people, resources and experience than I have, but, I mean… you don’t have to reach the top of the mountain to start climbing it.

This is a project with no narration and a very small script. We can’t wax poetic to get people feeling, so we need to rely on something else…
We’re treating this like a movie. We need voices, we need sound effects, and most of all, we need a great camera. Less novel, more visual. That’s where KiriKiri pays off.

*Here’s some cinematic flair from my previous NaNoRenO project built in Ren’Py. It took a lot of work to implement this kind of stuff, and it never felt good enough due to the line-by-line progression of Ren’Py.

Back in college, I was running two courses: English Literature and Filmmaking. It’s safe to say, capturing this cinematic style in a way that satisfies my mental image for what my games could look like has been a long-time goal, and hopefully this big switch-up leads me to the solution.

As a small bonus, the engine is also compatible with E-mote, a piece of animation software used to animate character sprites in games such as Nekopara and Go Go Nippon (neither of which I’ve played, so honestly I’m not sure how capable it is).
The software developers have created a handy guide for implementing E-mote into KiriKiri using the engine as the medium, so it’s the obvious go-to solution.

However, although this is available for any ol’ person to use, this is business software, only in Japanese, and getting the download (and a year-long license) involves email correspondence, so it’s not the most immediately-accessible solution. They only respond to inquiries on business days, so… I did that businessy junk before the month started, just to make sure I had the software ready to go in time.

Now, I’m not typically a fan of animated sprites in these kinds of games—honestly it always looked a bit naff to me when I saw it—but for the sake of pacing out the scenes in a game with no narration, we need something happening on screen when words aren’t being spoken, because… there’s nothing more obnoxious than a script that always speaks.
For the story to effectively communicate the right emotions, the various plot beats require time to breath—little pillow moments that give readers time to rest in the feelings of the moment.
So some subtle animation here and there to show what Aoi is thinking, which when combined with panning cameras, cutaways, sound effects, and everything that communicates wordlessly, should alleviate some of the cheesiness of sprite animation. And if it doesn’t? Well, at least it won’t be screaming for attention by being the only moving thing on screen.

So tomorrow we’ll get to work on Aoi’s sprite, designing her with animation in mind, and maybe we’ll even go a step further down the debug list to the ‘camera pans’ section and figure out how we’re going to do that…

That’s a brief introduction and a not-so-brief day 1 update on the game. It’s all foundational, so maybe it doesn’t make for the most enticing starter post, but… stay tuned for the cool stuff! You’re not gonna believe some of the tech on show this time.