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!

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

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.

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 and coordination

Deliver assets as they're completed