Juice it or lose it - a talk by Martin Jonasson & Petri Purho
grapefrukt12 HN recommenders · 2013–2025
616K views · talk · evergreen · Uploaded 2012-05-24
Martin Jonasson and Petri Purho take a bland Breakout clone and add layer after layer of 'juice' such as easing, particles, screen shake and sound until it feels alive. A live demo makes the effect of small feedback details obvious.
The go-to recommendation on game feel and polish, cited by HN as one of the best talks for anyone making interactive things feel good.
44:10Jan Willem Nijman - Vlambeer - "The art of screenshake" at INDIGO Classes 2013
Dutch Game Garden
1:02:42Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)
DevGAMM
1:15:51Jonathan Blow - How to program independent games - CSUA Speech
Alexandre Franco
53:51The Engoodening of No Man's Sky
Internet Historian
59:47Failing to Fail: The Spiderweb Software Way
GDC Festival of Gaming
31:00Exploring the Tech and Design of Noita
GDC Festival of Gaming
1:17:43'Diablo': A Classic Game Postmortem
GDC Festival of Gaming
48:27Jonathan Blow: Game design: the medium is the message
CreativeMornings HQ
20 comments from Hacker News
Very interesting to read! I guess I'll have to try my hand at multiplayer HTML5 game as well some time, because even reading you, I believe you, but at the same time it's hard to believe that it's hard like that :) Care to elaborate a bit on the part where you say communicating the entire board state was too much data? Looking at your game, I don't see how the board state could be much more than 100 bytes or so? Was it the JSON that bloated it up? If I were you, I'd do it like this: split the state into a static and dynamic part. Player's names won't change during the game. Or if they might, maybe even better to split the state into a high and low latency part. If you see a Player's name update a second too late, it's no big deal, so communicate that via a different, slower, channel. All the other data, the board state, player positions, scores, you don't need JSON if you're transmitting the same fields every time. So make sure everything's a ranged integer and squeeze them together either using a base64 library, or maybe just simply Number.toString and ParseInt with radix 36 (max natively supported radix encoding in JS, and still 5.17 bits/byte), or maybe you hack Unicode/UTF8 to translate integer code-points into bytes and vice versa (you should probably go for the latter, because it'll be awesome ). Oh and then, a tip, when you wrote: > I added some rules and gameplay elements to make it feel more like something one would like to play, including: Feedbacks when you get hit
"Juice it or lose it" is the best presentation I've seen on the matter. It's really funny and it clearly show how adding some bouncing or some particles can completely change the feel of a game (or UI) [VIDEO]
Looks like google needs to watch this video on how to make a good breakout game: [VIDEO] -- Juice it or Lose it.
A little offtopic, but I love the mouse-over effect on the blog header. It makes the text immediately stick out and seem more real — in the sense that this presentation says about making games "juicy": [VIDEO] It's a pity that it only links to a permalink of the blog, rather than being a call to action of some kind.
[VIDEO] Here's the presentation. It's a pretty fantastic watch that shows what just a few small design decisions can do for a product's impressions on an audience.
The articale reminds me a bit of this "Juice it or lose it" talk by Martin Jonasson and Petri Purho. [VIDEO]
The talk juice it or lose, by Martin Jonasson & Petri Purho, is all about this. Gotta be one of the best talks for anyone trying to make things interactive that also feel good. [VIDEO]
People normally call that making it "juicy". There's this awesome presentation on YouTube showing how a boring game can look awesome with some "juiciness", even if the core gameplay is unchanged: [VIDEO]
Wow after all the bad kerning jokes I can't believe I didn't think of this. So well executed too, very addictive :) Could 'juice'* it a little (*) [VIDEO]
Regarding your second point, there is this talk by Petri Purho (Noita) about making a bland game feel fun to the user: [VIDEO] As for your first point, I would suggest aspiring devs to try to prepare themselves to take part in "game jams". The constraints (including a time constraint) help focus on important parts. [LINK]
I'm reminded of the talk "Juice It of Lose It" < [VIDEO] >. This looks like a very juicy game. There's also an excellent video by Mark Brown, a fantastic resource for game design discussion < [LINK] >
> classic talk about juicing your game This one? "Juice it or lose it - a talk by Martin Jonasson & Petri Purho" [VIDEO]
This reminds me of the "Juice It or Lose It" talk. [VIDEO] I'm not sure I'd ever do any of this to a normal checkbox, but it's an essential skill in game development.
I had periods of time where I played nothing but a single game, though those were never more than a few months. Definitely seems like it would be good for your son to broaden his gaming horizons somewhat. Re: "Juicing" - I saw the word and immediately assumed you were using the definition from this classic gamedev talk, well worth a watch: [VIDEO]
I believe the term comes from the game development sphere originally. Martin Jonasson & Petri Purho (creator of Noita and Crayon Physics Deluxe ) gave a famous talk about it in 2010, Juice it or lose it : [VIDEO] Another classic talk on the same topic comes from Jan Willem Nijman in 2013, The art of screenshake : [LINK] It's nice to see these terms being adopted by the wider software development industry, though I doubt we'll be seeing much screenshake on websites or utility apps any time soon.
Related. Syntax.fm podcast interviewed the creator of Wordle[0]. In it he talked about seeing a talk[1] about adding "juice" and how it influenced some of the UX decisions for the game. I personally think that Wordle had the perfect amount a juice for what it was, a web game that involved text/reading. I think it's nice to add some juice to website/apps but they are not games and I think should be kept at a minimum. Know your audience. I don't want any of my finance related apps full of unnecessary juice, but that doesn't mean I don't want feedback for any processes I'm waiting for. Sometimes apps try to be cool/edgy with fancy transitions and those things look cool the first few times I see it but get annoying after that because I'm having to wait for it every time. Anyways I am rambling but you get the gist, don't overuse juice and the level of juice depends on your audience and the nature of your product. 0. [LINK] 1. [VIDEO]
Back in the days when I started with game dev hobby projects: "Juice it or lose it", which I think also includes valueable lessons to making "joyful" UX in apps, too. [1] [1] [VIDEO]
Don't worry too much about 3D (though Godot will make it easy enough to switch from 2D to 3D and even combine both) but focus on fun instead: [VIDEO]
Resources which helped me get started: "Challenges for Games Designers" by Brathwaite & Schreiber. This was by far the most helpful, as it laid out a process of finding & refining fun game ideas. "Game Feel" by Swink. Examines why jumping feels better in Super Mario than Donkey Kong, why Street Fighter feels the way it does, etc. This way of breaking down & examining mechanics was eye opening and can be applied to other kinds of games. lostgarden.com, especially [LINK] , which describes a process for rapidly iterating on ideas, and [LINK] , which introduced me to some of the fundamental building blocks of game mechanics. Resources which helped me later: I found "Art of Game Design" to be helpful later, when working on making a good game into a great game. The different lenses were great for finding areas where I could improve a game. [VIDEO] really drove home how important polish is. This was useful after I had a game which was already a bit fun. Finally, an observation & a suggestion, if you're open to them: You admit that you don't know game design, yet you're attempting to innovate by removing limits. This seems like an enormous challenge for a beginner, like someone who doesn't know how to play an instrument attempting to make a new style of jazz. I think you'd have more success if you learned to play the instrument first: Practice by making a lot of small games. Spend 2-4 days on each, no more. Learn to use prototypes to explore the design space, searching for ideas with
> With games like this, you might want to spend half the dev time on polish, or the game dev term being juice. see also: 2012 talk "juice it or lose it" [VIDEO] "A juicy game feels alive and responds to everything you do tons of cascading action and response for minimal user input."