|
We Won!
Click here to see our winning entry.
Inspired Logic was part of a team that created the winning entry for a multimedia contest run by Gunt. The contest was open to entries created with heavyweights like Director and mTropolis, and our entry, an interactive QuickTime sprite movie created with LiveStage, by Totally Hip Software, took the prize. Because the entry is a QuickTime movie, it's only 9k, and runs on Macs as well as PCs!
Special thanks to Gunt for running this--it can't have been easy.
Sometime in the last millenium, Gunt ran a multimedia contest. Click here to see the rules. This is the web page for an entry Inspired Logic helped create using LiveStage, by Totally Hip Software. LiveStage produces QuickTime movies, which can be very small--note that the entry is only 9k! QuickTime is a product of Apple Computer.
The current version of the entry is 1.4!
The entry is now (as I see it) entirely in conformance with the rules, as stated on Gunt's web page. The latest addition was to correct rebounds when sprites collide. Previously, the sprites simply exchanged momentums, which is entirely incorrect. Now when two sprites collide, momentum is exchanged (nearly) correctly. I say nearly because a square root function would help immensely.
You can see the current entry by clicking here--note that it is only 9k! You will need QuickTime to view it--I think 2.5 will do, but 3, 4, or 5 would be better. You can play it in anything that supports QuickTime, but I recommend Internet Explorer because it hogs processor cycles--the animation plays better in IE than in either Netscape Navigator or Movie Player. I submitted an IE page with the entry, to encourage the use of IE.
You can download the current version of the source here. The archive now includes the movie as well, since the whole package compresses to less than 20k.
The entry is open-source, in that anyone can download the entire source for the entry. You may use the source in any way you want, subject to the limitation that if you modify it, I'd like to see what you do with it. Comments, suggestions, and contributions are welcome. I will incorporate anything that makes sense into the entry. The deadline for the contest is May 31st. If you have something to contribute, or just want to ask a question or add a comment, email me at gcanyon@inspiredlogic.com.
The to-do list includes:
- Revel in victory!
Implemented features include:
Version 1.4 (Current)
- Wrote the documentation for the project.
- Changed the way the button worked to match the specifications. It originally just restarted everything, but on closer reading, it seemed the rules specified that it should first stop, then restart the animation, on subsequent pressing.
Version 1.3
- Got the sprite collisions to work properly, finally. It did turn out to be fairly simple, once looked at in the right way. It pays to have a physics text available! I had been going at things the wrong way because I was implicitly treating momentum as a scalar rather than a vector, which makes conservation of momentum a very difficult goal!
- Added initialization for the MIDI track, to avoid a performance hit when the first sprite hits a wall.
Version 1.2
- Figured out the slowdown because of the implementation of variables for the dimensions of the playing area. I used a counter for each sprite, which counts down the number of idles until the sprite will hit a wall. This should speed things up, because we only check one thing for each sprite each idle, instead of six. The code for situations where the sprite was moving to the left, or up (negative motion) was reversed, which meant that any sprite moving either left or up, it was not only doing the six calculations, but also resetting the counter repeatedly. UGH!
- Made further (bad) attempts at proper physics for sprite-to-sprite collision. Man, my physics is rusty. There's something I'm missing about this, because the code is coming out UGLY, and it's not doing to job.
- Changed spriteOfIndex references to spriteOfID, for readability and future utility.
Version 1.1
- Improved speed of the animation by further honing of the sprite-to-sprite collision detection code.
- Made a first (bad) attempt at proper physics for sprite-to-sprite collision.
- Added variables for the dimensions of the playing field. This inexplicable slows down the animation something fierce. I'll have to fix it, or remove it.
Version 1.0
- The movie is (I believe) in conformance with the rules! Yea!
- Added a black sprite in the lower right corner to restart the movie, and took that functionality out of the red ball. Is there a way to make transparent sprites take mouse clicks? Mine wouldn't, and as a result, I had to switch to the black sprite on the bottom layer. This looks okay, but it changes the index of all the sprites, and the code uses spriteOfIndex... :-( If the fact that spriteOfIndex(2) moves to x1 and y1 freaks people out, I'll change the names of all the variables.
- Michael Shaff threw down the gauntlet of optimization, and I picked it up a bit. Sprites now do no less than five tests to see if they are colliding. Each test bails out of the entire process, which means that if the first, simple, test fails (as it does most of the time) the rest are bypassed. The tests are:
- Are the sprites within 40 pixels horizontally?
- Are the sprites within 40 pixels vertically?
- Is the sum of the x and y differences less than 57? (This is roughly the square root of 2 times 40
- Are the sprites' centers within 40 pixels of each other? This is where the math starts to get ugly, but we rarely get here. This tests whether the sprites overlap.
- Are the sprites getting closer or farther apart. This is the ugliest math, but it only gets executed once for each sprite collision, or repeatedly if sprites overlap but are moving apart (which, aside from sprite initialization, is rare)
- I also did another optimization I'm pretty proud of: the tests for the four walls are simple, but they're a total of sixteen tests for four sprites every frame, so I figured out how to make them go away. Each time a sprite has a collision, it calculates, at its new velocity, which wall it will hit, and in how many frames. It then sets a counter to one less than that, and then just decrements it. This cuts twelve comparisons each frame. When the counter reaches zero, the sprite starts checking for the walls again. It doesn't keep track of which wall it's going to hit, so it starts checking all four, but it should only be a frame or two... It's on to beautifying and performance tuning...
Version .99
- Commented the daylights out of the code. Have a look. Figure out how to improve it. Let me know what you come up with. :-)
Version .9
- Pretty much matches the specs: 640x480, black background, four identically-sized objects of different colors, the objects are within the size parameters, the speed with which they move is within parameters (assuming the computer running the movie can keep up with the frame rate). The only thing I can think of offhands that doesn't conform yet is the restart procedure. (see item 7 on the to-do list below)
- Proper setup--one ball appears, then one ball for each impact, up to a total of four. The location of the creation of balls is per the rules. The rule that balls two through four be created "at the point of impact" is problematic: this guarantees overlapping balls. This version is designed to only collide overlapping objects that are getting closer, rather than getting farther apart, but it still tends toward "explosions" of balls that I don't think the contest designers intended.
- Good collision detection with the walls, with proper rebounds and one sound.
- Fair collision detection with other balls. Only one sound (as per the specs), non-realistic transfer of momentum. This may be affected by the rules,which require constant speed.
You can see the current entry by clicking here--note that it is only 9k!
You can download the current version of the source here.
 
|
|
