21. Lazy Engineering, Pt. 1
FUNCTION Scale
Variables: how much, how long, grow/shrinkboolean
VAR: record the starting time
WHILE time is smaller than “how long”
Change scale toward “how much”
Repeat function with opposite bool to reverse
Confirm:
Powerup:
Notice me:
Grow:
23. Lazy Engineering, PT 2
• LIST: all nearby nodes tomonster
• FOREACH node in list
• IF node is valid
• Random chance ofpicking it
• IF node chosen, movemonster
• ELSE repeat function
Game idea: Track down a monster
Code ideas: A* pathfinding, preset paths...
LAZY
CHOICE
TOO
HARD
Xin chao! Thank you for coming. This is a session about prototyping games, with some parts specifically about prototyping for mobile phones. First I’ll tell you a little about myself. I didn’t actually start out in the game industry. I was a journalist for several years, writing for Silicon Valley news outlets and some internationally known companies like CNN and the Economist While I was covering games, I decided that I wanted to make things instead of just talking about them. So I got this passion for actually doing things, building things, even though I didn’t want to be an engineer. I started off as a consulting game designer. We released an RPG called Vampire Legacy on Facebook, then some small mobile games. I was lead designer at a startup called Mixr until recently, when it got acquired. Now I’m building my own company, called Chronicle Games. This talk is about something I’ve been specializing in, which is gameplay prototyping. I’m not sure about here, but prototyping is becoming a big subject in Silicon Valley. People want to understand it, because it’s not quite game design, and it’s not just engineering either. I’m here to talk about what I’ve learned doing prototyping for mobile games.
So the topics of this talk are: 1. One, first we’ll talk about what prototyping is, not just for mobile games 2. Second I’ll talk about how I think prototyping has changed, since the changes are very important to prototyping today 3. And last, the best part: talking about some tips I’ve picked up
Let’s start with quickly defining gameplay prototyping
I asked myself: how would I explain prototyping to someone who has never heard of it before. It’s simple: testing out an idea without being too risky. For example, outside of games, in television, companies will make a pilot episode of a show to try to prove they have a good idea. More specifically, you can answer questions you have. You may want to know: what if I start with a pinball game and make the balls be able to destroy things on the board? What if I take a card battling game and let the cards level up like characters in an RPG?
The reason we prototype is that no designer or executive, no matter how good they are, can think of ideas that are guaranteed to be fun. I was a journalist, I met the smartest people in the world. I met people who had launched games that made a hundred million dollars. Then this same person, this same brilliant genius, would have a new idea and put 4 years into it. And it would completely fail. Traditionally for a lot of companies, game designers will design by making a document, then the company will build the game. Maybe the game succeeds, maybe it fails. With a prototype, you can be more sure about whether it will fail. It’s knowing, instead of just having a theory.
Not all companies work without prototyping though. Which companies prototype? Most of the really good ones I know about do. Plants vs Zombies had a very long prototyping period. In Mario 64, Shigeru Miyamoto had his team work on both the 3D movement and especially 3D camera prototyping, because it had never been done before. He said: when the prototypes were done, the game was done. All they had to do was build everything (art, levels, etc) -- the easy part. World of Goo is a game that’s popular, it actually started as a 1 week prototype by a student. It’s an indie game. Many indie games start as some kind of prototype.
Here’s an example of two companies who do really well right now on mobile and the scale of their prototyping and testing of game ideas.. They don’t give specific numbers about prototyping, but King said.. Supercell said.. I’m going to come back to these companies.
So moving on from talking about what a prototype is, let’s talk about who prototypes. My answer is: anyone who can build a game can prototype. The only problem is that prototyper isn’t usually a role. We call ourselves a game designer, an artist, an engineer, maybe even a marketer. So an artist will do art concepting, an engineer will do technical prototyping, a game designer will just get drunk... remember that the point of gameplay prototyping is to test out the gameplay. Not the art, the code, or even the market fit.
So moving on, let’s talk about what it means to prototype for mobile phones.
To me, four big things have changed.
This is the most obvious change. In the AAA world, prototypes could go on for months. In the mobile world, we build the whole game in months. My own belief is that a prototype for a mobile game should be achievable in 3 days to 30 days. The reason I say 3 days is that I’ve been to a lot of game jams, and almost all of those last for 2 days. Usually people almost complete their idea in those 2 days, but just need a little more time. So 3 days is good.
A month would be a really long time, in my opinion. And a lot of the reason why a month is a long time is that technology has gotten a lot easier to use.
So let me give you an example of the tools I’ve looked at. You don’t have to write all these down, I’ll share the presentation. All of these engines OK for prototyping, but most are also good enough for professional development. The important thing is that they’re easy to learn and avoid a lot of technical hassle. Personally I like the first ones listed, and I mainly use Unity now. Physical prototypes can be nice for helping the team understand, but if you’re making a digital game, focus on a digital prototype.
So how do you pick a tool? From the engines on the page before this, I put some time into maybe 7 of them to try to use for prototyping or game jams. What I found was...
Smaller is better for prototyping. It’s maybe fastest with 2 people -- one engineer plus one functional designer is good. But 1 person can do it alone very efficiently too.
I want to return to the idea of failing. It’s new in some ways. A few great companies like Nintendo had this idea in the past: that it’s OK to fail, that it’s great to fail early. But this is the first time that idea is becoming popular. At these companies, employees can fail many times and not worry about their job. The failures ensure that games that are released, do well.
These are some games where failure was not OK, and they did not prototype before building -- just these four wasted years for hundreds of developers, and spent over $250 million. Still happens a lot today. But now you can study the idea of failure. SuperCell has talked about it a lot. Besides, companies like Rovio have talked about how much they fail. Rovio: over 50 games until Angry Birds.. failures always happen, and prototypes always shorten the time until you fail.
Iwata on Miyamoto: His first goal is always the same – a [prototype,] very limited and very clear. The amount of time being spent on the game’s appearance is zero. Spry Fox thinks the same. I think... use enough art to get the theme / feel across. Just use free resources (clip art, OpenGameArt.org, etc)
There’s something similar to art. In a game, “juicy” is the word for knowing something happened. It’s feedback. Or you could say it’s like the MSG and salt in your pho. It’s what gives it taste. This is much more important than art for prototyping. Maybe the monster in your game is just a blue box. But when you hit that blue box, it should explode! Juiciness is communicating with your player about the results of actions.
So I’ll give you an example of how to do juiciness in a game prototype. The problem with feedback is that it can take days to polish, when really you want to spend minutes. The solution is to build up a selection of code-based effects that are flexible. This is pseudo-code for a simple scaling effect that can look a lot of different ways to players if you give it different timing. Especially if you combine it with another simple effect like fading in or out. Then copy & paste them over and over in your prototype. Each time you reuse simple code in your prototypes, you’ll save 30 minutes or more.
Famous game designer: “If it takes under 2 days, just do it” Mobile version: If it takes under 2 hours.
Engineering for a prototype is completely different from engineering for a game. If your code is clean and elegant, you’re doing it wrong Example from my prototyping: needed pathfinding, chose a recursive function that I was sure wouldn’t work -- but I did it anyway because it took less than 1 hour to build & test (faster features first!). It was a big win because the gameplay was actually more fun than I expected. Peter Molyneux story: “The fact that I programmed it meant some of the fundamental things that programmers can do in their sleep I couldn’t do.” A particular problem was getting the virtual people to navigate around walls rather than getting stuck. “I didn’t know how to do that. I tried to do it, tried to invent it myself and couldn’t and I thought ‘oh fuck it, I’ll just get the player to solve the prolem for me by raising and lowering the land’. That became the game’s fundamental mechanic. Pure and utter luck. Suddenly you’re raising and lowering land with little people, “Ah! You must be a god’.”
I’ll talk for a second about something that’s just for mobile devices. I think it’s almost as important as juiciness. For a mobile device, even though we’ve had touch screens for over 5 years, game designers are still figuring out how to use it as a controller. A lot of games come out with bad touch control, and they fail. The best games, especially the arcade games, have really simple controls. So this is a good thing to focus on prototyping for mobile. Even if your game has turns and doesn’t seem like it needs good controls, you can use prototyping to figure out ways to really improve how players use it.
This is more about arcade games on mobile. I think one of the most important things we can experiment with is changing the ideas we have from computer games, changing the ideas we got from console games. On mobile, you can’t assume that players can play same way. If you take an old game like, let’s say you could put Street Fighter on a mobile phone, if you don’t change how much the player has to react, I guarantee you it will fail. That’s why there are hundreds of old games from handheld devices on mobile phones and almost all of them have failed. So think about how much the player has to touch the screen and do things. Taps allow the most actions per minute; swipes are less (more concentration). Each interaction type you add makes it harder. Time people playing other games, count the taps / swipes in a minute.
Normally people are only interested in successful games. For a prototyper, knowing about the thousands of mediocre or failed games is useful too. Knowing about mechanics from other games is a shortcut for actually building them.
Whether a game is big or small it includes a “toy”: some thing the player does over and over, that makes them feel powerful. This is an Asian-style social battle game with hundreds of features, but if you prototyped it you would make this screen first. The toy here is the cards: you wait and time it out, then when you finally click, you feel powerful and successful.
Going back to the Mario 64 example from before, they prototyped for the motion and the camera: not for boss fights or level design. They didn’t have to prototype for the level design because the toy was perfect.
I’ve mentioned failure at the beginning and middle of the presentation... now I’ll also end with it. It’s really important. And it’s the one thing that’s the same for any prototyping. You want to fail. When you do, you want to be disciplined enough to admit that you failed and move on. Let it burn.
