Community News
Community news, customer stories, and more!
Previously on our last episode (Table Games) as I reflected over 10 years of Advent of Code problems and the many versions of games that one will encounter in that journey, we began with some table games. We dove into some very interesting versions of card and dice games that Alteryx was able to help us play/solve. If you missed it, be sure to go check it out! Today, however, we are taking a trip to the Arcade…
AoC Arcade Games
For the uninitiated, 2019 Advent of Code is infamous for one thing: its repeated use of an “IntCode computer” that you slowly develop throughout multiple early problems and then leverage over and over again throughout the course of the month. While this can certainly be done in Alteryx, the slow process of needing to iterate through provided IntCode “programs” is unfortunately exceptionally slow compared to other computing languages. With that being said, while slow going, there are still some really neat things you get a chance to build in this particular round of AoC. One such example is a version of the Block Breaker game contained within an arcade cabinet gifted to you by some elves to keep you busy on your interplanetary travels (did I mention there is a storyline to each year’s AoC adventures?). For those of you who don’t already know, there are a few easter egg games built right into Designer, Block Breaker, or rather “Data Breaker,” being one of them (I may have played this one once or twice). But why just play something built in and provided for you (that’s just too easy, right?) when you could instead build it in Alteryx yourself? To begin with, you first need a “complete IntCode computer” that was finished being assembled back on Day 9… in Alteryx this translated to an iterative macro. Mine looked like this (zoomed way out because building it is part of the challenge people! …and yes, I’m sure this could be optimized, but this was just one step of many in a marathon, so give me a break, there were lots more problems to solve still):
AoC 2019 IntCode Computer Macro (updates “installed” through Day 9)
Running the provided IntCode program contained within our gifted arcade cabinet (the puzzle input… luckily built for us) generates a set of mysterious output values:
The purpose of this particular problem, however, was not to assemble our IntCode Computer, it was to do something with it… so of course we are provided with some additional context in the problem statement of what to do with this particular output. It turns out that every set of three output records corresponds to an x-position (distance from left on arcade screen), a y-position (distance from top of screen), and a Tile ID that is representative of the objects to be rendered. Well then, I suppose it’s time for us to convert our dataset into something more meaningful. One quick and easy way to do so is to implement a set of Multi-Row Formula tools:
With the first, we establish the type of data, named “Header” here (more on that in a sec), and then the second allows us to easily group each set of three records into a single “Output Object.” Now let’s use that “Header” field we created with a Cross-Tab tool to transform our dataset into something more meaningful:
Now, all we need to do is implement the translation for our particular Tile IDs. When decoded and visualized, in this case using the Report Map tool, in order to better understand what we are dealing with (FYI, not required for the actual problem solving) our IntCode Computer output now looks something like this:
Look familiar? After the initial game state is rendered the IntCode program essentially “pauses” and awaits its next input. Here, the program allows for an input command (essentially move the paddle left, right, or stay still), iterates through its internal logic, and then outputs any changes to the game state, one frame at a time, updating (and outputting) the coordinates and status of any altered states. For part 2 of the problem, all we have to do is beat the game to see our high score once all blocks have been cleared.
While a simple enough task for an Alteryx Data Breaker 2-time reigning high score champ like myself, unfortunately the amount of time it takes for Alteryx to iterate through and produce each frame makes this infeasible (or at least not fun at all) to actively play. Instead, in true analytics automation fashion, we can build in logic (in another iterative macro) to have Alteryx move the paddle for us based upon the position of the ball, ensuring that it always meets the paddle and bounces back into the field of play. We can achieve this by merely isolating the x-coordinates of the paddle and the ball and having our macro input the correct movement command based upon their relative positions. Because our TileID field established earlier identifies which records correspond to the paddle and ball, some simple use of Filter tools allows us to zero in on the right data to evaluate (TileIDs 3 and 4 respectively). Appending the records and performing a quick comparison in a Formula tool then allows us to determine our next move/input:
For the execution of the whole process, however, we need to do this in stages. First, we run the input program through our operational IntCode “computer” (i.e. macro shown above) to output both the initial positions of all pieces on the game board, as well as the new state of our program (the code of the program can update itself with each iteration based on defined logic built out over previous AoC problems… I did say AoC 2019 was a bit of a doozy). The “current” program state (an additional output from IntCode Computer macro) is then used as part of an input into our secondary game simulation iterative macro (that in turn houses another copy of the IctCode Computer macro). We do this so we don’t have to reinitiate building the full game screen with each new iteration saving us a ton of processing time… instead we only cycle through the couple changes made as the ball moves a frame at a time and our paddle moves as well following it (plus any blocks that might be destroyed and changed into empty spaces). While this sounds simple enough in theory (okay, I’ll admit, maybe it doesn’t 😂), not gonna lie, this additional game simulation macro was a bit complicated to execute:
AoC 2019 Day 13 Part 2 Game Simulation Macro
If we run this, however, and render the resulting game state screens after each automated player input, we see this start to happen:
As you can see in the animation above, our paddle is tracking the ball, constantly moving (even in cases where we as a player would likely just leave it still) in order to ensure that it is in the appropriate position when the ball eventually approaches the y-position of the paddle and needs to be rebounded back towards the target blocks. Then we just have to wait it out until we clear all the blocks. Now, in my case at least, this required over 4,000 inputs (and too much time iterating the IntCode “computer” in Alteryx between each “button press”) to successfully beat the game, so I ultimately turned off the render (within the container section of the game sim macro above) and let it run itself, tracking the final score output (at the bottom left of our sample render) once I reached an exit state where there are zero remaining blocks being rendered. Unlike in the traditional game, you can’t hit the ball at an angle to change its trajectory (and speed things up) – better for automating, worse for how long it takes to clear all the blocks 🤷.
-----
Curious for more and want to try some of this out yourself? Be sure to head over to AOC 2025 to learn how to participate and get ready to join in on the fun as the calendar shifts over to December for Advent of Code 2025! Meanwhile, stay tuned for the final episode of this series as we go even further back into the AoC problem library and delve into the world of RPGs!
