2011-06-07T20:37:48 I need some help, I think 2011-06-07T20:38:05 I'm trying to imagine how to hook up things together 2011-06-07T20:38:19 that is for quest editing 2011-06-07T20:38:40 and I don't have slightest clue how things are made 2011-06-07T20:38:54 this question is pretty abstract, but 2011-06-07T20:39:54 is there any chance, for example, for joining a piece of information, like a dialogue, to a thing like a ground tile on map? 2011-06-07T20:40:16 does the tile have any unique ID? 2011-06-07T20:40:21 any tile? 2011-06-07T20:40:32 Hmm, if I'm understanding you correctly you're talking about datastructures. 2011-06-07T20:40:41 or, will it be possible to make such one? 2011-06-07T20:40:53 well, I think yes 2011-06-07T20:41:11 do we have any event system? 2011-06-07T20:41:28 locations on the map (e.g. a tile in a "quest" layer) are uniquely identified via the map and x,y,z coordinates. 2011-06-07T20:41:42 Not taht I am aware of Q_x 2011-06-07T20:41:58 like when fighting and PC hits NPC - how this can be made? 2011-06-07T20:42:31 AFAICT there is (plenty?) of code infrastructure missing to make that work at this point? 2011-06-07T20:43:22 Here's what I'm thinking: each map will have a "scripting" layer, which is just a layer of tiles to which are attached conditions and events that occur when those conditions are met. 2011-06-07T20:43:39 well, I think it's only event "pipeline", like some simple message-passing 2011-06-07T20:43:57 Yes, I think it partly depends upon implementing zenbitz's action ruleset 2011-06-07T20:44:05 may be hooked up to a given layer 2011-06-07T20:44:54 Hmm, the question is: how often are conditions checked, and under what circumstances? 2011-06-07T20:45:38 E.g. there might be a "trigger" condition that is met when the PC walks over a certain tile. 2011-06-07T20:45:40 I'm affraid that when we would hook an time-based condition to a map, it might not occur when a player will be off that map 2011-06-07T20:46:20 Well, that might actually be a "feature". 2011-06-07T20:46:29 I'm thinking of a quest rather looking like a tree of conditions and following state changes 2011-06-07T20:46:31 But yes, time-based events should probably be rare. 2011-06-07T20:47:09 so that you have to look in a list of like 100 condition every time player does anything 2011-06-07T20:47:17 conditions* 2011-06-07T20:47:21 e.g. a state machine? 2011-06-07T20:47:41 I doubt if this is a state machine 2011-06-07T20:48:12 A global list of conditions that are checked "each round" is probably too computation-heavy 2011-06-07T20:48:34 oh, but those are for quests only 2011-06-07T20:48:52 I can see local map conditions working that way though, provided the conditions aren't too complex. 2011-06-07T20:48:59 how do you mean? 2011-06-07T20:49:49 one type of events are "ordinary" - so like fighting or reaching new location that needs to be handled in an ordinary way 2011-06-07T20:49:57 quest-unrelated 2011-06-07T20:50:31 and I;m wondering about those important for quests 2011-06-07T20:50:51 I dunno if there is any difference in those two... 2011-06-07T20:51:19 Ideally those events/conditions wouldn't be any different from quest events/conditions. I.e. they would all exist in the same layer and be part of the same scripting system. 2011-06-07T20:51:43 That way everything is easily extended 2011-06-07T20:51:59 anyway - there is this "quest" stuff somewhere - connected chain of state changes and conditions 2011-06-07T20:52:45 Let's stop talking in the abstract and make up a concrete case. It might help us develop the abstract case. 2011-06-07T20:53:32 OK, quest "pull lever to activate trap door one level below" 2011-06-07T20:54:11 Ok, but how does the player get that quest? 2011-06-07T20:54:24 triggered by dialogue 2011-06-07T20:54:46 I see it that way - pc changes state of the lever, message like "lever XYZ was pulled" is passed to our blackbox 2011-06-07T20:54:56 no matter who pulls it 2011-06-07T20:55:01 That's probably the most straight-forward way I agree, but it might also be given to the player upon reaching some condition 2011-06-07T20:55:23 anyway I digress, continue. 2011-06-07T20:55:32 can we exclude time-based stuff? 2011-06-07T20:55:41 like reaching a given age? 2011-06-07T20:56:23 Well, ideally I think time/age is just another variable we can include in the conditions. 2011-06-07T20:56:29 *** DomtronVox has joined #parpg 2011-06-07T20:56:29 now, there may be two options 2011-06-07T20:56:32 hi 2011-06-07T20:56:39 But it probably is too complex to include time in most quests 2011-06-07T20:56:43 Hi DomtronVox 2011-06-07T20:57:38 first is that blackbox changes environment in the way that when PC reaches the level below, trap doors will be already activated 2011-06-07T20:57:49 Ok, lets flesh out this scenario: the pc is in a prison and talks with a prisoner. The prison wants the pc to let him out, so tells him to pull a leaver. 2011-06-07T20:58:06 second is the blackbox leaves a message for itself to do it when player will get to that level 2011-06-07T20:58:08 Hi Technomage, Q_x 2011-06-07T20:58:39 how are you 2011-06-07T20:58:58 Hi barra_home 2011-06-07T20:59:09 Hmm, why not just immediately change the state of the trap door when the lever is pulled? 2011-06-07T20:59:20 fine, thanks 2011-06-07T20:59:20 hi DomtronVox 2011-06-07T20:59:33 cause it's in a different map Technomage 2011-06-07T20:59:48 Oh I see. So the issue is how do we connect the two events. 2011-06-07T20:59:56 yes 2011-06-07T21:00:41 I don't have a clue how effective will be message-passing in this case, I'm just guessing it should work 2011-06-07T21:01:39 or "could" 2011-06-07T21:01:41 So it's kind of like a mailbox? E.g. "the lever on map xy sends a message to map zi that it has been activated", then on load of map zi the message box is read? 2011-06-07T21:02:15 it depends - it may alter like save file directly 2011-06-07T21:02:26 so that the changes are on the map 2011-06-07T21:02:34 "just like so" 2011-06-07T21:02:34 Hmm, serialization is another issue. 2011-06-07T21:03:36 Ok, it is probably impratical to have more than one map in memory at a time so we can take as granted that only the currently active map is in memory. 2011-06-07T21:04:07 well, we can assume that we want to care about one map only 2011-06-07T21:04:28 So the question is, how do we change the state of a map that isn't loaded? 2011-06-07T21:04:36 arcanum uses "endless" wilderness maps 2011-06-07T21:05:37 well, this is good question. My bet would be to alter "temporary save" directly, so that when a map is loaded, it gets loaded with the changes in place 2011-06-07T21:05:56 We could have a global "EventEngine" that trakes the scripting layers of all maps. 2011-06-07T21:06:13 *tracks 2011-06-07T21:06:39 What is a "temporary save"? 2011-06-07T21:07:02 well, it will be needed something like this... 2011-06-07T21:07:08 I'm kinda scared 2011-06-07T21:07:21 you can't alter map files directly 2011-06-07T21:07:31 you can't alter save files directly 2011-06-07T21:08:02 so this is my mockup band-aid to do "altering save" 2011-06-07T21:08:23 Ok, so we are pretty much required to have a global state system in memory at all times. 2011-06-07T21:08:50 stuff that will happen on demand in the way similar to when loading things from save 2011-06-07T21:09:21 no, I think just a queue of arguments will suffice 2011-06-07T21:09:37 and this blackbox to process them 2011-06-07T21:09:38 How about this: map scripting layers are all stored in a global "ScriptingSystem" instance that persists throughout the game. 2011-06-07T21:10:14 What do you mean "queue of arguments"? 2011-06-07T21:11:00 "change trap doors XYZ on map XYZ", "open doors XYZ in map XYZ" 2011-06-07T21:11:02 Do you mean a bunch of state changes that are applied upon map loading? 2011-06-07T21:11:07 aye 2011-06-07T21:11:08 Ok. 2011-06-07T21:11:31 First: where do we store these state changes? 2011-06-07T21:11:54 Second: how do we deal with dependencies between maps/events? 2011-06-07T21:12:24 E.g. how do we deal with the fact that the trap door on map a depends upon the level on map b? 2011-06-07T21:13:07 FIFO queue will be good to save it, binded tightly to PC, like an inventory 2011-06-07T21:13:57 dependencies may be much worse, like when you alter a state of the object that is destroyed with time 2011-06-07T21:15:23 I still can't see how this "quest layer" could work, but I guess it's only a way to make the data stick to somewhere? 2011-06-07T21:16:02 (but I have an idea how and editor may look!) 2011-06-07T21:16:11 and > an 2011-06-07T21:16:27 So I'm the PC and I pull the lever. The lever fires an EventMessage whose address is the name of the map in question. A global EventPostOffice stores the message in the map's EventMailbox. Each round the active map looks to see if it's EventMailbox has any EventMessages, and executes any state changes associated with the EventMessage. 2011-06-07T21:17:22 yes, but with an exception 2011-06-07T21:17:23 Or rather, the EventMessages don't *tell* the map to do a state change, but rather report on state changes made in other maps. 2011-06-07T21:17:40 Let the map decide how to deal with that information. 2011-06-07T21:18:17 on load all the messages should be processed before player will be able to see anything 2011-06-07T21:18:47 Sure, but that's just an extension of the "check messages each round" rule. just execute a round on map load. 2011-06-07T21:18:49 like when using those damn explosives - you can't be wounded on entry 2011-06-07T21:18:58 aye 2011-06-07T21:20:19 what we do... does it make any sense? 2011-06-07T21:20:43 That would allow events to unfold upon map entry, which can be both difficult to manage (e.g. PC dies horribly because he/she enters a map before disarming explosives) and featureful (e.g. PC learns not to explore recklessly :) ) 2011-06-07T21:21:01 I think so, yes. 2011-06-07T21:21:17 we've had all, or nearly all those event types sorted already with Rowan 2011-06-07T21:21:39 so like "change inventory item state" 2011-06-07T21:21:57 It sounds a lot like the Actor Model, which uses messages to communicate with independant entities. 2011-06-07T21:21:59 "change map tile to X" 2011-06-07T21:22:10 I dunno what that is 2011-06-07T21:22:29 will read 2011-06-07T21:22:46 Pretty much what we've described. Maps no nothing about each other except what messages are sent to them by another map. 2011-06-07T21:22:51 *know 2011-06-07T21:23:33 State changes are made by the map being changed, and not by another map. 2011-06-07T21:23:44 That reduces dependencies between maps. 2011-06-07T21:24:00 well, we should immediately rule out any time-based events if we will go that way 2011-06-07T21:24:43 So map a can say "I depend on events from map b and c" but map c can't force map a to depend on it. 2011-06-07T21:24:54 Hmm 2011-06-07T21:25:17 imagine you leave a bomb with a timer. you trigger a timer - may be a fuse of some kind, that should make water flow to a cave below. And you run away to that cave... And nothing happens. 2011-06-07T21:25:59 That could be a case where we introduce another entity to pass messages to: a global Timer. 2011-06-07T21:27:08 *** DomtronVox has quit IRC 2011-06-07T21:28:33 So if map a contains the bomb and map b has the soon-to-be-flooded cave, map a sends a message to itself and to map b that the bomb has been set. Map a and map b then process the Timer's event messages and trigger the explosion when the requisite amount of time has elapsed. 2011-06-07T21:29:16 we will need also cancellations of such triggers 2011-06-07T21:29:17 Granted, this is pretty complex and i don't remember ever playing a game that used this sort of thing. Most of the time the bomb is "magically" triggered upon entering some area or another map. 2011-06-07T21:29:40 *** DomtronVox has joined #parpg 2011-06-07T21:29:53 Use case? 2011-06-07T21:29:53 but there are other events 2011-06-07T21:30:27 case: like when you will "unset" the bomb's fuse with water 2011-06-07T21:31:05 there are other time-based events, like waiting until NPC will fix something 2011-06-07T21:31:16 Send another event message to the interested maps that the bomb has been defused. Condition requires both that the bomb is set and that the requisite amount of time has passed. 2011-06-07T21:31:59 but for "bomb is set" you will need a state of things to be stored somewhere 2011-06-07T21:32:07 not only on map 2011-06-07T21:32:40 Hmm, well this is related to map state serialization. 2011-06-07T21:33:17 I think that the scripting layers of all maps will need to be serialized with the rest of the game data upon save. 2011-06-07T21:33:21 I would rather send a message directly to the blackbox and let him find and delete detonation 2011-06-07T21:33:48 So you're thinking of a global director of events then? 2011-06-07T21:33:53 *** prock has quit IRC 2011-06-07T21:35:31 for some of the events this would do a better job 2011-06-07T21:35:41 Problem with a global director is that it couples all of the maps together. I would much rather have the maps responsible for changing their own state to simplfy dependencies. 2011-06-07T21:36:23 ok, map can delete events as well - first look for cancellations, later process events 2011-06-07T21:37:20 how map changes are stored on save? 2011-06-07T21:37:22 I can see that time will be an issue with this model though. E.g. what happens when a ton of events are queued up and the player enters the map in question? Does the whole thing expload with events? 2011-06-07T21:37:41 yes, but it is unseen 2011-06-07T21:38:10 out of sight 2011-06-07T21:38:25 Not sure if it is always going to be possible to hide them all. 2011-06-07T21:40:21 first - cave explodes, second - this triggers flooding a cave (load alternative map), finally - make trap door active. Process all following/resulting events (so that PC is not hit by explosion), show map in the end 2011-06-07T21:42:05 but even if the events would be visible it will not be that bad, you know... I think I've seen this bug in some first-grade stuff 2011-06-07T21:42:17 So now we've got priorities attached to the event messages. How do we manage the priorities so that things don't expload? 2011-06-07T21:42:40 no, this are not priorities 2011-06-07T21:42:55 this is time-based (FIFO) event queue 2011-06-07T21:42:56 off to a bath 2011-06-07T21:43:23 just explosion triggers flooding a cave 2011-06-07T21:43:25 But how do we predict what events occur in what order? 2011-06-07T21:43:54 those are things that have happened and are stored and just triggered on map load 2011-06-07T21:43:58 Or do we just have to script events that can occur independantly of one another. 2011-06-07T21:44:46 rather be triggered one by another 2011-06-07T21:45:08 Ok, but this means that we will have to place some limitations on what an event does. We can't have events that interfere with each other. 2011-06-07T21:45:38 I think I need an example 2011-06-07T21:46:06 what are possible interferrences? closing and opening trap doors at once? 2011-06-07T21:46:51 closing trap doors that are no longer on a given map? 2011-06-07T21:47:41 I guess since the map takes care of changing its own state that it can manage events that don't make sense any more. But there is the potential for breaking quests, so it'll require extensive player testing. 2011-06-07T21:48:19 Not that there is any solution to that issue, but just thought I'd put it out there. 2011-06-07T21:51:06 well, unsolvable quests are a PITA, but having "guardian angel" that will fix the world every time you want to break it is not good for a game like this. But yes, some care will be needed no matter what.