When developing a game, at some points you need to face the truth why your idea is not working. Well, I’ve been developing a shooter game, based on a C64 game of which I don’t remember its name. I liked the game back then and the graphics in the original are somewhat simpler then my approach.

This is the result:

What is wrong with this game? Well, the movie demonstrates exactly what is wrong. The world is based on 3D coordinates, which are translated to 2D using perspective projection. And this is very hard to play. As the movie shows, when the player is to the right and shoots, the fire-balls do not go straight up to the horizon, the follow a perspective diagonal line, tilted to the left. When shooting at the left side of the screen, the problem is vice versa. Only when the player is at the middle of the screen, the bullets go straight up.

The game would be more playable when the player’s bullets would go up all the time, as like in the middle of the screen. The bullets would follow a path of parallel projection, where the position on the Z-axiz (into the screen) would be a factor of the Y-axis (vertical).

But do players buy this? The “ground” could be in perspective projection, like it is now, but bullets follow a parallel projection path? Gamers would probably buy it, because like television, games are lies.

There is more wrong with this game, things that fall in the category “not finished so don’t complain”.

It is these moments one could give up the whole idea and declare the invested energy as a waste of time. However, you can also look away from it, and get back to it again later with better ideas. I guess it is part of the creative process.

Back in 2008 I wrote my first Silverlight game, in Silverlight 1.16 Beta. However, the game was never published because it had bad collision detection bugs. I spend a lot of time trying to fix this, but I didn’t succeed. Later I got an idea how to approach the ball to ball collision theme in a different way, but highly unmotivated, I started writing other games. Which is somehow a pity, because I think Bolas is a fun game.

Anyhow, I picked up the challenge now about two years later, introducing the collision detection scheme I was thinking of. First, let’s start with the research I’ve done until now.

I translated a Flash implementation of ball to ball collision from Flash action script found in this article. This script detects a collision and handles it. A known problem with this algorithm is that at some point, the balls will clutter together. If you have balls with different radii, this problem will occur sooner than when all the balls have the same radius. As I use different radii for Bolas, the problem occurred to me very quickly.

Another article from Gamasutra gave an algorithm plus code, to do a more accurate collision detection and handling. I implemented this, but at hot spot moments, it still failed. The reason for failure was that my algorithm did not consider multiple collisions within one frame. I tried to solve this, however my approach was simply bad, because I did not understand the problem.

However, I did understand one thing. If I have a series of touching balls in a straight line, and I bounce a moving ball against it, within the same line, the ball at the other end should move, while the others remain stationary. My algorithm could not handle this situation. Why? Because my approach was frame-to-frame oriented. My error was that things happening within a frame were unordered.

How is that? Well, a game-loop is typically based on frames, i.e. moments in time when the screen of your monitor is painted. In a game-loop, you reorder your visuals for the next frame to be painted. So if you calculate and handle all detected collisions for the next frame, you are missing information. Because handling one collision in a frame, could cause another collision within the same frame. So if you have three balls, A, B and C, a collision handling between A and B, could cause a new collision between B and C. If not handled correctly, this will cause errors in your collision detection and handling.

My new approach in calculating the next frame is to play whatever happens between the previous and the next frame. So:
1) If collisions are detected at X% of the frame time, then:
2) The balls are moved with X% of their speed;
3) The collisions are handled;
4) Run collision detection for the current and remaining (100-X)% of the frame
5) If step 4 resulted in collisions, then goto step 1 for new collision detections;
6) Else, move the balls for the remaining frame time

Because of step 4, a collision handling at frame time X, may cause new collisions for this same frame time X, which will be handled in the next iteration (the “goto 1” in step 5). Note, the above algorithm is more difficult to implement than described! A line of balls situation, described above, must be handled with a ball speed threshold. Suppose the speed of a ball becomes lower than a certain value, then the speed must become zero, to break infinite loops.

I haven’t figured everything yet, but let’s start with the simplest implementation. Moving balls which don’t lose speed, and which only bounce against the borders of the screen. It looks simple, but it was hard enough. A collision to one border is registered as one collision. Things happening within one frame are handled in order of time. This is not the ordinary bounce against borders and reverse the x or y parameter of the speed vector. Each border is a collision and handled accordingly.

Microsoft Director Brad Becker, recently published an article about the Future of Silverlight. Becker gives a decent argument why there is space for Silverlight on the planet, even though HTML5 is coming.

I would approach the argument from a simpler angle. Back in 1997, Java was only one year old. Evangelists predicted that Java would be on every thinkable device on the planet, even your refrigerator. Java would also conquer the Desktop. Well, Java was useful in many ways, but absolutely did not conquer the Desktop. Being platform independent, Java could not support the rich Windows features, which weren’t available in e.g. X11. Java didn’t conquer the desktop, because it supported a platform common denominator.

That’s the problem with being on many platforms, you can only support a smaller feature set than the richest platform.

Flash was ported to many platforms, taking Flash’s own features to the new platform. Silverlight is taking the same road. While a standard like HTML needs to be available on any platform, Adobe and Microsoft are the ones who choose which platforms they want to support; keeping the weak platforms out of the game.

