Physics Engine Implementation in Roguelikes

[gideon_stargrave]

I was wondering if someone had some advice as to the most common approach to this, or alternatively could point me in the direction of some resources. I have a rough idea of what's required, but if anyone has some more in-depth instructions, that would be a huge help!

[Quendus]

What kind of physics do you mean? Very few roguelikes have anything resembling Newtonian Physics. What effect would the physics engine have on objects in the game?

[gideon_stargrave]

What kind of physics do you mean? Very few roguelikes have anything resembling Newtonian Physics. What effect would the physics engine have on objects in the game?

Hmmm. I'd say the following:
- Object movement(eg after being thrown, or after an explosion), including projectile movement
- Collisions(Including weapon/armour contact, simulated using materials)

I know I could just implement materials simulation with the rest of combat, for example, but I wonder if there's a better systematic approach I could(should) take.

[Krice]

but I wonder if there's a better systematic approach I could(should) take.

I don't know if systematic means better. There are many things you need to consider when using physics. First one is that it can't be realistic. Or it can, but it makes the game most likely too difficult. I think physics can be used as a kind of abstract data to compute results in stuff like damage routines.

[gideon_stargrave]

but I wonder if there's a better systematic approach I could(should) take.

I don't know if systematic means better. There are many things you need to consider when using physics. First one is that it can't be realistic. Or it can, but it makes the game most likely too difficult. I think physics can be used as a kind of abstract data to compute results in stuff like damage routines.

I don't plan on making things overly realistic - I know my limitations. w/r/t making the game too difficult, are you referring to how challenging to the game is to code or to play? If it it's the latter, I should think that could be rectified if armour was appropriately balanced and a combat system was included that took into account the level of simulation in the game and gave the player appropriate options.

[Quendus]

I don't think the question of the most common approach to those problems can be answered - very few RLs, or games in general, use any system like that. You don't have to put them in your game just because Dwarf Fortress has them.

One way to allow items to be made from different materials is to have a system like IVAN's: each material has a few properties like hardness, flexibility, and density. An object like a weapon, limb, or piece of armour is made from a given has its bonuses (to stats, HP, damage, armour value, etc.) determined by the base item type and material properties. This system lets you have an intricate material system without implementing anything more complex than a normal RPG-style stat system.

[gideon_stargrave]

I don't think the question of the most common approach to those problems can be answered - very few RLs, or games in general, use any system like that. You don't have to put them in your game just because Dwarf Fortress has them.

One way to allow items to be made from different materials is to have a system like IVAN's: each material has a few properties like hardness, flexibility, and density. An object like a weapon, limb, or piece of armour is made from a given has its bonuses (to stats, HP, damage, armour value, etc.) determined by the base item type and material properties. This system lets you have an intricate material system without implementing anything more complex than a normal RPG-style stat system.

I do realise what I'm trying to do may seem impractical, and that I'm probably not the first one(by a long shot) to attempt something like, and I certainly wouldn't be the first one to fail.

However, it's not as if I'm terribly concerned with putting out a commercially viable product or conforming to a deadline or whatever. This is simply a project I'm working on in my spare time out of personal interest, and part of what makes it interesting to me is implementing a physics system. If it  well and truly is difficult as you say, I may be out of luck, but I'm going to give myself the opportunity to fail first. 

Any suggestions you can send my way are of course appreciated

[Quendus]

The important questions aren't "is it practical?" or "do I have the skills to do it?". You can probably learn the skills. The questions you should ask are "will the game benefit from it?" and "does the benefit from this feature justify the extra effort?".

[requerent]

You can do Newtonian physics just fine in a grid based game, you'll just be using discrete units of measure based upon a space-time relative to the grid. Which can be rationalized roughly as the space it takes to comfortably occupy a single 'person' and the time it takes for said person to 'move at a brisk pace' between two tiles. As units of measure, we don't need to know what the actual values are, just that they are logical placeholders that serve as an abstraction layer over Newtonian physics.


Your smallest units of measure are 1 tile and 1 tile per turn, so base everything around this, including mass and acceleration.

