View source for Guide:Your first visual novel jam

{{guide|author=[[User:Ironnori|Ironnori]]}}
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 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|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 [[Spooktober Visual Novel Jam|Halloween or spooky]], [[Winter Visual Novel Jam|winter]], or a given [[genre]]). Others have certain restrictions, such as [[O2A2 Visual Novel Jam|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<ref name="shino vnconf">[[Shino]], 2022. ''Releasing 8+ games (ft. game jams) and when to take a break''. Visual;Conference. https://www.youtube.com/watch?v=sMonrId8J28</ref>:

{| class="wikitable"
|-
! 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|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.
* [[O2A2 Visual Novel Jam|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 Visual Novel Jam|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 [[List of ongoing visual novel jams|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!

[[#top|{{clickable button|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<ref name="vimi yt">[[Vimi]], 2022. ''Game Jam Survival Guide: Essential Tips and Tricks''. Visual Novel Design. https://www.youtube.com/watch?v=KU7VYaKKWDc</ref><ref name="ari jams">[[Arimia]], 2024. ''Advice for Leading Visual Novel Game Jam Teams''. arimiadev. https://arimiadev.com/advice-for-leading-visual-novel-game-jam-teams/</ref>.

===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|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<ref name="guidebook">Tamafry, 2021. ''Director's Guidebook''. Notion. https://tamafry.notion.site/Director-s-Guidebook-6e9327f638a242218f09130302e3569e</ref>. Of course, if working solo, you'll need to fill every needed role yourself. (Remember, though, that you can [[#Using premade assets|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<ref name="ari jams"/>.

Shino recommends including the following in a pitch<ref name="shino vnconf"/>:
* 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 [[Guide:Target Audience|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)
* [[#Setting role expectations|Detailed role expectations]]
* Specifications, like game [[resolution]], [[Visual novel engine|engine]], and preferred file formats for images & audio
* Frequency of [[#Check in regularly|check-ins]] and preferred [[#Feedback and coordination|feedback styles]]
* [[#Use source control|Source control platform]] of choice

===Make a detailed plan===
Detailed plans can make a huge difference when it comes to the [[#Monitor your morale|morale]], and ultimately, success, of a jam team<ref name="vimi yt"/>. Creating an [[#List every task|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.

[[#top|{{clickable button|Back to top}}]]

==Scope and scheduling==
[[Scope]] refers to the total list of [[asset]]s and [[visual novel features|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<ref name="ari jams"/>.

Scheduling during a game jam can also be a difficult endeavor. Some tasks (especially the programming, proofreading, and voice acting if applicable<ref name="vimi yt"/>) 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<ref name="vimi yt"/>. 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 [[visual novel engine|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<ref name="ari backup">[[Arimia]], 2022. ''Making Game Development Backup Plans''. arimiadev. https://arimiadev.com/making-game-dev-backup-plans/</ref>.

[[Mikey]] recommends planning your scope for a one-month jam based on your reasonable output for '''two weeks''' to allow plenty of time for delays, problems, testing, and refining<ref>[[Mikey]], 2022. ''The ultimate VN jam advice''. Medium. https://atpprojects.medium.com/the-ultimate-vn-jam-advice-24b3c78c9190</ref>.

===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.

[[#top|{{clickable button|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 in regularly|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 [[visual novel engine|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 team]]s 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 [[#List every task|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 [[#Sort out technical and operational details|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<ref name="ari jams"/>.

It's normal, and perfectly okay, to [[#When things go wrong|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 [[#Sort out technical and operational details|technical specs]] of the game.

[[#top|{{clickable button|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 [[#When things go wrong|about to go wrong]] or if someone is at risk of [[#Ghosting (please don't)|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, [[#Feedback|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 [[#When to call it off|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.

[[#top|{{clickable button|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 [https://arimiadev.com/cutting-visual-novel-scope-examples/ 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!

[[#top|{{clickable button|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 [[List_of_VN_creation_resources#VN_postmortems|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, [https://arimiadev.com/youre-marketing-your-visual-novel-and-you-dont-even-know-it/ 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 [[#How to cut scope|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!

[[#top|{{clickable button|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 [[List_of_VN_creation_resources#VN_postmortems|visual novel jam postmortems]] and visual novel [[List_of_VN_creation_resources|development resources]]
* [[List of ongoing visual novel jams]]

==References==
<references/>

{{jam nav}}