Publishing¶

Now that your CYOA has been build, we need to discuss how to publish it to the world at large.

Tip

Before you publish, you should collapse all of your Rows except for those that are needed (if it's a long CYOA). This will ensure quicker loading times, as well as allowing the player to expand them as they wish.

Merging Viewer files and project.json¶

It's a good idea before uploading your CYOA anywhere to merge the Viewer files and project.json, rather than having to upload them separately. It just makes it easier to work with.

Organizing your site¶

It's a good idea to organize your website. Only using the top-level index is fine if you only want to host one CYOA, but what if you want to host more? It is then recommended to create folders, and move the project files in them.

If you're only going to use your Neocities site for CYOAs, I recommend using the following structure (using Neocities as an example):

Text Only

yoursite.neocities.org/
├─────────────────────superhero-cyoa/
│                     ├── css/
│                     ├── js/
│                     ├── index.html
│                     └── project.json
├─────────────────────steampunk/
│                     ├── css/
│                     ├── js/
│                     ├── index.html
│                     └── project.json
├─────────────────────harem-interactive/
│                     ├── css/
│                     ├── js/
│                     ├── index.html
│                     └── project.json

If you decide to use it for more than just CYOAs (like say, for example, setting up a blog or posting your own creations), you could put all CYOAs under a cyoas/ folder:

Text Only

yoursite.neocities.org/
├─────────────────────blog/
├─────────────────────cyoas/
├──────────────────────────superhero-cyoa/
│                          ├── css/
│                          ├── js/
│                          ├── index.html
│                          └── project.json
├──────────────────────────steampunk/
│                          ├── css/
│                          ├── js/
│                          ├── index.html
│                          └── project.json
├──────────────────────────harem-interactive/
│                          ├── css/
│                          ├── js/
│                          ├── index.html
│                          └── project.json
├─────────────────────secret-stuff/

Tip

Instead of accessing index.html directly (such as https://mysite.neocities.org/superhero-cyoa/index.html), you can instead forgo calling index.html, since web servers will almost always send you to this page automatically, without changing your URL.

So it is recommended that you share your link as https://mysite.neocities.org/superhero-cyoa/, as it is much cleaner and nicer to look at.

Where should I publish?¶

There are many possible sites to host and formats to publish your Interactive in, and we'll go over how to do so in this section.

There are quite a few sites that will publish your Interactive. In this tutorial we'll only be discussing options that cost no money whatsoever.

Many people use either Neocities or GitHub. For general use, I recommend using GitHub, as it allows you to make an unlimited amount of sites from the same account, with each site having a larger free size limit. This comes with a caveat, however, in that it can be confusing to beginners.

If you wanted to make or have made an NSFW Interactive however, I recommend using Neocities. GitHub's Sexually Obscene Content policy means that pornography (for the sake of pornography; educational and instructional use is fine) cannot be hosted there. Neocities, on the other hand, has no such policy.

In the end, it's up to you to choose whichever site works best for your use case.

Table of Comparison¶

Website	Site Limit	Size Limit	Bandwidth Limit (per month)	Bandwidth Speed	File limits
Cloudflare Pages	Unlimited	Depends on GitHub or GitLab	- Unlimited		Pages only supports files up to 26.2 MB in size
GitHub Pages	Unlimited¹	- 5 GB per repository - 1 GB per site - 25 MB per file (web upload) - 500 MB per file (git cli upload)	- 100 GB (soft limit)²	Fast transfer speeds	Any file type, but does not run server-side code such as PHP files, whereas paid Neocities supports PHP
Neocities	1 per account	- 1 GB per account - 50 GB per account	- 200 GB (free) - 3000 GB (paid)	Slower transfer speeds for free users	HTML files, CSS files, Javascript files, Markdown files, XML files, text files, fonts and images
GitLab Pages	Unlimited¹	- 5 GB per repository	- 100 GB

Why can I not view it locally?¶

See here.

Versioning¶

Note

This is entirely optional, and mostly relevant to users who decide to host their interactive in a Git repository, such as on sites like GitHub and GitLab.

However, you may find this useful if you're interested in learning how to standardize your versions.

It may be useful for users to have a consistent versioning scheme. I recommend reading about semantic versioning.

The basic summary is as follows:

Quote

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

Whenever a major or minor version is incremented, the following versions must be reset to 0: 1.2.3 → 1.3.0 → 1.3.1 → 2.0.0, and so on.

Initial development¶

Quote

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Projects start at version 0.1.0 when being initially developed, and stay in major version 0 until ready for public release.

Anything goes in the initial development phase, but you could:

Increment the minor number when making breaking changes: 0.1.3 → 0.2.0 → 0.3.0, and so on.
Increment the patch number when adding either backward-compatible functionality or bug fixes: 0.3.0 → 0.3.1 → 0.3.2, and so on.

Post-release¶

When you are finally ready to release your Interactive CYOA to the public, the version becomes 1.0.0.

After adding only bug fixes and minor changes, increment the patch version: 1.0.0 → 1.0.1 → 1.0.2, and so on.

After adding new, backward-compatible changes, increment the minor version: 1.0.2 → 1.1.0 → 1.2.0, and so on.

After adding breaking, incompatible changes, increment the major version: 1.2.0 → 2.0.0 → 3.0.0, and so on.

Note

Changes that would count as incompatible would be, for example:

Changing Row and Choice IDs, meaning any person looking to import their previous Backpack IDs would only be able to do so in 0.x.x if they made it in Major version 0, or 1.x.x if they made it in Major version 1.
Deleting rows or choices, such that users can't import their previous choices and expect the same result.
Changing requirements for existing choices.

Because of this predictable versioning, users can judge whether they would be able to use previous builds, or if they should either make a new one, or import their old one and try to pick up the pieces.

Note

The version doesn't increment with each change you make, but it increments each time you release your next version.

Changelog¶

On the note of versioning, it's a good idea to keep a "changelog": a list of what's new and changed since the previous versions. You can have this changelog be built into your Interactive or post it in the subreddit comments section, for example.

It's important for your users to know what has changed since the last time they played, so that they have a good idea of what to look forward to, and what may make their previous build incompatible.

You can see the changelog of the ICC in the Help and Instructions menu, and you can see the changelog of this tutorial in the About page.

Table of Contents¶

The follow pages include a step-by-step guide on how to publish your CYOA.

You can create an unlimited amount of public or private repositories, which can each act as their own site. ↩↩
You can go over this limit, but GitHub may decide to take down your site. ↩

Comments

If you have any questions, concerns, corrections, or anything else, please comment below.