Side Scrolling Fun V: Music, Levels, Bosses, and Media Managers

The next iteration of the side-scroller engine is up and running, and is almost starting to resemble an actual game. The first thing I did was find out why the game took so long to load. The answer was simple - I was being stupid: each instance of image and sound in the game was being loaded each time it was needed. In other words, I had roughly 3000 tiles consisting of one of 3 distinct images. When the level was loaded I loaded each image separately from the server, i.e. I downloaded ~3000 image per level, while in fact I needed to download three. To get around this, I wrote a ImageManager (iMan) class. Each time an Image is needed you ask the iMan for it and give it only the filename. The iMan checks its database to see if that file has been loaded yet. If it has, it returns a copy of the image, only if it has never loaded that image does it request it from the server. This lead to a tremendous speed-up in loading time and seems to work fine.

The next fish to fry was sound - both sound effects and soundtracks. I started by making a sound manager (sMan) similar to the image manager. Next I had some struggle with sound formats. Java doesn't care much for wav files. I basically had to tinker with the bit-rate, depth, etc. to get it to play, and I still don't know why some play and some don't. All I can say is that the java native sound engine is good, but finicky. As for sound track, I went for straight up midi which was a lot easier to work with. Currently, all the songs are ripped off from an awesome repository of nes roms that I came accross and I am starting to try to "compose the original score" :)

The next task was to create game states that allowed specific tasks to occur (ex. loading, player just died, player is playing, etc.) This allowed for an intro screen when the game was loading and cut-scenes between levels. This also allowed for animations and sound clips to run when the player dies or beats a level. The paint and run methods are then if-else statements based on the current state. The states are:

1. Intro
2. LoadIntro
3. LoadLevel
4. Playing
5. JustDied
6. Boss
7. JustPassed

The next improvement was the addition of levelguys, i.e. bosses. In boss mode a life-meter pops up displaying the boss' health as the gameState is set to "Boss". The screen also locks and the music changes. After the boss' energy reaches -1, the gamestate goes to justpassed and some celebratory music (currently from Duper Mario Bros.) plays. In order to mediate the timing of the cut-scenes, there is a variable tickCounter which is set when the game enters a given mode. When in this mode, each tick of the game loop reduces the tick-counter by one so that when it reaches zero, a new game state may be entered.

The boss can be seen here. He's (it's a dude) pretty easy and used for debugging purposes.



Here's screen shot of the the game in action: Click it to play!


The source code for this version can be found here. The "game" can be "played" here.

Twinkling Streetlights

If you ever look out over a city on a clear night, like on one of those 'make-out points' from cheesy 80's movies, you notice that distant streetlights seem to flicker and dance around a little, whereas closer ones don't. If your not making out with Winnie Cooper at the time, you inevitably start to wonder why that is the case. Notice that the same thing is seen in the sky: stars twinkle, but planets don't (the ones that wee can see, that is.)

The reason for the "twinkling of the stars" is what is called "atmospheric seeing": the atmosphere has layers of turbulent air of varying density and temperature, which leads to a time-varying index of refraction (The speed of light in a vacuum (outer space, say), divided by the speed of light in the material (air here.)) To see why this would make a star twinkle, recall that a lens is just a material of certain index of refraction, shaped in a certain way so as to focus (or diverge) light. The pockets of air blowing around the atmosphere, means that light from a star would rapidly become focused and unfocused as the air above blows around. This is kind of like the pattern you see on the sand, underneath shallow water: the light jumps around like crazy from being randomly bent at the surface. For water the effect is way more pronounced, since the index of refraction of water is about 1.33, whereas for air it's 1.0003 - just barely different than for a vacuum for which, by definition, it's 1. You can check how bad the current "seeing" is here.

So that's why stars twinkle, but then what about planets? The same "seeing effects" would be present for both planets and stars, but we only notice it for planets (actually, if you look through a telescope at Saturn or the Moon, you really start to notice the effects of seeing on a good night vs. a bad night.) The reason is that to us, stars come from a point in the sky - we can't resolve with our eyes what shape they are or what they look like. All our eyes know is that light is coming from one specific direction. When we see an object, say Winnie Cooper, her left ear is focused to one point on our retina, and her right ear is focused to another. That is, we can resolve the shape of the image. For stars, this is not the case: they're so far away that the left part of the star is totally smeared over with the right part of the star. Because light is wave, it can't be focused to an infinitely small point, the focus is limited (by diffraction) to a certain size, and for stars, this size is much bigger, that the size that they would be focused to on our retina. For planets however, we can make out the shape of them and although each point of the planet is experiencing this seeing effect, all of the combined effects average out into a steady (slightly blurred, if you look through a telescope) image. To verify this, we can to a rough calculation.

The minimum resolvable angular distance between two objects which are sent though a lens with diameter D is: sin(θ) = λ/D times some constant which is close to 1 and depends on the type of wave and the exact shape of the lens. For a plane wave through a perfectly circular lens, it is 1.22. For us, D is the diameter of our pupil, say 5 mm, at night. The wavelength of visible light is on the order of 600nm, so λ/D is about 10^(-4) which means that the minimum angle is about θ = 0.0001 (since sin(θ) is pretty much equal to θ when θ is so small.) Now by definition, sin(θ) = Dia/dist, where Dia is the diameter of the object and dist is the distance to it. We now have a test to see if an object is resolvable or not: if Dia/dist is bigger than 0.0001, it should be, if Dia/dist is much less that 0.0001, it's not (keeping in mind the roughness of the calculation.)

Several cases:

Mars: Dia = 6800 km, dist = 55000000 km, Dia/Dist = 0.00012
i.e It should just be resolvable.

Jupiter: Dia = 140000 km, dist = 700000000 km, Dia/Dist = 0.0002
i.e. Again, in the window of resolvability

α-Centauri (nearest star): Dia: 10^6 km, dist = 2*10^13 km, Dia/Dist = .0000005
=> much less that that of the planets.

Now, bringing this back to the original discussion, say that a street lamp has a diameter of about 10 cm. The distance at which it takes up about the same angle as a planet is: dist = Dia/θ = 1 km. Much farther than this, and the lights become point sources, like the stars. From where I live, the lights at the train-station 1 km from my place don't twinkle, but the lights on the ski-hill, 5 km away do. However, the giant billboards by the hill do not - they have a bigger Dia. and therefor are resolvable. These calculations were pretty rough, but they sketch out the main point - that the "twinkling" of stars and distant lights, stems from them being "point-sources" of light to our eyes.