I played over 100 visual novels in one month and here’s my advice to devs.

Surprisingly, the title isn’t clickbait. As part of my judging requirements for Spooktober Visual Novel Jam, an annual Halloween-themed visual novel jam I cohost, each judge had to play around 100 visual novels in the month of October. Each of the games were made in 1 month during September by teams or solo devs.

Together with my fellow judges, we’ve compiled a list of advice for visual novel developers based off of trends we saw while playing through the entries and ways to avoid common pitfalls.

ease of use / accessibility

If your visual novel is difficult to read, that’s a problem. Make sure you have legible text, make sure the user can advance through the story as easy as possible, and if you want to make the users do something other than “tap” to continue, it needs to be way more rewarding than it is difficult.


One of my biggest complaints from entries was a recurring theme of inaccessibility for players. Games that don’t let you click or press space or press enter to continue but instead have some arbitrary keybinding; games where the text speed cannot be set; games with no history log or back button so you can review seen text; games with no save or load; etc.

Your game is not a PVP with the player. We’re making visual novels here. I shouldn’t have to go through a puzzle sequence figuring out how to interact with a visual novel.

I had no idea this would make a difference to me, but it really helped when entries had friendly, clear, visible user interfaces, good/intuitive control schemes, all the standard visual novel features such as rollback, autoplay, skip, and the like. Additional accessibility options such as more readable font options and turning off special effects such as chromatic aberration were very appreciated as well.


I urge people every year to not make their own visual novel frameworks from scratch. It’s so much more effort than people think and takes so much time to polish as there’s much more that needs to be made than just printing text on the screen. There’s no good reason to try to make one from scratch for a one month game jam rather than on your own time, as there are plenty of ready to go visual novel frameworks that your players will thank you for.

Ren’Py – it’s free and has so many visual novel features (save/load, auto text, skip text, history, back, seen text, etc.) in the box. If you’re not utilizing 3D or don’t want to do a console port, then consider Ren’Py.

Naninovel – it’s a paid framework for Unity that works so, so much better than any homebrew framework I saw out of the 100+ VNs this month. Elringus has dedicated years to making it work great, so if Unity is your choice, please check it out.

Fungus – a free framework for Unity. Naninovel has a lot more features but if you’re on a budget then check Fungus out.

don’t shoot for the (word count) moon

One fatal flaw I see every year among game jammers when they tackle visual novels is that they try to make a giant story with 40k+ words, or a dating sim with multiple love interests, etc. A lot of the teams that attempt these end up with no game. Nothing to show for their work, because the scope creep was too large and killed the entire project.

If they’re lucky, though, they’ll end up with the story done… and not much else. It’s very, very hard to direct writers and artists and programmers to all finish a large story in just a month without any ghosting, any road bumps, any life issues. It’s not something new devs should attempt.

one of my favorite entries this year was only 10k~ words long

A short, memorable experience will almost always do better than a longer experience. With longer games, you have more chances to drop the ball with pacing, artwork, direction, bugs, and more. Shorter games, however, are easier to polish, easier to get finished, easier to playtest, and there’s less opportunity for players to get bored.

don’t bury the lede

The judges aren’t looking at your marketing materials; if your story has a hook, get to the hook.


This is a note from Vimi that I think holds true even for non-competitive game jams (and games in general). Not everyone will read every part of your store page, or they’ll gloss over a section, or they’ll be so excited to play it from the screenshots that they don’t want to be “spoiled” about the game and download it immediately. There’s plenty of reasons someone might not read the entirety of your store page (a store page being Steam,, Google Play, etc.).

Get to the hook quickly. Starting your game slowly can be good for building the atmosphere, but only if you’re actually cultivating an atmosphere rather than wasting time. A lot of slow openings can be trimmed down because they don’t add to the overall story—I’m a fan of openings that grow suspense or drama, but there is a very fine line between setting up the atmosphere and having a boring opening.

It’s a hard thing to set up and takes a lot of practice and effort! However, not every game needs this. There were several entries I played that started off mundane and then became horror, but the mundane parts at the beginning felt tacked on. The writers knew the horror was the meat of it, so why not start us closer to it? If your slow opening isn’t working out with beta readers and playtesters, consider dropping it altogether.

proofread and beta read

Entries that had not been proofread or were written/translated by someone who does not have an excellent grasp of English could not get a high rating from me. I’m such a stickler for proper grammar and syntax. I have a preference for clear, concise, non-flowery writing (but I can also appreciate a good poetic turn now and then).

