Inside Erin: The AIF Community Newsletter Volume 4 Number 7 - July 2008 A Letter from the Editor - Purple Dragon This month seems to be all about the Mini-comp, but before we get to announcing the winners I thought I would just take a moment to - wait a minute, you've already skipped ahead and peeked haven't you? Dammit, there is a progression here, first you read the letter from the editor, then "This Month in AIF" and THEN you go on to check out the rest of the newsletter. What am I going to do with you people? I guess I can't blame you too much, everyone wants to see if his or her favorite game made the grade. Well, after you take a look at who won what (on page three for those of you who haven't already looked) then we also have a couple of other Mini-comp related articles for you. A. Ninny had a chance to ask a few question of some of the voters this year. I think he found a good group and I was very impressed with the thoughtful answers to his questions. There are also some thoughts about the games and the Mini-comp in general by Softiron and myself. Rather than full reviews of the games, these are just a few comments about each. Be warned, however, that they contain some spoilers and probably shouldn't be read before you have had a chance to play the games (if there is anyone like that still out there). In addition to the Mini-comp stuff, we also have another issue of The Aphrodite Chronicles by A. Ninny and Programming Erin continues this month with a look at how to create basic rooms and objects. We at Inside Erin always welcome feedback on any of the articles or features that we offer. You can e-mail your comments to me or, better yet, as BBBen mentions below, post them on one of the boards so that everyone can get their two cents in. Now, I've kept you long enough. I'm sure a couple of you haven't checked out the winners yet so what are you waiting for? Get to it and I'll see you next month. * * * This Month in AIF by BBBen As expected (or hoped) the mini-comp injected a little life back in the community this month. Now we just need to find some way out of the "feed the beast" mentality that we have and get back to the more free-form creativity we used to have that gave rise to so many games. Having had a month to play the games now, I can say that I'm pretty impressed with the standard. The quality of the games really doesn't reflect the shambolic submission problems. I mentioned the "feed the beast" mentality - I think when we have an institutionalised, formal expectation of regular game releases it kills off writer's interest, but when there's a noticeable lack of games the community can still step up. I'm hoping we can break this attitude somehow. I think getting more chatter on the forums would help, as well as building more of a culture of players giving feedback to authors. Both are initiatives I'm currently pushing, and I entreat everyone who reads this newsletter to go onto the forums on the AIF Archive or AIFGames.com and get some conversations going. Anyway, that's all I've got to say this month. New Games Mini-comp games, released 2nd June 2008: Office Fantasy: The Boss' Wife TADS 2 A. Bomire Your boss is a jerk and is cheating on his wife. When she comes looking for him, how will you and she hit it off. Lusty Lovers Inform Negative Slippy Slide A spoof (actually written by Paul Swift) of crappy AIF games. Get some action with your jailbait sister! Office Fantasy: Working Late TADS 2 A. Bomire Your hot boss has been flirting with you a lot. Can you get rid of your co- worker so you can make some time with your boss? Sexual Awakening ADRIFT 3.9 Tanner V. Chorus A spoof of Vachon's AIF games... that's probably all that needs to be said. A Night With Kes Inform Purple Dragon Xtrek. Set in Star Trek: Voyager, you go to the medbay to get a physical from Kes, only to find strange thoughts in your mind. Winter Break Inform Dudeman While staying at a friend's place you meet his hot sister, and take the opportunity to get to know her a little better. A Lady in Waiting TADS 3 Knight Errant Set in Venice, the independent republic, city of merchants, you seek the attentions of the beautiful Lady Veronica. Bad Day to be a Princess TADS 3 Evil Bob The evil princess Chastity wants you to abduct her rival and sell her to slavery. Will you do it, or will you try and take advantage of the situation? Riding Home ADRIFT 4.0 Raul You, as a blind but capable man, are on a bus headed home, trying to help some friends organise their wedding. Meanwhile, you'll meet some interesting women on the bus. * * * 2008 Mini-comp Results Thank you all for your patience in awaiting the results for this year's Mini- comp and especially, thank you to all the authors who contributed games. Congratulations to this year's winner, Dudeman. Winter Break had good plot, a great sex scene, and with the addition of its innovative 'combo moves' I'm sure it does not come as a surprise that this game was at least toward the top (if not on the top) of most people's lists. The fact that Dudeman is a first time author makes our "Best Game by a First Time Author" category kind of pointless since he obviously won that one too. To all of you who think you don't have a chance to win this thing, note that he beat out three previous authors (four if you count Lusty Lovers), including yours truly (gasp!) to take the number one spot so it is certainly possible. Great job Dudeman and we're all looking forward to more to come. OVERALL 1st Place "Winter Break" 2nd Place "A Lady in Waiting" 3rd Place "Riding Home" 4th Place "Office Fantasy: Working Late" 5th Place "Office Fantasy: The Boss's Wife" 6th Place "A Night with Kes" 7th Place "Bad Day to be a Princess" 8th Place "Lusty Lovers" 9th Place "Sexual Awakening" CONCEPT 1st place "Riding Home" 2nd Place "Winter Break" 3rd Place "A Lady in Waiting" 4th Place "Office Fantasy: Working Late" 5th Place "Office Fantasy: The Boss's Wife" 6th Place "A Night with Kes" 7th Place "Bad Day to be a Princess" 8th Place "Sexual Awakening" 9th Place "Lusty Lovers" WRITING 1st Place "Winter Break" 2nd Place "A Lady in Waiting" 3rd Place "Riding Home" 4th Place "Office Fantasy: Working Late" 5th Place "Office Fantasy: The Boss's Wife" 6th Place "A Night with Kes 7th Place "Bad Day to be a Princess" 8th Place "Sexual Awakening" 9th Place "Lusty Lovers" CHARACTERS 1st Place "A Lady in Waiting" 2nd Place "Winter Break" 3rd Place "Riding Home" 4th Place "Office Fantasy: Working Late" 5th Place "Office Fantasy: The Boss's Wife" 6th Place "A Night with Kes" 7th Place "Bad Day to be a Princess" 8th Place "Lusty Lovers" 9th Place "Sexual Awakening" TECHNICAL 1st Place "Winter Break" 2nd Place "Office Fantasy: Working Late" 3rd Place "Office Fantasy: The Boss's Wife" 4th Place "A Lady in Waiting" 5th Place "Riding Home" 6th Place "A Night with Kes" 7th Place "Bad Day to be a Princess" 8th Place "Lusty Lovers" 9th Place "Sexual Awakening" SEX 1st Place "Winter Break" 2nd Place "A Lady in Waiting" 3rd Place "Office Fantasy: The Boss's Wife" 4th Place "Office Fantasy: Working Late" 5th Place "Riding Home" 6th Place "A Night with Kes" 7th Place "Bad Day to be a Princess" 8th Place "Sexual Awakening" 9th Place "Lusty Lovers" ENJOYMENT 1st Place "Winter Break" 2nd Place "A Lady in Waiting" 3rd Place "Riding Home" 4th Place "Office Fantasy: Working Late" 5th Place "Office Fantasy: The Boss's Wife" 6th Place "A Night with Kes" 7th Place "Bad Day to be a Princess" 8th Place "Sexual Awakening" 9th Place "Lusty Lovers" * * * Erin Street Interviews by A. Ninny Another month of great Mini-comp activity is drawing to a close, but before we put it in our rear-view mirrors once and for all I figured I'd go out on the street and collect some comments from some of you. I appreciate the candor and detail that Xavier Hawk, M. Johnston, DrPepperMD and Craig have brought to their responses to my questions. Without further ado, let's get right to the interviews! A. Ninny: Which games or aspects of the games did you particularly enjoy this year? DrPepperMD: Well, let's see. A. Bomire is of course a wonderful writer, and I enjoy basically everything he does. The combo system of Winter Break was great, and adds a lot of replay value. Riding Home did a great job of coming up with a storyline and protagonist different from what we've seen before, and making a great game around it. A Lady In Waiting was a fine short game. M. Johnston: Winter Break was by far the stand out game for this competition. It was well done, fun to play, and had a new combo system that was innovative. There was a purpose to all 3 rooms, and there was some sort of sex scene in all 3. I liked Lady in Waiting a whole lot. I liked how the separate scenes flowed together, from the party to outside to up in her room. And the puzzle to get up into the balcony was perfectly done. Hard enough that you had to think a little on how the pieces worked together, but not so hard you were stuck there for days trying to figure out what to do. I liked the humor in Lusty Lovers. A droppable cock and windows you can pick up are classic. And the names of the Inform 7 extensions were awesome. I didn't really know what to make of Sexual Awakening. Definitely a parody, but not as humorous as Lusty Lovers. Riding Home's level of detail while on the bus was very well done. I was a little disappointed once home, though. The two Office Fantasy games were pretty well done. I liked how Working Late had a bad, really bad, good, best ending. And I enjoyed how the two games referenced each other. I liked the concept of Bad Day for a Princess a lot. Unfortunately, it was poorly implemented. Xavier Hawk: As always Bomire provided a high standard of coding, detail, sex and puzzles. His use of computers within the game was an interesting method of digging around to achieve your goals. Only let down was I got stuck in a guess the verb situation with working late but apart from that another good showing from what I think is possibly one of the (if not the) most long term games writers within AIF (he even ran one of the first competitions alongside Christopher Cole) . One of the newcomers, Raul, impressed me a lot with his approach. Liked the way that object use and conversation flowed together and provided enough clues as to what to say or do next. All in all he provided a very good 'one action leads to another' scenario which puts him firmly on the list of writers to keep an eye. When it came down to the sex my favorite for this year was Dudeman with Winter Break, shortly followed by A Lady in Waiting by Knight Errant. Especially liked the combo system that Dudeman provided. At this point a special shout out for Purple Dragon whose game title alone brings back memories of the days when x-trek roamed the AIF forums and 'a night with' games were all the rage. Yes we've now arrived at a time where we're ready for retro AIF. Craig: This year I liked: Riding Home, the two Office Fantasies, and Lady in Waiting. All four had differing levels of overall writing quality, but they all kept me reading and interested in what was going to happen next. I felt the writing and programming of Winter Break were excellent, but the story just didn't hold my attention. I also really wanted to like Bad Day to be a Princess, but I got stuck. I liked where the story was going, but I couldn't get there! A. Ninny: When you're differentiating between the top three or four games, what methods do you use to decide what order to rank them? DrPepperMD: It wasn't easy. As I said in my comments, other than the two parody games, they were all worth playing. I think you start by eliminating games that don't have certain minimum requirements (writing, technical ability, sex appeal), and take it from there. I don't really pay attention to what format the game is. I've done some basic programming (never finished anything), and I know that ADRIFT and RAGS are easier to program (and TADS is getting easier with the modules that authors have created), but to the consumer, it doesn't really make a difference. A good game is a good game. M. Johnson: As I played each game, I went through the voting form and gave a rough vote for the game for each category, moving previously played games up or down appropriately. Then when I was finished with all the games, I went through and replayed the ones I thought were close in a category and reordered the voting on the games a little. Xavier Hawk: Several things I look for in a game, so in order: Playability - This ones the biggest factor, to me it's important that any game should be playable from start to end with as few bugs as possible (none is preferable but even the best coders make mistakes from time to time - I work in IT so I know how hard flawless code is too achieve). Guess factor - One of the worst things to happen in a game is to get stuck in the guess the verb scenario. I'm not talking about complicated puzzles which require thought but rather when you get into a position where you know what you have to do but can't for the life of you figure out the actual syntax for the command. Sex scenes - The more interesting and novel the better. The standard rub, suck and fuck is all well and good but the best games that have been posted always go the extra distance. I'm talking toys, ropes, fetishes and extra body parts (beyond just tits, ass and pussy). Novel approach - Past few years we've seen a rise in games which break with the traditional horny guy seeks sex approach. Christopher Cole provided us with excellent code coupled with graphics (he even went so far as to contact an actual internet porn star to obtain images). Lucilla Frost gave one of the best written games I've played along with my favourite approach of casting you as a woman instead of a bloke. Goblin Boy gave us character switching and loads of graphics with his Gifts of Phallius games (3rd one on the way can't wait). It's the writer's who provide new idea's or who excel at an approach who are truly memorable. Score - Not so much for the puzzle solving but for the sex, gives a goal to strive towards and also lets you know that there's still more to this game to discover. Extras - Always find it nice when you finish a game and then the author doles out some extra goodness. Some provide spoilers for alternate methods of play, others give you cheats, a couple have allowed you to replay the game but give writers commentary or alternate points of view. Two that I know of have run completions: GoddoG with Fever Cabin and Lucillia Frost with a contest to find the final point in her game British Fox (which I won and she based her next game on an idea we discussed and if your reading Lucillia thanks again). Craig: I pretty much go with: did I enjoy the story. The more enjoyable the story the higher I will rank it. Having to guess too many verbs, or crazy puzzles tends to turn me off. Finally I look at whether or not I was eager to read the entire prose or if I skimmed. The more I wanted to read, the higher the rating. The adult text is important as well, but if I don't enjoy the story chances are I will quit before getting there. As a further clarification by story I do not just mean the plot. If I have something beyond curiosity about the sex scene to keep me going chances are I will like the game. This could be the plot, the individual character interactions, interesting puzzles, or a combination. A. Ninny: How do you think this year's entries (or the competition as a whole) compare to previous years'? DrPepperMD: I think it very well might be better than previous years. Looking at the 2007 list, the only one I still play regularly is A Goblin's Life. I expect that I will play again the four games I mentioned in the first question. M. Johnston: Unfortunately, I think this year's entries really were poor in comparison to previous years' entries. Last year for instance, the top 6 games were all very, very well done. This year, I think there were only a small handful of games that could compare to those 6. Winter Break being really the only one that was of superior quality, I think. (Better than last year's winner The Second Guest in some ways, in my opinion.) Many games had a rushed feel to them, making it obvious they were crammed into the extension. I liked that you added a new first time author category this year. Although it wasn't always clear if they really were a new author or an old author writing under a new pseudonym. The authors need to be honest about that and let the content organizer know ahead of time if they are eligible. Xavier Hawk: Overall I was very impressed with this years entries, a bug here or there but for the most part some very good coding (well done especially to all the newcomers hope to see you all write some more). Lusty Lovers was a strange one though but by the author's admission he was going for a whole take the piss out of the much older games which contained mass hidden items most of which turned out to be red herrings (god I hate red herrings). This years outing fared well against previous years but I was disappointed that no games came with pictures and no female perspective games. None of which is criticism against what was produced merely just some of what I like in a game. Craig: I felt this year's entries were pretty much the same as in the past, mostly good ones, a few decent ones, and one or two that were less than perfect, to be nice. A. Ninny: What sorts of games would you like to see released in the future (either mini-comp or full-size games)? DrPepperMD: That depends. If we could somehow guarantee the same number of games either way, then sure, I'd love 9 full length games. But I understand that as the length of the game increases, so does its complexity and the amount of work the author puts into it. So if all you can release is a mini-comp game, that's fine. I think most people on the forums would agree that we'll take whatever games we can get. M. Johnston: I like games that push the envelope. Games that try something new, write their own libraries, explore new territory, and innovate. I'm definitely hoping for more from the author of the Winter Break series, Dudeman, in particular. I personally like games that are well written, bug free, and that are innovative. I'd also like to see more "hard-core" or taboo style games. Something like what Sly Dog used to write, but without all the bugs and guess the verb problems. :) Some of the concepts of his games I liked a lot, but they were rarely implemented very well. I'd like to see more of a "sandbox" approach to games; where things aren't so linear. Too often the sex scenes in AIF are kiss girl, rub tits, rub ass, rub pussy, remove shirt, lick tits, remove pants, rub pussy, remove panties, lick pussy, girl suck cock, fuck pussy, end. And you have to do it in that order or they aren't "turned on enough". And if you try to repeat, things don't work. Sure, some games may throw in a fuck tits and fuck ass in there, but it's still very linear. I'd personally like to see things be more free-form. Plus clothing is rarely simulated very well. Clothes are just something that get in the way. I'd prefer games where you can do a lot with the clothes. You should be able to reach into clothes, pull them down, rip them or whatever. Lastly, I also don't like games that tell me what I don't like just as an excuse to not code it. If I ask the girl to put on a strap on and fuck me, don't tell me I'm not into that. I asked her to do it, after all. :-) Xavier Hawk: AIF seems to be evolving at present (which is nice), way back when it started off as fairly poorly written games with rapid sex scenes and a high bug rate. That's grown and grown and we've now come to a point where authors are trying to release bigger and better games and whilst this has happened the players have become spoiled and at times impatient. Since we've come into contact with the better works players have made these the measuring stick for all other games which leaves some a bit wary of releasing games to compete against them. This in turn leaves large chunks of time where nothing new is released (was a time when you got at least one new game a month). I think the competitions provide a good way of letting first time writers showcase their games and for others to release shorter games. After all, if the competition games were released outside of a competition many would say they're not long enough but inside the competition framework they're exactly the right size. I'd say at this point with the dry spells increasing between the large game releases we could probably benefit from adding a second competition to the year. Also with AIF what's been interesting is that it's starting to appear in other places. For those that haven't checked them out yet try: Dating Ariane - http://arianeb.com/dategame.htm Hynopics Collective (if mind control ain't your thing stay away other wise they have a sizeable collection of RAGS games) - http://hypnopics- collective.net/index.php Now if I you want a wish list of what I'd like to see in the near future for AIF: 1) Goblin Boy's 3rd game in the Phallius series 2) More female perspective games (yes I have an obsession but I'm comfortable with that) 3) More competitions 4) The return of Chris Cole 5) Continuations for British Fox, Sam Shooter, Crossworlds and the Choices game * * * 2008 Mini-comp: A General Critique by Softiron I've become grumpy in my old age. Ten years ago I was excited to find a budding community and downloaded all of the games at Mycophile's website. I enjoyed them all, even the terrible games like Smut City. But as the years have gone by and I have less and less time to devote to my entertainment, I have demanded more and more from the quality therein. And while last year the comp was inundated with original, fleshed out, and competently coded games, this year's lot was incredibly disappointing. It is quite apparent that many of this year's entries were barely alpha tested, let alone beta tested. Bad Day To Be a Princess can be made unwinnable in just two moves thanks to some poor coding. But perhaps more annoying was how shallow most of the environments were. Synonyms are few and far between and many obvious objects go unimplemented. I was rarely immersed in these worlds I was joining. But what about the sex? That's what we all come here for, right? I have to say that rarely does an author write poor sexual descriptions anymore and this competition is no exception. But this is where the "me being old" part comes in. I want to be excited to see a description of sex and I want it to occur naturally given the context of the game's environment. The following sins that leave me flaccid seem to plague way too many games: Undesirable NPCs While authors cannot account for a variety of tastes, what they can do is make me at least think that I want to shag the leading lady. A. Bomire, whose work I generally love, makes this mistake in Working Late. He begins by luring me to my sexy and manipulative boss, all the while trashing my co-worker, who is quite unsexy throughout the game. Then, after an interesting plot twist, the final reward is extorting sexual favors from the person I was told to find unattractive. Am I to suddenly find her hot simply because I found dirty pictures of her on-line? It didn't work for me, because her personality hadn't changed despite the revelation. Bad Dialogue Many would agree, including myself, that Winter Break had the most impressive sex in the entire competition. The breadth and variety was commendable. In fact, the scene where Sara first diddles herself is one of the best masturbation scenes in AIF history. But while the sexual encounter itself wasn't entirely implausible, the characters themselves were made unbelievable by the way they acted around one another. In short, they go from being timid around each other one minute to brazenly addressing each other's sexual fantasies the next. When put in the context of the real world scenario it doesn't work, and it took me a long time for my brain to readjust to the new personalities of the characters. Busy Work Puzzles for puzzle's sake are annoying in regular IF, but are exponentially more annoying in games designed with the goal of sex in mind. With Boss's Wife, you do many mundane activities at the beginning, but these are well coded and do a good job of pacing the game while the storyline unfolds. The problem arises when you must open the liquor cabinet to get the aforementioned wife buzzed. There is virtually no reason for this puzzle to exist other than to create one more delay before the sex. It doesn't add to the story. It doesn't tell us any thing more about the characters. It doesn't make the ensuing sex more exciting. It's just there. What's worse, the puzzle can only be solved by requiring the player to use the dreaded "search" command to find the key. By the time I finally poured the booze, I had no desire to screw anybody. Hand Holding Understandably, authors want to avoid the problem where the player either gets so frustrated with a puzzle that he can't get to the sex, or that by the time he does solve the puzzle he's so annoyed with the game he quits in disgust. So in a frequent move that breaks mimesis, authors often TELL YOU EXACTLY WHAT YOU NEED TO DO TO SOLVE THE PUZZLE. Riding Home suffers from this several times, but so does Working Late and several others game in the AIF database. And when mimesis is broken this heavily, so goes the titillation. So, to all authors who are tempted to do this: 1) If your puzzle is so esoteric that you need to spell out the solution, change the puzzle or take it out. 2) If the puzzle is fine but you're worried that the player will get frustrated with it, make sure to give the player gentle clues in the game, or if you must, include an on-line hint system. Also, make sure your beta-testers provide you with alternate ways of phrasing the solution, or better yet, alternate ways of solving the puzzle. A well coded game does not need to put a leash around the player's head and walk her to the end. Not Enough Foreplay Unless I'm playing with a virtual sexbot (One Girl, e.g.), I want to be gradually drawn to my sexual contest. This can be done over the course of an entire game or just a few paragraphs of exposition. Regardless of how it's done, I would prefer to be randy before the clothes start coming off, not because of it. Venice, an otherwise solid game (less a few minor bugs), is nearly devoid of foreplay. Other than an optional tease surrounding the oysters (which isn't coded perfectly), the only reason to boink the Lord's wife is that she's willing. By the time I solved the puzzles and reached the bedroom scene, I still didn't know why I was having sex with her. It was fun, but not nearly as fun as it would have been had I been chomping at the bit to get in her dress. While the annual competition is effective at getting new games into the fold, it unfortunately encourages games to be submitted before they are polished. As it stands, even if most of the current crop is updated with bug fixes and other improvements, I'll be doubtful to play them again due to my first impressions. As for our two games that tried to be satires, they were anything but. Lampooning bad games by making equally bad games only results in more bad games. Lusty Lovers certainly had promise, what with the hilarious first puzzle and multiple endings. But poor writing and multiple bugs remain frustrating and are decidedly unfunny. The one game I have yet to mention is A Night With Kes, and that's because I found no fault with it. Despite being puzzleless, it was paced well and it is the only game in this comp that did not violate any of the sins above. I liked the plot and the ending. And heck, this old guy will gladly forgo awkward teenage fucking in favor of some good ol' lovemaking. Purple Dragon easily gets my first place vote. ~Softiron * * * 2008 Mini-comp: Additional Comments by Purple Dragon I don't think that anyone would disagree too strenuously that, on the whole, the games in this year's Mini-comp were not quite up to the level of quality seen in the last couple of comps. This is not to say that there weren't some good games this year, because there were, but to me at least, I got the feeling that some of the games were thrown together at the last minute. Certainly one of the main reasons for this is that many of them were. Six of the nine games were either completed or written from scratch during the three-week extension of the deadline. It's nice that we got the extra games, but it resulted in some games that were released before being completely polished (and in a couple of cases that is me being very generous). So when I received Softiron's critique of the Mini-comp, I can't say that I was too surprised that he seemed to have more bad to say about the entries than good. More than that, I found myself nodding agreement at more than one point that he made. However, there were a couple of places where I felt he was being a bit harsh, or maybe we were just looking at things differently. The following are just a few comments about each of the games that occurred to me as I read his critique. Office Fantasy: Working Late Softiron said: Then, after an interesting plot twist, the final reward is extorting sexual favors from the person I was told to find unattractive. Am I to suddenly find her hot simply because I found dirty pictures of her on-line? It didn't work for me, because her personality hadn't changed despite the revelation. Although I certainly see Softiron's point here I disagree with how jarring the switch is. Lacy is described throughout the game as being an attractive girl hiding behind concealing clothing. This in itself made me wonder why she dressed this way before I ever found the website. I loved the switch of focus and found it a surprising twist in a genre that so often fails to surprise anyone. By the time I found all the evidence in Melanie's office I had no desire to screw her, but did I really want to screw Lacy. Softiron's best point is that, "her personality hadn't changed despite the revelation." She is still a rude bitch but knowing why she is like that helps a bit. At this point you can go ahead and blackmail her, get some sex, and end the game. If that were all there was to it I would have agreed even more strongly with this point. However, the option of destroying the evidence and giving Lacy her "second chance" leads to a much more fulfilling scene. Of course it's still rather implausible that the two of them would suddenly fall in love from that one action but come on, when it comes right down to it which of these games (AIF in general, not this comp in particular) isn't a bit implausible. Although I don't think this was A. Bomire's best game, if we pay attention he has given us with more than enough information and detail to suspend disbelief and enjoy ourselves. Office Fantasy: The Boss' Wife Softiron said: There is virtually no reason for this puzzle to exist other than to create one more delay before the sex. It doesn't add to the story. It doesn't tell us anything more about the characters. It doesn't make the ensuing sex more exciting. It's just there. My apologies to A. Bomire but I can't bring myself to disagree with anything here. The puzzles in the beginning fit the game and made sense, but opening the liqueur cabinet is just a bad puzzle. The only thing I can think of to explain how something like this found its way into one of his (normally outstanding) games is that he evidently wrote this one between the two deadlines for the comp. Given more time, I can only assume he would have found a better way to go about it. Winter Break Softiron said: But while the sexual encounter itself wasn't entirely implausible, the characters themselves were made unbelievable by the way they acted around one another. In short, they go from being timid around each other one minute to brazenly addressing each other's sexual fantasies the next. One of the hardest things to do in any AIF game is to come up with a believable scenario as to why these two (or more) people are having sex. Yes, in this case the jump is fairly extreme. Some of this can be explained by the fact that Sara is a self-professed nymphomaniac and that the PC is, well, he's a guy, that's enough right? The sex scene is certainly hot (I gave it my first place mark in that category) but it could certainly have been improved by a more gradual buildup. This level of subtlety is something to strive for, but something hard to attain, even for more experienced authors. I'm more than willing to overlook something like this for a first time author and look forward to even better games to come. Riding Home Softiron said: So in a frequent move that breaks mimesis, authors often TELL YOU EXACTLY WHAT YOU NEED TO DO TO SOLVE THE PUZZLE. And when mimesis is broken this heavily, so goes the titillation. I agree that this is one of the hardest things for me to get around when playing a game. If you have to come right out and tell the player exactly what to type to solve the puzzle then you probably shouldn't have the puzzle in there to begin with. I recognize the reasoning behind doing so, and have even been guilty of it myself to some extent but that doesn't make it right. I guess where I disagree is that Riding Home was a major culprit of this. Yes, the puzzles were too easy and maybe the hints were a bit too blatant but I never really got that feeling that I was being told what I had to do next (even when that was exactly what was happening). I found this game to be a very good Mini- comp entry and I, for one, am looking forward to the longer game to come that the author has mentioned. A Lady in Waiting Softiron said: I want to be gradually drawn to my sexual contest. This can be done over the course of an entire game or just a few paragraphs of exposition. Regardless of how it's done, I would prefer to be randy before the clothes start coming off, not because of it. Venice, an otherwise solid game, is nearly devoid of foreplay. I mostly agree with this and it goes back to the problem of plausibly getting from the point of meeting someone to boinking her. Still, if you pay attention, there is some buildup here and it is done mostly through the conversational system at the party. You get some background information about Veronica and her husband, enough to know that their marriage isn't a happy one. Once you get a couple of drinks in her you can get into some more interesting topics and this is where the potential for some good buildup really comes in. Unfortunately, the scene ends too quickly and you have to be off to find your way into her bedroom. It is just too easy to get her to the point of being ready to jump your bones. The idea of a conversation in a non-sexual setting to build sexual tension is a great one and with a few more topics and a little more time to talk, that tension could have been built to the point where you could hardly wait to get her alone. Bad Day to Be a Princess Softiron said: It is quite apparent that many of this year's entries were barely alpha tested, let alone beta tested. Bad Day To Be a Princess can be made unwinnable in just two moves thanks to some poor coding. While I didn't find the way to accomplish that, I certainly found a few bugs along the way. I really liked the idea behind this game and found myself wanting to like the game itself as I played through it. Unfortunately, I found it hard to keep up that level of desire as I went along. What it seemed like to me is that the author was in the middle of writing it when he realized that the deadline was quickly approaching (again) and rushed to get it released. If he were to release an updated version of the game with a more fleshed out sex scene and better implemented ending I would certainly love to play it. Lusty Lovers Sexual Awakening Softiron said: As for our two games that tried to be satires, they were anything but. Lampooning bad games by making equally bad games only results in more bad games. I agree. While I found both games occasionally amusing, and I don't fault the authors for trying something like this, I can only hope that they have now gotten it out of their systems and that we can look forward to better games in the future. A Night with Kes Softiron said: The one game I have yet to mention is A Night With Kes, and that's because I found no fault with it. Despite being puzzleless, it was paced well and it is the only game in this comp that did not violate any of the sins above. It's a bit embarrassing that my game is the only one with no mention of a major flaw. I suppose it's more or less true that it didn't violate any of the categories above but I guess it's up to me to point out the ones it does violate. The biggest thing in my opinion is that it is extremely linear. I am very glad to hear that he found the pacing good and I hope that most others did as well. I experimented with a few timings, trying to give the player enough time to take a look around and talk to Kes a bit but not enough time to get bored. However, when it comes right down to it, you don't have to do anything at all. From the moment you sit down on the bio bed till the beginning of the initial sex scene, you can simply type z , z , z , etc until you get there. I have a hard time thinking of anything more linear than that and can only hope that the player takes the opportunity I was trying to give to get to know Kes and the environment a bit and that he enjoys what comes after. I would like to thank Softiron for taking the time to critique the Mini-comp this year. Although his comments are often brutally honest, they are never mean spirited and I can only hope that authors and players alike will take his comments and mine to heart and use them as points of instruction for future games. * * * The Aphrodite Chronicles by A. Ninny When the breeze inflates your two robes of silk you look like a Goddess enveloped in clouds. When you pass, the flowers of the mulberry tree drink in your perfume. When you carry the lilacs that you have gathered, they tremble with joy. Bands of gold encircle your ankles, stones of blue gleam in your girdle. A bird of jade has made its nest in your hair. The roses of your cheeks mirror themselves in the great pearls of your collar. When you look at me I see the river Yuen flowing. When you speak to me I hear the music of the wind among the pines of my own country. When a horseman meets you at dusk he thinks it is already dawn, and brutally he brings his horse to a standstill. ....When a beggar beholds you, he forgets his hunger. Dear Mortal Men and Women, That poem was written for me in what is now China nearly 1700 years ago. It's one of the most haunting and beautiful poems I ever received, and I've kept it alive all this time. I no longer remember the name of its author, or else I never knew it - a gift from a secret admirer, perhaps. I present it to you today to remind the people of today that they did not discover sex. Every generation believes that they invented it, and that they're pushing the envelope of what it is. But of course they're not. But what they are doing is discovering it for themselves. I recently spent time with a young mortal woman named Chica. She has decided to uncover the entirety of her own sexuality. She spoke with me about how she feels that when she is with someone they only scratch the surface of her sexuality, and though she always enjoys them, she's left knowing that she could experience so much more. She believes that she is capable of (and in need of) full-body eroticism. I'm the right person to help her. I set her on a bed and sat down on a nearby chair. She was wearing jeans and a t-shirt, her brown hair cropped messily and hanging midway down her neck. Her body was beautiful and young. Her breasts were small but shapely, her hips curvaceous, her eyes bright and eager. "What should I do?" she asked. "I want you to explore your body," I responded. "Make love to it in its entirety. But don't pretend I'm not here. Use my presence as an amplifier to your pleasure. Make my watching you important." "I don't quite understand." "Simple," I explained, smiling at her, "think about making me horny." She smiled back, understanding in her eyes. Then her look changed. She offered me an almost irresistible 'come hither' and let her hands roam upwards from her belly. She kneeled up tall and pointed her body straight at me, her chest beckoning, her nipples suddenly poking erect through her shirt, even without having been touched. I felt a sudden familiar wave of warmth flow through me, centering itself in my groin. Still with her eyes locked to mine - a wave of desire pouring from them, her body began to move. She lowered herself slowly from kneeling upright to resting on her calves, her legs spreading, looking very much like she was lowering herself onto a huge cock sticking out of the mattress. I could literally feel it penetrating my own pussy as she moved, imagining fucking it with long, long strokes. This woman has the power, I thought to myself, she's earth elemental - sexuality in its purest. I had to refrain from touching myself in response, to sit still and watch dispassionately - A difficult task. Her hands began exploring her body, and all the while she continued very slowly humping that huge imaginary cock, looking almost orgasmically beautiful and sexy. Slowly, her fingers traced through her curves, concentrating not on her traditional erogenous zones, but rather on less-explored areas: the sweeping triangle between breast and collarbone and underarm, for example, received encyclopedic study. Her triceps, pre-waddle of course, were her fingertips next target. She focused on the spot where her skin appeared from her sleeve, sometimes using her fingernails to leave white streaks that slowly, luxuriously filled in was pink as if her blood was participating in the tempo of her pleasure. I began feeling significant waves of heat emanating from Chica. Her whole body was radiating sexual energy, and she hadn't even bothered to remove any of her clothing. She made beautiful little sounds: hiccups, peeps of pleasure, her face betrayed her concentration, showing her to be focused in on every part of herself. And yet she had not forgotten me. Her eyes maintained some of their attention on me and I could swear she was making my own growing need part of. My mind began to wander almost uncontrollably and my eyes fell to her crotch, giving me an almost undeniable need to press my face into her pussy. "Are you sure you're not a demigoddess?" I asked her, my throat nearly constricting on the words so heavy was my desire. Her only response was a complicit grin. Clearly, I have much more to relate from my extraordinary visit with this woman. But it will have to wait until next month. Until then, I wish you all wonderful love. Aphrodite * * * Programming Erin: Part 2 - Basic Rooms and Objects Our task this month is to take a look of some of the basic building blocks of any game. Sure the games would be pretty boring without all the hot babes and studly guys doing what they do best, but they certainly wouldn't get very far without somplace for all that action to happen. A lot more will be said in future months about rooms and objects but for now, here is an introduction to creating your environment. I thought that I would give you a little insight into how this feature is coming together. As I mentioned last month, Knight Errant is taking the lead in this project. What this means is that he is writing his segment two to three weeks before the rest of us so that we have something to base our segments on. Remember that the main purpose of this feature is to compare the different programs so it stands to reason that the tasks each month need to be the same in each segment for the comparison to be valid. The best way that I could think of for this to happen was for one person (with input from the rest of us, and you too by the way if you have any ideas) to write up their segment and then have the rest of us show how to accomplish the same thing with the other programs. Time will tell if this is a workable idea or not, but it's what we're going with for now. Because of this, you may occasionally notice reverances to Knight Errant's TADS 3 segment in the other parts. I've considered whether to encourage or discourage this but in the end, I've desided to keep my big mouth shut (didn't think that was possible did you?) and let each author choose their own course within the limits of the month's assignment. All this is to explain that the TADS 3 segment will appear first in this feature from now on so that people reading through will recognize the reverences when they occur. TADS 3 Segment by Knight Errant Welcome back to the TADS 3 edition of Programming Erin! Last month we went over the basics of starting a new project. This month we'll be taking that project and begin turning it into a real game. Open up your source file and lets give the player some better surroundings. We can turn the scenario into a "working late" situation, and have the starting room be the player's office. myOffice : Room 'Your Office' "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. " ; + desk: Surface 'your desk' 'desk' "It's your desk. " ; ++ computer: Thing 'your office computer' 'computer' "It's your computer. " ; + me: Person 'you' 'you' "Just an average Joe. " isHim = true ; By default, the parser refers to objects (including object of the Person class) as "it". Setting the "isHim" property to true lets the parser know that it should refer to the character using male pronouns. It doesn't automatically create the appropriate body parts, we'll work on that another month. Since our description of "myOffice" mentions a desk and a computer, I've added an object for each. The computer is of the Thing class, which simply defines it as a generic inanimate object that can be carried around. Since it's described as being on the desk, we need to define the desk as a type of object that can have other objects on top of it. The class "Surface" is provided by the standard Adventure library to define this. Notice the + signs again. The way these work is that an object is located in the immediately preceding object with one less +. The office has no + signs, so nothing contains it. The desk and me have one +, so they're both located immediately in the office. The computer has ++, so it's located inside the preceding object with one +, in this case, the desk. Notice that the definitions of the desk, the computer, and the PC differ a little from the definition of the room. This is because we're not using the Room template, we're using the Thing template. This is what it looks like: Thing template 'vocabWords' 'name' @location? "desc"?; There are a few differences between the Thing template and the Room template. First, we have the single-quoted string 'vocabWords'. This defines the words and synonyms that the player can use to refer to this object. The possible adjective(s) (in this case, "your") are separated by spaces and the possible nouns (in this case, "computer") are separated by slashes. Thus, if we wanted to be able to refer to it as "your computer", "my computer", or "my CPU", we would define it like this: ++ computer: Thing 'my your computer/CPU' 'computer' "It's your computer. " ; The next part of the Thing template is the 'name'. This property defines how the game will refer to the object, to say things like "On the desk is a computer". Right now the desk is of the Surface class, which means you can put things on top of it. However, being a Surface doesn't preclude the player from picking it up and carrying it around. If you run the game right now you'll find you can do exactly that, which is obviously not the sort of behavior we want here. The class "Heavy" will stop all attempts to move the object with a message referring to the weight of the object, but if we changed the desk from a Surface to a Heavy object, we would find that we could no longer put things on top of it. The solution to this is to give the desk more than one class. Sometimes two classes will define the same property in different ways, in which case the class that comes first takes priority. The Surface behavior is more important than the Heavy, so Surface comes first. That way, if there are any conflicting properties between the two classes, the Surface properties will be used instead of the Heavy ones. Lets add the Heavy class to our desk, as follows: + desk: Surface, Heavy 'your desk' 'desk' "It's your desk. " ; Now, any attempts to take the desk will be met with the appropriate response "It's too heavy to pick up." One other thing to notice is that at the end of each description, I've inserted a few spaces. This is to ensure proper formatting when TADS generates responses. It makes sure that when the player types LOOK, he gets "It's your desk. On the desk is a computer." instead of "It's your desk.On the desk is a computer." Things are looking better so far, but most games have some introductory text to set the scene before beginning the game. Luckily, the GameMainDef class defines a method called showIntro() that will display some text at the start of the game. It also has a showGoodbye() method that can display a brief message when someone quits a game. Let's change the definition of our gameMain object to take advantage of these. gameMain: GameMainDef initialPlayerChar = me showIntro() { "You're stuck working late at the office again. You've been staring at the screen for so long that you're beginning to go cross-eyed. You step back from the computer to take a brief break when you hear a sound from outside your office. Perhaps you're not actually alone here. "; } showGoodbye() { "<.p> Thanks for playing!\b"; } ; Now we've introduced some new complications. Until this point, we've only been dealing with objects and properties of objects. Now, we're introducing methods. Properties define aspects of objects, such as their name, description, etc. Methods are the aspects of objects that actually do something, in this case, displaying simple messages. The name of the method is simply the way you refer to it in the code, it only has to be unique to the object. Standard T3 naming conventions are to begin things with a lowercase letter, and capitalize the first character of each subsequent word to make it readable without spaces. The actual stuff the method does goes within the curly brackets, in this case, it's a double-quoted string. So far, we've been using single-quoted strings and double-quoted strings without specifying what they are or what they do. A string is a sequence of text that the game uses. Single-quoted strings are strings that are used internally. They can be compared to other things, they can be modified, they can be printed to the screen, etc. Double-quoted strings are just printed to the screen, like descriptions or the showIntro. In the showGoodbye method we introduce two new formatting commands. <.p> is one of the TADS HTML commands. It's not actual html, of course, but TADS uses html-like tags to control formatting under the assumption that most of us are familiar with html. <.p> creates a new paragraph, just like the

