Guide:Your first visual novel jam

Drawing on advice from many veterans of the English visual novel space, this guide will help you choose, prepare for, participate in, and succeed in, your first visual novel jam. This guide is written for complete beginners to visual novel development, but intermediate developers looking to tackle their first timed jam will also find value here.

The basics

Before you start your jam adventure, there are a number of things you should think through.

What is a jam?

Main article: Visual novel jam

A visual novel jam is a set period of time where developers attempt to create and release visual novels, usually from scratch. Most jams have a theme of some sort (like Halloween or spooky, winter, or a given genre). Others have certain restrictions, such as using only one of any type of asset.

Why should I participate?

Jams are an excellent way to gain experience in making visual novels, and many visual novel veterans recommend that new developers create their first project as part of a jam. Well-known yuri developer Shino generated a list of pros and cons of participating in visual novel jams:

Pros	Cons
External deadline Low money concerns Low risk experimentation Event-based publicity Meet great teammates Get experience Understand your per-month output Short-term project	Short-term project Theme constraints Distraction Lack of polish time

In general, most new developers would benefit from starting with a jam project.

You might not want to participate in a jam if:

• Factors are limiting your ability to work on a game with a deadline, such as many personal/work obligations or a disability
• Your project idea doesn't fit into the jam theme
• You already have an ongoing visual novel project that you don't want to disrupt
• You want to get paid for your development work. Most jam projects are released for free, and most teams do not pay their members. Some teams will offer skill trading, though.

However, even these factors can be mitigated by choosing the right jam, as we'll discuss below.

Which jam is right for me?

Main article: List of ongoing visual novel jams

There are tons of jams to choose from (the number went from 39 to 42 while I wrote this), so choosing which to join can be pretty intimidating!

Truly, there's no one right choice for new developers. The correct jam for you is the one you're interested in and excited about joining! At the same time, a few jams are consistently recommended as good places for newcomers to start.

• NaNoRenO (March, 1 month): The original and longest-running visual novel jam, NaNoRenO is a popular and relaxed jam where participants make a visual novel in a month - with few other restrictions and no set theme. It's a great choice because of its popularity, relatively chill atmosphere, and strong community/opportunities for support.
• One of Any Asset Jam (O2A2) (July, 10 days): With one of any asset type and one thousand words as your maximums, O2A2 is a great opportunity to create something very small. Having a finished product can be highly motivating, and it's much less of a commitment than a full one-month jam. Teams are often smaller, which can make recruitment easier.
• Winter Jam (December, 1 month): A chill (pun intended) jam that occurs in December and has a theme of "winter". The broad theme and relaxed rules make it a great starting point.

If none of these jams strike your fancy, if it's a different time of year, or if you're looking for inspiration, explore the full list of jams. There are between 4 and 8 going on during any given month, and again - the right jam for you is the one that works with your schedule and that you're excited about doing!

Although jams are set events where participants can find comradery and support, also keep in mind that ultimately, a jam is a set of creative restrictions. If you want to create an O2A2-scoped jam, but it's December, you can absolutely have your own "jam" just for you if it'll help you grow, create, or have fun!

Back to top

Before the jam starts

