Sign in to follow this  
freddyscoming4you

Delayed/Phased Simulation Idea

Recommended Posts

Howdy,

In the game I'm making I want things to happen across the world constantly and by that I mean bar fights, people moving from house to house, forests and mountains being mined etc. Up until know I've been scratching my head at how I could even remotely make this plausible as I also want to incorporate dynamic geometry, break models into smaller bits, etc. So, the example of the bar fight you might have broken cups, stools, windows, etc. I was thinking that the game could approximate placements and collisions initially (such as stoolA hits stooolB and here their approximate end placement) but once a player gets into visual range or near by then the full simulation to perform computations such as seeing if two items broke, where do the pieces go, etc. The only issue I see with this is secondary and tertiary effects such as what if a bar stool breaks in half as a result of a fight and a half would otherwise collide with a mug which [i]should[/i] shatter the mug as well. I would think I would have to do that part of the simulation in real time and couldn't delay that.

Do you guys think I'm talking crazy or does it sound like it could work theoretically?

Thanks!

Share this post


Link to post
Share on other sites
I have thought about this type of thing before, and I didn't find any satisfactory way of dealing with the propagation of the differences introduced by a simulation with lower level of detail. I think this type of idea can't work if your simulation exhibits the butterfly effect (i.e., if it's at all like the real world). But if you can make it so changes in initial conditions eventually dissipate, it should be possible in principle (although perhaps not easy).

Share this post


Link to post
Share on other sites
My thinking is that if a player isn't in visual range of a bar fight (or whatever) taking place, then there's no way he/she could know whether the result (placement of stools, breakage of cups) is correct or not. Off the top of my head I'd say the best approach would be to have some sort of random 'rules' which approximate the results - 50% chance of a cup being broken, 80% chance of a stool being tipped over - which you can quickly apply when a player comes in range.

I'm interested to hear what other people's ideas are on this.

Share this post


Link to post
Share on other sites
Well, if this ideally gets implemented it'd be for, wait for it ---- an MMO. I would think a cluster devoted to each region similar to how Eve Online divides its world I wouldn't have to guess at the simulations. Though this would have its own set of headaches as several people in an area will require more and more processor power. But, with being able to utilize GPUs now as massively parallel processors this could help mitigate the processing power problem.

Share this post


Link to post
Share on other sites
You could implement bar fights that take place while the player's not around. That would require a lot of work.

Then your players will ask, "Why do only bar fights happen while we're not around but nothing else?"

Then you will set upon the task of making villagers able to grow crops while the player's not around. That would require a lot of work.

Then your players will ask, "Why do only bar fights and crops happen while we're not around?"

If you plan on implementing a general system that can model any sorts of usual human interactions taking place throughout the world, all at the same time, then you're talking about implementing reality and changing your name to God. You're not that good :)

Share this post


Link to post
Share on other sites
Yeah, I think actually doing the simulation is a lot of unnecessary work; if you have a higher level system that manages whether an event happened (bar fight at such a place, such-and-such planted a field of crop X, landslide happened at Z) you can go in and actually make the effects 'visible' at the very last moment (i.e. when an actual player is looking at it).

Share this post


Link to post
Share on other sites
The point being that normal physics/ai is way too fine-grained for what is actually required - a very coarse grained simulation that *just* does enough to keep events ticking along outside a player's awareness

Share this post


Link to post
Share on other sites
[quote name='A Brain in a Vat' timestamp='1313441995' post='4849563']
You could implement bar fights that take place while the player's not around. That would require a lot of work.

Then your players will ask, "Why do only bar fights happen while we're not around but nothing else?"

Then you will set upon the task of making villagers able to grow crops while the player's not around. That would require a lot of work.

Then your players will ask, "Why do only bar fights and crops happen while we're not around?"

If you plan on implementing a general system that can model any sorts of usual human interactions taking place throughout the world, all at the same time, then you're talking about implementing reality and changing your name to God. You're not that good :)
[/quote]

I don't want things to happen only when there isn't any player around. That wouldn't make sense and I don't want to model any sort of interaction. You took my question and stretched it way beyond the intent of what I would like to do. I don't want to model the universe, which is what you're implying what I want. Please don't do that as I can't possibly clarify what I'm trying to discuss with someone like that. If you can't restrain your responses to the context of the post please don't respond as it's purely combative in nature and only serves to detract from the point of the thread (i.e. trolling). Thank you.

As to the scope of what I want to do is to initially create a model that can support a series of initial events and eventually revise to support even more events but far from "any," especially to start out. What I'm trying to do here is met out the concept behind a system that doesn't need to do full physics simulations constantly but can create "summaries," for lack of a better term, that can be saved in the world state and used for further extrapolation by other in game characters, either player or not, and for the full simulation, such as the placement of wood splinters in the bar stool breaking example, to be done later once a player is either in close proximity to the event or can directly view it.

