Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Does Twine 2.0 have an upper character limit?
I know variations of this question have been asked but I feel like it's never really gotten a proper response. What's the final limit for a Twine 2 project, wherever this limit might come into play — be it the editor, the number of disparate passages, the final HTML output for distribution, etc. If there's not a specific one, at what point do extremely large stories/projects start exhibiting unstable behaviour?
Trying to gauge how much room I have for something I'm working on.
Trying to gauge how much room I have for something I'm working on.
Comments
If you are using the installable release of Twine 2 then the answer becomes more complex.
a. The default maximum local-storage size of node-webkit application is 1 Terabyte, so that should not be a problem.
b. The Story Projects are stored as files on your local hard-drive, so that also should not be a problem.
So the issue comes down to either the process that builds the temporary HTML document in memory or the process that creates the Story HTML file on your local hard-drive. An I would guess that the answer to how large either of those process can be before they fail is "No-body Knows" but it should be very large and not a problem. **
** Unless you are planning to embed media content within your Story Project, in which case the size of your Story Project file and the generated Story HTML file can become very large very fast.
If you plan on hosting the Story HTML file on a web-server then there can be issues if the Story HTML file becomes too large, as many web-sites have limits of the maximum size a HTML file can be, and which is why web-pages normally use external media files.
This is not a problem if you plan on storing the Story HTML file on a file hosting site.
You will need to check with both web2executable and chromium to see what their defaults are when it comes to available memory and local-storage space.
Here is a tutorial on how to use it natively with Twine which is very handy:
https://videlais.com/2014/08/26/twinetuesday-packaging-twine-with-node-webkit/
Once you get it all set up in the Twine folder it's literally just writing a single command line to build the exe.
That said, web2executable probably doesn't hurt in itself, and makes packaging for different platforms simpler, so by all means go ahead with it.
About RAM:
I have made Twine games with nw.js over a gig in size. I don't know the upper limit, but they ran fine... booted up in seconds and no lag in accessing the assets, even 50MB .ogg music files that play instantly.
RAM is no concern as NW.js does not function like an online Twine game that may try to preload assets. Instead of trying to preload assets at the start, it just reads them from hard disk as and when they are needed. Hence regardless of asset size, the only initial loading time is the time it takes to read the initial HTML.
In actual fact, Twine games run with NW.js load orders of magnitude faster than the same games run directly with a web browser. The web browser tries to preload stuff whereas nw.js does not. So I don't even test games with the browser anymore. I just type "nw ." in the command line in my Twine directory to run them in the NW.js app (after using the "rebuild story" command in Twine to rebuild the HTML).
(This quick testing is a real benefit of using nw.js without web2executable, since once you have it all set up you can test your app without having to compile it.)
Also if there is ever an issue with NW.js you can do some trickery with the web players in Unreal, Unity or WebGL to get Twine working there. These engines have their own garbage collectors that will keep RAM clear. There's a ton of options for Twine games so I don't think project size is a limiting concern in itself.
This means that your nw.js based application's built-in custom web-browser will not be able to load and unload the media as needed thus will not be able to release/reclaim the memory that embedded media is using the same way it would if that media was not originally embedded.
Was gonna say there probably isn't any benefit to using Base64 in the HTML, and only disadvantages. I'd just use optimised JPG files in an images folder for icons. There won't be any lag in accessing small icons of several kb. There isn't even any lag in my game in accessing multiple full screen images of several hundred kb.
NW.js runs very fast -- way faster than any web browser, so while it's still a good idea to optimise images, the usual constraints on browsers don't apply as much. Base64 is sorta a way to force preloading of assets before the rest of the page displays, but that's not important in a nw.js app.