# A9 — Final Prototype

## Ground Control

### Ground Control Rules

Ground Control is the name of my final project for this course. It is a strategic two-player board game. Players try to be the first to 25 points by completing randomly-assigned tickets. Individual tickets have point values between 7 and 14 points.

In order to complete a ticket, players must move one airplane token (of two) to the other side of the board, thereby letting the plane ‘take-off’. Planes move with the hexes.

However, tickets require specific resources to complete: fuel, water, and snacks. Each resource must be collected by players from one of the six specific resource springs. Players can collect from a resource spring only if they have a line of supply trucks (total of 24 per player) connecting from the spring to their end of the runway. Trucks move along the vertices of the hexes.

Each turn, two six-faced dice are rolled. The player may either:

• Move trucks along the vertices of the hexes equal to the sum of the numbers on the dice
• Collect one resource from a connected spring
• Move planes equal to half of the sum of the numbers on the dice, rounded down
• Draw three tickets cards and keep at least one

Tickets are random; at the beginning of the game, players randomly draw three tickets. They must keep at least one of the tickets, but they can elect to keep two or all three.

Resource springs are are located evenly on the board, but the spring’s specific resources are randomly assigned at the beginning of the game.

Ground Control forces players to exercise strategy. Users may move planes too vigorously to find that they don’t have the resources to complete the tickets. Too ambitious tickets may be drawn and player neglect the resources or plane movements; conversely, too many conservative low-point value tickets may require more plane movements.

### Background

For this final project, I had a lot to think about. I wanted to build a final project that was both educational and enjoyable. We were given the option to work with partners or alone. The project had to incorporate at least two of the different prototyping techniques that we learned.

The logical choice, as an aspiring UX professional, would be to do some project involving the website prototype, mobile prototype, and maybe the Wizard of Oz. Indeed, I did initially come up with an idea akin to Leafsnap for the Pacific Northwest. The app would identify if a plant is native or not native by simply taking a picture of the plant’s leaves or bark. My project would have it as a mobile app controlling some actions behind-the-scene with a Wizard of Oz setup.

I liked this idea, but given the complexities of building a mobile app and performing a Wizard of Oz prototype, I needed at least a couple other people. Additionally, since I was working on capstone, I either needed something easy (not the case, since it was a final project) or fun.

Nathaniel and I were working on our capstone project together and both in the prototyping class together. We had had a good time working together on capstone, and both had sketchy ideas for this project. Furthermore, despite the seemingly-little relation to UX, we had the most fun with the 3D printer (chess piece) and laser cutter (phone stand).

When I made the chess piece, I had the idea to make a full chess set and board for my final project. Unfortunately, it was a bit derivative, since I wasn’t making anything new, and the point of prototyping to make a new idea into a reality. However this idea, combined with Nathaniel’s love for gaming, led us to the idea that we should make a board game.

### Research

Neither of us had created a board game previously, so we started by searching the internet for inspiration. There are many excellent board games out there, and there are site devoted to people airing out ideas for new ones.

We came across an idea for a cooperative airport-themed game on a site called Board Game Designers Forum. The idea was for a two-player game where the players tried to get the airplanes sequenced and ready to take-off from an airport.

We liked the idea of a hex-tiled two-player airport runway game, but we wanted to design our own game.

### Design

We started by generating sketches of what we wanted the game to look like. Using the premise of a runway-themed two-player game, we created the hexes.

We began by creating the general shape of the runway with hexes; since it needed to be longer than wide, we quickly sketched out a board 13 hexes long and 4 hexes wide. We decided that instead of a cooperative game, this would be a two-player head-to-head game, with one player taking one end of the runway and another with the other.

The most imperative maxim that we held when we designed Ground Control (as is the case when designing games in general) is to preserve balance. Players cannot have such a one-sided game that victory is untenable/unexciting. Furthermore, the game must be quick-paced enough to not become boring, but long enough as to encourage strategy.

Our two favorite board games are Ticket to Ride and Settlers of Catan, and we were heavily-influenced by their dimensions of strategic resources, building the the edges of the hexes (Catan), and ticketed point-to-point connections (Ticket to Ride) among other aspects.

