HTML I want to make a JavaScript based text game and widely confused between the engines

[Purukitto]

[I am an intermediate in JavaScript, a novice in and beginner in Java]

I wanted to try and make a CYOA type of text game but with some complex mechanisms (like dynamic quests, inventory, etc) close to but simpler than Free Cities (FC game) system.

I want the game to be largely text-based but a custom UI for interaction.

I tried Twine 2 (FC was built with Twine 1) and although it is kinda fun to use, simply the setting up of dynamic variables and stuff is more convoluted than I thought.

I have tried Ren'py and really like to use it as such for sandbox VNs, but for just a text-based game I was wondering if that is a bit extra.

So I was thinking of using HTML5 and vanilla JS (which in my personal opinion is much simpler to use for an FC like game compared to Twine [Maybe that's because I am largely comfortable with JS and Twine just didn't click as such]) but I am confused about how the distribution would go (as in how Twine and RenPy and such complete the game into simple ready to go files).

While trying to find an answer to my previous question, I stumbled across this list [github] /collections/javascript-game-engines of JS-based game engines and I'm more confused than when I started.

I was hoping to hear your opinions on the same.

EDIT:
I would I believe prefer to work with HTML5 and JS and learn a way to compile the files for distributions unless there's an engine that aids this process (by that I mean to be able to share the game as an HTML without having to share all of the JS and Img files)

 

[Rell games]

It will probably feel like inventing the wheel again, but if you're going through the way of creating an HTML game from scratch without any game framework, I'd recommend using something like React instead of using plain JS. Vue.js will be a great choice as well, but with React you will be able to compile it to exe (

You must be registered to see the links

) and it also can be compiled into the static HTML that won't require any Node.js to run your application. Also android and iOS could be possible too with

You must be registered to see the links

, but it will require some additional work with the code since it can't work with HTML directly and you'll have to change your HTML tags with Native's tags.
As a downside, this stack might be a bit overwhelming, since it was made not for games but for websites in general, but since you have experience with JS it shouldn't be a big problem for you. As a plus, in the end, you'll be probably qualified enough to work as a frontend dev since this stack is very common in web studios

 

[Purukitto]

It will probably feel like inventing the wheel again, but if you're going through the way of creating an HTML game from scratch without any game framework, I'd recommend using something like React instead of using plain JS. Vue.js will be a great choice as well, but with React you will be able to compile it to exe (

You must be registered to see the links

) and it also can be compiled into the static HTML that won't require any Node.js to run your application. Also android and iOS could be possible too with

You must be registered to see the links

, but it will require some additional work with the code since it can't work with HTML directly and you'll have to change your HTML tags with Native's tags.
As a downside, this stack might be a bit overwhelming, since it was made not for games but for websites in general, but since you have experience with JS it shouldn't be a big problem for you. As a plus, in the end, you'll be probably qualified enough to work as a frontend dev since this stack is very common in web studios

I was at some point considering Vue.js (as I have used it before), but since I don't really need it to be stateful it would be kinda since it was mostly optimised for dynamic web pages/modules I believe. But definitely would look into it more.

I believe it could be nice as I would be able to update certain parts of the page as individual components with Vue but I will have to research if the effort would be worth it since I am a complete beginner with it.

As far as react is concerned, I find it very confusing, as the tags and structures are very different than vanilla HTML+JS and looking at the link you provided and diving a bit deeper, seems that the same method (Electron) can be used to package any HTML+JS+CSS project into a Windows and Linux program. So it seems I found the way to package what I want and as such, I won't have to learn React from scratch

 

[outsider artisan]

I'm not sure what you found convoluted but I strongly recommend re-trying Twine, with the SugarCube engine. This is sort of the de facto standard for HTML text games and it is so for a reason, it is very powerful and well-designed, extremely customizable, and comes with all the basic stuff you need without having to reinvent the wheel.

If your issue is the Twine program itself, try Tweego. There's a great VSC extension for Twee code you can use with it.