[quote name='johnchapman' timestamp='1313443721' post='4849577']
The point being that normal physics/ai is way too fine-grained for what is actually required - a very coarse grained simulation that *just* does enough to keep events ticking along outside a player's awareness
[/quote]

Right. I just want to create a "good enough" system but on a larger scale. I don't care if each grain of sand on a beach is displaced perfectly when a player walks down the beach. :) I'm perfectly content to take into account the character foot size/shape, weight, state of bipedal motion (running/walking/etc) and instead put an approximate "picture" that fits the criteria of the event in the location of each step, for example, or if, in the game state, it is stored that a deer strolled or ran on the beach just moments before that the player will see the appropriate series of prints on the sand for what happened rather than seeing a pristine beach head which, extending this example, the player could then track and furthermore kill said deer for either food to eat or antlers, hide, etc for trade if they are in particular need for the area.

Share this post


Link to post
Share on other sites
Based on the first couple of replies I would suggest dampening the influences by sectioning your game world so that different parts of it can be allowed to never come in contact, whatever the scope of the influences may be. You could limit each scope to a building or to a room or to a town or a group of NPCs. Additionally, you could consolidate changes every X amount of time so that influences wouldn't stack too much.

Share this post


Link to post
Share on other sites
Hmm I still think you're thinking about a system that's way too fine-grained, especially if it needs to 'scale up' later to add more possibilities. As irreversible says, you could start by partitioning the entire world into chunks. The coarse-grained simulation operates at the chunk level and updates at a relatively low rate, and is basically just a number cruncher; you might have rules for how each chunk can affect it's neighbours over time, for example "forest" chunks might cause neighbouring areas to become more forest-like (increase in vegitation) over time, but they won't affect "farm" chunks as much (if the farm is occupied, the people who live there trim the wild vegitation back). This way, over time, the chunks 'evolve' according to simple(ish) sets of rules that are pretty cheap to compute and update quite slowly. Then, when a player comes into view of a chunk you can take this abstract data and procedurally construct a more detailed view from it - how dense the forrest is, how well the crops are doing on the farm, etc. The fine-grained simulation then operates on the procedurally created chunk. You could run a number of these coarse-grained simulations to produce different sets of related data which the fine-grained simulation uses to create the actual player experience; for example a series of towns with different metrics about population happiness, trading, etc. which 'evolve' (again according to simple rules) and then affect, say, the characteristics of NPCs when it comes to the real simulation (how prone they are to violence, how much cash they have on them, etc).

The difficulty with this is persistence; if you want Joe Petticoat to live at number 7 Crantwerp Lane in Breadtown, and you want him to be there every time you visit Crantwerp Lane but to have 'done stuff' in the intermittent time, then the coarse-grained simulation might have to track Joe individually (and any other such NPCs). That doesn't mean to say that it should make decisions about where Joe is walking or what [i]exactly[/i] he is doing at any given moment (in case the player pops in), but it would need to know how some of his characteristics progress (according to certain probabillities and factors) so that, when the player does come and look at him, what they see make sense.

Going back to your deer example, you might not have to be so specific. You could have a per chunk "% likelihood of deer" and, as the player comes within range and you generate the chunk, throw a few deer in and a couple of hundred metres of randomly generate (ish) deer tracks which make it 'look' as though they've been walking around while the player's not there.

Sorry if that was a bit of a ramble :wink:. The more I think about it, though, the more I'm convinced that the only way to implement what you're describing (and to have it be even vaguely scalable) is by using a very simplified model of the evolution of the game world and the interactions of the stuff in it.

Share this post


Link to post
Share on other sites
I didn't imply you wanted anything to [b]only[/b] happen when the player is not around.

Combative? Stop whining and grow a pair.

You're talking about a system that simulates the occurrence of events without simulating the specifics of the event, leaving the specifics as something that can be simulated in full whenever the player enters that area. If you are limiting your scope to a certain number of possible types of events, then I'm not sure what you're scratching your head about. Your simulation code determines, with some probability, whether a given event occurred. It logs the details of said event, including general details (such as time of occurrence, location, etc), and also specific details (such as which villagers were involved in a bar fight or something).

You then need to write custom code for each type of event that can "replay" the event. This will involve noticing that an event occurred near a player, determining a simulation state by evolving by the amount of time that has passed (i.e. "in 3 days villager X will no longer be pissed off at villager Y"), and then altering or creating actual game objects to match.

Each type of simulation is going to need the following code written specifically for it:
* Possible variables and permutations, with associated probabilities
* Code to evolve the simulation a given amount of time
* Code to put the game state in sync with the given evolved simulation

