Game Design Workshop Wednesday Exercise 1.2: D.O.A. #GDWW

Welcome back! Last week, I pretended to be a tester for the indie hit FTL and documented everything I experienced and did in the game. This week, the second exercise of the Game Design Workshop Wednesday series makes me nervous: writing down what I didn’t like about a game.

Each week, I’ll go through an exercise from Tracy Fullerton’s Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Third Edition. Fullerton suggests treating the book less like a piece of text and more like a tool to guide you through the game design process, which is why the book is filled with so many exercises.

This section of the first chapter discusses what it takes to make a game. Good communication skills, teamwork, and a good dose of process are all needed.

Exercise 1.2 asks you to think about a game that was dead on arrival, then write down what you didn’t like about it and identify how the game could have been improved.

As I said, I’m nervous about this exercise.

Nervous about writing that I didn’t like a game? This is the Internet! People do it all the time!

I’m nervous because I don’t like raining on someone’s parade. Even if a game was flawed, there are people behind it who put their livelihoods on the line, who may have struggled and fought to get this game out the door. It’s easy to complain about the quality of something when you don’t have an idea of what went on behind the scenes.

In this case, I have some idea. I attended the post-mortem of Charlie and the Chocolate Factory back in 2005, hosted by the Chicago chapter of the International Game Developers Association. It was a fascinating look behind the scenes, with tight schedule pressures, lots of stakeholders, and a team that managed to pull it off despite having to throw away a lot of development effort more than once throughout the project.

I can’t find any information for how well it sold, but reviewers weren’t impressed with the game. I remember reading that it bombed in the market, although even poorly made licensed games tend to sell fairly well so it’s hard to say.

I met a developer who worked on it, and he had mentioned what a frustrating experience it was…to put it nicely.

I purchased the Gamecube version when I saw it discounted and put in the impulse-buy section of the checkout line at the store. My thought at the time was that playing bad games means I’ll better appreciate what it takes to design a good game.


I haven’t played it since I got it, and even then I didn’t get too far before giving up. When I started a new game recently for this exercise, I was experiencing it almost as if it was the first time.

Starting The Game

The first thing that struck me is the music loop on the title screen. Most of the time, music loops are seamless, as if you couldn’t tell that it stops and starts. Instead, there’s a noticeable cut. Now, this might be a minor thing, but I started noticing quite a few areas that felt similarly unpolished.

The game starts with a pre-rendered movie introducing the story, including the other children finding the golden tickets and Charlie feeling poor, until a $10 bill appears at his foot. Then the game starts, with you chasing the bill as it flies improbably around town.

Whenever you get close to the money, wind blows it somewhere else, and so you go chase it. When the money gets caught on a chain-link fence, some help text appears and says, “You have the knock the money off the fence.”

Now, what comes immediately to mind is that I need to perform a specific action, such as throwing something at the fence, or walking up to the fence and pressing an action button of some kind. But no sooner did I have this thought when I found out that walking up to the fence is all that is required. The fence shakes as you near it, and the money flies away. Now, why the heck did I need help text to tell me to do something if the most natural thing to do, walking towards the bill like I’ve been doing the entire time, works just fine?

Later I found myself frustrated because I didn’t know what to do and there was no such needed help appearing.

Ah, I can pick up boxes, which means I can put them down and climb on them to get to higher places. The help text tells me what button to press, which is fine as I’ve never done it before and so wouldn’t know what to do to pick a box up.

When the bill ends up flying onto a roof, I noticed the cutscene was not pre-rendered and seemed to use in-game graphics. Charlie slides down a roof for about a second, and then I can play again. Uh, ok. So I walk over to the bill, which is stuck on a chimney, and…another cutscene.

This one is another example of a lack of polish. Charlie screams “Oh, no!” yet doesn’t look like he is doing anything that matches. It’s as if they recorded the audio and made the scene separately, then never put them together until the last moment. It takes a few seconds after the scream before Charlie starts to fall.

