Go slow to move fast: Building a game in Ruby for the first time
The story is familiar. You’re given an abstract task with a lofty goal. We need to build a rocket to the moon, they say. You have limited time, few resources, no capital, and even fewer instructions. What do you do?
Find a friend.
Breathe: move slow to move fast.
Facebook, ironically, had to change its motto from “move fast and break things” because it really didn’t do this in practice. Facebook now champions the more awkward “move fast with stable infra.”
A better motto might be “move slow to move fast.” When Facebook wanted to expand into new countries, instead of building local teams for each new territory, it did something far more ingenious: it asked its users to translate words into other languages they knew. Boom. Facebook gained scale, instantly. But this solution wasn’t the first, or the most obvious, and probably took longer to come up. It takes patience to see the results of collecting all the best translations from its users for the ~7,000 languages in the world vs. seeing the immediate results of translating into the top languages based on territories in which Facebook is most popular.
At my current coding bootcamp, for our first game coding challenge, we were placed into groups of two. Marcella and I were given these instructions at Friday, three pm: build hangman by Tuesday morning. Ready. Set. Go.
# Ruby Final Project - A Command Line Interface Program
* Make your application interactive (take user input and display some output)
* Use good object oriented principles
## Your task
Your task is to build out hangman. Users guess letters, and depending on the word, each letter is filled in. Think about how to model the program such that we could hold onto a user history, and see the number of games a user has won or lost. Build this out in pure ruby. You can use the require_all gem, and the pry gem. Do not use any sql.
You'll need to build this project from scratch, but your project should have a good, clean directory structure and looks similar to other gems. Following the directory structure common in other gems will make it easier for other developers to pick up your code and know where to find things. You're directory/file structure should look something like this:
│ └── run
│ └── models
│ └── console.rb
The bin folder will hold your runner file which starts the program and should require only your environment file. You should be able to start your program by running `bin/run` in the command line. Remeber to put `#!/usr/bin/env ruby` at the top of your runner so that the command line knows to run it as a ruby file.
The config folder should have your environment file, which should require all the other files that are needed to run your project, and load Bundler to require all of the dependencies listed in your Gemfile
The README should be well written and clear. Anyone reading your readme should know exactly what your app/gem does, how to get it running on their computer, and how to contribute to it.
We should wrap this project up on Tuesday morning.
Are you moving yet?
Well, instead of starting to furiously draw relationships and build our models and classes — the usual first step in object oriented programming — Marcella suggested something far wiser: “Should we write our ReadMe first?” she probed. I thought about it for a minute. “YES.”
Side note for those less familiar: readmes are usually that annoying .txt file that come with most of your external downloads. MOST folks don’t read their readmes, but it’s usually a good idea to start there if it’s a new program. Fun thought: maybe programmers write readmes for themselves and not for users…
Here’s our readme.
To start the game, open your terminal and type in bin/run.
The hangperson game has a database built into the app with words and phrases. There are five categories, each of them containing words and phrases.
To begin the game, the application will ask the user for his or her name. Then, the user will be prompted to select one of five categories. The application then chooses a random word or phrase from that category. The application will display underscores for each letter in the word or phrase. The application will then prompt the user to guess a letter.
After each user letter or solve input, the user will see three things on the display: the hangperson, the incorrect guesses, and the puzzle. If the user guesses a letter which is not contained in the puzzle, the guessed letter will be stored under incorrect guesses. The user will also get one strike for each incorrect letter guessed, including if the user guesses the same incorrect letter multiple times. Each strike will add one part to the hangperson body. If the user enters a letter that is contained in the puzzle, the application will update the puzzle to reflect the placement of the correct letter. The hangperson and the incorrect guesses will also be displayed, but will not change after correct guesses.
Rules of the game:
The user has six strikes before the game ends, resulting in a loss for the user. If the user successfully guesses the word or phrase, or successfully “solves”, then the game ends, resulting in a win for the user.
If at any any point the user wants to "solve," he or she can type in the entire word or phrase at one time. If the guess is correct, the game ends, resulting in a win for the user. If the guess is incorrect, the game ends, resulting in a loss for the user.
This is not what our readme looked like in the beginning. Yet, by writing it together, we did a few amazing things:
- Aligned our vision for the game
- Painstakingly defined terms, such as “win,” “loss,” “solve”
- Visualized the game
- Had a point of reference as we coded to make sure we were on track; we constantly modified the readme to reflect any new thinking
Find a friend: Pair programming
Pair programming can be difficult. What’s the best way to work together in a group to ship code? Flatiron teaches us that there should be a division of responsibilities. One person should be the driver; the other, the leader. The driver types out the code while the leader strategizes / talks through what the code should be. The two constantly switch between the roles, usually after 25–30 minutes.
But before you do that, what do you wish you could have done differently?
See, I might have misled you. The first thing Marcella and I did when we got our assignment wasn’t to write the readme together.
The first thing we did was talk about how we liked working together.
- What do you want to work on?
- What do you feel less comfortable with?
- What do you want to do first?
- How are you thinking about this?
- How are you feeling?
- Tell me about your family. Teach me about you.
This step was the most important.
Visualizing is critical in object oriented programming. Draw with abandon. Erase. Take pictures. Re-draw.
Repeat it all
After cycle one, you have to iterate through the steps, until you feel done. Like any piece of writing, you won’t ever feel completely done.
But what we did learn was that our first version of hangperson didn’t follow the best object-orientation principles of creating classes, with each class having a single responsibility. Nor was it easy to read nor did it follow DON’T REPEAT YOURSELF principles.
We had go back and break our code to make it better. And we did this again, and again, and again.
The incredible thing about learning languages or coding involves erasing your “slate” and starting with a blank one. Things that we take for granted when we string together a sentence or an essay we have to un-learn and re-learn. And that’s a pretty amazing thing. Why?
Because it’s an opportunity to fix some of our worst habits.
Too often, I find myself rushing into a task instead of taking those beats to pause. For example, I’ve stopped outlining essays, because I have grown so confident that what I will write will make sense.
Yet, some of the best negotiations succeed because of process, not just the content of what you say.
What habit/process do you want to fix? And what other parts of your life can you use to to fix it?
PSA: If you want to play our first version of hangman, you can check our github here. It’s not perfect, but it works. If you’re a Flatiron student building hangperson for the first time, do yourself the favor and build it yourself first :)