Decide on whether you want to be fully physical or just use physics for certain effects. In a fully physical game, you need to ensure that an entity is always capable of moving 1 tile's worth based on it's physics-relevant statistics. This is important because you'll need to use it when calculating whether or not you can push into another object's tile.

You're going to probably want to use a state-machine to manage the physical states of agents. Don't use 3D physics, just use abstractions to represent traction. In most cases, if an entity is balanced, then it's forces will be cleared at the beginning of its turn. If not, they should spend their turn recovering balance. Traction should play a role here- for example, if an object waits, you can increase their traction, making it more difficult for them to be moved by other forces. If they're off-balance or in the air/falling, then traction should play no role in whether they recover or not. You'll need different rules for Flying or Floating enemies. An enemy that gets knocked-down might take a hit to their AC, while an enemy that's off-balanced may not be able to move/take action, but wouldn't suffer a penalty doing so.

Use your line-drawing algorithm and rectangles (two xy coords) to represent direction vectors. You'll need this for force calculations that make sense in grids.

[gideon_stargrave]

You can do Newtonian physics just fine in a grid based game, you'll just be using discrete units of measure based upon a space-time relative to the grid. Which can be rationalized roughly as the space it takes to comfortably occupy a single 'person' and the time it takes for said person to 'move at a brisk pace' between two tiles. As units of measure, we don't need to know what the actual values are, just that they are logical placeholders that serve as an abstraction layer over Newtonian physics.


Your smallest units of measure are 1 tile and 1 tile per turn, so base everything around this, including mass and acceleration.

Decide on whether you want to be fully physical or just use physics for certain effects. In a fully physical game, you need to ensure that an entity is always capable of moving 1 tile's worth based on it's physics-relevant statistics. This is important because you'll need to use it when calculating whether or not you can push into another object's tile.

You're going to probably want to use a state-machine to manage the physical states of agents. Don't use 3D physics, just use abstractions to represent traction. In most cases, if an entity is balanced, then it's forces will be cleared at the beginning of its turn. If not, they should spend their turn recovering balance. Traction should play a role here- for example, if an object waits, you can increase their traction, making it more difficult for them to be moved by other forces. If they're off-balance or in the air/falling, then traction should play no role in whether they recover or not. You'll need different rules for Flying or Floating enemies. An enemy that gets knocked-down might take a hit to their AC, while an enemy that's off-balanced may not be able to move/take action, but wouldn't suffer a penalty doing so.

Use your line-drawing algorithm and rectangles (two xy coords) to represent direction vectors. You'll need this for force calculations that make sense in grids.

Thanks! That all seems to make sense. Could you elaborate on how an solid state machine should best be implemented? I admit I'm not too familiar with them.

[Ex]

I guess my question is: will it make gameplay better or more fun? It seems like a lot of work for something that might not improve the game.

Basic Newtonian physics is really easy though, as long as you don't want complicated stuff. Requerent's ideas are all good.

[requerent]

You can do Newtonian physics just fine in a grid based game, you'll just be using discrete units of measure based upon a space-time relative to the grid. Which can be rationalized roughly as the space it takes to comfortably occupy a single 'person' and the time it takes for said person to 'move at a brisk pace' between two tiles. As units of measure, we don't need to know what the actual values are, just that they are logical placeholders that serve as an abstraction layer over Newtonian physics.


Your smallest units of measure are 1 tile and 1 tile per turn, so base everything around this, including mass and acceleration.

Decide on whether you want to be fully physical or just use physics for certain effects. In a fully physical game, you need to ensure that an entity is always capable of moving 1 tile's worth based on it's physics-relevant statistics. This is important because you'll need to use it when calculating whether or not you can push into another object's tile.

You're going to probably want to use a state-machine to manage the physical states of agents. Don't use 3D physics, just use abstractions to represent traction. In most cases, if an entity is balanced, then it's forces will be cleared at the beginning of its turn. If not, they should spend their turn recovering balance. Traction should play a role here- for example, if an object waits, you can increase their traction, making it more difficult for them to be moved by other forces. If they're off-balance or in the air/falling, then traction should play no role in whether they recover or not. You'll need different rules for Flying or Floating enemies. An enemy that gets knocked-down might take a hit to their AC, while an enemy that's off-balanced may not be able to move/take action, but wouldn't suffer a penalty doing so.

