Hi,

I decided to edit another section of my game for the time being due to latency issues making timed scripts not work online.

I already added a section at the beginning of my game that allows users to choose to skip or play the introduction. It worked just fine, so I added the same code to a later section using lots of timed scripts. Now, this later section will not play at all. The timed scripts will not work when under this menu selection system.

Could someone take a look and see if I'm not making a simple mistake?

I have attached my game file with the conversation library. To get to the section in question and play it, start the game and get through the introductory sequences. Then, type "move player". It will automatically move the player into the sequence that isn't working for me. The game hangs on the first timed script sequence.

I'm still looking it over, but one interesting thing is that once it's "hung", if you type a command, then the timers kick off, and it keeps going.

Oh wow. That's really strange!

Also, thanks for looking into it.

It's definitely related to the menu. If I replace the ShowMenu line with "if(true)" after setting a result variable to "Play Sequence", then the timers fire as expected. It's most likely a bug. I'm just wondering what is triggering it, as you had a menu and sequence before.

It could be where I have the script maybe? Although I will say that I tried it originally in the "Before Entering for First Time" script area, then I tried it in the "Before Entering" area. Finally, I moved it to its current spot in the room description.

It didn't work in any location, so that may rule out it being a location-specific bug.

Out of curiosity, what happens if you use show menu instead of ShowMenu?

Asyranok: Yeah, I tried that as well. I even tried removing the "firsttime". No joy.

levicki: Good idea. It works fine that way.

jaynabonne wrote:Asyranok: Yeah, I tried that as well. I even tried removing the "firsttime". No joy.

levicki: Good idea. It works fine that way.

So its a bug in new ShowMenu(), most likely something in JS part of it (other parts look to simple to cause that).

@Asyranok:
I know you are still at the beginning of the coding, but you should consider rewriting this:

            switch (result) {
              case ("Move to first spot") {
                Constellation01.order = 1
              }
              case ("Move to second spot") {
                Constellation01.order = 2
              }
              ...

You just need to use a dictionary:

    <order_dictionary type="stringdictionary">
      <item>
        <key>Move to first spot</key> // or even better just "first"
        <value>1</value>
      </item>
      <item>
        <key>Move to second spot</key> // or even better just "second"
        <value>2</value>
      </item>
      ...
    </order_dictionary>

And then write:

order = StringDictionaryItem(order_dictionary, player_choice) // where player_choice is a string "Move to first spot", etc

Variable order will be string so if you need a number to assign just use ToInt() around StringDictionaryItem(). You can now put that code into a function to which you pass a constelation object as a parameter and reuse the same code for all of them instead of having tons of cases with the same code repeating over and over.

Ok, so I just had to work out the difference in the two cases... The difference is that for the intro sequence, you have this:

ShowMenu
wait
SetTimeout

whereas for the complex sequence, you just have:

ShowMenu
SetTimeout

The intervening "wait" in the intro sequence seems to avoid the issue. (If I add a "wait" to the latter one, it works.)

So it's definitely a bug, but with an awkward workaround...

Thanks, Jay, for taking the time to help me! I'm glad you were able to figure out what was going on, as I was lost

Thanks, Levicki, I will change that as soon as I have the time. It looks more efficient.

Asyranok wrote:Thanks, Levicki, I will change that as soon as I have the time. It looks more efficient.

You are welcome, but please note that it is not only more efficient -- it is also more readable, and much easier to change how it works later because you have to edit only in one place, not in several.

An unwritten rule of thumb in programming:

Whenever you are tempted to use copy & paste on a part of code just stop and think how you could convert that code into a callable function.

Another thing I forgot to suggest:

if (condition1) {
  if (condition2) {
    if (condition3) {
      msg ("yes")
    }
    else {
      msg ("no")
    }
  }
  else {
    msg ("no")
  }
}
else {
  msg ("no")
}

Is also not really good style -- if "no" is always the same message (I put "no" for brevity, but it can be a long and complex one too) first thing you want to do is to make a template:

<template name="Yes">Here comes a story continuation once all the conditions are met.</template>
<template name="No">Here comes my really long explanation why you can't do something until all the conditions are met.</template>
...
  msg(Template("No"))

This way you will avoid copy & paste for text and you will have to edit only in one place when you want to change the text.

Also, unless you want to show different messages for each stage of puzzle completion (for example to give player some hints on how to proceed if the steps are different or need to be in certain order), the above can be written as:

if (condition1 and condition2 and condition3) {
  msg (Template("Yes"))
}
else {
  msg (Template("No"))
}

Finally, regarding the story, it sounds interesting but I find it a bit of a stretch that Duffy's wristband has such a large range that it can affect translation when he is away and you talk to Ziggy. Maybe she should have her own?

Hope my suggestions help.

While on the subject of "unwritten" rules of programming, I'd like to ask a question that I've been wondering about:

when should you put code into a function (and thus be used via calling the function) vs just writing the code in where you want it.

I am *NOT* asking about in regards to how often the code is going to be used elsewhere.

I'm asking about in terms of programming, what I mean is, like with using this example (I think this will explain better what I'm trying to ask about, and ignore the uber simplicity of my example, lol. It address the question that I'm trying to ask about):

which is better to do via programming efficiency? (if I may call it this, as I don't know what to call it, lol)
(and also, when do I do it which way?)

<turnscript name="game_turns_turnscript">
game.turns = game.turns + 1
<turnscript>

OR

<turnscript name="game_turns_turnscript">
game_turns_function
<turnscript>

<function name="game_turns_function">
game.turns = game.turns + 1
</function>

when should I put a code~script block into a function vs just using the raw code~script block ???

Is there a difference in terms of programming? and, if there is a difference,
Is it better to do it one way for certain situations, and the other way for other certain situations?

HK, here's my take.

For something like your example, I think a function that only has that one line and is only used in that one place would detract from the understandability of the code. It forces someone reading the code to look somewhere else. And I think that is the key for me in terms of functions. Functions (in any language) can be used as an organizational tool to:

1) Create pieces that are called from more than one place, to avoid having the same code all over the place (semantically as well as syntactically - in other words, you're not just compressing code by finding the same lines in different places. It has to *mean* the same thing in all the places it's used).

2) Isolate code that you think someone (or you) might want to change in the future

