> At 08:16 PM 9/6/2003, you wrote:
> >is funny, because while a supercharger multiload might give you effectively
> >more RAM and more ROM, I don't think anything ever gives you more time
> >for your kernal.)
>
> The Supercharger can give you more time in your kernel by virtue of being
> able to use strips of RAM to determine dynamically on a frame by frame
> basis what to display. You just blit to these RAM locations inbetween
> frames to move sprites vertically.
Good point, thanks for pointing the explanation.
>
> >One thing that's surprising me is that so far the best ball
> >movment algorithm has been the simple diaganols I have now...
> >one danger with that and this game is that it might be that
> >the ball tends to always go to the same rows...
>
> I know Warlords gets kudos from most, but what I don't like about it is the
> lack of possible angles. The total possible trajectories are too
> limited. The arcade version expressed the ball as a rotating fireball,
> which is why there is an arc to some of the trajectories. In Warlords this
Hehehehe....MONDO WARLORDS anyone?
For me and my crew, the difficulty in positioning your paddle quickly
enough so that the opponent couldn't mirror you led to a lot of
"slam your paddle against the left or right wall and let go"...
the trouble with THIS is a weird semi-glitch in Warlods I'm surprised
we don't hear more about, because while that technique would wreck a
lot of havoc if it got past the player, for some reason with the
guy in the lower right corner, the ball would tend to bounce in,
around, and out of the castle without touching the king! Something
was strange about the geometry there.
>
> So the moral of that story would be, spend some time trying to make the
> ball trajectories more varied. You do have to cheat a little because I've
> also seen some pong games that allow the ball to get grazed by the paddle
> in a way that it starts moving in a mostly vertical trajectory, almost 90'
> with almost no horizontal speed. When this happens it takes FOREVER for
> the ball to slowly zigzag its way across the screen. Since the paddle
> can't push forward, it's really hard if not impossible to get that
> horizontal momentum back. So you can't really have completely realistic
> physics. If you were playing a game of real air-hockey you'd be able to
> reach forward and hit the ball in a case like this, but because the paddles
> are railed in Pong the game itself has to make sure the ball doesn't get
> stuck in the middle of the screen. Actually, one way to compromise would
> be to allow for realistic physics but have the game run a timer and if it
> detects that the ball is in the unhittable middle zone for too long, bring
> out the Pterry to knock it around.
Those Pong programs are thinking way too hard. Historically, JoustPong
has always had a constant magnitude horizontal motion to the ball,
changing only in direction. It worked pretty well, despite not being
accurate physics.
Early on I tried setting the ball vertical speed after a collision
to the speed of the player plus the previous speed of the ball, but
it got too fast. (I may revisit this approach, putting in speed
limiters)
More recently, I tried setting the ball vertical speed just to
the speed of the player it hit, without regard for the ball's
previous speed. This was sort of maybe ok, except for the way
humans play vs the AI; with a human, he or she tends to hit the
ball while coming close to hover so the ball tended to have small
or zero vertical speed, while the computer plays a much more manic
game, and was hitting the ball with ferocious velocity.
I could also go back to classic Pong, and have where the ball hits
on the paddle determine where it bounces off.
I could also try "gravitypong" where the ball arcs with gravity
(though unlike the players, has elastic collisions with the floor)
but previous experiments on different platforms of JoustPong weren't
fruitful....having to intuit the flap physics is hard enoguh without
figuring out how a ball is going to arc.
>
> >Hrm. I'm not sure if I like that or not. I almost think
> >that rainbows are a bit of a cliche in atari programming
> >'cause they're so easy...
>
> You have to play to the 2600's strengths. Plus, it does provide separation
> between the bricks without having to have a blank line.
Yeah, but then right now the ball would be color shifting too...
> In Death Derby it could have been a garish rainbow background but I want to
> keep the game more austere in honor of its black and white roots so it's
> merely a white to black gradient on the tombstones and safe-zone borders.
I had a similar effect with my first try at a poorlords kernal...it
actually looked pretty cool (actualy I had some weirder effects,
where because of timing issues the players cast odd 'shadows' on
the wall...it sounds cool but it didn't look all that good.)
--
KirkIsrael@xxxxxxxxxxxxx http://kisrael.com
"the day that you die will be like any other day, only shorter." --Beckett
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
