Hello everyone. I didn't see a forum dedicated for feature requests / ideas for QuestKit so I'll just post here. Below is a list of my most memorable failures in getting stuff to work in Quest5 as well as things that would help the marginally incompetent people such as myself going forward with QuestKit.
1. Light sources.
In a cave, with a torch, or outdoors with the moon being a "light source", quest5 could handle that okay. What I found I had to do in one of my games was to have the very evil scientist be completely safety minded by making sure that all of the light switches were backlit, so when you entered a dark room of his underground complex, you could actually manipulate the light switch to turn on the light. In a dark room in Quest5, if it's dark, it's dark, and you cannot manipulate things that you cannot see. Think about what you do when walk into a dark room, and gosh golly darn, your bashed your lantern to pieces fending off a grue, so you've no light source. You feel left and right against the inside walls feeling for the light switch. I suppose I could have created a command "feel for light switch" or something and then flipped on a light source in the room that way, but I had lots of dark rooms. Not sure how to handle that case, but I thought I'd bring it up. It would be nice if the light-handling features took care of that, but eh.
2. Weight and volume. This I liked. It was perfect. The only problem I had was that I never figured out through the GUI a way to add up the total weight that the player carried (see item #9 about traversing collections) to be able to say sorry, you're bogged down and can't carry any more. I had no way to weigh a backpack on its own, I had to figure out what was in it, and then iterate through a loop that would have added up all the weights of all the items in the backpack before I could come back and say "that's too heavy for you to lift." Never figured out how to do that via the GUI.
3. Look directions. I see here in the forums (properly: fora) where look directions shall be deprecated in QuestKit. I'm the lonely soul who actually used and liked them (Simutronic's text adventure game Gemstone used them frequently. That was written in TADS). I digress. I read two reasons why the feature was to be deprecated. One, no one used it. I'm going to get a t-shirt printed up with "no one" on it and wear it whenever I write Q5 games from now on. Second, there was the issue of implementation, because the feature was made part of the exits, so developing and implementing exits had an extra layer of complexity. Fair enough. How about views? A completely different thing altogether? Leave exits as exits, and if you want a view, you can have those for a given direction. You can't go east if you are as east as you're going to get on a cliff, supposedly, but you can look east to see the mountains in the distance. I'm going to miss that. Also, in one of my games, The Mysterious Courtyard, which I never finished, the game starts off with the rider having just wrecked a car. I wasn't originally intending for that to happen, but driving the car around meant a scope of room(car(player)). I could do it, but then the tricky part was figuring out where the car was in order to provide the correct view out the window for a given spot along the road. I wanted the driver to be able to see the content on the road that I'd already written for it, so that in or out of the car, it would be same, without having to redo the same description along each spot of the road as the car traversed it. I gave up and just had it start out crashed, where the car wasn't going anywhere. I did successfully implement elevators, with the scope of building(floor(elevator(player))). Was a bit tricky but I managed. You could push the elevator (sorry, British audience, the lift) button up or down and it keep track of the elevator's progress in the building (lots of IF statements, but it worked).
4. Spaces inside of spaces. I like to organize my games into units so that in the tree-view control on the left of the object pane in the editor GUI, I can set up a drill down to start in large spaces and work my way into their littler spaces, rather than having everything organized in a flat hierarchy. For example, a castle is a space, but contains halls, and each hall has floors, and each floor has rooms, etc. By nesting the spaces in this way, I could copy and past an entire floor of a hall, move some rooms around, and save myself all sorts of time. The problem was how the copy/paste worked on the UI. It wasn't very friendly with nesting. It would sometimes get in the right place, but often times, the copied part would be pasted at the bottom of the node, and exists were always a bear to update, but faster than creating a whole floor from scratch.
5. Flammability. I had to create my own object properties and functions for flammability. I created things so that all objects, in their lowest definitions, could be burned, fail to burn, etc., without having to write a script for burning each object. This way, players could get creative in this highly interactive world, and randomly burn things for their amusement. So I had a set of properties -- flammability (0/1), can it even burn at all? Burn tick rate -- how many ticks (player turns) could an object, such as a candle, continue to burn, before it exhausted itself, and finally, how many ticks it had burned already. When burntickcount = burntickrate, the object called the extinguished function.
6. Fragility. Just like flammability, every object had a set of properties for fragility, so that I didn't have to stop and code each script for dropping a particular object, I could just set the object's properties, and the functions for fragility handled the rest. Could the object break? If so, did it break but was still something a player could pick up, or did it shatter, and was gone? All that was implemented. Fewer properties than flammability, but you can imagine, with flammability and fragility on every object, the interactivity went up. I wanted to take this a step further but never did, simply because my math isn't all that great. I wanted players, if they wanted, to be able to take off their boot, throw the boot through a window, thereby breaking the window and allowing the player to make their own exit and continue on. Could have been any nearby object to break the window, I'm just using a boot as an example. The player could just as easily have walked back to the previous room, picked up a chair, and tossed the chair through the window. The goal was to know that the only way out of the dead end room was to break the window, somehow, and to give the player the means to do it however the player wanted. I was so close, but the difficulty was in not knowing how to program the calculation between the likelihood of a given object to break another object. I knew I needed another property, something like a cudgel property -- how well did this thing act as a cudgel for breaking other objects? A piece of paper wadded up isn't going to break a window, etc.
7. Costuming. I had a really nice costuming setup, where the body slots were properties of the player object, and I put the object ID names in the slots. I could create as many body slots as I wanted that way, but life got complicated when I wanted to create layers of clothing. I left it at just one layer, because I didn't want to have to write the code necessary saying that body slot 1 had to be null before you could remove anything from body slot 2 because you can't take off your t-shirt while still wearing your shirt, etc.
8. Creating rooms while in the game. I call this walkthrough editing. The game is running as if playing the game, but in admin mode, so I can be looking around my room and decide that I want to create a room to the east, and then walk into that room and start plopping furniture and environmentals. I suppose I could have created commands that would have allowed me to do that, but walkthrough editing would be very, very cool.
9. Programming the traversal of a collection of objects via the GUI. I loved the idea of animating NPCs the same way that they move around in Simutronic's Gemstone. The rat dashes into the room, sniffs around, and dashes out again before you even have a chance to smack it with your sword, or it'll hesitate in that room, or attack you, etc. All seemed very random. I had in mind, the idea of a pathing zone. Think of my item #4. The spaces that the NPC could wander around in (a rat, for example), would be all the rooms along a given hallway, and the problem I had was not knowing in ASL how to traverse the collection of spaces that were within another space to be able to say okay, move to the next room in that collection of rooms. I did everything through the GUI, and will always do everything through the GUI, so it was getting too complicated to figure out.
Hopefully, this will start a constructive idea session.