Almost all jams allow a variety of prep work to be completed before the jam officially starts (though you should check the specific jam's rules to be sure). Having a strong plan and foundation can make a huge difference, and developers who plan well tend to have more successful and enjoyable jam experiences than those who don't.

Solo, join a team, or start a team?

The first decision you need to make, after choosing a jam to participate in, is whether you will participate solo, join an existing team, or start your own team. There are pros and cons to each option.

Solo developers for jam teams have complete creative control over their end product. They don't have to deal with recruiting team members, ghosting, or communication issues. At the same time, working alone can be quite difficult, especially for newcomers. It can be difficult to stay focused and motivated without other people, and games made by solo developers must necessarily be smaller in scope to accommodate the reduced amount of person-hours available to work on them.

Joining an existing team can be a great option for newcomers. Especially if one or more of the team members has previous visual novel (or game) development experience, it can be an opportunity to learn from their expertise. Working in a team comes with a variety of benefits including external accountability, productive collaboration, and networking. However, joining a team means agreeing to work on a project idea that someone else generated, and typically means you'll have slightly less creative control over the final product than you would as a solo developer or team lead. You'll also deal with the various struggles and complications that come with any team project.

Creating your own team combines many of the benefits of solo development and joining an existing team, in exchange for a significant increase in workload. As the creative lead (and often the project manager) for the project, you'll need to generate the concept, collect references, recruit team members with compatible creative styles and personalities, and manage those team members when things go off the rails. This approach may be better suited for developers with at least one jam under their belt - but first-time jammers can succeed in these roles, too.

What roles can you fill?

Main article: Development team

When considering what team to join, or to work solo, you should consider what roles you're able to fill. This may be the roles that you have prior experience with, or it may be roles that you are interested in practicing or learning. Of course, if working solo, you'll need to fill every needed role yourself. (Remember, though, that you can use premade assets for most jams.)

If you intend to join or form a team, be sure to communicate clearly with other team members about your skill and experience in various roles. Many teams welcome beginners, but others may want people with experience (especially in competitive jams like Spooktober.

Finding a team (recruitment)

Recruitment means matching interested developers and empty roles on jam teams.

If you're intending to recruit other people to work on your jam entry, you'll need to have a strategy. Some participants will recruit their friends or other developers they already know to work with. Others will make public recruitment posts to find other people who are interested in joining a team.

Common recruitment portals

The three most common places to find visual novel jam teams are as follows:

• DevTalk's recruitment channels
• Lemma Soft Forums' "recruitment & services offered" board
• The itch.io community tab for the jam

Developing a pitch

If you are planning to recruit anyone to help with your project (whether you're planning to lead a whole team, or just get help on one area), you'll need a pitch. A pitch is a summary of what you have planned for your jam project, and a good pitch is important for a strong recruitment process.

Shino recommends including the following in a pitch:

• Premise
• Requested roles
• Who are you? What are you doing?
• Scope of game
• Proof of concept

It's important to provide a clear understanding of your idea, genres, and overall themes. Do not be afraid to "spoil" people during recruitment - providing more information will help people take an interest, and the majority of your target audience will never see the post.

Sort out technical and operational details

Before a jam begins, you should set expectations on a number of items. This is especially the case when working in a team, but it's also helpful for solo developers to have a solid understanding of these factors going in, too.

• Preferred attribution/credit name(s)
• Money or payment (most jam projects are unpaid; some do skill trade)
• Detailed role expectations
• Specifications, like game resolution, engine, and preferred file formats for images & audio
• Frequency of check-ins and preferred feedback styles
• Source control platform of choice

Make a detailed plan

Detailed plans can make a huge difference when it comes to the morale, and ultimately, success, of a jam team. Creating an asset list and schedule is especially impactful.

Additionally, almost all visual novel jams allow pre-work such as outlines, gathering visual or audio references, and even sketching, as long as those assets are not used in the final product. (For example, cleaning up a sketch into linework may not be allowed, but using that sketch to generate ideas almost always is.) Be sure to check each jam's rules to understand what is permitted.

Back to top

Scope and scheduling

Scope refers to the total list of assets and features included in a visual novel. Scope is one of the most common challenges for new visual novel developers, especially during game jams. Scope creep (gradual expansion of scope to the extent that it becomes unmanageable) is unfortunately common. Similarly, due to delays, ghosting, or other issues, game jam entries frequently have their scope cut (reduced) to meet submission deadlines. One survey of visual novel jam participants found that more than half of jam games had their scope change during development.

Scheduling during a game jam can also be a difficult endeavor. Some tasks (especially the programmer's) cannot be started until other tasks are completed. Additionally, sometimes team members will be more or less available at different points during the jam window, which must be worked around.

Your reasonable output

Many experienced jam participants recommend setting your scope by working backwards from the "reasonable output" that team members expect during the period of the jam. Reasonable output should not be the maximum productivity you've ever achieved; rather, it should be a fair amount of work that you're quite confident you can complete, even if there are complications or challenges.

The reasonable output of a given team member will vary based on a variety of factors, including their experience, skill, real-life commitments, other projects, and mental & physical health. A team's reasonable output may also be higher if they have previously worked together and are familiar with each other's working styles.

List every task

Project management refers to the process of tracking all tasks that need to be completed for a project, and ensuring that they get done as close to the planned timeline and quality as possible. There are variety of styles and approaches for project management, but the details of those are outside the scope of this guide (ha!).

When planning for a jam, I recommend listing every task and asset that needs to be completed, along with planned completion dates, responsible team members, and dependencies. (A dependency is when one task must be completed before another can be started, such as needing to have sprites drawn before they can be implemented in the engine.)

Importantly, solo developers are not exempt from the need for project management. While it may look different than it does for a team, it's still critical to check in regularly (preferably every day) to ensure that you're on track with your planned timeline. If you're not, consider what can be cut or changed to meet the deadline.

Expect things to go wrong

For any game jam project, there will be issues. No one is exempt from this - experienced, brand new, long-term, short-term, solo, or team. When planning your scope and schedule, build in more time than you think you need for delays, problem-solving, and other mishaps.

Mikey recommends planning your scope based on your reasonable output for two weeks to allow plenty of time for delays, problems, testing, and refining.

Using premade assets

Using premade assets, often found on [itch.io] or the Lemma Soft Forums, can be a great way to reign in your scope before it becomes a problem. While you will sacrifice some creative control and cohesion, many premade assets are quite high quality, and can save you a lot of time. Pre-made code libraries can be especially helpful and flexible. Almost all jams allow use of premade assets, but be sure to check the jam rules.

Back to top

Working in a team

Creating a cohesive final product requires a cohesive team. Here's some tips for working together effectively.

Strong communication is a must

The importance of communicating clearly and often with your team cannot be overstated. Having regular check-ins is one part of this, but more than that, the team needs to trust each other, anticipate challenges, and communicate proactively. Proactive communication means thinking about and discussion potential problems before they get out of control.

For example, if the writer creates a scene where the plot hinges on being in a room without windows, the backgrounds must reflect this. Proactive communication would mean that the writer reaches out to discuss this with the background artist as soon as the decision is made. At the same time, the writer should be willing to listen to feedback and challenges from the background artist's perspective, and potentially change the scene if the art cannot be adjusted in time.

Communication about details is especially important between programmers and other asset creators (writers, artists, musicians). Slight changes to how something is formatted can be make or break for its compatibility with other assets and the engine. Such changes are often trivial when made at the start of the creation process, but can be very time consuming when assets need to be retroactively fixed.

Setting role expectations

Several roles on visual novel development teams are somewhat ill-defined, or their responsibilities vary across teams. (Examples include editing vs. proofreading and scripting vs. programming.) Therefore, an effective jam team will identify who is responsible for every task. This will help prevent team members becoming overworked or having to rush to complete forgotten work at the last minute.

You should also clearly communicate the technical expectations for each team member's output.

Ghosting (please don't)

Ghosting is when a team member stops responding to messages for an extended period of time. (In a one-month jam, not responding for a week or more is typically considered ghosting.) Unfortunately, ghosting is somewhat common among jam teams; one survey of jam participants found that over 60% of respondents had experienced ghosting or team members dropping out last minute.

It's normal, and perfectly okay, to run into problems during a jam. However, the most important thing is to communicate about these problems as soon as you know they exist. Even if you think you'll still be able to complete your tasks on time, it's still a good idea to talk to your team about any difficulties you're having, whether related to jam work or otherwise. When working on a tight timeline like a jam, providing notice and information early can help the team adapt and come up with backup plans, just in case things get worse.

I definitely understand the difficulties that come with not being able to do what you promised you would. Depending on your background, there can be a lot of shame or feelings of inadequacy wrapped up in it. However, the kindest thing you can do for your team and yourself is let them know what's going on, so you can work together to find a better path forward.

Feedback

Different developers have different preferences for how to give and receive feedback. Some creators welcome critique and see the assets they create as group projects; others hold their creations much closer to their chests. It's a good idea to have conversations with your team ahead of the jam period to understand how they give and receive feedback.

In general, the more feedback and communication about assets a team does, the more cohesive and smooth their final product will be. Waiting until an asset is nearly complete before sharing may result in large amounts of work having to be redone, or a variety of miscommunications. Sharing rough drafts, sketches, technical mockups, and the like can also help spot any compatibility issues with the technical specs of the game.

Back to top

During the jam

It's showtime! Hopefully, you've got a solid plan: your team is formed & talking; you've got an outline, visual references, and an asset list ready to go; and you feel comfortable with the workload ahead of you. If you're not quite there on day 1 of the jam, that's okay too! Just make sure to account for time to get organized when you create your schedule and set your planned scope.

Check in regularly

Frequent check-ins are essential to a successful jam experience - whether you're checking in with your entire team, a specific department or individual, or just yourself. A few questions to think about each time you check in:

• What progress have you made since the last check-in? Share any drafts, notes, or WIPs.
• What issues have you run into? Is anything (whether jam-related or life-related) making it difficult to complete your work?
• What are you planning to complete before the next check-in?
• Think a little ways out. What's coming up on your schedule that requires other people to help or complete their work first? Are those tasks on track?
• Are we on schedule? If not, what can we remove, adjust, or delegate to get back on track?

What "regularly" means for you will depend on a lot of factors, including the length of the jam, your team size, the amount of coordination required, and team members' other obligations. In general, for a one-month jam, I'd recommend checking in no less often than every three to four days. Ideally, your team will be communicating every day, even if briefly.

Check-ins can help identify when things might be about to go wrong or if someone is at risk of ghosting.

Progress is better than perfection

One of the main benefits of a jam is that it encourages you to have something complete, rather than something that stays in-progress forever because you're trying to make it perfect. So, don't work against that! When you're creating an asset, try to focus on having a complete, okay-ish version before you even start to do detailed revisions or additions.

Jam games will necessarily be imperfect, because they have an artificial time limit on them. That's okay and expected! The point is to get something out there. Do the same with your assets.

Plus, sharing your drafts early can help prevent many types of problems.

Monitor your morale

Morale can be a difficult beast during game jams. Specifically, morale means the overall energy and feelings of the team about the project: are you motivated? Energized? Apathetic? Burnt out? Teams that suffer major disruptions, like critical team members leaving or large amounts of scrapped work, are likely to have low morale.

The best way to keep your morale high is to plan well. The biggest morale killer is unexpected problems with no good solution - so the more "just in case scenarios" you can plan for, the more stable your morale will be.

If a team's morale is low, focusing on "quick wins" can help improve it. Sometimes, taking an intentional break to have fun and/or disconnect from the project can be very helpful, too. If things get too bad, you might want to consider whether to call things off.

Use source control

Source control refers to methods for tracking the versions of various assets, and ultimately, the game as a whole. Source control has a variety of benefits, including allowing you to easily view scrapped versions of your assets, aiding in team communication, and serving as a backup in case your local files are damaged or lost.

The most popular source control method is Git, which is easier to pick up than it might seem. I'd encourage you to learn how to use it for your jam project. If that's a barrier, though, file sharing services like Google Docs or OneDrive are better than nothing.

If you don't back up your files, you will regret it. Sorry, I don't make the rules - it's just murphy's law.

Back to top

When things go wrong

Notice that this section is titled "when" things go wrong, not "if". Something will go wrong during the jam - that's okay, and it's normal! Being prepared and thinking on your feet will help you recover.

Communicating through problems

When problems arise, the most important thing you can do is communicate with your team. Putting your heads together can help find solutions you might not have otherwise seen. Even if it doesn't, having conversations early and often can help you adjust your timeline and scope, which will make it more likely that you're able to have a complete product.

If the problems that come up are interpersonal among your team members, the answer again is to communicate. Allow both sides to share their frustrations, discuss how they've been inconvenienced (or harmed, if that's the case), and work together to come up with a mutually agreeable compromise. Of course, if someone is being harassed, targeted, or otherwise harmed, take action to protect yourself and your team.

Try to remember that jams are meant to be fun and a learning experience. Don't take things so seriously that you burn yourself out.

Ask for help

In addition to communicating with your teammates, you can ask the visual novel development community for help, too! If you need suggestions for how to solve a plot hole, fix a bug with your GUI, or get the shading on your main character's hair just right, there are many kind folks who are happy to help.

Good places to get help include:

• The DevTalk Discord server
• The itch.io community tab for the jam
• Lemma Soft Forums
• The forum or Discord server for the engine you're using

How to cut scope

When things get off schedule, cutting scope is the safest bet. While scope cuts can be dramatic, like removing a minigame or an entire route, other cuts can be relatively minor. For example, if your artist isn't able to complete as many backgrounds as they planned for, you can tweak a scene so that it occurs in an already-used place, thus eliminating the need for a background.

Arimia has a great list of examples of cutting scope.

When to call it off

There might come a point when you're wondering whether to call it quits on your jam project. In general, try to hang in there! Some of the best learning can happen when you're dealing with tricky situations. However, there are some times when it makes sense to wave the white flag. Here are some things to consider:

• Are you enjoying yourself?
• Are you learning from the experience?
• Is this hurting your mental health, or contributing to an overall feeling of burnout?
• Have your life circumstances changed, or just proved more difficult than you expected? If so, does that mean that right now isn't the right time to finish this game?

Remember, jam games that aren't submitted before the deadline aren't "failures". The only way to fail is refusing to learn. You can always come back to your idea later, or move on to a different one!

Back to top

After the jam

Whether you submitted a final product or not, congratulations! Participating in a game jam is a big achievement, and I'm sure you've learned a lot. To help you make the most of that learning, I recommend taking some intentional time to reflect on your experience - individually, and with your team if you have one. Lots of folks will write postmortems about their jam experiences, but you don't have to do anything quite that formal if you don't want to. Just scribble down some thoughts about the process, what went well and what didn't, and what you learned.

If you were able to complete a game, share it around! You've put in all this effort - let other people know about the fruits of your labor. As it turns out, you've almost certainly started marketing already, whether you know it or not.

If you weren't able to polish up everything you wanted to, or if your original ideas ended up victims of the scope knife, you might consider releasing an improved version of your game after the deadline. This is a fairly common practice, and it can allow you to fix up any issues or omissions you wish you had time to get to during the jam.

No matter how things ended up, give yourself a big pat on the back. Making a game in a month is a massive undertaking, and even attempting it deserves commendation!

Back to top

Further reading

• Vimi, 2022. Game Jam Survival Guide: Essential Tips and Tricks. Visual Novel Design. https://www.youtube.com/watch?v=KU7VYaKKWDc
• Arimia, 2024. Advice for Leading Visual Novel Game Jam Teams. arimiadev. https://arimiadev.com/advice-for-leading-visual-novel-game-jam-teams/
• Arimia, 2024. How to Make a Visual Novel Solo. arimiadev. https://arimiadev.com/how-to-make-a-visual-novel-solo/
• Tamafry, 2021. Director's Guidebook. Notion. https://tamafry.notion.site/Director-s-Guidebook-6e9327f638a242218f09130302e3569e
• Various visual novel jam postmortems and visual novel development resources
• List of ongoing visual novel jams