I think probably you should try to have the job of, at most, one person. Maybe two — it is the 21st century. Four or five is right out. Generally how it’s meant to work is that you do one or two things, get good at those, and then you spend the rest of the time playing video games.
Here’s what I don’t recommend:
Say you’re an artist — just for example. Well, maybe on top of the art you think you’d really like to get into music. That’s probably alright. Hobbies are great! Then you think, y’know, it’d be extra great if I could combine the two. Maybe you have a few months’ misadventure where you attempt to animate a music video and it burns your brain to a crisp, so you figure, okay, if I really want to combine art with music, I have to lean off the art side a bit.
So far so reasonable. Alright. So, if we lean off the art, we need something else to prop up the story. We need a new main dish. You have some experience writing prose — you’re pretty good at it, you think. Prose plus art is easy: they’ve already invented that; it’s called a “light novel.” Getting the music in there makes it trickier.
Someone on your Discord server points out that you could just release music alongside the light novel. You find this option deeply imperfect. Like, the music has to play when it has to play. You can’t just leave that to the user’s discretion. It’s a UX nightmare!
You envision a visual novel. This is where the alarms should be going off. You’re already talking about art, prose, and music. And now you’re thinking, y’know, visual novels are one thing, though ideally you’d like this to run in a browser — and you want it to run fast, too, like, ideally the user should be able to click exactly one link and be reading the novel within one to three seconds. Nobody’s made this engine yet, as far as you can tell. It’s too late now: A fourth person’s job has silently taken up residence in your brain.
You get to prototyping. You take a crash course in the numerous web technologies you’ll need to know to make this work. You feel like you’re actually getting somewhere, though it’s taken a couple months of late nights piecing this stuff all together. (You take a break in the middle to finally release that cute minicomic you’ve been trying to finish for a year.) The more real the engine gets the more it occurs to you that you’re going to need a website to host it, so instead of getting a WordPress like everyone else, you put on a fifth person’s job-hat and spend another month’s detour learning how to code a whole website from the ground up to host your new engine.
You come back to the engine. It’s versatile. It looks great in GIFs posted to Twitter. Unfortunately, your little diversion into web design proper has cursed you with a knowledge of best practices for internet typography. See, your engine needs to run on phones, not just desktops. But like most real visual novels, you’ve designed your engine’s screen layouts for one specific font size. You figured you could have a slider for changing the font size to make it easier to read on phones, but what you didn’t realize is just how much space accessibly standards-compliant text takes up on a phone screen. This introduces scrolling to your text boxes. And scrolling is a second thing!
The engine already has a first thing. The first thing is the “next” button — you click it or tap it to progress. Now there’s scrolling? And only sometimes? Buddy, that’s two things. And two things is inelegant. When these text boxes scroll, it feels like an accident — because it is an accident. You didn’t design this UI around the concept of scrolling. Images flash through your mind of users missing parts of the story because they — perfectly reasonably — failed to expect one text box out of ten to scroll.
You throw the engine in the garbage can.
Over the next month you brainstorm ways to make this experience feel good regardless of what you’re reading it on. The heart of the issue here is the inconsistency — it feels bad for text to scroll one time out of ten. It’s unpredictable; it’s friction. It’s better for it to always scroll. But you can’t just put all the text in one column and let the user scroll down the whole story from top to bottom. You need page breaks, because page breaks are part of the storytelling of a visual novel — they’re where time passes, and importantly they’re how the engine knows when to start or stop playing music.
You’re not sure, but this probably counts as a sixth person’s job. This is teetering dangerously close to game design.
Okay. You playtest a bunch of ideas. You come up with a good one. You can still divide the text and illustrations up into separate pages — you can just pad out the text a little so that it always scrolls even if there’s not enough text to actually require scrolling. It seems counterintuitive, but in playtest it works really well. You code it so that the prompt to proceed to the next page appears only once you’ve scrolled to the bottom of the text box. This way, scrolling becomes part of the flow of using the app — the user never, ever has to think about it; never has to guess whether this is a page they need to scroll or not. (You make sure to include a dedicated “next page” button in the navigation bar for the purposes of flipping through the story quickly, but also make sure that it’s subtly less convenient to use — like the function keys on a keyboard.)
Begrudgingly, you also relinquish the versatility of the 16:9 layout you were planning to use. You make the app work at any aspect ratio. Phone users no longer have to tilt their phones 90 degrees to read. Making the layout work responsively like this forces you to use 9:16 illustrations, because a tall illustration on a wide screen is a lot more legible than a wide illustration on a tall screen. With some experimentation you find that this is actually a pretty alright form factor for drawing illustrations, so you don’t feel you’ve lost much.
You continue like this for a while, identifying design patterns and best practices for a kind of media that kind of, sort of doesn’t exist yet, but which you know beyond a shadow of a doubt definitely could exist.
It is taking a long time.
Incidentally —
In the background, as you’ve been doing all this, you’ve been brushing up on your prose. Practice makes perfect, right? You’ve written almost a hundred thousand words of it now. Some have argued that’s worth about a hundred pictures.
You really enjoy prose, it turns out; you post some of it pseudonymously and find that other people really enjoy it too. This owns. It occurs to you that instead of doing six jobs, you could have done one job. There’s some alternate universe version of yourself who has already written a story you want to write, because they did not consider it unforgivable for a story to exist as words without music, or for a visual novel to take a long time to load in the browser, or for text to scroll one time out of ten. That person has made a thing that some people find beautiful anyway. Again: The person we’re describing here exists, and they’re you, because you literally wrote some stories and posted them and people were touched. Your head is sweating profusely beneath the weight of six perfectly supernumerary hats.
Anyway, this was all an excuse to type the sentence “Your head is sweating profusely beneath the weight of six perfectly supernumerary hats.” That’s a lie. Actually I just have no transition out of this little second-person cautionary tale. (I’m still figuring out how to transition out of it in real life.)
Having said all that:
I did make the thing.
Pictured: The Thing. The illustrations are all placeholders, purely for demonstrating the UI. Note how The Thing works in any device orientation!
And now I do get to use it.
The engine is called re:VN. I was going to call it deVN (short for “Deconstructed Visual Novel”), but that kind of made it sound like I’m one of those freakazoids who thinks visual novels need to be “fixed?” So the D became an R and the title grew a colon.
At a glance it seems a lot more basic than what I had going with the previous iteration of this engine. The glance is correct: It’s way more basic. However, it feels really nice to use. And it’s consistent! And it works on everything — as far as I can tell. And: I’ve filled out the infrastructure on my end of things such that in order to write a story for it, I only need to sit down, write exactly one markdown file, and fill it in with a few illustrations and incidental OGGs.
The hat reduction surgery is upon me. Questionability of the process of getting here aside, I have, in fact, gotten here. It’s the part where I get to write the freaking story!
I’m starting things off with the long-belabored reboot of the barely-booted CURSE/KISS/CUTE. I hope to have this prologue chapter finished this month or the next.
I’m setting myself a goal here: I am going to actively try to make this first episode a little rough around the edges. If it isn’t clear by now, simply trying not to be a perfectionist rarely cuts it for me. So let’s try to prove a positive instead of a negative! Positively rough, positively imperfect. I’m going to allow the art to be a little inconsistent, the sound mixing to be a little rough; the engine might not even have a settings menu yet by the time you play it.
Instead, I’ll refine these things by iteration as we go along. It’s an approach that worked once, right? (I’m talking about my webcomic.)
What else, what else…
If you want to keep an eye on how things are progressing, I like to post regular progress shots and musings on the discord, which anyone over the age of 20 is free to join.
Oh — and my website! It’s (mostly) fully functional by now. Even if Twitter and Discord explode tomorrow, you’ll always be able to find out what I’m working on by checking the site!