Juice it or lose it - a talk by Martin Jonasson & Petri Purho

> 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" ▶ this video "A juicy game feels alive and responds to everything you do tons of cascading action and response for minimal user input."

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. ▶ this 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

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: ▶ this 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] ▶ this video

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. ▶ this 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 : ▶ this 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.

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: ▶ this video

This reminds me of the "Juice It or Lose It" talk. ▶ this 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.

> classic talk about juicing your game This one? "Juice it or lose it - a talk by Martin Jonasson & Petri Purho" ▶ this video

I'm reminded of the talk "Juice It of Lose It" < ▶ this 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 >

Regarding your second point, there is this talk by Petri Purho (Noita) about making a bland game feel fun to the user: ▶ this 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

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 (*) ▶ this 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: ▶ this 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. ▶ this video

The articale reminds me a bit of this "Juice it or lose it" talk by Martin Jonasson and Petri Purho. ▶ this video

▶ this 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.

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": ▶ this 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.

Looks like google needs to watch this video on how to make a good breakout game: ▶ this video -- Juice it or Lose it.

"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) ▶ this video

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