0 votes
by (420 points)
Hey all!

Since moving to TweeGo and writing my project in VSCode my writing habits have changed over time, and I'm finding myself in situations where my prefered way of organizing scenes with several components and variations is to split them into several passages, .tw files, and sometimes, widgets.

My concern is that this may be detrimental in time, but I'm honestly not sure.

To be clear, I'm not increasing my use of story variables, just the breadth of passages, widgets, and files for TweeGo to compile.

My question is, how much additional resource overhead do these things add to the project? My assumption would be that additional files just adds to compile time and file size, which I know can be a problem for certain browsers, but I wouldn't think that more passages and widgets would equal much more in terms of resource impact. But, if I'm wrong, I'd rather course correct NOW than later on after adding hundreds more passages.


1 Answer

+1 vote
by (68.6k points)

How long it takes to compile a project should have zero effect on run time performance.  How many passages you have should also have little to no impact on run time performance.

Some examples of bad habits that do have noticeable negative impacts on run time performance:

  • Updating the DOM several times a turn.  The greater the scope and/or amount of the updates, the larger the impact.  Especially updating the name nodes multiple times.  Every time you jostle the DOM's elbow you run the risk of causing a cascade of recalculations and repaints of the screen, which is hell on performance.
  • Using loops for things you could accomplish via via simpler and more performant means—e.g., via arithmetic.  I'm not saying loops are evil.  Just be sensible with their use.
  • Using <<goto>> unwisely.

Beyond those, a tip I can't stress enough is to minimize state usage.  In other words, only use story variables for things that directly related to the playthrough and need to exist for more than one turn—if you need it for a few turns, then <<unset>> the story variable afterward if that's feasible.  For everything else, you should probably be using temporary variables, the setup object, etc.

by (420 points)

If passage counts don't have a real impact, then it sounds like widget counts don't as well?

Regarding DOM updates, I'm trying to wrap my head around what that actually means, because if it's what I think it might mean, there's not much I can do about.

My passages are heavily populated by dialogue boxes that effectively boil down to:

<div class="PersonA">
    Person A: Talk about stuff

<b>And in response...</b>

<div class="PersonB">
   Person B: Well here's what I think

Is that what you mean?

by (44.7k points)

If passage counts don't have a real impact, then it sounds like widget counts don't as well?


Regarding DOM updates, I'm trying to wrap my head around what that actually means

Basically it means changing the way a passage looks, after it's first displayed and before going to the next passage.  So, if you had a button that made an image on the screen change multiple times without going to a new passage, then that would be an example of a DOM update of the kind TheMadExile is referring to.  (Your code example isn't what he was referring to.)

From what I've seen, this isn't something you tend to do, so it's not a problem in your case.

Regardless, as far as Tweego is concerned, you could put your game data in one file or a thousand files, and if both ways contained the same data, the end results would be nearly identical, and there would be no difference in the performance.  The main slowdown will only be in your personal ability to work with that number of files.

by (420 points)
Thank you both!