Messages

1

Programming / Re: Physics Engine Implementation in Roguelikes

« on: May 13, 2013, 01:37:31 AM »

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 

2

Programming / Re: Physics Engine Implementation in Roguelikes

« on: May 12, 2013, 11:15:14 PM »

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.

3

Programming / Re: Physics Engine Implementation in Roguelikes

« on: May 12, 2013, 06:23:47 PM »

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

4

Programming / Re: Physics Engine Implementation in Roguelikes

« on: May 12, 2013, 05:29:45 PM »

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.

5

Programming / Re: Physics Engine Implementation in Roguelikes

« on: May 12, 2013, 03:43:11 PM »

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.

6

Programming / Physics Engine Implementation in Roguelikes

« on: May 12, 2013, 12:02:07 PM »

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!

7

Programming / Re: What's the best way to implement a 3D world with python/libtcod

« on: May 09, 2013, 12:48:06 AM »

err- sorry, the formatting messed up somehow.


Make the Z component of your map come first. So that you have a bunch of 2d arrays with respect to a Z-component Array.


In other words, your map is of the form Map[z]

• [y].

Now, when you want to draw something, you simply pass Map[z] into your grid-drawing function. The grid-drawing function expects a 2d array of x and y coordinates- Map[z] is a 2d array, whereas Map is a 3d array. Get it?

I think so. I'll mess around and see if I get something to work. I think so long as I can get something to show up on the screen I'll be able to jury-rig the rest.

8

Programming / Re: What's the best way to implement a 3D world with python/libtcod

« on: May 08, 2013, 10:23:48 PM »

Do the map as a Map[z]

• [y], and pass the Map[z] into the drawgrid thingy. I haven't used libtcod but I imagine that's the sort of pseudo-code you need.

Maybe I'm just thick, but I'm having a little trouble envisioning what you are suggesting here. Could you elaborate a little?

9

Programming / Re: What's the best way to implement a 3D world with python/libtcod

« on: May 08, 2013, 07:28:30 PM »

You need to make a distinction between the player's view and the game's map. This wouldn't be much different from a logically 2D game.

All you do is use a 3D array

• [y][z] and store whatever z-value the player is currently viewing from. This is no different from a normal game, where the view target of your proverbial camera can be described as the coordinate from which the viewing area is drawn.

In a fixed view roguelike, such as Brogue, the 'camera' is always pointing at the center of the viewing area, whereas in ToME, which follows the character (to some degree anyways) points at the character.

It can be useful to make the camera it's own entity so that you have the freedom to move it around with a 'look' command or what not- especially for a 3D roguelike.

I tried to do something akin to that, but I couldn;t get libtcod to display anything. I'll take another crack at it.

10

Programming / Re: What's the best way to implement a 3D world with python/libtcod

« on: May 08, 2013, 10:54:58 AM »

Logically 3D (dwarf fortress) or Graphically 3D (Diablo 3)?

Logically 3D. ASCII display with the ability to move up and down the z-axis.

11

Programming / What's the best way to implement a 3D world with python/libtcod

« on: May 08, 2013, 01:49:09 AM »

If it's possible, that is.


Logically 3D. ASCII display with the ability to move up and down the z-axis.

Whatever pointers/hints you can provide would be appreciated. If you could give a general sketch of the implementation rather than specific code, that would be great - learning experiences are valuable.

Thanks in advance!