ID:24648
 
A model is something that we use in order to predict/understand how a complicated system works - it describes how a system behaves. Models are usually not perfect and can be refined. An example of a model would be flipping a coin. One model might suggest that you have a 50% chance of getting heads on any given toss of the coin. But we can refine this model by adding to it that one side of the coin is heavier than other. This means that our model will now suggest you have a higher chance of getting one side than the other. But even then our model wouldn’t be perfect but it would still help us predict how the coin would land.

Models can also be used in programming, but the beauty is that the model you create will actually give the exact desired effect in your world. If you say that the probability of getting heads on a coin is 50%, then the probability of getting heads WILL be 50% (assuming your calculations and programming is correct). If you want to use something realistic though, you’ll have to come up with some models for your world.

Let’s suppose that there’re two people in a fight. Person A has a sword and is swinging it at person B who is stationary. Sir Isaac Newton’s second law of motion states that Force (F) = mass (m) * acceleration (a). If we let the sword be 4kg, person B be 3kg and say that as the sword hits person B, it is accelerating at 6 m/s^2 (6 metres per second squared), then we can work out the force that the sword strikes person B with.

F = ma
F = 4 * 6 = 24N

We could then say that person B is being pushed 24N. But the question is; what direction? If the sword were completely horizontal, then the 24N would be pushing person B completely horizontally. This usually isn’t the case though – the sword will most likely be a bit tilted. Let’s say that when the distance between person A and person B is 1 tile (that is to say they’re standing on tiles next to each other), then the sword always strikes person B at 30 degrees (to the horizontal). Let’s illustrate this on a diagram to make it clearer:





From the diagram, we can see the force, the angle and the person are related in a triangle.

Every sloped line can be resolved (broken up into) a horizontal and vertical part. Which means that our sloped 24N can also be resolved horizontally and vertically. The horizontal part shows what horizontal force would be applied to B and the vertical part shows what vertical force would be applied to B. Together, they would move B in the north east direction (which is what the 24N represents).



The diagram shows the 24N can be resolved horizontally and vertically. You should know from basic trigonometry that cos x = adjacent/hypotenuse and that sin x = opposite/hypotenuse (adjacent being the side next to the angle, opposite being the side opposite the angle and hypotenuse being the largest side of a right angled triangle).

Then we can work out the horizontal component of our 24N force:

cos(30) = Horizontal/24
Horizontal = 24cos(30) = 20.78…N

(The vertical force would then be 24sin(30). You can check these components are correct by using the Pythagorean theorem – (24cos(30))^2 + (24sin(30))^2 = 576, square root of 576 = 24N).

Therefore we can say that a force of 24cos(30)N is acting horizontally on B when it’s struck by the sword. Let’s assume this is the only force acting on B, we don't want B to move vertically so we disregard 24N's vertical component.

F = ma
24cos(30)N = 3kg * a
a = 24cos(30)/3 = 8cos(30) m/s^2

This shows that person B will accelerate at 8cos(30)m/s^2 horizontally.

Let's translate this into DM.

atom/movable/var
mass = 0
acceleration = 0

obj/Sword
mass = 4
verb/Strike(mob/M as mob in oview(1))
acceleration = 6
var/force = mass * acceleration //24N
var/angle = 30
var/horizontal = force * cos(angle) //24cos(30)
M.acceleration = horizontal/M.mass //24cos(30)/3 = 8cos(30)


At this point, we've worked out how fast person B will be accelerating (the reason lots of variables were used was because you might want to adjust the model).

Using this value is up to you. One way of using it would be to say, let the person accelerate for 3 seconds and then say that the person is able to stop the force acting on him completely (which means that no more movement occurs after 3 seconds - the person is stationary). The person's displacement can be given by:

s = ut + 1/2at^2

s = displacement.
u = initial velocity.
a = acceleration.
t = time.

We said the person is stationary at the top, which means that u = 0. Then:

s = ut + 1/2at^2
s = 0*t + 1/2at^2
s = 1/2at^2
s = 1/2*a*3^2
s = 1/2*a*9
s = 4.5a
s = 4.5 * 8cos(30)
s = 36cos(30)

