itch.io

Hey there!  I'm really excited to hear that you found about VN development through our jam.  It's one of our goals to turn people on to VN development through it, so it's great to know it's working for someone!

The other thing I wanted to mention is that Spooktober is just one of many annual events our community runs directly, and we support a number of others indirectly as well, so if you're excited for more and don't want to wait a full year, there's always more ahead.  Winter Jam starts in December.

If you use Discord, you can swing by and check out the hub of the community to connect with the rest of it over at https://discord.gg/devtalk, but if you don't use Discord you can check out the wiki the community also runs. It has a page about all of the VN jams there are that we track.

But in either case, I look forward to seeing what you put out, and hope to see you again soon at one of our jams!

I hadn't realized it was in demand.   It's one of those things that I've known how to do and I spent the time putting it together on a whim.

Hopefully it helps speed folks along in their dev.

Very cool!  Unfortunately this pack doesn't have much that's useful as examples for screens.  The ones that I included are more or less placeholder copies of the default one.

The magic in this pack happens in the Python logic that runs around the screens.  It probably won't help you make nice screens in and of itself, but once you're able to, it should be a force multiplier for your VNs.

Hey there, Your project is marked as private and isn't viewable by the judges.  Make sure you mark it as public before the jam working period is over.

I'm planning on starting up my own blog at some point.  If you have anything in particular you'd be interested in those, let me know and I can make it a point to write something on it.

Known Bugs:

When rolling back in some (most) situations , the camera projecting the Live2D models will rubberband, causing them to briefly shift on the screen a bit before settling down in their correct position.

This is fine.  Many of our submissions every year do not even approach horror.   Sometimes they're costume themed romances, or light hearted tales of kids on a candy adventure.

The interpretation is correct.  

This is mainly to thwart people who, in the past, have made things prior to the jam and explicitly for the jam, released them publicly within the jam's period, and claimed that since they are publicly available they were allowed to use them.  This behavior is generally unwanted since:

• The obscurity due to the timing of releasing the asset more or less promises the team near exclusive use.
• The assets released are often created with a singular aesthetic or focus in mind, giving the original creator a significant leg up in creating cohesive visuals ahead of the competition whereas the average participant uses third party assets to supplement.

The rule has some clear complications, especially with long time creators, tool creators and pack creators, so we do accept exception requests.  If you need to make such a request, feel free to send me a message on Discord via DevTalk or e-mail me at Nai@SpooktoberVNJam.com with details.  We will likely deny anything that was released less than six months ago.  

Next year we are intending to explicitly include assets made by the creator as long as they have a visible and cataloged publish date of some period of time before the jam, though the wording isn't settled yet.

This is where I'll talk about the road map for this game's development!  There's nothing here now because I said so!

I'm loving your drafts, especially that frankly sinister and haunting beauty at the bottom.  You can feel the disenfranchisement from the one wearing the star and the gentleman looks like he's about to either crack the biggest case in history and/or absolutely ruin someone's day with what he has to say.

I look forward to seeing what you bring to this year's competition.  As the host, I appreciate this write up on your reasons for joining, and I'm glad the competition has become something worthy of holding a tradition for.

I don't know if I'd call them wise words but if you're aiming to win, its more important that your submission feels complete rather than long.  You can check my profile for a collection of past year winners to get a feel for length, content and scope.

Generally we're fairly permissive.  Mini games and hybrid style VNs are generally fine.  I can't say I have any direct experience with Red String Club but we're not likely to disqualify a submission as long as an effort was made to be story and reading centric.

Things that are explicitly banned from the competition are listed on the page.  Otherwise you need descriptive content warnings on your submissions.

If you want a more concrete answer, you need to tell us what you're planning on making.

Sorry, for clarification, it needs to be minimally playable on Windows.  Many people submit builds that work in multiple platforms.

Halloween

Needs to be playable on Windows.

Are you participating in more than one jam this season?  Many jams allow you to submit to other jams with the same submission, though few jams have strict requirements like Spooktober Visual Novel Jam does.  Here's a quick checklist you can go through to make sure your jam submission is qualified to be added to the Spooktober Visual Novel Jam!

Cross-Jam Submission Checklist for Spooktober VN Jam

• The jam submission was not worked on prior to September 1st, 2024.
• The jam submission was added to the Spooktober Visual Novel Jam submission list before October 1st.
• The jam submission is a visual novel, visual novel hybrid, or narrative heavy game.
  
