This is 100% false.
It's fairly easy to pass variables back and forth between Twine and JavaScript if you're using a Twine story format which allows that, like the SugarCube story format. You can use
You must be registered to see the links
.variableName to access SugarCube story variables from JavaScript, or
You must be registered to see the links
.variableName to access temporary variables from JavaScript. (Those links take you straight to the documentation explaining what they do.)
You could use JavaScript variables and access them from Twine code, but if the data in them isn't static (unchanging) then you'll likely break the "back" and "forward" buttons and the "save" feature. (Generally it's recommended that you use the SugarCube
You must be registered to see the links
for things like this.)
Again, completely wrong. You can do anything with SugarCube code that you can with regular HTML/CSS/JavaScript, because SugarCube just makes doing some of those things simpler and adds in a history tracking and saving system (among many other built-in features you can use).
I don't think that John said it particularly clearly, but I think he were trying to point out that your code requires that the player be online (i.e. "runs JS through the browser"), since it tries to use jQuery from online sources. (Though, I'm rather baffled why you're trying to simultaneously use two different versions of jQuery, the current jQuery v3.5.1 and the terribly out of date jQuery v1.11.0, from two different sources in the same project.)
You should include the jQuery file with the project and just use that file (i.e. "being built in html", by which I assume he means included within the HTML file). That way it will work fine when offline and will start faster as well.
What?
First, I'm not sure why you keep referring to a "code editor" there. The editor has nothing to do with how the game functions.
Second, yeah, you can, as I explained above. Though, normally you should just use the SugarCube
story variables and
temporary variables instead, and you can access those just fine from JavaScript if you need to.
For example, here's some simple SugarCube code you could put into a passage which does what you said isn't possible:
Code:
<<set $storyVar = true>>
<<if $storyVar>>
Var was true.
<</if>>
You could put the
<<set>> line elsewhere in the code, it doesn't have to be right next to it like that, I just used that as an example.
Since
$storyVar is accessible from JavaScript as
State.variables.storyVar (and vice versa), then you've just created a boolean variable in the code which then causes some text to show or not show based on the value of that variable.
"OOP" (in this context) stands for "
You must be registered to see the links
", so your grammar doesn't quite make sense there.
Regardless, SugarCube is basically syntactical sugar on top of JavaScript, so Twine/SugarCube is just as much of an OOP structure as JavaScript is.
What?!? I mean, yeah, of course doing more complex things takes more work. That's just the nature of reality.
However, the "increases exponentially" part is obscenely false.
Twine, and specifically the Twine story format SugarCube, just simplifies doing things you could already do in HTML/CSS/JavaScript. It does
not take anything away from that. Hence, any complaint you try to level at Twine/SugarCube would either equally exist in HTML/CSS/JavaScript or it's an inaccurate complaint.
In other words, it's a mistake to think that Twine in any way limits what you can do. It's simply there to make some things
easier to do.
Maybe. However, if, for example, the feature already exists in Twine/SugarCube, then no, it most definitely would
not be easier to add that feature yourself in your own engine (vs not having to do anything at all, since it already exists in Twine/SugarCube). Especially considering all of the effort and testing that has already gone into making sure that the Twine/SugarCube versions of those features are compatible with a variety of different browsers and are fairly error-free.
There's something to be said for not re-inventing the wheel if you don't have to.
If you want an example of a card game made in Twine, check out "
TF Card Battle", which is made using Twine/SugarCube. I helped write some of the code it uses.
That said, it's your choice on how you want to develop your game. However, if you
do want to take advantage of a tried-and-tested "wheel" that already exists, I just want you to be aware that Twine is not as limited as you seem to think it is.
Good luck with your game!
