smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) (11/04/90)
This is being cross-listed to rec.games.misc. Let's try to keep this discussion on the *design* of a game, *not* the system which it runs on, OK? Patrick Jost <jost@coyote.trw.com> says: >Here are some of my "gripes" with most adventure games, and possible solutions >for what I'd consider better games: >1) Having to go through a tedious process of gaining "experience" before >being able to use certain spells and so on. As an alternative, I'd >recommend immediate access to just about everything, but making part of >the game sorting out what to do with them. For instance, if there are >several "attack" spells, which ones work best on which foes? Sure, you'd >be able to cast anything, but you'd better cast the RIGHT thing. Good observation, but I think magic is just too plentiful in RPG's as it is. There was a good review of the new Lord of the Rings RPG in a recent gaming magazine which pointed this out. In this new RPG magic users are not that powerful, and magic is hard to come by. This keeps the fighters from becoming mere baggage carriers after a certain level since most high level magic users in most games can wipe out half an army with a single spell. The article pointed out that in this new RPG the higher level MU's could be blown away by a mediocre MU from some other average RPG. I agree with you about the dumb idea of gaining levels to be able to do things. To me this is just a way of making the game last longer (which is unfortunately the intention of the programmers). Good grief, some games are long or too long already. Don't get me wrong--I love epic adventures and I almost always never give up on one I've started, but there are too many *bad* ways to make games last longer! (Like the blind mapping in Bard's Tale II.) But back to the original subject... I think I would rather see the player get *excited* when he/she is able to use a magic spell. Therefore I would like part of the game to be searching for magic items or spells AND finding out how to use them once found, as you mention above. Most games just allow you to use a spell once you get to that certain level, and what's so exciting about that? "Ho hum...another spell...guess I'll add it to the other fifty I have that I never use..." How many people out there have played any of the TSR games (Pool, Curse, Krynn, Blades, etc.)? Now be honest; what percentage of the available spells did you even use? How many times did you opt for the easy fireball routine instead of using the magic arrow? Too many spells either become obsolete or are never even used. Take Bard's Tale for instance--talk about tons of spells you never use! There were so MANY of them, and the ones that you did use were used so frequently there was nothing *special* about them, at least anything special to be excited about. And (to lengthen this tirade a little farther) I agree with you about searching for info on a magic item. In Might and Magic II (probably my favorite RPG) all the spells are listed for you right in the book. There's no chance for discovering a new one on your own, except in the sense of trying to find where some are located in the game. But you already know they are there somewhere. I would like to see a game designed where you have to be really sharp to find any magic items and have nothing mentioned in the book about them. You would be forced to learn about the history of the place, or talk to the right people, or maybe even experiment with the object before you learned its secrets. So I guess I'm generally agreeing with you, but stating that magic has become much too commonplace. Let's make it something *special*. >2) Running out of food, torches and so on. I think this reduces many >aspects of gameplay to tedium. Sure, you'd have to have these things >in real life, but I don't see that this adds anything to a game. True. There is a tension in RPG's and adventure games between what is realistic (in terms of correspondence between the gaming world and the real world) and what is practical and fun. We are forever wanting the gaming world to be more realistic, but if in fact something is *boring* we don't include it in the game, even if it would make the gaming world more realistic. There is nothing really too bad about this, after all it is a game and should be fun (yeah, for you die-hard RPG fans that statement nearly makes me cringe too :-). But of course when you're gaming system is not internally coherent, or if you're gaming system includes really dumb ways of doing things because "that's how it's always done" then the system should be revised. More on this below under #4. >3) Having a "quest" be an integral part of a game. Once the "quest" has >been accomplished, the game is more or less over. I'd like to see a game >where you just explore a large world-in fact, you could have the program >create an endless series of "random" worlds (along with different spell >characteristics and so on). I agree. There was some good discussion on this at the last Game Developer's Conference. It seems that the game designers are seeing this shortcoming too, and are now trying to develop a rich gaming world with an environment which would provide a "mood", and *then* drop a character into the middle of it so he/she can experience that world personally by interacting with it. This means either more miniquests or *only* miniquests; i.e., no ultimate objective. I too don't like the idea of being herded down a one way path in order to solve an ultimate goal in the way that the programmer wants it to be solved. This in my opinion is the big drawback about most of Sierra's games; they mostly consist of linear paths, and the only way to solve them is to do things in the "proper" order. Knights of Legend is one of the few games that doesn't have the "ultimate quest" syndrome. Check it out. >4) Lack of originality is chronic! Every game seems to have a few attack >spells, a few heal spells, transport spells and so on. For characters, >you get fighters, wizards and clerics; sometimes you get thieves, ninjas >and the like. Once again, I'd like to see more effort put into creating >a real "world" with characteristics to be learned as the game goes on. I agree! Here's another one for all you gamers out there: What about the whole concept of *hit points*? Now just think about that for a second. "Hit points"? We're so used to thinking in those terms we can't see how absurd this idea is. When you're dealing with computers of course one must reduce everything about a character to bits and bytes, but why be so bloody obvious about it? Or *at least* have the character be *wounded* if he's lost a few "hit points"! Your character could have 100 HP and be down to his very last HP (1 HP) and still be fighting like nothing is wrong. Stupid. >One of the best games I've had was Might and Magic. You've got good taste. :-) >Patrick Jost >jost@coyote.trw.com S. "Stevie" Smith \ + / <smsmith@hpuxa. \+++++/ " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@ ircc.ohio-state. \ + / {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-) " edu> \ + / BTW, WYSInaWYG \ + / --witty.saying.ARC
lwl@eniac.seas.upenn.edu (Lydia Leong) (11/04/90)
Interplay's Dragon Wars sets a good example to follow in the future. Dragon Wars utilizes a skill-based system. Granted, one needs to gain levels to get "skill points," but it is possible to have a character with just a few very high skills instead of a multi-skilled, well-rounded character. Magic spells must be found, and there are lots of surprises which are not level-dependent. Magic is relatively weak and fighters are NEVER useless. Origin's Ultima series also de-emphasizes magic. In Ultima V, there are certain spells not described in the rulebook which must be discovered by the player. Ultima VI players must buy the spells they want to use, so if it isn't useful, the player doesn't have to get it. I believe that inventory management - food, torches, and the like - is necessary in a truly excellent RPG. Well-implemented, it becomes part of the game world, enhancing rather than detracting from the gaming experience. Once again, look at Ultima VI. Here, players may fish for food, buy meat, or even buy flour and take it to a bakery and have it made into bread. This helps bring the world to life. Having unlimited resources is good in a dungeon hack 'n slash game, but not in a game where discovery is important. Anybody agree?
smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) (11/04/90)
Here's an additional thought of a practical nature. All of you know
how tedious it is to keep notes while you play an RPG. Even if you
have auto-mapping you still have 10-100 pages of notes. At least
I do! Why hasn't somebody programmed a game to use the printer for
note taking? Say for example someone you meet in the game says
something important and you need to write it down. Instead of turning
to the old pencil and paper you just press a key on the keyboard (such
as the PrtSc button or the "p" key) and the time, place, and content
of the conversation is printed out on the printer of your system. This
should be really easy to do since the whole thing could be kept in
ASCII characters. The game designer could even include a dozen or so
colored printer sheets with notebook holes on the side so you can file
them in a neatly organized notebook of some type, and if you wanted
more sheets just send the company a request with the appropriate $$$.
There's all kinds of variations on this, including printing to the
hard drive and allowing the player to view these messages at any time
in the game and to allow the players to organize them in any way they
like via a very simple word processor built into the game. If you're
playing off floppies there might be an "adventurer's journal" disk
where all these messages are kept. You could do the same thing with
maps, etc., etc.....
S. "Stevie" Smith \ + /
<smsmith@hpuxa. \+++++/ " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@
ircc.ohio-state. \ + / {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-) "
edu> \ + /
BTW, WYSInaWYG \ + / --witty.saying.ARCck31+@andrew.cmu.edu (Christopher Bruce Kidwell) (11/04/90)
>I agree! Here's another one for all you gamers out there: >What about the whole concept of *hit points*? Now just think about >that for a second. "Hit points"? We're so used to thinking in >those terms we can't see how absurd this idea is. When you're >down to is very last HP (1 HP) and still be fighting like nothing is wrong. >Stupid. I agree on this point as well. One system that I've seen that handles this quite well is Middle Earth Role Playing (MERP). There you can be hit once in a critical area and die. Or you can be hit and have an arm chopped off so that you can't use your sword any more. I havn't done any extensive playing in this system, so I don't know how complicated it is to play. There was one computer game produced under this title, but I'm not sure how (or if) they implemented this feature. Also, MERP allows for abilities in various skills such as tracking, making shelter, and horseback riding. It seems to me to be a very good system. On a different note, have any games dealt with the problem of a group of about six characters defeating hundreds of enemies without being killed? In Bard's Tale (I forgot which one) the party has to fight four groups of 99 Bezerkers. It seems to me that if about 20 of them came charging from all directions, the party wouldn't stand a chance. I seem to remember someone mentioning a rule like this from AD&D to the effect that if a character is surrounded by more than four enemies, he is automatically defeated. Any thoughts? Chris Kidwell ck31@andrew.cmu.edu
jost@alice.coyote.trw.com (Patrick Jost) (11/05/90)
In article <1990Nov3.234058.23166@magnus.ircc.ohio-state.edu> smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes: > >I agree with you about the dumb idea of gaining levels to be able to do >things. To me this is just a way of making the game last longer (which >is unfortunately the intention of the programmers). Good grief, some >games are long or too long already. Don't get me wrong--I love epic >adventures and I almost always never give up on one I've started, but >there are too many *bad* ways to make games last longer! (Like the >blind mapping in Bard's Tale II.) But back to the original subject... >I think I would rather see the player get *excited* when he/she is >able to use a magic spell. Therefore I would like part of the game >to be searching for magic items or spells AND finding out how to use >them once found, as you mention above. >So I guess I'm generally agreeing with you, but stating that magic >has become much too commonplace. Let's make it something *special*. Sure! I'd be all for that! Certain objects would be required to cast certain spells (make some of them BLOODY hard to get); some spells only work in certain places (inside, outside, near water, away from water); certain spells can only be cast by certain types of characters (e.g. women, elves, monsters). I didn't mean to suggest that all spells would be available at all times...but just accumulating "points" is foolish! PJ -- | Patrick Jost (PJester) | "The thief of Baghdad hides in Islington now" | jost@coyote.trw.com | -Marillion (Fish)
mlab2@kuhub.cc.ukans.edu (11/05/90)
In article <QbB2aqm00WB381m2ZV@andrew.cmu.edu>, ck31+@andrew.cmu.edu (Christopher Bruce Kidwell) writes: >>I agree! Here's another one for all you gamers out there: >>What about the whole concept of *hit points*? Now just think about >>that for a second. "Hit points"? We're so used to thinking in >>those terms we can't see how absurd this idea is. When you're >>down to is very last HP (1 HP) and still be fighting like nothing is wrong. >>Stupid. --stuff del-- > chopped off so that you can't use your sword any more. I havn't done > any extensive playing in this system, so I don't know how complicated it > is to play. There was one computer game produced under this title, but I'm > not sure how (or if) they implemented this feature. Also, MERP > allows for abilities in various skills such as tracking, making shelter, > and horseback riding> --stuff del-- > Any thoughts? > > Chris Kidwell Back in my RPG days, I discovered DragonQuest. I believe the rulebook can still be found in some gaming shops. IMHO, they were the most logical and yet easy to play set of rules I've come across (although I haven't seen MERP). An excellent balance between playability and realism. Skills, like horseback riding brought this to mind. Anyone else familiar with these rules? If I ever did an RP computer game, I'd use rules similar to these. :======:**************************************************************** : ==== :* ** And watching the stars go on at night, ** : === :* Soft Dorothy ** I'd like to see just one of them die.. ** : == :* *****************************************jc** :.=....:****************************************************************
so@duke.cs.duke.edu (Steve Owen) (11/05/90)
In article <QbB2aqm00WB381m2ZV@andrew.cmu.edu> ck31+@andrew.cmu.edu (Christopher Bruce Kidwell) writes: [stuff deleted] >I agree on this point as well. One system that I've seen that handles >this quite well is Middle Earth Role Playing (MERP). There you can be >hit once in a critical area and die. Or you can be hit and have an arm >chopped off so that you can't use your sword any more. I havn't done >any extensive playing in this system, so I don't know how complicated it >is to play. There was one computer game produced under this title, but I'm >not sure how (or if) they implemented this feature. Also, MERP >allows for abilities in various skills such as tracking, making shelter, >and horseback riding. It seems to me to be a very good system. [stuff deleted] >Chris Kidwell >ck31@andrew.cmu.edu I have played MERP before and would be very interested in a computer game based on that system. Anyone know the name of the game Chris refered to? Thanks, Steve -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Steve Owen ARPA: so@cs.duke.edu Department of Computer Science CSNET: so@duke Duke University UUCP: {mcnc,decvax}!duke!so Durham, NC 27706 USA "It pays to be obvious, especially if you have a reputation for subtlety." - Isaac Asimov -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
conty@cbnewsl.att.com (enrique.conty) (11/06/90)
In article <1990Nov3.234058.23166@magnus.ircc.ohio-state.edu>, smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes: > This is being cross-listed to rec.games.misc. Let's try to keep > this discussion on the *design* of a game, *not* the system which > it runs on, OK? Fine. > Patrick Jost <jost@coyote.trw.com> says: >>Here are some of my "gripes" with most adventure games, and possible solutions >>for what I'd consider better games: > > >1) [Why do we need to gain experience before getting the spells]? > > Good observation, but I think magic is just too plentiful in RPG's as > it is. [stuff deleted] Good point. Those Bard's Tale II spells that cause up to 800 HP damage per monster (or some such figure) sound too much like power gaming for my taste. How about this: have a very limited set of spells (less than 10). As experience increases, more powerful versions of the same spells can be used. > I agree with you about the dumb idea of gaining levels to be able to do > things. To me this is just a way of making the game last longer (which > is unfortunately the intention of the programmers). [stuff deleted] I don't quite agree. I like watching my cast of characters grow from a bunch of pathetic weaklings to a well-organized group of heroic adventurers. > [stuff deleted] I would like to see a game > designed where you have to be really sharp to find any magic items > and have nothing mentioned in the book about them. You would be > forced to learn about the history of the place, or talk to the right > people, or maybe even experiment with the object before you learned > its secrets. Like Ultima IV, where you had to find reagents and combine them in the correct proportions to create spells. What I liked about this system is that for some of the spells you had to experiment by yourself (given that you're familiar with the effects of various reagents) to get the right combination! > >2) Running out of food, torches and so on. I think this reduces many > >aspects of gameplay to tedium. Sure, you'd have to have these things > >in real life, but I don't see that this adds anything to a game. I prefer to think of it as non-combat planning strategy. From M&M II (now playing): "Let's see, should I spend 20 gold on a lantern, given that I have two characters which can cast light spells, or use the money to buy that nifty ring mail?" As it turned out, I ended up with an extinguished light in a non-magic zone shortly thereafter. I don't have a problem with having to do this sort of planning (unless taken to an extreme). > >3) Having a "quest" be an integral part of a game. Once the "quest" has > >been accomplished, the game is more or less over. [stuff deleted] I agree, but if we remove this, what is the purpose of the game? We could make it an "exploration" game, but without the "goal" incentive most kids might not be too interested in it, and the game wouldn't sell as well. About the need of alternate ways to solve an adventure (or a specific puzzle): you're right on target!! > >4) Lack of originality is chronic! Every game seems to have a few attack > >spells, a few heal spells, transport spells and so on. For characters, > >you get fighters, wizards and clerics; sometimes you get thieves, ninjas > >and the like. Once again, I'd like to see more effort put into creating > >a real "world" with characteristics to be learned as the game goes on. > > I agree! Here's another one for all you gamers out there: > What about the whole concept of *hit points*? Now just think about > that for a second. "Hit points"? We're so used to thinking in > those terms we can't see how absurd this idea is. When you're > dealing with computers of course one must reduce everything about > a character to bits and bytes, but why be so bloody obvious about > it? Or *at least* have the character be *wounded* if he's lost a > few "hit points"! Your character could have 100 HP and be down to > his very last HP (1 HP) and still be fighting like nothing is wrong. > Stupid. Excellent point. All these concepts (character classes, hardwired moral alignments, hit/magic points, etc.) are leftovers from AD&D, which have since been superseded (sp?) by better game mechanics. One of the things I liked the most from Interplay's Wasteland is that you could create any kind of character if you gave him/her the right set of skills (no character classes here). I think that the computer should be used to REMOVE the number-crunching drudgery from the game. As the character advances in experience (note that I haven't made any mention of levels) she would realize that she can strike harder / last more in combat / cast more powerful spells than before. While we're at it, what's with the f*@&!#% obsession with Sword-and-Sorcery scenarios in CRPGs? What's wrong with roleplaying in other historical/fantasy scenarios (Cyberpunk, feudal Japan, traditional SF)? Me, I'd love to see a CRPG based on turn-of-the-century science and adventure fiction (Jules Verne, H.G. Wells, Edgar Rice Burroughs, etc). I haven't played the Space 1889 RPG, but it sounds similar. > >One of the best games I've had was Might and Magic. > > You've got good taste. :-) Personally, I prefer the Ultima series. Also, note that all of the faults described above can be found in Might & Magic. Waiting for a computer equivalent of GURPS, -- E n r i q u e C o n t y jester@ihlpl.att.com
sandy@snoopy.cs.umass.edu (& Wise) (11/06/90)
> Me, I'd love to see a CRPG based on turn-of-the-century science and > adventure fiction (Jules Verne, H.G. Wells, Edgar Rice Burroughs, > etc). I haven't played the Space 1889 RPG, but it sounds similar. I recently saw a review of a CRPG based on the GDW's _Traveller_ mechanics, and world (the game occurs just before the Fifth Frontier War, for those knowledgable about Imperium history). Apparently, the same company has a _Space 1889_ game... I think the article was in "Computer Gaming" magazine... /s -- Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory /\/\/\/\/\/\/\/\/\/\/\/\/\/\ WISE@CS.UMASS.EDU /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\
man@cs.brown.edu (Mark H. Nodine) (11/07/90)
In article <QbB2aqm00WB381m2ZV@andrew.cmu.edu>, ck31+@andrew.cmu.edu (Christopher Bruce Kidwell) writes: |> On a different note, have any games dealt with the problem of a group of |> about six characters defeating hundreds of enemies without being killed? |> In Bard's Tale (I forgot which one) the party has to fight four groups of |> 99 Bezerkers. It seems to me that if about 20 of them came charging from |> all directions, the party wouldn't stand a chance. I seem to remember |> someone mentioning a rule like this from AD&D to the effect that if a |> character is surrounded by more than four enemies, he is automatically |> defeated. I'm not convinced that this is a problem that needs fixing. History is replete with examples where a few people held off entire armies. For example, II Samuel 23 lists some pretty great accomplishments, like Eleazar, who routed an entire army after the rest of the Israelites had fled. There are modern-day examples, too, like during the Mexican-American war, where a few sharpshooters turned away the Mexican army by lying low in a reedy field and standing up only to shoot. The problem with your argument is that even if 20 people came from all sides, you probably couldn't get more than 4 of them close enough to do any damage at any given time. If a single fighter is enough better than his opponents that he can hold off four at a time (especially after the bodies start piling up), then he can hold off indefinitely and keep smiting his foes until he tires. --Mark
francis@arthur.uchicago.edu (Francis Stracke) (11/08/90)
In article <55634@brunix.UUCP> man@cs.brown.edu (Mark H. Nodine) writes: >In article <QbB2aqm00WB381m2ZV@andrew.cmu.edu>, ck31+@andrew.cmu.edu (Christopher Bruce Kidwell) writes: >|> [...] I seem to remember >|> someone mentioning a rule like this from AD&D to the effect that if a >|> character is surrounded by more than four enemies, he is automatically >|> defeated. For what it's worth, AD&D has no such rule. Good Lord, what imbalance that would create! "Sorry, your 357th level fighter is dead." "Why?" "Well, he got surrounded by five kobolds." Yeah, right. | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Non sequiturs make me eat lampshades | | francis@zaphod.uchicago.edu | |
bhv@ddsw1.MCS.COM (Bronis Vidugiris) (11/08/90)
In article <1990Nov3.234058.23166@magnus.ircc.ohio-state.edu> smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes:
)This is being cross-listed to rec.games.misc. Let's try to keep
)this discussion on the *design* of a game, *not* the system which
)it runs on, OK?
)
)Patrick Jost <jost@coyote.trw.com> says:
)
)>Here are some of my "gripes" with most adventure games, and possible solutions
)>for what I'd consider better games:
)I agree! Here's another one for all you gamers out there:
)What about the whole concept of *hit points*? Now just think about
)that for a second. "Hit points"? We're so used to thinking in
)those terms we can't see how absurd this idea is. When you're
)dealing with computers of course one must reduce everything about
)a character to bits and bytes, but why be so bloody obvious about
)it? Or *at least* have the character be *wounded* if he's lost a
)few "hit points"! Your character could have 100 HP and be down to
)his very last HP (1 HP) and still be fighting like nothing is wrong.
)Stupid.
)
Runequest (a non-computer FRP game) has a very good fixed hitpoint system
which avoids this problem. The only drawback is that even a very experienced
character can be killed in one blow by a lucky shot. This is probably
realistic, but it's not very dramatic.
Hit points were fixed from the start, based mostly on constitution and
size, and were subdivided into specific locations. The system would cover
incapacitated and totally severed limbs. A severed result for a vital
area like the head would mean instant death.
The original Runequest had a pretty good magic system which was not
excessively powerful (at least the battle-magic spells were not - the rune
magic spells might be a little on the strong side). I'm not sure what these
are callled in the new Avalon Hill version, which has everything under the
sun as far as magic goes - but a typical spell would be bladesharp, which
would give edged weapons an extra hit probability and damage, or a
protection spell which would add a small amount of extra armor protection.
Direct damage spells were rare - though there was a befuddle (confusion), a
'hold person' equivalent (harmonize - by its nature only usable on one person
unlike the DD variety), and a 'disrupt' - one target SMALL direct damage.
Runequest also had a skill based system, and one didn't pick and
choose what skills one got better in, but improved them through direct
practice (with possible assist through expensive training - but training
would require improvement through direct personal experience after a point).
Its a very nice system - the only drawback to it is that the
characters generated are more or less human, not demi-gods.
[This may be an advantage - but I think that the demi-god
nature of many of the popular game system meets some
dramatic and psych needs].draphsor@elaine0.stanford.edu (Matt Rollefson) (11/08/90)
It looks like what you guys are looking for is not so much a computer role-playing game of the sort that have come out (basically hack-n-slash, with some puzzle solving but to an extent isolated from the role-playing experience), but rather an implementation of a role-playing system on the computer. That is, getting the computer to represent your characters and the world they interact with in its terms, and to take care of all the mechanical stuff of how they interact, how combat works, etc. A couple of points. 1) This is a *very* ambitious project. From what I've seen, most computer games implement a fairly detailed combat system, a detailed but simplistic magic system (mainly useful in combat), and then a very simplistic set of rules about movement and character interaction. The character interaction stuff especially is very weak. Now, if you're going to make a really general game system, you're going to have to throw away all assumptions about what kind of characters are going to be coming along, what kind of goals they're going to have, etc. The programmer will have to come up with a completely *general* way for non-player characters to react to the players. This is a daunting task to say the least. Even the less demanding (theoretically - as, to truly implement general NPC reaction, you need sophisticated AI) task of setting up rules for most of the normal actions characters wish to take is pretty tough. To get an idea of the number of rules needed, take a look at a Role-Playing Game - say, GURPS. The Basic rulebook is about 300 pages. Granted, not all of this is mechanistic rules by any means. But still, there's a lot of information in there. Coding this in a general way would be real tough. But, let's grant that we are able to do this - code a general system. We now have to create a world. On the character-creation side, this isn't too tough. We just give the players certain limited options depending on how the world is set up. But when it comes time to start detailing the world - well, here you're in trouble. As soon as you throw away the 'quest' and 'one true path' ideas, you have to attempt to account for *everything* your characters might do. In a RPG with a game master, the game master can make the decisions about how hard this wall is to climb and such. A computer isn't quite so smart - it needs to know. You'd need a very sophisticated world-builder with a large set of objects in order to come up with anything vaguely believable. Not to say that it couldn't be done. But it would be tough. In conclusion, I guess what I'm trying to say is that the games that most people here seem to want (and I must admit, I'm one of them in spades!) are out of the realm of true 'games' and much more into 'simulations'. When you're trying to simulate the complexities of 'real' life (albeit with fantastic elements), the programming gets incredibly complex. (This is speaking as a purely amateur pseudo-programmer; I've done some very limited actual programming. But I think I have a good enough understanding to be at least semi-aware of the difficulties involved. At the very least, I don't think I'm over-stating the difficulty...) 2) There is no 2. I said everything I wanted to say in 1. :) -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
draphsor@elaine0.stanford.edu (Matt Rollefson) (11/08/90)
lwl@eniac.seas.upenn.edu (Lydia Leong) writes: >I believe that inventory management - food, torches, and the like - is >necessary in a truly excellent RPG. Well-implemented, it becomes part of the >game world, enhancing rather than detracting from the gaming experience. Once >again, look at Ultima VI. Here, players may fish for food, buy meat, or even >buy flour and take it to a bakery and have it made into bread. This helps >bring the world to life. Having unlimited resources is good in a dungeon >hack 'n slash game, but not in a game where discovery is important. Well, it depends on what the object of the game is. If the game is basically just combat and exploration - how far can I get on how much money, etc - then inventory management becomes an element of strategy. If your game focuses more on role-playing and doing things in different places (exploration, but of a less war-game orientation), then it becomes annoying. After all, you'd think that characters who lived in those times would have developed certain 'standard' procedures to deal with things like getting food. Options: Make the player do everything. Grittily realistic (assuming realistic rules - not a given by *any* means), but can become tedious as you prepare for your tenth overland journey and have to go to the same five shops to get the provisions you need. Let the player create 'standard operating procedures'. Go through the gritty realism once, then save that as a macro (basically) and reimpliment it whenever the same situation comes up. This can be more or less automatic. Forget about all this boring stuff, and get to the excitement. Makes the game play more like a 'high fantasy' novel, where the mundane concerns of when to go to the bathroom and where to get food never seem to bother the characters, except when it adds to dramatic tension. Runs the risk of losing suspension of disbelief, though. For instance, if there is no way for the player to make an intelligent choice and avoid (near- this is heroic, remember) starvation in the desert, the player is going to get frustrated by the lack of control. Well, that's enough for this posting. Comments? >Anybody agree? -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
draphsor@elaine0.stanford.edu (Matt Rollefson) (11/08/90)
ck31+@andrew.cmu.edu (Christopher Bruce Kidwell) writes: [comments on hit points deleted] >On a different note, have any games dealt with the problem of a group of >about six characters defeating hundreds of enemies without being killed? >In Bard's Tale (I forgot which one) the party has to fight four groups of >99 Bezerkers. It seems to me that if about 20 of them came charging from >all directions, the party wouldn't stand a chance. I seem to remember >someone mentioning a rule like this from AD&D to the effect that if a >character is surrounded by more than four enemies, he is automatically >defeated. Well, there is no such rule in AD&D, as others have noted. However, you do have a point. It depends on what you're trying to do with the game - heroic fantasy where one man can hold off an army, or 'realistic' fantasy, where the guy's dead after the first three or four. This is an issue with 'normal' RPGs as well - GURPS is quite realistic, AD&D much less so. It's just that most of the computer games so far have been in the heroic mold, and even more specifically, the 'hack-n-slash' mode, where the whole point of the game is to kill scads of things. In real life, if you're a good but not incredible swordsman/martial artist/etc, you can expect to defeat up to say 90% of your opponents, if their skills varies in some bell curve and the outcome is not purely dependent on skill. (NOTE: These numbers are completely made up, not based on any real-world numbers or anything. I'm just giving examples.) Given this, how long will it be before you get defeated once? Once you get up to say 50 total combats, the chances of your being undefeated are real low. (Someone could do probabilities if they want to.) In combat to the death, you can only lose once. So bye-bye realism already, in any system where you need to kill >50 monsters/fighters/whatever to complete the game. In summary: Again, it looks like we want more realistic games, more on the order of simulations. (See my previous post.) Anyone want to write one? >Any thoughts? >Chris Kidwell >ck31@andrew.cmu.edu -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
draphsor@elaine0.stanford.edu (Matt Rollefson) (11/08/90)
man@cs.brown.edu (Mark H. Nodine) writes: >In article <QbB2aqm00WB381m2ZV@andrew.cmu.edu>, ck31+@andrew.cmu.edu (Christopher Bruce Kidwell) writes: >>[Discussion of 'problem' with being able to defeat multiple enemies.] >I'm not convinced that this is a problem that needs fixing. History is replete >with examples where a few people held off entire armies. For example, II Samuel 23 >lists some pretty great accomplishments, like Eleazar, who routed an entire army >after the rest of the Israelites had fled. There are modern-day examples, too, >like during the Mexican-American war, where a few sharpshooters turned away the >Mexican army by lying low in a reedy field and standing up only to shoot. >The problem with your argument is that even if 20 people came from all sides, you >probably couldn't get more than 4 of them close enough to do any damage at any >given time. If a single fighter is enough better than his opponents that he can >hold off four at a time (especially after the bodies start piling up), then he >can hold off indefinitely and keep smiting his foes until he tires. ^^^^^^^^^^^^^^ Granted. But he's going to tire pretty quickly. All the massive enemy has to do is surround him and camp out. He can't kill them, because if he attacks anyone he lets down his guard and three other people attack him. They can defend themselves, and just wait till he has to go to sleep, if they can't tire him out by making him run around. Overwhelming numbers will win out every time, except in specific cases where the defender has an overwhelming tactical advantage. And even then, time will usually tell. CRPGs in general don't model fatigue in combat very well. On another note: How do you think the program should tell the player the state of his characters? As in, when they're wounded, tired, hungry, etc. Hit points are annoying aesthetically, but they're simple. What options are there besides numeric displays? Here are some of my thoughts: Graphical displays. Work the same as numeric, except you don't necessarily know what the maximum is. Not all that much an improvement aesthetically. Maintains simplicity and ease of use. Text alerts. Better, as it gives much more flexibility. (You are sorely wounded, you are about to die, etc.) But, can be extremely distracting and/or easy to miss. Difficult to integrate with a graphically-based game. Pretty pictures. These would be displayed when certain conditions occured. Again, disrupt the flow of the game, but they do make things more interesting. Direct Sensory Stimulation. If your character is thirsty, you're thirsty. If he gets wounded, you bleed. Too bad the technology isn't quite there yet... :) Any other thoughts? Comments? Etc? > --Mark -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) (11/09/90)
Matt Rollefson in my opinion has posted a few *great* articles in the past couple days. I would just like to comment on a few things; look at his previous postings under this same subject to reconstruct my severely cut-up quotes: >>I believe that inventory management - food, torches, and the like - is >>necessary in a truly excellent RPG... >Well, it depends on what the object of the game is... >Options: >Make the player do everything. Grittily realistic... >Let the player create 'standard operating procedures'... > ...then save that as a macro ... >Forget about all this boring stuff, and get to the excitement... Matt is right in pointing out that one has to decide first between realistic, fun, expediency, pace, etc. in a game before you can sit down to answer specific questions about whether you should include a particular item in a game or not. In other words, just *how* realistic do you want it to be? Does your character need to put his shoes on in the morning or not? Realistically speaking he does, for the purposes of game play probably not--at least not performed by the player. In my original posting I did a lot of griping about RPG methods. I would like to qualify those remarks by saying that for the limited budget and limited time some companies have put out *excellent* products. But I would also like to point out something which I have failed to notice until recently. When computer games first became popular they tended to follow the arcade games and were largely shoot'em up/ eat'em up scenarios. As we all know the majority of video games (coin op) fall into this category (Space Invaders, Pac Man, etc.). Having been weened on games in which entire ships are blown up screen after screen we have become accustomed to waltzing through scores of enemy fighters in less than a minute. I believe this mentality has been carried over into the RPG world. Think about it a second: How many monsters do you kill in the average RPG? Several dozen? (Bzzzzzzt...) Several hundred? (Bzzzzzzzt....) Thousands? (Ding ding ding!) Even in those RPG's which I consider to be most "realistic" you still have to wade through *thousands* of those hairy and scaly brutes to get through the game. This goes for Bard's Tale, Might and Magic, all the AD&D games, and Ultima. I think if we sat down and calculated how many monsters we kill in the average game we would be appalled. I'm playing Might and Magic 2 right now and I'm on about my 1400th *battle* (not enemy--BATTLE). This would translate into around 5,000-10,000 wasted critters, and I'm only about half done with the game! The reason for this, as I said above, is that this is what we are used to. What I would like to see in an RPG is more anticipation leading up to the conflict, and having these conflicts be fewer in number. Suggested scenario: You talk to a villager. She/he mentions hearing about some monsters (fill in monster's name/type) doing something bad. In the next town you find a library in which there is a book on monsters. You read up on the monster you heard about and find out it eats kyppo weed. In another place you meet a man who is a grocer, and if you ask him about kyppo weed he'll say that it only grows in certain areas, specifically in a plateau above Mt. X. (to make a long story short)...you find out all you can about these monsters, you equip yourself accordingly, you hire a guide, figure out which way the battle should be fought (tactics--based on what you know about the monsters), then you go to meet them. Tons of other stuff could be put in along the way to increase the anticipation of the encounter and to make the learning/finding process fun and enjoyable. Now, to me, I wouldn't mind a game being almost totally that way. Sure, a few surpise encounters would be necessary and welcomed. But even in those situations you should have been told how best to confront enemies under various conditions. You may say to me "how boring...walking around, gathering clues, talking to people, reading books--dullesville city." Ah hah!--that attitude to me betrays that you have been negatively influenced by the unrealistic, fast-paced, and *boring* majority of Mac/PC games. Many things in an RPG could be included for simply the *fun* of discovering; the only thing boring about a "slower paced" game would be something that the designer put in that *was* boring. >It's just that most of the computer games so far have been in >the heroic mold, and even more specifically, the 'hack-n-slash' mode, >where the whole point of the game is to kill scads of things... > ...In combat to >the death, you can only lose once. So bye-bye realism already, in any >system where you need to kill >50 monsters/fighters/whatever to complete >the game. Exactly. So what I would like to see in a game is the ability to survive your battles by means of preparation, strategy, and even character training so that your character has the ability to fight a particular foe because he has *learned* more about that foe. (Translated into computer jargon--a +4 against a kyppo weedeater because he has learned a lot about just how to strike them, etc.) I guess this betrays what I feel about resurrection spells and the like. (Hmm...my character died. No prob; I'll just toss the temple priest a few bucks...) >CRPGs in general don't model fatigue in combat very well. Agreed. The only one that I know of that has done this well is Knights of Legend. In this RPG if you try to fight too much round and after round you can fall down from exhaustion, and if you cut your enemy enough he will retire from the combat and might even die from blood loss a few rounds later (all by himself). >On another note: How do you think the program should tell the player >the state of his characters? As in, when they're wounded, tired, >hungry, etc. Hit points are annoying aesthetically, but they're simple. >What options are there besides numeric displays? Here are some of my >thoughts: >Graphical displays.. >Text alerts... >Pretty pictures... >Direct Sensory Stimulation... Aye, there's the rub. What interface will you use? Do we need to rethink our whole windowing environment? We say we want realism, but on the other hand we don't want to be bothered by the real mundane things. For me, the worst interfacing techniques that have been used have included things I already know and don't care about (like the name of the game--how stupid to take up space on your screen for that!!!), or neglected to point out really important things such as items that were picked up, or diseases/poisonings which have occurred for your characters ("gee, how did Bigsley die? Did I save the game with him dead last time I played?") Is there some way for the player to choose how his interface should look and what information is to be displayed there? This would be the *neatest* way of doing it. Like a choice between statistics via pure numbers, or a bar graph representing that. One could choose whether to have a lot of information displayed on the first screen or whether to subordinate much of that info to subscreens. Word processors and other programs allow that to some degree; would that be too costly for the commercial game? That's it for now! Not much practical advice here, just abstract philosophical mutterings. S. "Stevie" Smith \ + / <smsmith@hpuxa. \+++++/ " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@ ircc.ohio-state. \ + / {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-) " edu> \ + / BTW, WYSInaWYG \ + / --witty.saying.ARC
draphsor@elaine0.stanford.edu (Matt Rollefson) (11/11/90)
smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes: >Matt Rollefson in my opinion has posted a few *great* articles in the >past couple days. Thank you, thank you, thank you. And for my next trick... :) Seriously, there is a reason for this followup, although it's fairly minor. [Much deleted. Of a very good article, btw - why don't you read it?] [No, I'm not talking about my article - I'm not that much of an arrogant fool! I'm talking about Stephen Smith's article.] > [Discussion of how most CRPGs have been rather video-game-like.] >The reason for this, as I said above, is that this is what we >are used to. What I would like to see in an RPG is more anticipation >leading up to the conflict, and having these conflicts be fewer >in number. Suggested scenario: >You talk to a villager. She/he mentions hearing about >some monsters (fill in monster's name/type) doing something >bad. >In the next town you find a library in which there is a >book on monsters. You read up on the monster you >heard about and find out it eats kyppo weed. >In another place you meet a man who is a grocer, and if you >ask him about kyppo weed he'll say that it only grows in certain >areas, specifically in a plateau above Mt. X. >(to make a long story short)...you find out all you can about >these monsters, you equip yourself accordingly, you hire a guide, >figure out which way the battle should be fought (tactics--based >on what you know about the monsters), then you go to meet them. >Tons of other stuff could be put in along the way to increase >the anticipation of the encounter and to make the learning/finding >process fun and enjoyable. I like it. It's the same debate as in RPGs - hack 'n' slash vs a more 'realistic' scenario. And there's no reason that this can't be maintained even in the heroic setting. For that matter, the basic hack 'n' slash adventure isn't all that 'heroic'. After all, what's heroic about killing twenty orcs when none of them have a chance of harming you? In my opinion, heroic is going up against long odds and winning. It's searching far and wide for every scrap of information about a vastly superior monster, in the hopes that you will, somehow, manage to defeat it. It's tiptoeing into the dragon's cave, armed with the best weapons you've been able to find, hoping against hope that the dragon won't wake up. It's that sinking feeling when you see those two balefully glowing red eyes... Most monsters in the arcade-style games are pitifully weak, compared to the typical party. As someone mentioned somewhere else (I don't remember if it was this thread or not), some of the major nasties in Bard's Tale that you meet at the end are pretty awesome monsters - the greater demons, for instance. But against a party, they're toast. You'd need about twenty greater demons to take out the typical Bard's Tale party that's progressed that far. You only meet one, or at the most five. This is as it has to be when you keep meeting more monsters every time you turn around. But there's no reason this should be the only type of game available. What would be nice to see in these games is a bit of a reality-check in terms of monster vs player strength. The power scale is simply not as steep as most games model it. That is, the difference between a typical monster (orc, say) and a high-level adventurer should not be that huge. Sure, the high-level adventurer should be able to beat the orc in almost any one-on-one confrontation. But he shouldn't have 20 to 30 *times* the life-expectancy, and armor that is orders of magnitude better. (Doesn't it bug you how nothing can ever hit your characters? Not ever? And then when something finally can, you get pissed off? Because you didn't think anything could ever hit your characters? I mean, you have no basis for judging beforehand if something can hit you or not.) I think the scale should be trimmed down a *lot*. Then battles which you truly plan ahead for are possible. After all, no one wants to fight a battle where there are one to one odds. You want overwhelming superiority. If you can't count on one character being 'overwhelming' relative to twenty orcs, you bring in tactics. You start having to think, instead of just pushing the (f)ight key. Well, enough gaming philosophy for the nonce. Is anyone besides Stephen and myself interested in this thread? :) -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
jost@acme.coyote.trw.com (Patrick Jost) (11/13/90)
Yes, I'm interested in this thread. What I'd like to see is a balance...between the "hack and slash" genre and the puzzle-ridden "Shadowgate" genre. I just like to tinker...I got SimEarth on Saturday...guess how I spent most of the weekend... PJ -- | Patrick Jost (PJester) | "The thief of Baghdad hides in Islington now" | jost@coyote.trw.com | -Marillion (Fish)
hirai@cs.swarthmore.edu (Eiji Hirai) (11/13/90)
draphsor@elaine0.stanford.edu (Matt Rollefson) writes: > > I like it. It's the same debate as in RPGs - hack 'n' slash vs a more > 'realistic' scenario. And there's no reason that this can't be > maintained even in the heroic setting. I agree. I think one of the reasons why hack-n-slash games are prevalent is because they're so easy to program and doesn't require much thought in planning the details of the game. In planning a more non-hack-n-slash game requires you to come up with an entirely new way of interacting with the npc's and having to give them motivations, etc. Not an easy task, but do-able. In any case, there are programs out there like this. I remember playing a game on an Apple II (IIe wasn't even out then) where you were the head of a group of surviving rebel forces, trying to oust this evil lord who's taken over you rland or somesuch. In any case, if you fight with him at the start of the game, you lose big-time since your forces are just too small. What you have to do is to recruit sympathetic forces by sending various political messages and bribes to other lords in the area. Only by mustering the allied forces can you even think of attacking the big bad dude. Each lord had their own motivations so you had to figure out what sort of deal you could cut with them individually. No hack-n-slash here, though I would term this an rpg game. Down with hack-n-slash! -- Eiji Hirai @ Mathematics Dept., Swarthmore College, Swarthmore, PA 19081-1397 hirai@cs.swarthmore.edu | hirai@swarthmr.bitnet | uunet!hirai%cs.swarthmore.edu Copyright 1990 by Eiji Hirai. All Rights Reserved. Permission to reproduce or quote explicitly denied except on Usenet. I don't speak for Swarthmore College.
smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) (11/13/90)
Matt Rollefson writes: >What would be nice to see in these games is a bit of a reality-check in >terms of monster vs player strength. The power scale is simply not as >steep as most games model it. That is, the difference between a typical >monster (orc, say) and a high-level adventurer should not be that huge. >Sure, the high-level adventurer should be able to beat the orc in almost >any one-on-one confrontation. But he shouldn't have 20 to 30 *times* >the life-expectancy, and armor that is orders of magnitude better. Here's another thought: Why should all the monsters have predetermined strengths, agility, "HP", etc.? If your elf fighter or dwarf fighter can range from "level 1" to "level 20", why does an orc always have the same HP and the same AC? Sure, every now and then you get an "orc leader" but this is rare. The reason this is done is twofold: 1) Since you have about 2,000 encounters in the average game you can't make them all different unless you have a random generator roll the monster's stats each time. But this would not be creative and might even make battles annoying. 2) Easier to program. Every monster X will have class A characteristics, every monster Y will have class B characteristics, etc. Solution: Reduce the the number of encounters to around 300 (?) and make each monster different from the next even within the same species. You might think that a reduction from, say, 2,000 encounters down to only 300 encounters is too drastic. On the contrary, in my opinion that is still too many. If you play 6 hours a day, 7 days a week, and encounter a monster (or a group of monsters) once each hour, it would still take you over 7 weeks to finish the game. I would probably make the game so that you would fight about 100 battles, one every 3 hours of real time. This would still barely give you time to prepare yourself, learn where the monster(s) is(are), find all you can about your foe, plan your battle strategy, etc. Plus the game would not be designed around simply fighting battles--fighting would be one element of the gaming world's environment. S. "Stevie" Smith \ + / <smsmith@hpuxa. \+++++/ " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@ ircc.ohio-state. \ + / {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-) " edu> \ + / BTW, WYSInaWYG \ + / --witty.saying.ARC
draphsor@elaine0.stanford.edu (Matt Rollefson) (11/13/90)
hirai@cs.swarthmore.edu (Eiji Hirai) writes: >In planning a more non-hack-n-slash game requires you to come up with an >entirely new way of interacting with the npc's and having to give them >motivations, etc. Not an easy task, but do-able. >In any case, there are programs out there like this. I remember playing a >game on an Apple II (IIe wasn't even out then) where you were the head of a >group of surviving rebel forces, trying to oust this evil lord who's taken >over you rland or somesuch. In any case, if you fight with him at the start >of the game, you lose big-time since your forces are just too small. >What you have to do is to recruit sympathetic forces by sending various >political messages and bribes to other lords in the area. Only by mustering >the allied forces can you even think of attacking the big bad dude. >Each lord had their own motivations so you had to figure out what sort of >deal you could cut with them individually. Sounds like fun. Although this is somewhat of a different genre - it's more like a large-scale strategy boardgame, such as Diplomacy, from the way you describe it. Role-playing in a sense, but not in a real personal level. Or do you have an individual character who has to move about the land to meet with the neighboring lords and such? Maybe my interpretation is off. >No hack-n-slash here, though I would term this an rpg game. Down with >hack-n-slash! Well, I wouldn't go that far. You have to keep the kids amused, after all! Besides, a well-implemented CRPG would be extremely complex, and therefore extremely expensive. I'd like to see the game companies stay in business. Selling to kids (and their parents) is the way to do it. >Eiji Hirai @ Mathematics Dept., Swarthmore College, Swarthmore, PA 19081-1397 >hirai@cs.swarthmore.edu | hirai@swarthmr.bitnet | uunet!hirai%cs.swarthmore.edu >Copyright 1990 by Eiji Hirai. All Rights Reserved. Permission to reproduce or >quote explicitly denied except on Usenet. I don't speak for Swarthmore College. -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
draphsor@elaine0.stanford.edu (Matt Rollefson) (11/13/90)
smsmith@hpuxa.ircc.ohio-state.edu (Stephen M. Smith) writes: >Here's another thought: Why should all the monsters have predetermined >strengths, agility, "HP", etc.? If your elf fighter or dwarf fighter >can range from "level 1" to "level 20", why does an orc always have >the same HP and the same AC? Excellent point. > Sure, every now and then you get an >"orc leader" but this is rare. The reason this is done is twofold: > 1) [w/2000 encounters, tough to make the monsters different > from the average.] Very true. The number of encounters is ridiculous. > 2) Easier to program. Every monster X will have class A > characteristics, every monster Y will have class B > characteristics, etc. I'm not so convinced on this one. I don't see why it would be that much tougher to give each monster X a range of characteristics in class A, each monster Y a (different) range in a (different) class B. The problem is not the programming, but rather the game conception. >Solution: Reduce the the number of encounters to around 300 (?) and >make each monster different from the next even within the same species. Like you, I'd actually like to see it go much lower - by another order of magnitude, in fact. > ... Plus the game >would not be designed around simply fighting battles--fighting would >be one element of the gaming world's environment. Exactly. Ideally, fighting would become something to be *avoided*, not sought out. Admittedly, in some heroic fantasy the hero seems to revel in battle, and even seek it out. But in real life (even real fantasy life :) ), you aren't going to go out and risk your neck without a *very* good reason. (And going into combat is a risk no matter your level of skill - in real life. In the typical hack 'n' slash game, of course, it's usually no longer a risk after the first three hours of playing the game, if you stay in the 'easy' dungeons long enough.) I'd like to see quests that could even be accomplished without combat, if you were extremely lucky/clever/skilled. Not to say that everything was a puzzle. More like there are two ways to go about things. For instance, there is a guard at a gate. You can kill the guard and walk in, or you can sneak past him. Often, getting into a fight is the worse approach - the guard is likely to cry for help. Now, there, I've just opened a huge can of worms. Yes, let's talk about it. The NPCs need to be intelligent. Our program (simulation, actually) now needs to keep track of who is within hearing of the guard, how soon they'll arrive, if he'll cry out, etc. Complication has gone up by another order of magnitude. The reason? We're asking for a program to model a dynamic world now. Most game worlds are static - they don't change until the player comes along. In a real simulation, things should be happening despite me as well as because of me. This becomes extremely difficult to program, though. Well, that's enough for tonight. I've been enjoying this discussion - hope you are too. (The lurkers, that is. I'm pretty sure that the other participants have enjoyed it, judging by their posts. Yay! No flames. And after reading comp.sys.mac.misc.next.flame.war, that is indeed a relief! :) ) -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
grue@batserver.cs.uq.oz.au (Frobozz) (11/14/90)
draphsor@elaine0.stanford.edu (Matt Rollefson) writes: >Now, there, I've just opened a huge can of worms. Yes, let's talk about >it. The NPCs need to be intelligent. Our program (simulation, >actually) now needs to keep track of who is within hearing of the guard, >how soon they'll arrive, if he'll cry out, etc. Complication has gone >up by another order of magnitude. The reason? We're asking for a >program to model a dynamic world now. Most game worlds are static - >they don't change until the player comes along. In a real simulation, >things should be happening despite me as well as because of me. This >becomes extremely difficult to program, though. I don't think that programming such a thing would be become extremely difficult. I do think that it would require a different approach to the problem. I'm not sure that the end result would be all that playable as a game. It would be a lot of fun as a simulation and it might be passable as a wargame (with multiple enemies all fighting with each other). The response time would probably degrade too much to be viable as a CRPG. Back to why I think it wouldn't be too much harder: You'd have to consider NPC - NPC interactions (rather than simply player - NPC) If the NPCs and PCs were properly written, the complexity shouldn't increase all that much: Define a class Character and sub-class it with NPC and PC. Declare a lot of virtual procedures that detail how the Character will interact with another Character. (for the PC sub-class, this requires input from the user, for the NPC some cute decisions have to be made). Consider all interactions as Character - Character ones and you are done. Running a CRPG as a discrete event simulation seems to be a very nice way to go. Whenever a Character does something, the associated process does a hold for the required time. No longer does combat take place in combat rounds. No longer does movement take place in steps. Everything happens in a pseudo continuous time. If it takes you 1 second to perform a task, then the game time will advance that one second and anything else that might have happened during that time can take place. The biggest problem with this is that it would be slow to play since all those extra interactions are going on in the background. e.g. If a player decides to perform a very time-consuming task (searching for traps/secret doors) the computer may take several minutes to say 'you found nothing'. One possible solution to this problem would be to restrict the area around the player when NPC - NPC interactions are occurring, this will have a harmful effect on the continuity of the rest of the game. It is slightly harder to implement but it should get response time back to a reasonable level. There is also the problem that current programming languages (things like Pascal, C and C++ even), has problems implementing co-routines and these are just about necessary for the successful implementation of a simulation of the magnitude that would be required. Event simulations (explained later) (which can be written in C without too many problems) are just too difficult to work with and a CRPG is a non-trivial task at the best of times. I'll now try to show the difference between an event simulation and a process simulation (which is what I was advocating initially). This isn't a very good description of what actually happens, but it should give some idea of the problems. A process simulation is based around the concept of a process, a process is a co-routine. If a process desires a pause in the action of, say 10 seconds, it makes a call Hold(10) which lets other processes take control until simulated time is 10 later than it is now. Things are generally nice to write since all of your delaying constructs appear in-line. An event simulation is based around events. Events are the things that say at this time, activate that piece of code. So my previous example, becomes create an event descriptor to be activated at the current time + 10 seconds with a pointer to this piece of code. When the simulated time gets advanced 10 seconds, the code is called/activated. This means that every entity becomes a series of procedures that get linked together by these event descriptors. You sort of lose a lot of your structure using this method. Process simulations are based on events but they're hidden from the user and because co-routines are used, the event descriptor can say at time t, continue execution from where I was before I made this call. Event simulations are lower-level and thus some things can be performed more efficiently using them but the extra effort is not usually worthwhile. (Do you write large programs in assembler or a high level language???). BTW: There is a public domain implementation of the programming language Simula for the mac which is very good at implementing the constructs needed. gee, did I really ramble on that much? Pauli seeya Paul Dale | Internet/CSnet: grue@batserver.cs.uq.oz.au Dept of Computer Science| Bitnet: grue%batserver.cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%batserver.cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@batserver.cs.uq.oz | UUCP: uunet!munnari!batserver.cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@batserver.cs.uq.oz.au --
draphsor@elaine12.stanford.edu (Matt Rollefson) (11/15/90)
grue@batserver.cs.uq.oz.au (Frobozz) writes: >draphsor@elaine0.stanford.edu (Matt Rollefson) writes: >>Now, there, I've just opened a huge can of worms. Yes, let's talk about >>it. The NPCs need to be intelligent. Our program (simulation, >>actually) now needs to keep track of who is within hearing of the guard, >>how soon they'll arrive, if he'll cry out, etc. Complication has gone >>up by another order of magnitude. The reason? We're asking for a >>program to model a dynamic world now. Most game worlds are static - >>they don't change until the player comes along. In a real simulation, >>things should be happening despite me as well as because of me. This >>becomes extremely difficult to program, though. >I don't think that programming such a thing would be become extremely difficult. >I do think that it would require a different approach to the problem. I'm not >sure that the end result would be all that playable as a game. It would be a >lot of fun as a simulation and it might be passable as a wargame (with multiple >enemies all fighting with each other). The response time would probably >degrade too much to be viable as a CRPG. Yes, but what is a game but a simulation? As long as there are still objectives and some sort of consistancy (ie the NPCs have personalities, they don't just randomly move about) it's still a game, not 'just' a simulation. The response time is a factor, but there are ways to get around that in the implementation. >Back to why I think it wouldn't be too much harder: [Programming details deleted.] >The biggest problem with this is that it would be slow to play since all those >extra interactions are going on in the background. e.g. If a player decides >to perform a very time-consuming task (searching for traps/secret doors) the >computer may take several minutes to say 'you found nothing'. One possible >solution to this problem would be to restrict the area around the player when >NPC - NPC interactions are occurring, this will have a harmful effect on the >continuity of the rest of the game. It is slightly harder to implement but it >should get response time back to a reasonable level. Actually what I think would work best is to have several important NPCs which you keep track of all the time, and then only the NPCs which are close to the player character are kept track of. A castle would have a basic setup that most of the NPCs are in most of the time, which would then start varying when the PC got close enough. The master of the castle, however, could be doing anything even when the PC was far away. You'd probably have to have two levels of complexity for actions in this system. Obviously you don't care about how far the major NPCs walk in a day spent around their castle. Rather, you care about how their plans are developing and what they're doing to thwart/aid the PC in non-obvious ways. You could either do this as a set script, as a number of set scripts, or as a completely dynamic process. Again, the more general you try to get, the harder it is. [Rest of programming comments deleted.] Looks good. While I'm not up on the technical stuff of how to implement what you suggest, it makes sense. Still, it seems to me that the most difficult part would be making a realistic set of motivations for the NPCs and figuring out how to implement them in a non-trivial way. So, any chance you might want to write such a beast, now that you've described it? I'm sure we could find enough willing playtesters! :) > Pauli -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
grue@batserver.cs.uq.oz.au (Frobozz) (11/15/90)
draphsor@elaine12.stanford.edu (Matt Rollefson) writes: >Yes, but what is a game but a simulation? As long as there are still >objectives and some sort of consistancy (ie the NPCs have personalities, >they don't just randomly move about) it's still a game, not 'just' a >simulation. The response time is a factor, but there are ways to get >around that in the implementation. >Actually what I think would work best is to have several important NPCs >which you keep track of all the time, and then only the NPCs which are >close to the player character are kept track of. A castle would have a >basic setup that most of the NPCs are in most of the time, which would >then start varying when the PC got close enough. The master of the >castle, however, could be doing anything even when the PC was far away. >You'd probably have to have two levels of complexity for actions in this >system. Obviously you don't care about how far the major NPCs walk in a >day spent around their castle. Rather, you care about how their plans >are developing and what they're doing to thwart/aid the PC in >non-obvious ways. You could either do this as a set script, as a number >of set scripts, or as a completely dynamic process. Again, the more >general you try to get, the harder it is. Having special NPCs and normal NPCs makes the coding a fair bit more difficult. You now have players and two distinct types of NPC to worry about. There are now five types of interaction available (player and one of two different NPC, and the three ways of NPCs meeting), it would not be a problem to get rid of the dumb NPC -- dumb NPC interaction since they would not happen unless dumb NPC were capable of independant movement. My prefered design would be one where all NPCs are mobile (possibly restricted) and all of them respond to various cues. An Eliza like talking module should be sufficient most of the time (it would have to be extended to take in more than just word, it must take in actions as well. LPmud implements a 'talking monster' that is capable of doing this sort of thing in a rather ugly way. As for response time, IMHO response time will be bad reguardless of which approach you take (it would be worse for the more general everything is semi-intelligent). Consider the case when the player wants a long duration action to be performed (e.g. eating a meal, going to sleep, casting a ritual spell), while this action is underway all active NPCs are going to be doing their thing. If a couple are slogging away at each other then they are going to be context switching every couple of seconds (simulated time). How many couple of seconds are there in 6 to 8 hours? An awful lot I'd expect. This would inherently make everything slower. Again, the response could be improved by forcing NPC never to get into tightly interactive loops (combat is about the only example I can think of off the top of my head, I am sure that there are others). So, we decided that NPC-NPC combat will not take place as a lot of short term exchanges (which is how I'd do player-NPC combat). Sure, working out some expected damage suffered and short circuiting the entire combat is possible but suddenly we have another special case for the code to consider...keep going like this and NPCs are becoming less and less like players. The less the code looks like players, the more tempting it is to take some extra short cuts to save some work and the cycle repeats itself. I firmly believe that NPCs and players should share just about all of their code. The $200000 question: who would be willing to play a CRPG that had rather non-deterministic response times? Most of the time you would get a reasonably fast response but occasionally you would have a longish wait (two really powerful nasties decide that they both want to eat the player and blast each other to pieces for a few hours simulated time). Finally the first question gets an answer: What is a game but a simulation? I think I probably confused myself and everybody else with my switching of terms everywhere. I agree that a game is a simulation. I failed to make a distinction between a simulation based methodology under which a game is written and the game being a simulation written using a different methodology. A decent CRPG would (IMHO) have to be written using some kind of simulation package/language in order to be able to comprehend things properly. >Looks good. While I'm not up on the technical stuff of how to implement >what you suggest, it makes sense. Still, it seems to me that the most >difficult part would be making a realistic set of motivations for the >NPCs and figuring out how to implement them in a non-trivial way. I agree that creating the NPCs would be a very difficult problem (and one which I would be quite terrible at doing). Creating the background program should not pose too much of a problem, it is likely to be a large thing and it would contain a *LOT* of data (who here realises exactly how much data is contained in your average RPG? As a start choose an interesting section out of your favourite RPG and try to implement it on a compuiter. In a space game I'd suggest trying starship generation or combat, in a fantasy game try combat or perhaps spell casting. And don't simplify anything major either, you need a lot of stuff there to keep the game interesting!). >So, any chance you might want to write such a beast, now that you've >described it? I'm sure we could find enough willing playtesters! :) Writing such a thing is a job that I've wanted to do for quite a long time (several years in fact, the more I think about the problem, the more sophisticated my conceptual design becomes. Originally I just wanted to write a decent text adventure, now I want to do a decent CRPG :-) I think I've rambled on even longer than last time :) Pauli seeya Paul Dale | Internet/CSnet: grue@batserver.cs.uq.oz.au Dept of Computer Science| Bitnet: grue%batserver.cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%batserver.cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@batserver.cs.uq.oz | UUCP: uunet!munnari!batserver.cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@batserver.cs.uq.oz.au --
carl@udwarf.tymnet.com (Carl Baltrunas & Cherie Marinelli 0.1.9) (11/15/90)
In article <draphsor.658482002@elaine0.stanford.edu>, draphsor@elaine0.stanford.edu (Matt Rollefson) writes: > .......... We're asking for a > program to model a dynamic world now. Most game worlds are static - > they don't change until the player comes along. In a real simulation, > things should be happening despite me as well as because of me. This > becomes extremely difficult to program, though. > Draphsor vo'drun-Aelf draphsor@portia.stanford.edu I had a design once for a game called Amazon, set in the amazon jungle and some caves/dungeon nearby (why is there always a cave or dungeon?). Anyway, the game consisted of rooms, objects and players (real and npc). The idea was to have the game maintain all the players and randomly move the npc's that were not part of your party as well as your character and your band of npc's. The movment of npc's was to be according to some role-script and not entirely random. That being the case, the only reason your band fights on your side is because their scripts have a "loyalty" factor built in. If you treat them well, the loyalty factor goes up, if not, it goes down and there is the chance they will attack you (or each other, since they have varying loyalty based on their scripts). Next, the characteristics of all players changes with experience. If you do a lot of fighting, your strength increases. If you make a lot of good decisons, your wisdom goes up. If your move quickly, your agility increases... etc.. for all of the different capabilities. Spells work better the more you use them. (An aside: Read "The Practice Effect" by David Brin, Bantam Books, April 1984, for an example of how tools work better the more you use them, and become dull and useless if they are not used for awhile. Interesting concept.) Also, for some reality, if you happen to be a band of level 3-5 characters and walk into a room with a couple of 9-15 monsters, they may very well be fighting or not, but they'll probably ignore you since you're not much more that a samll nuisance to them (eg. like flies at a picnic). If you attact them, they'll kill you with once swat (if they connect), but otherwise they won't bother you. The major impetus for this design was that most CRPC games were single user, you and your guide vs. the static computer. My game was to be dynamic and allow for multiple players to come and go (or play simultaneously from different access points [vis. terminals]) with all movement of players and objects kept in a shared database (also shared memory on the machine it was designed for) so you could play as player-1 for a while and then as player-2, etc. Whenever your player wasn't connected and playing, you (and your band of npc's) were expected to be sleeping (so it was a good idea to find a safe haven to make camp). If another player came across your sleeping band, they could wake up your npc's and/or kill/rob/bribe them away from you. [Loyalty values again, a single npc could have many loyalties, again a touch of reality] An npc might also join another band (depends of their script) to stay alive, but if they encounter you the best loyalty may win out. Rooms, puzzles, monsters, objects, players corridors were designed as objects that had properties, and could be added easily while playing the game (if you knew how). The idea here was to have the game evolve and different copies would not be the same after a short while of playing. An export/import facility was being designed to move things to/from various instantiations of the game. My design is over 10 years old, ideas based on TSR's D&D, the original Adventure from Stanford and the original Zork from MIT. It was never implemented, although parts of it were written. It required a lisp-like language so capabilities for objects and players could be kept. Of course it didn't have a Graphical User Interface, since multi-access timesharing systems didn't have those things in ready supply back then. Even today, there are very few applications with a shared GUI (don't flame me, I know there are some :-). I still have a fondness for these ideas in a game, single user or multi-user and have not been too impressed by many of the slasher games coming out of the game industry today, since I can't be the only one that has some of these ideas, I'm still waiting for someone to incorporate these things into new games (or some of the old ones, i don't care which). I might... if I get around to developing games for the Mac. Or if someone is willing to collaborate using my ideas. -carl Carl A Baltrunas - Catalyst Art Cherie Marinelli - Bijoux {sumex, apple}!oliveb!tymix!atlas!udwarf!{carl or cherie} {carl or cherie}%udwarf@tardis.tymnet.com