In Ticket to Ride, players try to accrue the most points by connecting cities with railroads. They collect points by the rail laid, but also by connecting specific cities together. These objectives are given by random cards, or tickets. We designed Ground Control’s tickets to behave similarly, in that the number points is equal to sum of the required resources.

Settlers of Catan scores by having the most settlements, longest road connections, and other point-scoring schemes. In Catan, players connect to resources by having settlements on the vertices of resource hexes, and these are connected to other settlements by hex-edge-long road segments. Unlike Catan, we felt that having every hex be a resource would be overloaded in Ground Control. We simplified the resource collection by only requiring a truck connection to the end of the runway, eliminating settlements, and having only certain hexes have resource springs.

### Laser-Cut Game Board

Once we had the game rules and design figured out, we began our designs on the game board. We measured the laser cutter and found that the maximum dimensions were 60 x 30 cm. We wanted a long board, so we maximized at 60 cm. For the width, we decided that it would be variable between 20 and 30 cm (and aimed for 24 cm). Nathaniel created the board on Rhino and I bought the material.

I went to Home Depot to find suitable material for the laser cutter. I found a pressboard panel used for the bottom of home drawers, such as you’d find in a bathroom or kitchen drawer. The material was sturdy, but thin, and had a nice faux-grain surface. However, the Home Depot did not have a working saw to cut it to size. The full board measured 120 x 60 cm, which meant we had to cut it down ourselves.

Unfortunately, there were no power saws in our class workspace. Instead, we clamped the board to the table and roughly sawed off the end of the board at 30 cm mark. We did so by taking turns with a hand saw. Since the board was 60 cm at its short end, we only had to cut the width for use in the laser cutter.

The Rhino design did come out to be 60 x 24 cm, which Nathaniel then processed into the laser cutter. Once our game board was separated from the larger board, Nathaniel cut the board with the laser cutter. He also added flourishes with our names and the title Ground Control. More importantly, he also scored small circles in the hexes where resource springs would be.

### 3D-Printed Trucks and Planes

The tokens for Ground Control were printed with the Makerbots that we used in the 3D Object Prototype assignment. We needed to design the trucks and planes to fit the game board. The hexes had edges 3 cm long.

#### Planes

We started by designing the planes. Initially, I wanted realistic-looking planes. Indeed, I began by designing a model of a jumbo jet in Rhino. However, this proved to be quite difficult, so I began looking for models already created on Makerbot Thingiverse. One that I found looked exactly like what I wanted to build. I downloaded it, and scaled it to fit between 3 and 3.7 cm, to fit in the hexes.

The quick print did not turn out well. The scaled-down model did not print well, since it had so many details. The wings were so fragile that they broke off when I tried to free them from the raft, and one even broke off when I simply touched it.

I went back to the drawing board and completely revamped the design. Like icons and signs depicting planes, I shifted to a silhouette design for the plane tokens. This design was the outline of a Boeing 747, traced, and raised to 1 cm high.

With fewer parts sticking out and details, these tokens printed out nicely. They are immeditely recognizable as planes, get are sturdy enough to hold up during gameplay.

As an added bonus, they can be stood up in multiple ways — they can lay flat, on their tail fins, between the wingtip and either the nose or tail fin. We thought it might be an interesting way to indicate some sort of status during gameplay, but we didn’t add anything to Ground Control at that point.

#### Trucks

The small trucks were simple to design and execute, but unlike the plane, the printing itself was problematic.

We had the design for the trucks early on. They were 2 x 1 cm long and shaped like a delivery truck. The cab was 1 mm narrower than the container end on each side, to make the truck shape immediately recognizable.

To print, we wanted to minimize the amount of supports and rafting needed. However, the cylindrical wheels meant that it wouldn’t be smart to print with the wheels down. Instead, as to maximize surface area, we printed the trucks flipped onto the right side. This required a little amount of supports (for the 1 mm narrowing).

Our first batch of 24 trucks were printed with both the raft and the supports. The raft made the print clean, but proved to be difficult to remove in about 2/3 of them — 1/3 of the trucks removed cleanly, 1/3 had bits that we were able to remove, and 1/3 had the raft stubbornly stuck. For the 2/3 that had the raft stuck, it ate a lot of our time removing them with pliers and tweezers. For a few of them, the raft simply could not be removed, so we could only sand them down a bit, leaving unsightly bulges on the right side.