Ok, so Charlie falls. He lands on a garbage can lid, apparently at the highest point of the town, and now you’re chasing the bill while sliding through the icy streets. You can knock over snowmen and garbage cans, and trucks pull out from side streets, but nothing actually hurts you and there’s no point but to get to the end of the sliding, where Charlie lands in front of a candy shop with his new treasure.

The Cutscenes and Augustus Gloop

If the introduction was a pre-rendered cutscene, and the other cutscenes were using the in-game engine to render them, Chapter 1 starts now, with page-turning transitions and…suddenly everything is hand-drawn? Oh, and Chapter 2 starts right after without any game play in between. These inconsistencies contribute to the feeling of a lack of polish, as if the game wasn’t finished or was rushed.

When I finally can play, I’m supposed to find two Oompa-Loompas to work on some machines to pump Augustus Gloop out of the tube he is stuck in. Now, the bellows are hidden under the meadow, which was a neat way that the level designers were able to work around the fact that they were required to use the movie sets, which normally aren’t created to make for good game play.

Once Gloop is freed, you are told to find some Wonka-Vite for energy in a quick cutscene. You are also given Ever-Lasting Gobstoppers, which function as a projectile weapon. You can throw them at trees and objects to knock candy down.

So, using some gobstoppers and an Oompa-Loompa’s help, I manage to procure some Wonka-Vite. Now what? Grandpa Joe’s advice to find Wonka-Vite when I already found some didn’t help matters. I must have walked around that meadow a half dozen times trying to find an exit before I discovered I had to find multiple Wonka-Vites before I could proceed.

Why couldn’t there be a mission objective to indicate how many I had to get? Also, it wasn’t clear what “energy” it was giving me, as I didn’t notice I was using any energy in the first place. The HUD shows some tubes on the top right, but the game gives no context for them and they didn’t seem to matter, so I ignored them. Plus, the controls felt a bit awkward, as it was difficult to aim the gobstoppers, jumping around felt sloppy, and occasionally the camera would end up in an bad angle. All of these things combined made me feel confused and frustrated as I played.

The Jelly Beanstalk Level

The next level shows that Gloop is still stuck in the pipe, only this time in the jelly beanstalk room. You can now use Jelly Beanstalk Candy, which you can throw to create vines which snare the unwary. Oompa-Loompas seem unaffected, and they don’t seem to do anything to Charlie, either. Oh, I see. Once I get the Wonkabots to appear, I can trap them into a ball of vines, then throw those balls into the vents to help increase the pressure to get Gloop through the tube.

The vine balls appear near where the robot and the vines are, but they never seem connected quite right. The vents are in a thorny patch I can’t walk on, and it took me some time before I realized I could throw a vine ball into the area to try to get them into the vents.

The entire level is geared around multiple floors of vents arranged in various angles in a patch of thorns, with nearby Oompa-Loompas who I charge with fixing the machine to create Wonkabots so I can create vine balls and throw them at the vents over and over until I succeed in getting them all. Oh, and between each floor, I need to jump from leaf to leaf of the giant jelly bean plant, which is not very easy to do. Haven’t enough people complained about jumping puzzles over the last few decades? And the target audience has to be children who may or may not be as dexterous with the controls, right?

So after saving the jelly beanstalk plant, I find that Chapter 3 starts, and I end my play session.

Summarized Thoughts

Again, I feel bad about writing about all of the bad things about this game, knowing what the development team went through. And perhaps it isn’t fair to call it “dead on arrival.” I’m leaving out the bits of delight I experienced because I’m focusing on what was wrong for this exercise. Considering how rushed it was and the constraints they were under, they managed to put together something. It just never felt cohesive or polished, and the few times I was pleasantly surprised by the game were marred by the confusion and frustration and tediousness of the rest of it.

For instance, why was I allowed to hit the Wonkabot with a gobstopper and see an animation of it falling down if there wasn’t supposed to be combat? Or why was candy allowed to get stuck on top of trees, resulting in Oompa-Loompas tasked with collecting the candy running in place? Why were some cutscenes pre-rendered, some in-game engine, and some illustrated, and why were there so many of them?