• The jam submission has had erotic content disabled/removed for submission to the Spooktober Visual Novel Jam.  We recommend an 'All-Ages' edition to protect our streamer friends who would want to cover your content.
• The jam submission page credits every single person on the team regardless of their depth of involvement.
• The jam submission does not contain AI created works, has never contained AI created works, and has not had work supplemented by generative AI (e.g, paint overs of AI output, code or script created by AI, story supplemented our outlines by AI.)
• The jam submission does not contain endorsements, glorifications, or instructions of suicide.
• The jam submission contains any kind of theme that could be connected to Halloween.  (e.g, Horror genre, focus on candy, presence of monsters, use of costumes or disguises, etc ) OR the story takes place on October 31st of any year.
• The jam submission only contains things assets that are publicly available for free or for sale that were made by a third party (e.g, not you, and not on your behalf), or assets that you and your team created between September 1st and October 1st
• The submission is of an Intellectual Property you own or have been authorized to create.  (e.g, No fan games without getting its owners permissions, but you can make spin offs of your own content.)

For additional information about rules and prize eligibility, check the jam page itself!

Once the submission period opens there will be a button on the page where you can click to submit your entries.  

Shoot, I should've said 'First' in here.

So then, just asking out of curiosity, is there a "time/length limit" the gameplay should be under?

There's no limit to the length of the game.

I'm asking because if I were the judge evaluating these games, I wouldn't have the patience to sit trough lengthy submissions

Well, I enjoy reading visual novels, as do most of the judges so it isn't too bad. 

It's worth noting that our process for judging comes in two phases.  The first being a 'vetting' phase where we quickly go through the submission, which we're expecting to be around 220~260 this year, to determine whether or not it will likely be within the top 10 or be a contender for a special category, then we will moved forward for our second phase, where all of the judges read it in full.

The competition is fierce ever year and it's only gotten more so over the years, so entries that have significant bugs, errors, or obvious place holders will often get put aside.

Winners typically have the following features/strategies:

• A short but complete experience.  Most winners are in the ball park of 30 minutes to an hour to conusme.  By our usual word to time conversion, that's something around 7000-12,000 words.
• Tightly scoped games.  On average, winners have something around 3-5 character sprites at most, a modest sound track and limited game play.
• Cohesive aesthetic.  Everything fits together, because it was made to fit together. 

I have a collection of past winners you can check out here if you want to get a feel for them here:

https://itch.io/c/4692741/spooktober-visual-novel-jam-winners

is there a theme reveal like in other jams?

The theme is always Halloween, and it doesn't change.  It's a loose theme.

If no, how do we prove we didn't start working on our spooky VN before the start of a game jam?

In short: You don't. It's the judges job to evaluate the submissions to determine if a rule was broken.

If that sounds like a lot of work, it is!  Not all of the rules get the same level of application due to the scale of the competition vs the quantity of judges we have to work with. Content rules, like the ones about erotic content, are applied universally because of the simplicity of doing so, where more complex to apply rules are applied only when the violation has either been made apparent OR they are likely to rank in the top 10 and get an aggressive and active investigation.

I'd caution you away from a remake.  A straight remake likely wouldn't fly.  You could make a spin off, sequel or prequel, or alternate universe.  I can't say we have had to rule on a remake before but I suspect it would get disqualified.

We've accepted Visual Novels with some game like mechanics, which we typically refer to as hybrids.   The main thing is that the experience still largely needs to lean on reading.

You can check out a winner from a previous year, Stardander Revenant, as an example.

Hey there!  What is your question in regards to? 

If you're in need of assistance regarding the competition, recruitment, or anything related to the Spooktober Visual Novel Jam, please let us know.

Thanks!

Awesome, glad that was the right direction!  Looking forward to seeing what you make!

I don't have the code right in front of me, but if I had to guess the error is likely coming from an instance where we're multiplying or dividing a full integer (eg.: 8) instead of a float/double (e.g 8.0) or vec2 (e.g, (8.0 , 8.0))  I can't recall any specific instance where I did that, but that's where I would start looking.

Normally I'd jump in to assist directly, but I'm presently drowning in event prep work for the Spooktober VN Jam and likely won't have time to do a full dive with you for at least a few weeks.  Let me know  what you find in a reply here and I'll do my best to offer suggestions during my down time.

