Well, I just know that some of the worst gaming blunders or getting stuck in development hell is generally a result of constant refactoring or redesigning when something doesn't need to be redesigned. Not pointing fingers at anyone here in particular, rather when I think of that I think of a guy named Josh Parnell, "trying" to make a game called "Limit Theory". He seems to be a very talented individual, but there were numerous instances, before he burned out, of him getting caught in the constant refactoring of the code. So, I learned from his mistakes by just refactoring code I know that I will be added to in the future and know that the refactor will greatly aid my workflow. Like in the example of adding spells with the 12 step process, it would take me about 2 hours of coding to add 6 new spells. With the new system of about 4 step process, it took me all of 10 minutes to add 2 new spells. So, that is a great example of where refactoring greatly aided my workflow. But, as there are other places where things could be refactored, but won't aid my workflow because I don't intend to add anything to it, there wouldn't be much point in refactoring, other than to make the code prettier. So that's my personal view on things. I definitely agree that learning to do things better is a good idea, and I will utilize a lot of that for future projects, but for things that aren't needed to be refactored, I'll leave them alone!
===
Well, in C++, when you learn to initially code in the console window, it has you code within int main(), which is implied to be the main function. So when you do a function call, it returns a value to another function call, but eventually control is given back to int main() and the program ends when int main () reaches a return statement, and returns control back to the OS. At least that's how my old C++ textbook explains it.
Well no, actually in console coding I found you can actually declare things outside of int main () which would make them a global variable, usable by any function or code block within the entire program.
I've actually not taken a look at the raw code in the renamed zip file, so can't comment on that.
===
Well, being that Quest only recently got an update (August 2017), after it went with about 1-2 years without any updates, I doubt it includes the const feature from the 2015 update to JavaScript. I've certainly not seen it anywhere mentioned in the documentation or when using the program itself.
===
Both. The documentation is VERY brief on the usage of function calls (they only explain how to use string-based function calls), and I only learned how to use them by trial and error, as they don't work exactly as a C++ function call does. I'll give a basic example I ran into:
Buy a spell that cost 100 soul shards. You start with 300 soul shards. Set to return a value of type integer. Formal parameter and argument is an integer. Formal parameter takes your current soul shards, parameter being called CurrentShards:
CurrentShards = CurrentShards - 100
Return (CurrentShards)
So if you do it like this, the function call BORKS, and returns no value, and instead sets your current shards outside of the function call to 0, and spews an error about the function call not returning a value. However, if you do it like this:
Return (CurrentShards - 100)
Then, it will properly subtract 100 from 300, and returns a value of 200 and then assigns 200 to your actual current soul shards outside of the function call; also won't spew an error about returning a value.
In C++, either way of doing things would properly return a value of 200. But here, it will only work properly if you do the subtraction inside the actual return variable. So as a result, most of the time I don't bother with the formal parameters and just take the actual value that stores the soul shards and has it subtracted in the calculation and gets applied to the value storing the soul shards outside of the program and also don't bother with return values. Its very strange.
===
The program doesn't allow for arrays as far as I can tell. The closest thing to an array here are Lists or Dictionaries. Lists can store a list of strings or objects (which is something you can technically do in C++) but cannot store variables or values unless they are a string or an object. Dictionaries I think work something like a mini-database and requires you to use Keywords to access values in a Dictionary. Unfortunately both Lists and Dictionaries have terrible documentation, and even asking for help from other developers on the Quest Forums, I've still not managed to get Lists to work properly, and haven't attempted to use a Dictionary. If I could figure out how to use them, it would make doing Lore entries significantly easier and listing off purchaseable spells, but my current methods of doing both are sufficient for my needs; just that Lists could likely make it a lot easier... if I could figure out how to use them.
There is a consistent theme with the documentation; it isn't well documented, and most of my workarounds have been devised by trial and error and getting help from the Quest Forums... I've tried to use the documentation but its not very helpful. So learning how to do things in Quest has been slow for me.
Well, the documentation is useful if the type of text adventure you want to do is something like Zork. But if it is more complicated than Zork, which my game is incredibly more complex, then its terrible for getting assistance from.
===
Lore is fun! However I want some consistency, and some recurring characters, otherwise the player asks the question, "Why should I care about all of this?". So need to figure out some ways of both overcoming writers block but also devising interesting mini-storylines that are worthwhile to read and help to immerse players more into the game!
