I'm currently working on a tutorial and various libraries for Quest 3.0 and am wondering how people feel about the level of complexity within a library compared to hard coding into a specific game.

This was prompted by a previous thread in which Computer Whizz and I exchanged our thoughts regarding coding a 'read' command - so he's equally guilty for prompting this long winded posting :-)

I'll use the coding of a read command to work on a 'book' object as an example, just because it has been discussed at length here already so it'll make sense to those who read all the threads as I do.

O.K. - As I see it, there are two ways to go when coding something like this, firstly a bare bones get the job done as easy as possible one - simple user command in the game block, something like:-

quote:

---

command <read #object#> {
if is <#object#;book> then {
msg <A short History of the Universe Volume 14,917, you find it is very dull.>
}
else msg <You can't do that.>
}

---

Easy as pie, and providing there is only one readable object (the book) and the code is put into the main ASL game file this works perfectly well.

If you want to provide that 'read' command as a library though, so that others can use it with a simple !include <libname>. it is a rather restrictive piece of code as it is,
Firstly because I believe that the end user should NEVER have to make any changes actually in the library code - if he or she is using QDK exclusively that is impossible so I think that's a good yardstick.

That means that in a library the code as given will only work for an object named 'book', To get around this you need to find a way to pass the name of the object to the library, either by using a string variable somewhere, or (in Quest 3.0) by giving the book object a property that can be tested by the library, That means the book object must be given a boolean property say - 'readable' and the library code becomes...

quote:

---

command <read #object#> {
if property <#object#;readable> then {
msg <A short History of the Universe Volume 14,917, you find it is very dull.>
}
else msg <You can't do that.>
}

---

That'll work - except of course the message is hard coded in the library and specific to the original book! Again one has to have a way to pass a message appropriate to the author's specific readable object to the library. One could use a string variable, but in Q3 it's better to give the book another property, say readmessage and provide that with an appropriate piece of text. The library code thus becomes..

quote:

---

command <read #object#> {
if property <#object#;readable> then {
msg <$objectproperty(#object#;readmessage)$>
}
else msg <There's nothing to read!>
}

---

The original code would only ever deal with one readable object, As a side effect of coding this more library minded way it is now possible to have multiple readable objects that have different responses. The code isn't as simple to understand, but that's unavoidable.

O.K. Now if one throws in the requirement that reading an object should be able to optionally trigger other events, one needs another property to test.. and the code complexity increases again (I'll spare you an example). Also, because we are now getting potentially several properties for a readable item, time to define a type <readable>.
so that these properties can have defaults that are inherited. The type definition ought to go in the library = further complexity!

The code in a library thus tends to balloon quickly and become very complex in places, the question I have here is (give that libraries are intended to be !include to use and dont EVER modify them) does that really matter? I personally don't think so, the.idea is that libraries are easy to USE not necessarily easy to understand! :-)

An example.. using QDK an author wants to code a series of readable tablets of stone, some significant, some not. All he or she needs to do is include the library (if not already included), then create a series of tablet objects and give each type <readable>. By default the player is told the tablets are boring to read, so for those that are NOT boring, add a property like so:

quote:

---

type <readable>
properties <readmessage = It is the fourth part of the ancient curse - very spooky!>

---

Obviously provide any message that is needed, :-)

That's easy enough to follow I think... and how about having a apocalyptic event triggered by reading the fifth and final tablet? That would require the fifth tablet to have it's readaction property set to "yes" (that means run the author provided 'readaction' if this object is read!):

quote:

---

properties <readmessage = It is the final part of the ancient curse - promising death __
by fire!;readaction=yes>
action <readaction> {
msg <There is a hail of all consuming fire and brimstone just as the curse said...>
playerlose
}

---

Note that because the properties are changeable from code, it is quite possible to start by not setting the 'readaction' for the fifth tablet, only setting it to 'yes' if the other four tablets have been read. So even though a readaction is provided it can be controlled. Then the player could read the fifth tablet over and over safely, until he's also read the other four ;-) This would be very easy to code.

Now all the crunching for the reading and provision of defaults and code choice etc is done in the library - so it does get a bit 'evil' in there at times, but it's not hard to actually use.

My prime question then - should I continue to write my libraries in this 'covers all possibilities' style where they are complex (but hopefully easy to use) or would it be preferable to write easier to follow but necessarily less flexible code?

I'd appreciate any comments from y'all!

Yes, I can see it now.
*I* myself wouldn't do it this way because I want to code it easily and things are easy to get around....... but your way DOES give alot of variety.

Keep it up, just explain stuff as you go in your libraries!