The person moves approximately 31.1m horizontally. Translating this to DM gives:

atom/movable/var
mass = 0
acceleration = 0
u = 0 //initial velocity


obj/Sword
mass = 4
verb/Strike(mob/M as mob in oview(1))
acceleration = 6
var/force = mass * acceleration
var/angle = 30
var/horizontal = force * cos(angle)
M.acceleration = horizontal/M.mass //24cos(30)/3 = 8cos(30)
var/time = 3 //as defined in the model
var/s = (M.u*t)+(0.5*M.acceleration*(3**2)) //the brackets are unnecessary but demonstrate what's happening - s = 36cos(30)


Now clearly moving the person 31 tiles in our world would seem stupid. Let's say each metre is 2 pixels.

atom/movable/var
mass = 0
acceleration = 0
u = 0 //initial velocity


obj/Sword
mass = 4
verb/Strike(mob/M as mob in oview(1))
acceleration = 6
var/force = mass * acceleration
var/angle = 30
var/horizontal = force * cos(angle)
M.acceleration = horizontal/M.mass
var/time = 3
var/s = (M.u*t)+(0.5*M.acceleration*(3**2))
s = round(s,1)
while(s>0)
M.pixel_x += 2
s--
sleep(2)


That would give the graphical effect of moving M s*2 pixels. Clearly there's a problem that pixel_x can only range from -127 to 127, but there are ways around that which you will have to implement yourself.

Problems with the model.

1) Everything has been treated as a particle. If a person is pushed with a force of 24cos(30), the person wouldn't really move a distance of 36cos(30) for several reasons. One reason is that your mass isn't concentrated all into one spot. It is easier for one to push your hand backwards than to push your entire body backwards. But in our model, we treat the person as a particle with its mass concentrated in a single point. The same goes for the sword.

2) The model assumes that the sword always strikes the person at a 30 degree angle. This is clearly not the case and depends on the shape of person B and the sword. Accurate collision detection would allow you to draw a much better triangle and also work out the correct angle using some trigonometry.

3) The model assumes that the force produced by the sword is the resultant force acting on person B. This clearly isn't the case in the real world. A gravitational field acts on your body and pulls you downwards to the centre of the Earth. A reaction force is produced by the surface your body is on which acts on you (Newton's 3rd law of motion). There might also be some air acting on you.

4) The model assumes you always move for 3 seconds before stopping. This would however depend on many factors such as your strength.

5) The model disregards friction when moving person B.

6) The vertical force produced by the sword was completely ignored.

There are probably even more flaws in the model that have not been explicitly pointed out.

However, there is absolutely no need to make your game 100% realistic. You, the creator, can choose what you want in your world. And if your chosen model does not behave in the way you'd like it to, you can always refine it (not to make it realistic, but to make it how you wanted it to be in your head - your programming is just a model of what you want in your head).

(Images are courtesy of Popisfizzy).
Interesting. Makes me wish I was good at math. =/
Interesting article. Although, I think a mace or large hammer would have been a better example, as a sword's cutting power reduces the amount of force thrown directly into the person's body.

Would be rather fun to implement into a game, though. *Imagines swinging a huge hammer into the torso of a skeleton sending it flying into a wall where it shatters into 206 peices*

It's funny, but you never really know what you're actually doing until you read an article about it. Just about every game will have several to many models in it, but I doubt anyone thought of it that way.
1 question can you help me make my Naruto Game?Or be my iconner?
Popisfizzy wrote:
Interesting. Makes me wish I was good at math. =/

Same, I currently suck ass in it. o_O
Although the point got across I have discovered a couple of minor problems:

Firstly, in the equation:

var/s = (M.u*t)+(0.5*M.acceleration*(3**2))

The 't' variable doesn't exist, that should be replaced with the 'time' identifier.

Secondly, the mobs mass has been initially set to 0 however later on throughout the procedure you deal with:

M.acceleration = horizontal/M.mass

But the mobs mass was never changed to something not 0.

So that would lead to a "division by zero" runtime error.

Anyhow, this is a really good article and has really help me understand the use of models.

Really good article, thank you.