Still not there yet, but it feels like progressing. I’ve been working on my ball to ball to border collision algorithm for the game Bolas. With Bolas I found complicated situations, which I am trying to test now.

The video shows three tests:

The first test is a blue ball lying against the border, which is hit by a red ball. The video shows that the stationary ball will start moving after the hit.

The second test is a blue ball lying in the corner, while being hit by the red ball at an angle of 45 degrees. The blue ball is played out of the corner with success.

The third test, in which the red balls are lined up and the blue ball hits them, this test ends in an infinite loop, which is why the animation stops.

The first and second tests look confident, though I changed something in the code which makes me wonder how it is possible that they do work. It is usually easier to find out why something does not work, while it is harder to find out why something actually does work.

To be precise, if the current state of my code would be working properly, the first two tests should fail, while the third test should stop after the blue ball hit the red one. Why? Because I play all collisions within a frame, in the order that they occur.

In a correct working of this scheme, the following should happen (referring to test 1):
1. Red Ball hits Blue ball and registers a new collision;
2. Collision from step 1 is handled;
3. Re-detect collisions results in a new collision, at the same moment as step 1, from the blue ball hitting the border;
4. Collision from step 3 is handled;
5. Re-detect collisions results in a new collision, at the same moment as step 1, from the red ball hitting the blue ball;
6. Collision from step 5 is handled;
7. Re-detect collision results in a new collision, at the same moment as step 1, from the red ball hitting the border;

At step 7, we’re actually back at step 3 – an infinite loop. This is why test 1 and 2 should fail, and test 3 should be in an infinite loop after the blue ball hits the red ball. So the current state of the code is still not working. The reason why the tests do work, is because time is increasing. Step 3,5,7, the collision moment is not at the same time as it is in step 1. As a result of this, the balls sometimes overlap.

Now nobody wants an infinite loop, but I regarded this as a problem to be solved later. Well, let’s get this scheme working first.

For the fun of it, here a little video demonstrating the current features in Slengo:

The above is my testing level, so whenever I add a feature to the game, I put it into this level to test it. So it is not very strange that you see the same level over and over again in the video.

The current features. The enemies find their way through the maze, they can smash the icecubes and follow the player. There are some bonusses in the game, some for points, others to improve the player's powers. The enemy can be delayed before it hatches. The borders paralyzes the enemies touching it.

As you can see, currently there is only one enemy. I am currently working to add more enemies, however one enemy-type per level will not be feasible.

I was exploring the idea of adding a SeuJogo bumper to my games. When a game has loaded, a little movie is displayed about the manufacturer, before the titlescreen of the game being displayed. Many online games have such a movie. It helps to remember the manufacturer’s name.

For the bumper not to get irritating, it must be a short visual sequence and it may not consume too much bandwidth. There are two options. Either you create some sequence with images, while your software is in charge of moving the images around. Or you create a little movie in which you do all the displaying. It is obvious that a software movie consumes less bandwidth than a real movie, but with a real movie you can do much more.

I created a short movie for the test. The original movie size is 78 Mb, uncompressed, with a resolution of 320x240. Using Windows Media Encoder it became 214 Kb, with a resolution of 160x120. A further compression would heavily destroy the quality.

That’s what it all is about, quality versus bandwidth. The bumber is shown in the player below. Its only 8.5 seconds and has no sound. Still, for a first movie made ever, I think the result is not that bad.