Possible Improvements

Some consistency would have helped, and I think if they had more time to playtest, they would have found areas which were confusing to new players. Letting the player know that Willy Wonka wants you to find five Wonka-Vites, for instance, would have meant that after finding the first one, I wouldn’t have felt lost. Perhaps the controls could have been tightened up, although I wonder if part of the problem is how Charlie was animated. I recall picking up a vine ball next to the thorny patch, only to be surprised that Charlie’s pick-up animation moved him forward into the patch, which forced him to drop the ball. I also wonder if the game could have been improved if there were fewer cutscenes, allowing more of the story to be revealed during game play instead.

But of course, these things take time, and when your deadline is the release date of the movie with a quick production schedule, things can slip. It’s hard not to imagine what the game could have been with a little bit more polish, as the people who worked on it loved the story and probably feel terrible for every flaw they know about that I might not have noticed.

Exercise Complete. Pencils Down.

That’s it for this week’s exercise. If you participated in exercise 1.2 on your own, please comment below to let me know, and if you wrote your own blog post or discuss it online, make sure to use the hashtag #GDWW.

Next week, I’ll describe five areas of my life that could be games.

Game Design Workshop Wednesday Exercise 1.1: Become a Tester #GDWW

Welcome to the first exercise of the Game Design Workshop Wednesday series!

Each week, I’ll go through an exercise from Tracy Fullerton’s Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Third Edition. Fullerton suggests treating the book less like a piece of text and more like a tool to guide you through the game design process, which is why the book is filled with so many exercises.

The first chapter explains that the role of the game designer is to be an advocate for the player. Playtesters are essential for the feedback they provide because otherwise you are designing games in a vacuum. If you don’t bring in playtesters early in the design process, you will have no idea how your game will be received when other people finally do play it.

And so exercise 1.1 challenges you to take on the role of a tester. Play a game, and document what you are doing and how you are feeling.

I chose to play FTL: Faster Than Light, the space-based roguelike from Subset Games. I purchased it a couple of years ago, but I saw people mentioning online that it had some updates, so I fired the game up again.

My First FTL Game Over

I started a new game, and I noticed that there was an option to enable Advanced Edition Content. I opted to leave it disabled for this playtesting session. I left the difficulty on Normal, and I hit Start.

I read the brief text telling me that I’m trying to get data to the remaining Federation fleet before the Rebels can catch up to me. It occurs to me that I’m the kind of person who roots for the underdog, and I wondered about the design choice of being on the side of the presumably better-equipped and much larger Federation.

I remember I preferred to have one member of the crew in the shield room, so I reassigned the one from the engine room. I found that a good part of the game was spent moving crew around to repair damage, put out fires, fight off invaders, and enhance capabilities such as those shields. I don’t remember if the hotkey to assign people to specific stations was there in the original game before the updates, but I just noticed them this playthrough and really appreciated it. When new crew members joined the ship, I found myself assigning them to their strengths, juggling responsibilities if needed.

Rather than risk the lives of my crew to out-of-control fires, I found I liked the idea of venting the air out into space by opening the doors and waiting. I lost too many good people in multiple playsessions before I learned that lesson.

When it came to jumping from one beacon to another, I thought about how I made the decision of which one to choose. While I kept the approaching rebels in mind to make sure I didn’t dawdle, I found that I preferred circuitous routes in order to get more opportunities to answer distress calls and collect supplies. I only took more direct routes to the exit beacon when I was my hull was badly damaged and I wanted to avoid as much interaction with the locals as I could.

After arriving at a beacon, there would be a random encounter. Sometimes it was a fight with a pirate or rebel scout. If I had a choice, I found myself coming to the rescue of another ship or attacking slave drivers. It seemed that despite the main mission, I made choices based on principle and morals. Well, most of the time, at least. I needed to ensure I survived, so the times I chose not to enter a fight were the times I couldn’t.

Sometimes I jumped instead of fighting so I could live to fight another day. Sometimes I fought rather than surrender needed supplies.

