Subject: Re: plot coding Sender: Greg McIntyre Date: Sat, 21 Sep 2002 03:44:35 +1000 Newsgroup: rec.games.roguelike.development > Say, for instance, that the plot is : > - go to Gaeral star system, find Blackthorn and ask him about the > alien > ship he says he saw last month. Then come back and debrief. > > Well, just imagine Blackthorne is not so evident to find (he moves or > was killed just last week but have documents,etc.) > > How do you code that ? I'm no expert, but I've thought about these things, so here's what I think. This is a very OO approach. 1. This plot is triggered in some manner. (e.g. The player searches the job database and accepts this mission.) 2. At this time the plot is instantiated as an object, which is perhaps associated with a scripting file (or if you're using a scripting language in the first place, is a script itself). This object contains all the information about that plot as it progresses, and knows how to handle the various exceptional cases that may arise. This object is perhaps kept in a collection of active plots. 3. This object registers a set of hooks (or callbacks if you prefer that term) in the game engine, such that it will be notified when certain things happen. The things it wants to know about are: - NPC is talked to - NPC has died - star system is reached (perhaps) (Note: This is not necessarily a good set of callbacks) When these things happen, a method in the plot object is called. If the NPC being talked to is Blackthorn or one of his associates who knows about the alien ship, the plot object will take over the handling of the conversation. Otherwise it will ignore it, assuming it's unrelated to this plot. If an NPC dies, it checks to see if it's Blackthorn, and if so may put his body in the morgue after a time via another callback on a timeout. Basically handle the branching or diverting of the plot should this important character die, or should the plot take other (predictable and significant) twists. Obviously you can't forsee *all* situations, but if you are clear about your winning/losing conditions for each plot, and have a bit of a conclusion in those events, your plot should be fairly coherent. If you're careful and your game is reasonably logical, most variations can be handled without explicit code. e.g. this plot is over when you return to the debriefing room with the knowledge/documents. What happens in the interim is unimportant (car chases, theft, death, whatever). If it turns out that the alien ship presents a new conundrum, this should be a different plot. You may also be able to exploit OO to provide standard methods for handling exceptional cases in plots. For example, the code for placing an important plot-related character in the morgue after death, along with records etc, may be coded in a class which all plots inherit and thereby implicitly (or just conveniently) handle that exceptional case. 4. The plot object's situation may change and it may need to register and unregister hooks. This doesn't have to work as I described above. You may think of a more efficient/convenient arrangement for hooks than calling one every time any NPC is talked to, for example. 5. Once the player returns to the debriefing room (something the plot object is informed about via a hook/callback), it checks the player's inventory for valid documents. It might also possibly check a flag you could set if the player got the information as knowledge (e.g. talking to Blackthorn or his associates), representing that the player has learnt about the alien ship. If successful, the player is rewarded. Known computer algorithms aren't the best for representing this kind of thing. They often don't handle exceptional cases gracefully or transparently. I'm very interested in this topic, as creating random plots is my roguelike's main design goal (most roguelikes have a random setting, not a random non-trivial plot). If you think of interesting and convenient ways to handle plots, please tell me. I believe collaboration of different ideas and perspectives would be very advantageous for this problem in particular. -- Greg McIntyre greg@puyo.cjb.net http://puyo.cjb.net