I decided to do this.
OK guys, what are we making?
Offline
Bump. Only 5 more days to submit a beta!
Offline
Vote.
Scimonster: 1
applejack: 1
EDIT: amcerbu, would we show the math? We want this to have something to do with math.
Last edited by scimonster (2011-08-10 11:10:30)
Offline
You mean a story about a pool game as you play it? "applejack broke... and nothing went in! Now it's scimonster's turn, he seems to be going for the 13.. but he got the 11 in instead!"
amcerbu wrote:
Collab thing? How about a game or something. I know how we could make 8-ball.
Last edited by applejack (2011-08-10 11:16:36)
Offline
Anyway, I'll upload the images to my account in a few minutes.
EDIT: Here's the link:
Pool Sprites
Last edited by amcerbu (2011-08-11 13:47:07)
Offline
YAY!
amcerbu wrote:
Anyway, I'll upload the images to my account in a few minutes.
EDIT: Here's the link:
Pool Sprites
Offline
Nice sprites. Who's going first? I'll try to get something, but I'm not so good at the trig that's needed.
Offline
I'm not going to be able to help, so: Good luck!
PS Please don't mention me in the credits, I didn't help...
PSS Remember, it's a story, not a game. How's pool a story?
Last edited by Hardmath123 (2011-08-12 11:26:46)
Offline
Maybe this won't be for collab camp, but just another Xenon project. Hardmath is right- pool's not really a story. If you guys want to do something for the "official" collab challenge, let's put this on hold for a bit.
Otherwise, I've thought a good bit about how this project should work. The main problem we will have to deal with is collision detection.
A standard game of 8-ball includes 16 balls: the white cue ball, 7 solids, 7 stripes, and the 8 ball. That means that in each frame, Scratch will have to test a total of...
15+14+13+12+11+10+9+8+7+6+5+4+3+2+1 = 120 possible collisions! (each ball can collide with any ball except itself)
In my "Elastic Collision Multi" projects, I used a list that stored all possible collisions between any two balls. For five balls, the list would read...
1 2 1 3 1 4 1 5 2 3 2 4 2 5 3 4 3 5 4 5
Each set of consecutive members represents two "names" of balls (since I stored their positions and velocities in lists, "1" would be both the name of the ball, and the location in each list that held 1's data).
Unfortunately, Scratch's repeats are simply too slow to iterate through 120 possibly combinations. So, we are presented with two options:
Option 1: Hardcode everything. This would be an incredible hassle, considering that we would end up assembling code for 120 collisions. The possibility that we made a mistake would be large, and additionally, every time a ball sinks, we will be testing unnecessary collisions. The one advantage is that it doesn't require the use of turbo mode, so it would be more accessible.
Option 2: Use Flash turbo mode. This solves a number of our problems (I know for sure that my "Elastic Collision" project works fine in Flash turbo with 16 objects). The only thing we need to deal with is framerate, so a "wait 0 seconds" block might be placed before drawing each frame, to prevent the undesirable effect of only seeing the final frame, after collisions have occurred. In addition, we can delete unnecessary items from the collision list as the game goes on and balls are pocketed.
Tell me what you think.
Offline
Option 3: Use sprites...
amcerbu wrote:
Maybe this won't be for collab camp, but just another Xenon project. Hardmath is right- pool's not really a story. If you guys want to do something for the "official" collab challenge, let's put this on hold for a bit.
Otherwise, I've thought a good bit about how this project should work. The main problem we will have to deal with is collision detection.
A standard game of 8-ball includes 16 balls: the white cue ball, 7 solids, 7 stripes, and the 8 ball. That means that in each frame, Scratch will have to test a total of...
15+14+13+12+11+10+9+8+7+6+5+4+3+2+1 = 120 possible collisions! (each ball can collide with any ball except itself)
In my "Elastic Collision Multi" projects, I used a list that stored all possible collisions between any two balls. For five balls, the list would read...Code:
1 2 1 3 1 4 1 5 2 3 2 4 2 5 3 4 3 5 4 5Each set of consecutive members represents two "names" of balls (since I stored their positions and velocities in lists, "1" would be both the name of the ball, and the location in each list that held 1's data).
Unfortunately, Scratch's repeats are simply too slow to iterate through 120 possibly combinations. So, we are presented with two options:
Option 1: Hardcode everything. This would be an incredible hassle, considering that we would end up assembling code for 120 collisions. The possibility that we made a mistake would be large, and additionally, every time a ball sinks, we will be testing unnecessary collisions. The one advantage is that it doesn't require the use of turbo mode, so it would be more accessible.
Option 2: Use Flash turbo mode. This solves a number of our problems (I know for sure that my "Elastic Collision" project works fine in Flash turbo with 16 objects). The only thing we need to deal with is framerate, so a "wait 0 seconds" block might be placed before drawing each frame, to prevent the undesirable effect of only seeing the final frame, after collisions have occurred. In addition, we can delete unnecessary items from the collision list as the game goes on and balls are pocketed.
Tell me what you think.
Offline
Only two more days! I'm going to try my idea, a story about a kid who learns to like math. It will be interactive in the way that the user can try out the same thing the guy is.
Offline
If you need graphics...
scimonster wrote:
Only two more days! I'm going to try my idea, a story about a kid who learns to like math. It will be interactive in the way that the user can try out the same thing the guy is.
Offline