8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / compuserve-file-archive / 19 Adventure Games / ADVGAM.CNF < prev next >

Wrap

Text File | 2019-04-13 | 19.0 KB | 511 lines

Transcript of the Adventure Game COnference from the CBMART forum on CompuServe. 10/21/88 Moderated and edited by Todd Heimarck (ToddH) --------------------------------------------- ! = I have a comment. ? = I have a question. ga = GA = Ga = go ahead. --------------------------------------------- The COnference begins at 6 PM PDT (9 PM Eastern)... ToddH/Sysop: I've read some Dungeons & Dragons books, and one point they make is that you've got to make a setting realistic. For example, if you have 50 trolls in one room, where do they get their food? (By the way, are my words coming through OK? I'm getting garbage on my end.) ga Lex: ! ToddH/Sysop: Lex, ga Stephen: ! Lex: (You're coming in clear.) A problem is how much of the setting do you have to develop? For example if the setting is a town, do you design every building? ga ToddH/Sysop: I would think so... Chad: ! ToddH/Sysop: ...but you don't necessarily have to put treasure or monsters in every house. ToddH/Sysop: Stephen, ga. Stephen: About realism -- I wish computer role-playing games would STOP making their mazes have a 'wrap-around' ability. A couple of teleporter squares are OK, but a hallway that wraps around on itself after a mere 16 or so steps is absolutely ridiculous. GA. ToddH/Sysop: I'm going to add a new rule. I just realized that this CO is unusual because we don't have an official guest speaker, so type ! for a brand new comment or topic. Type !! for the same topic. Chad, ga. Chad: I think the settings can be as complicated as you want to make them or as simple as you want. It all depends on how complicated you are planning to make the game and how muchprogramming time you are willing to spend on it. Ga Stephen: ! ToddH/Sysop: Stephen, ga Lex: ? Stephen: About settings, just watch out that you don't go to all the trouble to make the PERFECT town, with explicit detail in every building just to run out of memory, or simply become tired of programming ... William: ! ToddH/Sysop: I think there's a balance to be struck... Stephen: ...and make a lousy dungeon, or scenario. GA ToddH/Sysop: The main thing is that the game is FUN for the player. So in a sense, the question of detail is this: Does a lot of detail make the game fun? If so, then do it. You probably also want a goal, like rescuing the maiden in distress or getting a quillion dollars worth of gold. And you probably want puzzles (a door that won't open without a key, say, or a sphinx with a riddle). Lex, ga. Lex: Having been a Dungeon Master of D&D for over 10 years, I have many... William: The trouble with explicit detail is... Lex: ...adventures that I would like to convert to a computer game. My question is, how do you decide what to keep and what to throw away? GA ToddH/Sysop: Anybody want to answer that? No answer. OK, I will. There are a couple of limits. One is how good are you at programming? Certain things are really hard to do. Another is memory. Your computer only has X number of bytes. If you do too much, you have to go to the disk drive. William, ga. William: I just wanted to add that the amount of detail used in an adventure also results in the programmer having to think of various inputs by the player. GA Stephen: ?? ToddH/Sysop: Stephen, ga. Stephen: Let's talk about parsers. I've been wanting to do one for a game I'm working on, but I don't know where to start. Also, I would prefer to do a parser that recognizes MORE than just the verb-noun syntax. Without getting into too much detailed program-instruction level talk, does anyone know where to start? Ga ToddH/Sysop: I was thinking about that tonight as I was stuck in traffic. I thought about three types of "parsers" from simple to complex. The first is very ugly. It's like one of those dumb books that say, "If you fight the troll, turn to page 33. If you run away, turn to page 56." It's not a parser at all; it's just a series of decisions. The second is a fixed list of commands (usually on a menu). You give the player about 10 choices: (F)ight, (G)o, (L)ook, etc. I've seen some games like that that work reasonably well. The third is a real parser that figures out the meaning of GO NORTH. One way to do it (maybe not the best) is to list every single verb and every single noun and mark which ones make sense. EAT FOOD is OK, EAT SWORD is not OK. You could put the results in a two-dimensional array, with a code that tells the program where to go. Any comments? Chad: !! (does this mean same subject?) ToddH/Sysop: Yes. GA, Chad. Lex: !! Chad: I just finished a simple adventure written totally in C. I did it mainly for practice in C programming, but I did write a simple parser for it. At first I was going to make use of a menu system like you described, but I didn't think the game would feel... Stephen: ?s (same subject) Chad: ...like a "real" adventure game. I ended up writing a parser that would accept commands in verb/noun format that was mentioned before. The way I set it up was to put all of the characters up to the first space into a string and then all of the characters after the verb into a second string. I then compared the first string to a list of commands set up in an array. For each command I had a function set up which then evaluated the noun to see if it would work with that command. I'm sure there is probably a better way to write a parser, but that is how I managed to write a working one. Ga ToddH/Sysop: Let's use !! and ?? for "same subject." Lex, ga. Lex: In a BASIC version of a Scott Adams' adventure, he used a similar parser, like Chad's. Verbs, nouns, adjectives and conjunctions were put in separate arrays. The verb number was used for a ON x GOSUB command. The subroutine would parse the rest of the command. If a noun didn't make sense with the verb, a standard "You can't do that" message was displayed. Adjectives and conjunctions called other subroutines, until the entire command was interpreted and acted upon. Ga ToddH/Sysop: Stephen, ga. No one is next in line. Stephen: Lex brought up the very thing I had a question about -- the "you can't do that" message. Naturally, that is the easiest way to handle: unprogrammed commands. But, it is also the most boring to the player. Fancier parsers, like the Infocom ones, at least say something like "You can't eat that", etc. depending on the 'foul' word in the phrase. But, my main question is: What about words with multiple meanings like RUN -- RUN NORTH, RUN MACHINE. Or even worse, ROLL -- ROLL NEWSPAPER, ROLL ROCK ACROSS FLOOR, EAT ROLL. I've seen that. Even the Infocom parser avoids this problem by carefully arranging that such words only require one of the possible meanings throughout... Lex: !! Stephen: ...the entire game. Anyone have any suggestions to make using such words in DIFFERENT meaning possible? Ga ToddH/Sysop: Lex, ga. Chad: !! ToddH/Sysop: !! Lex: First, ROLL would check for the curl synonym. If the noun doesn't make sense, try the MOVE routine (your 2nd example). In the 3rd example, ROLL would be a noun and wouldn't be checked as a verb. EAT would be [checked as a verb]. Ga ToddH/Sysop: Chad, ga. I'm next. Chad: What Lex said would be the most logical way to do it. But the problem lies in the fact that the programmer is going to have to try to guess at all of the possible commands and usages the user will enter. The same holds true for printing out error messages that are interesting. I love how Infocom handled "dirty" phrases in "Leather Goddesses of Phobos". Ga. ToddH/Sysop: Me now. Nobody is in line. ToddH/Sysop: I have several things to say. Feel free to interrupt with ! or ?. The first is about "bad" programming. I think it's nuts to do a sequential search of 500 commands. A binary search makes much more sense and is faster. Say you're looking up John Smith in the phone book. You DON'T start with AAA Locksmith and read forward through every name. You jump into the list halfway. Mick Murrow. Smith is > Murrow. In one step, you've eliminated half the names in the phone book. Then you divide the remaining names in half. Troy Tucker. Smith is < Tucker, and so on. To do this right, you need to alphabetize the names or commands... ...Another bad programming practice is a labyrinth of IF-THEN statements. IF VERB = EAT and NOUN = ROCK THEN GOTO 300... if verb = eat and noun = troll then goto 300. You can easily fill up memory with a zillion IF-THENs. ON-GOSUB makes a lot more sense (as someone pointed out earlier) and if you can't fit it on a line, use ON VERB-10 GOSUB 1,2,3,4,etc. In Commodore BASIC, a number that's too big drops you to the next line. (Anybody have comments so far?) Chad: !! ToddH/Sysop: Chad, ga. ToddH/Sysop: ! Chad: I totally agree with using a binary search. The only reason I didn't was because I was writing a simple adventure with about 20 commands. Anything much bigger, it would be the only sensible way to do it. I also agree with your comments about using a bunch of IF-THEN statements. Ga. ToddH/Sysop: I wanted to say something about the C language. What's really neat about it is that you can use the address of a function so you could set up a 2-D array and both EAT ROCK and EAT TROLL would contain pointers to the function that says "Don't be ridiculous." You find the address and call the function at that address. In BASIC, you have to use ON-GOSUB. I'd also argue that the NONSENSE subroutine (or function) should contain about 50 messages. You pick one at random. It's really boring for a player to see "You can't do that" 600 times. Any comments? Chad: !! ToddH/Sysop: ga Chad: I am brand new to the C language. The adventure game I described was my program written in C, but I really love the language. It didn't occur... Stephen: ? Chad: ...to me to set up my program like you just suggested, but that is just one more way C is so great. Ga ToddH/Sysop: Stephen, ga. ToddH/Sysop: ! Stephen: Oops, Lex is next, I think. ToddH/Sysop: Oh. Lex, ga. Then Stephen. Lex: In response to the NONSENSE routine: Infocom and others see the command of EAT TROLL as legal. However, it doesn't do anything except display a particular message. Ga ToddH/Sysop: Stephen, ga. Then me. Stephen: Changing the subject, I had a question about one of the other topics planned for tonight. How to keep a game from being too easy/difficult. This can apply to any type of game, but I'm working on a RPG... Chad: ?? (what is RPG?) Stephen: After playing games like Wizardry, Ultima, etc., I remember... Stephen: ...(RPG = Role Playing Game)... Stephen: ...my first experience with the game Bard's Tale. I spent several minutes creating my party of 6 characters, stepping outside of the 'Guild' (where the game starts) and encountered 8 Orcs. I was still unarmed, unarmored, as I hadn't even had a chance of finding the store, and I was promptly annihilated! On the other hand, I found that Bard's Tale 2 felt far too EASY to start with. So, how does one go about making the... Lex: !! Stephen: ...game have that PERFECT balance between hard and easy? Ga ToddH/Sysop: Chad's convention is now official. If you can fit the question on one line (80 characters), type this: ?? What is RPG? Lex, ga. ToddH/Sysop: !! Lex: The answer is rather simple, but time consuming. If you read the credits to most games, you'll see the PlayTesters. They play and play, finding bugs and making suggestions. So the simple answer is Test, test and then have your friends test and test. Ga Stephen: ?? ToddH/Sysop: Stephen, ga Stephen: Ok, I don't have a lot of friends with the same computer as I have (an Apple IIGS), so I foresee a shortage of playtesters. In addition I hope that upon completion of my game, it will be able to contain many new ideas/concepts, and a completely new, different feel than any other game thus far, so I hesitate just soliciting for unknown playtesters. Any ideas as to how to handle this dilemma? GA ToddH/Sysop: I have a few comments about the easy/difficult question. First, I think that testing is important. Testers give you good ideas and they find bugs that you yourself never imagined. One danger is this: Piracy is popular. You give out a beta copy of your game and suddenly it's on 500 BBSes around the country... Chad: ?? ToddH/Sysop: ...Another danger is the "lean over the shoulder" problem. If the tester can't figure out something, you (the programmer) are tempted to say "Hey, try dropping the torch. It will set the carpet on fire." In real life, the programmer can't lean over and give a hint. One solution to the easy/difficult problem is to think as a player would think. For example, I've seen games that read the disk after every command and it takes 30 seconds. I guess one rule is "Make it fun." Another is "Don't annoy the user." You might have a great game, but if you make the player wait 30 seconds between turns, he or she will just get mad. Plus, I think sometimes you have to create a room that's empty. Nothing's there. Or give them a tool they'll never use. You can pick up the crystal of awareness, but it never does anything. To sum it up, I think testers can give you valuable advice. Chad, ga. Chad: What level of programming is this being approached at? It makes a big difference in the testing procedures. If you are writing a commercial game you have to have all testers sign nondisclosure agreements, or ?? If you are just writing it for fun then you can show it to anyone you can get to come over and try the game. Ga ToddH/Sysop: I think we're talking in general. Might be commercial. Might be for fun. Ga, Stephen. No one is next. Stephen: I hope mine will be 'commercial' quality when I'm finished. Chad, do you (or anyone) know if nondisclosure agreements are 'generic',... Chad: !! Stephen: ...or does one have to hire a lawyer to draw one up on each and every occasion? Ga ToddH/Sysop: Chad, ga Chad: A lot depends on the wording of the agreement. You do have to have the people sign a new one for each project you show them. I think I have a book with a sample agreement that is a generic version. I'll see if I can find it. Ga. ToddH/Sysop: I have something to say. I think you could use a generic contract with only one new paragraph. At the top, you say "Green Aliens from Pluto" is hereafter referred to as "the program." Then you call it "the program" in the rest of the contract. Because of piracy there is a lot of paranoia in the software industry. If you submit a program to a big software company, they will use a double-non-disclosure agreement. They make you promise you didn't steal the program and they promise they won't steal it from you. Ed and Betty haven't said anything tonight. Do you have any comments about adventure games? ga Sysop/Betty: !! ToddH/Sysop: Betty, ga. Ed Flinn/Sysop: !! Sysop/Betty: I was wondering if before you start writing an adventure game, do you make a "flow chart" or "map" and then follow that logic with your coding? ga ToddH/Sysop: Chad, you've written adventure games. Wanna answer that one? ga Chad: OK. The way I started with my game was to first draw up a map of all the rooms and what they contained. Then I made a list of all the commands the parser would respond to and what those commands would do. I also wrote down any kind of puzzles or interesting twists in the game that I wanted. After that I really didn't use any sort of flow charting. I did do a little pseudo-code for the major routines but not very much, but then that is my programming style... Sysop/Betty: Thanks, Chad. ga ToddH/Sysop: Lex, you've written D&D scenarios. Want to add anything about games? ga Chad: ...I think everyone writes programs differently, so it is really up to you. ToddH/Sysop: OK. Lex, any comments about games in general? Lex: Well, I always start with the ending. I decide what the goal is and then work on how the people would get there. If it seems too easy, I work on puzzles and problems. But, mostly I work on the mood. My adventures are always good versus evil, and (hopefully) good triumphs. To set the mood, I spend a lot of time on descriptions. Also, I make sure that everything makes sense. I dislike being asked "Why is this here?" without having a GOOD answer. Ga. ToddH/Sysop: In a sense that's "top-down" programming. Start with the goal and work backwards from there. I guess I disagree with Chad a little: I don't think adventure programming is a coding problem. He mentioned pseudo-code, which is a valuable tool, but (personally) I would start with the data structures. I've got this map. I've got these commands. I have magic spells. How do I store them in arrays (or (in C) in structures)? If I know how to store the data, the code is easier to write. Chad: !! ToddH/Sysop: Ed, you're next. Then Chad. ga. Ed Flinn/Sysop: OK. Nothing profound to say. I think some people weren't meant to play adventure games. I enjoy them, but I never get very far. As a programmer, I'm supposed to be good at working with logic, but I never get very far <grin>. Ga. ToddH/Sysop: That's the same question we discussed earlier: the too easy/too tough problem. I hate (*H*A*T*E*) games where I die in the first 3 turns. But if I solve it in 3 minutes and reach the goal, I feel cheated. Chad, ga. Chad: I didn't mention it when I described what I did while setting up my game, but... Lex: !! Chad: ...I did do all of the data structures right after I finished my map. I had to decide how to do my room links and room descriptions, which was a major part of the task. I also want to mention that I agree with Ed. I like to program adventure games but not play them. I got through Zork I and then decided I would never play a major adventure game again. Ga ToddH/Sysop: Lex: I wasn't criticizing you. I just wanted to suggest another approach. The CO is scheduled to end now, but I think we should continue as long as people have comments. Stephen has left (but he said he'd download the transcript to see what he missed)... Chad: !! ToddH/Sysop: Something to think about is "Which games are great and why?" Lex, ga. Lex: I think that the term "too easy/too difficult" is too generic. I run two games: one for experts and one for novices. So I feel that adventure games can be geared toward either audience. Ga ToddH/Sysop: You have a good point. Maybe adventure games should alternate between easy and tough: Let the player win, win, win, then he loses. He gets stuck at some point until he figures out the puzzle. Chad, ga. ToddH/Sysop: ! Chad: I'm sorry to say I have to go too. I'll be sure to download the transcript. This has been great and I think we should plan on doing it again sometime. Bye. Ga ToddH/Sysop: Bye, Chad. Lex: I second that motion. ToddH/Sysop: I guess that's the end of the CO... Lex: Great job, Todd! ToddH/Sysop: To other sysops: Should we huddle in CO after it ends? Thanks Lex. Sysop/Betty: Thanks for a great job of moderating, Todd. Ed Flinn/Sysop: If ya want. Sysop/Betty: OK. ToddH/Sysop: For 5-10 minutes, I think. Ed Flinn/Sysop: OK, lemme close my capture. --- ...and that ended the COnference about adventure games.