Concept for Implementing Bowling 2
The main problem in implementing a 'good' bowling game is not, in my
opinion, the physics. It is the acceptable representation of the pins being
hit and falling over. The concept presented here is a technique for drawing
pin animations which should allow a good bowling program to be written.
Firstly, the pins are 'drawn' inside a 5 sprite wide x 20 line deep bitmap.
These dimensions are rough - but the essence of the idea is that the bitmap
is present in RAM, and built on-the-fly (or at least in VBlank) by combining
lots of smaller bitmaps. The dimensions given take 100 bytes of RAM... The
vertical resolution is, of course, stretched onscreen to whatever size
required to look reasonable (ie: a multiline kernal, of sorts).
Now, drawing a bitmap sprite onscreen is already handled by fine the large
sprite demos of years back. This uses the same technique (so yes, we could
go to 6 sprites wide if needed). The actual copying of a bitmap of sprites
from RAM to the screen, then, is trivial - given existing technology and
code. The non-trivial part becomes creating the bitmap itself, so that it
adequately represents pins being hit in a bowling simulation.
My idea is to decompose the pin setup and draw pins over the top of each
other into the RAM bitmap, from back to front, so that the RAM bitmap is
actually lots of little bitmaps drawn over the top of each other (with
transparency). This reduces the problem, then, to accruately representing
the collisions and interaction of pins.
How so?
Becasue the process of colliding can (in a simplistic fashion, yes, but good
enough for a bowling simulation) be reduced to a recursive process where the
closest of the three pins is hit by the ball (or another pin) and then goes
on to fall over and either...
a) miss everything else
b) Hit a pin behind it to the left
c) Hit a pin behind it to the right
d) Hit both pins behind it
THe draw technique I'm suggesting IGNORES the fact that the pin may hit
other pins. All we are concerned about is a pin being hit and animating as
it falls over. There are 10 pins to start with - the process of drawing the
whole 'board' consists of iterating through the pins - back to front in
order - and drawing their current animation into the RAM bitmap. If some of
those pins happen to be in the process of falling over - we don't really
care - the draw process is the same.
So each of the pins has an animation pointer, and a distance from the bowler
(so the back-to-front draw can work correctly). The draw, as stated, just
goes through all the pins, OR-ing in the animations for those pins into the
RAM bitmap in the correct position.
Due to 8-pixel boundaries, and the non-byte positioning of pins (they are
staggered), it may be necessary to repeat some of the animations for various
positions. That's a fairly trivial ask, but it does add to the ROM cost
(for storing essentially duplicate frames). But still, it's do-able.
Now the only remaining task becomes one of doing the physics of collisions.
That would be determining what pin had been hit, and in which direction and
speed it should move as a result. The choice of direction (and speed) will
then influence what animation is selected to play for it. The speed will
influence how far the pin moves, and consequently if/when it hits other pins
behind it, and at what speed. THough a bit trickier, this is still a
pretty simple task.
So, the whole process of drawing a set of pins being hit by a ball consists
of (for all pins)...
a) Determining which pin(s) have being hit, and setting them in motion with
appropriate animation
b) Drawing each pin into the bitmap, using current animation, in
back-to-front order.
c) Repeating until there is no movement (ie: animations have stopped)
That's essentially it. It sounds pretty straightforward.
Let's do some calculations...
RAM requirement for onscreen pin bitmap.... 100+ bytes
For calculation purposes, assume that each animating pin is drawn in a frame
5 bytes wide by 10 bytes deep. That's 50 bytes/frame. In reality, most of
that will be blank, and could probably be represented more efficiently. But
let's keep going...
We have the following animations...
* pin stationary
* pin wobbling but not falling over
* pin knocked in various directions
* straight back
* to the left, spinning sideways
* to the right, spinning sideways
The backward movement is catered for by the distance of the pin (which is
modified as the pin has been hit). The draw draws pins at their correct
distance-position (that is, the farther away a pin, the higher its base is
onscreen). So animations don't need to cater for pins going backwards...
they just need to give the frames of the pin animation.
So, the above frame list is pretty small. Assume that we have 7 different
pin positions
1 2 3 4
5 6 7
8 9
10
See that positions 2,8 and 3,9 and 10,6 are the same in the bitmap (in terms
of left/right position).
SO there are only 1,5,2,6,3,7,4 positions (that is, 7 different positions).
Some of those would probably be isomorphic.
7 positions x (say) 32 frames of animation x 50 bytes/frame (unpacked) = 11K
The 64 bytes/frame comes from the height of a single pin (say, 10 pixels) *
5 bytes/line.
Now pack that using simple RLE (which will give HUGE packing for this
layout) would go to < 4K.
So, we'd be able to get a reasonable-size pin layout drawn as a RAM bitmap -
copied to screen as a sprite matrix of - say - 40 x 20 pixels, with pins
animating in a realistic way, and independantly hitting and causing other
pins to animate (ie: it would look pretty much like the real thing) in a 4K
cartridge with very little difficulty.
Cheers
A
----- Original Message -----
From: "Glenn Saunders" <cybpunks2@xxxxxxxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Friday, September 06, 2002 5:29 PM
Subject: Re: [stella] Progrmmer needed for Bowling 2 :-)
> At 07:01 PM 9/5/2002 -0400, you wrote:
> >I was thinking one of those gauges that are so popular on golf games
> >now-a-days would be a neat way to control the amount of curve you put on
> >the ball and your roll's speed, but every time I get to the pins, I'm
> >stumped for an easy way to handle it.
>
> Someone should disassemble both Bowling and Trick Shot and see how the
> physics are done there.
>
> You want to have a healthy dose of randomization, but maintaining some
good
> control too so you aren't completely limited by chance.
>
> I wouldn't think too literally about the physics. The end result is a
> pattern of downed pins that seems to make sense. You shouldn't have to
> track each trajectory and velocity and angle. I think that's how bowling
> works. If you study the patterns of pins that occur in real bowling, it's
> not a lot of different combinations, actually. It's somewhat
deterministic
> based on which pin you hit first and how centered your throw is and how
> much english.
>
>
>
> --------------------------------------------------------------------------
--------------------
> Archives (includes files) at http://www.biglist.com/lists/stella/archives/
> Unsub & more at http://www.biglist.com/lists/stella/
>
>
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
