
				\|\|\|\|

By Anders Hansson
Gamasutra
[Author's Bio]
October 18,2002

Game Mechanics

100m

Long Jump

	Printer Friendly Version

Game Developer Magazine Back Issues four CD Set.
Every issue 1994 to April 2002.
Price: $189.00 + S&H

Letters to the Editor:

Write a letter

View all letters

Features

Track and Field Game Mechanics

100m

The Speed Algorithm
With this vision clear in my mind I started to consider the design of the actual events. As 100m is the first event of the decathlon and as eight of the ten events in the decathlon involve running, it was natural to start with the 100m.

At this time in my life, I had taken up track & field training again after a break of some years. Now older, I had a more analytical interest in the sport. I studied video recordings of competitions and read scientific studies.

With realism in my mind, I began to think about the algorithm for running speed. You cannot simply let a certain button pressing frequency correspond to a certain running speed. The player is able to reach maximum button pressing frequency at once from the shot of the gun. A runner, however, reaches top speed only after 40-50 m of acceleration. We can achieve this easily by letting each button press increase the running speed and the higher the running speed, the smaller the increase in speed. If we also include a constant deceleration factor, a certain button pressing frequency will eventually result in a certain maximum running speed.

By adjusting the parameters of this algorithm we should be able to let a player of a certain skill run the 100m at a certain time. We found that it should be possible to simplify the player input to a constant button pressing frequency from start to the finish. By simple statistical analysis of the decathlon series by the top 20 performers of all time, we found that 10.56s and 11.03s at 100m correspond respectively to 9000p and 8000p in the decathlon. As 9000p roughly equals the world record, the button frequency of a 10.56s race should only be attainable for gifted player. As 8000p would roughly match the score needed to qualify to the World Championship, the corresponding button pressing frequency should be attainable for most players.

To ensure that maximum speed is reached in the right part of the race (i.e. after 40-50m) further balancing of the parameters is necessary. A wacky velocity-distance curve could easily spoil the effect of an otherwise realistically and carefully done animation of the runner. Still, you could argue that the fine tuning of the velocity-distance curve is only a visual matter and thus of minor importance. If we didn’t aim for perfection, I would be inclined to agree. However, we should naturally use the same algorithms and parameters for the running speed in the long jump and as the velocity-distance curve has a more profound influence on the long jump, there are strong reasons to have it properly done from the beginning. The time-velocity curve determines when top speed is reached and consequently it determines the length of an optimal run-up. The velocity-distance curve also determines the top speed, which is the major deciding factor of the length of the actual jump

The animation of the running stride
Let’s then turn to the visual representation of running. It should be pretty simple, shouldn’t it? Just make an animation cycle that constitutes two running strides and make sure to draw enough frames for smooth movements. Well, it will certainly look odd if the runner goes directly from the crouched starting position to an upright running position. Games with a comical graphical style like the original Track & Field can get away with this but it would clash very badly with an otherwise realistic animation. A realistically animated acceleration phase will require an awful lot of frames and plenty of work considering that our intention is to use hand drawn sprites. Fortunately we should be able to use the same animation in the 110m hurdles and the 400m and perhaps also part of it in the long jump (you do not start from starting-blocks in the long jump).

A few words on how the animation was actually made: I guess you could say that we used a rotoscoping technique. I filmed athletes for every animation sequence, extracted the video frames, cut out the frame of the athlete, manipulated size, colors and lights and finally I manually drew/colored clothes, shoes and the head of the athlete along with a lot of other manual modifications. No fancy camera equipment was used. To maintain a proper side view perspective, I filmed from a long distance with a lot of zoom and occasionally I had to take several shots from different viewpoints.

Sliding feet is a very common visual shortcoming in all kinds of videogames. Track and field games are no exception. The quality of the visuals and animations of many sports games today may at first glance be mistaken for real television footage but sliding movements will destroy the illusion and reveal its artificial origin. I am proud to say that there are no sliding movements at all in Fila Decathlon.

How do we avoid sliding feet during the running animation? If every frame change corresponds to a certain forward distance covered, we can simply let the frame changes be distance dependent instead of time dependant. The animation cycle of one running stride then corresponds to the sum of these distances, which implies that the time needed to complete a running stride is inversely proportional to the running speed. That is, stride frequency increases with running speed. In reality, faster running is achieved by an increase in both the stride length and the stride frequency. A running stride can be divided into the ground support phase and the airborne phase. If the frame changes during the ground support are distance dependant and the frame changes during the airborne phase are time dependent, the outcome should be the desired – no sliding feet and a stride length as well as a stride frequency that increase with the running speed. (As an aside: the stride frequency of elite sprinters is about 4.5 - 5 strides/second and at top speed their stride length typically varies between 2.2 – 2.4 meters.)

Ok, as you can see a lot of thought and work were done to optimize the realism of running. But did it have any significant effect on the playability of the 100m event? Not really, what makes the 100m more interesting in Fila Decathlon than in most other games are probably the well balanced result levels and the challenging computer controlled athletes.

A short analysis of the factors that determine the outcome in the 100m would result in the diagram below.

Factor one, the reaction time, is of course present in all track and field games. A neat addition in Fila Decathlon is that the reaction time is displayed on a clock of the in-game graphics and just like in real track and field a reaction time below 0.10s is considered to be beyond the human limit and is penalized by a false start warning. (In the decathlon you are allowed two warnings, after the third warning you are disqualified.)

Factor two, the button pressing frequency, is more complex as it stretches over time. A bit simplified, you could say that it consists of the ability to achieve a certain button pressing frequency and of the ability to keep this button pressing frequency during the whole race. With regard to the playability, it is really not the realism of the speed algorithm but its sensibility to the slightest change of pressing frequency that matters.

Factor three, the timing of the finishing dip over the finish line, is not present in all track and field games. In reality a finishing dip, even if perfectly timed, improves your time very little. We actually exaggerated the effect of the finish dip to add significance to this factor, that is, we departed deliberately away from realism.

______________________________________________________

Long Jump