Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!grue From: grue@batserver.cs.uq.oz.au (Frobozz) Newsgroups: comp.sys.mac.games Subject: Re: RPG opinions (was Re: Programmer...) Message-ID: <5668@uqcspe.cs.uq.oz.au> Date: 13 Nov 90 23:26:11 GMT References: <1990Nov13.013631.1774@magnus.ircc.ohio-state.edu> Sender: sarge@uqcspe.cs.uq.oz.au Reply-To: grue@batserver.cs.uq.oz.au Lines: 99 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 --