I've been working on "BlockBreaker" again, and having considerably troubles. I haven't been able to clear up the blurry/choppy movement of the ball. Further, even after spending a whole day on collisions detection, it still isn't where I want it to be. After some considerable improvements to it, I am now to the point where I'm looping through all of the objects and testing them for collision with the ball. This obviously isn't correct. I will have to learn how to find the nearest block and only test that one. So there is more learning to do.
Besides the problems, the game is working very well. Collision works great when the ball does not strike more than one block at the same time. I can't simply calculate 'first hit', because the first hit may not be the closest.
I want to clear up the problems, but I'm also happy with the progress. The game needs sound and a graphical tweaking. The only real engine coding left to do is high score and the transition between levels.
I've actually considered designing an rpg style breakout game, similar to Puzzle Quest. Breakout does not need to consist only of hitting a ball with a paddle.
Tonight for my coding time, I'm going to look into finding the nearest block, and then into smoothing the ball animation. Maybe I'm still timing everything wrong.
Monday, October 19, 2009
Monday, October 12, 2009
Work on Break Out
This weekend I pulled a version of Break Out I started in 2001 off of a really old backup CD and checked it into my subversion repository.
I learned quite a bit by reviewing the source code. Most importantly was that there wasn't much code at all. This was a single Java file along with a matching HTML to show the applet. This was important for a number of reasons; the first being that it did not seem to contain as much effort as I remember. Reading the code I realized that it probably was only a few hours work, if that much. The size of the code struck home to me that I did not put as much effort into these early projects as I had thought. I seemed to have given it a bit of a try, and then moved on.
The source code for this old breakout, did not user any kind of timer, it simply ran and painted as many times as the main loop could run; it was timed by the Thread.sleep(x) method. Input was also handled by a direct input method; pressing the right arrow button moved the paddle to the right by it's acceleration. Further the constants for the states were defined, but there were no states. I couldn't help but wonder if this wasn't the latest version of this source code, since I did not have a repository back then.
I decided that this was one of those projects that should be completed. At first I simply cleaned it up a bit and it became a fun little game. Of course, this reached a point where I had simply made 1,000 lines of horrible source into 400 lines of alright source, that simply played the same half-game. From there I added my KeyWatcher, MouseWatcher and Timer classes to the mix; introducing a real game loop, better input and locking into 60 fps. I know based on my recent reading that this still isn't the optimal way to handle frames, but it's block breaker and it will never be heavy on the cpu, etc.
I stopped there and got it checked into subversion, then made a page for it on my private wiki. After writing out a bit of a design, I returned to the code and tore out all of the game objects. Although component (aggregate) based game objects are all the rage, I went with a simple hierarchy involving a base class and an extension for each of the types I would need. Proper state was added, and not based on constants.
I spent the rest of the weekend working on collision detection and resolution. I have never really tackled this problem; I've always tried to do a simple approximation of things bouncing and it has never worked. There was a considerable amount of contemplation on the effect of this on other projects. How many projects had failed or been abandoned because I couldn't get this part right?
This weekend I forced myself to sit and do the reading, review the math, and correctly bounce the ball off the walls, bricks and paddle. With this done I was very proud and felt like I was finally approaching projects correctly. I still need to go back and group bricks (two bricks next to each other shouldn't run a separate collision), as well as add a coefficient of friction to the paddle.
The game needs graphics, sounds, actual stages (it just has one) and some fine tuning, but it is hardly the toy script I recovered from the CD.
It's good to be picking up old projects and finishing them.
I learned quite a bit by reviewing the source code. Most importantly was that there wasn't much code at all. This was a single Java file along with a matching HTML to show the applet. This was important for a number of reasons; the first being that it did not seem to contain as much effort as I remember. Reading the code I realized that it probably was only a few hours work, if that much. The size of the code struck home to me that I did not put as much effort into these early projects as I had thought. I seemed to have given it a bit of a try, and then moved on.
The source code for this old breakout, did not user any kind of timer, it simply ran and painted as many times as the main loop could run; it was timed by the Thread.sleep(x) method. Input was also handled by a direct input method; pressing the right arrow button moved the paddle to the right by it's acceleration. Further the constants for the states were defined, but there were no states. I couldn't help but wonder if this wasn't the latest version of this source code, since I did not have a repository back then.
I decided that this was one of those projects that should be completed. At first I simply cleaned it up a bit and it became a fun little game. Of course, this reached a point where I had simply made 1,000 lines of horrible source into 400 lines of alright source, that simply played the same half-game. From there I added my KeyWatcher, MouseWatcher and Timer classes to the mix; introducing a real game loop, better input and locking into 60 fps. I know based on my recent reading that this still isn't the optimal way to handle frames, but it's block breaker and it will never be heavy on the cpu, etc.
I stopped there and got it checked into subversion, then made a page for it on my private wiki. After writing out a bit of a design, I returned to the code and tore out all of the game objects. Although component (aggregate) based game objects are all the rage, I went with a simple hierarchy involving a base class and an extension for each of the types I would need. Proper state was added, and not based on constants.
I spent the rest of the weekend working on collision detection and resolution. I have never really tackled this problem; I've always tried to do a simple approximation of things bouncing and it has never worked. There was a considerable amount of contemplation on the effect of this on other projects. How many projects had failed or been abandoned because I couldn't get this part right?
This weekend I forced myself to sit and do the reading, review the math, and correctly bounce the ball off the walls, bricks and paddle. With this done I was very proud and felt like I was finally approaching projects correctly. I still need to go back and group bricks (two bricks next to each other shouldn't run a separate collision), as well as add a coefficient of friction to the paddle.
The game needs graphics, sounds, actual stages (it just has one) and some fine tuning, but it is hardly the toy script I recovered from the CD.
It's good to be picking up old projects and finishing them.
Subscribe to:
Posts (Atom)