Hey there!  Quick reminder that our schedule includes 3 live recruitment events in Discord.  These organized events are called Meet & Greets!  You can join our community  and tune into the Meet & Greet voice channel and the game-jams text channel to participate!  This is one of the best ways to meet a lot of participants all at once and find a team to participate on OR build your own team!  Voice participation not required, but encouraged!

The schedule for the Meet & Greets, along with the rest of the events we have planned before the competition, are listed on the jam's main page!

Hope to see you there!

Hi there! I wrote a rough script that I'm interested in adapting for the jam, but only if it's okay with the rules.

It's more of a first draft script than an outline. There is a lot of dialogue but it's rough, and significant portions would be changed. There's also a large missing section that I would need to write during the actual jam, which may result in other big changes elsewhere. But I'm not clear on whether every line of dialogue would need to be rewritten to be okay for the jam.

Is this in violation of the spirit of the jam?  Judging by the rules, it sounds like it may be off-limits. However, if I'm mistaken, please let me know.

Thank you!

Hey there!  Thanks for the question.  

You wouldn't be able to use an existing script as is, no.  Anything created before the jam's starting period, with some exceptions as mentioned on the page, cannot be used inside your submission.  

What you could do right now is cut down your current draft into an outline to use to inform your story design and lay out, and then re-write anything that would be presented inside of the submission itself. (existing dialogue, narration, description intended for viewers, etc,) 

Sure, I can help!

Try tossing this at the start of your scenes:

    camera:
        perspective True

This will cause the camera (in reality, the master layer) to use perspective mode, which should straighten that out for you.

Here's the documentation if you want to read more up on it:

https://www.renpy.org/doc/html/3dstage.html#using-the-3d-stage

Sorry for the delay in answering, we've been busy working and ramping up for the competition coming.

Nothing here I can see would violate our rules.  Just be sure to use content labels to help your audience and judges navigate your content.  We recommend checking out the ESRB's descriptions.

 https://www.esrb.org/ratings-guide/#cont_desc

The rule is about suicide and self harm, and unless your concept or OCs revolves around that, it's mostly irrelevant to the line of questioning.

The only major content restriction beyond that is that we don't permit NSFW, specifically erotic works.  Otherwise just make sure you're using appropriate content warnings to inform your audience and judges.  We recommend taking a peek at the ESRB definitions to help guide you in labelling.

https://www.esrb.org/ratings-guide/#cont_desc

Hey there!  Sorry about the delay.  You'll want to check the RenPy documentation for how transforms work.

https://www.renpy.org/doc/html/transforms.html

RenPy has a few built in ones, like 'at right' or 'at left', etc.  The pack here gives you more of those prebaked options with the ability to tweak their y and x positions in the configuration.

In one of their examples:

show eileen happy at right

In short, you can add 'at scene_back_left_far' to the end of a line where you show a sprite and it'll move them there.  

It would then look like this:

show eileen happy at scene_back_left_far

Hope that helps!  

There's a few ways to combine them, though I can't say I've looked too deeply about how they all look together.

The first way would be to apply one of the shaders to a layer and another shader to the displayables themselves.    In doing that you can sort of stack two shaders together.   RenPy docs on Layers here: https://www.renpy.org/doc/html/displaying_images.html#layer

The other way would be to directly edit the shader code to produce both effects, which I wouldn't recommend unless you're comfortable with writing shaders.

Nice.  I'll see about working that into an update on the pack.  I appreciate it!

Weeeird.  I wish I had a picture of your sprite without influence from the shader so I could get a better idea of how things are changing.  

You clearly know this because since you knew setting the output(gl_FragColor) to what you sampled would effectively disable any shader effects, but for everyone else: texture2d() is a function that returns a pixel(the color) at a given coordinate (uv) from a supplied texture, or tex0 as it's called in RenPy.   

vec4 color = texture2d(tex0,uv) in this case would be the pixel color information from the source texture/image.

Shaders would then typically operate on, or using, this information to eventually assign it to the output, gl_FragColor.  So in testing: 

vec4 color = texture2D(tex0, uv);
gl_FragColor = color;