This is a lot of work for each type of occurrence. And that's not even taking into account interactions between simulations, which makes the problem a combinatorial one.

So if that kind of limited, specific type of simulation is what you want, then how you'd do it as how I described, and RPGs do it all the time. If you want something more -- a general system for simulating world events -- then you're out of luck.

Share this post


Link to post
Share on other sites
[quote name='johnchapman' timestamp='1313499220' post='4849822']
Hmm I still think you're thinking about a system that's way too fine-grained, especially if it needs to 'scale up' later to add more possibilities. As irreversible says, you could start by partitioning the entire world into chunks. The coarse-grained simulation operates at the chunk level and updates at a relatively low rate, and is basically just a number cruncher; you might have rules for how each chunk can affect it's neighbours over time, for example "forest" chunks might cause neighbouring areas to become more forest-like (increase in vegitation) over time, but they won't affect "farm" chunks as much (if the farm is occupied, the people who live there trim the wild vegitation back). This way, over time, the chunks 'evolve' according to simple(ish) sets of rules that are pretty cheap to compute and update quite slowly. Then, when a player comes into view of a chunk you can take this abstract data and procedurally construct a more detailed view from it - how dense the forrest is, how well the crops are doing on the farm, etc. The fine-grained simulation then operates on the procedurally created chunk. You could run a number of these coarse-grained simulations to produce different sets of related data which the fine-grained simulation uses to create the actual player experience; for example a series of towns with different metrics about population happiness, trading, etc. which 'evolve' (again according to simple rules) and then affect, say, the characteristics of NPCs when it comes to the real simulation (how prone they are to violence, how much cash they have on them, etc).

The difficulty with this is persistence; if you want Joe Petticoat to live at number 7 Crantwerp Lane in Breadtown, and you want him to be there every time you visit Crantwerp Lane but to have 'done stuff' in the intermittent time, then the coarse-grained simulation might have to track Joe individually (and any other such NPCs). That doesn't mean to say that it should make decisions about where Joe is walking or what [i]exactly[/i] he is doing at any given moment (in case the player pops in), but it would need to know how some of his characteristics progress (according to certain probabillities and factors) so that, when the player does come and look at him, what they see make sense.

Going back to your deer example, you might not have to be so specific. You could have a per chunk "% likelihood of deer" and, as the player comes within range and you generate the chunk, throw a few deer in and a couple of hundred metres of randomly generate (ish) deer tracks which make it 'look' as though they've been walking around while the player's not there.

Sorry if that was a bit of a ramble :wink:. The more I think about it, though, the more I'm convinced that the only way to implement what you're describing (and to have it be even vaguely scalable) is by using a very simplified model of the evolution of the game world and the interactions of the stuff in it.
[/quote]
Thanks and I enjoyed the ramble, haha. You've given me a lot to think about. I had already accepted the fact I would have to be comfortable with making a lot of assumptions and dealing with several preset values as a basis for the overall simulation (for example, steel always has a hardness of 9 compared to woods constant of 3). I like your suggestion about not necessarily tracking everything and doing things from a high level such as having a forest grow slowly into other parts of the game world. The only part that I would have to compromise based on your post is NPC actions. I want them at least be able to move around freely and at least appear to have a life. What do you think about taking the forest idea and applying it to NPCs as well? By that I mean setting up characteristics associated with NPCs like type (merchant, soldier, peasant, beggar, etc) along with several attributes (adventurousness, attractiveness, gregariousness, combativeness, etc) and using that to approximate their actions when no one is around (likely hood they started on a trip somewhere, likelihood they made a trade with someone, likelihood they got in a fight with someone, etc etc), save the results of those things and use those results as the basis of future sim approximations.

That would be very data intensive but it would take the best of both worlds and seem to make things move. I would treat NPCs specially and wildlife differently. Though, I'd have to update world values so things seem to flow. Like if someone goes on a killing spree in a forest and someone else comes in I don't want everything to repop based on those likelihood values you mentioned. I'd want to at least temporarily lower those values greatly and let them tick back up over time as the forest slowly repopulates.

Share this post


Link to post
Share on other sites
[quote name='A Brain in a Vat' timestamp='1313441995' post='4849563']
You could implement bar fights that take place while the player's not around. That would require a lot of work.

Then your players will ask, "Why do [b]only [/b]bar fights happen while we're not around but nothing else?"

Then you will set upon the task of making villagers able to grow crops while the player's not around. That would require a lot of work.

Then your players will ask, "Why do [b]only [/b]bar fights and crops happen while we're not around?"

If you plan on implementing a general system that can model any sorts of usual human interactions taking place throughout the world, all at the same time, then you're talking about implementing reality and changing your name to God. You're not that good :)
[/quote]

See emphasis above.

