These are various notes (reminders, development tips, design decisions) made before, during, and after develpment of Tales / Traveling Swordsman. It a way, it's like a jumbled journal of random Swordsman thoughts. :) ---- 07/24/2006 ---- * You can go any direction from the first room, and it becomes "forward". * You can also go ahead or forward, and the game picks a random direction. * A tip for Hugo programmers: Spend a lot of time on grammar definitions. Important! It can really complicate the game, but if done right, it's worth it. The better the recognized grammar, the more realistic the game will be. ---- 07/25/2006 ---- * I thought of the title for this game, "The Traveling Swordsman", on July 18th 2006, as a twist on the phrase "the traveling salesman." I searched for it on Google.com, just to be sure I wasn't missing some obvious connection to an existing work, and I didn't find much. On July 21st, I added the "Tales of" to the beginning of the title, as I started to think about what kind of game it would be. That's the day I started working on the story and the title and chapter logos. That's when the game began. * Debated with myself about making the swordsman deaf. Didn't want it to be too obvious until the very end, but it worries me that players might think it's just too over-the-top and purposely emotional. More than anything, I just needed a way to justify the swordsman's lack of dialogue. Even though my wife cringed when I told her, I'm going to do it anyway. * Also debated with myself about using the twist ending. I don't want to catch M. Night disease, but it really does fit here. Well, the original concept called for no twist, but deciding on the twist has really helped shape the rest of the game. Has this been done before? I don't mean this kind of twist, but I mean where the whole game turns out to be the result of a kid's imagination? Er... probably. And if so, I bet judges will be quick to point out examples. Well, at least I didn't _knowingly_ copy it. * More debates. Should I release it under my real name, or with an alias, or just anonymously? Graphics are done to show my name in the title, and also no name at all. I find it hard to believe it'll fool anybody at this point, since only Robb Sherwin, Kent Tessman, and myself seem to be writing games in Hugo. My style is very unlike Robb's and nobody would believe Kent has entered the comp again, so who's it really going to confuse? * Oh well. I kind of feel like entering anonymously, but I'll reveal at the end. I can even have the game check the current date, to change the About text and title when it's after the voting deadline. * It's a story about a boy with an active imagination who gets sidetracked and distracted while trying to do what was asked of him by his mother. * When trying to "talk to" somebody, say "they wouldn't be able to undestand you." - player can nod or shake head instead (or use "yes" and "no"). Or maybe remind player that the swordsman is the strong and silent type. * All I can do to resist putting in a "snakes on a plain" joke in prologue, if attempting to search the meadow. But, I will resist the urge. * Transition from chapter to chapter should be described in a more gradual way -- the swordsman went farther, it's later now -- so it "feels" like a separate "tale" even if it really happens pretty soon after the prior. * Yes, Homesdale (where the motherly maiden resides) is actually a twist on "Dale's home." Get it? The swordsman's name is Dale. That's his home. :) I wonder how many people will figure that out before reaching the end? * For that matter, I wonder how many people will figure out the "twist" before reaching the end. There will be clues. * Story.txt contains the original "rough draft" for the story. Details for each chapter will be fleshed out during development. * The original filename was "totts.hex" (the acronym for the game). However, upon realizing that this might clue people into the twist before even getting started (totts as in "tots" as in "kids" or "a kid") I changed it. * To make a convincing swordsman, I really need to implement sword-fighting verbs (even if most of them do the same thing) -- like parry and thrust. * More than that, I should let the swordsman attack as many things (even scenery) as I can, even if no damage is done. For instance, attacking the field would cut a slice in the ground. He could chop a notch in a tree, and so forth. Just to help perpetuate the "swordsman" theme. * I comment my code a *lot*. I guess it could be a benefit to other Hugo authors when/if I release the source later, but primarily it's for me. If in two weeks, two months, or two years I'm trying to fix a bug or change something about the game, it really helps me to be be able to fully know why I did something the way I did it. This has often proved useful. * Even though it's only going to come into play briefly at the end, I want to be sure the conversation between mother and son "makes sense" in sign language. I'll start at http://en.wikipedia.org/wiki/American_sign_language but I doubt it'll tell me everything I need to know. Does ASL have an equivalent of contractions? How loud must a sound be before a deaf person can sense it through auditory means? I know there are different degrees of hearing loss for different people. I just want to stay sensitive to all this when relating the tales of the swordsman, and at the ending. * Oh man, if I interpret literally, it's going to be hard for people to read the conversation. I think I'll interpret generally, and assume that there _are_ signs to convey the same complete thought, even if syntax differs. Also, that would be a lot to throw in at the end. I think if I do anything with actual ASL syntax or usage, I'll work it into the story-proper. It shouldn't be "obvious" though, except at the end when _hopefully_ some players will go "AH! It makes sense now." But yeah, we'll see. * I'm not sure I even want to stress the lack of communication more than I have to, else the story could feel too bitter at the end. I could have the swordsman talk to NPCs and they don't understand him (because he's signing) and maybe even say "whatever NPC watches you for a moment, but doesn't understand what you mean" -- a clue. But I'm not even sure I want to do that. With the exception of the neighbor's granddaughter (and maybe Mrs. Hucklebee herself), the other NPCs aren't real. Okay, maybe the spiders are real (but harmless), but the ghost captain isn't. Oh, and Tyrant is real, but there won't be any _real_ communication going on there. * It would be easier -- and probably add to the semi-surreal feeling I'm after -- if the swordsman says nothing at all. The neighbor woman says Hi, and he imagines a one-sided conversation with her. The girl may or may not say anything. He ends up chasing her home with a stick (why? who knows). But then it's the ghost captain, and finally the tyrant. * If that's how it'll go, then I need some way of conveying this to the player without making it feel unnatural. The player should be able to nod yes or shake no, and possibly point at things. Anything more might break the illusion (for the player *and* for the PC himself). I think I can trap "talk" and "ask" verbs in the swordsman player_character object, without having to muck with the grammar definitions. * Better yet, I can just replace the grammar handling verb routines. Oh wait. I shouldn't, since I don't want to give the same responses if the player tries to "talk" as the motherly maiden at the end (even though nobody is in the same room to talk to). Yeah, I'll just do it at the PC object level. ---- 07/26/2006 ---- * I have implemented so many variations of yes/no that the player is bound to figure it out if they even try a little. You can "say" or "tell" it. You can nod or shake your head. Even "yes" and "no" are verbs. At this point, the grammar _should_ be pretty robust. If I think of others, I'll add them. * We can imply that the player, as the traveling swordsman, intends to use the broadsword for any sword-related actions (cut, stab, and so forth). I won't need to introduce any other cutting or stabbing objects, which might complicate things. That'll make it easier to say "cut X" or "stab Y". * I'm a _little_ worried that some veteran players may be confused when the game doesn't explicitly say which cardinal direction is "forward" and which is "backward" (because wherever the player heads will determine that). It probably won't be a big problem for new players, where "ahead" and "back" will even work, but it might tick off the more experience players. Well, I can see how it goes in beta-testing. Even "go to grass" or "go to object" will work, so if anybody feels stuck, it's really their own fault... * I won't be able to figure out what "score" points to put where, until the game is done (or almost done). I want it to reflect a true percentage of completion, so points are going to come from unlikely places, as long as it's something necessary to advance the game. I'll just have to work out how many "things" have to be done, divide it all up, and maybe give more weight to harder things. That should let the player know % of completion. ---- 07/26/2006 ---- * Assuming the player breezes through the prologue and epilogue (as they should, then each of the three chapters should be be roughly 40 minutes long (to make the game a full two hours). This can be done either with a lot of story and easy/no puzzles, or with a small section containing more difficult puzzles. The difficulty in opting for the latter is that some players may feel stuck too easily, resorting to hints without really needing to (as happend with Distress, where people finished in under an hour but relied heavily on hints). ---- 07/28/2006 ---- * Ah ha! I solved a problem that I also had in last year's IFComp entry. There are times when even though I issue AssignPronoun(obj) due to some prompting in the text (i.e., you cut down the grass and find the pendant, the "it" pronoun ought to be "pendant" instead of "grass"), the parser changes it back automatically. I tracked this down to calling Perform() to get into the routine that calls AssignPronoun(). Perform() will set a "last_object" variable, and the library Parse() routine will assign the pronoun back to whatever this variable is. So, my work-around is to have a "set_pronoun_to" global, and use that _instead_ of AssignPronoun in the routines where I want to change a pronoun. Then, at the bottom of my Main() I check for set_pronoun_to ~= nothing, and then AssignPronoun() there, as well as set "last_object" equal to -1. I have to do it in a global spot like that, because if I just did it in the routine where I wanted to set the pronoun, it's still going to fall through after running the verb routine and set "last_object" before returning control to the system. * As to the twist ending, I'm not quite as worried about it as I was. Yeah, some people will undoubtedly slam me for lack of originality. But, if you don't see it coming, and you reach the end thinking _something_ seems amiss, it could hit just right. I think if people "get it", it'll be fine. ---- 07/29/2006 ---- * It's harder than one might think, changing what's always a given (like the ability to _hear_ things) in a game. I have the old woman sitting in a creaky rocking chair at the two-story farmhouse. Woops! I'll change that. * Also, why did I intend to have the player listen and understand other people, but not be able to talk back? The twist is he's a boy with a big imagination, but I can't really justify saying he's a lip-reader _or_ that he can somehow understand them but they can't understand him. Now, here's the dilemma. I can have it so that none of the characters say _anything_ and that's more likely to be how he'd imagine things, but that means all the info I'd have relayed in dialogue will have to come in other ways. Now, as he's imagining things, it would make sense that he would just _know_ what's going on. He's making it up, after all. But it's probably going to be confusing enough to players as it is. If the game runs long and judges stop before finishing, would it leave people thinking that the game just doesn't make any sense? ---- 07/30/2006 ---- * See, there is a distinction between "You hear nothing" and "She's not making a sound" -- the former being my version, and the latter being the default, which isn't accurate for Tales of the Traveling Swordsman. * There seems to be a fine line between too verbose and not verbose enough. I'm putting different "initial descriptions" for rooms, that change upon re-viewing. I also have the game start in verbose mode. But, the normal long_desc is still pretty lengthy, and it may hide important details if players skim over it. So, should there be a 3rd level of description, which just shows the basics (without the completely blank room description that is common when in terse mode)? Hmm. I'll give it some thought. * Something important in this game -- really, in _any_ game -- is that the rooms be interesting and meaningful. The first two areas (in the prologue) may not be _too_ meaningful, but they should at least be interesting. One failure of interactive fiction is having too many poorly described game locations. ---- 07/30/2006 ---- * I have created an ASCII map for Part 1 (The Widow's Daughter): part1.txt. I may do this for each of the chapters, instead of drafting on paper. * Okay, the gate key is with the broken gate, north of the house. But, how do I call the player's attention to it, so they'll find the key? Hmmm? * I've never used Hugo's "attachable" class before, but I think I need to learn more about it. In Part 1, I know there will be two or three cases where a rope has to be tied to one or more things. It's all simple enough that I could probably code it manually, but if this class will work... ---- 08/02/2006 ---- * Finding the gate key just by looking at the other gate (when you're on the hill) is both difficult to clue and boring. I think I'll provide at least one or two other more interesting ways to find the gate key. It won't matter if the key is "gone" from the other places once it's found. In essence, Dale is making it up as he goes along, and it's just as valid that the key could be found in the barn as it is at the opposite gate. The important thing is that it's not found at the house itself. I want for the player to leave the room and come back, to have a chance at seeing the old woman point south to the orchard. * For properties that have more than one value (like misc 1, 1, 1), I tend to use #1 for the first property, even though it's implied if no number is specified, just to avoid confusion and make the code clearer. * There might be a way for people to get stuck in Part 1. I let players go back to the worn path *if* they dropped the amulet there. There's no reason for them to drop it, but since I already prevent dropping of other stuff, I at least wanted to let them drop that. But, say you drop the amulet, go on and collect other vital stuff, go back to the path, drop the necessary stuff but leave with the amulet, you'll not be able to go back and get it. The easy answer would be to let them go back always, but... that's sort of a cutscene section (prelude to arriving in the Part 1 area). So, we'll see. * Two big questions remain, for Part 1. (A) How should I let the player block the barn's southwest exit, when I don't want to just use another lockable door and I don't want it to be accessible from inside the barn until *after* the girl has gone in from the orchard, and (B) how is the player going to know to give the girl the pendant, at the end? * Okay, three big questions. (C) The wheel to the wagon will be in the cellar under the barn... but... why? There has to be a reason. Okay, maybe there is some kind of machine down there, and it's been hooked up to the machine. Like, maybe a turn-wheel to operate the machine. * Except at the end, when it'll be more obvious, I don't want to make it too clear exactly when the game takes place. Is it set a century ago? Ten centuries ago? Longer? Or is it set in a far distant future, like the Tales of the Dying Earth? Well, only Dale's imagination knows for sure. :) Anyway, I don't want it to seem like a hodge-podge of concepts. Even if I mix things, I want it to be predominately neutral. Not much mention of anything modern, unless absolutely necessary. * The bees in the cellar come from the girl's last name -- "Hucklebee" -- it makes Dale think of "bees" when he hears it, hence it's part of daydream. * The story has to work on two levels. It has to make sense if taken without the epilogue (i.e., there's a reason bees are in the cellar, etc), but it also has to make sense _with_ the epilogue (the bees exist in his imagi- nation because "Hucklebee" makes him think of bees). ---- 08/03/2006 ---- * Ah, the "attachable" handling is pretty slick. I just have to do a little customization when the rope is initially found, since the user must slice it off instead of untying it from the cellar hatch handle. * If players don't figure out to throw an apple at the ladder release inside the barn (to get into the loft), they might spend some time trying to climb the barn to get up to and in the loft windows. I just thought of that. Should this be an alternate solution? Maybe. I guess I could have a ladder on the outside, too. I'll give it some thought. An obvious solution would be to climb the wagon after it's crashed against the barn. Thing is, you have to get the harness from the loft _before_ the wagon can be moved. * How about I *don't* put the harness in the loft? After all, what the heck would it be doing up there? I'll put the harness... well, I don't want to put it in the cabinet behind the barrel, because that's one place to find the gate key. And I don't want to put it in the bin, because that's where the feed is, and the harness and feed are part of the same puzzle. No, we can make this simple. The harness will be just hanging on the barn wall. That'll give the player a clue and a goal. Then, what we need from the loft is just the beam for barring the barn door, and we can get that before _or_ after doing the bit with the bull and the wagon. Yeah. That'll work. ---- 08/04/2006 ---- * A tip for Hugo programmers: Remember that properties don't have to be static. If you want something that's "found_in" a location only in certain conditions, the "found_in" property can return the location *or* the "nothing" var, depending on those conditions. Same thing with any other property, such as door_to or in_to -- maybe it's a shifting gate that randomly sends the player to one of three different places. It even works for properties like parse_rank -- maybe you want to disambiguate in different ways depending on what room the player is in. You can do it! This is something I'm only just now beginning to appreciate and use a lot. * Another tip: Don't make the player do things that could otherwise be implied, unless it's somehow important. For instance, If the player looks in or searches an "openable" container that is not open, Hugo will default by telling them that the container is closed. Instead, trap for DoLookIn and DoSearch in the container.before routine. If the container isn't open, print "(opening it first)", set self.open = true (you could call a Perform on &DoOpen, but then it's going to say "opened" afterwards), and return "false" from the container.before so that the search/look continues on. This goes for unlocking and opening doors too. If you've given the door a key_object, and the player has it in inventory, let them auto-use it whenever they try opening the locked door. Some (fairly) good examples can be seen in the Swordsman source -- part1.hug, for south_gate, barn_door, and to a lesser extent maybe, the storage_bin scenery objects. * Yet another tip: I mentioned before that grammar definitions are important. Don't forgot that! Just as important, though, is that you cover the actions players might try, and redirect to the appropriate verb. For instance, I expect players to "put wheel on wagon" (there are a variety of phrasings). But, what happens if they try to "fix wagon with wheel"? I've created some grammar in newverbs.g (with appropriate "default" code in newverbs.h), so that I can trap for &DoRepair in object and xobject before/after routines. If the player is carrying the wheel, and they try to fix the wagon with it, it's simple to make a call to Perform(&DoPutIn,wheel,wagon). And it works! But that's just one example. If you include enough of this type of thing, and as long as you're careful with the grammar definitions, you can really help avoid the dreaded "guess the verb" or "guess the command" problems. * And another: Get your game beta tested by several people. I try to go for anywhere from six to fifteen people, depending on who all I can rally to the cause. Insist that they run a transcript ("script on") and email it to you afterwards. You might be amazed at the things they don't report as being broken or wrong because they don't know really what to expect from your game. But, when you read through their transcript, things just jump out at you. Plus, it helps you spot where "guess the verb" might be a problem. If it's too outlandish, don't worry. Some people will try crazy stuff. But if it's reasonable, and _especially_ if it shows up in other transcripts from your other beta testers, you probably need to address it. * I'm trying to be realistic with inventory management. The only thing that the player really can't carry is the huge wooden beam (if they have the sack of grain, harness, or wheel). The grain goes over the right shoulder (or "sheath-side") and the harness goes over the left. At least one hand is needed to hold the wheel (unless you drop and drag it by the rope). This _hopefully_ won't be the lame kind of inventory management, but will make things a little more realistic. But, those things will be kept to a minimum. The main thing is that I'm describing "how" player carries things. * I wonder if judges are going to complain that this game "isn't original?" I don't mean just the twist ending in the epilogue, but the whole setting, and puzzle-fest nature of it all. I bet some will, but if so, I think they are probably missing the point. It's meant to be a fun, fairly easy romp. We shouldn't forget that interactive fiction should entertain, even if it tells new stories in a familiar setting. Not every story has to be entirely unique. Well, that's my thinking. We'll see what the IFComp judges think. ---- 08/04/2006 ---- * Oh man, I just thought of something cool. I've been giving thought to doing multiple endings (even though I'm usually not a fan of that myself). That way, people could strive toward getting the "good" ending (the one I have planned all along, where the twist is revealed). But, I didn't want to make it _hard_ to achieve, otherwise most people won't bother. It should be something that some players will just honestly get. But, until now, I had no idea of what players could do differently, to affect the ending. But, now I do. If the player kills _nobody_ they'll get the normal ending. But, if they kill some of the NPCs, they'll get a bad ending (they're taken to prison or something). If they manage to kill _all_ the NPCs, they'll get an evil ending -- no prison, just say that the player lives "evilly ever after." Also, change the "x me" text if the player has killed anyone. * I want to use the word "alacrity" somewhere in the game. That'd be cool. * For the first time in a Hugo game, I'm making using of the "plural_class". It does come in handy when there are multiple things like fences and gates. * I just added a cool but obscure little feature. Search for "answer_object" in the source code. It's now possible for me to ask the player questions like "How do you intend to do that?" and handle responses that are like "with the wheel" or "using the key". Of course, they can just as easily type the entire command too. It _seems_ to work pretty well, and if the player takes another turn instead of answering, then the game will go back to responding "you'll have to be more specific" if they try to use the "with" verb. It requires some globals, a LookForAnswer routine, two lines of code in Main, a new with/using verb definition, and DoAnswerWith handle. ---- 08/05/2006 ---- * I've worked out the idea for the three different endings (white, gray, and black) now, and updated the story.txt to include basic info. I'm a little concerned about it, though. The gray and black endings will cast a dark tone to the earlier parts of the game, and I was really going for something more light-hearted at the end -- the "white" epilogue, where Dale is a kid. I think it's a good idea, though, as long as people don't think they *have* to kill the NPCs. * It will be obvious to not kill the old woman. That will make it unlikely that players will get the black ending, unless they are purposely trying for it. But the daughter... described in a monster-like way... and maybe even the tyrant... that'll be another matter. How am I going to make it so that players are *aware* they have other options, so they don't always end up with the gray ending? I'm partial to the white ending, after all. * Once a player begins on the "gray" path, certain aspects of the game will change. For instance, the text on the parchment will change, telling the swordsmans to *kill* the tyrant, instead of capture him. In fact, to make both the black and the gray endings work, I'll have to require the player to kill the tyrant to complete the game (if they're on the gray path). If they're on the white path until the end, I'll make it so that they aren't even able to kill the tyrant. They're good, and killing him isn't possible. Plus, that way, you couldn't just pick between two endings right at the end (white-gray or gray-black). Yeah, I think that'll work. * What about the ghost captain though? You can't kill a ghost. I've thought about having him be an "albino" in the black ending, and maybe just not mentioning him at all in the gray ending. But we'll see. Okay, in the gray ending, he's an albino cab driver (the "barge" is a taxicab). In the black ending, he's... don't know, some dock worker, or something. * When trying to kill the girl, I could say that the swordsman hesitates. Make it obvious that it'll work if he tries again, but maybe hint that he doesn't have to do it. Well, unless he's already killed the old woman, and then it won't matter. And he won't need to hesitate on the old woman, because that's a conscious decision. No ambiguity there. * Once we start down the "gray" path, there is no need to make things silent. The black and gray endings both call for the swordsman to be silent, but neither require him to be deaf. So, that's another difference. ---- 08/06/2006 ---- * In regards to the multiple endings, I think I should try to get the "white" ending done before I work on the other two. With the deadline approaching, it might just be too ambitious of me to work all the rest of that in. If there is time, I can add those endings and make changes throughout the existing code based on the "gray" path (for instance, being able to go into the house after killing the old woman, to get something that's required if you intend to kill the barge captain). Fortunately, all (or at least most) of the text is in PrintMessage, and a lot of the "changes" that happen when you start down the "gray" path can be done just by altering that text. * If the player does start down the "gray" path (provided I have time to get it done), I should change the water to alcohol in the flask. * In Part 1, you have to chase and trap the girl. That's kind of what I had originally intended for Part 3 (with the tyrant). Instead, it might be more fun to play it stealthy. Hide, sneak, etc. That would also serve to support the gray and/or black alternate endings (if I do end up with them). ---- 08/10/2006 ---- * Progress is good. Still working on Part 1. I think I've solved the problem of being able to prevent the player from going SW from inside the barn _before_ they've been to the orchard, yet still allowing the girl to enter that way from the orchard. And, the idea should allow the player to block the door from outside. So, they're going to have to run the girl in from the west, which isn't what I'd originally planned, because it's the only entrance that is blocked from inside instead of outside. I'm going to put a heavy panel that raises and lowers from outside, using a pully mechanism. The player will have a way to disable it, so the door stays down. * I think the puzzles in the first part are pretty good. Most of it involves trying to _block_ exits (where usually, players have to _open_ new exits). That's pretty original... isn't it? Well, we'll see. ---- 08/14/2006 ---- * I'm behind. I need to finish Part 1 by tomorrow, if I'm going to finish Part 2 by the end of the month, Part 3 by the middle of next month, and still have time for the epilogue and beta testing. I doubt I'll have time to work in the "gray" and "black" endings after all. I still have several more days to work on Part 1. So yeah, I'm behind. * I want the player to encounter the girl in the orchard _before_ releasing the bees from the cellar, otherwise I have to completely change the initial meeting with the girl. Right now, nothing forces the player to do one before the other. Is there a way I can allow the player into the barn but not to open the cellar hatch, before meeting the girl? I don't really want to add another layer of complexity to the puzzles in the Part 1. I guess the easiest thing would be to allow the player to release the bees, but not have them fly to the girl until after the player has met her. * As complicated as this game is becoming (even though it should hopefully be fairly easy, and still fly in under the two hour limit), I might have been able to write the second Convergence Saga game after all. I guess my probably wasn't so much lack of time. I haven't entirely figured out what is going to happen in that game, aside from the premise and basic plot. * Hmmm... am I mentally picturing a scene from "The Ring" or some other horror movie, in my initial description of the girl? I must be. Well, maybe Dale saw that movie too. :) * I need multiple ways to get the girl's attention. We could tap the tree (which is pretty obviously prompted), tap the girl herself... what else? Listed several ways to get her attention, in the Part1.txt file. * Do I need to create an "approach" verb? Would it be the same as "go to?" ---- 08/15/2006 ---- * Initially, the player may think the girl wants the apple, and that upon getting it, it should be given to the girl. So, I'll probably need to account for that. ---- 08/15/2006 ---- * Someone in this game needs to have "esquire" after their name. Heh heh. ---- 08/17/2006 ---- * I should also feature a highwayman in the game, somehow, somewhere. ---- 08/21/2006 ---- * As often as the swordsman will be sheathing and unsheathing his sword automatically, I should come up with lots of different ways of saying it. Otherwise, the text could begin to get really really old after a while. * To stay on schedule, I needed to finish Part 1 by the middle of August, Part 2 by the end of August, Part 3 by the middle of September, the Epilogue by the last week of September, and then all beta testing by the end of September. I'm behind. I still have (possibly) several more days of work to do just on Part 1, and I don't want this to be too short a game by cutting out Part 2 and/or Part 3. I could be in trouble. Argh. * Big progress tonight. Most of the cellar area is implemented now, including some unnecessary interactions with the contraption. The wheel can be retrieved, and pretty much all that's left is to describe the tapestry. This is going to (somehow) describe a pact or agreement made with the tyrant, and it will describe the gift (being able to make the world's greatest cider), the curse (hence the bees and the bee-girl), and the method by which to defeat the girl (giving her the pendant). Exactly how I'm going to describe all that succinctly and rationally, I don't yet know. ---- 08/25/2006 ---- * I'm trying something with this game that I haven't really done before. For some repeatable tasks (such as barring the barn door) where there is a blurb of text associated with the action, I'm only going to describe the action at length the first time. After that, having remembered that the player already saw the long version, I'll print a short version. Hopefully this will help avoid the player's tendencies to skim/skip text. It should also play on the memory of past experiences. If the player reads the action once, then even a short description the second time will hopefully bring up mental images of the first description, without saying it all. * I'm close to done with Part 1 (aside from some clean-up and implementation of extra scenery). It's possible now to do everything necessary to trap the girl in the barn, but three things remain. One, I have to be able to give her the pendant and end the chapter. Two, I have to handle attempts to interact with her, both when she's on the run, and when she's trapped in the barn. Three, I need to give (somehow) more than just the brief clue on the tapestry that giving her the pendant is the right action. * It's safe to say I will not have time to implement the two alternate endings, so I will have to prevent the player from killing the girl. I need to come up with plausable responses for players who try. * How do I (or _can_ I) prevent the player from chasing the girl all over the farm, and thinking it's really a stupid thing that she nevers stops? The trick is to start blocking the barn exits, but if the player doesn't think ahead, it might just seem like she goes on forever. Maybe I need to start giving clues, the more times the player follows her. ---- 08/26/2006 ---- * I originally planned for the player the trap the girl from the inside, by barring the door. But, it's possible to bar the door and the northwest exit while leaving the southwest exit open, leave to the southwest while the girl is still inside, and close it. That traps her inside. When that happens, I'll print a message saying you must confront her to end the curse. But, instead of forcing the player to open the door, go in and let her out, open the barn door, leave and close the southwest exit again, and then chase her back in from the house and re-block the barn door, I'll let the player climb the wagon again, and enter that way. Now, if the player doesn't know you can get in that way, then they'll have to do it the hard way. Of course, some players might get it right to begin with, and lock her in from the inside. But we'll see. I just hope it all works. * Swordsman (188,580 bytes) is now larger, hex-size-wise, then Distress (which is 188,340 bytes). There are still two chapters and an epilogue remaining to be done. It may end up larger even than Trading Punches. * This is a trick other authors probably use, and I'm starting to see why. When you describe something unimportant, a good way of making it clear that it's unimiportant without *saying* that it's unimportant is to not offer any new information. For instance, if the player looks at the girl's dress, I can just restate that the girl is wearing a yellow dress. If I try to describe it (pockets, lace, sleeves, etc), then it just opens up more things the player is going to have to deal with. ---- 08/27/2006 ---- * The widow always knows which room the girl is in, because Dale once saw on TV that parents are supposed to always know where their kids are. :) * I've added the routine for adding score points, and checking to make sure the points weren't already awarded for a given task. Actually, it's not so much "score" as it is "percentage of game completed." I also created a "score.txt" file, to keep the numbering and total points awarded straight. * I have tentatively finished Part 1, including the cutscene leading to Part 2. There are other things I want to do, but at least it's "complete" now. If I finish the rest before the competition, I'll come back and add the extra stuff that I wanted for this chapter. Now... to design Part 2, based on what I have previously written (short description) in "story.txt". ---- 08/28/2006 ---- * It would be nice to re-use elements in each chapter, so that it makes more sense in the end that Dale was taking these things to work into his story. For example, the wagon wheel could also be the wheel at the helm of barge. The netting used to climb up the barge could be same net in the village. The green and brown stone path in the orchard is the same as the stone on the windmill, in part 2. I think a few well-placed things like this will strike the player as odd, but hopefully make sense at the end. ---- 08/30/2006 ---- * Woops! It's a good thing I remembered that all animals in the game have been given the "living" flag. This makes them candidates for the talk, ask, and other verbs. I've now trapped for this with an "animal" class. ---- 08/31/2006 ---- * Most of Part 2 is designed (as part2.txt), although more remains to be determined. I want to have the swordsman free the captain from his own fate (flying the barge, instead of passing on to the afterlife), so I need to work that in as the common theme. Also, I want the sky to grow cloudy through the course of Part 2, so that I can have it raining in Part 3. The beginnings of the first room (the campsite clearing) are underway. ---- 09/05/2006 ---- * No way am I getting this game done in time for IFComp 2006. If I'm to have two weeks to work on Part 3 _and_ a week to do the epilogue and beta testing (which isn't _nearly_ enough), I need to finish Part 2 by this weekend. Spider battle is done (mostly). Raising the rails is done. * There are plenty of ways I could let the Swordsman die in this game. Walking off the side of the barge, getting killed by spiders, bees, or the bull, falling off the trawl net, or whatever. What he's doing is kind of dangerous. But, (1) this year I wanted to enter a game where it's impossible to lose or die, and (2) it turns out he's a kid, so there is no reason to introduce "death" endings into the game. * Speaking of endings, I won't have time for "gray" and "black" endings, as I had thought about earlier. It's just going to be Dale the kid. The End. * It's important that the barge be flying in the right direction (toward the "forward" dir, toward the fishing village), otherwise the Swordsman would lose his way. But, to simplify things at the windmill, I want the barge to face west (putting the windmill off starboard, to the north). My fear, though, is that this change in navigation will confuse players. I am trying to mention which compass direction is aft and fore in all the descriptions, but I may need to do a little more to make it intuitive. ---- 09/06/2006 ---- * Another tip for Hugo programmers. Use the MISC property! It's an easy way to set status flags (as many as you want, as long as you declare default values in the object declaration). You could even alias one or more things to avoid saying object.misc (example: object.was_damaged). For things that apply to just a single object, this makes more sense than creating a whole new property. I use MISC a lot, just for flags and statuses. ---- 09/07/2006 ---- * Interesting. The source code for Trading Punches is about 518k, yet the source code for this game is already up to about 610k. Even so, the .HEX size of TRADING.HEX is 315k, while TALES_TS.HEX is only 252k (so far). * No way will I get this done in time. If I haven't finished Part 2 by the end of the day this coming Sunday (and today is Thursday), I feel I should withdraw from the competition and just finish it as a non-comp game. ---- 09/10/2006 ---- * I have drafted up an initial version of the read_1st.txt file. I almost put some information about the game's design (there is no way to put it in an unwinnable state, and no actions can lead to failure). The former might be okay, but to say the latter might remove any sense of urgency and danger from the game. I think people tend to play games differently when they know that there's no way to mess up, and that detracts a little from the "adventure" of it. At the same time, players might *think* there is a way to mess up, even if they've avoided it. For instance, you can break the mill door's latch with the pipe, or you can pick the lock with the fish bones. If you have the bones but think "wow, this would not have been possible if I missed picking those up", then you may _think_ there is a design flaw, when actually there isn't. I figure I'll address all of that in the extended walkthrough, but in the built-in one, I'll tailor the walkthrough to advice based on what the player _has_ done so far. In other words, if the player missed the bones, it'll give the pipe method. * The furnishings in the captain's quarters appear "unused" because they're exactly that. The captain is a ghost. He hasn't touched any of it a long time (probably months or years). The player only finds out later, though. ---- 09/11/2006 ---- * The number of verbs recognized by this game just keeps on growing. I have now added "prop" and "stand object up/by" as aliases for DoArrange, some verbs for "release" and "unclamp", and last night I added "sleep" verbs. * How stupid can I be??? It's only just now that I'm seeing the obvious connection that people may draw between this story, and Don Quixote? I had better allow "fight windmill" or there'll be hell to pay. It's not a Don Quixote story, though. Well, not really. By the time they reach the windmill, players are probably going to be _convinced_ that's what I'm doing. The Traveling Swordsman. Duh!!! Okay, well, I'll work around it. * Maybe I should claim it was intentional. The "real" swordsman (Dale, the child) is kind of a little Don Quixote, but in a playful, pretend way. If anything, this gives it more of a theme than it otherwise would have. * However, this is likely to elicit a very real complaint. "You, sir, are no Cervantes." Well, I didn't intend to be, so we'll see how it goes. * I wish I had more TIME. It would be cool if "XYZZY" could initiate a treasure hunt. Like, the first clue is "count the grass" (69,105), and this leads to the next clue, etc. Kind of a little side quest that's played out as a treasure hunt. If I don't have time to do that in this game, maybe I'll do it in another game. * I will purposely not use the word "magic" anywhere in the game. There are "enchantments" at times, but at least I avoided magic... except for one bit where you can say "fix me" but that's the only case. * I _really_ want to finish in time for IFComp '06, but I'm worried I won't. To do it, I may need to short-change Part 3 -- either by making it shorter, or by making it simpler or easier. I really wanted to have a richly-implemented game, but even if I finish in time, I think I may make too many mistakes in my rush, and end up with a less-than-great entry. Maybe Part 3 could take place in underground caves, which would require very little extra implementation. I don't know. We'll see. ---- 09/12/2006 ---- * Tales_ts.hex broke the 300,000 byte barrier tonight. At this point, I'm very close to finishing Part 2, aside from dislodging the sail arm, putting it in the starboard slot, and then figuring out the ending. The IFComp deadline was moved up a day, so I have even less time to finish. And, Part 3 hasn't even been scoped and drafted up yet, aside from the basic premise/goal in the story.txt file, from my original notes. ---- 09/13/2006 ---- * Nearly done with Part 2. I just have to describe the captain at the very end part, have him direct the player to mess with the helm, write the ending cutscene, and... that's it. I also have to go back through and clean up any glaring bugs (of which, hopefully, there are few). * If I can put effort into Part 3 (and the epilogue) _and_ get the game tested and polished by the end of the day on the 29th, I think I stand a good chance at making Top-3 this year. I think it's turning out to be a really interesting, imaginative, well-written game. * Of course, I thought the same thing about Trading Punches, which was a great idea and well-conceived story (IMO), but poorly executed. So, we'll see. I also thought Distress (last year) would be a dud, yet it picked up quite a few fans and is generally well-liked. Who knows what 2006 will be. ---- 09/14/2006 ---- * Whew -- Part 2 is done (just going through doing some touch-ups). The current .hex file size is 315,715 bytes, compared to Trading Punches at 315,934 bytes. This is the biggest work of IF I've ever written. * Part 3 is probably going to be shorter than Parts 1 and 2, due to the ever-approaching IFComp deadline. After I add the score points for Part 2 (which should bump it over Trading Punches), I'll need to design Part 3 in a hurry. I may end up redistributing the score points, so that it isn't 5/30/30/30/5. How about 5/35/35/20/5, if Part 3 really is shorter? ---- 09/15/2006 ---- * At what point does a robust implementation become implementation hell? In describing the cargo crates as "nailed shut" I may be prompting the players to reference the nails. I think I'll just add it as extra_scenery. I could make them a component of the crates, but then I have to worry with implementing "pull nails" and a host of other things that may or may not be appropriate to route directly to the crates. And I haven't the time. * I've changed every chapter somewhat (and added much more to it), from what the original "story.txt" concept called for. I think Part 3 will end up being changed more than any of them, because I don't plan to have the player chase Tyrant and set a trap. It'll still involve the net, but probably just to capture him in his chamber (In the Tyrant's Chamber). * I'll use "pier" as a synonym for "wharf" in Part 3, although it's not exactly the same thing. Also, according to wikipedia, "staithe" is used. The legs are wooden pilings (singular "pile"). A tie-in to mast, maybe? ---- 09/16/2006 ---- * What I'm figuring out for Part 3 is going to be a little like Part 1 after all. The player will trap the tyrant in a net, hung from hooks outside the emergency exit of his lair (under the wharf). But, I don't want the player to chase him endlessly, so I would like to make sure the player has everything necessary before getting there. It might take one loop through the area to figure out what the tyrant does, but then hopefully the player will figure out to hang the net from the hooks. I hope so. ---- 09/17/2006 ---- * I have only figured out about half of what needs to happen in Part 3, but the inspiration just isn't coming to me. I have started coding the half that I know, just to keep from wasting the rest of the weekend. ---- 09/18/2006 ---- * I was going to have it so that the tyrant teleports the swordsman back to the village, if not protected by an enchantment. But that's a problem. If he can teleport the swordsman, he could teleport himself (rather than leaving through the panel), and more than that, he could escape the net. So, I'll have to think of something else. Maybe swordsman is forced out. ---- 09/19/2006 ---- * I have added a "tales_ts.ini" containing custom style/color settings, which will be used with Gargoyle (for any players using it). ---- 09/20/2006 ---- * Making progress on Part 3, but I'm really going to be cutting it close. * I wanted certain parts to seem a little surreal and unexpected, but when I think about the premise, that might not be possible. The blurb mentions monsters ("monsters learn to fear you")... I think this is going to clue the player to monsters and magic, even though I wanted the story to feel more down-to-earth until the strange things happen. So, what can I do? Probably nothing. I could think up a new word for "monsters", but most likely players are going to expect unusual things to happen, regardless. In a different setting, a "modern day" setting, it would probably work. * I have changed "monsters" to "scoundrels" in the blurb. That'll work. It might seem a little sillier, but I think it fits in with the theme. ---- 09/22/2006 ---- * Holy cow, it was hard to get "identical_class" working just right, because there are times I trap for actions in an xobject (throw rock at plate) and the library assumes I mean the "rocks" plural class, whether I'm holding any rocks or not. I had to write a routine "GetSingleFromPlural" that will try to see if there are any instances of the object in scope, and assume that instead of the plural version, and then add that to my actor.before routines. I think I've caught all the instances where it can go wrong, but I may have missed something. A better way would probably be to trap for the identical_class anywhere that an object is being tested at the xobject level, but that would take a lot of work now. This fix was really just a patch, and I'll worry about a better solution for the next game, I guess. If I find many more exceptions, though, I may just remove the "identical" nature of the rocks, and let them be three separate, different rocks. * I've given myself a deadline of Sunday night to be completely done with the game (which includes writing the epilogue). I don't see how it's possible, since I still have quite a bit more to do in Part 3. If I can't make that deadline, how will I have time for beta-testing and bug fixes? ---- 09/23/2006 ---- * I think the illusions in the Hall of Tapestries is a pretty cool idea. It gives me an opportunity to put in something different _and_ let the player find the third fist-sized rock _and_ give a clue about watering the saplings. But, how am I going to clue players to touch the tapestries? I need to figure that out, otherwise the whole thing won't even work. ---- 09/24/2006 ---- * This is going to be my greatest game ever! ...Assuming I finish it... * I am so close to figuring out the last bit of Part 3. I just need to solve a problem. The player has to get a speed enchantment from the saplings. This makes it possible not only to run down the tunnel without having to throw something from the other end, but also to avoid the tyrant's magical attack when entering the chamber. But, if the player waters the saplings first and gets the speed enchantment, then the entire pressure-plate puzzle (throwing the pipe or bag of rocks or whatever) is not necessary. What can I do that requires the player to enter the chamber at least one time before getting the speed enchantment? Should the player get something from the encounter that is necessary before watering the saplings? Player already has a flask of water. Maybe we get something from the tyrant and something else from the saplings, and these two things together are used to obtain the enchantment? This would mean some additional implementation, such as a lone cabin to the east of the village. * Okay, here's an idea, if I can make it work. The tyrant attacks with a blast of water. It will fill the player's flask, if it has already been emptied. When the player waters the saplings once, they react, but they need more. You have to fill the flask a second time and water them again. It's only twice, so it shouldn't be retarded like the "cups" puzzle in chapter 1-2 of Trading Punches. I just need to be sure it's clear to the player what's going on every step of the way, otherwise it might be too easy to get lost and confused on what's supposed to happen next. ---- 09/25/2006 ---- * FINALLY. I'm done with Part 3, not counting a little touch-up. I still have to come up with a way of cluing the player to "touch" the tapestries (but other actions, like pulling or pushing or getting will work too). I'll set that aside for now, as I begin on the epilogue. I _have_ to finish the beta version tonight, so I can get it sent out to my testers. Today is Monday. The deadline is Friday. I am nearly out of time. * By way of the epilogue, I want to give this game a real ending. The player actually gets to take a couple of turns, before the game just "ends". This was a problem with my prior games. Unexpected actions bring the game to a sudden halt, and nothing is really resolved. Here, everything will be resolved. If I do it right, players may be left to think back over the story, and wonder what was real and what was imagined. ---- 09/26/2006 ---- * After staying up really late, until around 12:30 AM, I completed the first beta version to send to the dozen or so testers that volunteered from my Lunatix Online game. Two have already provided some revealing transcripts, but both are stuck in the first chapter. They both started out really well, breezing through the epilogue, and figuring out how to get the wheel up to the barn. I see a few minor things to fix. If I can get more of these, and some transcripts that cover the rest of the game, I will be in good shape to release a second beta version later tonight. * I have posted anonymously to the newsgroups, asking for testers. I am kind of skeptical that anybody will reply, but we'll see. I didn't want to say anything about the game (not even that it's written in Hugo), because if there is just one Hugo game (mine), the rest of the community may already assume that the game sucks (the author waited until the last minute to look for beta testers). I don't want to risk there being any biases against my game, before the judging period even starts. ---- 09/27/2006 ---- * Another night of staying up way too late. Too many bugs, and I didn't get a second beta version done. Hopefully I will tonight. Time is running out. * I did get two responses to my newsgroup post, yesterday, so that's two more testers. A third replied today, but I don't have a new beta ready, and I think I'll have enough testers at this point. * I'm amazed at how many bugs there are in the game. Most of it is just stuff I have to handle, like "tie bull to wagon" (instead of tying the rope to each thing individually). Then, there's the problem of players thinking they have to chase the girl around the farm (even though the game gives absolutely no indication that you should do it, and in fact the mere ridiculousness of it should be discouraging enough). How can I keep the whole thing stable at this point, but discourage the player from chasing the girl? I thought that by eventually telling the player (after several turns) that you can only trap her in the barn, that would do the trick. The game actually does handle "trap girl" if she's in the same room. But players were trying to trap her, "make trap" and all sorts of things. They get it figured out eventually, but I can tell they're very frustrated (some testers even comment in the transcripts about how dumb it is having to chase her around). They're not supposed to chase her! They're supposed to figure out that the exits can be blocked. * And then there are bigger bugs, like being able to cut the sail arms off the windmill from down below, without climbing up *or* stopping the arms. That was an easy enough fix, and a disaster if it had made it into the competition version. Good grief, beta testing is essential, no matter how simple your game is, but *especially* in a complicated one such as this. The competition version will have bugs, but hopefully I will have time to fix the most important ones in time. There is no way possible that I can fix everything, even if I take Friday off work (the last day to submit). ---- 09/29/2006 ---- * I'm just wrapping it up. The deadline is in two hours. There are a few miscellaneous things to figure out. Oh, and Bill called to tell me that Monkey Island 2 ends the exact same way. ARGH! It really *IS* cliche! ---- 09/30/2006 ---- * Maybe the other games will be released tonight? * This is by far the biggest "short game" I've ever written. As testing went on and I added synonymous phrasing for various actions and I added more clues and pointers in-game, it became easier and easier. Dan finished in just over two hours, and that was probably at a slower pace with testing. With the inclusion of a walkthrough (which, I suspect, players will use far too often), it will be even shorter. Yet it's packed with detail. Two hours probably won't reveal a fraction of all that makes the game 421k. * Running late last night, I didn't run the Hugo compiler "export" to make a text dump of all dictionary entries. As a result, I missed about ten typos and misspellings, including a double "the" and the word "shakey". Some of it is in obscure areas most players may never find. All in all, that few mistakes isn't anything I need to worry hurting the game in the contest. * So, what response will it get? Positive? Negative? The feeling I got from beta-testing is that the NPCs were a major frustration, although some test- ers did feel that the ending made up for it. Others were lukewarm about the ending, neither wowed nor frustrated by it. Are judges going to "get" it, though? Will they understand the connections between chapters? The story? Will it come across as a little eerie, but generally a fun romp, as I have intended? Even though it's generic pseudo-fantasy, will judges understand that it's _meant_ to be, and that the idea was simply to do such a thing really, really well? Or will it be forgettable, criticized as lacking in originality? I have six weeks to wait until the results and reviews. ---- 10/03/2006 ---- * NOOOO! There is one bug that makes the game unwinnable. It's obscure, but not so obscure that nobody will fall victim to it. I got an email from a player, and he mentioned that the built-in walkthrough in Part 3 mentions putting rocks in a sack, but the rocks are never discovered. It's only supposed to mention finding the rocks (which make up for not having the apple and/or the rusty lock) if you started the chapter without the pipe. The lead pipe is heavy enough by itself. So, what I found was I have left some debugging code, so that when you look at the walkthrough in Part 3, it "unsets" two flags that are supposed to indicate whether or not you started the chapter already carrying the sack and/or the lead pipe. Because it then unsets those flags, the walkthrough always mentions the rocks, whether or not you can really find them in the chapter. Not a big deal, right? The bigger problem is, those same flags are used to determine whether or not you will find the burlap sack in one of the huts (if you left it behind in a prior chapter _and_ you don't have the lead pipe). Again, not a big deal. It will look quirky to "find" the burlap sack you're already carrying, but not harm done. The problem, though, is I anticipated the player putting stuff in the sack in an earlier chapter, then leaving it behind. So, to be sure it's not possible to "bring" stuff into Part 3 that way, I have the game remove everything that might already be contained in the sack object, and then give it to the player. So yeah, if you (a) do not actually have the pipe to get past the pressure plate, (b) put anything in the sack that you need to weigh down the plate (for instance, the lock, apple, or rocks), (c) look at the built-in walkthrough (which unsets those flags), and (d) go into a hut, you'll lose everything you put in the sack, making the last chapter unwinnable. I am so irked and mad at myself. This could kill the game, when judges stumble upon that unwinnable situation. They probably won't even realize that going to the walkthrough caused it to happen. It'll just look like I'm a frikken idiot, and it's an ordinary bug in the game.