I am very skeptical that designing your own engine is necessary or a good use of your time. If you want to though, then obviously do it.

 

[PTSdev]

I'm not sure what you found convoluted but I strongly recommend re-trying Twine, with the SugarCube engine. This is sort of the de facto standard for HTML text games and it is so for a reason, it is very powerful and well-designed, extremely customizable, and comes with all the basic stuff you need without having to reinvent the wheel.

If your issue is the Twine program itself, try Tweego. There's a great VSC extension for Twee code you can use with it.

I am very skeptical that designing your own engine is necessary or a good use of your time. If you want to though, then obviously do it.

This. If you only want to create a CYOA type game, Sugarcube with tweego is more than enough. Creating an own engine only is an option if you want to go all-out and create something large. For a simple text-based game, it's too much.

 

[Purukitto]

I'm not sure what you found convoluted but I strongly recommend re-trying Twine, with the SugarCube engine.

Personally I find the data stores/strutures complicated. The way variables were declared and handled was confusing and back when I was learning Twine out of just curiosity (I think that was about 3 years ago?) there was really 1 'good' tutorial about dynamic variables.

I know it has JS support but I was confused how much I can plug JS in it and how I was supposed to actually do it as well. Different tutorials had different suggestions and everything seemed to be a tad bit convoluted at that time.

If your issue is the Twine program itself, try Tweego. There's a great VSC extension for Twee code you can use with it.

Heard about it and was considering that as VSC is home.

I am very skeptical that designing your own engine is necessary or a good use of your time. If you want to though, then obviously do it.

This. If you only want to create a CYOA type game, Sugarcube with tweego is more than enough. Creating an own engine only is an option if you want to go all-out and create something large. For a simple text-based game, it's too much.

Although I agree the thing is that I have to learn Twine, which at least back when I was trying it seemed very confusing thing to do and I was not able to clear my doubts.

With JS, although it would take more time to achieve similar results, at least I can make the data stores and structure them however I need and I can find answers to most of my questions online already.


Saying that, I could reconsider revisiting Twine tutorials and try to see if I can find something that would clear things out for me.

Honestly as is, I am simply confused about where and how to start with Twine. and I would be grateful if either of you could guide me to a suitable resource. (I have referred to the documentation but I would prefer to see a use case project to get comfortable with the library and the docs)

What I found the hardest was UI formatting, and how I can access/change the already existing UI

 

[HiEv]

Personally I find the data stores/strutures complicated. The way variables were declared and handled was confusing and back when I was learning Twine out of just curiosity (I think that was about 3 years ago?) there was really 1 'good' tutorial about dynamic variables.

Could you clarify what you mean by "dynamic variables"? Because it doesn't sound like you mean it in any specific way. Did you just mean "variables"?

As far as how variables are declared in Twine/SugarCube, you can just do things like:

<<set $storyVarname = "string value">>
<<set _temporaryVarname = ["array value"]>>

In Twine/SugarCube, there are two main types of

You must be registered to see the links

:

• Story variables: These have names which start with "$" and the data in them is preserved from one passage to another. The data in story variables are stored in the game's history, which allows the history navigation buttons to work.
• Temporary variables: These have names which start with "_" and they are removed upon passage navigation. Temporary variables are not stored in the game's history.

Temporary should be used whenever possible, since they aren't stored in the game's history, and that helps cut down the size of the data in the game's history. Too much history "bloat" can slow down saving, loading, and passage transitions and fill up the browser's (rather limited) "localStorage" space.

Furthermore, the variables are basically JavaScript variables, and thus they mainly fall into two other categories:

• "
  You must be registered to see the links
  " variable types: The values of these types of variables are stored in the variable itself. Primitive variable types include strings, numbers, Booleans, undefined, and null.