So in this constellation, HTML5 will always be average, compared to Flash/Silverlight, which are designed to be excellent. And that is really all there is to it.

People like excellence, while developers – not normal people – like standards. As excellence sells, I expect that HTML5 will never be a killer for Flash/Silverlight.

Thanks to Silverlight’s powerful clipping features, it is incredibly simple to create a triangle sliding volume control.

1) Create a Canvas, which contains all visuals;
2) Create a rectangle for the background within the Canvas. Width=100, Height=50. Here, the background is green;

3) Create a rectangle for the slider, on top of the background. Height=50, Width is smaller than 100 to show that this red rectangle is on top;

4) Create a clipping on the Canvas which contains the rectangles;

The clipping XAML defines the rectangle path:

Note that Blend converts the above to a more compact format, but this is not a problem. The path starts at the left-bottom corner, then via a line segment, it goes to the upper-right and then to the bottom-right. The bottom line segment is not required thanks to the “IsClosed” setting.

5) Create a border around the volume control. A part of the clipping geometry is copied for this, into a Path control. The XAML for this path control needs to be inserted below the XAML of the red rectangle, so that the border is on top:

Note that Blend will convert this Path figure into something more compact, which is no problem if you are satisfied with it.

6) Now that we have the visual part ready, it is time to implement the code behind. First, give names to your controls. The green background gets the x:Name=“Background”, the red slider gets the x:Name=”RedRectangle”. In Visual Studio, both green and red rectangles need mouse events. For both rectangles, these mouse events are wired to the same function.
Add these mouse event attributes to both rectangles:

7) Implement the mouse events:

Explanation:

The mouse-move event should only work when the mouse button is clicked, so the mouse-down and mouse-up events set a variable “clicked”. When clicking, the slider’s position should be adjusted right away, so in the mouse-down event the SetVolumePosition function is called. We are interested in the horizontal mouse-position, relatively to the green background rectangle, as this is our origin. The SetVolumePosition only sets the width of our sliding red rectangle.

Finished!

Up till now I’ve been using the file extension XZ for compressed XAML vectors (Xap, Zipped - chosen uncarefully). But someone was Googling on “XZ”, not finding what they expected because XZ stands for compressed archives under Unix. So from now on, I’ll be using the file extension “CVF”: Compressed Vector Format.

A few days further, I’ve been very busy testing my CVF technique with different images. As expected, these tests had different results. In some cases, it pays to use the vector compression technique over PNG-24 or PNG-8. In some cases, the result of the compression can be larger than a PNG-24 original. It all depends on how much detail the picture has, whether the subject of the image has hard or smooth edges, and which optimization choices you make. So sometimes it works fine, and other times it is the worst option.

But CVF can be an option. I had the most amazing result with the graphic for the vertical bar in the game Slengo. The playing field is bordered by thick blue lines. If the player pushes these thick borders, they will paralyze all enemies which are next to the border. An animation is played, making the border more elastic for a while. This animation is making the graphic for the vertical borders very large in size: 117Kb (PNG-24). Converting this image to a PNG-8 format results in 61Kb. Lastly; I have scanned the PNG-24 vertical bar graphic with Inkscape, saved XAML and converted it to CVF. The result file is 47Kb, which can be Winzipped to 24Kb, in the XAP file. Compared to the original 117Kb, this is a reduction of 79%. The vertical bar is one of the largest images in the game, so it sure counts for download time.

Now for clouds. I wanted a cloudy background for a new game I’ve been creating, and I wanted this the easy way.

So I took clouds from Brazil:

I removed the scene and cropped the image to get clouds in the sky and forming clouds at the horizon. I filtered the result to give it a little more atmosphere. The result:

The PNG-24 version is 59.2Kb. The PNG-8 version is 17Kb. I have traced the PNG-24 with Inkscape, saved XAML and converted to CVF, not paying much attention to optimization. The result CVF file is 82Kb, which may be Winzipped to 38Kb. So the CVF version is smaller than the PNG-24 version and larger than the PNG-8 version.

I decided to test both in my game. Opacity is set to 0.5, to let the sky-background influence the cloud’s appearance.

Image above: The CVF-clouds are quite fluent, not much detailed, so a real part of the background which does not draw too much attention, while still pleasing.

Image above: The PNG-8 version of the clouds is much more detailed, making them a little more realistic. It’s nice, but the style does not match the rest of the game, which is more surrealistic.

Ofcourse we can do more image processing to smooth the PNG-8’s edges, making it look more like the CVF version. And we can do more optimizations on the CVF version, to decrease quality and filesize. That’s a decision to make later. Still it’s nice how the two compare.

The little blob in the centre of both images is an enemy helicopter. This helicopter uses CVF images only. PNG-8 was unsuitable to use for the helicopter, because they had a weird white border around the helicopter, which I was unable to remove. I have encountered this problem more often with PNG-8's, which is why I've been using PNG-24 all the time. The first versions of the CVF also had a strange white border round the helicopter, but I removed them by adjusting the trace options in Inkscape. The result is quite satisfying.