Use your line-drawing algorithm and rectangles (two xy coords) to represent direction vectors. You'll need this for force calculations that make sense in grids.

Thanks! That all seems to make sense. Could you elaborate on how an solid state machine should best be implemented? I admit I'm not too familiar with them.

A Finite State Machine is just a way of representing different states that an object may be in. You don't actually need any specialist infrastructure to implement them, it's more of a conceptual thing. You may have different states for things like: dead, dying, falling, flying, walking, standing, charging, etc. These states can be implemented as flags or Booleans whereby the functionality of some methods/functions/processes is altered based upon the state. There is no formal way to manage states. Different states are treated in different ways and have different properties, but all represent the same object.

So- for example, we might want an enumerated type to describe the physics states. And then if-statements to modify calculations based upon whatever active physics state that object is in. State Machines are 99% of the time always a smart thing to implement for every game. Let's say the player character fails a traction check against some force applied to him. We just change the physics state and the next time an opponent attacks the player, we use data/values/algorithms relative to that particular state. Say the player gets knocked on the ground- we can change his physics state to 'prone,' which might put him out of LOS for some enemies and easier to hit for nearby enemies.

[gideon_stargrave]

You can do Newtonian physics just fine in a grid based game, you'll just be using discrete units of measure based upon a space-time relative to the grid. Which can be rationalized roughly as the space it takes to comfortably occupy a single 'person' and the time it takes for said person to 'move at a brisk pace' between two tiles. As units of measure, we don't need to know what the actual values are, just that they are logical placeholders that serve as an abstraction layer over Newtonian physics.


Your smallest units of measure are 1 tile and 1 tile per turn, so base everything around this, including mass and acceleration.

Decide on whether you want to be fully physical or just use physics for certain effects. In a fully physical game, you need to ensure that an entity is always capable of moving 1 tile's worth based on it's physics-relevant statistics. This is important because you'll need to use it when calculating whether or not you can push into another object's tile.

You're going to probably want to use a state-machine to manage the physical states of agents. Don't use 3D physics, just use abstractions to represent traction. In most cases, if an entity is balanced, then it's forces will be cleared at the beginning of its turn. If not, they should spend their turn recovering balance. Traction should play a role here- for example, if an object waits, you can increase their traction, making it more difficult for them to be moved by other forces. If they're off-balance or in the air/falling, then traction should play no role in whether they recover or not. You'll need different rules for Flying or Floating enemies. An enemy that gets knocked-down might take a hit to their AC, while an enemy that's off-balanced may not be able to move/take action, but wouldn't suffer a penalty doing so.

Use your line-drawing algorithm and rectangles (two xy coords) to represent direction vectors. You'll need this for force calculations that make sense in grids.

Thanks! That all seems to make sense. Could you elaborate on how an solid state machine should best be implemented? I admit I'm not too familiar with them.

A Finite State Machine is just a way of representing different states that an object may be in. You don't actually need any specialist infrastructure to implement them, it's more of a conceptual thing. You may have different states for things like: dead, dying, falling, flying, walking, standing, charging, etc. These states can be implemented as flags or Booleans whereby the functionality of some methods/functions/processes is altered based upon the state. There is no formal way to manage states. Different states are treated in different ways and have different properties, but all represent the same object.

So- for example, we might want an enumerated type to describe the physics states. And then if-statements to modify calculations based upon whatever active physics state that object is in. State Machines are 99% of the time always a smart thing to implement for every game. Let's say the player character fails a traction check against some force applied to him. We just change the physics state and the next time an opponent attacks the player, we use data/values/algorithms relative to that particular state. Say the player gets knocked on the ground- we can change his physics state to 'prone,' which might put him out of LOS for some enemies and easier to hit for nearby enemies.

Alright, thanks again! I have a lot of work to get started on