Inside Erin: The AIF Community Newsletter Volume 5 Number 7 – July 2009 A Letter from the Editor – Purple Dragon I realize that for many of you, July 4th is just another day on the calendar. However, since the editor, several of the staff, and about half the readership of this newsletter are from the US of A, I thought that I would indulge my sense of patriotism a bit. For many Americans, the forth of July seems to be just another opportunity to get drunk and make a lot of noise (as if they need an excuse). I’m afraid that many people miss the point of what this day symbolizes. Words like freedom and patriotism are thrown around an awful lot. When they come from the mouth of an elected official (or someone who hopes to be one soon) they are often seen as some kind of act – as calculated, empty words designed to acquire votes or public approval. It is a shame that they are seen that way, and even more of a shame that, all too often, that view is closer to the truth than not. Freedom is not a gimmick to achieve personal gain, and its purpose is certainly not to ensure a person’s right to stay up until three o’clock in the morning shooting off fireworks. I would bet that even many of you who do not live in this country have heard the following words at one time or another. “We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.” These words from the Declaration of Independence are perhaps some of the best known words in the English language. They do not talk about the rights of individuals to have riches or power. In fact, they do not talk about the rights of the individual at all. They talk about “all men” having the very basic rights of living, being free, and at least striving for happiness. If something an individual does or says puts those rights in jeopardy for anyone, then that is not freedom, that’s its black sheep cousin. The one that everyone tries to exclude from family reunions, but who nonetheless seems to keep showing up anyway. Abraham Lincoln said, “Those who deny freedom to others deserve it not for themselves.” and truer words have never been spoken. In this country we enjoy a tremendous amount of personal freedom. Some would no doubt disagree with that, but compared with many countries in the world it certainly seems true to me. Without the freedoms we enjoy there would be no Inside Erin, no AIF Mini-comp, no AIF games at all. Many people in this country would call what we do here obscene. Many, many others would not find it so, but would still call it juvenile and pointless. But no matter what they call it, I think that most people (I don’t say all) would defend our right to be here. Maybe that’s what freedom really is. Defending someone’s right to do something even when you don’t personally agree with it. I know that this letter is way off topic, and I apologize for that – especially to those of you who don’t live in the United States, who have still managed to read through this whole thing. However, don’t say that none of this applies to you just because you live in a different country. I don’t see any mention of the word “American” in the quote above. That “all men” should apply to anyone reading this. We are a multi- national community, but we are all just men and women, and the freedoms I speak of need to apply to everyone, or they don’t really apply to anyone. Thanks for indulging me. I promise not to do this too often. God bless you all, and God bless America. * * * This Month in AIF by BBBen The main event this month was, obviously, the mini-comp. There were six entrants, which is certainly down on previous years but still a good turn-out (especially considering how generally quiet things have been lately). Rip_CPU entered twice, with one of his games being slightly outside the rules (ironically it was called The Prosperity of Cheaters), and I’ll be interested to see how that is reflected in the voting. Occasionally there are themes that crop up totally coincidentally in a mini-comp, and if there are any this time then I suppose they would be Superheroes/villains and the breaking of wills through sex, which both appeared in Obedience, incidentally. Play the games, you’ll see what I mean. Otherwise the month was generally quiet, with talk still ongoing about SD3, and a little bit of interesting research as to whether there was a correlation between activity on the AIF Archive and the level of turnout for the mini-comp. There wasn’t. New games Mini-comp entrants: Sex is Mental by Rabbi. Released June 10th 2009 for ADRIFT 4. BSG: Twenty Two by Madquest8. Released June 10th 2009 for ADRIFT 4. The Mechano-Menace by A. Bomire. Released June 10th 2009 for TADS 2. Obedience by Rip_CPU. Released June 10th 2009 for Inform 7. The Prosperity of Cheaters by Rip_CPU. Released June 10th 2009 for Inform 7. In Darkness by Goblinboy. Released June 10th 2009 for TADS 2. * * * This Month at TF Games Site by Nandi Bear In at least one way I’m much like the Graffiti artist Bansky. No really. You could walk past both of us in the street and never know or realize who we were. And at heart we’re both artists, no not in the pretentious way, just in that we produce something that (hopefully) people enjoy. But despite the rather strange position of being both know and unknown because of the internet I suffer from the curse of all artist. I have an Ego! Anyone who shares anything with the rest of the world, be it virtual or not, must have some confidence that what they produce is good enough for other people to enjoy. On some level they must believe that their stuff is a bit good. This means they at heart want people to say that they like their work. Now there are two ways that this works. The more pessimistic and introverted of us sit back and hope that someone will say they like the work. If they do well great, if not well the work wasn’t good enough anyway. The more extroverted among us however look for column inches, if they don’t get any comments they need to know why. They never consider that people are happy, but quiet, with the game. Silence means that they’re not good enough and they need to know why. Traditionally at this point a column would then take the option over which one is the better style. And then try to lecture the other over how to make themselves better. Again, like Banksy, I’ve never held to following tradition as I can see that both have there own drawbacks. The Introvert has the possibility of being ignored, there games lost among others that are sold better. And the Extrovert can alienate there public by constantly asking, even demanding, more and more attention. Ironically not ending traditionally I can’t end with a nice neat Oprah or Springer sound bite. But being on the introvert / pessimist side it does mean I can babble on in this column month by month with no feedback. For all I know everyone skips this section for the more interesting stuff. With only me and the editor even reading what I’ve written. Oh well, ever onwards. This month has been rather quite in the TFGamesite forums, as those of us still in school finish all those important exams and essay. So whilst people like Gunny and CryOfPain tease us with games to come we’ve had to entertain ourselves with only a few, excellent as they are, games. On the RPGmaker’s side, we have the only game I know where the hero is (briefly) a chicken Pojo’s Quest for a Cure. Whilst on the RAGS side we dipped into an experimental idea of Fuearye shared world idea of TF Wars. Where twenty people take turns to transform each other on the forums, only to see there results in an ongoing RAGS game. And finally on the Hypnopic cross over stakes we have another update on Orca’s Demon Town (RAGS). So another month, another column. Please, if you do have any comments, feel free to contact me. * * * Collectively Made: This Month at the Collective by TeraS Summertime! Yay! Well... Mostly yay, but game-wise the Collective slowed down last month some... TinaB posted that she is working on her House of the Future game. She has added some sound effects, music and other things, but does not have a release date as yet. VVrayven, a really wonderful manipper on the Collective posted this on the game she is working on: “Just a little update: still progressing with the game I'm now simply calling Resist. It's both larger and smaller in scope than I had intended. I'm making a "framework" that I can plug future scripts into - with the idea that a second game would be easier. But this first one is HARD!” NandiBear and WightWashed posted an update on their game called The House That Jack Built. They noted that, about 80% of part 3 been put together, but NadniBear and WW have been comparing notes and making sure everything works the way they want it. No release date as yet posted. Sirgiggles posted an update on his game S.U.B.Mission Spa and Resort that he is working on it again and is expecting to release a new version of the game sometime in August of 2009. Benmbedlam posted an update on his game Rough Landing that Rough Landing as of version 1.3 he considers done and completed. Rough Landing 2 is going to be a sequel set three years later, leading on from the four potential endings of the first game. Release date for version 1.3 is not known, but he is hoping sometime over the next few weeks it will be released. Blau is working on a Harem Collection game and is looking for ideas. You can help by visiting this thread: http://hypnopics-collective.net/viewtopic.php?f=11&t=15636 Dromdri posted a new game called For Fear of Little Men. It is a short game which can be found at this link: http://hypnopics-collective.net/cpg132/displayimage.php?pos=-94199 And the thread to comment on or help in the game's development is: http://hypnopics-collective.net/viewtopic.php?f=11&t=15809 And finally for this month, Orcha posted a new version of Demon Town which you can find here: http://hypnopics-collective.net/cpg132/displayimage.php?pos=-86846 And bug reports and comments can be placed here: http://hypnopics-collective.net/viewtopic.php?f=11&t=14673 And that's June at the Collective! Have a great summer! Tera * * * 2009 AIF Mini-comp Results Here are the results for the 2009 AIF Mini-comp. Congratulations to GoblinBoy for taking the number one position. It was a fairly close race overall, especially between 1st and 2nd place where just a couple of votes made the difference in several of the categories. You will also notice that there was actually a tie for 4th place so if you’re one of those people who think that your vote doesn’t matter, think again. I’m sure that you will all join me in thanking all of our participants in this year’s comp for some really interesting games. Remember that it is not too late to send some feedback to the authors telling them what you liked (or even what you didn’t) about their games. It is really the only payment they receive for their efforts, and in some cases it can mean the difference between them writing another game or not. Overall Finish Results 1. In Darkness 2. The Mechano-Menace 3. Obedience 4. BSG: Twenty Two (Tie for 4th) 4. Prosperity of Cheaters (Tie for 4th) 6. Sex is Mental Category: Concept 1. In Darkness 2. The Mechano-Menace 3. Prosperity of Cheaters 4. BSG: Twenty Two 5. Obedience 6. Sex is Mental Category: Characters 1. In Darkness 2. The Mechano-Menace 3. Obedience 4. BSG: Twenty Two 5. Prosperity of Cheaters 6. Sex is Mental Category: Sex 1. The Mechano-Menace 2. In Darkness 3. Obedience 4. BSG: Twenty Two 5. Prosperity of Cheaters 6. Sex is Mental Category: Writing 1. In Darkness 2. The Mechano-Menace 3. Obedience 4. Prosperity of Cheaters 5. BSG: Twenty Two 6. Sex is Mental Category: Technical 1. In Darkness 2. The Mechano-Menace 3. Obedience 4. BSG: Twenty Two 5. Prosperity of Cheaters 6. Sex is Mental Category: Enjoyment 1. The Mechano-Menace 2. In Darkness 3. Obedience 4. Prosperity of Cheaters 5. BSG: Twenty Two 6. Sex is Mental * * * Mini-comp Reviews Mini-comp Reviews by A. Ninny Another year, another mini-comp. I’m happy to see the community still supporting this event. This comp received six entries, which is a good number because otherwise I might not be able to write such detailed and well-considered reviews of all of them. So without further delay, let’s get right to these reviews. BSG: Twenty-two by Madquest8 Overview: This game has a science fiction setting; you play a ruthless space warrior. Humanity is at war with a robotic alien race and your warship has had a bomb concealed on it by a particularly sexy alien lady robot, whom your crew has captured. It’s your job to convince the alien to reveal the location of the bomb before it explodes. You have only twenty-two turns. Review: This is the kind of game that’s got such a cheesy story, if it seemed like it was taking itself too seriously it would fall flat. Instead, you get just enough backstory to know your mission and off you go. The whole setup - you’re in heightened suspense for 22 turns before the game ends - makes the author’s terseness an asset to the feeling of the game. If you waste a lot of time looking for backstory, you’ll die. If you spend a lot of time looking at the scenery, you’ll die. So best to get straight to the point. It’s also a game that you’re going to have to play repeatedly before you solve, and so were I the author I’d want to make sure to offer enough variety in actions that player won’t get bored. I thought the author got part of the way there on that point. There are a fairly wide variety of options, but not different descriptions for similar actions. I found the sex writing to be pretty much comic book goofy, but that didn’t bother me too much given the hokiness of the story. I appreciated that the characters stay consistent to their roles and don’t become generic, not that that’s too difficult considering how cartoony they are. I didn’t really buy the author’s choice as to what the solution would be. It felt like he was trying to use something that players wouldn’t hit upon in their normal AIF command repertoire, but even though I figured it out relatively quickly, it left me scratching my head as to just why that worked. Concept: B-. I guess I’m a sucker for goofy Sci-fi stories. This qualifies. Writing: B. As soon as I saw that this was a space opera, my expectations dropped, but the writing was actually pretty good. Characters: B-. Both of the characters are cartoonish and flat, but still fun. Hotness: C. While the sex scene is in character with the rest of the story, it isn’t one that did much for me. Technical: C. There are some bugs, but overall the game works pretty well. Enjoyment: C+. I think it could have been better if the solution to the puzzle made more sense. In Darkness by GoblinBoy Overview: It’s hard to describe this game without giving too much away. You start the game with no knowledge about the PC whatsoever and slowly, over several small episodes, the game reveals itself and develops into a horror/mystery story. Review: GoblinBoy, as usual, has given us a fully realized story, fabulously detailed sex, and realized deliciously complete technical achievement. The story is really frightening, and the PC’s confusion and fear are palpable from the first moment of the game. Structurally, the game is set up as a series of flashbacks. You get transported to various points in the PC’s past (though not his memory – he has none) in order to learn something about who he is and how he got where he is now. I found it a very immersive way to tell the story. I also felt like the game treated me fairly. I never felt like GoblinBoy was cynically saying ‘I know something you don’t!’ I thought the PC was truly just as in the dark as I was. About halfway through I guessed the answer, and felt like the PC probably did as well – at that point it was more like being drawn through the story by frightening forces unseen. There are two separate sex scenes in the game, both ably written, though not without GoblinBoy’s perennial mention of de-virginification that peppers all his games, and, not without the phrase ‘anal deflowering’ which I can always do without. In his favor, he managed to write a detailed and highly explicit sex scene that really kept the game’s confused and frightening tone consistently running through it, and that extra layer of emotion made it that much more hot. Concept: A. A deeply frightening mystery story, wonderfully executed. Writing: A. Excellent storytelling. Characters: B+. The PC is a total enigma, but the NPC’s step up and fill in nicely. Hotness: A-. Great characterization in the sex scenes, and I didn’t have my normal feeling with GB games that I’m watching the kind of porn where the cameras are too close and the lights are too bright. Technical: A. I found no bugs, and the game was technically ambitious. Enjoyment: A. A game with rich depth and great suspense, and, almost unnecessarily, pictures. Obedience by Rip_CPU Overview: One of two superhero-themed games in this mini-comp; this time you play the supervillian. You’ve captured a superheroine and have her in your lair. What fun do you think you could have trying to break her? Review: Like in In Darkness, Obedience begins with you having no knowledge of your true identity. Unlike In Darkness, though, the PC knows exactly who he is. So there’s no reason - other than to toss in a useless puzzle - for me not to be told right off the bat who I am, who I’ve captured, and what I’m about to do. Once I sort that I’m a supervillian, there’s nothing in my way of getting it on with the superheroine I’ve captured. Not that she’s willing, of course. She gets into it (don’t they always?), but essentially this is a rape fantasy. I had some thoughts on improving this game, the most obvious would be to have another superhero or superheroine that I had to defeat in order to get at my quarry. Another would be to somehow corrupt the superheroine to come to my side and conquer the world (and, as a bonus, initiate action in the sex scene). Concept: C-. This game is simplistic to the point of being meaningless. Writing. B-. I didn’t have as big a problem with the quality of the writing as the story itself. Characters: C-. The characters were really generic. Next time, create a bigger difference between the superheroine and the villain. Hotness: C-. The non-consensual aspect and the lack of emotional quality mostly did this in for me. Technical: C. Some opportunities to improve the tech in this game were missed. For instance, give the player the opportunity to manipulate the apparatus restraining the girl. Enjoyment: C. This game simply lacks the impact to make it very enjoyable. The Mechano-Menace! by A. Bomire Overview: The other superhero-themed game. In this one you play Aegis, a superhero from __. Along with the superheroine Marvela, you are hot on the tail of MechanoMan, an evil genius who commands an army of robotic hell hares to try to vanquish you. Review: This is actually a pretty cool adventure game condensed into mini-comp size, with a hot sex scene to boot. It has a combat system built in – you have two attributes that you track as you battle the evil MechanoMan in his secret hideaway lair: health and shield. If your health falls to 0, you lose the game. Using shields too much drains you so your moves are less effective. This all seems to work quite well, and didn’t confuse or hold me up. As to the characters, I’m not familiar with the comic books that they are drawn from, so I can’t say how well they conform to their sources, but Bomire has graciously provided background on them within a ‘help’ menu, and the characters don’t behave contrary to these descriptions. From the description, it appears that Marvela doesn’t actually have any superhuman powers; all her abilities are gained from training. Since she doesn’t have powers, when it comes to the sex scene, an opportunity for superhuman sex is mostly lost, and in the end, ignored. Aegis does have super strength, and Bomire does mention that he uses it to lift her, but I didn’t feel like she had much of a reaction. Perhaps she should have emphasized how much she appreciates being fucked by super-strong dudes and that could have been a focus for making the sex scene more in character with the rest of the game. Concept: A-. A fun little comic book adventure that comes to life nicely. Writing: A-. A. Bomire has a great ability to use his writing to create lively settings and characters, and this game is no different. Characters: B. The characters are written with a definite slant toward humor, and it works well during the battle scene, but less so during the sex. Hotness: B: The sex writing is immersive and detailed, but I felt it didn’t take advantage of the characters well enough. Technical: A-. This game was well put together, not as ambitious as his WWE game, but it certainly works cleanly and the battle scene is intuitively simple. Enjoyment: B+. Definitely a fun game, but I wished the sex scene had been a little less ordinary. Sex is Mental by Rabbi Overview: You play a patient in a mental institution. You’re hot for a nurse and are about to get a new crazy roommate. You need to somehow use the roommate’s craziness to get in the nurse’s good graces. Review: I had to suspend my disbelief in a big way just to get into the concept of this game. Usually I don’t have a problem with that – I’m good at immersing myself in even a simple game’s world, but in Sex is Mental I was asked over and over to believe more and more unlikely and outlandish concepts as the game progressed. I’m a patient in a mental hospital and I have the hots for a nurse. I can easily buy that. I get a new roommate who I manage to learn goes bonkers when he hears the word ‘taxi’. Well, ok…. keep going… Of course, I say ‘taxi’ and end up in the infirmary with said nurse who is suddenly eager to put out. Riiight, I think you lost me along the way there, sonny. Sorry. There are just too many improbable things going on. Then some weird thing happens at the end that is so poorly explained that I can’t figure it out. At least I made it to the end. The whole game is just tossed together from a shake of this and a dab of that, and the characters don’t offer much more conviction that they know why they’re there, either. Add to these problems the fact that the ADRIFT coding is full of holes and that the spelling and grammar are pretty miserable, and you have a rather unsatisfactory experience. Concept: D. If this game had limited the oddball ideas to just one, it could have been successful. It just asked me to accept too many. Writing: C. I appreciated that there were a few humorous moments in the game that helped salvage the writing, but the concept dragged it down. Characters: D. None of them came to life or seemed realized. Sex: D. Unfortunately, the sex is very clipped. Precious little redemption here. Technical. D. The game is buggy. There are a few guess-the-verb issues and lots of grammatical glitches. Enjoyment. D. Not very enjoyable. Prosperity of Cheaters by Rip_CPU. Overview: You’ve got the hots for a girl, but she’s got a boyfriend. You have a girlfriend, so if you want to score you’re going to have to cheat and convince her to cheat as well. Now’s your chance: it’s the wildest party of the year. Review: I’m going to review this game as it is, ignoring for the moment that it violated the mini-comp rules by using three non-player characters, instead of the maximum two. I penalized it for this when I voted; no need to penalize it twice. This is a nice little game, not too ambitious, but it works well in an old-fashioned mini-AIF kind of way: a simple setting, a straightforward goal, an endlessly repeating script to give you plenty of time to figure out the solution, and a puzzle that isn’t too taxing, but one that has six different outcomes. If this weren’t a mini-comp game, instead of two sex endings and four non-sex endings, you could have different pairings and even orgies. Maybe Rip_CPU will go back and add these later – it would make for a fun little T&AIF. The game doesn’t concern itself too much with characters or background. The PC expresses his feelings in a basic way about the boyfriend of the target girl (he’s a jerk, of course), his own girlfriend (gotta get her out of the way somehow), and the desired girl (hottie), but that’s all the depth we get on them. Still, even though we don’t get much characterization, it works with the casual sex college kid attitude that permeates the game. The sex writing is decent; there are two different sex scenes, and they’re quite different from one another. I think it’s worth your while to find both. Concept: B. It’s a simple idea, executed reasonably well. Writing: B. Concise, simple to follow, writing that doesn’t challenge, but still provides enough detail to carry the story. The writing could have been improved if the party atmosphere was noisier – the game has scripts constantly running, why not add some party activity in the background? Characters: C+. They’re certainly not profound, but there’s enough here to work with. Hotness: B. Two different sex scenes, nicely detailed, with several different responses for each action. Technical: C. I found quite a few bugs, commands that gave no responses, objects that didn’t disambiguate properly, and overall I think the implementation could have been more robust. Enjoyment: B-. Again, I found this to be a simple concept built into a fun little game. Mini-comp Reviews by ExLibris Games are listed in the order that I played them, and some of the comments reflect that. BSG: Twenty Two Through no fault of its own, BSG starts with a few strikes against it simply because of my own my own subjective prejudices. Firstly, as a rule I don't like regular fan-fiction very much, but after playing this game I realised that it's preferable to fan-fiction with the names slightly changed. Secondly, I'm not too keen on games with time limits, especially when the time is advanced by nearly any action, even something as innocuous as examining an object. Generally that means the annoyance of having to undo a lot, but in this case the annoyance was increased by the fact that undo was disabled. I can sympathise with the desire to create tension, but when it comes to not being able to undo after accidentally wasting a turn through a typo, it's a bit much. The time limit is an indirect cause of my third quibble, the huge infodump at the beginning. A lot of the stuff in the infodump could have quite happily been placed in a readme file (BSG was also the only game without a readme file, which I'm afraid is another strike against it). As far as the story related information goes, I think there are better ways to provide it. Obedience was a good example of this, as it drip-fed the required information, allowing the player to slowly submerge into the character, instead of just dumping everything on the player in one load. The load in this case felt particularly heavy as well, not so much nudging the player in the right direction as leading them by the hand. My prejudices against the game were increased by the fact that Tricia's dialogue was in a different colour to the rest of the text. Normally I'd think that was a good idea but, like probably 50% of the population, I had white set as my background colour. Consequently, making the dialogue yellow was not an inspired choice unless the aim was eyestrain. Changing the colour was easy enough, but it was just one more little annoyance. Finally, run on sentences are bad, m'kay. Splicing them with commas or chaining them together with ellipses doesn't improve readability either. The reason I mention all of this, is that I really had to force myself to play this game through to completion. And I'm glad I did as there is a surprising amount of content concealed under that rather unappealing exterior. Tricia is certainly one of the better implemented NPCs in the competition, with a wide variety of responses to both conversation and especially actions. Also, while the execution didn't appeal to me in a lot of ways, I felt that the basic concept was a good one. Overall, I'd classify this game as something of an ugly duckling. It doesn't quite grow up into a beautiful swan when you get into it, but there are certainly some features of interest. Prosperity of Cheaters It says something for the prevailing themes of this minicomp that despite casting the player in the role of someone who happily drugs people and cheats on his girlfriend, Cheaters was actually one of the 'lighter' games. I think it's pretty safe to say that of the two games the author contributed to the minicomp, this is the one that was finished second. Compared to Obedience, it feels unfinished and lacks the same degree of polish. Objects mentioned in room descriptions aren't always implemented (a pet peeve of mine) and the sex scene (or at least the one I've found so far) feels fairly perfunctory. There were also a few bugs, mainly actions that could be repeated when they shouldn't (e.g. talking to Beth or using the phone). Cheaters does breach the rules as far as characters go, and I've reflected that in where I've ranked it. But I think I would have ranked it quite low in any case, as characterisation is one of the areas where the game is lacking. There's no ask/tell system, which wouldn't be so bad except that talking to characters rarely produces anything meaningful either. The only real source of characterisation is a few snippets of conversation that you overhear while standing about in the main room. Of course sometimes a little is enough, and hearing their respective opinions on Twilight was certainly enough to make me want to pick Beth over Kirsten. A consequence of the limited characterisation is that there is no real relationship built up between the PC and Bethany. The PC is told that she's hot, but that's about it. If it wasn't for the Twilight thing she and Kirsten would be virtually indistinguishable. Beth really needed more spotlight time than she received to sell her to the player as a desirable lust object. As it was, when the sex scene made its appearance, Beth moved from being 'girl you've just met' to 'girl you're having sex with' very abruptly and unconvincingly. From memory the conversation ran something like this: PC: "Oh dear, my girlfriend and your boyfriend are having sex." Beth: "Yes, that is a shame. Perhaps we should have sex also?" PC: "Okay". I'm exaggerating a bit, but that's the overall impression I have of it. As mentioned above, the sex scene is comparatively brief and one of the weaker entries in the competition. The lack of characterisation led to a sex scene that had no real power attached to it. If it had been written differently it could have been carried by simple physical lust, but that didn't happen either and the scene felt like something of a dud. Overall, I'd classify this game as a might have been. Having multiple endings is always a plus, and I feel that the basic concept was a good one, though not necessarily for a minicomp game. It also needed more time and polish to properly realise that concept. In Darkness Wow, what a downer. Although looking at Goblinboy's other games, delivering a happy ending doesn't seem to be very high on his list of priorities. Actually, calling In Darkness a game is a bit of a stretch. There aren't any real choices to make or puzzles to solve. The player merely has to work out what action will trigger the next 'page' of the story, making it interactive fiction in the most literal sense. It's somewhat subjective, but I think that the storyline would have worked better as prose rather than a 'game'. IF has a much closer identification of reader with protagonist than traditional fiction does. Consequently as a player I enjoy games where I feel in charge of the PC's destiny, rather than merely trudging towards a depressing and predestined fate without any hope of reprieve. While playing In Darkness you don't even get the chance to struggle against the inevitable. The decisions the player makes don't have any effect on the outcome, things just happen the way they happened. It didn't help that it was fairly obvious how the game was going to end from quite early on, which cast a shadow over what would normally be the fun parts of AIF. I'm not completely opposed to telling a story like this in IF, but because of the way it was executed I didn't find it particularly enjoyable. On the other hand you do get to kill Mike... er I mean Jeff, so it's not all bad. In technical terms, it's what we've come to expect from a Goblinboy game. That would normally be high praise, but after his nth well executed game it doesn't get him as much credit as it might. Actually, something that probably decreased my enjoyment is how similar In Darkness is to previous Goblinboy games, primarily thematically but also in some specific ways. As I've already implied, Jeff is a similar character to Mike from the School Dreams series. Additionally, the basic premise is quite similar to Ghost and the downer ending is reminiscent of The Casabian Virus. The difference here is that as the protagonist I felt restricted, even more so than in The Casabian Virus or The Key to Eternity where the ending is predestined and the opposite of what the PC wants. When playing In Darkness I wasn't really conscious of being able to push against the flow of the story at all. I felt more like a spectator than a participant. One final nitpick. Although I'm no expert in American law, it doesn't seem that likely to me that the PC would get the chair for what are two textbook cases of voluntary manslaughter. More dramatic, yes. More accurate, no. Oh, and the electric chair isn't actually used very much any more either. Suicide would have been a believable alternative ending, which probably sums up how depressing I found this game. Obedience First things first. The comics geek in me wants to point out that Ben Urich was the author of 'Legacy of Evil', not Ben Ulrich. Sorry about that. Obedience was one of two superhero themed games in this year’s minicomp, though it takes the opposite tack to The Mechano-Menace!. Coincidentally it also has a very similar basic premise to BSG 22, but I think it managed to execute it a lot better. In particular, I found the way in which information about the PC and his aims is slowly drip-fed to the player to be very effective, and a prime example of the virtues of showing rather than telling. The subject matter isn't something that would immediately appeal to me, but this introduction allowed me to slowly submerge myself in the character. This was something that didn't happen with BSG 22's abrupt infodump, and consequently I was more resistant to that game. Having so many items hidden under other items did get a bit repetitive, but there were plenty of warnings about that so I'm not going to complain too much. Objects mentioned in the room descriptions were also consistently implemented in the game, which is always nice to see. Obedience also delivered one of the more satisfying puzzles of the competition, in the shape of finding your way into the PC's secret lair. There wasn't a good deal of obvious characterisation, but what there was went a long way. Due to the way in which the PC was characterised I was never in doubt about his motivations or desires. The character of Polaris was a little flat, but given her role in the game that was perfectly sufficient. The premise of the game also gives the player concrete reasons for wanting her (reasons other than just the fact that she's hot, I mean), rather than just letting the relationship between the principals fend for itself, as seemed to happen in Prosperity of Cheaters or The Mechano-Menace! The sex scene was among the better written, and was possibly the best implemented as well. The addition of the PC's 'tools' gave it that x-factor required to distinguish it from the rest of the pack. The many different possible variations and outcomes added extra interest as well, and kept the scene from becoming mechanical or predictable. Overall, I think Obedience is a good game rather than an outstanding one, but it's a game that is consistently good in every area. The only thing I can really say against it is that it had a few too many typos. Sex Is Mental Somewhat disappointingly, this was the only game by a new author in this year’s minicomp. Rather more disappointingly, it also played very much like a first game as well, with a number of rookie mistakes on display. As an example, on my first playthrough I got as far as the ward before giving up. The problem was that the description of the room failed to mention any of the objects within it. I did correctly guess that there was a bed, which was described when examined (unlike either of the beds in the first room). The object that is needed to progress from this point is briefly mentioned in a cut scene, but unless you pick up on that clue and investigate you’ll be a bit stuck. Like I was. The second barrier is that even if you know you’re supposed to be looking for a glass of water, you won’t find it unless you ‘x glass of water’. Neither ‘glass’ or ‘water’ are apparently listed as synonyms for the item. The third barrier is that old classic, ‘guess the verb’. You then have to do something with the glass of water, and it involves a specific verb and none other. Reasonable synonyms such as ‘push’ don’t work. To be fair, these are the kind of mistakes that a first-time author is likely to make and they’re nothing that can’t be remedied with experience. More subjectively, there were some formatting choices that made the game less readable for me. In particular there was an over-abundance of blank lines and white space. Another thing that I found interfered with readability was prefixing each line of dialogue with the name of the person speaking it. That just looks weird to me, and made the dialogue seem even more stilted and artificial than it was. A number of the games in the minicomp suffered from insufficient proof-reading, but this was the worst offender. I noticed many instances of missing punctuation, random capitalisation, typos and so on. Annoying, but reasonably straight-forward to fix. On the plus side, I thought the concept was an original one and quite well supported by some little touches in the writing. And all credit to the author for having the perseverance to finish writing his game. That’s possibly the most important talent that an author needs, everything after that is just polish and can be learned. I hope the author is strong enough to take any criticism he receives and use it constructively in the next game he produces. The Mechano-Menace! The only game in this year's minicomp to cast the PC in the role of a 'good guy'! Given that I see the entertainment value of AIF primarily in terms of escapism and wish fulfilment, and my wishes don't run to finding my best friend having sex with my wife (to pick just one example), this was a welcome relief. The greatest strength of The Mechano-Menace! was the depth and inventiveness of its technical implementation. The most obvious example is the PC’s shield power, and the shield and health stats that are tracked in the statusbar at the top of the screen. However, there were a lot of other little touches that made the game a pleasure to play, from the extensive help system to alternate means of solving problems to the implementation of amusing responses for various actions a superhero might try. Even better, the game ran perfectly smoothly with no bugs or problems observable. I didn’t even notice any spelling mistakes. The two-part combat with the robots was also very well implemented. I was a little disappointed that the solution to the robot problem could be as simple as just hitting things, although that is certainly in keeping with the superhero genre. The villain is suitably mad, and when you add in robot rabbit ninjas and Herr Hare, this scene was a lot of fun. Unfortunately in comparison to Mechano, the character of Marvela seems a little... bland. Marvela doesn't get a great deal of dialogue and what she does get is largely reactive, especially in the first half of the game so, she never builds up much of a 'presence'. The relationship between her and the PC isn't given any real development either, so when the story shifts from beating up the bad guy to Marvela's bedroom it feels quite abrupt. This something that I also noticed in one of A.Bomire's games from last year's minicomp (Working Late). What was really needed was another scene of some kind to develop the relationship between Aegis and Marvela, or at least something to suggest they were attracted to each other. The sex scene itself was very well written, probably the best of the minicomp. However, as mentioned above, the lack of any real build-up robbed it of some of the punch it could have had. Something else I would have liked to have seen was something a little unique to make the scene more memorable, especially given the fact that both of the participants were superheroes. I'm sure there's a few interesting things Aegis could do with his shield power... Overall though, The Mechano-Menace! was one of my favourite games in this year’s minicomp. A.Bomire is one of the best when it comes to both writing and technical polish, and it’s a pity that it’s been so long since he’s released a full length game (hint hint) Mini-comp Reviews by Gary Plume BSG: Twenty Two This game was annoying. Violent domination sex is not my cup of tea, and the threat of being bombed into oblivion put another damper on my enjoyment. The NPC laughing at the PC was actually a powerful technique, but it unfortunately increased my revulsion of the game. The main puzzle seemed to be a conversational maze that you were supposed to follow, but the constant restarts to try to find a brute force way of exploring all dead ends annoyed me. Eventually, I gave up because the path that seemed to be correct didn't seem to win the game and then I had to postulate following combinations of pathways which wasn't fun. What does this game want from me? The titillation over frustration quotient was too low to make me come back for more after each bomb blast. I gave up trying to win. I don't remember where I read it recently, but someone recommended NOT trying to quote the onomatopeia of an orgasm. This game shows me exactly what a terrible technique it is. Prosperity of Cheaters This had nice gameplay if a bit simplistic in manipulating humans and timing their routines. I didn't mind the rule violation because I'm not a stickler by nature. Sex with the object of your affections seemed anticlimactic. It was fun trying the game over to reach all six endings: a nice device to keep me coming back. There is a technical problem with talking to Beth in the bathroom in scenario 6 - her discovery of the boyfriend's infidelity repeats. In post-mini-comp modifications, wouldn't mind playing for a menage-a-troi ending or even a lesbo voyeur ending. I was annoyed that the punch couldn't be used to spike drinks. Perhaps a solution could be a warning that "The purple color of the punch is going to be a dead giveaway if you spike drinks with it." "Ask ____ about ____" provoked puzzling nonresponses. In Darkness Interesting start concept from initial scene and buildup of background to romantic love that goes beyond "You want to bone this textual chick because she's hot." Flashback device with objects were linear and not too adventuresome but an understandable and effectively jarring device in the minicomp limitations. I appreciated the effort to make the flashbacks different, especially the braid, with some variation in how the charms disintegrated afterward. The first sex scene felt very hot to me mostly because of the tentativeness and restraint of the PC and the corresponding flirtatiousness of the NPC. A delicate tug-of-war. The game itself functioned like one of its talismans and transported me back to a time when I was a horny teenage virgin with nothing but fantasies. The part where the PC creams in his jeans and the NPC giggles was the most memorable scene for me out of all the entries. Contributing to the heat was the challenge of doing/saying the right thing without getting too guess-what-author-wants, although I almost gave up getting my pants off. The sad and mostly predictable ending was a boner-killer, but evoked in this reader the intended feelings of jealousy, betrayal, rage. I guess the author should be applauded for creating pathos, but I would've just liked a happy ending. In fact, I was so inspired, that I am now porting the first sex scene into Inform, partly to see how difficult it would be to render the NPC. Technical: got stuck after touching braid the second time since the replay didn't succeed in "ask jemma about friend" - kinda like getting stuck in the "friends zone". I somehow successfully did "fuck pussy" before final ending which made it confusing as the plot seemed to depend on this being refused. Mechano-Menace This was a funny and well coded and well written game. I liked the novelty of the spicy latina superhero and her Spanish exclamations. The enemies were quite funny. The Health/Shield meter was an interesting technical achievement, but not really a management challenge during the fight. It would have been fun to work in the scene where the supervillain talks too much and gives away the lynchpin of his plan. I have no idea where those damn last 10 points are. It's probably because I only used brute force on Herr Hare without anything more clever. The sex was well written, but picturing two musclebound goody two-shoes together created a comic distance that shielded me from some of the hotness. Obedience This was a fun segue from mundane to extraordinary. Again, domination is not my cup of tea, but this was certainly better than BSG. Being the supervillain created some fun, but the toys seemed to become useless too quickly. Aren't there more ways to use my supervillain powers? Sex was hot but again not really consensual. The scale of obedience that the XYZZY-summoned author seemed to allude to was too subtle for me to grasp; perhaps a status bar meter would help me understand what was helping or hurting my cause. The "look under _____" puzzles seemed awfully simplistic for game play. I'd have preferred a secret narcissistic closet/shrine for the uniform. Sex Is Mental This was a weird twist on an old fantasy. What red-blooded male hasn't wanted a nurse fantasy? Even though we had very little interaction with the first NPC, I got some nice insight into the dog-eat-dog institutional life and the craziness of the PC. I found this the weakest game in terms of technical implementation. What about groin as a synonym for balls? Annoying grammatical errors and inexplicably capitalized words (Jacket, Guards, Corner, Dirty, Knock) bugged me. I got stuck in the ward and almost gave up trying to find a legitimate excuse for Mary to stay - I'm going to blame it on guess-the-verb and a nearly invisible cup of water. Sex was okay, if somewhat perfunctory. Technical: Where's my bandage? In an empty room, I feel more acutely aware of the scarcity of resources. The least I should be able to do is use the broom to sweep the floor, drink the water, lie on the bed, and masturbate. Some amusing bugs show up if you try doing some things with the NPC while she's out of the room. A Case for In Darkness by Softiron I'm not near as grumpy as I was after playing last year's mini-comp, and the reason is GoblinBoy. New and aspiring authors, please take note: you don't need to make an epic to create a game that will be praised and remembered. How does In Darkness prove this? Let me count the ways: 1. There is no pre-game info dump. It is very tempting as an author to provide exposition to bring the player up to speed with the characters and the plot. In most cases, this is entirely unnecessary and defeats the purpose of the medium. This is "interactive" fiction. GoblinBoy allows the player to gradually learn about the main character by exploring his surroundings and talking to other characters. 2. The few puzzles that exist fit into the story. They are clued, but not so much that they cease to be puzzles. Take, for example, a minor paragraph early in the game: You look round, taking it all in. It appears to be late spring. There are flower beds with multi- coloured blossoms. Lots and lots of grass, of course, a deep, rich green. There are a couple of trees nearby, and it seems there must have been some strong winds recently, as a fairly large branch has fallen to the ground at the base of a nearby tree. Various people move around in the distance, doing all the things that people do in a park. It’s a fairly innocuous passage, there to provide setting. Initially, one would not think a clue to a puzzle would be here, and that’s the way it should be. Imagine if it instead read like this: There are a couple of trees nearby, and it seems there must have been some strong winds recently, as a fairly large BRANCH has fallen to the ground at the base of a nearby tree. Not only is the first version not insultingly easy, it forces the player to share the motivations of the PC. It’s now MY idea to pick up the branch, and not the author’s. This helps build identification which is key in bringing the player into the story. 3. The sex serves the plot. There is a reason I think Basic Instinct is a better movie than Pirates! Now, the latter is a fine movie, but all the costumes and set decorations and cinematography is all there to serve the sex. There’s nothing wrong with this; I like my straight porn just as much as the next guy. But there’s just something special about a great, realistic story that is enhanced with adult situations. The sex in In Darkness is never gratuitous, but that doesn’t mean it is any less sexy. In fact, I would contend the opposite is true. My only criticism of the entire game is that the primary sex scene uses the chick.t sex daemon, which disrupts mimesis. 4. Nothing feels excessive. The best songs always seem too short. The best movies are over too quickly. And some of the best fiction is over before you can blink. There is nary a wasted word or unnecessary subplot to be found. And despite only being allowed three rooms and three characters, GoblinBoy made his world seem much larger. This did not feel like a competition game, yet it is the type of game that is attainable for any new author. Of course, just because a game is solidly made does not mean it will be to everybody’s taste. If you prefer AIF that acts more as a role-playing game (e.g. School Dreams 3), then In Darkness will certainly not be to your taste. GoblinBoy has written a dark piece of adult fiction and programmed it into TADS. Like reading an actual piece of fiction, you have no real control over how the story unfolds or how it ends. But the experience is more than simply turning pages. By having the reader manually explore the environment and interact with it, the story can be internalized, thereby providing more emotional impact. For those who played Adam Cadre’s Photopia, it is quite apparent that story would have failed as static fiction. It is much the same here, and I applaud GoblinBoy for not treating his work of fiction like a toy box, allowing the player to mess with it at will. This may be a mean thing to say in light of how much work was put into SD3, but due to the reasons listed above, I strongly believe this is the best game GoblinBoy has made, and it has supplanted Blowjob Drifter and Memories Are Made Of These as my favorite AIF game of all-time. And now, for a couple of my own awards. Hottest Individual Sex Scene: This would go to me nailing an “influenced” Bethany in front of several partygoers. Suggestion to Rip-CPU: more games like this one, tightly-packed with multiple endings. If not for all the misspellings, grammar issues, and bugs, this would have finished in 2nd place on my ballot. Paul O’Brian Award: To Mechano-Menace, for rivaling the fun factor of Another Earth, Another Sky, only adding some gratuitous sex at the end. Can’t complain about that! Or the upcoming sequel, I hope. * * * Coder’s Corner There have been more than a few examples of windows in AIF games, but more often than not they seem to be just static objects with a single description. They do not have to be that way. It is possible to create a window which functions like they real thing. Something that can be used to look into the other room and show the true state of that room as well as the people or objects it contains. That was the task that I set for our authors this month. Create a window between two locations that the player can look through to see the other location. Both locations should be actual “rooms” that the player can get to. In addition, the description of looking through the window should reflect changes in the other location. For instance, if the player takes something from one room to the other and drops it, he should be able to look back into that room later and see the new object. I’ll leave the particulars in your imaginative hands. TADS 2 Segment by A. Bomire In this month's "Coder's Corner", we will be exploring seeing objects that are not in the same location as the player; i.e, in another room. This can be handy for spying on sunbathing women through a window, watching someone through a security camera, or just in general looking at something that is not in the same location. There are a couple of ways of handling this: 1) The easy way, or 2) The harder but much more effective way. Guess which one we are going to do? Sorry, that was a trick question. I'm actually going to describe both methods! To begin with, let's set the stage. In our sample game, the player character is involved in an investigation, and the game takes place in your typical interrogation room. There is an observation room with a piece of one-way glass looking into the interrogation room. From the interrogation room, the glass appears to be a mirror but from the observation room the player can see everything that is happening in the interrogation room. Let's create our two rooms: startroom: room sdesc = "Observation room" ldesc = "This is the observation room, where you can observe what is going on in the interrogation room to the south. There is a large window made of one-way glass on the south wall, allowing you to see into the other room. " south = Interrogation ; window: fixeditem, seethruItem location = startroom sdesc = "window" ldesc = "You can look through this window to see what is going on in the interrogation room, but from there the window appears to be a mirror. " noun = 'window' thrudesc = Interrogation.lookAround(true) ; Interrogation: room sdesc = "Interrogation" ldesc = "This is the room that is used to interrogate suspects. There is a large mirror on the north wall next to the door leading out. The room has a simple table and chair, used in performing interrogations. " north = startroom ; mirror: fixeditem, seethruItem location = Interrogation sdesc = "mirror" ldesc = "This big mirror is actually a window through which observers in the outer room can look to see what is going on in this room. " noun = 'mirror' thrudesc = "You just see yourself. " ; table: beditem location = Interrogation sdesc = "table" ldesc = "This is just a simple metal table - nothing fancy that a potential suspect can use as a weapon. " noun = 'table' adjective = 'simple' 'metal' ; chair: chairitem location = Interrogation sdesc = "chair" ldesc = "This metal chair goes with the metal table, and is also of heavy construction to keep a suspect from breaking it. " noun = 'chair' adjective = 'metal' 'heavy' ; Pretty simple, right? You'll notice that I've placed a window in one room and a mirror in the other, both of which are objects of TADS class seethruItem. A seethruItem is a special object class for which TADS has predefined the ability to "look through". When the player types "look through window", TADS will find the window object and execute/display whatever is defined for that object's thrudesc property. For the mirror, I defined this to simply tell the player that he can see himself. For the window, I have TADS display what the player would see if he were in the interrogation room and executed the "look" command. This is the easy method of performing this task. However, it is of very limited effectiveness. To begin with, looking through the window displays something like this: Interrogation This is the room that is used to interrogate suspects. There is a large mirror on the north wall next to the door leading out. The room has a simple table and chair, used in performing interrogations. While this accurately displays the room, and any visible objects in the room, it really isn't a good description. After all, it describes the mirror - something which the player cannot see from where he is (on the other side of the mirror). Furthermore, any objects in the interrogation room aren't really "visible" in the sense that the player can examine them individually. For example, from the outer room the player cannot "x table" or "x chair". If he does, he will get a message indicating "I don't see that here." A much more effective method of doing this would be to make all of the objects within the Interrogation room visible from beyond that location. To do this, we would need to play around with a property of TADS objects called isVisible. (For more information about this, please see the TADS manual, Chapter 4 - Parsing Fundamentals. Also, see Chapter 6 - The Parsing Sequence, and Chapter 7 - Parser Summary and Quick Reference.) The isVisible property is accessed like this: object.isVisible(vantage) Where object is the object which we are checking to see is visible, and vantage is the vantage-point or viewpoint from which we are checking. Usually, vantage is a character (and almost always the player), but you could use it to see if something is visible to a completely different object. For example, in our scenario above, the chair is visible to the table and vise-versa, but not to the player. This property returns a boolean (true/false [nil]) response. How does TADS determine this? Well, it goes through a series of tests to see if an object is in the same room as the vantage (let's just say the player to make this simpler), is that object within another object and if so is that object open (like an open box containing things), and other tests like this. It can get pretty complicated. For us, we are going to make it simple. If the player is in the observation room, and the object is in the Interrogation room, then that object is visible to the player. If the object isn't directly in the Interrogation room, then normal isVisible processing will be done. The good thing about this is that if an object is in/on another object (say, on the table), then the normal processing for TADS will be to check to see if the table, for example, is visible, and if it is then the object resting on the table will be as well. So, we don't have to worry about drilling down into object contents - it will automatically be handled. We could modify every object in the game, but instead we are going to modify the big cahoona of the TADS object hierarchy, the thing object: modify thing isVisible(vantage) = { if (vantage = Me and Me.location = startroom and self.location = Interrogation) return true; else pass isVisible; } ; Now, if we make that change, the table and chair should be visible from the observation/startroom. However, testing reveals that we are still receiving the message "I don't see that here.". Why is this? Because TADS is attempting to work faster. Whenever the player types a command that acts upon other objects, TADS goes through all of the objects that match the noun phrase used, and whittles them down to just objects that are in the same room as the player. From those, it then whittles away the ones that are out of reach - for example inside a closed, tranparent container. This is something that we talked about in this newsletter's earlier series "Programming Erin", when we attempted to place a phone call to Erin while she was out of the room. But, it doesn't hurt to go over this again. The list of objects that are in the same room as the player is the validDoList (for Valid Direct Object List). Now here's the somewhat tricky part - if you set the value of this list to nil, then you would assume that this means there are NO objects that are valid. This isn't true. Instead, TADS then assumes that ALL objects are valid, and begins checking every object in the game to see if it is within the player's reach. Odd, right? Yes, but it is done this way for the exact reason that we are using it - to allow us to bypass the visibility of an object and allow the player to act upon it if we want, without having to rewrite a bunch of code. (For more information on the use of validDoList and its companion validIoList, see the in-code documentation in ADV.T and the TADS manual, Chapter 4 - Parsing Fundamentals and Chapter 6 - The Parsing Sequence.) As we did earlier, we can modify the validDoList for all verbs within the game by modifying the root deepverb. However, in this case this may not be what we want. After all, Mike Roberts designed the validDoList and validIoList functions to act as they do for a reason. We will not be allowing the player to act upon any object in the Interrogation room other than to view it, so the only verb we really need to alter is the one that is used when the player examines something (ex. "x table"). This is the inspectVerb: modify inspectVerb validDoList (actor, prep, iobj) = nil ; Lastly, we need to alter what is displayed when the player looks through the window in the observation room. Instead of just parroting what the player would see if he were actually within that room, we will customize it. We'll need to paraphrase the room's description, and then list any objects of interest in the room. This can be somewhat involved. After all, we have the room itself, then any objects which may be on the table, and any objects which may be in the chair. If we had more furniture in the room, we would need to worry about that as well. And we also may need to worry about things inside of other things, such as a picture inside of a box that is sitting on the table. These can all add complications to your viewing. Or not, depending upon how detailed you wish to be. For us, we are going to worry only about superficial items; e.g., in the above example we would say that a box is on the table, but not the contents of the box. TADS has built-in routines to list the contents of objects, but they would not necessarily work for us. For one thing, the routines do not list actors/characters, so any characters we have in our room wouldn't be listed. So, we are instead going to write our own routine, which I am going to call listObjects. This will involve writing a function that goes through a list and outputs the individual entries, with a comma after every entry except the last one. But, we don't want to list any of the Interrogation room's normal contents, which are the mirror, the table and the chair. So, we will ignore them. First, let's write a routine to print out a list of items: listObjects: function (objList) { local i, tot; tot := length(objList); if (tot = 0) return; for (i:=1; i<= tot; i++) { "<>"; if (i = tot - 1) ", and "; else if (i < tot) ", "; } } Now, we can use this function to list the contents of the Interrogation room. We will first look in the room itself, then what is on the table, and finally what is in the chair. The objects within all of these will be listed in the contents property of each object. All of this will be done when the player looks through the window: window: fixeditem, seethruItem location = startroom sdesc = "window" ldesc = "You can look through this window to see what is going on in the interrogation room, but from there the window appears to be a mirror. " noun = 'window' 'mirror' thrudesc = { local i, objects := [ ], x; "Through the window you can see the interior of the interrogation room, including the table and chair. "; //List the contents of the room, if there are any for (i:=1; i<= length(Interrogation.contents); i++) { x := Interrogation.contents[i]; if (not (x = mirror or x = table or x = chair) ) objects := objects + x; } if (length(objects) > 0) "Inside the room you can see <>. "; //List the contents of the table, if there are any objects := [ ]; for (i:=1; i<= length(table.contents); i++) { x := table.contents[i]; objects := objects + x; } if (length(objects) > 0) "Sitting on the table is <>. "; //List the contents of the chair, if there are any objects := [ ]; for (i:=1; i<= length(chair.contents); i++) { x := chair.contents[i]; objects := objects + x; } if (length(objects) > 0) "Sitting in the chair is <>. "; } ; Now that we've written a routine to see into the other room, we need some objects to view. An appropriate addition would be someone who needs to be interrogated, like Erin. And of course, the ubiquitous glass of water: Erin: Actor location = chair sdesc = "Erin" adesc = self.sdesc thedesc = self.sdesc ldesc = "Erin is a lovely young woman. " noun = 'erin' ; glass: item location = table sdesc = "glass of water" ldesc = "This is an ordinary glass of water. " noun = 'water' adjective = 'glass' 'glass of' ; If everything has been done right, the player should be able to see both of these objects through the window, as well as examining them individually. TADS 3 Segment by Knight Errant Welcome once again to Coder's Corner. This week's programming issue is windows. Unlike doors, TADS 3 doesn't have a built-in class for windows. Instead, we'll have to make do with a combination of a SenseConnector (to connect the two locations) and Fixture (because we don't want to allow the player to remove the window). First, create two rooms that you'll want to connect ... for example, an indoor and an outdoor room. Indoor rooms come complete with walls, so we'll just place the inside half of the window on one of the walls. We'll need a Fixture in the outside room to represent the building, that we can put the outside half of the window in. It can work like this. Window : SenseConnector, Fixture 'window' 'window' “It's an example of a window.” connectorMaterial = glass locationList = [outsideRoom, insideRoom] ; For any sense connector, the connectorMaterial determines what senses can travel across the connector. “Glass” allows sight but nothing else. “Adventium” blocks all senses. “CoarseMesh” allows all senses including touch, but does not allow movement of objects across. “FineMesh” is transparent to all senses save touch. “Paper” blocks sight and touch, but allows sound and smell. Here, we want glass. With the sense connector in place, we can now see from room to room, and objects in each room will be visible to each other. However, any object viewed through the window will use it's remoteDesc or remoteSpecialDesc. That means you'll have to customize these properties for any objects that may be viewed from from room to room. The easiest way to deal with this is to modify Thing to have an appropriate remoteDesc, like this. modify Thing remoteDesc = “<> is in <>” Of course, even if you modify Thing to give a decent generic description, you can always also give an individual item a more specific remoteDesc of it's own. That's all it takes for a window you can look through. If you want to make it something you can open, add an Openable class. If you want to be able to climb through it, make it a door as well. Until next month! Inform 6 Segment by ’trix Hello, marionettes. This week, a window into another room. Perhaps a metaphor for ... Anyway, this is one of the things that TADS 3 is really good at. But we can make do in I6. Essentially it's a scoping problem, so here is my IF Beginner's Introduction to Scope. Scope is one of the basic things that IF authors need to get to know. When the player has typed a command that seems to contain references to objects, the parser goes through all the objects in scope to find the best match. Things out of scope are not considered. Mostly, scope just means "stuff the pc can see", which more or less means "stuff in the room"; but certain contexts require variations. For instance, if you're issuing orders to an NPC in another room, telling him to pick up an ostrich, then scope needs to consider what the NPC can see, not what the pc can see. And if the pc is in a dark room, but it has been established that there is a light switch that the pc can find and reach, that needs to be in scope. Or, if you want to write a debugging verb that will move any named object in the game into the pc's inventory, scope needs to include every object in the game. (That debugging action does exist, and is called 'purloin'.) Going through scope is part of parsing, which is the process of working out what the player's command means. Before parsing is complete, you can't check the values of variables like action and noun, because they haven't been decided yet. So any alterations to scope need to be dealt with before any action processing, and need to use other methods to work out what's going on. Fortunately I6 has enough scope entry points to make that fairly straightforward. Any object that is in scope by the normal scope rules can provide the property add_to_scope, to add a bunch of other objects into scope. add_to_scope can either be an array of objects, or it can be a routine, which should add objects to scope with the command AddToScope(obj). If you put a standalone routine called InScope in your code, then it can override the normal scoping rules according to your own whims. If you want a special scope for a particular action, you can use scope=Routine in the verb grammar, as I think I did for one of these articles a couple of months ago. Who can keep track. OK. Here's the rooms with a window. I'll make it work later. Constant STORY "A Window Into Something"; Constant HEADLINE "^Perhaps a metaphor for ...^"; Include "Parser"; Include "VerbLib"; ! Yes, it's good old TwoDoor again Class TwoDoor with directions, door_dir [; if (parent(self)==self.&found_in-->0) return self.&directions-->0; return self.&directions-->1; ], door_to [; if (parent(self)==self.&found_in-->0) return self.&found_in-->1; return self.&found_in-->0; ], has static door; Object viewroom "Viewing Room" with description "This is the room wherein you can view things in the interview room. There's a big window on the north wall, and a black door to the west.", w_to viewdoor, out_to viewdoor, has light; Object -> window "window" with name 'big' 'glass' 'window', has scenery; TwoDoor -> viewdoor "black door" with name 'black' 'door', found_in viewroom corridor, directions w_to e_to, when_open "The black door is open.", when_closed "The black door is closed.", has openable; Object corridor "Corridor" with description "A short, curiously sparse corridor. There is a black door to the east, and a white door to the north.", e_to viewdoor, n_to interviewdoor, has light; TwoDoor -> interviewdoor "white door" with name 'white' 'door', found_in corridor interviewroom, directions n_to s_to, when_open "The white door is open.", when_closed "The white door is closed.", has openable; Object interviewroom "Interview Room" with description "A big white room with a wooden table, and a white door leading south. On the south wall is a big mirror.", s_to interviewdoor, out_to interviewdoor, has light; Object -> table "table" with name 'wood' 'wooden' 'table', has scenery supporter; Object -> -> notepad "notepad" with name 'notepad' 'pad' ; Object -> -> pencil "pencil" with name 'pencil' ; Object -> mirror "mirror" with name 'big' 'mirror', description "Damn you look good.", has scenery; [ Initialise; location = viewroom; ]; Include "Grammar"; Now, when you look in the window, you should get a description of the interview room and its contents. There's two ways to approach this: we can print the text we want, and customise it ourselves according to the objects in the room; or we can cheat and get the standard looking rules to do it for us. Unremarkably, I'm opting for the latter option. Let's try this: Object -> window "window" with name 'big' 'glass' 'window', before [ loc; Examine, Search: loc = parent(player); PlayerTo(InterviewRoom, 1); ; PlayerTo(loc, 1); rtrue; ], has scenery; That's moving the player (silently) to the other room, looking, and then moving her back. That works, after a fashion, but you'll get the room announcement at the top, which isn't really appropriate, and the room description isn't quite what we want. What we want is to skip the announcement and the normal description, print a customised description, and then do the standard ##Look listing of the room's contents. Fortunately, listing a room's contents is in a routine called Locale, which we can call ourselves. Object -> window "window" with name 'big' 'glass' 'window', before [ loc; Examine, Search: print "Through the window, you can see the interview room. It is a big white room with a wooden table in the centre.^"; loc = parent(player); PlayerTo(InterviewRoom, 1); Locale(InterviewRoom); PlayerTo(loc, 1); rtrue; ], has scenery; We intercept ##Search as well as ##Examine because the command "Look in mirror" will generate a Search action. There's one subtle issue here to mention: the white door (in the interview room) is on the south wall, so it shouldn't be mentioned ("The white door is closed.") in the locale text. So here's how we stop it: set a flag when we're looking through the window, and have the white door not announce its presence when the flag is on. Object -> window "window" with name 'big' 'glass' 'window', before [ loc; Examine, Search: give self general; print "Through the window, you can see the interview room. It is a big white room with a wooden table in the centre.^"; loc = parent(player); PlayerTo(InterviewRoom, 1); Locale(InterviewRoom); PlayerTo(loc, 1); give self ~general; rtrue; ], has scenery; ! .... TwoDoor -> interviewdoor "white door" with name 'white' 'door', found_in corridor interviewroom, directions n_to s_to, describe [; if (window has general) rtrue; if (self has open) "^The white door is open."; "^The white door is closed."; ], has openable; describe is always the property to use if you want the option of hiding an object entirely, because if it returns true, the room contents list prints nothing related to the object, not even a new line. Next, the scope stuff. The quick way to add the contents of the interview room into scope is using ScopeWithin. Put this anywhere before Include "Grammar": [ InScope person; if (person in viewroom) { ScopeWithin(interviewroom); } rfalse; ]; ScopeWithin put the contents of the given object in scope, recursing down by containment. Returning false at the end of the routine means that the parser can carry on and put everything in scope that would normally be in scope. Now that's the quick way to put everything in scope. But not everything should be in scope: the white door and the mirror aren't visible through the window. So instead we'll have to go through the contents of the room and add the stuff we want to be added. [ InScope person x; if (person in viewroom) { objectloop (x in interviewroom) { if (x ~= mirror or interviewdoor) { PlaceInScope(x); ScopeWithin(x); } } } rfalse; ]; Now anything (other than things specifically excluded) in the interview room will be in scope from the viewing room. That makes them available for examining (which is what we want), and conceivably for other actions, like opening and closing. How do you prevent that? One way is to write a before property on the viewing room that intercepts any unsuitable action on an object in the other room. That's not as much trouble as it sounds. But there is a possibly easier way: every action involving physical contact will call the routine ObjectIsUntouchable. This checks if the player is separated from a given object, for instance by being in a sealed glass case. If we replace this routine, we can add the extra check we need. To do this, we can copy the routine from out of VerbLibM, paste it into our code, and put some extra stuff in it to check what we need to check. Include "Parser"; Replace ObjectIsUntouchable; Include "VerbLib"; [ ObjectIsUntouchable item flag1 flag2 ancestor i; ! NEW STUFF BEGINS HERE if (IndirectlyContains(viewroom, player) && IndirectlyContains(interviewroom, item)) { if (flag1) rtrue; print_ret (CTheyreOrThats) item, " in another room."; } ! NEW STUFF ENDS HERE. Everything below this is just ! copied and pasted from VerbLibM.h. ! Determine if there's any barrier preventing the player from moving ! things to "item". Return false if no barrier; otherwise print a ! suitable message and return true. ! If flag1 is set, do not print any message. ! If flag2 is set, also apply Take/Remove restrictions. ! If the item has been added to scope by something, it's first necessary ! for that something to be touchable. ancestor = CommonAncestor(player, item); if (ancestor == 0) { ancestor = item; while (ancestor && (i = ObjectScopedBySomething(ancestor)) == 0) ancestor = parent(ancestor); if (i ~= 0) { if (ObjectIsUntouchable(i, flag1, flag2)) return; ! An item immediately added to scope } } else ! First, a barrier between the player and the ancestor. The player ! can only be in a sequence of enterable objects, and only closed ! containers form a barrier. if (player ~= ancestor) { i = parent(player); while (i ~= ancestor) { if (i has container && i hasnt open) { if (flag1) rtrue; return L__M(##Take, 9, i); } i = parent(i); } } ! Second, a barrier between the item and the ancestor. The item can ! be carried by someone, part of a piece of machinery, in or on top ! of something and so on. if (item ~= ancestor) { i = parent(item); while (i ~= ancestor) { if (flag2 && i hasnt container && i hasnt supporter) { if (i has animate) { if (flag1) rtrue; return L__M(##Take, 6, i); } if (i has transparent) { if (flag1) rtrue; return L__M(##Take, 7, i); } if (flag1) rtrue; return L__M(##Take, 8, item); } if (i has container && i hasnt open) { if (flag1) rtrue; return L__M(##Take, 9, i); } i = parent(i); } } rfalse; ]; You should maintain the practice of checking ObjectIsUntouchable in any new actions that you write so that this sort of thing will work consistently. That's about it from me this month. Happy programming, hypothetical readers. Inform 7 Segment by Dudeman Another month, another coding problem for us to tackle here at coder’s corner. This month we will be dealing with windows. Though this can be a literal glass window, from a coding stand point a window can be anything that allows the player to see into a room without actually being in that room. However, to keep things simple we will just be dealing with a basic everyday window, like one that might be in your kitchen that looks out into your backyard. the Kitchen is a room. "A standard kitchen with all the standard kitchen fixtures. To the north is the backyard with a large window looking out into it.". the Backyard is north of the kitchen. "The backyard is fairly large with a small garden running along the side. To the south is the entrance to the kitchen with a window along the wall looking into it.". Jill is in the backyard. The description of Jill is "Jill is your wife of only a few months and the two of you are still very much still in the honeymoon phase. Her hot, tight young body still makes you want to jump her every time you see her.". a window is a backdrop. It is in the kitchen and the backyard. The window can be openable. The window can be open. The window is openable and closed. Now that we have our basic set up, we now want to make it so that the player can look into the backyard from the kitchen and vice-versa as would be expected by the presence of the window. Just like last month, this feature of games is so common that it is actually addressed by the Recipe Book that comes with the Inform 7 software. Specifically, chapter 3 part 5 of the recipe book titled “Windows” covers various situations revolving around windows in a game. In this case, the best example give would be “Dinner is Served” which gives you a basic idea of how to tackle this in our little game. Using this example, we can fit it into our game with only minor tweaks and taking out the parts we don’t need like being about to reach through the window since we don’t need that for our example. After deciding the scope of the player: if the player is in the kitchen, place the backyard in scope; if the player is in the backyard, place the kitchen in scope. Instead of examining the backyard while in the kitchen: say "Looking through the window into the backyard you can see [a list of visible things in the backyard].". Instead of examining the kitchen while in the backyard: say "Looking through the window into the kitchen you can see [a list of visible things in the kitchen].". Instead of examining the window: if in the kitchen, try examining the backyard; if in the backyard, try examining the kitchen. And that gives the player the ability to see into the kitchen from the backyard and vice-versa through the window, but will not be able to otherwise interact with things in the other room, behavior that is expected of a window. This is because the “scope of the player” as used in the first rule is the term Inform 7 uses to describe what the player can interact with, but there are other rules in place that prevent physical interactions from happening between rooms that would be illogical. You can learn more about scope in Chapter 17 part 27 of the Inform 7 documentation. Now to test this out we can add a few random objects to the rooms such as; an apple is a thing in the kitchen. The description of the apple is "A healthy, nutritious red apple. Not much more to say about it.". A watering can is in the backyard. The description of the watering can is "A large watering can Jill uses to water her garden every day.". Now you can try playing around with these objects, moving them from room to room and you can see that any changes will be reflected when you look through the window. Now this is just very basic behavior and can always be expanded upon, but for now I feel this should give you an idea of how Inform 7 handles things like windows. ADRIFT Segment by BBBen This month’s challenge is, I’m pleased to say, not too challenging in ADRIFT. In fact, there’s a nice, easy way to take care of it. Let’s say we have two rooms, a living room and a garden, and a window that looks out from the living room onto the garden. 1. Create the rooms, and an object for the window. 2. Put that object in the living room. In the window object give a description along the lines of “This window looks out onto the garden. You can look through it.” 3. Next, create a task called “look through window”. Make it repeatable, and make it completable only in the living room. 4. Now, instead of putting any description in the task, just below the “message upon completion” box is a drop-down menu labelled “Then show description for room:”. All you have to do is select the room “garden”. And that’s the extent of it! Now when the player types “look through window” in the living room they will get a response that is just like a “look” command in the “garden” room. * * * 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. 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. Dudeman has released one game and is working on a second. He has also released an impressive Inform 7 sex extension to help make it easier for others to write games of their own. 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.