Not looking to repeat this, we decided to print our second batch without rafts, but with supports. We eliminated the problem of the raft, but introduced a new one: stringy supports. Without the raft, the supports weren’t built correctly. Without the correct supports, the right side of the truck cab did not have a clean edge. This required light sanding, but still did not look as good as the first batch. However, we agreed that this was still an improvement over the stubborn rafts.

#### Printing woes

In addition to the issues that we faced with the 3D print designs, we had issues with the printer itself.

We chose yellow for our first set out of convenience — the Makerbot was already set up with the yellow PLA material.

For the second set, we needed a different color. We decided to go with red. However, the red material had knots in it. About halfway through our print, the nozzle stopped feeding material. We straightened out the material, but it happened again. The third attempt had us switch spools and use translucent white.

### Tickets and Resources

The next step was to create the destination tickets and resource tiles.

#### Destination Tickets

To make the game balanced, we needed tickets that didn’t favor one resource over another. We agreed to have 25 tickets whose point values differed, but when added together, the number of resources would balance out.

To that end, I created a list of 25 destinations and compiled them into Excel. Each destination had three columns for the resources water, fuel, and snacks, and a total of these three. Each column had a total at the bottom.

Once I ran a heuristic to see that there was a good spread of points per ticket, I went through to make sure that there were no requirement duplicates (e.g. both Cape Town and Hong Kong requiring 3 water, 4 fuel, and 3 snacks).

The tickets themselves were created in Microsoft Publisher, using a vertical business card template. Included on each ticket is the point total, the name of the city, and the water, fuel, and snack requirements.

Future work would have us add more design flair to the ticket destinations. Initial sketches had us give interesting designs to the cards, such as the name of the city in the local language, the airport ICAO code, and a picture of the skyline or something that they city’s known for in the background. Unfortunately, time constraints forced us to only provide the simple design.

#### Resource Tiles

The next items to design were the resource tiles. The resource tiles would be both at the springs and be collectible for use when taking-off and completing a ticket.

Nate printed off a few 3 cm diameter circles on some chipboard in the laser cutter. I found some free-use icons online and modified them slightly.

I printed these icons, then affixed them to the chipboard rounds with rubber cement.

### Iteration and Video

Our next step was to actually perform a user test. For us, this was quite easy — we just got two people to play our game. We were relieved to find out that our concept was good — the game was fun and enjoyable. We did record a few tweaks that affected the gameplay:

• Movement of planes equal to half of the sum of the numbers on the dice, rounded down (was originally just one hex)
• Needed more resource tiles
• Set goal to 25 points (was originally undetermined)
• Rebalance the tickets (have more variation in points per card, more disbalanced resources per ticket — some should require 0 of a resource)

#### Video

We created a video demo of Ground Control. We filmed together using equipment that we had for our capstone video and also took some promotional pictures of the game board.

We did primary shots of different game actions, such as redeeming a completed ticket once a plane takes off, moving trucks for the supply line, and gathering resources.

Nathaniel wrote the script, provided the narration, and did all the film editing. He edited the film on iMovie and made it fit into a 60 second time limit. Unfortunately, he couldn’t find the windscreen on his microphone, which meant that some of the harder consonants of his narration sound rough.

### Lessons Learned

Nathaniel and I had a fun time working together and on Ground Control. Although designing a board game, dealing with weird 3D prints, and having to use handsaws to cut boards is not easy, we had a good time doing so. It provided a nice relief from our capstone project for us.

One major thing that I learned was that 3D printing is still new and developing. I got lucky with my chess piece, as the raft wasn’t an issue and the piece printed out nicely. With Ground Control, I learned that size matters. 3D printers choke on small objects like our planes and trucks.

Another thing that 3D printing the planes reinforced for me is the difference between recognition and realism. I set out to create realistic-looking planes, and I spent a lot of time trying to make a model of a 747 in Rhino, then finding one online. But with the simple silhouette design that I came up with, I was able to create a simple and solid token that easily conveyed the idea of a plane. This to me parallels the difference between skeuomorphism and flat design. Pablo Picasso did a series of drawings where he went from a detailed sketch of a bull and reduced it to its simplest form where it was still recognizable. What matters is what the viewer recognizes — the additional details are wasted time and effort on the part of the viewer.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.