I've been playing alot of Arkanoid on my NES lately. Curious to hear if anyone else thinks this game is hard. I'm lucky if I can get to the 4th level. Usually the only way I can beat the impossible 3rd level is if I get the pink power-up that let's you advance to the next level. But what is really humbling is that the default high score in the game is 50000. I've only gotten over 50000 once and I've probably played over 50 games of it the last week. The default high scores on games seem to pretty achievable. Are there any secrets to this game or do I just suck that bad?
believe it or not, ive seen the arkanoid controllers at gamestop, and they were priced the same as a standard NES game, i nabbed two of them (just in case), but sadly, i dont have a copy of arkanoid to play
My local GS has Arkanoid, but no controller. And the game is so icky with a sticker from a rental place right on the label. Ugh, I freaking hate that and turn down any cart with non-removable labels like that.
I remeber back in High School (yeah, that was a long time ago ) almost every computer had a breakout clone and I took to it quickly. When I was asked why I was so good at it, I said "because I beat Arkanoid, duh." Not an ounce of recognition! Philistines and heathans, all of them! (except shep and smitty)
Our old computer had one called "MBlast" that was awesome. And had an "Auto" mode that let the computer play. And it wasn't scripted, it was actually logical. In that once in a while, the game would get "stuck" with the ball bouncing back and forth in the same place infinity. That just meant it had to be started over. Eventually it would actually make it all the way through if you were lucky.
You MUST have the special controller to have a fair shot at this game. I have beaten it; I'm pretty sure there are 36 levels, three more than the arcade. And yes, it's very hard even with the special controller.
I don't recall having any problems with the standard NES pad, but I typically used the vaus controller too. The 3rd level was more luck than anything, sometimes I'd die there, sometimes if I could beat it, I'd go several more levels past that. I don't have it anymore thou.
36 levels??? Good grief. I don't see how it's possible to finish the game with the standard controller. I'll have to keep my eyes out for the special one. Is there a way to continue where you left off? In the NES version you start out with 3 lives, and get a bonus life every 50000 I think. Making it through 36 levels with that few lives seems impossible. I don't know of anyway to continue where you left off in the NES version.
If you don't want to change all your games using dial to a mouse then you can make a separate "arkanoid.ini" file and place in your Mame INI folder. You would simply but that one line in there and MAME will take that as priority over your main MAME.ini file but leave all other settings the same.
You likely want the above. This is just letting MAME you want to use those devices. The previous entries that sundogak posted tell MAME which one of your devices to use when emulating those devices in MAME.
If you have multiple mouse devices, like a spinner, trackball, mouse, Windows normally treats them as one single device. In that case you want to use multimouse 1 and within MAME, each device will appear as a different mouse device.
I have a slider, whose velocity I calculate via the difference between positions each tick (this can sometimes be huge due to using it via a touch screen, so maybe I should clamp this at some arbitrary number to avoid some of these issues?)
This seems to work great, except in some cases it seems to be very possible for any of the balls axis to equal zero, resulting in it never returning to the slider in some cases. What would be a good solution to this? And what would be a good way to handle the response with the blocks when it collides with them? Should it return to bouncing at right angles, or should it maintain reflecting with the same bounce modifiers applied by the slider? Also any other physics tips for this kind of projectile simulation would be appreciated.
Hmm, this is a nice problem; the thing is, a good solution (that is, one that looks and feels just like real physics) is by nature one that uses real physics. Luckily, most of the newtonian physics within this problem can be easily simplified. Pardon me if I get overly verbose, but physics tends to do that to you.
So, to define the problem, this is an elastic (as in, no energy is absorbed) collision between an arkanoid ball and a paddle. First of all, since you've obviously got the vertical motion down, I won't concern myself with that. So what follows is all on the horizontal components of the collsions.
The paddle transfers a certain amount of horizontal momentum to the ball (although, since this is Arkanoid physics, the paddle loses no momentum itself :P). This can be recieved in two ways -- by making the ball spin, and by giving the ball some horizontal momentum (obviously, if the ball already has horizontal momentum or spin, the added momentum will be...well, added).
Of course, it might be annoying to work with momenta, since you don't really have to. I would asssume that the ball and the paddle have constant mass (that is, the ball does not suddenly become heavier, although you could easily work with that), because then you could factor the mass of each out of your momentum equations. So then,
This will be enough to set up a quasi-realistic bounce, but one nugget remains (which you don't need to adress, but adressing it would make your Arkanoid amazing) -- what happens to all that spin? Can the spin be used somehow for more interesting bounces?
So, to recap, your spin is the speed at which the periphery of the ball is moving relative to the center. Thing is, whenever a spinning ball bounces against something stationary, its spin changes as well as its velocity. If a spinning ball hits a stationary surface, the bal gets a little "kick" in the direction opposite that of its spin (if spin is measured at the point of contact), and the spin will change.
for a clean collision detection the ball movement is calculated several times a frame (+collision detection) and then drawed. so if the ball has a speed of 5, his way is calculated 5 times and then drawed to the screen.
with this technique he flies fast enough for the human eye but is calculated exactly and doesnt jum in 5 pixel steps.
Now that I think about it, it probably is easiest to plot the entire line of the balls path from one frame to the next and just deal with collisions on a pixel co-ordinate basis. (still using a bounding box for a block, no actual pixel collisions).
Now that I think about it, it probably is easiest to plot the entire line of the balls path from one frame to the next and just deal with collisions on a pixel co-ordinate basis. (still using a bounding box for a block, no actual pixel collisions).
[/quote]
True, but surely you can stick with simple curves (like quadratics) at least until you want multiple simultaneous gravity sources etc?
Maintain a position or iterator in each list based on the current ball position, checking for collisions as you update the position of these iterators. You will know which block you hit by comparing the distance to the edges in the list that are around the iterator and within one ball radius. Just remember that if you are one ball radius or less away from the edge at the iterator, you must still check the next edge until you hit an edge that is farther than one ball radius from the current balls position.
Multiple balls mean multiple iterators in the edge lists.
You would have to use your own custom list structures and iterators likely.
Because you are only checking against edges near the ball you have much less checks than there are blocks and can often stop checking after only one edge if the first edge at the iterator position is already too far away.
your suggestions are focusing on making a faster and more effective collision detection. i alredy thought about using a quad-tree with sectors etc.
an important thing about my arkanoid is, that i dont want only to create a smooth arkanoid (who needs another one ?)
but to learn the main techniques about 2d-game programming. so i dont want to fit the code in all manors to the arkanoid topic, rather to build a little engine.
i have a little formula for the collision reaction of my ball of it hits a block or the paddel:
i need to know where exactly the ball hit the block so that i can change his angle in relation to this point, eg.: it hits the mid of the paddle it is going to reflect 0, but if it hits the right side-corner, it reflcets with perhaps 50
so im very ashamed about my very first solution (which hasnt changed yet =)
the ball isnt a real box, it is a circle of 8 hotspots arranged to a circular form. so if one of these spots collides with the edge of a block, i can exactly determine, where it collided.
both of you helped me a lot, but perhaps it would be more effective if you could see the applet and the source.
unfortunately my only web account doesnt permit applets.
so i can upload full scource (html / zip) or i could send it to you.
These calculations are super easy because the block edges are aligned to the coordinate system. the distance is always a simple subtraction of x or y coordinates depending on if you are checking against a vertical or horizontal line. The point of intersection is then always, one coordinate from the block edge and the other coordinate from the ball OR the endpoint of the edge line segment, if the hit is close to the block corner.
93ddb68554