Also – please, please end your sentences with periods. All of them. Thank you.


While a typo or two are somewhat expected from a game made in a month (and my own articles!), there were a few entries I played that had no proofreading at all. Get people to help with proofreading and consider getting beta readers- people who will read over the story and give general feedback.

have an art director

Art is the most important factor for whether a visual novel gets sales/plays. […] Character art should enhance and compliment the character’s personality, not clash with it. The background art, sprites, cut-ins and UI design should work together harmoniously, not fight with each other. If you don’t know what that means exactly, you should show your work to someone who has an eye for that kind of thing and can give you constructive criticism.


Art direction is a vital part of visual novels. Good art direction is to make sure the game looks cohesive together, that the UI, the character art, the backgrounds and more have a reason for looking the way they do and they all work together.

Art direction is a tough concept to understand immediately, but your sense develops a little more with each new thing you make. I want devs to think of any given screen in their visual novel—be it the main game or the settings screen—as a complete scene. An illustration. And when you think of a well-done illustration (characters within an environment, intentional color and lighting, bits of artistic flair like calligraphic writing or an intricate border, etc.), it is one complete image where every element complements each other. It’s a unified snapshot at a glance. When we start considering how line, color, lighting, form, shape, perspective, and composition can look cohesive, we’re already on the right track.

Have a goal in mind for what you want every element to help evoke (a mood, a theme, a recognizable visual, etc.), do some research and collect visual inspiration and references in a moodboard, sketch thumbnail mockups, make sure your assets and text are still clear and legible to the player so as not to unintentionally confuse, and go for it.


There were several Spooktober entries that had great art direction. 3 shortlisted games with defined aesthetics and direction are Model Employee, Beary the Hatchet, and Satan is an Astronaut.

Satan is an Astronaut

When these pieces are of varying degrees of quality or don’t match stylistically, it’s off-putting to see and takes away a lot from the experience.

A cohesive art direction should include:

  • Character sprites
  • Character designs
  • Cutscenes
  • Backgrounds
  • GUI
  • Aesthetics

A great character design will falter if it doesn’t work well with the rest of the cast or if it doesn’t fit the setting the story is in. There are some exceptions where you can get away with varied designs such as fantasy settings, but in general you want the art to all work together. Each part is a cog in the project machine—if they’re out of sync then players will notice.

attention to (cinematography) details

Ideally, something on the screen should look different after every click. Move the camera or sprites, change the character’s expression, or anything that keeps the visual momentum going.


Programming and doing sprite direction takes a lot of time—it’s something myself and Vimi focus on a lot in our own games, so we understand the amount of effort it takes to implement cinematography. Vimi comes from a traditional game development background and I come from a more classic visual novel player background, so we can both appreciate good visual direction.

Here’s a few examples of cinematography from Shared Beauty, one of the Best Cinematography nominees.

Personally, I prefer to do my own programming so I can direct the art how I want it to be. I can set the (metaphorical) stage, I can move the characters around, I can make it how I envisioned it when writing. When you’re with a team though, you don’t always have the luxury of having time to be the programmer, art director, and writer, so you have to relay that information. Allow your art director to talk about parts with the writer and programmer. The writers should leave notes for the programmer on how they envisioned certain stuff that’s not clear in the text, especially things like expressions or subtle changes.

remember where your text is

Please make sure your artists design your screens around your text box; a lot of important visual information can get lost when you put your text box over a quarter of your screen, and you need to design compositions that work around that live space.


There were several entries where character art was cut off right at the textbox, or the textbox was almost fully covering artwork, and more. To prevent these things from happening, try making quick mockups and putting them into your engine. See how they look together before committing to anything.

have an audio director

Sound is critical to the experience, and everyone handles their computer volumes differently. So make sure players can adjust these volume levels within your game itself. Preferably as soon as possible or even before it starts. I’d also suggest not setting the default volume levels to 100%. It’s better to have players turn up your game if they need to instead of killing their ears as a first impression.


Bad audio mixing is worse than having no audio at all sometimes. This can include things like:

  • scuffed audio with background noise
  • voice actors’ audio being wildly different
  • audio that is cut off
  • sound effects that don’t fit the scene

Having a variety of sound volumes (music, sound, ambience, and sliders for each voice actor) can help with these issues but you still need proper audio mixing and testing that it all sounds good in-game.

We mostly see audio problems when it comes to voice acting, such as the audio not being mixed or character’s audios being quieter than others.

