I wish we can use +, - ,* ,/ ,//,%,(),^ for numeric variables and being able to use other variables to assign their values to other variables using these arithmetic operations Eg. Debt = Wealth - Income This will help in making better games with more complex world mechanics.
I was about to write the same thing. There are so many things I've wanted to do but couldn't (realistically), due to not being able to directly set variables based on other variables. This is the feature I most want to see right now, by far.
I would like to have the ability to do calculations with more than one variable as well, though I think that won't be enough. To be able to implement complex game mechanics, things like conditionals, logical operators, min/max, and rounding (some calculations might result in floating point numbers) might be necessary as well.
Hmm I wonder how far Friedman (I assume it's Friedman?) is aiming to take this new game mode. Depending on how much he's planning to add, it might be most efficient (albeit still a ton of work) to lean in on the user-generated aspect of the site, implement some fundamentals (loops, functions, setting variables based on other variables, etc.) and then some kinda system to allow users to create and share functions. With that: We could build up from even just bitwise operations to typical arithmetic operations, common rpg systems, various specialty functions like pseudorandom number generators, calculations with more than one variable at once, etc., saving Friedman from having to do any of the work for that stuff himself. Users who have no experience with coding/etc. could easily use many of the useful but complicated systems that other users create. Friedman could just make a few of the very generally useful functions public and referenced in the documentation, for people who don't want to go browsing to add user-made functions that allow them to easily do fundamentals like foo = bar1 × bar2 via something like foo = multiply(bar1, bar2). But honestly I'm just happy game mode got any updates, I wasn't expecting it and it's already much better than it was.
Thank you all for the suggestions! I have now introduced the first version of Game State formulas. When editing a chapter, authors can select Set by formula under Changes to game state for Number, Percent, and Age variables. Formulas can reference other Game State variables, including the value being changed. For example: Code: game:debt = game:wealth - game:income The formula field itself would contain: Code: game:wealth - game:income The first version supports: - +, -, *, /, //, %, ^, and parentheses - comparisons and AND, OR, and NOT - conditional calculations with IF - MIN, MAX, ABS, ROUND, FLOOR, CEIL, and CLAMP - random calculations with DICE and RANDOM - references to Number, Percent, Age, and Yes/No Game State variables Calculations use exact decimal arithmetic internally, avoiding the usual floating-point surprises. The final stored value must currently be a whole number, so ROUND, FLOOR, or CEIL can be used when necessary. Multiple Game State changes in one chapter run from top to bottom, and a formula can see the results of earlier changes. The complete guide, including examples, functions, limits, and troubleshooting, is available here: https://chyoa.com/chapter/Game-State-Formulas.1878510 What would you like to see next? It would be great if you could share an example of how you would use it in a story.
This is amazing and enables so many things! Would it be possible to do the same for action buttons? Something like: {action "Gain income" set game:wealth+=game:income}
I would've wrote essentially the same (including the praise). The action buttons are so nice! No need to wait for a page load to change the variables. Loops, arrays and objects would also be amazing, but it's very understandable if any or all of that is asking for too much. Definable functions that can be used in formulas would also be nice, to avoid needing to copy+paste huge sub-formulas to do complex operations that we'll want to do in a lot of different circumstances.
Not necessarily, I meant to include both story level and broader level in how I was defining "definable functions" (as in either one would be good).
I’ve now introduced this for Action buttons: Code: {action "Gain income" set game:wealth += game:income} Actions can perform multiple Game State changes at once, and each formula sees the changes made earlier in the same action. The reader’s Game State, inventory, and available chapter choices update immediately without reloading the page. Formula-based changes also work with Reveals, Code Lock outcomes, and Ordering Puzzle outcomes. If a formula is invalid or cannot be evaluated, none of that interaction’s changes are applied and it can be tried again. Regarding loops, arrays, objects, and definable functions: could you share some concrete examples of how you would use them in a story?
The mad lad has done it again, absolutely fabulous! Yes: Brief example: A 2d roguelike with tile data stored in an object made up of arrays for each y slice. Generating the dungeon could involve looping over each tile in the object and performing some tile generating function on it. Ranged attacks could involve looping over each tile in the direction you're facing and attacking the enemy closest to you (if there is one). Could also loop over each enemy and perform their corresponding function(s) during their turn. Longer example with elaboration: A shop with 8 slots for random items, where all the slots have the same functionality. If we lack both loops and functions, we have to copy+paste the entire code to have each slot generate. If the code is complex (eg. maybe different items become available or more probable based on various different conditions, there can be discounts, different currencies used for certain items, etc.), it could easily balloon into copying a ton of code for each slot. This not only takes up a lot of our limited code real-estate (possibly to the point that we would have to make the player press multiple buttons to progress a loading bar every time they enter the shop), but it also leads to other difficulties. For a complex chapter (like this shop example), this could easily result in adding many hundreds or thousands of lines of code. Assuming that authors always think to put that code at the bottom so they don't have to scroll past it every time they edit any standard text, it's still going to be a bother to deal with whenever they want to update that copied code. Maybe they think of a new condition that they want to affect the item generation, or a new item that they want to add to the random pool. Now they have to scroll past a bunch of copied code for other functionality like this to find the slot generation code, make their edits, and then copy it 8 times once they're finished. And for more complex cases, this can of course become even worse (having to go through a lot of this per test / bugfix, having a much harder time bugfixing because of how disorganized it'd be, etc.) With just functions, if nothing else we could use a function to assign some temporary variables to the generated result, and then assign one slot's variables to those temporary variables, potentially massively reducing the amount of code we have to copy. Eg. generateSlot(), game:slot1Cost = game:tempSlotCost, game:slot1Item = game:tempSlotItem, generateSlot(), game:slot2Cost = game:tempSlotCost, and so on. With just loops + arrays/objects, we could have an array/object for the slots (/their properties) and loop over the random generation code, only changing which element(s) of the array/object we are writing to based on the loop iteration. Having all functions, loops and arrays/objects wouldn't help much in this example, but there are many cases (where we want to use code in multiple different ways that don't just involve simple looping) where having both is very useful. Or cases where we need one in particular, like the 2d roguelike example I gave earlier: even if we have a function for generating each tile, copy+pasting the function for a 10x10 grid would already mean having 100 function calls in the chapter text. The code bloat issues are especially relevant for stories where authors want to keep most functionality in a single chapter. Eg. A stereotypical text adventure game where you want to be able to access your inventory everywhere, but also want to be able to use an item from your inventory on a given thing in the environment (also being able to select the thing in the environment). With a few more interconnected systems like this, I think the best approach could easily be to have everything in one chapter. Otherwise, it seems like you'd have to copy a ton of code into a lot of chapters in order to have different chapters for different locations while maintaining this functionality, or a chapter for accessing your inventory while still being able to easily select things in the environment you're supposed to be in, etc. Also can't believe I didn't think of this before, but timing systems would also be amazing! The simplest implementation that comes to mind is just to have a way to set a variable to something like Unix time (although this would obviously require something like increasing the limits of variables, at least for variables storing Unix time). But it would also be really useful to have some way to automatically perform actions every second or something, for realtime games. But as always this might all be outside of the planned scope of this update, I'm just describing all my wildest dreams at this point. It's completely understandable if adding even more features for the minority of nerds who would use them is not deemed worth it, or if there are too many performance concerns with a lot of these ideas.
I guess arrays would be good for implementing a card game. To start, you could use an array with the cards ordered, and you know how many items are in the array. Then, you use a random number 1 to [maxitems] to draw a card and put it into the reader's hand (might be an array as well). Subtract 1 from [maxitems] and draw another card. This might already be possible right now, but it's probably a bit cumbersome. Time and date should already be pretty simple to implement, as you can use a number and count up the minutes or hours. To show the time in useful numbers, you can use a formula with modulo operators. E.g., if you have the lowest unit as minutes, you can do game:minutes = game:time % 60 game:hours24 = ( (game:time - game:minutes) / 60 ) % 24 game:days = ( ( (game:time - game:minutes) / 60 ) - game:hours24 ) / 24 Besides the issue of the currently limited size of variables, a contemporary date/time might not be that useful, both in terms of unit conversion and range. (Think of fantasy stories in a separate universe or a science fiction story with an approach to time that doesn't rely on a changing time an object moves around another object. (Though ages must be adjusted accordingly.)) I would rather go in the direction of (fixed) floating-point variables, manipulation of dropdown variables (shift up/down, choose element n), string variables (with string manipulation), and arrays. For the given example, story-wide functions might be useful, like game:hours24 = function:hours() with a story-wide definition of function:hours() = ( (game:time - game:minutes) / 60 ) % 24 In this case, there is no need for parameters, and the values of the hardcoded variables at the time of the function call would be used. If parameters should be used for that, it could be implemented like this: function:hours( parameter:time ; parameter:minutes ) = ( (parameter:time - parameter:minutes) / 60 ) % 24 (If functions can be used within functions, nesting might become an issue.) It might be useful to set a variable that points to a certain chapter. Then, linking a chapter could offer the option "go to remembered chapter". That way, you could set a pointer to the current chapter, and offer a link to a detailed inventory or a detailed character sheet. From the character sheet, you could then use the link to go back to the remembered chapter. To make that work, linking chapters would need a checkbox option "ignore game state changes of destination". (This might be useful anyway.) I'm not sure about using real time stamps within a story.
Good idea, if the variable limit is increased (at least for time) and Unix or something similar is used under the hood (so that time essentially passes even without the user), then that could also work well. Although I guess it would also be useful to know how much time has passed *with* the user, maybe even moreso. The main reasons I suggested Unix were ease of implementation (since there should be a JavaScript function for it or something iirc, and no performance concerns with keeping track of tons of independent timers), and the ability to keep track of when the user eg. leaves for a while, for some immersive reactions. It wasn't for the contemporary aspect of it, that can easily be negated by just setting a variable to the Unix time when the story is first started, and then subtracting that from later Unix times, to get the time since the story was started. And this could be done again or modified further for eg. time travel or displaying a different year/made up time scale for fantasy/sci fi, since Unix is just the amount of seconds since a certain date and doesn't otherwise contain any dependence on our favored time format or length of Earth years, etc. What are fixed floating-point variables? I've only heard of fixed-point numbers and floating-point numbers, I haven't heard of a hybrid format before. Searching doesn't seem to pull up anything, and I'm struggling to imagine what it could mean. Sorry if I'm missing something obvious! It's an interesting idea to add array-manipulation functions for drop-down variables, I like it. Can't believe I forgot about string manipulation, I really want that as well!
Yes, it's just a number. Thus, I don't see how it would be useful to use existing time/date functions. I guess it might be possible to have a variable type for time and date that allows you to set up how it works. E.g., setting a date or date 0, the starting date, day of the week, and so on. Though I'm not sure whether or not it might be easier to implement that within the story itself. I meant floating-point variables, but with a fixed number of decimal places. (I see the contradiction ^^) I guess fixed-point is the right term.
