>If we're talking about action games, I think player's control. It must be
>smooth and immediate to understand (thought not necessarily easy to master).
>
>If there's a thing that I really hate, it's that kind of platform games
>where you control a man, and when he jumps he does not follow the physics
>laws (i.e. gravity acceleration). Sadly, there are many games of this kind
>for the 2600.
It is a shame, because gravity is relativelyl easy, in my opinion, to
implement.
Keep track of a character's vertical velocity, so that jumping will
simply set that velocity to some high amount. If there is nothing
underneath the player, accelerate that velocity vector downward by
some gravity constant. The jump looks natural, and the vector follows
a completely linear progression: +3, +2, +1, 0, -1, -2, -3...
Here is the sort of decision tree you'd be dealing with.... some of these
IF's won't be parsed by the program, but hard-coded as you, the programmer,
decide what will bounce and whether there will even be a terminal velocity.
I bet this could be streamlined very easily.
If object's foot is touching the ground,
then (IF object is landing)
IF vertical velocity is too high,
THEN splatter object all over pavement
IF object is supposed to bounce,
THEN vertical velocity = vertical velocity *= - buoyancy constant
ELSE set vertical velocity to zero
IF object is to skid, horizontal velocity *= friction constant
else (IF object is still falling)
IF velocity + gravity constant is greater than terminal velocity,
THEN vertical velocity = terminal velocity
ELSE vertical velocity += gravity constant.
vertical position += vertical velocity
In case you don't know C notation, += and *= mean "increments by" and
"multiplies itself by", respectively. If you don't know physics,
terminal velocity refers to the velocity where falling objects stop
accelerating; in the real world it's because of air resistance, but
in a game its purpose is more aesthetic. The gravity constant should
be fairly obvious; the frictional and buoyancy constants(*) are fractional
values less than 1; an object with a frictional constant of 0 would
grind to a halt upon landing, and an object with a buoyancy constant
of 0 would not bounce.
*: I don't know if these are the official names.
I can imagine on the 2600, you wouldn't be eager to do all this
multiplication, though you could probably swing friction/buoyancy
constants of 1/2, 3/4, 7/8, etc. I imagine the velocity itself will be
represented by an 8-bit fixed-point register, which would probably
provide both sufficient precision on the fractional side, and
sufficient range for a good, decent arc.
Also... I don't really know much about the overflow bit on the 6502, but
my guess is the terminal velocity were 127, the overflow bit would signal
that the object has passed terminal velocity. This would apply
the double-duty of keeping the object from falling too fast, _and_
keeping the register from suddenly changing sign and "bouncing" the
object.
Man, have I written at length on this or what? You probably got the
gist of it in the first two or three paragraphs anyway.
--
Archives updated once/day at http://www.biglist.com/lists/stella/archives/
Unsubscribing and other info at http://www.biglist.com/lists/stella/stella.html
