Oh boy. Time sure flies when you're building the backend for a game, huh? I've got lots of questions this time around, although not all of them are necessarily about making my game. I'm not even certain all of these first ones will be easily answered by anyone but Alex, honestly.
Last update: 2/18


Improvement Inquiries
1.) Perhaps my most important (in my mind) inquiry that's not related to an issue I'm having with my game.

Quite a long time ago, someone made a post here related to some improvements to ASL; amongst other things, I was interested in shorthand operators to increment, decrement, and otherwise shorten code while changing the value of a variable, similar to JavaScript. (++, --, and +=|-=|*=|/=) I wasn't too interested in much else there, but I'm sure other people would be; I'm basically fine with our current and/or/not, seeing as Quest is supposed to be easily understandable by the average person. (I know I had no clue how to read more advanced JavaScript when I first saw it - &&? ||? !? Those aren't intuitive at all!)

Did that ever pan out? They ended up just not posting ever again in that topic, it seems, and it apparently never got committed as an actual improvement to ASL. If it was a matter of man-hours, I'd be willing to look into helping make it happen; I'm no professional coder, but with enough time, Google, and determination, I can definitely learn enough to get things done.


2.) This actually segues nicely into my second non-issue inquiry. I've noticed that there are no GUI interfaces for Object or General Dictionaries, and that there was a similar issue of GUI elements being required for prior improvements.

In a similar vein, I've noticed that the Script Editor has the same layout as it did back in ~2008-2010: a single column of folding categories that you have to scroll down and find what you're looking for.

Modern game design has shown me how terrible this is. Seriously. The more elements you have, the more cluttered it gets, and the further down an element is, the longer it takes to access it. IIRC, Kerbal Space Program used to have an issue with this, as did TerraTech. It just doesn't cut it with large numbers of entries.

I suggest it be switched to a tab-style interface, just like most of the QDK. In fact, I'd be willing to help modify/extend the current editor libraries to allow for editing and creating the new dictionaries. I'm not certain if the current Script Editor layout is defined by the editor libraries or by vbscript(?); if it's not defined by the libraries, I think I'll have a lot more learning to do.

?: I don't recall exactly what the topic said Quest/QDK is written in, but that was the first language I saw at a quick glance, and it may be wrong.


3.) While reading the forum topic linked in #1, I'd like to think I've gained at least a little bit on insight into how ASL (and by extension, Quest) works. Correct me if I'm wrong, but are stringdictionary, scriptdictionary, and objectdictionary preferred over a generic dictionary because the system has to check what kind of value an entry is before it can return it?
If so, perhaps it would be a good decision to implement dictionaries for booleans, doubles, integers, etc...? I don't recall any other types off the top of my head. As above, I'd be willing to help with their UI elements.


4a.) I have a few suggestions to improve upon the current Map system. For one, I think it would be a good idea to include dropdown selectors for all 15 non-blank tiles that are possible with the current system; currently, only something like 7-9 are available.

4b.) Second, how difficult would it be to implement a more advanced border draw system (such as diagonal edges, round/circular walls, geometric shapes, etc)?

4c.) Less importantly, I would suggest eventually implementing a tile preview on the room's Map tab, if possible; that way, a test run wouldn't be necessary to check your colors and/or otherwise confirm you're satisfied with the look of a room.


5a.) After all of this talk about the UI, I've actually thought up something else about it; correct me if I'm wrong, but currently, the UI requires fiddling with JavaScript and CSS for actual, physical layout customization.

Would it be possible to implement an easily-editable layout, such as an HTML template and stylesheet pair defined in XML? You would define the correct div IDs within the html file in the order and layout you want, and the system would then insert the necessary properties and other data. By default, Core.aslx would eventually point down to the default UI files.

If I remember correctly, (I haven't done much digging into the current UI system) it may also be necessary to include a JS file with that pair, to define certain variables for the UI to properly update.

5b.) 2/17: After taking a look through some of the functions defined by Core, I've mocked up a library editor that could be used for such a custom UI feature. I will warn you (Alex) ahead of time, though; it may be necessary to change your current code for InitInterface to split externalstylesheets as a string if you don't feel like adding a stringlist controltype.