3) Break code down into more manageable pieces. For example, you would not want to have a single script that scans page after page after page. It becomes too difficult for someone looking at the code to take in. By breaking the code down into logical pieces, someone can get a good sense of the overall structure of a piece of code and then drill down into called functions if those pieces need to be understood in detail. It provides a way to "chunk up" the code.

4) Provide clean entry points to an area of functionality. That might be outside the scope of what you're asking. But if, in your example, that code logicially fit into a library - part of a bigger whole - then you could define all that code together as functions.

So the aesthetics for me are: 1) Logical grouping of code, in terms of functionality or even policy (that is, keeping all code together that makes certain decisions about how the code operates) and 2) Ease of understanding and maintenance.

As an example of policy, if you want the game object to own what happens with turns, then instead of putting the code in the turn script (or even a function), you might want to invoke a script on the game object, so that all the code for turns is under the game object's control.

I'd say that the more you program, the more you'll develop an instinct for how code should be broken down. But there is no one answer. In the end, it's your creation, and it all depends on what makes sense to you. Just as with writing, where you develop your own style about sentence length, when to make a new paragraph, how to organize text into chapters, etc, so too with programming you'll build your own style. There are guidelines and lots of opinions, but in the end, it's what makes sense to you.

Since Jay has already answered the theoretical part I will just cover your question with a direct example:

Putting such a simple one-liner:

game.turns = game.turns + 1

Into a function does not make sense.

It would however make sense if you wanted to increase game.turns by a variable amount:

<function name="game_turns_function" parameters="turns">
game.turns = game.turns + turns
</function>

And now you can call the function from a turn script:

<turnscript name="game_turns_turnscript">
game_turns_function(1)
<turnscript>

But now you can also call it from any other object script! For example, you can make passing through every exit take a different number of turns:

  <exit alias="south" to="lounge">
    <inherit name="southdirection" />
    <attr name="turns" type="integer">5</attr>
    <script type="script">
      ... process your exit checking, unlocking, etc ...
      game_turns_function(this.turns)
    </script>
  </exit>

You can even go further by creating a new type and moving attributes and scripts there so each object inheriting from new type will have default handling where you will only have to change the turns attribute value to make them behave differently.

Hope this example helps.

thanks to both of you (and ya, sorry about the uber short simple example, replace it with a large code~script block and not a single definition~attribute~variable line, lol. Actually, don't just replace it with a single large code~script as well, see below for hopefully something that makes sense of what I'm trying to ask about, lol)

so, for the most part the difference is for what's best or needed by you (organization or purpose) in what you want to do.

I though I was more asking about... maybe this is a better way to say it (sorry for not being clear):

processing power, does the game engine run faster if your code is more broken down into more functions (being called upon) than just sticking the raw code~script blocks into the code where you want it, or is it worse for performance?

I mean, for nesting code, is it better to use a bunch of layers (via function calling), or to just have the raw script~code in the desired nested code location?

what's better in terms of processing~performance of the game engine in regards to code:

code location
-> call function 1
->-> call function 2*
->->-> etc

*function 1
-> call function 2**

**function 2
-> call function 3

or just:

code location
-> raw script 1
->-> raw script 2
->->-> raw script 3

----

or maybe this is how I should phrase it:

is it better or worse to have layers upon layers of calling functions or to have as least layers as possible of calling functions ??

-------------

I was just reading some of that book edition on "Mr. Mike" and game programming~making, and he talks about how you want to keep your code as "flat layered" as you can (if I remember correctly), but this was more due to working with a team, and having to connect all the different work~elements~systems together in being in sync for the making of a game, as it can cause more hassle by having too deeply layered code, again if I understood it correctly.

