And when you do complete this "game" and are about to ship it you must send the user / player all the data necessary to play the game. Hence this every piece of media you want to code into your game / story must be in the directory of your new story.
Right when you create a new story in Archive a corresponding folder is created in Archives "Storys" directory. In that you will find a system directory. For example: \Storys\Archive\System ... everything that you do copy info this folder will be loaded into your story and is then accessible as media. You can also create subfolders for more organization. Maybe have a look into Archives system folder..
If I'm following you correctly, I must then create a folder within the Story folder itself if I want it to be available within the GUI to be accessed through a variable, and the same with any media. So it's impossible to point the folder variable to a folder located elsewhere on the system. If I'm following you correctly, I guess that makes sense, and I can understand the reasons you wouldn't want it to work that way. I guess maybe I should have thought of that, but I'm a developer. I wouldn't say the same is true of the average user, so this is probably something you want to explain quite well in your tutorial.
EDIT: Okay, future me here, back to revisit this. I finally figured out that I need to have the folder I want to access media from in the "System" folder, and not in the "Media" folder. I know this is what you said in the quoted section above, but the first time I set up a folder in the System folder, the program didn't detect it, because I alt+tabbed out to move some stuff in there. Only after I backed out to go and look at how you set it up in the included stories did I catch the program parsing my directory, and then I understood how it worked. Constructive criticism: this is wholly un-intuitive. Can you call your folder parsing function when a user clicks the button to browse for a folder, so that the directory parsing happens closer to the point the user is going to look for it? This would likely eliminate some confusion, and have the added benefit of allowing a content creator to alt+tab out and make changes without needing to close out of their editing session and restart it simply so the program can reparse the folder. Also, if media doesn't go in the "Media" folder, what is the Media folder for? One further suggestion, the options to display a random image, or display images in descending order (not ascending?) I can see the use-cases for, but MostlyDescending seems unnecessary. Less random than random and less in order than descending... might as well just be random. Also, the tooltip for FromFolder mode is displayed regardless of what mode is selected above. And I would maybe rethink the way you're asking the user to position/scale the images. Scaling and placing the images through scaling the negative space is un-intuitive. I would have expected something more along the lines of setting the coordinate for the top left corner of the image, and then optionally choosing to scale it with perhaps a slider and a range from 1-200% or something like that. Probably the ideal solution is some kind of a drag'n'drop interface if you want to adhere to the GUI-driven principle. Asking the user to do their own arithmetic here and to manipulate the negative space rather than the image itself seems a strange way to handle this, and it raises questions like the following: What is the reference point for left margin if my image is say 450x900 in portrait mode and my resolution is 1920x1080? I'm sure we could agree a solution that eliminates such questions is going to feel a lot easier to the end-user.
Also: how does the AutoTimer thing work?
The second part to realize is, there are two stages .. levels ... conditions ... call it what you what. However, the one is your story, while you are writing. And the other is your story while someone plays it. For example you do create a number variable with the value of 5. And you continue to use this variable. Let assume, later on in your story you add 3 to the variable. So you know at this point in the story the value will be 8. But all of this will only happend at runtime. When the player plays the story. Only at runtime this varaible goes live with value of 5 and later will be added by 3.
And that's the same for variable file & folder. These both variable types are for the player to be filled. (Ok, you can fill them also in the stage, but I would not do that. I even think about denying it by code, hence this is a security issue.)
On this part, if I'm not misunderstanding you, then I think we're in disagreement. Let me see if I'm understanding correctly. I can set a value for any variable, as I would expect, but are you saying that when the user encounters that variable at run-time they can choose to reset it? And you feel that the author of the "story" pre-setting the variable values is a bad idea? Maybe I've misinterpreted you, but any time we're designing content to be consumed by the user, I would take the opposite position and say that it's a bad idea to expose the nuts and bolts in user space, as we shouldn't assume that the average user is as technically inclined as the average content creator, programmer, story writer, whatever you want to call it. I think for the most part, a user just wants to consume content without having to think too much about it. Also, it would seem to quash the ability to write my dialog in such a way that it seems "aware" of the picture being displayed, in the case that I wanted to distribute the story along with accompanying media that it is designed to work with. If the user then points the script at a different folder without knowing why they're being prompted to change it, I would think that at a minimum they would run into confusing dialog if not error messages.
Ok, on to your second big question..
I have to think about that. Right now I would say no. It's not that it would be impossible to ex- or import data. This is instead the other way around. I already implemented such a function. As this is part of a coming feature. No, right now I assume that the structur behind it is to complex / not opitmized for this... I mean really... it is very complex.
Ok, I think I take your point. I was running under the assumption that you had approached this by simply linking gui elements to method or function calls, and thus, if one simply had even rudimentary documentation of the names of the functions or methods along with their accepted parameters, then understanding what they do should be fairly self-evident as one node in the gui would execute exactly one function or method in the code and the functions themselves wouldn't have a need for more than maybe one or two parameters, because that's all that's available in the gui itself. But if this is not the design, I couldn't imagine how it must be working behind the scenes, so I will take your word for it that it's too complex to implement.
Or another example: the routing between nodes & chapters is all guid driven. Sure you could name them yourself, but if you look into more complex chapters you would go insane by wiring them up just by code. But hey, that's my opinion. I'm a very visual person and every one of us works in a different way.
I think the insanity you're referring to is an artifact of the GUI creating a program flow that is highly procedural in nature, versus being a more event-driven or object oriented design. I don't disagree with this design choice, though, as a procedural flow is going to be much simpler for someone who doesn't have a background in programming to digest and learn to do in a short amount of time. Event driven wouldn't make a whole lot of sense in this format, and while an object oriented design would be overall more robust and more flexible, it would be quite difficult if not impossible to represent and explain in a graphical way. Overall, I think you've done a really nice job of creating something that has the potential to be fairly intuitive for anyone who's inclined to put the time into creating something, but as both an interested user and a fellow developer, I would give you this advice: great documentation/tutorial mode is going to be the difference between success and failure. The easier it is to understand and utilize the content creation system, the more people will be inclined to use it, and eventually, you're bound to see some really good content come out of it, and it's that user-created content that is going to drive the user experience for the vast majority of the userbase who are going to be more interested in consuming content than creating it. Those content creators are all worth twice their weight in gold, do everything you can to empower them!
Now that I think I understand why I couldn't get things to work the way I expected, I'm going to take another shot at producing some content of my own, and I will be sure to report back on my experience. Thanks for taking the time to engage with my questions!
So congrats and thanks a lot for all your work.
She said she enjoyed them. 