• You must be registered to see the links
  variable types: Object variables actually just hold a reference to the object, rather than the values themselves. Thus, even if two different object variables hold the same information, unless they also refer to the same object, then they won't be seen as equivalent. Furthermore, Twine/SugarCube "clones" objects during passage navigation, so two variables which referred to the same object in one passage, will refer to two separate copies of that object in the next passage. Object variable types include generic objects and objects of the
  You must be registered to see the links
  ,
  You must be registered to see the links
  ,
  You must be registered to see the links
  , and
  You must be registered to see the links
  types.

Of the objects, most commonly you'll use either generic objects, which are unordered collections of key/value pairs, which can be initialized like this:

<<set $genericObjectVar = {}>>

or arrays, which are indexed lists of values (always starting at index 0), and can be initialized like this:

<<set $arrayVar = []>>

See the above links on those data types for how to work with them.

I know it has JS support but I was confused how much I can plug JS in it and how I was supposed to actually do it as well.

You can plug pretty much any JavaScript into your code that you want, though you may have to tweak it a little to fit into the Twine/SugarCube framework. This is mainly due to the fact that SugarCube first renders passages to a "virtual" context before actually adding them to the document, so code which attempts to immediately access HTML elements in a passage won't work. Instead, you'll have to wait until the passage is rendered, such as by using the SugarCube

You must be registered to see the links

or the new

You must be registered to see the links

(the latter requires SugarCube v2.35.0 or later).

For using single lines of JavaScript within a passage, you can put them inside of a

You must be registered to see the links

or, for multiple lines, you can use the

You must be registered to see the links

. There's also the JavaScript section, which is the first thing run when the game starts up. That said, unless you're using the <<run>> macro, you'll need to access SugarCube variables from JavaScript using things like the

You must be registered to see the links

and

You must be registered to see the links

.

Although I agree the thing is that I have to learn Twine, which at least back when I was trying it seemed very confusing thing to do and I was not able to clear my doubts.

If you have questions, take a look at the documentation or the code any of other Twine/SugarCube games (which you can see simply by importing them into the Twine editor).

If you still have questions after that, feel free ask at

You must be registered to see the links

,

You must be registered to see the links

, or

You must be registered to see the links

. Lots of people at all of those places willing to help.

With JS, although it would take more time to achieve similar results, at least I can make the data stores and structure them however I need and I can find answers to most of my questions online already.

You can do just about anything with Twine/SugarCube that you can with just HTML/CSS/JavaScript on your own, but you'll likely save yourself a lot of time that would be spent reinventing the wheel if you didn't use Twine/SugarCube for your CYOA-type game.

Saying that, I could reconsider revisiting Twine tutorials and try to see if I can find something that would clear things out for me.

Honestly as is, I am simply confused about where and how to start with Twine. and I would be grateful if either of you could guide me to a suitable resource. (I have referred to the documentation but I would prefer to see a use case project to get comfortable with the library and the docs)

The "

You must be registered to see the links

" is a little bit out of date, but for the most part it's a pretty good introductory tutorial to using Twine/SugarCube.

You'll find a ton of other useful stuff over at Chapel's "

You must be registered to see the links

".

I also have a bunch of sample code and tips in my "

You must be registered to see the links

" page (created using Twine), however, DriveToWeb is broken right now, so that link probably won't work (should be working again). Instead of that, you can

You must be registered to see the links

(click the "download" link in the upper-right), extract the files onto your computer, and then run it locally if you want to take a look.

What I found the hardest was UI formatting, and how I can access/change the already existing UI

This is mostly down to learning to use CSS (

You must be registered to see the links

) and the Developer Tools window in your browser (see

You must be registered to see the links

). If you want to change things on the fly,

You must be registered to see the links