and still came up with artifacts is odd.   I had spoken to Fen (go check them out btw they're awesome) and I recall something about v_tex_coord needing to be set to a_tex_coord in the Vertex shader-- I might be misremembering the details but if you're still getting those weird artifacts on your outputs when setting the input to the output (almost) directly, then we can really only assume that either the source texture or the coordinates are the problem.

I don't have it right in front of me at the moment, but if you're still toying with it and are familiar with it, it might be worth adding 

v_tex_coord = a_tex_coord;

into the vertex shader and trying again.  I'm about 80% sure I'm using v_tex_coord as UV, which feels like the most likely culprit.  

If you're able to try and confirm it, I can add a correction into the pack pretty quick to prevent anyone else from running into the problem.  Otherwise I'll see if I can reproduce and fix it when I have time.  I'm currently drowning in VN dev, several new packs, Spooktober Jam scouting and prep, and a half dozen IRL things so I don't know when exactly I'll get to it.

It is literally the first rule in the list.

Game Engines:

• Ren'Py: Free, open source, and specifically designed for visual novels.  Uses Python and an in-house scripting language.
• Visual Novel Machinery(via Unreal Engine): A visual novel engine with emphasis on visual programming using Unreal engine.  Uses Unreal BluePrints, and Unreal uses C++.
• NaniNovel (via Unity): A fully featured scripting oriented visual novel plugin for Unity.  NaniNovel uses an intuitive, extendable and well documented scripting language.  Unity uses C#
• RPG Maker: Great for visual novels looking to add more hybrid-style features related to RPG mechanics.  Uses a combination of scripting and visual editing.  Programming languages used depends on version of RPG Maker.
• Godot: Open-source game engine with a visual scripting language and strong community support.  Godot inherently supports C/C++ and C#, but can be extended to use other languages via GDNative.

Useful Programming Related Resources:

• (RenPy) Visual Novel Design with Vimi: Covers general visual novel design with specific videos for RenPy. https://www.youtube.com/@vimi
• (NaniNovel) Elringus's Youtube Channel, the official Youtube channel for the NaniNovel Documentation:  https://www.youtube.com/@Elringus
• (NaniNovel) Ida's Github provides a visual scene editor extension for NaniNovel and a scripting extension to add high powered post processing effects. https://github.com/idaocracy
• (RenPy) Fenik's website contains useful tutorials for getting started and getting the most out of RenPy. https://feniksdev.com/

Yep!  So nearly any property that is supplied by the transform can be animated using the animation command. Good job on figuring out a way forward on it!

Ironically, it's harder to animate AnimatedAberration than it is to animate the still version of it from the outside.  AnimatedAberration takes u_time into consideration, which is a uniform property that is representative of ongoing time.  If you were able to set u_time to a constant value, it would.. actually stop animating!  The changing of u_time as supplied by RenPy and the shader's uptime is actually driving that one's particular animation.

You could still animate Animated Aberration from the outside, but you'd only be able to animate the other exposed properties, and it probably would be hard to fine tune the appearance because the animation is baked into the shader itself for that one.  

It was smart to go to the still version of it, because now you have significantly more control over how it behaves from the outside using the animation commands in RenPy.  What you're doing is changing the values supplied by the transform directly, rather than having the shader calculate the latest step there.

I'd love to see how you did it, and I'm sure some other folks would too if you'd like to share.

You have a couple options for customizing them.  

The easiest and recommended way is to use the accompanying configuration file to bulk change all of the speed.  Most everything has some type of configuration setting in MVNStagePackConfig.rpy, including the distance, offsets for different directions(Useful for adjusting sprites up and down when they're too tall/too short for the defaults), the duration and time of effects.  The parameters are well documented, or at the very least are named in ways that should inform their purpose.

As of this writing, Line 7 has the pedestal_duration for the Pedestal (down to up pan), Line 13 has the establish_duration for the Establishing (left to right pan), and all of the zooms if you leave their zoom time unchanged will use line 18: default_zoom_time. If you change these variables in the config, it will change the timing on all of their associated premade shots.  

Another way that will give you more presets while keeping the originals, you can copy and paste the transforms out of the MVNStagePackCamera.rpy and make new ones in your own files to make your own shots.  For example, starting at line 51:

transform zoom_front_right:
    perspective True
    parallel:
        ease default_zoom_time zpos -300 + zoom_front_zoffset
    parallel:
        ease default_zoom_time xpos 0.15 + zoom_front_xoffset
    parallel:
        ease default_zoom_time ypos 0.05 + zoom_front_yoffset

Lets say you like the original enough to want to keep it, you could customize this one like so to change some stuff around regarding the timing.

In your own RPY file, you could write something like this:

transform fast_zoom_front_right:
    perspective True
    parallel:
        ease 0.3 zpos -300 + zoom_front_zoffset
    parallel:
        ease 0.3 xpos 0.15 + zoom_front_xoffset
    parallel:
        ease 0.3 ypos 0.05 + zoom_front_yoffset

This would keep all of the positional settings and just change the new timing to be 0.3 seconds vs the default 1.3 seconds.

Lets say you want to make fast versions of ALL of them, and you really don't want to go ham on having to edit each one of these 90 times.

In YOUR RPY file, try this:

define fast_zoom_time = 0.3

If you're using VSCode, you can copy all of the definitions and their transform instructions into YOUR RPY, then highlight the transform definitions ("transform zoom"), press Ctrl D to multi select lines, use your arrow keys to put the cusor in front of zoom, and just add "fast_" , then repeat this step for all of the default_ lines to replace them with "fast_".

.

Actually this was such an easy mass modification to do that, in the process of making sure I was giving you good instructions, I just..  Made it myself.  Whoops.  Anyway here's a 'Fast' version'   Which you're welcome to copy paste and redefine in your own RPY.  But I recommend you take a peek at the instructions I gave above since it'll let you make an infinite number of your own variations of your own camera shots using my preset package.

define fast_zoom_time = 0.3
transform fast_zoom_origin:
    perspective True
    parallel:
        ease fast_zoom_time zpos 0
    parallel:
        ease fast_zoom_time xpos 0
    parallel:
        ease fast_zoom_time ypos 0
transform fast_zoom_front_right:
    perspective True
    parallel:
        ease fast_zoom_time zpos -300 + zoom_front_zoffset
    parallel:
        ease fast_zoom_time xpos 0.15 + zoom_front_xoffset
    parallel:
        ease fast_zoom_time ypos 0.05 + zoom_front_yoffset
transform fast_zoom_front_left:
    perspective True
    parallel:
        ease fast_zoom_time zpos -300 + zoom_front_zoffset
    parallel:
        ease fast_zoom_time xpos -0.15 - zoom_front_xoffset
    parallel:
        ease fast_zoom_time ypos 0.05 + zoom_front_yoffset
transform fast_zoom_front_center:
    perspective True
    parallel:
        ease fast_zoom_time zpos -300 + zoom_front_zoffset
    parallel:
        ease fast_zoom_time xpos 0.0
    parallel:
        ease fast_zoom_time ypos 0.05 + zoom_front_yoffset
transform fast_zoom_back_right:
    perspective True
    parallel:
        ease fast_zoom_time zpos -500 + zoom_back_zoffset
    parallel:
        ease fast_zoom_time xpos 0.25 + zoom_back_xoffset
    parallel:
        ease fast_zoom_time ypos -0.10 + zoom_back_yoffset
transform fast_zoom_back_left:
    perspective True
    parallel:
        ease fast_zoom_time zpos -500 + zoom_back_zoffset
    parallel:
        ease fast_zoom_time xpos -0.25 - zoom_back_xoffset
    parallel:
        ease fast_zoom_time ypos -0.10 + zoom_back_yoffset
transform fast_zoom_back_center:
    perspective True
    parallel:
        ease fast_zoom_time zpos -500 + zoom_back_zoffset
    parallel:
        ease fast_zoom_time xpos 0.0
    parallel:
        ease fast_zoom_time ypos -0.10 + zoom_back_yoffset
transform fast_zoom_right:
    perspective True
    parallel:
        ease fast_zoom_time zpos -450 + zoom_mid_zoffset
    parallel:
        ease fast_zoom_time xpos 0.25 + zoom_mid_xoffset
    parallel:
        ease fast_zoom_time ypos -0.10 + zoom_mid_yoffset
transform fast_zoom_left:
    perspective True
    parallel:
        ease fast_zoom_time zpos -450 + zoom_mid_zoffset
    parallel:
        ease fast_zoom_time xpos -0.25 - zoom_mid_xoffset
    parallel:
        ease fast_zoom_time ypos -0.10 + zoom_mid_yoffset
    
transform fast_zoom_center:
    perspective True
    parallel:
        ease fast_zoom_time zpos -450 + zoom_mid_zoffset
    parallel:
        ease fast_zoom_time xpos 0.0
    parallel:
        ease fast_zoom_time ypos -0.10 + zoom_mid_yoffset

An easy and helpful modification would be to make a slow version of this.   As a challenge for you or anyone else reading this, see if you can follow my above instructions to make a slow_ version of this. :D