Voice acting is a very difficult addition for game jams because you have to finish the script, proofread it, cast the actors, give and direct their lines to read, get all of their recordings, do audio mixing on the recordings, program them in, get and pick-up lines, and playtest to make sure it all works. It’s not as easy as getting a VA, getting lines from them and plugging it into Ren’Py.

playtest (and playtest again)

Be sure to thoroughly playtest, especially for any crashes or soft-locks in the final builds before the deadline. If players find issues like these then it will significantly impact their experience or prevent them from finishing it at all. This can also include doing your best to ensure your game can still run on a variety of potential setups.


When you are testing, you need to work to break your game. Don’t just play through with the idea that the end user will be doing perfectly expected behaviors, like waiting for a voice line to finish before advancing, never choosing to hide the textbox/UI during gameplay, or never opening an extendable quick menu before a cinematic cutscene.

Physically spam the advance button (not auto-skip). Hide your UI to check that all your elements are still presentable and properly layered. Keep your quick menu open or hotkey it open during cutscene segments to see if it intrudes. Hell, load your build on a USB flash drive and play your game on library computers to see how it runs on different specs, if you don’t have multiple systems of your own.

Work to break your game. And then fix or prevent everything that could go wrong. And if there’s something you can’t fix, be considerate to players and list Known Bugs on your game page.


There were quite a few games with bugs or, worse, game-breaking crashes we ran into. These could’ve been avoided with more playtesting. At the beginning of the jam we always push for devs to finish their games before the end of the month and save time for proper playtesting, both by themselves and with proper playtesters.

Play through the entire thing on skip. Try clicking around wildly. Have choices? Try unconventional patterns. Have puzzles? Try breaking the puzzles. Have point-and-click segments? Try to soft-lock yourself.

You never know how players will accidentally break your game or where bugs are lurking. Spend more time breaking things.

play more visual novels

A lot of these examples we’ve brought up can be avoided by playing more visual novels and experiencing what the medium has to offer. Things like how to get to the point quicker rather than slow starts, how to do impressive cinematography rather than static sprites, how to make more accessible games, and more.

There are visual novels of all sorts nowadays, from queer fantasies to yuri dating sims to slice of life historical stories. You can definitely find some that will interest you and learn from them.

Take (mental or physical) notes of what you enjoy, what surprised you, what you think could’ve been done better. Get inspiration from those around you and bring that to the table.


Spooktober is always a stressful-fun time of year and this year was definitely no exception, with it being our biggest year to date. We had 156 entries last year but this year we had over 200! Reading over 100 visual novels in October was no small feat and I’m proud of the rest of the judges for being able to handle it with grace. There were so many great entries this year and I hope it’ll inspire devs to continue making more fun and cool visual novels.

I hope this article gives you some ideas for how to improve your future visual novels. If it was, consider resharing my posts for it on Tumblr, Twitter, or Bluesky.

The other judges helped me with quotes for this article but several of them will be making their own Spooktober re-caps which I’ll be linking here as they’re posted.

RedOwl’s write-up

Another Halloween has arrived! Halloween is my favorite holiday, but wow did October go by like a blur. There was Spooktober judging which probably took…. 30+ hours? 40+ hours? A lot of time.

The first day of judging was definitely my busiest—we held our second ever Élan Festival on October 1st. I’d been preparing for it for weeks beforehand, but it was still a lot of work left to do on the day of, namely because we had so many announcements and social medias now to share them to. If you make announcements for 5 games, then you have to make a social media post for each of those announcements on Twitter, Tumblr, and Instagram plus an announcement devlog on the individual Steam and pages plus a wrap-up post afterwards on Patreon, your newsletter, and Discord. If you’re releasing a demo (like we did for Twofold), then the store pages need to be made/edited with the new builds and info. Before the event though you have to do the lead-up marketing for it on these different platforms to let people know it’s even happening. There’s a lot of moving parts—thank you to everyone at Élan that helped with the event!

Later on, just a few days ago, at Élan we published Twofold, a queer visual novel that’s been in development since 2012. I’ve only been following the development of the game for the past few years, but it’s been really great to see it take shape. I’m so happy for the team that this wonderful story is finally out for people to experience.

I spent most of my month working on visual novel stuff that wasn’t my own… which is why I want to try to do a lite NaNoWriMo next month (tomorrow). I’ve got several scripts half started that need more work—aside from a demo, I don’t like doing art or programming for my VNs until the script itself is finished as I do a lot of small edits.

Until next time, stay safe.

— Arimia

Leave a Reply