Hello all.

When I create a Quest adventure my workflow is like this:

• First i create all the rooms.
  I give them names, but do only the very basic configurations.
• Then I create all the exits connecting everything and effectually create the world.
• Then I go back and start completing the rooms one at a time adding descriptions, aliases, objects inside the room etc.
• Finally I put the NPC's in their right places.

This approach works very well for me (I was inspired by a thread inhere somewhere, thank you)

But if the world is big it can be a little overwhelming to keep track of which rooms are completed (or maybe semi-completed) and which have not been toughed yet.

So.
It would be great for me if it was possible to for example rightclick on a room in the left pane, and assign a colour to it.
Or something like that.
That way it would be easier to keep track.

And come to think of it, the same goes for any other object.
I actually put objects in the rooms fairly early and then return to complete them.

Just a though :-)

Best regards
Benny

while not quite the same as what you want...

you can use Objects like a 'folder', for your own internal (specifically using/within the GUI/Editor, though also via directly in-code too, it can be useful as well) organization (these Objects are NOT interactable within your game world by the person playing the game, they can't be visited by the person playing the game):

<object name="room_objects_folder">

  <object name="completed_room_objects_folder">

    <object name="room_99">
    </object>

    <object name="room_98">
    </object>

  </object>

  <object name="incomplete_room_object_folder">

    <object name="room_1">
    </object>

    <object name="room_2">
    </object>

  </object>

</object>

<object name="npc_objects_folder">

  <object name="completed_npc_objects_folder">

    <object name="npc_1">
      <attr name="parent" type="object">room_1</attr>
    </object>

    <object name="npc_2">
      <attr name="parent" type="object">room_2</attr>
    </object>

  </object>

  <object name="incomplete_npc_objects_folder">

    <object name="npc_99">
      <attr name="parent" type="object">room_99</attr>
    </object>

    <object name="npc_98">
      <attr name="parent" type="object">room_98</attr>
    </object>

  </object>

</object>

and... there's also the comment lines/blocks too:

within scripting (within a scripting container) only:

<object name="example_object">
  <attr name="example_script_attribute" type="Script">
    // your comments (comment line)
    msg ("blah")
  </attr>
</object>

<function name="example_function">
  // your comments (comment line)
  msg ("blah")
</function>

etc scripting containers (within Command's 'script' Attribute, Turnscript's 'script' Attribute, etc etc etc)

--------

I think... this can go anywhere... but not sure....

a comment line:

<!-- your comments -->

or, a comment block:

<!--
your comments
-->

you can also create a library and just use it manually (copy and paste the code from library into your game file as needed) (NOT as an actual library that is added to your game):

example_library_file.aslx

(the below is just a brief/quick example, to give you an idea of how you can use it for your own organization/reference/usage... my library is much more expansive... lol)

<library>

  <!--
  Functions
  -->

  <function name="example_function">
  </function>

  <!--
  Commands
  -->

  <command name="example_command">
  </command>

  <!--
  Verbs
  -->

  <verb>
    <property>XXX</property>
    <pattern>XXX</pattern>
  </verb>

  <!--
  Libraries
  -->

  <include ref="magic_library_file.aslx" />

  <!--
  Templates
  -->

  (I don't know templates that well, hadn't learned how to use them yet, and nor how to write their syntax yet)

  <!--
  Delegates
  -->

  <delegate name="example_delegate" />

  <!--
  Attributes
  -->

  <!--
  Integer Attributes
  -->

  <attr name="strength" type="int">0</attr>
  <attr name="endurance" type="int">0</attr>

  <!--
  Boolean Attributes
  -->

  <attr name="dead" type="boolean">false</attr>

  <!--
  Objects
  -->

  <!--
  Player Objects
  -->

  <object name="player">
  </object>

  <!--
  Room Objects
  -->

  <object name="room">
  </object>

  <!--
  NPC Objects
  -->

  <object name="npc_1">
  </object>

  <!--
  Mechanics/Formulas/Equations/Expressions/etc
  -->

  // player.base_damage = player.weapon.damage + player.weapon.damage * player.strength / 100

  // damage = (attacker base damage * critical_function) - defender base armor rating

  <function name="leveling_function">
    <![CDATA[
      if (player.experience >= player.level * 100 + 100) {
        player.experience = player.experience - (player.level * 100 + 100)
        player.level = player.level + 1
        leveling_function
      }
    ]]>
  </function>

  // damage_modifier_integer_attribute = critical_function (player.luck)

  <function name="critical_function" parameters="luck_integer_attribute_parameter" type="int">
    if (RandomChance (luck_integer_attribute_parameter)) {
      return (2)
    } else {
      return (1)
    }
  </function>

  <!--
  NOTES:

  // blah notes
  -->

  <!--
  To Do List:
  
  // blah to do list
  -->

</library>

I like the folder idea...
V1) folders to separate the rooms
rooms not finished..
Rooms finished
V2) group like rooms together...
World map
House 1
House 2

