Physics and Environmental Effects

In what I've seen of games like Fallout, Torchlight, and Ultima, the nature of the environment doesn't lend itself to physics or a changeable world. Characters can't jump, I've never been able to smash through walls, and no matter how many fireballs I cast, the city doesn't burn down! That would be a really, really sweet thing to be able to do. Maybe not in turn-based play, but I think VQ has some real-time potential in these areas.

One of the most challenging to implement, I believe, would be gravity. I'd argue that it's essential for an actiony first-person experience, and the math is relatively easy. But does it create a performance issue? Should characters in an isometric view be able to jump?

Destructive fire would be a cool thing to add, as well as the ability to kick down weakened, worn doors. Tree-felling also comes to mind. Maybe rain could make steep slopes more "slidy", and random asteroid collisions could create craters. :) Characters could mine, create tunnels, build monuments to themselves, etc.

With the open-world destructive/constructive potential of VQ, what mechanics would you like to see for physical/chemical/physics-based interactions? Do they add enough to the world to make them worthwhile, or is this something you'd rather see in a novelty mod?

Comments

  • This makes me think of the original wasteland. You could literally destroy walls. Normally you would use explosives, but I had a character with all their points in strength that could punch through walls. It really did open up a variety of approaches to situations.

  • One of the most challenging to implement, I believe, would be gravity. I'd argue that it's essential for an actiony first-person experience, and the math is relatively easy. But does it create a performance issue? Should characters in an isometric view be able to jump?

    From a programmer's perspective: Yeah, adding a system like gravity would add to the calculations, and therefore a quantifiable effect to the CPU load - but if implemented properly, it would only have this kind of effect while things are actually falling. If optimized even better, it would only have a real effect when the object begins falling, and the reason for this is (to put it bluntly): Collision detection is hell. Calculating where the object will collide with the terrain once is far smarter than checking every frame. As long as the object can't roll, you're good at that point, and gravity should have pretty much a minimum effect on frame rate.

    Destructive fire would be a cool thing to add, as well as the ability to kick down weakened, worn doors. Tree-felling also comes to mind. Maybe rain could make steep slopes more "slidy", and random asteroid collisions could create craters. :) Characters could mine, create tunnels, build monuments to themselves, etc.

    All doable. Destructive fire is a bit more difficult, but very well-suited to a voxel engine - far more so than your traditional polygon system.

    With the open-world destructive/constructive potential of VQ, what mechanics would you like to see for physical/chemical/physics-based interactions? Do they add enough to the world to make them worthwhile, or is this something you'd rather see in a novelty mod?

    Some yes, some no. I can see destruction of terrain and buildings as being very useful in gameplay. Fire is a different matter - you'll never really be able to use it meaningfully, and that sort of simulation is a massive CPU hog.

  • Definitely something I'd love with a voxel engine.
    I wonder what impact on the performances such physic would have. Speaking of voxels and physics you have two excellent examples with :
    - Seed of Andromeda :
    - Voxel Farm (of course) :
  • @Talvieno, that's a good point with the fire. It makes more sense to include explosions with fire effects, because modelling the natural spread of fire would be rather difficult.

    @Clement, thanks for those! I'm especially interested in SoA-style explosions, and those fluid dynamics are pretty cool as well.
  • Far Cry 2 had a fairly robust fire spreading algorithm, which its creator has outlined.
  • @Flatfingers‌: not too complicated (when compared to what it could be) but gets the job done. Thanks for the link!
  • There will be jumping, climbing, etc, but most physics are going to be very simplified at this point (i.e. you will jump 3 units to the left or climb up 2 units). As with multiplayer, most physics features are at the back of the queue - and while I enjoy a good physics sandbox (like Gary's Mod), there are just too many tasks that take priority right now in terms of getting a "fun" playable game. Fire,snow,lava,terrain, and fluid dynamics are all calculated in the same volume, at the macro level, which is convenient from a simulation standpoint and AI standpoint (allows AI to easily pathfind around fires, flooded areas, etc.
  • edited November 2014
    "Environmental effects" is something in which I'm especially interested, because I define that term to mean "modifications to how character abilities work that are cause by environmental phenomena."

    A simple example is the effect of rain/snow/smoke on line of sight for ranged weapons. Normally (in clear weather) Weapon X can shoot something out to Distance Y. And Distance Y might also be modified by the character's ability level in the Shoot Ranged Weapon skill. But what's really interesting is when a temporary dynamic phenomenon, such as weather or smoke from a fire, can also have a modifying effect on Distance Y.

    That's just one example meant to illustrate the larger point: a game world is more interesting when its contents are more capable of producing dynamic effects on character abilities, which in turn opens up more interesting choices for characters to make. That is a world that will feel more alive than one in which anything you can see is just cosmetic, and all abilities have the same single effect in all cases.

    And don't forget that this covers more than just immediate phenomena. Suppose that the average temperature and the amount of rainfall that a part of the world gets can vary over a fairly long period of time -- what effects could that have? Could forests become grasslands or deserts? Could glaciers form and move? What would happen to the people and places of the game world as these long-term dynamic environmental effects accumulate?

    So, excluding physics (mostly meaning gravity), what active effects could/should things like fire, snow, lava, terrain, and fluid dynamics have on character abilities and maybe long-term character behaviors in Voxel Quest?
  • edited November 2014
    I very much like this insight on how we define environmental effects. Giving a gameplay purpose to things like rain is brilliant.

    I mentioned something like this in another thread - erosion. Basically, erosion would occur around areas with soft, oversaturated soil and little to no vegetation. With a combination of different systems, something like this could happen:

    1. A lumberjack searching for wood finds a nice patch bordering a small river gorge, and chops the trees down.
    2. A traveler finds the nice clearing the lumberjack has cleared, and sets camp there. He leaves, but the embers spread and cause the surrounding vegetation to catch fire, burning it to the ground. Anyone within visible range of the fire can have knowledge of it, and be able to tell someone later trying to hunt down this chain of events.
    3. A traveler walking along the road encounters three enemy elven archers, but is able to take them down because it's raining and he can get to them before they notice him. He thinks nothing of the little clearing, other than the large expanse of open space prohibiting the stealthy continuation of his journey.
    4. The bare soil directly by the steep riverbank, oversaturated with rain, collapses into the gorge, damming the river. The water level on the downriver side lowers dramatically - any NPC that sees the river can later tell the player that the river dried up, and any NPC that sees the upriver side can tell the player that a new lake formed.
    5. The crops downriver suffer for want of the river's water, prompting a severe shortage of food. Farmers would be able to tell the player of this.


  • I anticipate that it would be difficult to balance the frequency of such events against the consistency of the world. If they occur too frequently, the player will grow tired of finding their favorite villages crushed by glaciers, washed away, flooded by rivers, riven by earthquake fissures... as interesting as each event surely is on its own.

    On the other hand, if such events have a realistic rate of occurrence, then the player (whom will only be aware of a fairly small portion of the world unless they subscribe to some kind of news service such as teams of town criers) will hardly ever see the events... which seems like a waste of developer time.

    Fortunately, fantasy gives us a third option. In fables and fantasy stories, natural disasters always have a supernatural cause. It makes for better storytelling; most people agree that bad things happening to good people without the influence of bad people is one of the major downsides of reality. If powerful, evil (or misanthropic) mages, monsters, and gods exist, then every tornado, landslide, volcano, glacier, or plague is due to them. Or, at least most of them.

    PCs can thus interact with disasters on equal terms and with a variety of responses. If a glacier is bearing down on a village, then he can go kill the ice giant who's riding it. If a forest burns down, then he can find the fire spirit that sparked it. If the PC finds a tome of eldrich lore vis-a-vis life-and-or-death, he can trigger an undead plauge upon the land.

    Taking this narrative perspective allows some leeway in where disasters occur; most audiences accept that villains are more active when heroes are near, and the occasional distant plague can still occur for the PC to hear about and travel to rescue.
  • edited November 2014
    PTTG said:

    I anticipate that it would be difficult to balance the frequency of such events against the consistency of the world. If they occur too frequently, the player will grow tired of finding their favorite villages crushed by glaciers, washed away, flooded by rivers, riven by earthquake fissures... as interesting as each event surely is on its own.

    I'm right there with you on that... but please note that I'm not thinking of environmental effects only as "things the environment does on its own." As Talvieno implied in his fire scenario, it's not unreasonable that characters can actively generate environmental effects, which in turn can be used to help or hinder various character abilities.

    Smoke is a good example. In a modern-day game, warfighters might pop a smoke grenade to obscure their movements. The smoke is an environmental effect -- it's particle FX, occurring in the world, that modifies a character ability. And that's true even if that effect was caused by the action of a character.

    This applies equally to fantasy games. You might set a fire to distract an enemy, or if you have a pool of oil handy (as is so often the case ;)), you could generate a fire spreading effect that does direct damage to an enemy. Other examples might be casting a Freeze spell on part of a river so that you can cross it, or masking your scent from animals hunting you by finding and breaking a spore-bearing mushroom, or -- somewhat longer-term -- causing all the vegetation around your Evil Wizard's Tower to die by generating a permanent cloud over it.

    Again, the larger point is that when you build the environment of the world of a game so that it has a lot of ways to interact with character abilities, you add significant gameplay value to every one of those abilities. Some (many?) game developers implement character abilities only as "powers" that are imposed against other characters. That's valid gameplay, but to my mind it's terribly limited gameplay when you've got a really interesting gameworld to play in... and with.
  • edited November 2014
    You guys have excellent points! I fully agree with both of you. I think there's room for a very rich variety of interactions between the triangle of players/entities, environment, and gameworld:

    (as examples)
    entities on entities: combat, trade, conversation
    entities on environment: Smoke grenades, poison gas, oil spills
    entities on gameworld: Digging, freezing water, chopping trees
    environment on entities: rain, snow, fog, fire
    environment on environment: rain on lava for steam, fire creating embers, floating embers igniting an oil spill, poison gas killing a swarm of bees
    environment on gameworld: rain loosening terrain, floating embers setting a tree alight, acid rain killing forestry, rain freezing into ice
    world on entities: drowning, crushing people under cave-ins, lack of water causing drought
    world on environment: avalanches, sand storms, bees, floating embers from fires, water freezing in the winter
    world on world: landscape eroding and causing landslides, rivers cutting through terrain, buildings collapsing when badly damaged

  • Those things. Make those things happen.

    For a start. :)
  • edited November 2014
    I felt like making an image to illustrate it. The trinity of entity, gameworld and environment really makes sense to me.

    I couldn't come up with descriptors for two of the environment sets, though.
    image
  • edited November 2014
    I've been thinking about this (and the graphic is helpful!), and I'm still having trouble thinking of "game world" and "environment" as separate things.

    I'm thinking in terms of Actor and World, where an Actor is any mobile object with at least some amount of AI that can independently impose some direct effect on the world, and the World is any non-AI-bearing terrain, inanimate object, or dynamic effect that's simulated by the game.

    Do the graph and the outline of suggested interactions feel any clearer conceptually if treated that way? I also like trinities of things when appropriate, but in this case I'm not sure what distinctive value is added by breaking World into two components. I'm open to that if you can help me see the value in it, though.
  • @Flatfingers
    Usually when I think about simulation, I tend to group things as you mentioned into actors and worlds. The first computer science class that I took used these same terms in an insect simulation (I don't know if "actor" and "world" are universal, but I'm rather partial to them since they're what I first heard :) ).

    I do believe that there's some value in separating "game world" from "environment." To me, environmental effects are local effects that change the way that an immediate scenario plays out -- smoke obscuring visibility, slippery ice reducing a character's ability to evade, etc. They make up the fundamental physics of how the universe of the game operates and define how what immediately affects a character's abilities.

    On the other hand, the term "game world" relates to the feel of the world, its themes and objectives. If the environment is the engine, then the game world is the plot and overall direction of the game built from the engine. The game world can be manipulated broadly for to influence the plot, such as a fire ravaging a city or a flood destroying much-needed crops. It seems more event-based and geared towards a game's concept or purpose. The difference between a game focused on empire-building and a game focused on defending your outpost from zombie attacks is a game world difference, not an environmental difference.

    Game world and environment are of course linked and changing one affects the other, but I think they should be separated because they have different scopes. What do you think?
  • edited November 2014

    I've been thinking about this (and the graphic is helpful!), and I'm still having trouble thinking of "game world" and "environment" as separate things.

    I'm thinking in terms of Actor and World, where an Actor is any mobile object with at least some amount of AI that can independently impose some direct effect on the world, and the World is any non-AI-bearing terrain, inanimate object, or dynamic effect that's simulated by the game.

    Do the graph and the outline of suggested interactions feel any clearer conceptually if treated that way? I also like trinities of things when appropriate, but in this case I'm not sure what distinctive value is added by breaking World into two components. I'm open to that if you can help me see the value in it, though.

    "Actor" is a far better word, yes.

    I was personally thinking of:

    Actor/Entity: Mobile creatures with AI. Humans, monsters, animals.
    World: Terrain. Trees, rocks, houses, lakes. The world the game takes place in.
    Environment: anything like fire, smoke, fog, bee swarms, poison gas, rain, temperature, etc.


    I should've been clearer, yes.

    "Environment" refers to localized effects that are hard (if not impossible) for the player to physically interact with.
    "World" refers to elements that are present across the entire world, and far easier for the player to physically interact with.

    Or, simplest:

    Environment: localized effects
    World: Voxels
    Actors: creatures/NPCs
  • I find it interesting that both @PreacherJayne and @Talvieno developed different interpretations of how "game world" and "environment" are different. :)

    In both formulations, what's important for game design (from my perspective) is the middle part: how an Actor applies abilities (verbs) to those content forms (nouns). The question is whether there's some conceptual value for thinking of the nouns as two different kinds of things, or if it helps yield a better game to think in terms of nouns generally as things an Actor acts on regardless of their lower-level form.

    Let me take these out of order:
    Talvieno said:

    I was personally thinking of:

    Actor/Entity: Mobile creatures with AI. Humans, monsters, animals.
    World: Terrain. Trees, rocks, houses, lakes. The world the game takes place in.
    Environment: anything like fire, smoke, fog, bee swarms, poison gas, rain, temperature, etc.


    I should've been clearer, yes.

    "Environment" refers to localized effects that are hard (if not impossible) for the player to physically interact with.
    "World" refers to elements that are present across the entire world, and far easier for the player to physically interact with.

    Would I be close enough if I simplified this to World and Environment being "static content" and "dynamic content" respectively?

    If so, is there a meaningful difference for game design in how Actors apply verbs to static content versus dynamic content?

    To me, environmental effects are local effects that change the way that an immediate scenario plays out -- smoke obscuring visibility, slippery ice reducing a character's ability to evade, etc. They make up the fundamental physics of how the universe of the game operates and define how what immediately affects a character's abilities.

    On the other hand, the term "game world" relates to the feel of the world, its themes and objectives. If the environment is the engine, then the game world is the plot and overall direction of the game built from the engine.
    ...
    Game world and environment are of course linked and changing one affects the other, but I think they should be separated because they have different scopes. What do you think?

    This is different from Talvieno's formulation in that you're not thinking just of Game World and Environment as different kinds of things, but as different levels of things.

    In fact, what this latter definition of Game World and Environment most reminds me of is the Mechanics/Dynamics/Aesthetics (MDA) model.

    In this mapping, Environment = Dynamics (the physics of the world) and World = Aesthetics (themes and objectives). (Actors, meanwhile, operate at the level of Mechanics.)

    If that seems like it's got about the right resonances to you, then I'd say go with it. The MDA model (or KMDA as I extended it in a moment of hubris) is respected in the game design community because it's a demonstrably useful way of breaking down the levels at which a game can be experienced into the most important forms. They all interact, but it can be helpful to see them as distinct kinds of gameplay modes so that you can punch up the value of design features applied to each of those modes.

    In this case, thinking of Environment as dynamic effects lets you focus on selecting good system-interactions so that the world feels both alive and logically consistent, but without having to worry (yet) about questions like "is it satisfying for me to do that for five hours straight?" or "what did I learn from it as a person?" which are Mechanics and Aesthetics questions. Similarly, focusing on Game World for its aesthetics of theme and meaning lets you operate at the highest level of design, where you're making sure all the kinetics and mechanics and dynamics are integrated to elicit a feeling of emotional coherence when you play the game: it just feels right.

    I could live with that. :)

    Otherwise, I think I might go with Actors (for mechanics/verbs) and World (for the dynamic noun-objects of those verbs), with the level of how the whole thing feels treated as an aesthetic level encapsulating Actors and World.

    Note: I know perfectly well that all of the above stuff sounds pointlessly abstract to some readers, who think a designer should get on with it without all the theoretical mumbo-jumbo and just crank out gameplay. That "just make it and see if it works" approach (which is not the same thing as iterative development) could be successful... but all I can say is, that's not how I'd bet. ;) A model for game design -- what Raph Koster called "a theory of fun" -- has value if it gives you a meter for assessing the relative value of different gameplay features for a particular game.

    I don't say that there's one feature-assessment model that every game designer should use. But I sure do think the best game designers have some model that they use. Even a vague (but still accurate) map is better than no map at all.
  • Yes, static content and dynamic content seem like reasonable labels to apply... And no, I suppose there isn't all that much reason to separate them, other than that it classifies everything in the game into three distinct categories that each interact with themselves in similar ways, but with others in different ways.

    I like your other points, though, and Mechanics/Dynamics/Aesthetics seems reasonable, although I'd like to add that I don't really think either Dynamics or Mechanics could alter the Aesthetics of a game - or the other way around.
  • There was an old writeup I did on procedural storytelling (sadly site seems to be down and google is not turning up cached results), where I used the terms "actors", "stage", and "props" to describe characters, the environment, and items/artifacts. :)


  • edited November 2014
    gavanw said:

    There was an old writeup I did on procedural storytelling (sadly site seems to be down and google is not turning up cached results), where I used the terms "actors", "stage", and "props" to describe characters, the environment, and items/artifacts. :)

    Is this it?
  • Talvieno said:

    Mechanics/Dynamics/Aesthetics seems reasonable, although I'd like to add that I don't really think either Dynamics or Mechanics could alter the Aesthetics of a game - or the other way around.

    Aesthetics in the MDA system can be understood broadly as the "feel" of a game.

    Mechanics and Dynamics contribute to the Aesthetics. If you make a game whose primary mechanics are Console, Encourage, and Question, and whose dynamics and settings are designed to enhance those mechanics, that game is going to have a very aesthetic from one whose primary mechanics are Shoot, Stab, and Strangle.

    This goes the other direction, too. A game set in a sun-dappled forest with birds singing, and which is given mechanics and dynamics that fit that aesthetic, is likely to have very different verbs than a game set on a rainy night at a blighted tenement guarded by armed thugs.

    These "alter" each other during design. At least, they do if you've got a good designer willing and able to make all the components of a game support and enhance each other at all experiential levels. The MDA model is handy because it helps with that process of systemic alignment. But any model that helps a designer keep all of a game's systems synchronized toward delivering the distinct vision for that game is a win.
  • @gavanw
    How much information does each voxel use (in terms of bytes, color, special properties, etc)? Does each voxel have a field that specifies what "type" of voxel it is, like water, dirt, etc?
  • edited November 2014

    @gavanw
    How much information does each voxel use (in terms of bytes, color, special properties, etc)? Does each voxel have a field that specifies what "type" of voxel it is, like water, dirt, etc?

    Data gets converted at many stages, based on if in the voxel level, vertex level, or final render (post process).

    Initially, just 32 bits are used per voxel during generation. This gets uppped to 64 when preparing for vertex processing, but the the actual vertices are only 8 floating point numbers total for position and data (8*32 bits (256 bits), or 32 bytes of data per vertex).

    The actual material and voxel information is mostly contained within 16 bits, which allows for 2^16 (64k) base voxel types - an additional 8 to 16 bits can be thrown on top of that if more are needed.

    Vertices only came into use with the new perspective camera. The advantage is that they are more sparse than caching everything in bitmaps -- if a bitmap only had one voxel, it would still require the entire bitmap for storage. Now only visible voxels are stored, and the storage required is 1:1 with the number of visible voxels present.
  • Thanks for the info! That's a little more complex than I'd imagined previously due to the graphical processing, but the number of available voxel types offers a ton on options... :) Are voxels stored in 3-D arrays (or vectors, or another similar structure) by position, or does position information work differently?
  • edited January 2015
    I did some googling about these things. It seems like there is still a lot to learn for me about voxel engines.

    Good general overview:
    http://www.ibm.com/developerworks/library/os-physicsengines/
    (In the networking post I am re-writing I will have link to erlybullet an bullet library based on erlang.)

    Apparently some game engines use bounding hiearchies for splitting objects.Bounding can be split on many different types of objects: https://en.wikipedia.org/wiki/Bounding_volume#Common_types_of_bounding_volume

    The bounded voxels contained within a tree are named Bounding Hierarchies (https://en.wikipedia.org/wiki/Bounding_volume_hierarchy , http://www.win.tue.nl/~hermanh/stack/bvh.pdf) are good for having hierarchies of voxel structures where the objects can be cut into other voxel shapes.

    A survey of methods: http://image.diku.dk/projects/media/christian.bay.kasper.andersen.06B.pdf

    A cache efficient version in research though it is only free for noncommercial usage: http://gamma.cs.unc.edu/COLBVH/ with downloadable sourcecode: http://gamma.cs.unc.edu/COL/OpenCCL/download.html
    Other libraries also only free for noncommercial: http://gamma.cs.unc.edu/software/


    Some free that are bsd licensed for collision detection: https://github.com/danfis/libccd , https://github.com/OctoMap/octomap
    I'm not sure of the license on this: https://github.com/flexible-collision-library/fcl
    Box2d has some examples for collision as well that are free domain: https://code.google.com/p/box2d/downloads/list
Sign In or Register to comment.