1.  10/06/2009, 06:09 PM I have a two comments on the physics of the game. One: We are playing the game from a view point that is above the game, it seems as from that view point, if any part of the ball touches a hole, it falls in. But in reality, the ball is only touching the game table at the center of said ball. Just to make sure you understand what I am saying. The ball is a sphere, only a small point at the bottom the sphere is actually touching the table. But in the game, from the view from above, the hole bottom half of the sphere is touching the table, so even if the edge of ball touches the hole, it falls in. Hopefully I explained that right, I had a hard time putting it into words. Two: It seems as if though the game is predicting, based off the the current trajectory, where it thinks the ball is going to be in a half second. If the ball is heading strait for a hole at a moderate speed, the ball jumps into the hole before it should actually gets there, by note worthy amount. I do not think it is merely the movement from one frame to another, because there is a lag between the last frame of being alive, and falling in the hole. If head towards a hole a slow enough speed, the ball does not jump into the hole. Great app, I look forward to its growing maturity.
2.  10/06/2009, 08:27 PM Originally Posted by fallen One: We are playing the game from a view point that is above the game, it seems as from that view point, if any part of the ball touches a hole, it falls in. But in reality, the ball is only touching the game table at the center of said ball. Just to make sure you understand what I am saying. The ball is a sphere, only a small point at the bottom the sphere is actually touching the table. But in the game, from the view from above, the hole bottom half of the sphere is touching the table, so even if the edge of ball touches the hole, it falls in. Hopefully I explained that right, I had a hard time putting it into words. Thank you very much for posting your feedback. I agree with you 100% on this. This is because the hit detection I used on the holes involves testing squares, not circles. I plan to change this. Imagine me drawing a small square about half the area that the holes and ball takes up, centering it in the ball and hole. I check if they intersect, and when they do, I suck the ball in. This is the way it currently does things. The way it should be changed to is checking if the center of the ball crosses the circle of the hole. I'm not sure why I did it the other way, but I've been aware of it and am planning to change it. Right now, though, I'm mostly focusing on the maze part of the game I'm working on. Originally Posted by fallen Two: It seems as if though the game is predicting, based off the the current trajectory, where it thinks the ball is going to be in a half second. If the ball is heading strait for a hole at a moderate speed, the ball jumps into the hole before it should actually gets there, by note worthy amount. I do not think it is merely the movement from one frame to another, because there is a lag between the last frame of being alive, and falling in the hole. If head towards a hole a slow enough speed, the ball does not jump into the hole. Well, there are a few things. At any given frame, the ball has a velocity and acceleration value. On each frame, I update the position based off of it's velocity, and then I update the velocity based on the acceleration. The magnitude is also determined by the length of time between now and the last frame. If all goes well, it will be 40ms (if the game is set to 25fps). Like in other games, the game goes at the same speed even if the framerate drops. The exception happens when the game would have lost 3 or more frames, it picks up as if 1 frame of time went by. I do this because the Pre seems to lag every now and then. I see this in my game, as well as other games like Riot, Blobber, or Super Dog. It is possible that the phenomenon you are describing happens because of a small loss in frame rate, it projects the ball further than you expect. Another possibility: I do hit detection just before I draw. If I see a hit, I apply the hole's "sucking-in force" and update the changes. In theory this can appear that there is a frame missing in time. That alone, or that in combination of what I said earlier could attribute what you are describing. I will look into changing some of that in order to make the game visually more natural. You may notice other things funky with the physics. As I stated in an earlier post, the long horizontal and vertical "holes" pull the ball to one side EXTREMELY fast. I draw them as a gradient in an attempt to make it seem like they were some kind of slide - thus making an excuse for me not to have to change the method I use for checking a fall - which is exactly the same as the small uniform hole. In some cases, like in the later levels, you can have the ball slide from one hole into the other and gain enough velocity to be ejected off the screen. You can even have the ball fall in a hole and roll out if you hold it vertical and it's going fast enough. Also, if you have "game walls" enabled, you'll notice the ball is really hoppity if you hold the device vertical. This is my first game and I'm new to a lot of this, so I just need to sit down and figure things out in order to smooth them Thanks again for your comments!
3.  10/06/2009, 09:35 PM Great game. Don't know if it was mentioned, but the scoring is a little funky at times. For some reason, frequently when I would lose my last ball on level 8, I would have a much higher score than when I would finish on level 9. I would have to make it to level 11 to beat that score. Took me about 20 tries to make it through. Best accellerometer game on the pre to date. Attached Images toppleball_2009-06-10_211151.png (36.5 KB, 19 views)
4.  10/07/2009, 07:45 AM Originally Posted by amateurhack Don't know if it was mentioned, but the scoring is a little funky at times. For some reason, frequently when I would lose my last ball on level 8, I would have a much higher score than when I would finish on level 9. I would have to make it to level 11 to beat that score. Nice job on level 20. The reason for the score fluctuation is because you get a higher score the faster you complete a level. toppleball_2009-07-10_074624.jpg
5.  10/07/2009, 07:33 PM Originally Posted by MrJspeed Thank you very much for posting your feedback. I agree with you 100% on this. This is because the hit detection I used on the holes involves testing squares, not circles. I plan to change this. Imagine me drawing a small square about half the area that the holes and ball takes up, centering it in the ball and hole. I check if they intersect, and when they do, I suck the ball in. This is the way it currently does things. The way it should be changed to is checking if the center of the ball crosses the circle of the hole. I'm not sure why I did it the other way, but I've been aware of it and am planning to change it. Right now, though, I'm mostly focusing on the maze part of the game I'm working on. Well, there are a few things. At any given frame, the ball has a velocity and acceleration value. On each frame, I update the position based off of it's velocity, and then I update the velocity based on the acceleration. The magnitude is also determined by the length of time between now and the last frame. If all goes well, it will be 40ms (if the game is set to 25fps). Like in other games, the game goes at the same speed even if the framerate drops. The exception happens when the game would have lost 3 or more frames, it picks up as if 1 frame of time went by. I do this because the Pre seems to lag every now and then. I see this in my game, as well as other games like Riot, Blobber, or Super Dog. It is possible that the phenomenon you are describing happens because of a small loss in frame rate, it projects the ball further than you expect. Another possibility: I do hit detection just before I draw. If I see a hit, I apply the hole's "sucking-in force" and update the changes. In theory this can appear that there is a frame missing in time. That alone, or that in combination of what I said earlier could attribute what you are describing. I will look into changing some of that in order to make the game visually more natural. You may notice other things funky with the physics. As I stated in an earlier post, the long horizontal and vertical "holes" pull the ball to one side EXTREMELY fast. I draw them as a gradient in an attempt to make it seem like they were some kind of slide - thus making an excuse for me not to have to change the method I use for checking a fall - which is exactly the same as the small uniform hole. In some cases, like in the later levels, you can have the ball slide from one hole into the other and gain enough velocity to be ejected off the screen. You can even have the ball fall in a hole and roll out if you hold it vertical and it's going fast enough. Also, if you have "game walls" enabled, you'll notice the ball is really hoppity if you hold the device vertical. This is my first game and I'm new to a lot of this, so I just need to sit down and figure things out in order to smooth them Thanks again for your comments! Thank you for being human about it.
6.  10/08/2009, 11:58 AM Originally Posted by MrJspeed Nice job on level 20. The reason for the score fluctuation is because you get a higher score the faster you complete a level. toppleball_2009-07-10_074624.jpg Regarding the scoring, a couple issues. When the game is paused the score continues to 'count down' for the current level. Similarly when the game lags momentarily in the middle of the level the score will be lower than it would have been with no lag. The second issue is more subtle (and probably harder to fix?) but still a little annoying if you're playing to beat your own high score. Fantastic game all around though.
7.  10/08/2009, 01:58 PM Originally Posted by jjthe2 Regarding the scoring, a couple issues. When the game is paused the score continues to 'count down' for the current level. Similarly when the game lags momentarily in the middle of the level the score will be lower than it would have been with no lag. The second issue is more subtle (and probably harder to fix?) but still a little annoying if you're playing to beat your own high score. Fantastic game all around though. great catch. I can fix both of those issues next release.
8.  10/10/2009, 11:28 PM Any possibility of being able to change the table from wood to something else like stainless or other backgrounds?
9.  10/11/2009, 12:48 PM My best score so far is 1327 on level 20. I love this game!
10.  10/11/2009, 02:38 PM Originally Posted by caseyatbt Any possibility of being able to change the table from wood to something else like stainless or other backgrounds? that's a good idea. I might do something like that. Originally Posted by cwgtex My best score so far is 1327 on level 20. I love this game! get 1337 and you'll really be awesome!
11.  10/11/2009, 02:45 PM Great game! Thanks
12.  10/11/2009, 07:30 PM Obviously the best game developed for the Pre, to date. This is one of the only apps that make me feel like I'm not playing with a step down to the iPhone. Please not only continue to enhance this game, but also offer more in the family. Ideas: Putt Putt Golf? Some sort of board game like Chutes and Ladders Bowling Fishing
13.  10/12/2009, 02:08 PM I just want to say this is one of my favorite apps and I can't wait for your updates. I didn't read all the posts, but one thing I noticed is while you are playing the game and the phone is set to vibrate, the game still plays the sounds. Do you plan on changing this in the future?
14.  10/12/2009, 02:21 PM Originally Posted by slp15 I just want to say this is one of my favorite apps and I can't wait for your updates. I didn't read all the posts, but one thing I noticed is while you are playing the game and the phone is set to vibrate, the game still plays the sounds. Do you plan on changing this in the future? Should an app's audio settings be tied to the phone's vibration settings? Wouldn't that mean apps like Pandora should not allow audio play while the phone's in vibrate? I think the vibration setting should be strictly for whether phone calls or other notification alarms produce audible alerts.
15.  10/12/2009, 02:32 PM Originally Posted by caseyatbt Any possibility of being able to change the table from wood to something else like stainless or other backgrounds? +1 Uniden PC100 -> Visor -> Visor Pro w/VisorPhone -> Tungsten T -> Tungsten T2 -> Tungsten T5 -> TX -> Treo 650 -> Treo 755p -> Pre -> Evo 4G
16.  10/13/2009, 01:05 PM My favorite game on the Pre!
17.  10/13/2009, 01:31 PM Just an update on my progress... I've decided to make the "Maze" game into a different app, I'll probably have it on PreCentral in a few weeks depending on my free time to code. As for Topple Ball, I will be posting the next version by the end of the week. I've been doing a lot of changes/additions, a lot of them behind the scenes. I can't think of everything I've changed at the moment, but the major changes are: - Topple Ball will be Pixi compatible - There be a choice of game board backgrounds (Wood, Steel, Concrete, and Carbon Fiber) - There will be a new obstacle as well as several other small things. Stay tuned.
18.  10/13/2009, 01:37 PM Originally Posted by MrJspeed Just an update on my progress... I've decided to make the "Maze" game into a different app, I'll probably have it on PreCentral in a few weeks depending on my free time to code. As for Topple Ball, I will be posting the next version by the end of the week. I've been doing a lot of changes/additions, a lot of them behind the scenes. I can't think of everything I've changed at the moment, but the major changes are: - Topple Ball will be Pixi compatible - There be a choice of game board backgrounds (Wood, Steel, Concrete, and Carbon Fiber) - There will be a new obstacle as well as several other small things. Stay tuned. I think having the maze game as a separate app is a good idea. Just because the game involves a ball moving around with the accelerometer, it doesn't mean it belongs in the "Topple Ball" app. You know what would be cool would be if the different backgrounds/surfaces actually affected game-play. For instance, ice would make the surface slippery. But on second thought, I think this would be more suited for a maze game.
19.  10/13/2009, 01:49 PM Originally Posted by DanPLC I think having the maze game as a separate app is a good idea. Just because the game involves a ball moving around with the accelerometer, it doesn't mean it belongs in the "Topple Ball" app. You know what would be cool would be if the different backgrounds/surfaces actually affected game-play. For instance, ice would make the surface slippery. But on second thought, I think this would be more suited for a maze game. I've considered adding something equivalent to "oil slicks" or "tar" on Topple Ball to change the board's drag in certain areas. A target goal in the middle of a plane of slick oil would be more challenging to hit.