The problem with using objects as folders is if you already use them for some in-game purpose. Like an NPC who wanders around rooms within his house, or similar.

you can always have a higher (or highest/root) Object be the 'folder' Object(s), containing your 'group' Object(s) (which contain your individual Objects that can be visited/interacted with by the person playing your game) for your in-game functionalities (such as your random npc movement for a house, if I'm guessing right at what you were referencing in your example in your post, or whatever the in-game usage of your 'group' Object might be used for doing)

the nesting/layering can be as deep/high as you want in general (there might be a limit at some point, lol)

example:

the in-game 'city' Objects (Sacramento) would be the visitable/interactable individual Objects by the person playing the game

you have one code functionality upon the 'california' 'group' Object, moving an 'npc' Object random amongst the 'city' individual Objects (I only have Sacramento in my example though) in the 'California' 'group' Object

at some layer of Objects, there's NO (or no/less significant game-playing) code functionality, and thus these Objects with no (or no/less significant game-playing) code functionality, would be your internal organization 'folder' Objects, unlike your 'group' Objects with code functionality (or significant or more significant code functionality) (but are otherwise non-visitable/non-interactable by the person playing your game), and unlike the individual Objects that the person playing the game actually can visit/interact with

existence
-> multiverse 1
->-> universe 1
->->->galaxy cluster 1
->->->-> Milky Way spiral galaxy
->->->->-> "The Sun" (a star near the end of one of the milky way galaxy's tendrils)
->->->->->-> Earth planet
->->->->->->-> North America continent
->->->->->->->-> United States of America country
->->->->->->->->-> California state
->->->->->->->->->-> Sacramento capitol city
->->->->->->->-> Canada country
->->->->->->-> Asia continent
->->->->->->->-> China country
->->->->->-> Mars planet
->->->-> Andromeda spiral galaxy
->->-> galaxy cluster 2
->-> universe 2
-> multiverse 2
non-existence/ "the void"

I like the idea of moving romms into folders.
I allready something similar to hegemonkhans last suggestion.

The problem with that for my current purpose is, that if I have for example Sacramento and San Fransisco.
Then I want those to be in California.
But If I have only finished the descriptions of Sacramento I want San Fransisco to be in an "incompleted items" folder.
And it can't be in both folders at the same time.

But as I tend to finish the California level before I move on to different states, I can keep California in the "incompleted items" folder.
So it does give me some help.

I would still love to do the color coding though.
Or the ability to let an object be in two folders at once for organisational purposes.

Or HEY!
Maybe also for plot purposes.
Maybe some quantum mechanics fun :-D

no, it can't be in two 'folder' Objects (as then you've got two of the same Objects, which can't be done, everything must be unique via its 'name' as its 'ID' String Attribute), though you could have a cloned Object be in the other folder Object, but containment is actually controlled by the built-in 'parent' Object Attribute... so, using the same example:

so, if you forget where an Object goes, you can just look at its 'parent' Object Attribute, and technically, you don't even have to move (cut and paste) it over to the 'california' Object, as that's what the 'parent' Object Attribute already does, though yes you would move (cut and paste) it over, as for your own continued work on your game and its organization for yourself, of course.

(when you nest Objects within the code, it knows the Object's parent is the Object you nested it within, and thus it doesn't show the 'parent' Object Attribute, but it's there (created), as it's the 'parent' Object Attribute, which actually controls the containment/parent-child/location structure/heirarchy of your Objects)

<object name="completed">
  <object name="california">
    <object name="sacramento">
    </object>
  </object>
</object>

<object name="incompleted">
  <object name="san_francisco">
    <attr name="parent" type="object">california</attr>
  </object>
</object>

and of course... once you're done with 'san_francisco' Object, you'd move (cut and paste) it over to within your 'california' Object

if the above wasn't clear... hopefully this will make it clear:

This:

<object name="room">
</object>

<object name="player">
  <attr name="parent" type="object">room</attr>
</object>

is functionally (code/game running-wise) the exact same as:

<object name="room">
  <object name="player">
  </object>
</object>

@HK

Thanks for the info. Does it mean that a player (at level 0) inside a room (at level 1) can interact with objects at the player's and rooms' levels (levels 0 and 1), but not at the house level (level 2)?

I also remember that a player at level 0 can, of course, interact with other objects at level 0, but not with objects nested within those level 0 objects (at level -1, assuming the level 0 object is not a container).

As an aside, I like your comprehensive "model of everything" analogy -- didn't realize that there might be multiple multiverses (j/k)

Thanks for the info. Does it mean that a player (at level 0) inside a room (at level 1) can interact with objects at the player's and rooms' levels (levels 0 and 1), but not at the house level (level 2)?

Not quite; a player can only reach objects with the same parent as them (so at the same level), and the children of any reachable objects that are containers. In order to move from one room to another, the player is interacting with an exit at the same level as them, not the room itself.

Of course, you can write a script that does things with the room; but then a script can do anything at any level. Things like the "look" command show a description of an object (the room) which the player can't actually reach as far as Quest is concerned.

think of it this way:

you're in a box, so you know you're in a box, and you know of other things that are in the box with you, and also if one of those other things in the box with you, is also a (smaller) box, you can open up that (smaller) box and know of the things inside of it (and on and on), as well

but, you can't know of anything outside of that box, you can't know of another box (or whatever thing) next to your box, and you can't know that the box you're in, is actually within another (bigger) box.

does this make sense?

now, during game play, you can traverse the Objects via:

(1) normally using the 'Exits' you added/coded into your game
and/or
(2) using scripting via changing the value of the 'parent' Object Attribute (or the 'MoveObject' helper Function, which is just doing the changing of the value of the 'parent' Object Attribute for you)

also, coding/scripting wise, you can have interaction/functionality with any Object(s) and any other object(s) of course

but outside-of (withOUT any) scripting/coding... the 'box world' analogy at the top of my post applies, that's how containment/parent-child structure/heirarchy works in programming (and in real life, as shown by my 'box world' analogy)

(or if you want a different analogy: an ant doesn't know it's in ant farm container, with you looking at it, nor would humans know of higher planes and their inhabitants/"gods" if you want a religious/spiritual/fantasy analogy, or some scientific theories, that we humans and our world is also just an "ant farm container" with some higher being looking at us or we're a computer simulation/game and of course we're not aware of it, thinking we're real and in the real world, when we're just a computer simulation/game, the two dimensional doesn't know of the 3 dimensional, the 3 dimensional doesn't know of the 4 dimensional, etc etc etc)

here's another explanation:

HK
-> pants
->-> wallet
->>-> dollar

HK is the root/main/"top" parent of pants, wallet, and dollar
HK is the direct parent of pants
HK is the indirect parent of wallet and dollar

pants is the direct child of HK
pants is the direct parent of wallet
pants is the indirect parent of dollar

wallet is the indirect child of HK
wallet is the direct child of pants
wallet is the direct parent of dollar

dollar is the indirect child of HK and pants
dollar is the direct child of wallet

now, let's manipulate it:

dollar.parent = null (technically/underneath its the 'asl' GAME OBJECT, the ROOT OBJECT containing your entire game: your game's contents/code)

wallet.parent = dollar

pants.parent = wallet

HK.parent = pants

creating this new containment/parent-child structure/heirarchy:

dollar
-> wallet
->-> pants
->->-> HK

let's manipulate it (continuing-on-with/using the new structure/heirarchy) again....

HK.parent = wallet

creating this new containment/parent-child structure/heirarchy:

dollar
-> wallet
->-> pants
->-> HK

let's manipulate it (continuing-on-with/using the new structure/heirarchy) again....

dollar.parent = pants
wallet.parent = null

creating this new containment/parent-child structure/heirarchy:

wallet
-> pants
->-> dollar
-> HK

I think you get the idea now...

this is also how the internet works (same "tree" heirarchy/structure as described in my previous post):

https://docs.oracle.com/cd/E19683-01/817-4843/dnsintro-70/index.html

(and recursion is used to traverse/check to get to your desired destination and back to your computer)

quick search for it... and it does show/explain it... might not be the best resource, but it works... lol

the "tree" diagram shows the structure/heirarchy much better:

https://en.wikipedia.org/wiki/Tree_(data_structure)

(see the little picture on the right side)

another link of some tree structures:

https://en.wikipedia.org/wiki/Tree_structure

Ok, thanks guys

One way to do that would be to turn annotations on on the Features tab of the game object, then on the Notes tab, list everything outstanding, under the heading "TODO". In the start script of the game, check for any object that has a TODO list:

foreach (o, AllObjects()) {
  if (Instr(o.implementation_notes, "TODO") > 0) {
    msg ("TODO: " + o.name)
  }
}

Every time you play your game you will get a list of rooms that have work outstanding.

Every time you play your game you will get a list of rooms that have work outstanding.

That's really handy! Thanks man!

On another note: I second the use of colours on rooms/objects. Would really make things easier!

On a third note: One thing (pretty much the only thing to be honest) I've really missed is the possibility to right click on a room (in dev mode, desktop) and choosing "move player here". to move the player object into the room you just rightclicked.