Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

The World’s Bestest Internship

Welcome to Gamewerks Corporation! After talking to some friends who took 207, you learned about an amazing opportunity to work for the best game design studio on the planet, at least, according to the advertisement they found on bulletin board in the JRC. You had your reservations but after your friends assured you that “the codebase was immaculate” and “you certainly won’t rip out your hair,” you decided to give it a shot.

You are now sitting in your office on your first day with your internship partner in a rundown building in downtown Des Moines when you boss comes in and screams:

“[Insert your name here], we have a crisis again! Our last intern who was working on the game quit while refactoring the codebase! We need to get the latest version of the game out by next Wednesday. If we don’t do it, our publisher will have our heads on a stick. You need to dive into the codebase, fix the last few bugs, and ship it!

Well this seems completely unreasonable given this is your first day, but because your boss has absolute power over you, you acquiesce to their demands.

Github

First thing first: you need to get the code. Gamewerks Corporation uses Github to store their source code.

(Why is the corporate repository stored on your 207 professor’s personal Github account? Who knows…)

Your boss wants you to follow the same practices you used in your CSC 207 class: make a new repository on your personal Github account that is a copy of this template repository. That way you can make changes on your own without disrupting everyone else’s workflow.

Your boss also tells you that it is company policy to commit to your repository at least once per major task that you perform. In other words, you keep in the back of your mind that you should commit your work and push your changes after completing each part of this internship.

Preamble: Block-what?

Of course, you have no idea what kind of game this is. Without knowing how the game works, you don’t really have any way of fixing bugs. So you, first, ask your boss what exactly this Blocky stuff is:

“…it’s Tetris.”

Oh, well that explains it. You should make the program behave like the classic game, Tetris. You know you don’t really need docs for this because you can simply Google one of the billion Tetris clones out there (you observe that Tetr.io is particularly popular) to get a feel for how it works.

As you get your bearings, your boss mentions one more thing:

“…well, it’s more than just Tetris. It is a riff on Tetris the Grandmaster by Akira. We use the Akira Rotation System here.”

Wow. He said that with some sass, like this is a thing or something. Well, whatever. This is good information to know, but you probably don’t need to worry about it…

Part 1: The Lay of the Land

The first thing you should do is understand the codebase. Conveniently, your boss observes:

“The old intern was working on an architecture document, found in ARCHITECTURE.md at the root of the project repository. It is partially complete, but they left a number of holes! Fill them in for us, please!”

Well, you can’t complain. You were going to sift through the codebase anyway. Writing down what you find into this document seems like it helps everyone, so you decide to give it a shot! Once you are done, you remember to commit your changes to your repository so you have a log of completing this step!

Part 2: Testing the Well

With the architecture document completed, you have a better sense of how the code is organized. Your boss comes to you with your first real task:

“That intern left after writing the code to check and perform line completions in the well. They began writing tests, but then they ghosted us! Can you complete the test suite for the well class? You can just worry about testing detecting line completions and deleting rows.”

Ghosted, what? Well, nevertheless, that’s a concrete enough task. You set to work writing a reasonably robust test suite for the Well class’s line completion functionality. After you finish the suite, you remember to commit your changes to your repository again!

Part 3: Emergency Debugging

Now your boss comes to you with more things to do:

“That stupid intern couldn’t fix all the bugs before they left! Can you finish up their work please?”

Man, are you just cleaning up after people? Whatever, it’s a job, so you set to work. You check the bug queue and find three reports:

Caution

When a piece move off the right end of the board, the program blows up!

Caution

While tapping on the shift right key works, holding down the key does not cause the active piece to move!

Caution

New blocks spawn too fast! There should be an entry delay, the ARE, between when a block clicks into place and when the piece appears. This is even more obvious when you use a soft drop to lock a piece into the well immediately. I know the ARE is a game attribute currently; it just doesn’t seem to be used? Also, there is similarly a line delay that should be respected when a line is cleared. That is also a game attribute, but it doesn’t get used!

These bug reports aren’t… great. You expect a lot more detail, maybe even specific reproducibility instructions, in a good bug report. Nevertheless, these look like serious issues, so you dive into bug fixing, keeping in mind your architecture document as a guide and the debugger as a tool to better understand how the code works. After you all done, you remember, yet again, to commit your changes to your repository!

Part 4: Random Block Generation

After getting the game into a playable state, you have noticed that it is still broken! In particular, it looks like only the “I” block spawns every time a new block is required; this isn’t how Tetris Blocky should work! You look up online on what to do, and it appears that the official Tetris Blocky standard states that you should:

  • Have (a) an array containing all the possible block kinds and, as a piece of state, (b) the current index of the array you are on.
  • Shuffle the contents of the array.
  • When you need to get a random block kind, return the piece corresponding to the current index you are on and then increment the index.
  • When the array is exhausted, i.e., the last piece has been returned, reshuffle the array and reset the current index.

In this manner, it looks like that you will never randomly generate two block kinds without first generating all the other kinds beforehand.

From this algorithm you have identified that you need:

  1. An array to hold the blocks.
  2. An integer to remember the current index.

However, your boss says that you aren’t allowed to use the Java standard library to shuffle the array for you! This makes absolutely no sense because the rest of the code base does this, but again, they have power over you.

Luckily, you have identified the Fisher-Yates Shuffle as an appropriate algorithm for shuffling an array. You will likely need to create a shuffle method that takes an array of pieces and shuffles them as a result. So you concede the point and implement these things along with the random piece generator, taking care to integrate your changes appropriately into the pre-existing code. You also note that the ThreadLocalRandom class and its current() static method allow you to fetch a Random object that you can use to generate random numbers.

After you are done, you remember to commit your changes yet again to log your progress.

Update Your Changelog

Whew. At this point, the game is in… well, some playable condition. Mission accomplished!

At this point, you remember that it is Gamewerks policy to include a changelog in the project’s CHANGELOG.md file that captures all the changes you made to your codebase. You find it a bit redundant since you could always query git for this information, but this changelog is supposed to contain the output of running the git log command in the terminal, verbatim. Oh well, you go ahead and make your edits, also making sure to fill in the remaining TODOs in README.md, e.g., your name and resources used.

Turn-in

Finally, once you are done, you know that you should commit/push your work and submit it to Gradescope when you are done. Why Gradescope when this is an internship? Who knows, but you know you’ll want to ensure that your repository has the following folder structure:

┠─ pom.xml
┠─ ARCHITECTURE.md
┠─ README.md
┠─ .git/
│  └─ ... 
└─ src/
│  └─ ...

You also know that once you are done submitting your work, you should get your things and leave the building as soon as possible, so you don’t go down with this sinking ship.