can make that a lot easier (it's included with SugarCube). There's also the SugarCube

You must be registered to see the links

, if you really want to redesign the UI from the ground up.

Hope that helps!

 

[Purukitto]

Could you clarify what you mean by "dynamic variables"? Because it doesn't sound like you mean it in any specific way. Did you just mean "variables"?

As far as how variables are declared in Twine/SugarCube, you can just do things like:

<<set $storyVarname = "string value">>
<<set _temporaryVarname = ["array value"]>>

In Twine/SugarCube, there are two main types of

You must be registered to see the links

:

• Story variables: These have names which start with "$" and the data in them is preserved from one passage to another. The data in story variables are stored in the game's history, which allows the history navigation buttons to work.
• Temporary variables: These have names which start with "_" and they are removed upon passage navigation. Temporary variables are not stored in the game's history.

Temporary should be used whenever possible, since they aren't stored in the game's history, and that helps cut down the size of the data in the game's history. Too much history "bloat" can slow down saving, loading, and passage transitions and fill up the browser's (rather limited) "localStorage" space.

Furthermore, the variables are basically JavaScript variables, and thus they mainly fall into two other categories:

• "
  You must be registered to see the links
  " variable types: The values of these types of variables are stored in the variable itself. Primitive variable types include strings, numbers, Booleans, undefined, and null.
• You must be registered to see the links
  variable types: Object variables actually just hold a reference to the object, rather than the values themselves. Thus, even if two different object variables hold the same information, unless they also refer to the same object, then they won't be seen as equivalent. Furthermore, Twine/SugarCube "clones" objects during passage navigation, so two variables which referred to the same object in one passage, will refer to two separate copies of that object in the next passage. Object variable types include generic objects and objects of the
  You must be registered to see the links
  ,
  You must be registered to see the links
  ,
  You must be registered to see the links
  , and
  You must be registered to see the links
  types.

Of the objects, most commonly you'll use either generic objects, which are unordered collections of key/value pairs, which can be initialized like this:

<<set $genericObjectVar = {}>>

or arrays, which are indexed lists of values (always starting at index 0), and can be initialized like this:

<<set $arrayVar = []>>

See the above links on those data types for how to work with them.


You can plug pretty much any JavaScript into your code that you want, though you may have to tweak it a little to fit into the Twine/SugarCube framework. This is mainly due to the fact that SugarCube first renders passages to a "virtual" context before actually adding them to the document, so code which attempts to immediately access HTML elements in a passage won't work. Instead, you'll have to wait until the passage is rendered, such as by using the SugarCube

You must be registered to see the links

or the new

You must be registered to see the links

(the latter requires SugarCube v2.35.0 or later).

For using single lines of JavaScript within a passage, you can put them inside of a

You must be registered to see the links

or, for multiple lines, you can use the

You must be registered to see the links

. There's also the JavaScript section, which is the first thing run when the game starts up. That said, unless you're using the <<run>> macro, you'll need to access SugarCube variables from JavaScript using things like the

You must be registered to see the links

and

You must be registered to see the links

.


If you have questions, take a look at the documentation or the code any of other Twine/SugarCube games (which you can see simply by importing them into the Twine editor).

If you still have questions after that, feel free ask at

You must be registered to see the links

,

You must be registered to see the links

, or

You must be registered to see the links

. Lots of people at all of those places willing to help.


You can do just about anything with Twine/SugarCube that you can with just HTML/CSS/JavaScript on your own, but you'll likely save yourself a lot of time that would be spent reinventing the wheel if you didn't use Twine/SugarCube for your CYOA-type game.


The "

You must be registered to see the links

" is a little bit out of date, but for the most part it's a pretty good introductory tutorial to using Twine/SugarCube.

You'll find a ton of other useful stuff over at Chapel's "

You must be registered to see the links

".

I also have a bunch of sample code and tips in my "

You must be registered to see the links

" page (created using Twine), however, DriveToWeb is broken right now, so that link probably won't work. Instead, you can

You must be registered to see the links

(click the "download" link in the upper-right), extract the files onto your computer, and then run it locally if you want to take a look.


This is mostly down to learning to use CSS (

You must be registered to see the links

) and the Developer Tools window in your browser (see

You must be registered to see the links

). If you want to change things on the fly,

You must be registered to see the links

can make that a lot easier (it's included with SugarCube). There's also the SugarCube

You must be registered to see the links

, if you really want to redesign the UI from the ground up.

Hope that helps!

First of all, thank you for taking the time and giving such a detailed answer. Between the time I posted the last answer and now I researched a bit decided to get started with Twine and go from there.

I realised during browsing through the documentation, that the first time (years ago) I was learning Twine I was using Harlowe as it was the default and I believed the default would be the most supported one, thus me finding a lot complex things consulted as (I think) the earlier versions of Harlowe were not that customisable and were made to do everything without JS and CSS for people who didn't know them. As a result, things were confusing to me.

Going through SugarCube a lot of things make sense to me, I feel slightly more comfortable with the same and will go forward with that.

Thanks a lot for the links as they will help me be a little more targeted.

I had a quick look at your Sample code collection and UInv from your signature from another thread on this forum (I believe it was about patching variables for updates) and I'm sure it would be a great help.

I wanted to ask you about UInv though, it seemed like a great cookbook solution to me although it seems you haven't updated it since the last 2 years, if I may ask why is that as I believe, it was almost at completion.
And would you update it/or create something similar for the new versions?

 

[HiEv]

I realised during browsing through the documentation, that the first time (years ago) I was learning Twine I was using Harlowe as it was the default and I believed the default would be the most supported one, thus me finding a lot complex things consulted as (I think) the earlier versions of Harlowe were not that customisable and were made to do everything without JS and CSS for people who didn't know them. As a result, things were confusing to me.

Ugh. Yeah. Harlowe.

Unfortunately, Harlowe, despite

You must be registered to see the links

, is the default Twine story format. As far as I can tell, this is purely due to inertia at this point. It has some, what I can only describe as, insane choices for how to do things with variables, and

You must be registered to see the links

, from the few times I've tried to use it, is deplorable. Who would ever think that creating a two dimensional array should be done like this: (set: $array to (a:(a:1,2),(a:3,4)))? Or, even worse, you should access the "1" value in that array by using the code: $array's 1st's 1st?

It's appalling and I totally understand why that would have confused you.

I had a quick look at your Sample code collection and UInv from your signature from another thread on this forum (I believe it was about patching variables for updates) and I'm sure it would be a great help.

I wanted to ask you about UInv though, it seemed like a great cookbook solution to me although it seems you haven't updated it since the last 2 years, if I may ask why is that as I believe, it was almost at completion.
And would you update it/or create something similar for the new versions?

Yes, it was nearing completion. However, life threw some hoops at me, and I simply haven't had both the time and built up the steam to get back to completing it. I do want to, and do I dabble at additions and (as yet unreleased) fixes periodically, but energy and opportunity have yet to meet in order to push past the final few hurdles (i.e. completing the remaining interactive elements, documentation, sample code, and automated testing code, plus a few more "builders" for helping generate code). Especially when I know I still have to develop some things, like workarounds for browser security issues involving

You must be registered to see the links

.

I do plan on completing it someday, I just can't say when.

That said, UInv is totally useable as-is, with only three bugs in it that I'm aware of (and I have unreleased fixes for: the BagHasAllItems() and BagHasAnyItem() functions only check the first item in the array of items, and GetAllBagPockets() may incorrectly return duplicate pocket names).

Feel free to ask if you have any questions or issues regarding it.

 

[outsider artisan]

I realised during browsing through the documentation, that the first time (years ago) I was learning Twine I was using Harlowe as it was the default and I believed the default would be the most supported one, thus me finding a lot complex things consulted as (I think) the earlier versions of Harlowe were not that customisable and were made to do everything without JS and CSS for people who didn't know them. As a result, things were confusing to me.

I almost bounced off of Twine for the same reason, but found enough posts recommending SugarCube that i decided to try it out before abandoning Twine entirely, so i get where you're coming from. A lot works against Twine at its initial impression, and I think Harlowe is a big part of that.