Often, I died. So much dying. If I was juggling crew members at the start, it’s nothing compared to frantically trying to move the lone surviving member of the crew from one fire to another while the ship has been boarded and the enemy ship is still attacking while your own weapons are down. He or she could not repair anything fast enough before the lack of oxygen or lack of hull ended the game mercifully.

During a fight, I had to choose which room of the enemy ship to attack. I liked knocking down their weapons, which saved my hull while I continued the attack with impunity. If it was a scout ship revving up its FTL drive to alert the rebel fleet, I would try to attack the engines to stop it. Sometimes I found that I couldn’t get a missile past the drone defending the ship, so I started striking at the drone control room to disable the drone. I sometimes attacked shields, but often I found that my multi-shot lasers would knock them down and still get some hits in, so early in a game I focus on weapons instead.

If I collected enough scrap, I could upgrade the ship. Did I improve shields? Weapons? Engines? Do I improve them now, or wait a little longer in case the scrap could be used on better purchases and upgrades later? If I waited too long, I would fight stronger and stronger ships until they badly outclassed me, but if I upgrade too soon, I might not be able to afford new crew members or better weaponry if I find a store.

When I did get new weaponry, I found new attack options opened up. Attacking empty rooms means bonus damage? Well, ok then. Also, if I upgraded my sensors, I could see the enemy crew on their ship, so I could purposefully try to attack them if I see they are weak. Fewer of them means less opportunities to board my ship or repair theirs.

Every so often, I come across a quest marker. For instance, I was asked if I was willing to defend a space dock from a rebel assault. Well, why not? The fight was easy, and I get a reward. Or I would have, had the rebel fleet not overtaken the area where I would go get my reward. Oh, well.

When I find myself in rebel fleet space, the battle is intense. There’s no quarter given or taken, and I find myself frantically trying to repair hull breaches and engines to jump away to safety, but I rarely succeed.

When I do lose the ship and the total score is tallied, I see how this session compared to previous sessions. I want to get a higher score, and I also want to make it past the latest sector I’ve arrived at. It’s enough to make me want to replay each time.

So there you have it. I documented my experience playing FTL, and I gained an appreciation for just how much is going on in this game. If you participated in exercise 1.1 on your own, please comment below to let me know, and if you wrote your own blog post or discuss it online, make sure to use the hashtag #GDWW.

Next week, I’ll be writing about a game that was “dead on arrival”, talking about what I didn’t like about it and how the game could be improved.

More Game Mechanic and Algorithm Visualizations

Sometime back, I wrote about GameMechanicExplorer, which was a new site that allowed you to explore game mechanics interactively.

Seeing a new technique represented in a visual space can help make it easier to understand, especially if the math or algorithm is complex.

If you’ve ever done searches online for game development, you’ve probably come across Amit Patel’s website, which acted as a public set of bookmarks for various game development resources.

RedBlobGames 1

In the last year, he started posting interactive visualizations to explain topics such as lighting and visibility, A* pathfinding, probability, and using noise to make procedural generation look natural, among others.

RedBlobGames 2

I enjoyed his article on procedural map generation in the past, but being able to see (and hear) how noise works and learning about the different kinds of noise in one place is amazing.

In general, you can find a lot of great game development resources at Red Blob Games, but these new visualizations add a lot of value. Thanks for posting these, Amit!

Introducing Game Design Workshop Wednesdays #GDWW

Recently I was sent a review copy of Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Third Edition by Tracy Fullerton. Fullerton is the Chair of the Interactive Media & Games Division at the USC School of Cinematic Arts and won the IndieCade 2013 Trailblazer award, which is an award given annually “to a working game creator who has both made great contributions to the field of games and captures the independent spirit.”

I’ll have a review of the book itself published at a later time, but I’ll quickly highlight the vitals.

The book is split into three parts. The first part is all about game design basics. Terminology is defined, and games are broken down into formal elements, dramatic elements, and system dynamics.

