Array Transformations
‘The job of feet is walking, but their hobby is dancing.’
Lately, allowing players to write custom code, in game, that alters the game itself is becoming a somewhat common feature. While this might seem like something you would only see in smaller independent games, it can be found in popular titles like Minecraft, where there’s redstone circuitry and command blocks. The Dragon Age series have conditional statements that the player can use to improve its parties ai. You can also see it in idle games where the player can write behaviors that automates the the game play while they are not playing, like Stone Story’s robust stonescript or Soda Dungon’s user friendly sodascript. In all these examples the coding is optional content the player can choose to ignore, but there are new games coming out where that coding is focus of the gamely itself. I want to talk about two such games and how they helped me learn software engineering.
As a visual learner I struggle with coding, because its not terribly visible. So for a new person in a boot camp or someone who’s beginning their journey programming, it can be challenging to ground all the abstract processes that are going on. For me, it’s similar to a watch designer who is only allowed to write down and describe how a watch behaves in a book, rather than getting to mill gears or wind springs and see it in motion.
When it came time to learn while loops I kept thinking about this level I’d played in Prime Mover that helped me grasp the concept quickly. I returned to it for this article and I didn’t realize how spot on it was, not just at visualizing how while loops work but, more broadly the game manages to abstract the concept of programming as a whole to a visual medium.
def countdown(number)
while number > 0
puts number
number -=1
end
end puts countdown(10)
#=> [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
Breaking down this gif.
I wrote code in ruby next to the game to show how the game takes code elements and visualizes them.
We have our initial array or arguments in the bottom right corner, that we turned in to whatever the program is on the surface. On the top right above that we have, what the expected results should be, in Ruby that would be the Rspec tests. In the center there is what looks like a chess board where our program lives. On that we have a while loop. Each segment of track the number moves along represents how code is executed linearly in order written. But the beauty of it is that visualization is we can see how it can execute as a literal loop. And on the loop we have the other elements of the code
For while number > 0 and the first end, would be the two pieces on the left side of the loop. The puts number function is the tool in the upper right corner of the loop. number -=1 one is in the top left corner of the loop. Every time we see the word number we are referencing the number moving through the loop and its called the neutral word number because it is constantly changing as the code executes. We can see every word of the code that we wrote and each individual piece visualized here.
def even_deleter(array)
array.select.each_with_index {|number, index| index.even? }
end
array = [33, 5, -17, 11, 5, 7, 8]
puts even_deleter(array)
#=> [33, -17, 5, 8]In this level, the game is introducing the user to methods. Essentially the board we see the array traveling through is our program. But we can insert smaller programs written on different boards along the way, to to vastly expand the functionality of how a program works, the same way a programmer can utilize helper methods in their own code.
I want to talk a minute about the score screen. So unlike many classic puzzle games there is no single solution. Everyone who plays the game has their solution scored on a global leader board. And those are scored against two metrics: ticks, which is time, and that would be if you were writing a program how how quickly that program executes the code that’s given to it. And chips, which is the amount of pieces you used to build the code. If you were writing a code this would represent writing code more efficiently with fewer lines.
It teaches:
- You can make quick but inefficiently written code
- You can make slow but efficiently written code
- You can make code be both slow and inefficient and still work
- The goal of coding is to solve the problem first then optimize it
The developers of Human Resource Machines tackle the same concept of visualizing array transformations, but do it in a significantly different way. In this game you have an avatar that is your program. And you give this avatar, a set of instructions to execute.
What I think is wild is each game functions as its own simple coding language with its own quirks, which can both be used to accomplish the similar tasks. So the final lesson they teach together is that Prime Mover might make more sense to one player then Human Resource Machine. In the same way Ruby might make more sense to someone then Python. On top of that, beating one game before playing the other would make it significantly easier to beat the new games, just as it becomes easier to learn a second programming language. Showing how different languages could appeal to different people because of differences in their construction is useful because it’s confusing to new programmer as to why someone would have a preference in code languages that can be used to do similar tasks.
These games are great tools, showcasing why someone would want to be a developer, the way of thinking that a developer has to consider and is also an excellent way for people beginning to program to have a foundation to visualize what their code is doing.
Games mentioned: Prime Mover, Human Resource Machine, Minecraft, Dragon Age, Stone Story RPG, Soda Dungeon
-the quote in the title is from ― Amit Kalantri, Wealth of Words