So, i was just wondering if it matters in terms of the programming and~or its processing~performance with quest, if layers of code makes a difference or not.

i.e.

if quest has to search for multiple functions and functions within those functions to run some code, can it handle this fine, or will it be slowed down or even have problems with doing it? or would it be better to have as little layers upon layers of finding chunks of code of when trying to do some main code?

or, maybe this makes sense, lol:

is it better to have all nested script, right there in the code location (the main~specific code you're working with), or is it better to be referencing it (the nested script of the main~specific code you're working with) from many other locations and even further nested layers of those other locations?

I'm not sure about what "Mr Mike" is saying, but I'd say that you would only bother optimizing something that has an actual performance problem. For most of what you will be doing in Quest, the difference caused by the overhead of function calls will be on the order of milliseconds. It's just not even worth worrying about.

So basically: if you end up with part of the code being slower than you'd like, by all means optimize it. But unless you get into some really processing-intensive coding, I wouldn't even let it cross your mind. Computers are fast enough that for what Quest games normally do, it doesn't even factor in.

That is a good question, though.

thanks for the additional response, jaynebonne, and sorry for me being so unclear on what I was trying to ask about. I wish I knew the programming terminology and~or concepts better, and so I'm not fumbling around with trying to ask about such stuff.

------

and I was refering to this:

http://freecodingtutorial.files.wordpre ... mplete.pdf

sorry, for the unexplained reference of "mr. mike", lol.

-------

I can't find from where I was reading it (good luck finding it... 754 pages... lol... though I didn't get that far into reading but I don't know how far I got and I think also also skipped ahead and read those parts so I've no idea where I was reading the stuff from), but I just happened to re-come across this snippet, though the surrounding text may not be on the subject: 229 pg in the comment box. I think it is talking about the inherited (or object types) properties (if we wee talking about quest), so I was wondering about the coding "heirarchy" too.

My opinion - it's misguided. Let's examine the two sentences that are actually intact (the others seem to be missing words?).

Object-oriented coding techniques make it easy to
extend one class into another, but there is a risk of confusion
and error when the new class is so different from the original
that it might as well be a completely new class.

Well, that makes no sense. The point of inheritance in the standard sense is to model an "is-a" kind of relationship. As a crude example, you could have an "Animal" base class with a "Mammal" derived class, and then two derived classes from that, "dog" and "cat." So you have "a Mammal is an Animal", "a Dog is a Mammal, which means it also is an Animal", and similarly for a cat. Yes, if you derive incorrectly and, say, derive a Cat from a Car, such that your Cat now has four wheels, then you deserve all the confusion you get. That's not a flaw of object-oriented design - that's the danger of bad design, period. It doesn't follow to not use inheritance - it follows that you use it properly. If the new class is so different from the original that it might as well be a new class, then there is your clue - make it a new class. And if you have a screw, you use a screwdriver, not a hammer.

A deep inheritance tree complicates the
problems of changing something in a base class without
adversely affecting many classes that inherit from it.

So, again, it comes down to design. If you have a class hierarchy with a well thought-out design, what sort of change would you be making in the base class that would have adverse effects on the derived classes? If it has an adverse effect, then it means it's probably not a proper change. It requires you to acually know your code before you make changes and to make sure the changes are logical.

WIth the sentence fragment I see, I sense he wants to recommend using helper functions and keeping the classes distinct instead of class inheritance. But depending on what you do, this will end up with the same problem. What happens if you have classes that all rely on the same helper function and you change the helper function? A base class with functionality is identical issue-wise to functionality that is broken out and called. The latter ends up not being encapsulated in an "object", but the perils are the same. Basically, in the end, it's all code calling code. The only way you will be able to keep changes from affecting a wide range of code is to keep all the code entirely separate - and then you run into the *other* grief, which is maintaining multiple copies of identical functionality, spread out across the code base. Believe me, I'd rather have to keep a class hierarchy sane than try to keep multiple pieces of common code in line.

These comments together imply to me that the author, either himself or via others' horror stories, has encounted bad design in OO situations. That is not an inherent flaw with OO techniques. Whatever technique you use, bad design will bite you. A well worked out OO design will modularize and encapsulate your code and make life much easier and (ideally) prevent spaghetti code and bugs. It's not a straightjacket that forces you to write good code, however.

Jay, nice explanation, but I think that in this particular example it would have been sufficient if you just said "Take anything that begins with free... on the Internet with a chunk of salt".

That too.

lol !
I've had trouble finding books on programming that I liked. In my experience they seem to often be written by either
A) A professional writer, who researched the program language to write the book, and isn't the greatest programmer
B) An extreme nerd who is great with programming, but is not particularly good at communicating with people

The "For Dummies" books I've read are clear, but not especially thorough or well organized. Another book I tried was thorough, but very fast paced and laden with "nerd humor" which I enjoyed but was also distracted by.
Of course, it doesn't help that not knowing the proper terminology makes it hard to look stuff up in a glossary or index.