[quote name='A Brain in a Vat' timestamp='1313505321' post='4849869']
I didn't imply you wanted anything to [b]only[/b] happen when the player is not around.
[/quote]

Hmm.

[quote name='A Brain in a Vat' timestamp='1313505321' post='4849869']
Combative? Stop whining and grow a pair.
[/quote]

You were trolling. If that's how you're going to be then kindly go away. This isn't a trolling forum. Use the Lounge for that.

[quote name='A Brain in a Vat' timestamp='1313505321' post='4849869']
You're talking about a system that simulates the occurrence of events without simulating the specifics of the event, leaving the specifics as something that can be simulated in full whenever the player enters that area. If you are limiting your scope to a certain number of possible types of events, then I'm not sure what you're scratching your head about. Your simulation code determines, with some probability, whether a given event occurred. It logs the details of said event, including general details (such as time of occurrence, location, etc), and also specific details (such as which villagers were involved in a bar fight or something).

You then need to write custom code for each type of event that can "replay" the event. This will involve noticing that an event occurred near a player, determining a simulation state by evolving by the amount of time that has passed (i.e. "in 3 days villager X will no longer be pissed off at villager Y"), and then altering or creating actual game objects to match.

Each type of simulation is going to need the following code written specifically for it:
* Possible variables and permutations, with associated probabilities
* Code to evolve the simulation a given amount of time
* Code to put the game state in sync with the given evolved simulation

This is a lot of work for each type of occurrence. And that's not even taking into account interactions between simulations, which makes the problem a combinatorial one.

So if that kind of limited, specific type of simulation is what you want, then how you'd do it as how I described, and RPGs do it all the time. If you want something more -- a general system for simulating world events -- then you're out of luck.
[/quote]

That seems to be generally about what I'm going to have to do. As far as simulations interacting with each other I'm thinking of breaking the world into smaller chunks (as in perhaps as small as a single house, for example) and when an NPC or character pass from one chunk to another then it simply stops being a factor, so to speak, in its previous chunk and it's now a new factor in the new chunk and simply processing each chunk of game space in an abbreviated form and updating that chunks state with the results of the sim and letting the game seemingly evolve like that.

This would make a chase scenario somewhat interesting. If an NPC is being perused and goes from one chunk to another then any persuers would then need to wait until they leave their current chunk and enter a new one before it could be determined if they keep pursuing or stop or engage or else as soon as an NPC leaves a chunk of "sim space" then any pursuers in the same would suddenly stop which wouldn't make sense. Hmm.

Share this post


Link to post
Share on other sites
[quote name='freddyscoming4you' timestamp='1313515640' post='4849930']
[quote name='A Brain in a Vat' timestamp='1313441995' post='4849563']
You could implement bar fights that take place while the player's not around. That would require a lot of work.

Then your players will ask, "Why do [b]only [/b]bar fights happen while we're not around but nothing else?"

Then you will set upon the task of making villagers able to grow crops while the player's not around. That would require a lot of work.

Then your players will ask, "Why do [b]only [/b]bar fights and crops happen while we're not around?"

If you plan on implementing a general system that can model any sorts of usual human interactions taking place throughout the world, all at the same time, then you're talking about implementing reality and changing your name to God. You're not that good :)
[/quote]

See emphasis above.

[quote name='A Brain in a Vat' timestamp='1313505321' post='4849869']
I didn't imply you wanted anything to [b]only[/b] happen when the player is not around.
[/quote]

Hmm.

[/quote]


So... what you're saying is, you don't understand the difference between:
Only X happens when Y
and
X happens only when Y
?

I suggest you think about it for a while. Maybe it'll dawn on you.

Share this post


Link to post
Share on other sites
Hmm. So you want to be able to run a simulation at various levels of detail? Here's an idea...

Suppose that you can think of your entire simulation as a big Markov Chain (or perhaps a controlled Markov Chain, AKA Markov Decision Process). One way to look at this "coarsely" is to aggregate states. E.g., say you have a Markov Chain with states x1, x2, x3, x4. Now you partition the states into y1={x1,x2}, y2={x3,x4}, and pick a probability distribution that says, "given that I'm in y1, how likely is it that I'm in x1? Or x2?" and another one for y2. These should probably come from the stationary distribution of the original chain, but that might not be necessary. In any event, together with the transition probabilities of the original Markov chain, this induces transition probabilities for the new chain. Now you have a "lower resolution" simulation that uses randomness to represent all the details you've forgotten about. Moreover, you can imagine taking the resulting, coarse Markov chain, and in turn approximating it with a yet coarser one, and so on, for as many "levels of detail" as you need. This might give a theoretically clean way to think about the problem. You see constructions a bit like this in the Approximate Dynamic Programming literature...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this