tag in html. The \b tag forms a line break, just like the
HTML tag. For more information about text formatting in TADS, take a look at this article: http://www.tads.org/t3doc/doc/htmltads/intro.htm The game so far is still a pretty boring game, but at least now we have a bit of a scenario and understand a little of the basics of TADS 3. Next month we'll get into some more interesting details. TADS 2 Segment by A. Bomire It's time once again to look at writing a small game using TADS 2. In the last portion of this series, we looked at getting the software and files installed onto our computer, and we left off at the point at which we were ready to begin creating our game. So, let's pick it up there. As tempting as it is to dive right in and start coding, you first want to spend a little bit of time getting a game design in place. You probably have an idea in your head about what your game will be about, and the setting in which it will take place. Take a couple of minutes and write all of this down - jot it down on a piece of scrap paper, open up a convenient text editor and write a quick note, carve it into the wall of your bedroom, etc. Just get it down. You will refer to this later when you are writing your game to see what you need to do, or what you might have missed. This is also a good place to jot down those ideas that come to you while you are writing so that you don't forget them. For our small game, we are going to assume it takes place in an office environment. Just knowing that, we know some things that we will want to include in our game: a desk, a chair, perhaps a computer on the desk. Those objects, in turn, supply their own assumptions. A chair implies that the player will be able to sit upon it. The desk implies that it may have some drawers in it and that the player can sit or even lie upon it. At the very least, the player may expect to be able to open and close the desk, and possibly put things inside of it. The computer will be something that the player will want to operate. At the very least, the player will want to turn it on and off. I'm going to take a brief moment here to point out something that you may have noticed in the above paragraph: when writing a game, I always try to look at it from the player's point of view. When I place an object, puzzle, character, situation, etc. into a game, I try to view it as a player. Presented with the same object, puzzle, character, situation, etc., what would an average player do? Then I try to set up my game to respond in a logical manner to the player's input. Allow me to indulge in passing on my favorite quote from a book I read many years ago. It hung on my wall when I was a professional programmer, and it graces my website now: A program should follow the 'Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least. - Geoffrey James, The Tao of Programming Granted, this is talking about program and interface design, but I've always found it to be just as applicable if you replace the word "program" with "game" and "user" with "player". What does it mean? It means that you should write a game in such a way that the player isn't "surprised" at anything that happens - well, except for deliberate surprises. Objects, characters, situations, etc. should all act and be what the player expects. A couch should be something the player can sit or lie upon, perhaps even look behind or under. A cabinet should be able to be opened, and objects placed inside. And you should go beyond these obvious things to things you may not initially think about. For example, a wallet is something into which you should be able to place things - but only small things. You shouldn't be able to put the tennis racket into the wallet, for example, but you should be able to put the piece of paper into it. And this 'Law of Least Astonishment' applies to object placement as well. Do you, as a player, expect to find the ax in the kitchen or the tool shed? Just what do you expect to find in the kitchen? In short, when writing a game you should be on the lookout to avoid creating "guess the verb" problems and violating "mimesis" - that feeling of verisimilitude or of the game imitating real life (as much as a fantasy setting can, of course). There are lots of articles on these subjects, but I've always felt that Geoffrey James summed it up best - don't surprise the player! Okay, enough of that. The first thing to remember about TADS (version 2 and 3) is that it is object- oriented. This series is way too short for me to go into just what the heck that means, but in short you define an object, give it some properties, and then tell TADS that other objects are like that original object. These other objects will automatically have those properties you defined (called inheritance). For example, if I want to have some "chairs", I would define the master chair object (called a class) and define what happens when the player (or another character) tries to sit in the chair, pick it up, put objects on the chair, etc. From this master "template", I can then create various other chairs within my game. TADS has many of these templates already defined (such as the chairitem class), and we will make use of them in creating the various objects within our game. You can redefine various properties of your additional objects, thus avoiding some obvious conflicts such as every chair being described the same. The second thing to remember about TADS is that EVERYTHING is an object - the room you are in, the objects within that room, the commands the player types, the player character, the other actors...EVERYTHING! All of them can be altered to fit exactly what you want to do, which is both incredibly powerful, and incredibly scary as well. Because you can alter everything, you can really screw up everything! So, be careful with what you are doing. The first object we will be creating is a room. "Room" is a convenient label for a location within your game. It doesn't have to be a room - it could be outside, in a cavern, on a bus, in the middle of nowhere, in the void of outer space, etc. But, you have to call it something, and for convenience TADS (and most authoring languages) call it a room. The room class object is expected to have at least 2 properties defined: the short description (displayed in the status bar), and a long description (displayed when the player types look while in that location). The first room you create in TADS, or at least the room where you expect the player to start, is called the "startroom". Let's create that room now: 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. " ; That pretty much creates the room. It also shows how an object definition looks in TADS: object_name: class property_name = property_value ... ; When the game starts, the player will see something that looks like this: Your Office 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. > And the player can then begin exploring the virtual world we are creating. Right now, that world is pretty limited, because we've just created a room but we haven't put anything into it. At least, we need to add a desk and computer, because they've been mentioned in the description. I'm also going to add a chair because nobody stands at their desk all day - do they? (Again, the player will expect a chair with the desk, so I'm not going to "surprise" him/her by not having one there.) Let's create these objects, using some other of TADS built-in object classes: fixeditem, chairitem, and beditem. desk: beditem location = startroom sdesc = "desk" ldesc = "It's your desk. " noun = 'desk' adjective = 'your' ; chair: chairitem location = startroom sdesc = "chair" ldesc = "It's your chair. " noun = 'chair' adjective = 'your' ; computer: fixeditem, switchItem location = desk sdesc = "computer" ldesc = { "It's your computer. "; if (self.isActive) "It's currently on. "; else "It's currently off. "; } noun = 'computer' adjective = 'your' isActive = nil ; All of that seems pretty straightforward. You'll note that we specify where an object is located by the use of the location property. We also specify what words we wish to use to refer to an object by the use of the noun and adjective properties. Here, we've used a single set of words for each, but you can include as many words as you wish. For example, we could have described the desk as being a "large, oaken desk" and then set up the noun/adjective properties of the desk like this: noun = 'desk' adjective = 'large' 'oaken' 'your' This would have allowed you to refer to the desk as the "large desk", "large oaken desk", "oaken desk", "your desk", "your oaken desk", etc. For some of the other properties of the objects we've included, I've chosen to inherit properties from previously defined classes. The desk is a "bed", meaning you can sit on it, lie on it, and even put things on it. The chair is a "chair", meaning you can sit on it and put things on it, but you cannot lie on it. But wait..the computer is two things? Is that possible? Sure it is. This takes advantage of another aspect of object-oriented languages - multiple inheritance. Within TADS, there are two classes defined: fixeditem, which is basically an object that is fixed in place and cannot be moved around, and switchItem which is an object that can be turned on and off. We want our computer to both be fixed in place and able to be turned on and off, so we've defined it as an object that inherits characteristics from both of these classes. The switchItem class keeps track of whether an object is "on" or "off" by using the property isActive. If it is true, then the object is turned on. We can query this property to alter our description of the object to reflect this on/off status, which is what I've done by creating a slightly more complicated long description (ldesc) for the computer object. This illustrates yet another feature of TADS. Pretty much anywhere you like, you can set up a property of an object to evaluate some code to determine it's value. This can come in really handy when doing things like describing an object whose description can change (such as turning the computer on and off), or whose value can depend upon the value of another object. For example, turning on the wall switch might automatically turn on the light sitting on the desk. When we alter a property to evaluate some code, we call that a method. Why? I'm not sure, other than to differentiate it from a simple property which has a value. All methods have bracket characters { } surrounding them to set them apart from other properties. Okay, we've set up our starting location and some simple objects in that location. But wait a minute, we are referring to some classes of objects which we haven't defined. For example the chairitem and beditem classes. TADS has already defined them for us, but we haven't told our new game where to get those definitions. These definitions are found in the TADS library files ADV.T and STD.T. (Mostly in ADV.T, but you'll find a few in STD.T as well.) To take advantage of these pre-defined classes, and also all of the other stuff that you find in a TADS game, we'll need to tell our new game to use that stuff as well. This is called including, and is done using the special include directive: #include #include These directives are special in that they are preceded by a pound or number sign (#), and that they ALWAYS begin in column 1 of your game file. If you place a space before the # sign, then TADS will not treat it as include and will generate an error. Always place these directives at the beginning of your game file. If you use one of the sexual library files, like NewKid's chick.t or Sir Gareth's sex.t, then you will also use the include directive to add those library files to your game as well. You can even break up your game into sections, and include all of those sections in the same manner. However, be sure to pay attention to the order in which you include files. TADS processes these files in the order in which you include them. If you, for example, were to put the standard TADS library files in this order: #include #include You will start getting all kinds of errors about UNDEFINED OBJECT. This is because STD.T refers to objects which are defined within ADV.T. So, you have to put ADV.T first. Okay, all of that seems pretty straightforward. Now, let's get into something which isn't. Or, at least, isn't as simple as the above. Almost every game you do will have some sort of introductory text associated with it. This is usually a few lines or a couple of paragraphs and may describe the setting of the game, or the general characters in the game. There are a few schools of thought on how to do this, and I'm going to outline two of them. If you read the TADS manual, you will discover that the standard library file STD.T is described as being one that the author is expected to modify. There are more than a couple of places within that file where the comments will indicate that the author can freely change what is currently in the file. This is good, and a perfectly acceptable way of doing things. However, be warned that you will need STD.T for every game you create. If you modify your only copy of the file - you may have trouble getting it back to "factory defaults" for your next game. Be sure to keep a backup copy somewhere. Open up STD.T, and look for a function called init, which as is implied performs initialization. The function looks something like this: init: function { #ifdef USE_HTML_STATUS if (systemInfo(__SYSINFO_SYSINFO) != true || systemInfo(__SYSINFO_VERSION) < '2.2.4') { "\b\b\(WARNING! This game requires the TADS run-time version 2.2.4 or higher. You appear to be using an older version of the TADS run-time. You can still attempt to run this game, but the game's screen display may not work properly. If you experience any problems, you should try upgrading to the latest version of the TADS run-time.\)\b\b"; } #endif /* perform common initializations */ commonInit(); // put introductory text here version.sdesc; setdaemon(turncount, nil); setdaemon(sleepDaemon, nil); setdaemon(eatDaemon, nil); parserGetMe().location := startroom; startroom.lookAround(true); startroom.isseen := true; scoreStatus(0, 0); } You'll note right there in the middle of all of that code it says "put introductory text here". This is one of the places where the author, that's you by the way, is expected to modify the standard code. Right where it says "put introductory text here" you are expected to put in any introductory text you wish to display. So, that's just what we'll do: init: function { #ifdef USE_HTML_STATUS if (systemInfo(__SYSINFO_SYSINFO) != true || systemInfo(__SYSINFO_VERSION) < '2.2.4') { "\b\b\(WARNING! This game requires the TADS run-time version 2.2.4 or higher. You appear to be using an older version of the TADS run-time. You can still attempt to run this game, but the game's screen display may not work properly. If you experience any problems, you should try upgrading to the latest version of the TADS run-time.\)\b\b"; } #endif /* perform common initializations */ commonInit(); // put introductory text here "You're stuck working late at the office again. You've been staring at the screen for so long that you're beginning to go cross-eyed. You step back from the computer to take a brief break when you hear a sound from outside your office. Perhaps you're not actually alone here. \b"; version.sdesc; setdaemon(turncount, nil); setdaemon(sleepDaemon, nil); setdaemon(eatDaemon, nil); parserGetMe().location := startroom; startroom.lookAround(true); startroom.isseen := true; scoreStatus(0, 0); } Now, when you run your game, you will see this initial text displayed. While we are looking at the initialization code, take a look at some of the setdaemon commands listed here. You'll notice one for something called "sleepDaemon" and one for "eatDaemon". These basically count down until the player is hungry and sleepy, forcing the player to find something to eat and someplace to sleep. These used to be popular and part of every "dungeon crawl" game, but almost no one uses them anymore. So, it is probably a good idea to remove them from our game. Just delete those lines. And, you remember when I said every TADS game begins in the startroom? Well, here in init is where it says that the player starts out in room startroom. If you ever want your player to start someplace else, say in a chair in a room or in another room entirely, then this is the section you would modify to affect that change. Make the necessary changes to init, then save STD.T. Compile your game, run it and verify that your changes took place. In the end, your init function should look something like this: init: function { #ifdef USE_HTML_STATUS if (systemInfo(__SYSINFO_SYSINFO) != true || systemInfo(__SYSINFO_VERSION) < '2.2.4') { "\b\b\(WARNING! This game requires the TADS run-time version 2.2.4 or higher. You appear to be using an older version of the TADS run-time. You can still attempt to run this game, but the game's screen display may not work properly. If you experience any problems, you should try upgrading to the latest version of the TADS run-time.\)\b\b"; } #endif /* perform common initializations */ commonInit(); // put introductory text here "You're stuck working late at the office again. You've been staring at the screen for so long that you're beginning to go cross-eyed. You step back from the computer to take a brief break when you hear a sound from outside your office. Perhaps you're not actually alone here. \b"; version.sdesc; setdaemon(turncount, nil); parserGetMe().location := startroom; startroom.lookAround(true); startroom.isseen := true; scoreStatus(0, 0); } Now, that is just one way to display the introductory text. A different version is to do something very similar, but not to modify the STD.T file at all. Some authors, myself included, don't feel comfortable modifying a standard library file like STD.T. So, they take advantage of the TADS replace and modify commands to alter previously defined objects. Replace and modify are designed specifically to allow the author to change previously defined objects, without having to make changes to other library or module files. They were originally created to allow the author to make specific changes to objects defined within ADV.T so that when new versions of ADV.T were released the author didn't have to worry about replicating his or her changes to the new version. But these same commands can be used to modify objects defined within STD.T, or NewKid's chick.t, for example. As it sounds, replace completely replaces the object definition with a new definition, and modify simply modifies a portion of the object definition. When it comes to changing STD.T, I usually don't do so, and just use replace or modify to make any changes that I need to make. So, when I make the above listed changes to the init function, I do so using replace, like this: replace init: function { #ifdef USE_HTML_STATUS if (systemInfo(__SYSINFO_SYSINFO) != true || systemInfo(__SYSINFO_VERSION) < '2.2.4') { "\b\b\(WARNING! This game requires the TADS run-time version 2.2.4 or higher. You appear to be using an older version of the TADS run-time. You can still attempt to run this game, but the game's screen display may not work properly. If you experience any problems, you should try upgrading to the latest version of the TADS run-time.\)\b\b"; } #endif /* perform common initializations */ commonInit(); // put introductory text here "You're stuck working late at the office again. You've been staring at the screen for so long that you're beginning to go cross-eyed. You step back from the computer to take a brief break when you hear a sound from outside your office. Perhaps you're not actually alone here. \b"; version.sdesc; setdaemon(turncount, nil); parserGetMe().location := startroom; startroom.lookAround(true); startroom.isseen := true; scoreStatus(0, 0); } I would typically place this somewhere within my game module. There is no difference to the changes listed above compared the the previously described changes to init made within STD.T, other than no changes to the STD.T file have been made. I guess the methodology would depend upon the author. Use whichever method you prefer. However, I would give you one word of warning. Other library modules you may include in your game may make changes to the way that the init function is defined, or other objects defined within STD.T that you may alter, and thus when you include those modules in your game you'll suddenly discover that the changes you made aren't taking effect. Sir Gareth's sex.t is one example. Well, that pretty much wraps up creating your initial environment. Granted, the environment we've created is fairly boring, but next month we'll get into some more interesting details. ADRIFT Segment by BBBen I'll start out this month by mentioning that I recently (and finally) purchased a registered copy of ADRIFT 4.0, so I can now compare the features more effectively. The differences are mostly subtle ones, advanced features and general stability, so I'm now sure that my comments will apply pretty well to both versions. So anyway, we're dealing with some of the basics of getting a game going. This stuff is really easy in Adrift, so I can probably keep this article simple. In fact, the ease of understanding these basics is a big part of the appeal of this system, because while Adrift has a few features that other systems don't (auto- mapping, predictive text, the control panel, to name a few), the real appeal of Adrift is its accessibility to newcomers. This stuff is all easy enough to figure out for yourself, but I'll run you through it anyway. Under the menus along the top are a row of buttons. After "New Adventure", "Open Adventure" and "Save Adventure" are five buttons to create rooms, objects, tasks, events and characters. We're going to deal with the ones that are easy to understand this time (tasks and events are a little more complicated, but still not too hard; we'll get to them another time), namely rooms, objects and characters. First of all, you need to have a room in which to start your adventure (it helps to create your first room before writing your intro text, but it's not essential), so press the "Add Room" button. A box will pop up - in the "short room description" section give the room a name, like "Office", and in the "long room description" write the response you want the player to see when they "look" inside the room. Up the top of the box you'll see that there are two tabs - one titled "description" and the other titled "directions". Finish that room by clicking "Add Room" in the box (you can edit it again later if you want), then start a second room by clicking the "add room" button below the menu. Call this one "hallway" in the short room description and give it a long room description, then click on the "directions" tab. There are drop down boxes here; we want the hallway to be south from the office, so where it says "Move North to", open the drop down box to the right and select "Office". Now click "Add Room" and the generator will ask you a question: "Would you also like to move south from Office to Hallway". Select "yes" - in this way the system simplifies how to create directions of movement. Generally you will always want to select "yes" unless you only want one-way travel for some reason. Next up we'll add some intro text for your game. Open the "Adventure" menu and select "Introduction" if you're using 3.9, or "Introduction and Winning" in 4.0. This will bring up a box with space to put in some text; you can actually use line breaks in this box, unlike other text boxes in Adrift (elsewhere you will have to use the html code
to create a line break). Type in some text in the area labelled "text to show on startup", it doesn't matter what, and then click the box next to "display first room on startup". You don't have to do this, but I think it's preferable to orient the player. There should be a drop down box next to the words "Start the adventure in room:", and with that box you can select any existing room to be the first one. Keep it as "Office" for now, or change it to "Hallway" if you want. Click "OK". We need to create the player's character now. Open the "Adventure" menu and select "Player". You can give the PC a name, but let's let the player choose by clicking the box next to "Prompt for name". Give the PC a description of some kind - something simple since we're making this character generic. The other options give you the ability to change the PC's starting state and add an alternate description, but we won't use those right now. However, at the bottom you will see options for the size of the PC's inventory. I don't like to limit the players in how much they can carry, so I always change these options to "99" in each of the number boxes, and change the drop down boxes to "huge" and "very heavy". Click "OK" to close this box. Now let's put a desk in the office. Click on "add object" and it will bring up a box. The first field for text is titled "Object prefix" - you can use this if you don't want your object's name to be preceded by "a" (for instance you wouldn't want it to say "a egg" - it would be "an egg", or "the egg" or "my egg" or "Grobnar's egg" or whatever you want). We'll leave this as it is for now, but to the right is a field for the "object name". Write "desk" in there. Below that is room for an alias (or more than one in version 4.0), which is good if you wanted to call an object by other names too. However "desk" pretty much covers it for now. There are two possible object types - static and dynamic. This is pretty straightforward, actually: static objects are things like desks that stay where they are, and dynamic objects are objects that the player can pick up and put in their inventory. The desk is static, so leave those options as they are. However, where it says "object exists in" you should select the "Office" option, so it can be interacted with there. You can actually make a static object exist in multiple rooms, which can save you time or allow you to use "rooms" a little differently (say if you wanted to make several "rooms" as just part of a big ballroom, and you want the chandelier object to be in all of those room sections). Add a description of the desk in the "description" field, then click on the "attributes" tab to check out some of the other things that can be done with objects. Here you can change a lot of properties of items, with different choices depending on whether the item is static or dynamic. You can make the object wearable, openable or closable, readable, you can make it a container, you can give it a surface to put things on, you can decide whether the player can sit or lie on it and more. I think all of this is pretty self-explanatory, so I won't go into it in detail. Play around with the options if you want; the one bit of advice I'd give here is to think about the ramifications of giving items different properties - sometimes even if it would make sense for a player to be able to sit or lie on something, or whatever, it can throw off what is happening in the scene, so don't give items a lot more properties than they need. For now, just give the desk a surface by clicking the box next to that option, then click "Add Object" to close the box. We'll ignore the "advanced" tab in 4.0 for now. I think that's all we need to cover this month. Hopefully by now you're already getting the hang of this, and you can probably leap right in and make a bunch of rooms with objects in them. Try test-running the game to see what it's like. You won't be able to do much yet, but at least you can see if all the rooms and objects are in the right places. In a way, I've just said some really obvious stuff with a lot of words; the Adrift generator pretty much explains itself as you use it, so there's no need to worry too much if my explanations were unclear. Poke around in the generator and have some fun, and you'll be ready to make real stuff happen in no time - you can even play around with characters and tasks if you want, which I suspect I'll be discussing next month. Inform 6 Segment by 'trix This month we're going to make a room with some objects in. Most of the code for this is conceptually similar to the TADS 3 code. Constant Story "Programming Erin"; Constant Headline "^A simple Inform 6 AIF game by Some Author^^"; Include "Parser"; Include "VerbLib"; Object Office "Your Office" with description "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." has light; Object -> Desk "desk" with name 'desk' has supporter; Object -> -> Computer "computer" with name 'computer' 'pc', description "It's your computer." ; [ Initialise; location = Office; selfobj.description = "Just an average Joe."; ]; Include "Grammar"; Things to notice: There are three object declarations in the code above. Notice that each one ends in a semi-colon. Other things you might like to notice at this point: there is quite a lot of whitespace in the source. As in all good programming languages, whitespace is there to make the code readable to you, not to communicate with the compiler. It separates words, but the length and type of the whitespace doesn't matter. Whitespace is significant in strings: the string "alpha beta gamma" is different from the string "alpha beta gamma". However, you may further notice that there are line breaks in the description string for the Office object. Line breaks make long strings in code a lot easier to read, and are compiled into single spaces. If you want an actual line break in a string, you use the caret ^ character, as seen in the headline. One more pretty important thing to mention is that identifiers in I6 code are case insensitive. That means you can refer in your code to office, Office or OFFICE and they will all be the same object. However, keywords (like "if" and "print") are a little more delicate, and generally need to written in lower case. The Desk object has the attribute supporter. This means that the desk can have other objects sitting on top of it. The arrow -> in the Desk object's declaration means "inside the office" (the office being the last object declared without an arrow). The two arrows in the Computer object's declaration mean it is on the desk (the desk being the last object declared with one arrow). Arrows in I6 work the same way as +-symbols before object declarations in TADS 3. The name property defines an array of words that the player can use to refer to an object. So if the player issued the command "Take PC", the game will understand what object she means. Words in a name array are (nowadays) given in single-quotes, not double-quotes. They are what we in the know refer to as "dictionary words" - words for matching against what the player types. Generally, strings that are to be shown to the player are in double-quotes, and words to match the player's input are in single-quotes. The "with" clause for the Computer defines two properties. The two property definitions are separated by a comma (after the word 'pc'). The Computer does not have any attributes (yet), so it doesn't need a "has" clause, just a semi-colon to indicate the end of the Object definition. Since the TADS 3 example defines a description for the player, I've included that in my code too. It may be convenient later to define a new player-object (as in TADS 3) but for the moment we can just stick with the I6 default player- object (which is called selfobj) and assign a new description property to it. That's what the line selfobj.description = "Just an average Joe."; does in Initialise. If you compile and run the game, you should see something like this: Programming Erin A simple Inform 6 AIF game by Some Author (Some release info here) Your Office 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. You can see a desk (on which is a computer) here. There are several improvements that may be made. Since this is your office, that is presumably your desk and computer, not just a desk and a computer. The simplest way to change the indefinite article is by providing the article property and giving a (double-quoted) string. Object -> Desk "desk" with article "your", name 'desk' has supporter; Object -> -> Computer "computer" with article "your", name 'computer' 'pc', description "It's your computer." ; Also, that "You can see a desk here" is pretty lame what with it only just having been mentioned in the room description. The attribute scenery means "this object is always here, probably mentioned in the room description, and so need not be explicitly mentioned". It will also prevent the player picking up the desk and walking off with it. So add the scenery attribute to the Desk object. If you compile and run now, you will see the text "On the desk is your computer." We could get rid of that too by giving the Computer object the scenery attribute, but that would mean that if the player searches the Desk then the Computer will not be mentioned, which would be very odd. So rather than that, it's easier just to take the redundant mention out of the room description. If the computer is a significant object, it's a courtesy to the player to let it announce itself rather than just mention it in the room description as if it was background. One more thing to do is to add introductory text so the title and release information are not the first things the player sees when she starts the game. Since we already have a routine in our code that we know is run at the start of the game, we can put the introductory text in there, giving source that looks like this: Constant Story "Programming Erin"; Constant Headline "^A simple Inform 6 AIF game by Some Author^^"; Include "Parser"; Include "VerbLib"; Object Office "Your Office" with description "Your office is fairly small, but it lets you do your job. Most of your coworkers have gone home, so it's pretty quiet." has light; Object -> Desk "desk" with article "your", name 'desk' has supporter scenery; Object -> -> Computer "computer" with article "your", name 'computer' 'pc', description "It's your computer." ; [ Initialise; location = Office; selfobj.description = "Just an average Joe."; print "^^You're stuck working late at the office again. You've been staring at the screen for so long that you're beginning to go cross-eyed. You step back from the computer to take a brief break, when you hear a sound from outside your office. Perhaps you're not actually alone here.^^"; ]; Include "Grammar"; The command print is simply an instruction to display the following text to the player. The carets (as before) indicate line breaks. And at the end of the instruction is a semi-colon. Compile and run it. You will probably notice several things that could be improved-should the computer be portable or do you want to give it the attribute static? Should the player be able to turn it on and off? There is an attribute for that too. Damn, I'm such a tease. More in future months ... Inform 7 Segment by Purple Dragon As we take the project that we set up last month and start the process of turning it into a game, you will notice one of the beautiful things about working with Inform 7. The following paragraphs look more like notes you might make about a game that you are planning rather the code of that game itself, but that is exactly what it is. No one reading them should have any problems in understanding what they are and what they do. Of course, the more complicated we get, the more this illusion of I7 text not really being a programming language will fall by the wayside, but for now, let's just enjoy the simplicity of the language and set up a few simple objects. Your Office is a room. "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." your desk is a supporter in your office with description "It's your desk." your office computer is on your desk. The description is "It's your computer." The description of the player is "Just an average Joe." There are a few things to take notice of here. First of all, when you create an object you have to be aware of the fact that every object has what I7 calls a "kind." This tells the program what it is or how it should act. For the desk above we wrote, "your desk is a supporter..." where "supporter" is its kind. This gives the desk a few special properties, the most important of which is that we are now allowed to set things on it. On the other hand, we didn't explicitly give the computer a kind at all. When this happens, Inform (usually) makes the object of the "thing" kind. This is the most basic of all kinds and the one on which all others build. So the desk is actually a "thing" as well, but one with more specialized properties. Next, let's take a look at the relationships between the things we have created. It is important to keep track of where everything is, or at least, where it starts. If we had written simply "your desk is a supporter with description..." Inform would have created the desk just fine but when the game is run you would not see it. The reason is that we have not told Inform where to put the object so it is sitting in a limbo called "out of play." There are times when this might be just what we want, to have something off stage until the proper moment when we spring it on the player, but in this case it isn't so we specify that it is in the office. For the computer, we got a bit more specific and said that it sitting on the desk. This means that the computer will start the game on the desk so if you don't specify where the desk is then the computer will begin the game out of play as well. If you compile the game now you will see something like this: Programming Erin An Interactive Fiction by Purple Dragon Release 1 / Serial number 080629 / Inform 7 build 5J39 (I6/v6.31 lib 6/11N) SD Your Office 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. You can see your desk (on which is your office computer) here. That all looks pretty good but you will probably notice some things that could be improved. Our room description says "Your computer is on the desk in front of you." and then Inform goes on to mention the same thing again. This is hardly a game killing bug but it isn't very elegant. It would probably be better to have only one or the other. The easiest thing to do would be to just remove that last line from the room description but sometimes having all the items listed out at the end of a room description can be a bit jarring. To get around this, Inform allows us to make pretty much any object "scenery." For instance, you can add the line, "The desk is scenery." to the end of the desk description to accomplish this. The desk will still be there, the player will still be able to examine it, put things on it, etc. It will just not be mentioned separately in the room description. In addition to that, making something scenery also means that it will be fixed in place so that the player can't pick it up and walk off with it. In the case of the desk it doesn't really matter since we made it a supporter, which is fixed in place by default, but we certainly don't want the player to be able to pick it up. As a rule, this tends to work out ok since you would not normally want to make a portable object scenery. You obviously would not want to mention something in a room description if it could be removed from the room so you would normally want portable objects to announce themselves. You can handle the computer in the same way but you want to be a bit careful here. Making the computer scenery will mean that it will not be mentioned in the room description but it also means that if the player searched the desk, they will get something like this: >search desk There is nothing on your desk. Which is obviously not what we want. For now let's just leave the computer alone. There are still problems with it. For example, should it be portable (it is right now), should the player be able to turn it on and off (he can't right now). We'll get to that later but we don't want to get too far ahead of ourselves. You can give any object a list of synonyms and it is a good idea to do so in most cases. Understand "CPU" as the computer. When the player types "x cpu" he would normally get a response saying that he can't see any such thing. What this line does is make it so that when the player tries to do something with the CPU, the program understands that he is really talking about the computer and redirects the command accordingly. The final thing I want to mention about the above text is the player. Notice that we didn't actually create the player here but simply gave him a description. This is because Inform automatically creates the player and puts him in the starting room when play begins. Unless we specify otherwise, the starting room is always the first one created. When the game starts the player is usually treated to a little introductory text. To print out this text we have to use something that Inform calls a rule. Rules are the way that you tell the program what should happen in any given situation. Here is how to print out the introduction. When play begins: Say "You're stuck working late at the office again. You've been staring at the screen for so long that you're beginning to go cross-eyed. You step back from the computer to take a brief break when you hear a sound from outside your office. Perhaps you're not actually alone here." We will be talking much, much more about rules in future months, but for now just take a look at the format. First is the name of the rule followed by a colon. Then there is a list of things that take place when that rule happens, each followed with a semi-colon until you get to the last one, which ends with a period. So in general: Name of the rule: First thing that happens; Second thing that happens; Last thing that happens. In this case there is only a single thing in the list so there are no semi- colons at all. The only thing that we want to happen is for the introduction to be printed out so we tell Inform to "say the following text," in other words, to print it out on the screen. What we want to print out is enclosed in double quotation marks. It is important to note the difference between single ( ' ) and double ( " ) quotation marks and when to use each of them. Double quotation marks are always used to show what we want to be printed to the screen in that situation. If you want the block of text itself to use quotation marks then just use the singles and they will be printed out as doubles when the game is run. That might sound more confusing than it really is. Here is an example. Say "you say hello to the girl." Produces: You say hello to the girl. While the following: Say "'Hello,' you say to the girl." Produces: "Hello," you say to the girl. In our introductory text above there are three words that use an apostrophe and you may be wondering why Inform doesn't turn them into quotation marks. The program is pretty good at deciding when something is an apostrophe and when it is a quotation mark. In general, if it occurs within a word it will be assumed to be an apostrophe. However, you might very well run into problems if you were talking about something like "Achilles' heel" where it comes at the end of the word. For cases like this you can always force the apostrophe by writing, "Achilles[apostrophe] heel." The text in a square bracket within a set of double quotation marks is a text substitution where something is substituted for that text. You will be using this quite a bit as well but don't worry about it for right now. That's about it for this month. We now have an introduction, someplace for the player to stand, and a couple of things for him to look at. Yeah, pretty boring at the moment but we're just getting started. Tune in next month and we'll see if we can make things a bit more interesting. * * * 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.