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

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

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

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]