Inside Erin: The AIF Community Newsletter Volume 4 Number 8 - August 2008 A Letter from the Editor -- Purple Dragon Welcome to the Crossworlds special edition of Inside Erin. Well, maybe that's putting things a bit too strongly but you will find a lot about that series here this month. I didn't originally plan it this way but here is what happened. A couple of months ago I got an idea for an In the Hot Seat interview with the Crossworlds gals. It didn't happen right away but we have it for you this month. Talking to the girls got me thinking about those games and I decided to brush them off and take another look. I started at the beginning with CW0 and realized that it had never been reviewed so I thought I would remedy that situation. I had forgotten just how hot that final scene is. Certainly, I thought to myself, it is good enough to constitute a Great Moment in AIF, so I added that as well. So, as it turns out, we have Programming Erin this month as well as the Threesome Competition rules, but other than that, we're Normville bound. I think you'll find it a delightful place to visit and I hope you join me for the trip. * * * This Month in AIF by BBBen After the (eventual) success of the mini-comp (congrats to Dudemandude, by the way - the first 'new author' to win a mini-comp so far) I was inspired to suggest a new type of comp/mini-comp to the community: a threesome comp. I solicited opinions, weighed up ideas and eventually wrote up a list of rules for the comp, which I have decided to host. It will not be a replacement for the mini-comp, it will be in addition to the next mini-comp, running in a different part of the year (the deadline is the end of January 2009). Full details are provided elsewhere in the newsletter. No one should be able to claim they don't have enough time to complete a game, as the deadline is a long way away for the relatively smallish games I expect to be entered. I hope this sparks a few author's or potential author's interests. In other news, Dudemandude has released a public beta of an AIF extension for Inform 7, available here: http://www.mediafire.com/?bqblom9xwln and there has also been other activity to do with AIF coding on Inform 7 at: http://groups.yahoo.com/group/inform7aif/ I must personally admit that I haven't the foggiest idea what any of this Inform 7 stuff is about, but if you are interested, check out those links or the discussions on the AIF Archive. In more layman-ish news, Burnout, writer of A Goblin's Life has begun a 'live AIF' project (in which the players give commands and he writes the responses directly for those commands) on AIFGames.com in the "Live AIF" forum. It is called A Goblin's Life 1.5, and follows from one of the potential endings of the original game. Also, there has been some interest in the "Top AIF" group that was created a while back, with thehomedespot wanting to update the group again, and with Choices soliciting opinions on the best games and authors of the past 5 years. That's all for this month. Go and look at the rules for the threesome comp and if they stimulate your imagination, remember that you have more than enough time to get a game designed, even if you happen to leave it a few months before you get started! * * * BBBen's 2008 AIF Threesome Competition Submission deadline: 31st of January, 2009. All entries must be submitted to: BBBen DOT aif AT gmail DOT com (Note, the address above is written to foil spam. Please replace the "DOT"s with . and the "AT" with @) Rules in brief: 1 PC, 2 sexual NPCs, 1 non-sexual NPC, 5 rooms, 300kb of multimedia, and only one room may have a threesome. The pitch: This is a unique comp that gives authors the opportunity to design a small game with a threesome in a mini-comp style competition. The mini-comp restrictions have only been loosened a little to make sure that comp entries remain a manageable size and that the comp is friendly to new authors. The changes do, however, allow the opportunity to explore something fundamentally different from what the mini-comp usually offers - threesome sex! Rules in detail: Characters: 1 PC, 2 sexually interactive NPCs, and 1 non-sexual NPC are permitted. Less characters than this is acceptable (in particular the non-sexual NPC is optional), but more is not. The non-sexual NPC may never be involved in interactive OR non-interactive sex. Perspective shifting (say, changing the PC to NPC A) is permitted, but the sexually interactive characters must remain the same. Room limit: 5 rooms maximum, and less is fine. No 'wardrobe' rooms are acceptable, as these can be incorporated into main rooms easily enough anyway. Five rooms is five rooms. Other areas may be described in the game, but may not be interactive. Mutlimedia: Multimedia such as pictures and sounds are permitted, provided that the added multimedia does not exceed 300kb on top of the file size of the game. Pictures in-built in RAGS are not counted toward this total. Multimedia must not breach copyright, so only original or public domain pictures and sounds are permitted. And it should go without saying that nothing illegal will be permitted! Originality: The game must be original, with no part of the game having been released before, in any form. Programming code can be re-used from other games, as can settings and characters from other games, provided that text used to describe them is not re-used. Characters from other works of fiction can be used, allowing 'fan-fiction' games, but again original text must be used for them throughout. File size: There is no file size restriction, beyond the restriction on the amount of multimedia permitted. Threesomes: Threesomes are encouraged in this competition, but are not necessary. Remember that threesomes are only allowed in ONE room. The characters, as said above, must always be only the same three, but beyond that the characters are your choice. Any combination of genders is permitted, as well as more... erm... creative options (if you know what I mean). Basically what I'm saying is that M/F/F, M/M/F, F/F/F and M/M/M are all permissible, and if you want to come up with more unusual ideas than just those they are probably permissible too, provided there are only ever the same three characters. The spirit of the rules: In the event of questions as to whether a game fits the rules of the comp, the situation will be compared more against the 'spirit' of the rules, rather than the letter of the wording. Because of that, the spirit of the rules and the intention of the comp is outlined here. Note that unless the rules are very seriously breached the submitted game will probably still be allowed to enter the comp. The voters will be asked to factor in adherence to the rules in the "concept" category of voting. These rules are very similar to the standard AIF mini-comp rules, and though the loosening of the restrictions from the normal mini-comp rules potentially opens up a lot of new possibilities, the main intention of this loosening is simply to get roughly mini-comp sized entries with threesomes at the end instead of one- on-one sex scenes. The expansion of the room limit was permitted to allow more storytelling instead of more sex (as more build-up may be necessary for a threesome), and that is why threesomes are limited to ONE room. We don't want to create an expectation of five rooms full of orgies; instead this comp is designed to remain accessible to all authors. That said, different threesome scenes are allowed depending on the player's choices in the game or random factors, etc., provided they are always in the same room with the same characters. Also, one-on-one sex scenes are permitted in the other rooms, though the focus of the comp is on the idea of threesomes. Threesomes are not compulsory though, so these rules could be used to create a game with a number of one-on-one sex scenes with interchanging partners (provided the combinations never breach the "Characters" rules above). ALL restrictions apply to ALL possible 'paths' or 'play-throughs' of the game. Therefore, if it is possible in one play-through to make choice A and as a result have the threesome in room X, OR to make choice B to have the threesome in room Y, even though the two sex scenes cannot be attained in the one play- through, this would be a breach of the rules. You must select one room for threesomes, and any different scenes will still have to be in that room. Also, you are only permitted to have three characters (including, presumably, the PC) involved in sex, no matter how the game pans out. If you choose to take a fourth, non-sexual character, that character can never be involved in sex in this game. Customisation of characters is permitted to a limited extent, but only for more superficial aspects. The player may choose the names of characters (this will most likely apply to the player character, but is permitted with other characters also), and may make some choices about characters' physical attributes, though extensive physical customisation is discouraged. Personality and behavioural customisation is not permissible, unless this is played out through choices in the plot and character development (for example, choosing at the beginning of the game to make Betty a prude or a nymphomaniac would not be permissible, but she could develop in either direction depending on whether she is introduced to sex gradually or abruptly by the player). The rule of thumb is that the character should feel like the same character regardless of the choices made, even if that character does change throughout the course of the game. * * * In the Hot Seat: The AIF Interviews Most of you are familiar with the Crossworlds series, but what you may not know is that the exploits depicted in them are purportedly based on real life events. I tracked down Janey, Lin, and Debbie to get to the bottom of things. Frankly, I was surprised that they were real people at all, but as for the question of whether they actually lived through the amazing events from the games -- well, I'll let you decide that for yourself. IE: Thank you very much for agreeing to sit down with me today. Why don't we start with each of you introducing yourself? Janey: Sure. My name is Janey Jones, Lin is the girl on my right, Lin: Hi. Janey: And on my left- Debbie: I'm Debbie! Winner of the Erin Award for "best female NPC" and all- around babe. Janey: Uh, yeah. We're all eighteen, although the Crossworlds series is set when we were sixteen. We all live together in Normville... um, Lin and I go to Normville University... uh... I think that's about it. Was there anything else you wanted to know? IE: Most people consider the Crossworlds games, to be just a story (although certainly a good one) what is the real story here? Are you actually trying to say that the events in the games really happened? That there are gremlins and fairies living among us? Janey: The games are pretty close to the real thing, I think, although I didn't witness everything that happens in them personally. Lin: Yes, BBBen did a pretty good job of interpreting the accounts we gave him, though if you ask me his take on the whole story was a little bit lecherous. Debbie: (Putting her hands behind her head and puffing out her chest with a self-satisfied smile) I don't blame him. Janey: I grant you, it may seem a little bit remarkable, but if you'd seen what we've seen... anyway, we didn't really expect anyone to believe it. We were happy enough to let it stand as a work of fiction - we just wanted it all properly recorded as a creative work so we could relive the highlights if we wanted to. You know, with my magic powers and everything. IE: Let's assume for the moment that I believe everything in the games. What were your thoughts when you first found yourselves on that plain? Janey: Well, when we first appeared in the field of flowers I thought I'd gone crazy. I was already pretty spooked after getting attacked a minute before, so I wasn't thinking all that straight, but... well, I always kind of had a feeling there was something weird going on that nobody knew about. I guess it all made a weird kind of sense to me when it happened. Debbie: I had no idea what to think, but I'm a go-with-the-flow kind of girl. It was cool, and we had these super powers, so I just decided to have fun with it. Lin: Well, for me it was like an almost instantaneous transformation of my world-view. I've always been pretty rational, but when I found myself teleported into a totally different world it was clear to me that I was dealing with something well beyond my ken. IE: Why do you think you each appeared like you did? Let me see, if memory serves, Janey, you were a sorceress, Debbie was a cleric, and Lin a rogue. Do you think those roles had any special meaning or significance or were they just arbitrary? Debbie: Well, I think mine was obvious. I was a priestess to the goddess of love and fertility - sex, basically - and worshipping sex is really what I'm all about, you know. Janey: Yeah, I get Debbie's powers and I get Lin's, because she's all lithe and graceful, Lin: Oh, thanks! Janey: No prob, it's true. But anyway, I don't really get mine... maybe I had magic because I really am sort of magical? I don't know. I got a cute dress, though, and I could set things on fire with my thoughts, so I'm not complaining. Of course it all made a lot less sense in the science-fiction world, but that whole concept seemed a bit less inspired to me, anyway. IE: You all went through quite a bit in your adventures. What was the hardest thing that you had to do during them? Debbie: Heh, well the hardest thing I had to do was- Lin: Don't make the joke, Debbie, we could all see it coming a mile away. Debbie: I miss the submissive Lin that would do whatever I tell her to. Lin: Yeah, yeah. Anyway, hmm... you know, we were usually pretty up to the task for the stuff the three of us had to do, so I don't really know what the greatest challenge would be... Janey: For me it was definitely using my powers to beat the Great Gremlin. I had no real idea what to do, and that scared the hell out of me. Luckily my friends were there and, well it all came naturally in the end. Debbie: Oh, if it's scariest moments we're talking about, I think the time I was trapped in the TV was pretty scary. Lin: Well, my scariest moment was losing my virginity. Janey: Really? You never said anything! Lin: No, well, I didn't want to disappoint you guys, so I covered at the time. I was pretty nervous, though. Janey: Wow. IE: Even with all everything you were put through, the games still convey a certain amount of lightheartedness at times, as though you were sometimes actually enjoying yourselves. What was your favorite part of the whole thing? Debbie: Yeah, it was actually pretty fun. Probably more so for me, since I didn't really have to take care of the important stuff too much. Let me think... uh, I guess seducing that guard woman, Tabitha, was probably the most fun part for me. I got to be all sultry and sexy and turn a hetro girl's head... put on a show... Lin: I liked the science-fiction world best. Those tentacles I had were really fun, and I was a total badass. Janey: I think for me, the end of the story is my favourite bit. When my boyfriend and I got back together at the end, and I was the Candy Girl, it was sweet, and I knew it was a happily ever after moment. Of course, life's never all that simple, but it was a great time for me. Debbie: Oh, wait, I changed my mind. The orgy - the first time the four of us all had sex together - that was the best part. Best night of my life, I think. Janey: That was a good night. Lin: Yeah. IE: Speaking of orgies, I couldn't help but notice that there was an incredible amount of sex in the games. Was that added for commercial value or are those parts as factual as the rest of the story? What was the purpose of so much sex? Yes, I know what the games said, but I'd like to hear it from you. Debbie: Sex needs a purpose, now? Man, are you a prude or something? I thought this was some kind of porno newsletter! Janey: Erm... it was real sex. I mean, there may be a few more orgasms in the story than in real life, but otherwise... you don't think that's weird, do you? Lin: The sex actually did serve a purpose, guys. I mean, Janey and her mother's powers are fueled by sex. It's the 'act of creation' and is a way for mortals to harness the power that created reality. I think. I'm not really an expert, I'm just going off what I've been told, but that all seems clear enough to me. Debbie: I think it's all a bit confusing, but who cares? Stop looking for justifications for having sex, buddy. IE: So, are your adventures and trials really over or can we expect to see a sequel to the current games out in the future? Lin: It's not like those are the only interesting things that have ever happened to us, but BBBen has said he's not going to document any more of our adventures for us. Apparently he's got "other interested parties" looking to get him to write their stories, so he's not writing about us any more. Debbie: Screw him. There's no way he deserved the "best writing" award. He never listened to any of my suggestions. Lin: You wanted him to give you your own spin-off. Debbie: With vampires! It would have been cool! And dead sexy! That's a pun, you see. Lin: Didn't you stand him up as his date to the Erins one year? Maybe that's the reason he never did it. Debbie: Oh, yeah. I forgot about that. Janey: Um, there's been talk about other stuff getting written about us, but we'll just have to wait and see. Frankly, I'm a little embarrassed having all that stuff out there about us already, so I don't know about any more... IE: Again, thank you for your time. I'm still not quite sure I buy everything in the games as gospel truth, but you are certainly all lovely ladies and I know I'll never look at them quite the same way again. * * * Great Moments in AIF The final scene in Crossworlds 0 (or The Sleepover if you played the original) is one of the best orgy scenes in any game. It is an amazing foursome between the PC and three girls, culminating in the following bit of debauchery that most guys can only dream about (if that). > fuck girls "Lie back on the couch, we're going to take turns on you," Debbie says. She guides you to lie back with one hand and holds your erection with the other. "We are?" Lin asks, "Well, uh, who goes first?" "Lin, honey," Debbie says, getting up on the couch and throws a leg over you, "A general rule - I always come first." Without inserting your dick into her, Debbie strokes her snatch against your erection, which is pressed back down against your stomach. You feel the moisture dampening the underside of your shaft before Debbie raises herself up and pulls your cock into position for you to fuck her. She lowers herself again, and takes your whole length inside. She puts her hands behind her head and starts grinding her hips around in circles, swirling your cock around in her pussy, her big tits swaying. Janey comes up alongside the sofa and leans in to kiss you. Her soft lips passionately meet yours, and she puts a hand on each side of your head to hold you as she kisses you firmly. When she eventually disengages she looks up at Debbie, who has now put her hands on your chest and begun bouncing up and down with gusto. Janey looks back to you, and whispers, "I love you." You consider that you must be on to a pretty good thing with Janey if she loves you just as much when you're fucking her best friend in front of her. "Uh! Uh! I told you!" Debbie cries out, "I come first!" Debbie's pussy juices stream down over your balls as she comes, and she falls forward onto your chest, her tits sandwiching between you. "Mmm," Debbie pulls herself off you, "Your turn, Lin. Get your ass up here." "I'd rather try it like this," Lin says, getting on the floor on all fours and wiggling her behind at you, so you get down off the sofa, kneel behind her and start fucking her doggy style. As you feel Lin's pussy getting wetter and wetter, she lowers her head down right between Janey's legs and starts sucking that cute little pussy. Janey's face contorts with pleasure, her full lips curling up almost in a sneer, and her eyes closing. You interchange while fucking Lin between short, rapid strokes and long, deep strokes, and it drives the girl wild. Soon she can't even keep eating out Janey and she just gives herself up to the sensation, being buffeted almost limply by your motion. With each thrust she is bumped forward a little more, crawling step by step over the top of Janey, until they are lined up face to face, with Janey lying below Lin on the ground. "Oh God!" Lin's voice heralds the arrival of her orgasm, and she falls forward off your cock, slumping onto Janey. Lin pants into Janey's ear and Janey strokes Lin's back gently as she recovers. Debbie comes over and says, "Janey's turn," and gently rolls Lin off Janey. Lin just rolls off as if she were unconscious, but Debbie lies down next to her and kisses her, and Lin's tongue responds. Janey's legs wrap around your hips and, with her eyes half-lidded with lust, she says, "I want to be the one you come inside." She parts her pussy lips with one hand and feels your chest with the other, and you take hold of her hips, guiding your cock, already wet with the juice of two girls inside her dripping snatch. Fucking Debbie and Lin has not left you with a lot of endurance, but Janey herself seems close to orgasm, so both of you start bumping your hips together with enthusiasm, trying to drive yourselves over the edge. You've been pushed so far that every thrust feels like an orgasm, and Janey moans like she feels the same. Her chest heaves and you feel a moment like an explosion, and suddenly the two of you are sharing your climax. Sperm pumps out of you and into Janey, and her hips buck and twitch as her own juices pour out and mix with yours. You hold Janey against you until Debbie says, "Whoa, that looked intense," her voice calling you back to reality. You gently lower Janey to the floor and lie down next to her, reaching out to hold all three girls as best you can. You lie there holding them for a little while, feeling totally spent. * * * Game Reviews Crossworlds: Part 0 - The Girl Next Door A Review by Purple Dragon Game Info: Crossworlds: Part 0 - The Girl Next Door Author: BBBen Release Date: September 2006 Platform: ADRIFT 3.9 Size: 182 KB Content: mfff, ff, fff, light bondage, underage (16 yo) Type: T&AIF Length: Medium Reviewed: August 2008 Extras: Flashbacks with multiple PCs Basic Story Janey Jones has lived next door with her mother since she was a young girl. In the past years, she has grown into a beautiful young lady and when her mother asks you to baby-sit for her and her friends during a sleepover, you find yourself in store for an experience beyond your wildest dreams. Overall Thoughts I normally think that prequels are a bad idea. I've read enough books and seen enough movies that try this tactic and fall flat, that now view all such attempts with more than a little trepidation. However, there are exceptions to every rule and this is it. If you have played Janey's Diary and The Sleepover then this game will be very familiar to you as it incorporates both of those games. If you haven't played those two then don't bother. This one not only has everything that they did, but also a few extras and the effect of having it all together in one game works much better and adds up to much more than the sum of the parts. Puzzles/Game Play If you're looking for a game with a lot of puzzles that make you work for thrills, then this isn't the one for you. The puzzles are of the simple "search and use" type in order to move you from one sex scene to the next. Nothing in the least bit mind-bending here, but what it lacks in puzzles, it more than makes up for in the sex category. As far as game play goes, you play the only guy in the story, but before you can get to the main scene the game has some very pleasant surprises for you. Twice during the game the perspective changes and you find yourself in control of Janey and her mother in two separate scenes. They are both hot, and both add not just sex, but some good background and characterization. Sex The sex is varied and well written. Getting to play as Janey and her mother in two very different types of lesbian scenes provides more variety and titillation than a lot of other games, and that's before you even get to the main scene. The climax (sorry, I couldn't resist) of the game is an orgy between you and the three girls and it is very well implemented. Not only can you try all the normal things with each of the girls, but you can also direct them to play with each other (and themselves), and there are even a couple of commands that get all four of you into the action at the same time. The fact that there are relatively few of these last types is the only thing I can really think of to say bad about the scene, and considering the vast amount of sex here, it's hard for me to say it very seriously. Technical Most things in the games work very well, and I certainly didn't find anything even close to game killing. The rooms aren't very full, mostly just the bare minimums needed. There are also a couple of strange things like having to go out on the front porch to answer the door, rather than just opening it. I also noticed that the descriptions of the girls don't change when they are naked, which is a bit annoying. However, the main reason that I mention these things at all is because I didn't want to say ONLY good things about the game. All the problems are very minor and don't detract at all from the game as a whole. Final Thoughts If you have played the Crossworlds series and haven't gotten around to this one then you really should. The game is extremely hot and stands well on it's own, but the added characterization of all these gals is something that no fan of the series can possibly overlook. The alternate perspective scenes are also something that you don't see much of, and are, in my opinion, worth the price of admission in and of themselves. Overall, it's a great game that you shouldn't miss. Rating: A- * * * Programming Erin Last month we got our game started by creating a room and a few simple objects. This month we will be building on that by creating a couple of more rooms and some objects that may be just a touch more complicated than the ones we made last month. We are still in the very early stages of the game at this point, which means that most of this stuff is pretty easy no matter what language you choose. That will change as we delve deeper in so get used to the basics because most of what follows will build on them. The biggest thing in this month's edition is that we finally get to create our NPC. Creating basic characters isn't much more complicated than creating basic objects so don't expect Erin to be all that exciting at the moment. In the following months we will be doing quite a bit with her and you will get to see just what is involved in creating a character. You might be surprised by just how much work goes into making a good interactive character. Hopefully we will be able to break it down into manageable sections that shouldn't present too many problems for those of you trying to follow along. And now, on with the show. TADS 3 Segment by Knight Errant This month in Programming Erin, we'll be adding a couple more rooms, a few more objects, and the part you've all been waiting for ... the NPC! NPCs are obviously the most complex part of any game and how to implement them depends entirely on what you intend to do with them in your game. This month we'll just be going over the bare-bones essentials. First, let's add another office. The room itself can be created the same way we created the player's office, like so: erinOffice : Room 'Erin\'s Office' "Erin's quite a bit more successful than you, she has a corner office and a larger desk. She even has a window overlooking the park! " ; Note the slash before the apostrophe in "Erin\'s Office". Whenever you use a single quoted string in TADS, an apostrophe would give the compiler the incorrect message that the string terminates early. Thus, we need to use a slash to mark that the apostrophe isn't meant to terminate the string. Obviously, any time we mention an object in the room, we need to implement it in the description. As A. Bomire mentioned last month in his TADS 2 edition, we also need to add all the doodads and features that the player would expect to encounter. Last month we showed you how to add a Surface (the desk), now let's add one to this room. + erinDesk: Surface 'large wood desk' 'Erin\'s desk' "Erin's desk affords her a large working space, and she keeps it neat and tidy. " owner=erin ; All Things can have owners. By setting the owner of an object, it automatically lets us refer to it as "owner's object", and will refer to it as such if we need to clarify a player's command. It also lets us easily check if the player is trying to do something he's not allowed to do ... for example, you could add a check to Wearable to prevent the player from wearing clothes that he doesn't own. Most desks have drawers as well, so let's add one to the desk. Drawers aren't supposed to be removed from the desk, so it should be a Component. You can also put things in them, which makes them a Container. Since drawers open and close as well, the appropriate class is OpenableContainer. If we wanted to make it a locking drawer for a puzzle, we change OpenableContainer to LockableContainer or KeyedContainer (if you want to require a key to unlock it). For now, leave it as Openable. ++ leftDrawer: OpenableContainer, Component 'left drawer' 'left drawer' "It's the desk's left drawer. " ; You can add a right drawer the same way if you like. Now, if the player types "open desk", we can probably assume that he wants to open the drawer. To handle this, we need to modify the default way the desk responds to an Open command. To do that, we use a macro called dobjFor. If we just have one drawer, we can assume the player wants to open that drawer, and we can add the following to the desk. dobjFor(Open) remapTo(Open, leftDrawer) What this means is that if erinDesk is the Direct Object for the Open command, then the command should be changed into an open command for the drawer. If there's more than one drawer on the other hand, we need to tell the player to be more specific. If you added more than one drawer, add this instead: dobjFor(Open) { verify(){logical;} action() {"You need to specify which drawer you want to open. ";} } Now we're getting into some interesting details of how TADS 3 handles actions. When the player types an action, there are a wide range of checks that occur in order to make sure everything that needs to be checked is checked. The Verify phase is a series of checks to try and figure out what the player meant. Normally Surfaces can't be opened, so the library defines that action as Illogical, with the appropriate error message. We need to redefined that as Logical in this case, because it's something that would actually make sense for the player to do. Then, it proceeds along as normal to the Action phase, where we're specifying what the result of the player's action should be. Since we have a desk, we probably should add a chair. This uses the Chair class, like so: +erinChair: Chair 'leather office desk chair' 'Erin\'s chair' "Erin has a leather chair for her desk. It looks very comfortable. " ; It's just as easy to add a desk chair to the player's office, so you can do that as well. Since this is an office, we should probably add a computer too, but now that we've gotten a little more advanced here, we can actually make the computer functional. Instead of defining it as a Thing, we can define it as an OnOffControl, which automatically adds the ability to turn it On or Off. Since we don't want people carrying around her computer, we can also make it an Immovable. Place it right after her desk. ++ erinComputer: OnOffControl, Immovable 'computer' 'Erin\'s computer' "It looks like a nice computer. " isOn = true ; Next, the room mentions a window with a view of the park. If the park was an in-game room with objects in it, TADS 3 has a Window class that would allow the player to LOOK OUT the window and see who was in that room and what objects were left there. For now, let's just make it a Fixture. Fixture 'window' 'window' "From here, you have an excellent view of the park below. " ; If we're not planning on referring to the window in any other part of the code, then we don't even need to give the object a name. The park can be added in using the Distant class, since from here it's too far away to interact with. Like the window, all you need to specify is the vocabulary, an in-game name, and a description for the park, so I'll leave that as an exercise for the reader. Now we have two rooms, but no way to get between them. Let's add a third room: a connecting hallway. hallway: Room 'hallway' 'hallway' "To the south is your office and to the north is Erin's office. The hallway also leads further east to other offices. " south = myOffice north = erinOffice east: FakeConnector {"Everyone else has gone home, all their offices are locked. ";} ; The South and North properties define connections to the other rooms. You'll need to place reciprocal connections on the myOffice room and the erinOffice room in order to get to the hallway from those rooms. East is actually a nested FakeConnector object. Nested objects are useful for keeping all relevant parts of your code together, and it also saves typing. FakeConnector is a class used for establishing "soft boundaries" to the map. It will present an exit on the Exit list in the status bar and as a response to the Exit command, but if the player actually tries to go that way the game will halt the travel with the message we specify. Now we get to the fun part, Erin herself. Here, instead of using the + to define her location, I'm using an @ sign. This allows me to put the Erin object anywhere in my code that I want. Since NPCs are complex creations, it's best to give them their own file. Otherwise, your source code will quickly become difficult to navigate. Here's how we define her: erin: Person 'lovely young coworker erin' 'Erin' @ erinChair "Erin is your lovely coworker. Her slender body and long legs have been the object of many of your fantasies. " isHer = true posture = sitting ; + tits: Component 'tit/tits/breast/breasts' 'tits' "Her perky breasts are about a C-cup. " isPlural = true ; You can define her other body parts the same way I've defined her tits. While you're at it, why not add some body parts to the player too? TADS 3 automatically assumes that the object's owner is the object that contains it, so we don't need to define the owner ourselves. Now we have our object of interest, but so far there's no way to really interact with her. That's ok for now, because this is a game and we should put at least some obstacle in the player's way. Let's have her office door start out locked. First, we need a door, of course. In TADS 3, doors consist of two sides, one side in each room the door connects. hallway: Room 'hallway' 'hallway' "To the south is your office and to the north is Erin's office. The hallway also leads further east to other offices. " south = myOffice north = officeDoor east: FakeConnector {"Everyone else has gone home, all their offices are locked. ";} ; +officeDoor: LockableWithKey, Door 'erin\'s office door' 'Erin\'s door' "This door leads to Erin's office. " keyList=[erinKey] isQualifiedName = true ; otherOffice : Room 'Erin\'s Office' "Erin's quite a bit more successful than you, she has a corner office and a larger desk. She even has a window overlooking the park! " south = officeDoor2 ; +officeDoor2: Lockable, Door -> 'erin\'s office door' 'Erin\'s door' isQualifiedName = true ; Notice that officeDoor is LockableWithKey but officeDoor2 is just Lockable. This means that like most doors, you don't need a key to unlock it from the inside. Also, since we have a door, we need to change the north and south properties of the rooms to point to the door instead of each other, that way when the player tries to travel in that direction, it'll check if the door is open first. If it's closed, TADS 3 will automatically make the PC try to open it. If it's currently locked, then the PC will automatically try and unlock it, if possible. This greatly helps reduce the number of obvious steps the player has to take. Finally, since we have Erin's name in the name of her door, we need to set isQualifiedName = true to tell TADS not to add "the" or "a" when referring to the door. Finally, let's make a key for the door and give it to Erin. Place this object after her body parts. +erinKey: Key 'erin\'s brass office key' 'brass key' "It's a small brass key. " ; Now the game is finally starting to look like a game! There's a little more here, and we can actually interact with some of it. Our NPC still isn't much of a character, but we'll begin to work on that next month. TADS 2 Segment by A. Bomire Ah - finally! Our game will finally have what every player is looking for - the NPC, Erin! Now, how you implement your NPC will depend greatly upon what sort of strategy you are using to write your game. If you are using one of the popular TADS 2 libraries such as those made by NewKid or Sir Gareth, then some of the options for creating an NPC will vary greatly from those that are available if you use the TADS standard NPC. But, there are some that will apply to any game, and those are ones which we will concentrate upon here. Before we create our new character, let's create an office for her to work within. We went over the details of creating an office-type environment in last month's edition, so I'm not going to go into a lot of detail here. Our new office is going to be much like the one we created last month: a desk, a chair, and a computer. In creating Erin's office, we are going to vary it a little bit. In an environment like an office, where every room is very similar to every other room, it is important to provide some variations for the player. This both reflects reality and prevents the player from becoming bored with seeing the same cookie-cutter environment over and over. Okay, let's create her office, which is a room just like the room we've already created. Because it isn't the starting room, we can call it anything we want. Because I am nothing if not creative, I'm going to call it "Erin's Office": ErinsOffice: room sdesc = "Erin's Office" ldesc = "Erin's quite a bit more successful than you, she has a corner office and a larger desk. She even has a window overlooking the park! " ; Along with Erin's office, let's also add a way to get from one office to the other. In our case, it will be a hallway outside of the offices. Hallway: room sdesc = "Hallway" ldesc = "To the south is your office and to the north is Erin's office. The hallway also leads further east to other offices. " ; Okay, that's fine, but now we need to connect these three rooms together. To do so, we create what TADS calls an exit. There are 11 different exits from any room: north, south, east, west, ne (northeast), se (southeast), nw (northwest), sw (southwest), up, down and noexit. Each of them corresponds to the direction in which the player can travel, except for "noexit". Noexit is the exit that is used when the player attempts to go in a direction that is not defined for a room. It provides an opportunity for the author to create a custom message to let the player know that he has chosen an invalid direction. You can define one if you wish, or just use the TADS default of "You can't go that way." To define an exit, you tell TADS which direction you are using, and where that direction leads. So, from the description of our Hallway above, we can see that the player can go north from the player's office into the Hallway, south from Erin's Office into the Hallway, and either north or south from the Hallway into Erin's Office or the player's office, respectively. Let's add those directions to our room definitions: startroom: room sdesc = "Your Office" ldesc = "Your office is fairly small, but it lets you do your job. Most of your coworkers have gone home, so it's pretty quiet. Your computer is on the desk in front of you. " north = Hallway ; ErinsOffice: room sdesc = "Erin's Office" ldesc = "Erin's quite a bit more successful than you, she has a corner office and a larger desk. She even has a window overlooking the park! " south = Hallway ; Hallway: room sdesc = "Hallway" ldesc = "To the south is your office and to the north is Erin's office. The hallway also leads further east to other offices. " north = ErinsOffice south = startroom east = "Everyone else has gone home; all of their offices are locked. " ; Notice that for the Hallway, I have added an exit definition for "east", even though it isn't a valid choice. When the player chooses east, he will see the description I've provided instead of the usual "You can't go that way." This is important, as I've listed east in the hallway's description - I need to both provide for a valid exit and to explain why that exit isn't available to the player at this time. Okay, we've added the rooms and provided a means to travel from room to room - we now need to add in Erin's furniture. To make it simple, we'll make it much like the furniture that is within the player's office. As I said, in a real game I would probably customize it a bit more: Erinsdesk: beditem location = ErinsOffice sdesc = "desk" ldesc = "It's Erin's desk. " noun = 'desk' adjective = 'Erin\'s' ; Erinschair: chairitem location = ErinsOffice sdesc = "chair" ldesc = "It's Erin's chair. " noun = 'chair' adjective = 'Erin\'s' ; Erinscomputer: fixeditem, switchItem location = desk sdesc = "computer" ldesc = { "It's Erin's computer. "; if (self.isActive) "It's currently on. "; else "It's currently off. "; } noun = 'computer' adjective = 'Erin\'s' isActive = nil ; You'll notice that I named all of the furniture using Erin's name. This is an easy technique to both differentiate her desk from your desk, for example, and to still be able to remember the name of her desk. When writing your own game, try to use descriptive names as much as possible while maintaining a pattern that makes it easy to remember later on. In a game with 3 rooms, it is pretty easy to remember all of the objects. In a game with 300 rooms that is much more of a challenge! One more thing we'll need to add - a window. When the player looks through the window, he'll see the park. Because the park will be mentioned, we'll also make it a separate object, but we will prevent the player from manipulating it. You'll see how in a second: ErinsWindow: fixeditem, seethruItem location = ErinsOffice sdesc = "window" ldesc = "From here, you have an excellent view of the park below. " noun = 'window' thrudesc = self.ldesc; ; park: distantItem location = ErinsOffice sdesc = "park" ldesc = ErinsWindow.ldesc noun = 'park' ; We've introduced two new classes here: seethruItem and distantItem. As the names imply, a seethruItem is something which can be seen through, such as a window. A distantItem is something that is too far away to manipulate, but can be seen. The only additional property we need to worry about is the thrudesc property, which is displayed when the player attempts to "look through" a seethruItem. In our case, I've decided that examining the window, looking through the window, or examining the park will all display the same description. In your own game, you can, of course, provide as much and as varied of a description as you like. All of that is simple side dishes, as it were, for the main course - Erin, our NPC. Let's get to her next. An NPC is just another object to TADS - like any other object, it is the properties that define how the object is different from other objects. As such, you create an NPC in the same manner in which you create a desk, a room, a chair, etc. For TADS 2, NPCs are created using the Actor- class: Erin: Actor location = Erinschair sdesc = "Erin" adesc = "Erin" thedesc = "Erin" ldesc = "Erin is your lovely coworker. Her slender body and long legs have been the object of many of your fantasies. " noun = 'Erin' adjective = 'lovely' 'young' 'coworker' isHer = true ; These are just some of the properties you can use to define Erin. You can also customize what is displayed when you enter the room in which Erin resides, which is typically "Erin is here". You can customize how Erin responds when you ask her to do something. Plus many, many others. For the full list, I would suggest checking out the TADS manual. You may also notice that for Erin I have specified the adesc and thedesc properties. If I don't, then TADS will use its default behavior of adding "a" and "the" to Erin's sdesc property, giving you such results as "A Erin is here" and "The Erin doesn't reply". Note: If you are using a popular library such as the one created by NewKid or Sir Gareth, then you most likely create your characters in a different manner. Usually, those libraries have their own defined class used for NPCs. Check the documentation of your library for details. What those libraries will also pre-define for you is the various body parts of your NPCs. Since we are doing things by hand, we'll have to create Erin's body parts ourselves. There are a lot of techniques we could use for this, but the one I'm going to use is to create an item that is carried by Erin. By making it something carried by Erin the body part will move about with her, and the player cannot pick it up or otherwise manipulate the body part. Let's see an example using a typical body part for a female character, her breasts: ErinsTits: fixeditem location = Erin sdesc = "Erin's breasts" adesc = self.sdesc thedesc = self.sdesc ldesc = "Her perky breasts are about a C-cup. " noun = 'breast' 'tit' 'breasts' 'tits' adjective = 'Erin\'s' 'perky' 'c-cup' isThem = true ; By the way, this technique not only works for NPCs, but for the player character as well. So, be sure to define some body parts for your player character too! But, you may need to add some additional code for those objects, as the player will be entitled to pick up, drop, move about, etc. his body parts! (Or, her body parts if you create a female player character.) This is just a basic definition of Erin. We haven't even begun to fill her out yet. We need to look at the rest of her body parts, her clothing, how her description alters as her clothing changes, how she responds to the player talking to her and asking her things, and how she (and her body parts) respond to sexual activity. We'll go over some more of that in the next installment. ADRIFT Segment by BBBen These articles are intended primarily as a comparison of platforms for authors trying to decide what system to use to make a game. I'll make a confession first out: my article this month was very late, and I think the reason (apart from the fact that other things kept getting in the way of my time) was that this stuff is really, really easy in Adrift and it doesn't really engage my brain to explain it all. If that in of itself doesn't give you a good enough idea of how Adrift compares in its complexity to the other systems, however, I do have some actual explanations of how to do stuff in Adrift. Knight Errant has put in extra rooms and objects in his tutorial, but I can't be bothered doing that for mine as I already went into all the details of that last month. It doesn't really get any more complicated than that, so we can move on. Anyway, this month we'll add a character; we'll stick to relatively simple stuff because more complex things are going to require explanations of Adrift's more important features, but simply creating the characters is done mostly with the 'cruise control' elements of the platform. Click on the "add character" button below the menus, and it will bring up a box. Give the character a name, "Erin", then change the gender to "female" with the buttons to the right. The drop down box below the name allows you to set their starting position; let's change that from "hidden" to "Office". The "prefix" and "alias(es)" options are pretty much the same as for objects, so let's skip them and go straight in to create a description. One of the most obvious differences between Adrift and other systems is the way the streamlined Adrift setup doesn't have much accommodation for subtle stripping systems. You can have two different set descriptions (for example, dressed and naked) depending on completed tasks, and that's all that is provided for in this box. With the more advanced ALR file functions you can actually get past this problem and have unlimited variations on the character's descriptions, but that's a lesson for another day. For now, write a clothed description for Erin in the "description" area, and while you're at it, add a naked description in the field below it. We'll need to come back to that later to put a "strip" into the drop down box, but for now let's move on to the tabs. The first tab is "Movement", and you can play with this if you want, but I'm not going to discuss it right now. It's an advanced function, and I personally prefer to override this system and make my own movement commands. You can move characters around with tasks and events pretty easily, and the "movement" controls don't seem to work properly in 3.9. I hear they work fine in 4.0, but I haven't tested that myself just yet. In any case, it's irrelevant to us at the moment. The second tab is titled "Coversation", and we're also going to skip over this one. The thing about the default Adrift conversation system is that it's not all that useful for puzzles. If you're planning puzzles based around things happening when the player asks the right questions, then you'll want to override the standard conversation system because it doesn't have that function. Also, the responses can change once based on a task being completed or not, and you can use ALR files to create more complex options (again, that's a lesson for another day), but basically the built-in conversation system isn't all that flexible. It's also useless for "talk to" conversations and the like, so I don't tend to use it much. Click on "add character" and you've created Erin. It's really easy stuff, and I feel a little silly explaining some of it, but I do think the Programming Erin project is worthwhile so I have to do my part. The lesson to take from my articles to this point are: starting an Adrift game, creating rooms, objects and even characters are all really easy. The next article might just get into the functions of "tasks" in Adrift (not too much harder to understand, but really important), so that's pretty much when the real Adrift articles start. Inform 6 Segment by 'trix OK, matching what's going on in the T3 section, we'll start by adding some new rooms. Object erinOffice "Erin's Office" with description "Erin's quite a bit more successful than you: she has a corner office and a larger desk. She even has a window overlooking the park." has light; Things to notice about this: as I6 strings for output are double-quoted, there is no need to escape apostrophes in them (i.e. you don't have to prefix them with a backslash). Inside the office we put a desk. Object -> erinDesk "desk" with article "Erin's", name 'erin^s' 'large' 'wood' 'wooden' 'desk', description "Erin's desk affords her a large working space, which she keeps neat and tidy." has scenery supporter; A few points of conceivable interest: we give Erin's desk the printed name "desk" and the article "Erin's" so that it will be referred to as "Erin's desk" in the place of "a desk", but still be "the desk" in situations appropriate to a definite article (which is more like natural English than using the fully qualified "Erin's desk" in every situation). The standard I6 library doesn't have a mechanism built in for parsing genitive phrases, so we can't simply set the desk's owner property to Erin and trust everything to parse correctly. Adding 'erin^s' to the array of applicable words for the desk is usually sufficient in this kind of case. The caret character in this case is standing in place of an apostrophe, since dictionary words are single-quoted, so an apostrophe cannot be included in them in code. Adding components in I6 is also a little less straightforward than in T3. The standard (but not the only) way to do it is using add_to_scope, but in this case it's easier just to put the drawer in the room with the desk. Object -> leftDrawer "left drawer" with name 'desk^s' 'left' 'drawer' 'drawers//p', description "It is the desk's left drawer." has openable scenery container; Object -> rightDrawer "right drawer" with name 'desk^s' 'right' 'drawer' 'drawers//p', description "It is the desk's right drawer." has openable scenery container. Note the attributes the drawers have: openable means "can be opened and closed"; container means "can contain objects inside it"; and scenery means "don't go out of your way to mention it, and don't let the player take it anywhere". All of these are appropriate for drawers fixed inside a desk. Intriguingly, the drawers' name arrays contain the curious looking dictionary- word 'drawers//p'. This is the same as including the word 'drawers', but //p means "mark this word as plural". This is the simplest mechanism for getting plural phrases like "take apples" to apply to a load of apples instead of a single apple. If the player tries to open the desk, you can remap or reject her instruction in the following respective ways: Object -> erinDesk with ......... before [; Open: <>; Close: <>; ], .......... Object -> erinDesk with ......... before [; Open, Close: "The desk contains a left drawer and a right drawer. You'll have to be specific."; ], ......... What's going on here is the most common way of writing individual behaviour on an I6 object. If you want new behaviour to come in before the standard behaviour and do something new, use the before property for the object (reassuringly enough, there's also an after property that comes in after the standard behaviour). The << >> notation in the first block means "Call this action and then return true". Returning true in a before property means that the action is complete and the standard behaviour is cut off. The double-quoted string in the second block is an implied print_ret statement. Writing a double-quoted string inside a block, without the word "print" is equivalent to putting print_ret "Whatever text."; which is equivalent to putting print "Whatever text."; return true; This makes I6 code kind of confusing at first if you're trying to follow the path of execution. But wanting to print a string and return true is so common that the implied print_ret is used very frequently, particularly in before routines. Now to add the chair. Object -> erinChair "chair" with article "Erin's", name 'erin^s' 'leather' 'office' 'desk' 'chair', description "Erin has a leather chair for her desk. It looks very comfortable." has scenery enterable supporter; One thing to note in I6 is that it has a fairly simplistic posture model: if you make an enterable supporter, players can stand, sit or lie on it, and the result is that the player will be regarded as "on" the chair. This is another complexity that is regarded as unnecessary in the standard library, but can be added into a game where it's important enough to be worthwhile. (Iffen anyone actually reads these articles and wants to know how, I'll demonstrate.) Adding Erin's computer (put this code right after the desk): Object -> -> erinComputer "computer" with article "Erin's", name 'erin^s' 'pc' 'computer', description "Looks like a nice computer." has static switchable on; Much the same stuff as ever. Attributes: static means "can't be moved"; switchable means "can be switched on and off"; and on means "is switched on at the moment". Now another room, then we'll be able to wander around. Thrills aplenty. Object hallway "Hallway" with description "This is a hallway leading to the east. To the south is your office, and to the north is Erin's." s_to myOffice, n_to erinOffice, e_to "Everyone else has gone home: all their offices are locked." has light; Something to learn here is how to lay out directions in I6. When you provide a s_to property on a room, it means "going south from here leads to the following room", unless you put a string instead of a room, in which case it means "going in this direction results in the following message". To make the map self-consistent you'd put n_to hallway, and s_to hallway, in myOffice. You might also like to put out_to hallway, in those rooms so that the player can simply "go out" of the offices in to the hallway. As in the T3 code (using the @ symbol), you can specify the location of an object explicitly in I6, which is often helpful if it makes your code read simpler. We'll use it to write the Erin NPC. Object Erin "Erin" erinChair with name 'lovely' 'young' 'coworker' 'woman' 'girl' 'erin', description "Erin is your lovely coworker. Her slender body and long legs have been the object of many of your fantasies." has proper animate transparent female; Most of that should be fairly clear, but here's the rundown on the attributes: proper means "has a proper name, so don't prefix it with articles"; animate means "is a person/animal/lively object of some kind"; transparent means "the contents of this object are visible to the player (contents in this case meaning things Erin is wearing, carrying or composed of)"; and female means "is a her, not a him". At some point, assuming we get that far, we'll have to write a class for anatomy, because there's all sorts of unusual behaviour that body parts display, but for the moment I will cobble together a workable bosom for our NPC. Object -> erinBreasts "breasts" with articles "Erin's" "Erin's" "Erin's", name 'breasts' 'breast' 'tit' 'tits' 'erin^s' 'perky', description "Her perky breasts are about a C-cup." before [; Take, Remove: "Those are part of Erin's body."; ], has pluralname scenery; The attribute pluralname means "is a them, not an it". The message in the before routine is so that if the player optimistically tries to "Take Erin's breasts", a fairly appropriate response will be printed. Giving anatomy the attribute scenery gives a hint that anatomy is something ever-present and fixed in place, but that shouldn't be explicitly mentioned as "being here". You can add other anatomy if you're so inclined. If you add any to the player, you need to add a Drop, Insert, Puton: clause to its before property, so the player cannot leave his anatomy somewhere and then wander off without it. Also, anything contained in the player-character will appear in the player's inventory. This is not right for anatomy, and I will explain how to fix it some other time. Now for doors. Doors in I6 are inherently one-sided, but there is a standard technique for writing two-sided doors that work sensibly. This is the code for an ordinary one-sided door: Object -> lameDoor "lame door" with name 'lame' 'one-sided' 'door', description "This is a lame one-sided door.", door_dir n_to, door_to some_room, has scenery openable door; The attribute door means, transparently enough, "This object is a door". The property door_dir means "This is the direction the door leads in"; and door_to means "This is where the player ends up after going through the door". When you go through a one-sided door, you leave the door behind in the previous room. This is how we write a two-sided door: Object -> decentDoor "decent door" with name 'decent' 'two-sided' 'door', description "This is a far superior two-sided door.", door_dir [; if (real_location==southernroom) return n_to; return s_to; ], door_to [; if (real_location==southernroom) return northernroom; return southernroom; ], found_in northernroom southernroom, has scenery openable door; That's about all there is to it. The found_in property specifies an array of rooms where the object exists (this can only be used for non-portable objects). The door_dir and door_to properties are changed into routines that check which side of the door the player is on and return the appropriate direction or destination. The variable real_location always stores the room where the player is. It's safer to use real_location in this case than location, since (for somewhat anachronistic reasons) location is set to the special room thedark when the player is in a dark room, but real_location is always set to the actual room. As a two-sided door is useful in many situations, I'm going to be adventurous and demonstrate how to write a class. You can put into a class a set of behaviours that you want several objects to provide, but you don't want to write the same properties and attributes over and over. Class TwoDoor with loc_one 0, loc_two 0, dir_one 0, dir_two 0, door_dir [; if (real_location == self.loc_one) return self.dir_one; return self.dir_two; ], door_to [; if (real_location == self.loc_one) return self.loc_two; return self.loc_one; ], found_in [; return (real_location == self.loc_one || real_location == self.loc_two); ], has static door; This is more-or-less the class that I would use for double-sided doors in an I6 game. The class specifies properties loc_one and _two, and dir_one and _two, which need to be set for any object that is using the TwoDoor class. Notice how the properties are accessed using self.propertyname . The keyword self allows the programmer to refer to whichever specific instance of a TwoDoor is being worked on. (It's the I6 equivalent of putting *this in C++-like languages.) Now we can write a double-sided door into our game like this: TwoDoor erinOfficeDoor "Erin's door" with name 'erin^s' 'office' 'door', loc_one hallway, loc_two erinOffice, dir_one n_to, dir_two s_to, has scenery openable; You'll also need to change the hallway and erinOffice definitions so they have n_to erinOfficeDoor and s_to erinOfficeDoor respectively. To make the door (or any openable thing) locked, you can give it the attribute locked. To make it so it can be locked and unlocked with a key, give it the attribute lockable and the property with_key. TwoDoor erinOfficeDoor "Erin's door" with name 'erin^s' 'office' 'door', loc_one hallway, loc_two erinOffice, dir_one n_to, dir_two s_to, with_key erinKey, has scenery openable lockable locked; For this to compile, you'll need to put the object erinKey in the game, so put this definition in the appropriate place (notice me flattering my audience to have absorbed all my prior instructions about the order of object declarations in code): Object -> erinKey "brass key" with name 'brass' 'key' 'erin^s' 'keys//p', description "It's a small brass key." ; Notice here that I've put 'keys//p' in the name array: in the not unlikely circumstance that more keys are added to the game later, we would certainly want the player to refer to them collectively as "keys". It's a common annoyance in IF that logical plurals are not included, so it's worth getting into the habit of considering plural dictionary words for each object you define. (/preachy) I don't know what we're covering next month, but there's a good chance it will involve developing the NPC and the anatomy a bit, which means I'll have to stop dodging the difficult stuff and write some meaty parsing routines, so we can all look forward to that. Inform 7 Segment by Purple Dragon We have our very basic office set up but as of yet, there is nowhere to go. So let's start out by creating a couple of extra rooms. We can set up Erin's office pretty much the same way that we did the player's like so: Erin's Office is a room. "Erin's quite a bit more successful than you, she has a corner office and a larger desk. She even has a window overlooking the park!" And since it would be unusual for one office to lead directly to another, let's also put in a hallway between them. Hallway is north of your office. The description of hallway is "To the south is your office and to the north is Erin's office. The hallway also leads further east to other offices." Hallway is south of Erin's office. Instead of going east in Hallway, say "Everyone else has gone home, all their offices are locked." There are just a couple of things to notice here. The first is that we didn't explicitly say that "Hallway" is a room, but Inform will nonetheless understand it to be one. The reason is that we have said that it is north of "Your Office." The only two things that can be talked about as being in a certain direction from a room are a door or another room. Since we didn't say that "Hallway" is a door, Inform will assume that it is a room. Also note that when you say that "hallway is north of your office" Inform will automatically assume that the inverse is also true, which saves us also having to write, "your office is south of hallway." I put the directions between the hallway and Erin's office on a separate line here but you can actually combine them if you wish. I could just as easily have written, "Hallway is north of your office and south of Erin's office." The reason I didn't do it that way will become clear later on. I also added a message for if the player tries to go east in the hallway. This kind of "soft boundary" is a good way to give your map the appearance of being larger than it actually is and helps the world to feel more complete. Be careful of the wording here. If I had said, "Instead of going east FROM Hallway" the player would never have seen the message. The reason is that using the word "From" means that there is a room in that direction that we just want to keep the player out of (perhaps until they solve a puzzle to get past it). Since there isn't anything to the east of the Hallway, that message would never be reached. So now we have a way to get to her office but obviously, there is nothing to see there at the moment. Let's add some objects and see if we can make her office a bit more interesting than we did the PC's last month. Erin's desk is a supporter in Erin's office with description "Erin's desk affords her a large working space, and she keeps it neat and tidy." It is scenery. The left drawer is part of Erin's desk. It is a closed, openable container. The description is "It's the desk's left drawer." Before opening Erin's desk, try opening the left drawer instead. Before closing Erin's desk, try closing the left drawer instead. Erin's Chair is an enterable supporter in Erin's Office. The description is "Erin has a leather chair for her desk. It looks very comfortable." Erin's Computer is a device on Erin's desk with description "It looks like a nice computer." It is fixed in place. The window is scenery in Erin's office with description "From here, you have an excellent view of the park below." Understand "park" as the window. We have actually accomplished quite a bit with the 140 words above. We have created five objects and provided some special handling for a couple of them, but some parts may require a bit of explanation. The Desk -- Nothing new here, this is pretty much exactly the way we created the other desk last month. The Drawer -- Desks have drawers right? If the player sees a desk, he is going to expect it to have one so if it doesn't, you better explain why not. There are a couple of things to notice about the way we created the drawer. First, we made it part of Erin's desk. This has the effect of attaching it to the desk so that if the desk were ever moved for some reason, the drawer would automatically move with it. When something is "part" of something else, it is part of it forever. The drawer cannot be removed from the desk, but 99 times out of 100 you would never want it to be removed anyway. You would, however, want it to be able to be opened and closed, which is what the next line does. "It is a closed, openable container" gives Inform quite a bit of information about how we want the drawer to behave. Without this sentence, Inform will still create something called "the left drawer" but it won't behave anything like a drawer should. Saying that it is a container makes sure that Inform knows that we want this to be something that the player can put things into. This makes "container" the "kind" for this object. If you remember, last month we said that every object has a kind. In addition to the kind, we also give the drawer two "properties" here. "Openable" means, as you may suspect, that the object can be opened or closed, and "closed" means that it starts out closed rather than open. If the difference between kinds and properties seems a bit confusing, just remember that any object can only have one kind, and it will have that kind forever since the kind of an object can never be changed. On the other hand, an object can have as many properties as you wish and they can be changed at will. In this example, the drawer might sometimes be an open container, and sometimes a closed container, but it will always be a container. One final thing about the drawer/desk. Especially since there is only one drawer in the desk, players may very well try typing "open desk" instead of "open drawer." That is a pretty easy thing to allow and it is what the last two sentences under the drawer above do. If there were more than one drawer then you would probably want to change this, maybe to give the player a message saying to choose one drawer to open at a time. The Chair -- The chair is a supporter like the desk, but since we want the player (or other characters) to be able to sit on it, we also say that it is "enterable." This allows the chair to support, not only other objects, but the people in the game as well. The Computer -- The computer we made last week was simply of the "thing" class, which will allow the player to examine it, but otherwise it will not act much like a computer. For Erin's computer we use another of the (relatively few) kinds built into Inform and make it a "device." This kind is usually used for mechanical or electronic objects that can be turned on and off. As a result, if you add this and try "turn on computer" in Erin's office, the game will inform you of your success. Of course, at the moment, nothing else happens, but it does give us an easy way to handle and track the state of the computer when we do want to make something more interesting happen. We also say that the computer is "fixed in place." Since this is a desktop computer and not a laptop it would be a bit strange to be able to pick it up and carry it around. I'll pause here a moment to mention something that you may want to keep an eye on. The default response that the player will get when he tries to take something that is fixed in place is, "That's fixed in place." Ok, so that is exactly what we told Inform, but it is at least a bit boring, and at times, downright inaccurate. If you ever want to override a specific default response like this it is easy to do. Instead of taking Erin's computer, say "That would be awfully awkward to carry around with you, and besides, if you unplug it, it won't work anyway." The Window -- Here we make the window a simple scenery object, which means that the player will be able to examine it but, under normal circumstances, nothing else. I also added "park" as a synonym so that the player will get the same message if he tries to look at it. And that gives us a little something to start with in Erin's office. Sure there are other things we could do, but it's a good start and certainly better than the player's office we did last week. And now it is time to introduce the object of our affections, it is time to start programming Erin herself. Erin is a woman on Erin's chair. The description of Erin is "Erin is your lovely coworker. Her slender body and long legs have been the object of many of your fantasies." Erin's tits are part of Erin. The description is "Her perky breasts are about a C-cup." Programming people is really not much different that programming any other objects. At least, the basics aren't much different. Once we get to things like movement, conversation, interaction, clothing, and oh yes, sex, you will find that they are quite a bit more complicated. But for now, we basically just create her the same way we did the other objects in her office. We call her a woman (her kind) to insure that Inform will use the correct pronouns and start her out on her chair, which Inform will allow since we made it an enterable supporter. If we hadn't, we would get an error here. Look at the way we created her tits. Does that look familiar? Yep, that's the same way we programmed the desk drawer. In practice, there are shortcuts you can take when creating body parts (especially if you have more than one girl in your game) but the above will work just fine and other body parts (hers or the PC's) can be created in the same way. A good game will usually have obstacles between the player and the goal of the game so let's start by giving Erin's office a door. Obviously, there are doors between most pairs of rooms that we pass through, but usually they are not even mentioned since it would be extremely annoying to have to open every door before walking through. However, in certain cases we might want one so here is how to do it. Remember that I said it would become clear why I separated the directions between the hallway and Erin's office. The reason I did it that way is because we now need to get rid of that whole line so that we can add a door between them. So, first we delete the following line from our code. Hallway is south of Erin's office. And then add in the door. Erin's door is a door. Erin's door is north of Hallway and south of Erin's office. The description is "This door leads to Erin's office." It is lockable and locked. The brass key is carried by Erin. The description is "It's a small brass key." The brass key unlocks Erin's door. First of all, it may seem a bit redundant to say something like "Erin's door is a door." but it really isn't. Remember that Inform does not really understand English, so it has no idea that an item called "Erin's door" is actually a door unless we say so. If we had left off that line and just wrote the rest then Inform would actually have created a new room called "Erin's door" between Erin's office and the hallway. Since there is little point (that I can think of) to put in an actual door unless you intend to lock it, we do that here. "Lockable" and "locked" are properties just like the ones we put on the container above. Actually, you can use these two on the container as well if you wanted to make it a locked container. Finally, if a door is locked, there should really be a key that will unlock it somewhere in the game. The brass key will do nicely and since it is Erin's door, we'll give it to here for safekeeping. Of course, this means that the key is inside the locked room so we are still going to need some help to get in there. In reality, a person would not really need a key to unlock something like the office door from the inside. Unfortunately, Inform does not have a default way of handling this. I thought about taking you through how to do it here but this is getting a bit long for the month so I think I'll just let you look for yourself if you want to. For anyone interest, Inform goes over this exact scenario in example 23 of the manual, which you can find under the numerical list of examples on the documentation content page. Well, that's enough for this month. We now have our environment coming together just a bit and we have a few things (and one person) to play with. In future months we will develop both of them quite a bit more and take a look at some common (and maybe not so common) things to do in a game and how exactly to make them work. * * * AIF Wants You If you can write game reviews, articles, opinion pieces, humorous essays, or endless blather, we want you. Contact the Editor for suggested content or just write what you want and send it to us. Submitting your work to Inside Erin: Please direct all comments, articles, reviews, discussion and art to the Editor at aifsubmissions@gmail.com. * * * Staff Editor: Purple Dragon has written six AIF games including Archie's Birthday - Chapter 1: Reggie's Gift, A Dream Come True, and Time in the Dark. He has received one Erin award and been nominated for several others. Webmaster: Darc Nite is an avid gamer who heard the call for help with the AIF Newsletter. Staff: A Bomire is the author of several TADS AIF games, including Dexter Dixon: In Search of the Prussian Pussy, Tomorrow Never Comes and The Backlot. His games have won numerous awards and Erin nominations. He was the co-recipient of the Badman Memorial Lifetime Achievement Award in 2006. A Ninny is an AIF player, author of four AIF games and frequent beta-tester. His Parlour received an Erin for Best "One Night Stand" game in 2004 and his most recent game, HORSE walked away with three Erins at the 2007 awards show. BBBen is an author of a number of Adrift AIF games. His games have received numerous Erin awards and nominations and first place in A. Bomire's 2004 mini- comp. He was also the recipient of the 2007 Badman Memorial Lifetime Achievement Award. Bitterfrost is a longtime IF/AIF player working on his first (and last) game, How I Got Syphilix. Knight Errant is an AIF player who has released two games and is currently working on a couple of others. 'trix has released one game, Casting, which was written in Inform 6, and is sporadically working on another in TADS 3.