Actually, after having typed this; is it possible that there's already a means to implement a completely custom game UI in Quest, just lacking a UI element for itself? What I have seen doesn't seem like it has quite the flexibility I'm looking for; since writing this post, I've already devised and prototyped a rather nice UI replacement that I'd like to implement into my game if at all possible. It would absolutely require that I be able to efficiently replace the entirety of the current generic UI html, though (and likely the UI code itself); I don't know if you build the UI in code or simply use a base HTML template, but if it's the latter, this would hopefully go quite smoothly.

2/18: I forgot to mention last night; my intent is that the HTML template replace only the body of the current UI template. As far as I can tell, almost everything currently in the header should absolutely not be removed.


6a.) Last but not least, would it be possible to implement extended and direct JavaScript callbacks?

For example, let's say we have a function "yes" that simply returns "yes" as a string. Normally, to use the value of this function, it would have to call an ASLEvent, which would then call some dedicated function that would do something with that "yes".

It would be great if you could simply type something along these lines:

answerVariable = JS.YesLib.yes()

6b.) 2/13: I only just thought of this, but how difficult would it be to extend the ASLEvent function/native ASLEvent code to handle any number of parameters?



Questions


1a.) Alright, now that I've gotten all of that stuff out of the way, time to go through my questions list. First off, I've been wondering for a while; is using dictionaries faster, slower, or the same speed (delay) as using purely object attributes? Originally, I had my combat stats (defenses) stored as attributes; however, now that I mostly use Cloud9 to edit my game, I realize that there's just so much clutter in my player object.

I've been considering two different systems to replace my old one (and to build off of in the future), both of which I've prototyped and made a lot of code for: one revolves around using dictionaries to store almost all data (ie game.pov.equipment["weapon"], game.pov.def["kinetic"], etc) and one revolves around object trees to organize data (ie game.pov.equipment -> Character_Equipment, game.pov.equipment.clothing -> Character_Clothing)

Which of these will cause the least amount of delay when being accessed? I'd rather prefer to use dictionaries, but I've played some IF in the past where access speed was just horrible; taking up to three seconds to switch area and having a good second delay to every command. I want any games I make to be snappy and light, so knowing this in advance would be very useful.


1b.) Along the same lines as above, which would be the better choice: an object with up to a thousand (possibly more?) boolean attributes ("flags", if you will), or a single dictionary filled with booleans? Again, I'm primarily concerned with access time; if there's a noticeable delay from using __DictionaryItem() as opposed to simply using object.attribute, I'd really like to know. That said, these flags won't likely get called nearly as often as combat stats.


1c.) I also have been looking into the processing delay in Java for integer variables compared to doubles and floats. I got the sense that what I was reading mostly applied to extremely time-sensitive tasks (where every ms counts), but would it be better for me to store doubles (ie percent modifiers, or fractions of a liter) and use them directly, or to store integers and divide them to get the double I need?

For example, I'm creating a more advanced volume system that measures in mL; my first draft simply used the built-in volume system to store individual mL, but would it be noticeably slower if I were to instead base volume in liters and have objects measure down to the thousandths?


2.) Is it possible to have functions with subfunctions (methods?) in Quest like JavaScript? For example, a function CustomUI.Update or something. It's getting a bit late, and I don't really know how else to elaborate on that matter. It would just be convenient for organization, I can certainly make due without it.


3.) How would one use a positive-number variable as a negative number? Is it as simple as typing variable = var1 + -var2, or would I have to use something like var2 = 0 - var2?


Alright. I'm heading to bed; this post took a lot longer to make than I thought it would. See you all tomorrow morning.

I think QuestKit will resolve most of this, as it will use JavaScript directly, but that is some years off, I would guess, so is not a solution yet. I doubt the Quest language will be changed much, given QuestKit is beinhg developed.

1. I remember Chase asking about that. Nothing came of it...

2. A simple, if partial, solution in my opinion would be to have the option to default to code view for scripts, as that allows you to see much more at one go.

I tend to put any long scripts in their own function, and put that in a library, so it is not so much an issue.

5. This post describes how to add a stylesheet to your game. You can add javaScript the same way.
viewtopic.php?f=18&t=4747

Is that what you mean?

1a. I doubt it makes a difference.

1b. It has to take longer to get a string from a dictionary attribute and convert it to a Boolean, rather than just get a boolean, but whether the difference is noticeable I do not know. Try it and see what happens.

1c. Personally I would stick with integers as far as possible, as you do not get the funny rounding errors (0.9999999 instead of 1). I would guess it would be quicker, but modern CPUs handle floating point arithmetic directly nowadays, so you will not notice a difference.

