Mechanical Proto Juice [My AMaze 2013 Short Talk]

0 Comments
tuism

I gave a brief Pecha Kucha (20 slides, 20 seconds each) talk at this year’s AMaze Indie Game Festival about effectively using Juice in Prototypes to communicate Mechanics, and was met with surprisingly positive response from everybody from Vlambeer‘s Rami to Nigeria’s SJ to Poland’s Sos, to our own Cape Townian heroes Danny Day and Evan, Ruan, and co of Freelives…

It was a really humbling experience, even if it were only 6 minutes and 40 seconds. Here’s an even shorter Vine of it (big thanks to Simon Bachelier for making this and getting me to use Vine!):

I’ll post the full video of the talk when it’s available, depending on the AMaze organisers.

The full PDF can be downloaded here.

 

And here’s the full talk, without the 6 minutes, 40 seconds limit 🙂
(Kindly excuse the formatting, web code is not my strong suite and this was a wrangled template… >_<)

 

An introduction, I'm Steven Tu and I'm exactly one year into learning game dev since last year's AMaze festival. I've since then made about 6 prototypes and learned much, I hope this will help aspiring new game makers.

 

This talk is all about conveying mechanics in Prototypes by effectively using Juice.Because we're aiming to make a game (as opposed to a book or a movie or an artbook or a music album), the mechanics are the hardest part to test and refine, so we should be focusing on mechanics.

 

This popular talk "Juice it or Lose it" by Martin Jonasson & Petri Purho is super important for any game makers. If you haven't seen it, it's on YouTube and is basically set material for learning to make games. They defined juice and said adding juiciness makes your game better 100% of the time, guaranteed.

 

But prototypes and games are different! Prototypes are made to test concepts by rapid iterations. Thus, adding juiciness DOESN'T always make your game better 100% of the time! Repeat! Prototypes are not the same as games!

 

This notion came to me while I was making my own game Fling Fight. I had made it quite juicy - it was animated, things flashed, explosions were cool, there were awesome screenshakes, and blocks flew around spinning. It was juicy. Yet when I tested, player were constantly confused and asked "How do you win?" and "What're the scary Xs?" and other seemingly trivial questions. I had made the wrong kind of juice and did not help the players play my game, and thus had failed.

 

It might sound obvious, but we, as indie game makers, have to realise that we have chips in the denomination of time. Working on your game is betting your time on various aspects. If you bet wrong, you'll run out of chips. We can bet Time on things, we can bet More Time on things, but we should never spend More Time Than You Can Afford. So we must be careful where we bet our time and maximise their effectiveness!

 

A game progresses from its start as a bad prototype to a good prototype, then from a bad game to a good game. As you add juiciness to a game, there is a Zone Of Wasteful Juice. Adding more and more juice to your prototype is simply wasteful, as you get no real returns from adding that juice. What returns are those? The ability to test and refine your game further - mechanically!

 

The more frequent an event happens the less loud it needs to be. For example, when Mario's clock counts down, all it does is... counts down. There's no fanfare. When he gets a mushroom, the game pauses slightly, and makes the power-up sound. Notifying the player that it's happened. When Mario gets to the flagpole at the end of each stage, the music, and animation, and fireworks take up significant mind and timespace, because it's meant to be significant and rewarding.

 

In QCF Studio's Desktop Dungeons, they had this cool mechanic - the player healed from exploring undiscovered blocks. Players were having trouble understanding that concept, so eventually they made orbs fly from the dungeon to the players' health bars, and players were like "ohhhhh".

 

In my game Fling Fight, when players matched blocks to clear them, two things happened - 1, they exploded, and 2, they made blocks fall on the opponent's side. But people weren't getting that mechanic, so I added orbs that flew to the other side and turned into falling block indicators.

 

In both of the previous examples, there were mechanics that were not what players expected from other comparable games. That the players didn't understand them doesn't essentially mean that they were bad! It just meant that you need to communicate them better before you can *actually* judge if they were bad.

 

This screen came from Chris Bischoff's gorgeous game Stasis. He had used a disc with text around as his mouse pointer... But people didn't get that, and it was obscuring many things and made clicking difficult. Eventually we suggested that he stick to a more conventional pointer, and he seemed to have bought it. If the circle cursor was meant for an innovative mechanic, it wasn't supporting that by being harder to understand for the average player.

 

You (yes you) have one of the most flexible and sophisticated instruments known to man - your voice. You also have a million recording devices from your phone to your computer to everything in between. You should be making sounds! Adding sounds to your prototype is one of the most effective ways to communicate various things. Foley is the art of bashing things to make sound effects. Look it up! It doesn't have to be amazing, it just has to communicate.

 

From human experience, sounds can communicate good or bad easily. Sounds that go up are usually good sounds. Example Mario's coins, power-up, and 1-up. Also Sonic's rings. Sounds that go down are usually not good. For example, Mario dying, Mario's game over. If you were at the talk I would have voiced those effects for you :) These aren't the only conventions, but they're a good start. Think about what people know when making sounds.

 

Don't waste time crafting everything. Just steal everything from online - tilable art, backgrounds, explosions, whatever. Grab them because you're prototyping and not crafting for the next IGF. Don't steal when you're going for release!

 

This is one of my favourite up-and-coming games, Super Time Force. They do something quite cool - all of the enemies' shots are red, and all of friendlies' shots are blue. Usually, this is important, but much more so in this game since it can get VERY chaotic with a single player controlling up to something like 5 time-warped characters. It helps simplify the player experience, and reduces potential for twitch-speed confusion, which sucks.

 

Your prototype doesn't need raycast shadows when a blurred sprite will do. Don't do full vector art when you're not even sure how your characters will need to move. In my game, I was in a big bind trying to write some full blown basic (sounds like an oxymoron but it's not!) AI for people to play against... But it was super daunting... Then Travis Bulford suggested something - just make the AI pick a few random things and pick one of them to do. Done! No more existential crisis AI to build! Fake everything you can!

 

When people play your game, STFU and watch! Don't explain! Everything you say prevents you from learning about what players don't "get" about your game. Your game must work without you, unless you're shipping a copy of your mind with each copy of your game! Don't deprive yourself! Learn by watching, take notes, and listen!

 

Thanks Evan for this great graph! The more you test and fail, the more you level up. Investing your time chips in polish just makes you take longer till that point of failure, and failing is what makes you try again, test again, and get better!

 

When you're prototyping, you spend time in 3 ways: 1. Making prototype 2. Testing prototype 3. Re-iterate prototype and return to 1. The faster you can get through stage 1 the faster you can return to stage 1. The smaller you can make the lap, the more laps you can do, and the more your prototype improves! Make faster failures!