I talked to Friedman about this feature, but it is not set in stone yet. This feature would allow "programmed" stories. It would exactly allow, what you could do with a typical choose your own adventure book, which is nothing else than a single player role play game. (At least, the cyoa books that I read in my youth were like that.) So, it is my intention to provide a functionality, that could simulate this, including the character sheet you would need besides the book. Why? So I should reinvent the wheel? What kind of restrictions are you talking about? This would be integrated as a score change. What would you expect instead?
I was afraid of this. (Saw it coming from the thread about downvotes...) You're one of those people who treat any criticism or disagreement as a personal attack. As such there's no point in my trying to persuade you to change course before you run us all aground on this semicolons business. Pity. Still, mental masochist that I am I'll give this one last shot. No, I'm not suggesting you reinvent the wheel: Actually the opposite. I'm suggesting (to carry on the metaphore) that you, rather than yolk the site to a sledge because you don't want to reinvent the wheel, you cut down a junker truck (BASIC would be an ideal choice) into a wagon and hitch us all to that instead. Will using the steel saws and welding torches to make it functional take a little longer? Of course. That's not the issue. The issue is that if you don't choose the cut down truck NOW the option to do so is GONE forever, you said so yourself. Because of the nature of this site we either get it right the first time or... There is no 'or', whatever is chosen now, for good or ill, is what we're going to be stuck with. Last item: and I hope to Hell that this makes as much sense to you as it does to me: the problem with colons/semicolons instead of words is one of flexibility: you can't reorder operations to altar results under that system. Remember, whatever you INTEND to do with this people will, (because we are human,) push its capacity to the utmost. You have to simply accept that, because you can't change it. Even with the semicolons I can already see how to make a primitive videogame. It's nightmarishly complex, but it can be done, and because it CAN, it WILL. THAT'S the issue. Once you do this, this is not just a CYOA site, it's a CYOA videogame site
I too read the thread about Down Votes, and I genuinely don't understand why condescension and insults are your reflex whenever someone asks you to elaborate upon a subject or simply presents a dissenting opinion, but allow me to inform you that it is simply not an effective means of crafting a convincing argument and winning supporters of said argument. The fact that you can string together more than five sentences implies that you have some form of brain in your head, but the constant self congratulation and flippant dismissal of others' intellects does not boost the perception of your intellect the way you seem to think it does. So basically you want to scrap the idea of advanced spreadsheet math calculations... for a full-blown, though decidedly old school, programming language? Is this really from the same person who at the beginning of this thread said: Now my understanding of this last argument is that it is going back to your earlier list of options, specifically option 1 — i.e. Abandon All Advanced Coding Is it your fear that everyone will turn into crazed, code-wrangling programmers building video games of beguiling complexity that will drive away the common folk? Do you see the whiff of programming as a dangerous, slippery slope? Is it because it starts with "P" which rhymes with "T" and that stands for "Trouble"? The features that gene.sis is describing would not be a requirement for writing on the site, just an added bonus for authors that want to do some advanced interactions with variables. Even if you allowed full-blown programming (which I genuinely don't know how you'd add to the site outside of straight-up allowing people to upload JAVA code somehow, which I think would be insane because some Black Hat hackers might have a field day with that), I don't see any discussions about removing the easy writing functionality of the basic site. If the spreadsheet formula system is implemented, it is possible that some crazy dedicated programmer type will spend the time to make a very elaborate video game. However, I highly doubt that will ever be the norm. I think people like the simple interface. I've attempted to get into the various Interactive Fiction programming codes over the years, and most of them have proved to be too much programming for my tastes, but CHYOA is the right balance in my opinion. Enough options to allow you to do almost anything you want, but simple enough you can build a great story with zero interactive variables. I've made it farther to writing a complete story using this site than I've ever done elsewhere. Now one could argue that is more a statement about my own failings at finishing things and then muse upon the trials and tribulations of the creative spirit, or one could take it as a glowing accolade for the inviting nature of the site's web design and the vibrant community that inhabits it. I honestly think the site will continue with writers using a range of the features, but with most utilizing the simple side of things, and an ambitious few pushing the boundaries of what is possible within the platform, because, as you said, we are human.
I LOLed at this so hard I almost woke up the rest of the house! XD (I do hope you take this as a compliment, that's how it's intended.)
In any case, you make good points on all fronts. Yes, I am advocating the use of a full capacity programming language for CHYOA. Not because I foresee MYSELF ever being able too make any use of it, but because I can't foresee there NOT being a significant number of users who both CAN and WILL. I also foresee that the presently suggested system will frustrate those users to the point that, yes, they go elsewhere. This would deprive us of the chance to see the wonderful worlds and characters therein which they would have built for us... Maybe I am overreacting, maybe not, I guess we'll find out, because, as I said, that was my last effort.
I don't feel attacked. The thing is, I can't do anything with an issue description like "It's a problem!" How would you integrate a programming language like BASIC into CHYOA? Within the chapter text? Replacing the current Score Changes and providing one input field? Introducing a new story mode for "programming"? None of that options would fit into the current structure of CHYOA. What is wrong about that? Providing more options doesn't mean, that everyone has to use them. There are linear stories on CHYOA which don't use branching at all. There are stories without any use of linking. There are stories without any use of conditional branching features. There are stories telling a story, where every decision leads to branching, though every branch continues with the same story, which can lead to literally thousands of chapters with nearly identical content if the story would reach the length of a novel. It's an addition, not a replacement.
I'm glad my Professor Harold Hill impression was greeted with the humor it was intended to produce I honestly believe that anybody who has the skills and inclination to actually program an adult game will do so and they will use one of the many options already out there. I personally follow (and often financially support) 29 such creators on Patreon. They use a variety of different platforms like RAGS, Flash, JAVA, GBLORB, and more. We are in somewhat of a golden age for adult games, as the creators are able to get supported and influenced by their audience during development, leading to some amazing games that would never possibly have existed without this sort of crowd-funding structure. I recommend you check out the work of AKABUR, for example. His Princess Trainer game is simply amazing and free for anyone to download and play. He is a Russian artist, writer, and game designer that is now able to work on these adult games full-time. But I digress. The point is that creators that want full programming flexibility will go to platforms that are designed for that. CHYOA is not the right platform for them, it is designed to be user-friendly and intuitive. It is one of the simplest of platforms and needs to be able to function without forcing people to delve into the depths of the arcane-arts of programming. Gene.sis's improvements is designed for the users that feel like wading around in the shallow-end of the programming pool, without scaring off the users that can't swim at all.
One thing about introducing programming-like features is complexity. This isn't inherently bad, but one does need to pay attention to it. So just a few random points, in no particular order: How will the UI handle very long formulas? Will there be a way to break up big code blocks (e.g. functions)? Will users be able debug/test formulas without having to edit/publish the story every time? What is the execution cap? (An attacker could construct malicious CPU-wasting formulae
That are all good points. I currently use the very small field where you can only see about 15 letters. This is not that convenient. Probably an unfolding input field (js) would be useful. It is possible to add additional spaces between elements, though it wouldn't be necessary to use spaces at all. The current draft also includes inline comments. It is also possible to work with more than one formula by creating additional variables. That way, formulas can be split into smaller pieces to reduce the complexity of a single formula. (There should also be a way to unset variables) There is a syntax check of the formula when saving the chapter. Currently, the formula gets dropped when the syntax check fails (it uses the same behavior of the current score changes). It would be useful to have a way to keep a formula with a syntax error or have the chance to do a syntax check before saving the chapter. (maybe with AJAX). At the moment there is a bug with going backwards, which makes debugging of the current score changes really hard. There is a fix for that bug, where you can go forth and back without messing up score values. (This fix is necessary for the Formula Parser) The execution cap could be a number of score changes and the length of formulas. Thanks for hint.
I will pop my two cents in here quickly. I think any new feature is good but I think this is a complex one. How many new stories use the games system, how many readers do? If it is super popular and brings in site traffic then adding more too it could further boost it. If it hasn't taken off then maybe look into why. It is a good feature but something may be standing in the way of it getting used by authors or readers. As a author I don't usually want to use the game system as it is a lot of extra planning and work even if in the end it makes better content, as a reader I don't want to loose out on content or options. Getting feedback from any user base is like pulling teeth but from this one it may be neigh impossible. People who write erotica on the internet don't often want to talk about it for a lot of different reasons. Reaching out to the most prolific authors and game system users might be one step but there is no promise they will respond or even if their feedback would be useful. Observing trends is another but data can give you a false picture and is easy to get lost in. If this does go forward in it's current form we will need a wiki with coding examples and lots of documentation. I believe there is a better way though, however it would but a huge amount of work on you probably. Put in a visual coding system, it is what most software uses to ease people into coding. Scratch, mindstorms, even unity and UE4 which are professional tools have visual coding systems. These allow people with little or no coding experience to do what they want quickly. A simple example is this, you make four content blocks with text and 2 code blocks. One changes a string which is then used in the end of the story so it reflects the reads choice and the other block contains an if statement that requires they do something to get that option (In this case nothing because I made a bad example but you get the idea.) I wasn't early to this party and I am pretty sure you will already be hard at work on your current features set although I don't think people will really need functions (yet...) and don't stop that work. Just consider how to put the power in the users hands. Edit: Minor spelling, also I forgot to ask about strings. So strings?
There are currently 271 stories have the game system activated (source of that number is the search function, though it doesn't tell if that stories really use it) A reason could be, that you can't do things, you want to do. An example is my own story, which I kind of abandoned because I can't do several things. There is a good example what you actually can't do here. It shows an implementation approach of a clock which would horror to use because it needs a lot of text. Here an example how it would be possible with the formula parser Code: time = {time} + 10 // 10 is the time used for the last action; the initial value for time could be 1080 for 18:00 hour = ROUNDDOWN( MOD( {time} ; 1440) / 60 ) // 1440 is the number of minutes per day. minute = MOD( {time} ; 60) within the chapter the writer then could simply use (as a 24h clock) Code: {hour}:{minute} Documentation should be similar to the Conditional Branches Documentation and examples in the Showcase. This thread is also a good source for creating a documentation. Well, I'm actually not completely sure if I got you. Are the 4 code blocks meant to be one chapter? Conditional Branches - If-Statements let you manipulate the chapter text. The Formula Parser would let you manipulate Scores. Of course, the manipulated Score Variables can be used with Conditional Branches - If-Statements, so you can influence chapter text indirectly. No strings. This feature uses the current SaveGame structure, which uses integer values. Score calculated by the Formula Parser will be truncated to an integer value, though you can use decimal places internally. (else 1/3*3 would result in 0 instead of 1) Using of strings would need an actual coding feature, as you need to create input fields within the chapter text.
Is there any way to tell how many new stories in a given period used the game system and how many didn't. Like in a week 10 normal stories and 5 game stories were created. Is the creation speeding up or slowing down. I think there are probably a bunch of reasons but they can be put in three pots. It won't do what I want, I don't understand it, I do understand it but see it as too much work. Maybe more reasons I don't know Maybe, called me old fashioned I like wikis sorry it was pretty late at night when I made it. Each blue block is a chapter or 'content block' there is a start an end an two in between chapters. It was meant as a bare-bones example of what a visual coding system on chyoa could look like. I said before and I will say it again this path would probably be the most work for you. It would require used of custom scripts either java script or some other such thing and very likely a lot of it and backend stuff. I do think it would make things eaiser on the end user and some compromise that is less coding intensive to make may be out there. I understand, but fuck. What if the input was a chapter, have some chapter a reader can't get to and have the script paste them into another chapter at a defined point could that work?
Well, you could take the number from the main page ("8,349 interactive sex stories") and the current number of game stories from the search function now and later. great summary. The first one could be worked against by extending functionality. The second could be worked against by better and more detailed documentation, and examples. Getting slowly into the issue can also be helpful. For the third one, I don't see a reason to change something. ^^ I won't call it old fashioned. The thing is, that we already have a structure for content, which can be used for documentation easily. Well, this would be much more in direction of arranging chapters and making paths more visible. Like a story map view from a specific chapter to parents and childs (which could appear more than once) A blue block would always consist of the elements - Conditions - Score Changes (includes the tool Formula Parser) - Chapter Content (includes the tool Conditional Branches - If-Statements) - Chapter Answers (connection to other chapters) If the string is defined by the author and there are only a couple of possibilities, it is easier to define a numerical alias. e.g. you could ask the reader for the hair color at the end of a chapter. The answers are the different hair colors and each color would set the variable {haircolor} to a different value. Later you could use Conditional Branches - If-Statements to show the actual value {if haircolor = 1}black{elseif haircolor = 2}blonde{elseif haircolor =3} and so on. This wouldn't be a practical solution for a lot of different values.
I am vastly too lazy I was hoping there was a quick way of telling Not everything is for everyone and that is fine My idea was to but text in blue blocks and then link them together visually so you could see a map of where each option went. In between the text you could add code that would change something, check something, or do something thereby keeping the two thing separate. This system would also allow for easier linking of chapters and the ability to move chapters around with ease. How about this then could I define a block of text as 'end 1' or just '001' and a block that was '002'. Then paste a link to both in the last chapter in a story and have only one show based on a value check? Basically it would mean instead of two different ending chapters I would only have one which was slightly smarter and more centralized. This wouldn't remove your ability to do it the old way but instead provide a clear way of doing it if you wanted.
If you would add Score Changes and Conditions within the text you have to process the text several times just to filter out the "commands". It would also make creating more difficult because the things get processed in the above order. Setting a Condition after a Score Change could seem to be applied before the Condition. If a Score Change is between two Conditional Branches - If-Statements, the writer could think, that the Score isn't changed before the first If-Statement. (maybe If-Statements could get enhanced in the future) Well, linking, in general, could need some improvements. You actually can do this with numerical identifiers. (boolean identifier would work as well) That way you would also only have one end chapter. e.g. sth like {if ending = 1}First ending{elseif ending = 2}Second ending{endif}
Hi! I just want to say that this stuff is neat, and I would really want to use this. I would, but I'm kind of a dumbass when it comes to coding. I dabble but nothing much else. So on the topic of people like me, who would want to use this, but get lost in the coding and worry whether it was done right or not, I would like to add my two cents. I don't think whether the syntax (I hope I'm using the right word) is complicated or not is the problem, but rather the accessibility. In other words, it would be nice if on the side of the page, in perhaps a collapsible box, labeled something along the lines of 'for advanced writers', was a list of every single coding feature, that can be easily copied and modified. Perhaps even with a concise description of what it does. Something easily accessible while writing, so one can quickly check. I think something like that would boost the number of more complex stories. And I think we'd all benefit from that. Is that feasible? I apologise in advance if this was talked about and I missed it, or if I'm just spouting gibberish. I feel like I'm way out of my depth in this thread, but I just wanted to ask.
Maybe we can do something like that in the future. I recently finished the documentation for the current version which includes a function reference sheet. The Formulas can only solve mathematical problems, so the main thing about it is to know what you want to calculate.
I was wondering if you could give us an update on the progress, or even give out an estimate, when the Formula Parser might become available for authors to use?
Done: - integrate and adjust the parser generator library - create parser language - write tests for parser language - create documentation (thanks to Shassar for editing) - implement an autosize textarea as input field for Formulas on Edit Chapter page - implement an AJAX Syntax Check on Edit Chapter page (including a note about missing variable name) - implement a proposal of an 'unset Variable' function "UNSET()" with alias "UNSET" To do: - add execution cap for Formulas - review the feature - review the design of Edit Chapter page - check if the Formula Parser is the best place to unset Score Variables - revise after review (if necessary) (- write tests for the underlying handling of previous chapters (this fixes that problem)) - not sure if I forgot something So the progress is quite advanced and there are just some details missing.
