It can be 1, it can be 3, it could even be more. This is a design decision that you need to make, based on a number of factors. Some of them are soft decisions based on your circumstances and preferences:
- How much functionality (data and behaviour) is shared between the different types of bullets?
- How large and complex is the project going to be in the end?
- Where do your architectural tastes lie: do you flinch at the thought of having multiple small classes which only differ a little bit?
To answer the first point, it seems to me like a fair bit of functionality is going to be shared among the 3 types of bullets, unless my assumptions are wrong. It's a good bet that they will have a position vector, a velocity vector, a size property, some way of drawing themselves on the screen, and some way of detecting collisions.
This is a pretty good indication that you should start by having a "Bullet" class, which implements many of these things. One option available after this would be to inherit from Bullet, so e.g. OvalBullet could inherit from Bullet and implement its own Draw() method. In turn, you may already have a class in your project which is even more simple than "Bullet", e.g. an "Entity" class. Bullet could in turn inherit from there.
One important area where your bullets may differ is in collision detection. You could of course implement the exact collision detection code in OvalBullet, RectangleBullet, etc, but after a while you'll notice that you are duplicating code. Many different things will want to use either a box or a circle for collision detection. You might want to refactor the collision logic into several classes like RectangleCollisionDetector, CircleCollisionDetector, etc.
At this point, the job of a class like OvalBullet would be something like: correctly configure the relevant collision detector upon construction, pass the relevant parameters to the base (Bullet) constructor, and implement any truly unique behaviour (e.g. custom drawing). This way you can reduce duplication in your code, and make a trade-off between having shorter classes, but more of them interacting to achieve the outcome (hence my comment about your own preferences). The most basic, monolithic implementation might be 1 class. On the other end of the spectrum, this might be split into 2 base classes, a couple of interfaces, 2 or 3 collision detection classes, and 3 bullet classes.