Path: utzoo!attcan!uunet!lll-winken!unixhub!shelby!portia.stanford.edu!elaine12.stanford.edu!draphsor From: draphsor@elaine12.stanford.edu (Matt Rollefson) Newsgroups: comp.sys.mac.games Subject: Re: RPG opinions (was Re: Programmer...) Message-ID: Date: 14 Nov 90 18:33:59 GMT References: <1990Nov13.013631.1774@magnus.ircc.ohio-state.edu> <5668@uqcspe.cs.uq.oz.au> Sender: news@portia.Stanford.EDU (USENET News System) Organization: AIR, Stanford University Lines: 69 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