In our two week Flash project titled The Perilous Paint Project, the player explores invisible worlds, using paint to reveal their surroundings. Our team brainstormed multiple methods to apply the paint: the artists could make splatter images that would be placed on top of the objects, or each object could have different states that corresponded to different levels of paint.
Ultimately, it was proposed that we could have a dynamically generated image that will generate a random splatter effect at the collision point whenever an object was hit. It took much more work to pull off, but the result was rather compelling - using the paint became one of the most fun parts of the game. In this article, I’ll go into how the effect was achieved.
When designing the painting mechanic, I tried my best to not get in the way of the artists and the producers. There was no extra effort required on their part to get the paint working in the level. As a result, everything about the paint was done dynamically, from setup to runtime. When the game is run, the paint system follows three steps to create the paint splatter effect.
Step 1: Create the Bitmap
The first step is to create a bitmap that can be drawn to. The first thing I tried was to create a bitmap that matched the bounding box of the objects in the level. However, the objects could be any arbitrary shape, and I didn’t want paint to show up where there was not an obstacle. Luckily, Flash has a very powerful masking system built in, so I was able to duplicate the level object and use it as a mask for the bitmap. Here’s a view of the game in debug mode to demonstrate the difference:
Step 2: Detect the Collision Point
To bounce the balls around the level, a physics system was needed. While it’s too much to go into that system in this article, I’ll mention it because the paint system needs to know where the ball collides to first generate the splatter. In the game, colliders are made up of lines made with the pen tool in the Flash editor. This allows the designer to make whatever shape collider that’s necessary. When the ball crosses any of the lines, a collision is resolved and a splatter is created at the collision point. Here you can see a table in the game with its collider next to it:
Step 3: Generate the Paint!
The paint is generated with a very simple algorithm that has many parameters. When a paint splatter is created at a collision point, it creates 8 splatter instances that each update independently. Each time the splatters update, their positions move and their sizes get smaller. Each time a splatter is drawn, it draws a circle. That’s it. The splatter pattern is the result of a bunch of circles being drawn on top of each other. There are many different options that will randomly modify each splatter:
- Number of splatters generated
- Min and max starting velocity
- Min and max acceleration
- Min and max starting size
- Min and max rate of decay of the size
- Min and max number of total updates
- Min and max delay between draw times
There was a lot of risk in trying to get a system like this working in a two week development cycle. But that’s kind of the point of a rapid prototype - if it works, then celebrate, and if not, then on to the next prototype! In this case, it was a cause for celebration, and I hope my next project will be the same.
You can watch some gameplay below: