Back To The Drawing Board: What's Up With Picross?

November 06, 2019

Last week, Professor Yarger helped me come to the realization that this game… doesn’t really seem to have any depth. If anything, it’s a visualizer that tells the player what drum beat to play to be successful. Maybe kinda helpful with the teaching of the music, but not a compelling game or rewarding to players who know drums. I spent this week doing some redesigning and I came up with a potential idea that might solve this problem.

Actual Drawing Board: Some Design Ideas

Staying Within Platforming?

I first tried to think about staying within the platforming genre and maybe changing how the platforming game worked. It honestly made me frustrated as I was having a hard time coming up with any good ideas.

I set the idea of platforming to the side because I felt some other designs percolating in my brain.

Fighting Game

With the idea in mind that maybe a platformer might not be the most compelling, I next tired to take a look at what it might mean to integrate my rhythm system into a fighting game.

The idea of the game here is that the enemy would state what attacks they are about to do, and then like Daigo at EVO 2004, the player’s drum beat would allow their character to perfect parry the attacks.

This initially appeared to have the same problem as the platformer - it’s hard to immediately think about the depth possible with this game.

So, I decided to try designing something completely different. Something non-character-based.

Color Blending Game

The next idea I briefly had was this: imagine each instrument corresponds to a different color. All of the instruments played in a single loop combine into a single color by adding together and normalizing the hex colors. You beat a level by blending the target color - which would be equivalent to the good drum beat.

While this has a small amount of potential, there are a couple key issues here.

Firstly, this is completely inaccessible to players who have a vision impairment affecting color.

Secondly, this doesn’t restrict where in the measure each instrument needs to be placed. I can place a bass and snare hit on beats 1 and 4 and still solve the level above.

So what if each beat also corresponded to a color, and placing the instrument on that beat created a specific blend of colors? you tell a player that the first beat needs to be purple, and they see the color of the beat is red, they know that since bass drum is blue they have to put a bass drum on the first beat.

Hmm, this is interesting, but again it doesn’t entirely solve the problem we’re trying to solve.

I decided to scrap the idea and after ~2 hours with no avail, I gave up for the day and took a break.

Picross: What is it?

On Sunday, this Polygon video popped up in my recommended feed on YouTube. I’ve always heard of picross but never really bothered to look into the genre or understand it. Intrigued, I watched it, and delved deep into a hole of playing picross.

Picross is a picture-based puzzle game. It’s kinda like sudoku in that you have to fulfill the constraints of some numbers that appear on the puzzle/level at the start.

Essentially, you begin with a 2D grid. The rows and columns are labeled with numbers; each number on a row/column indicates a sequence of that many consecutive pixels that should be colored in. By fulfilling all such constraints on all of the rows and columns, you produce an image, like the example from wikipedia below:

Picross Realization

What I realized about Picross was that there are essentially three big approaches here to solving a level.

1) Brute force until it works 2) Do the math blindly without looking at the image being produced, and complete the level purely mathematically 3) Do some small things mathematically or with brute force, and then use intuition that is known about pixel art to draw what might be the rest of the solution.

I think that this is a very important concept when it comes to the design of this game. While Picross’s intent isn’t to teach the player pixel art, what if it kinda was?

Sound Picross…. Socross?

The question that I asked myself was “what if I tried something like, but applied it project legato?”

Here’s the concept I came up with. Imagine the grid which instruments can be placed on beats has a 1:1 mapping with a grid of numbers. Placing an instrument on a beat will subtract a set number from that beat, a different number from the beats edge-wise adjacent, and a third number on the beats corner-wise adjacent.

The solution to the puzzle will cause all of the numbers on the grid to be 0. It will also be a good drum beat.

Example Level 1

Here’s a simple example showing the initial screen of the puzzle and the “solved” screen of the puzzle. In it, the bass drum only subtracts a 10 on the square you place the drum beat on, so the solution is a bass drum hit on 1 and 3.

Example Level 2

Here’s another example level. here, the solution is the same, but the puzzle looks different since the bass drum subtracts 10 from its square and 5 from edge-wise adjacent squares.

Example Level 3, 4, and 5

Here are a few more levels, increasing more and more in complexity:

After sketching out these 5 levels, I decided that I really wanted to try and implement this for this week to see how it works out.

Implementation

Thanks to the work I’d done in previous weeks, the instrument system was pretty much completely decoupled from the platforming game, except for where those implementing my InstrumentController interface performed game mechanics, and a single call that the BeatManager class made to the platforming character object.

The biggest things I had to do now though were:

1. the instruments need to have configurable number tilesets for each level.
2. unlike in the platforming game where you want the action corresponding to the instrument to happen every single loop (like jumping or shooting), you only want to subtract or un-subtract numbers on a placement or unplacement.

To address problem 2, I added a couple events that the InstrumentController interface has called OnSet and OnUnSet. Boom, done.

Problem 1 was a little tougher. To address it, I had to restrict myself to not be able to have levels like example level 3 above. Instead, each instrument can specify what they apply to a 3x3 grid by specifying the number to apply to the center, to edges, and to corners.

Now that I had the ability for the instruments to notify the information they had to my puzzle game, I had to implement the puzzle game itself.

I created a system of PuzzleSquare objects, and PuzzleRow objects that parent a bunch of squares; then a PuzzleManager that parents all the rows it needs.

The grid will already be known by the music components - the number of instruments is the number of rows, and the number of columns is the number of beats in the level.

But how do I populate the grid with the numbers?

This is when I had to cut my attempts to over-engineer this and just expect that I know the numbers for each of the levels. I’ll have a scriptable object of the numbers for each level (this way, I’ll be able to create levels easily by placing down drum beats on a new scene configured to do so.)

Progress GIF

Here’s a GIF of what the game looks like with this new gameplay. I’ve implemented the example level 5 that I sketched above.

Next Steps

• Consider if this is truly the right direction to go.

If so:

• The game should show the player what subtraction each instrument will apply to the level.
• Make this easier by showing the player how many of each instrument is needed for the solution.
• The ability to reset the level.

If not:

• More exploration.