I ended up throwing away the genetic algorithm and instead implementing a basic flood-fill selection with a twist.

Basically, the algorithm iterates through the image doing flood fill. The difference is, instead of four or eight connectivity, the algorithm selects a window of size n around the pixel. Additionally, instead of filling in the paint in those regions, it instead selects the pixels and pushes them onto a list. This collection of pixels of a similar color is called a step. The steps are then sorted by their length, from largest (longest, really) to smallest. In doing so, it looks as if fake Bob Ross is painting the big regions first, then filling in the details. It’s far from perfect. The foreground is obviously painted in, rather than over. It looks good enough, though, and it was fun.

For the up-coming Rage of Painting game, I really wanted to automate the creation of the intermediate steps of painting a picture. Doing so would mean I could upload only the finished steps and have the system automatically compute the intermediates. More compellingly, it would mean in a future version users could upload their own photos and have Ross paint them. The method I tried was simulated annealing.

Kiiiillllll Meeee

The results were unspectacular. Summarily, after computing the 16-bit palette, I’d generate a set of n rectangles with X,Y,W,H, and palette index values. Each rectangle was one ‘gene’ in the organism. Fitness was defined as the number of pixels which don’t match between the ‘painted’ image and the target image. (Really, 1.0/(1.0 + number of mismatched pixels).) Generations were bred, mutated, and selected. Wash, rinse, repeat.

I’m not sure what I’ll try next. Maybe loosen the painting order a bit. Maybe select regions to paint by biggest area or most pixels.

This space is reserved for ideas and drafts for my entry into this year’s Awful Game Dev competition. The theme? Public Access Television.

I am easily amused and quick to jump on terrible ideas.

Why am I doing this?

• It’s an amusing take on Bob Ross and everyone loves Bob Ross.
• It doesn’t require lots of realtime physics or math-heavy operations.
• It gives me a chance to stretch my algorithmic skills in Java, as almost all image processing algorithms I’ve written so far have been in Python.
• It doesn’t require very many art assets. Despite being a show about art, it’s pretty light on that front.

What are the key pieces and how will it play?

• The game is broken up into stages or ‘episodes’.
• Each episode has the user drawing a picture, and pictures increase linearly in difficulty and complexity.
• Knob Ross opens each episode by showing the image to be completed.
• Ross runs through the steps for painting it.
• Ross shows the finished image again and the countdown timer starts.
• At the end of each episode, Knob Ross will compare the image the user has drawn to the objective image and give it a score.
• New episodes are unlocked by having the sum scores from the previous episodes greater than a threshold.
• Stretch goal: In the Android version, it would be nice to snap a photo of someone/something and have Ross paint it.
• Stretch goal: User upload gallery.

What will the engine have to do?

• A. We will need to display Ross with some animations, text for his speech, and the image to be drawn.
• B. We will need to read mouse input from the user, including palette selection, brush strokes, and ‘finish’ buttons.
• C. We will need a countdown timer to prevent dilly-dallying on the user’s behalf.
• D. We will need to play sounds for his speech and some background music.
• E. We will need a menu system to select episodes.
• F. We will need systems to load an image, convert it to n colors, decompose it into steps, and compare it to the user’s image.

How will these systems interact?

No idea. Gotta’ fill out this.