Subject: Re: [stella] lots of things added to rescue.bin From: Nick S Bensema <nickb@xxxxxxxxxxxx> Date: Thu, 28 Aug 1997 13:26:37 -0700 (MST) |
>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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Duel Arena, Nick S Bensema | Thread | Re: [stella] lots of things added t, Matthew B. Vigor |
[stella] Duel Arena, Robin Harbron | Date | Re: [stella] lots of things added t, Matthew B. Vigor |
Month |