The second part is about taking what you learned in the first part and putting it into practice. You’ll learn how to generate ideas, prototype them, conduct playtests, and refine the design until it is functional, complete, and balanced.

The third part focuses on working as a game designer in the industry, both in terms of job descriptions as well as what life is like working on a team. I note that going independent was given roughly a page in a 10-page chapter on getting you and your ideas into the industry.

I think the book overall covers a lot of ground, provides lessons as well as examples, and even features the wisdom and advice of many prominent game designers such as Richard Garfield, Josh Holmes, Jenova Chen, and Will Wright. I think this book is a great addition to my game design library.

Of course, merely reading a game design book won’t teach you game design anymore than reading an art book will teach you to be a painter.

You need to DO game design to become a game designer.

This book has plenty of exercises throughout its chapters to guide you through creating your own playable game designs. As Fullerton says in the introduction, “If you think of this book as a tool to lead you through the process of design, and not just a text to read, you’ll find the experience much more valuable.”

On that note, I’d like to introduce Game Design Workshop Wednesdays. Each Wednesday, I’ll take an exercise from the book and go through it myself, sharing what I’m doing. If you’d like to follow along at home, you can click on the link above to get your own copy through Amazon.

So join me next week as we learn and create games together. I’d love it if you left comments to share how you did on your exercises as well. Alternatively, if you would like to write your own blog posts, or tweet or otherwise participate on your own, use the hashtag #GDWW so we can all keep in touch.

Why Does Your Game App Need My Browser History and Photos?

Years ago, I started paying attention to the usage of so-called digital rights management (DRM) in games and made my purchasing decisions accordingly. I might have missed out on some major cultural impacts, but I wasn’t going to passively accept what I thought was a draconian form of copy protection. A form of protection that, by the way, doesn’t even work most of the time, so only legitimate customers get punished.

In practice, it meant not buying many major games. Spore is one very famous example, and I wrote a bit about it in this post about it’s reception in the market. Reading it today, I can see I was a bit angry about the DRM:

Do I like the game? I haven’t played it. Apparently Spore has some crappy so-called DRM solution attached to it, and it’s definitely not available for Gnu/Linux, so my choice is to boot up Windows AND suffer this DRM crap, or play a different game on my preferred system. It’s too bad. If things were different, I’m sure I would have liked Spore, too, but I refuse to pay for a steak dinner delivered on a garbage can lid.

Ooh, burn!

It was my attitude, and it still is today, partly because DRM is fundamentally flawed and partly because it’s a system that makes it easier to be a criminal.

But this post isn’t really supposed to be about DRM. Today, I find myself concerned about downloading free-to-play games on my smartphone that require bizarre permissions.

Recently, I was looking for a good strategy or simulation game to play on my Android smartphone. I found some that seemed promising and popular, and I found myself stopped when I clicked the install button because the requested permissions were ridiculous.

Why does this game need access to my browser bookmarks and history? Or why does that game need access to my photos?

Actually, it seems that Google’s API just doesn’t allow very fine-grained control of what is and isn’t allowed to be accessed by an app. According to this What’s on Dave’s Droid? post, if an app needs access to the state of the phone to know when to minimize if a call is coming in, it has to get that information from the same permission that gives it access to the identity of who is calling.

And this isn’t a new story. I’ve just only become aware of the problem myself.

I get that the permissions section can’t be too complex for the user experience. People don’t read EULAs as it is, and I’m sure many apps are perfectly safe, but is it weird that we’re being so trusting of apps by hoping that they don’t cross a line we’ve given them permission to cross? Especially in a world where we know we’re being spied on?

For now, I feel that I need to treat some apps just as I treated games packaged with so-called DRM. I’ll ignore the ones that ask too much or that are made by someone I have no reason to trust. Maybe I miss out on a gem, but I’ve survived without Sony’s rootkits and the pain of not being able to install a game I’ve legally purchased in the past. I think I’ll survive not playing a game that may or may not be compiling a list of my contacts and recording my location.

Follow GBGames on Google Plus and Facebook!

Association of Software Professionals

Twitter: GBGames