2. No.

3. This works as expected:
x = 5
msg(-x)
y = -x
msg(y)
z = y + -x
msg(z)
You can test something like this in seconds by putting it into a start script (Scripts tab of the game object).

The Pixie wrote:I think QuestKit will resolve most of this, as it will use JavaScript directly, but that is some years off, I would guess, so is not a solution yet. I doubt the Quest language will be changed much, given QuestKit is beinhg developed.

1. I remember Chase asking about that. Nothing came of it...

I somewhat expected as much. Reading that entire topic, they seemed incredibly all-over-the-place. I didn't initially see the second page, but in any case, I don't think it's anywhere near so vital that we change all of the syntax to match another language; I really just want shorthand for inc/dec and math. I do most of my editing in Cloud9, and sometimes it's nerve-grating to type very long variables. I can only imagine that if I go with my tree-style tracking system, I'll have a lot more of that to come.

The Pixie wrote:2. A simple, if partial, solution in my opinion would be to have the option to default to code view for scripts, as that allows you to see much more at one go.

I tend to put any long scripts in their own function, and put that in a library, so it is not so much an issue.

True; however, it's only good for people who know how to make what they want to happen, happen with the use of code. Some people (off the top of my head, I can think of XanMag) just don't have an affinity for code, and would prefer to use the graphical editor. Honestly, as it stands, the current Script Editor (ie the panel used to select new code to insert, as opposed to directly edit it) is "good enough", which is likely why it hasn't changed; however, there are many ways it could be improved.

As do I. Most of my game is stored in a series of libraries, mostly for organization. I even discovered that objects can be cloned using a library, but it's difficult to make them work correctly. Quest especially doesn't like inherited dictionaries.

The Pixie wrote:5. This post describes how to add a stylesheet to your game. You can add javaScript the same way.
viewtopic.php?f=18&t=4747

Is that what you mean?

No, sorry. I think you misunderstood; I already know how to (and have) customized my game with a stylesheet and some UI-altering Javascript, but I think it would be much better to implement a system where the entire UI is flexible; similar to how libraries can currently extend the editor, it would be so much more efficient if the game used a more-or-less blank HTML page as a template, filled with ID-tagged DIVs.

Then, it would be incredibly easy (not to mention require less code) if one could simply add an <include ref="customui.html" /> tag near the top of their game, and the parser would then use that, combined with a defined stylesheet, as the basis on which it runs. It would be as easy as moving the gridcanvas (or whatever) div to, say, it's own dedicated accordion; the UI would simply deal with it. There'd be no need to run a bunch of JS every time the UI updated in order to keep everything where you want it to be.

Even better, one could perhaps then use a command to load a new HTML template if they want to switch UI style mid-game.

The Pixie wrote:1a. I doubt it makes a difference.

1b. It has to take longer to get a string from a dictionary attribute and convert it to a Boolean, rather than just get a boolean, but whether the difference is noticeable I do not know. Try it and see what happens.

1c. Personally I would stick with integers as far as possible, as you do not get the funny rounding errors (0.9999999 instead of 1). I would guess it would be quicker, but modern CPUs handle floating point arithmetic directly nowadays, so you will not notice a difference.

1a.) That's good, it means I have some flexibility. Both of my methods have some flaws I have to work around, but now I have options.

1b.) I haven't tested this, but the default Dictionary type allows for any type of value; in the XML, you simply add 'type="{type}" ' to the value tag. I wouldn't be converting strings to booleans, I literally would be storing booleans inside a dictionary for more sane access, as opposed to tracker.eventTagWXYZ.

1c.) I don't really plan to use much more than three or four digits past the decimal point, in any case. My biggest issue with integers is that my smallest measurement is set in stone; nothing can be smaller than 1. I'll look into both systems, but I'm leaning mostly towards my double prototype as opposed to my older int prototype.

The Pixie wrote:2. No.

That's a shame, but no big deal. I personally just prefer the organization that it would afford me.

The Pixie wrote:3. This works as expected:
x = 5
msg(-x)
y = -x
msg(y)
z = y + -x
msg(z)
You can test something like this in seconds by putting it into a start script (Scripts tab of the game object).

Good to know! I suppose you're right; it was just an idle thought I had around the time I made my post, and I decided to include it.