Home
Artists
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register
Partychan Telegram ThePornDude
Home Artists Posts Import Register

Help me write a talk! (Patreon)

Published:
2017-06-16 13:09:19
Edited:
2017-06-16 13:47:13
Imported:
2021-01

Content

Hello! So, I’m going to Prague this month to give a talk on game design.

(If you don't care - I'll be back later with a video!)

The conference is for HTML5 and Javascript developers, so it’s going to be focused on quite fundamental design stuff that will be applicable to more simple web and mobile games

I’m calling it “10 most important things I know about game design (despite having never made a game)”, and while I’ve got about 8 1/2 I wanted to get some ideas from you lot - especially the real designers among you! - for what I could include.

Here’s what I’ve got so far

1 - Find the gameplay first. Talking about the tendency to get hung up on stories and graphics when gameplay should be of primary concern. Examples of the core ideas / inspirations behind some top games. (Note: This is less of a rule and more of a suggestion. I know many great games start with stories!)

2 - Make form follow function. Talking about designing characters and objects to explain their properties through design.

3 - Make the game fit the device. Talking about the unique properties of mobile, and how games should take advantage of the hardware, not try and make the hardware fit around the game.

4 - Do more with less. Talking about versatile verbs and dual purpose mechanics. Aka my favourite things.

5 - Help players find the best experience. Talking about how developers can encourage different behaviours in their players.

6 - Remove frustration, add fun. Quick tips for these two things, like hitboxes and Super Mario World’s dynamic pokeys.

7 - Get the difficulty right. Some general difficulty talk. Flow, and different ways to handle difficulty.

8 - Pick the right mechanics. Looking at how different mechanics can lead to very different feelings. 

9 - Make it juicy. Juice and game feel talk. Making your hands, ears, and eyes happy!

What am I missing? What needs to go? Why did I agree to do this? Thoughts in the comments would be appreciated! 

Files

Comments

Anonymous (edited)

Comment edits

2023-06-24 04:22:42 浴衣のモルガン陛下可愛くて好き
2017-06-16 13:14:14 Throw out what doesn't work, or which repeats something you've done without advancing or iterating it. You've talked about many games that removed bloat in design phases, and which have mechanics that don't outstay their welcome (Braid comes to mind).

Throw out what doesn't work, or which repeats something you've done without advancing or iterating it. You've talked about many games that removed bloat in design phases, and which have mechanics that don't outstay their welcome (Braid comes to mind).

Anonymous

Test functionality as often as you can. In any project testing small additions as they come makes the whole development process much better than trying to test everything t the end. Build, test, build, test, build, test.

Anonymous

From the top of my head, maybe you could add something about making something distinctive in the game. Something that makes it "special". It could be the graphicak design, the level design, the main mechanic... I know these kind of features are specially difficult to find, and also not necessary for making a videogame (nor necessarily good, some generic videogames are good). But this could add something to they talk.

Anonymous

For #6, make sure to emphasize the consistency of systems that govern things like hitboxes and the dynamic pokeys, so that players can make predictions that inform their decisions and help make the game feel "fair" rather than "broken".

Anonymous

I feel like #1 and #8 are very similar, and also slightly disagree with #1-- if you want to start with the core idea a tone or story, you can use it to make a cohesive game if you design the gameplay and mechanics to fit that story. An expected example, but Dark Souls has a cloying, heavy tone, and harsh gameplay to fit that tone. I agree with not getting hung up on the details of story before the rest of it, though. Maybe that's more what you were going for with #1.

GameMakersToolkit
>>5697366

Yeah, 8 feels weird. I might can that or merge it into 1. As for 1, it will of course come with the caveats that this is not the only way to make games, but is a good way to start out when making smaller, mobile and indie games!

Tom Cullum

Design by subtraction is a good one. Even if it’s not labeled in that way specifically, I think that kind of strict self-editing is important when working on any kind of creative project. If an element isn’t pulling in the same direction as everything else, then it’s probably just getting in the way.

Anonymous

I think the most important thing is consider the decision making of the player. Games are often a test of risk/reward where the decisions a player makes as well as their ability to pull off such is what makes gameplay interesting. It's not enough to just have mechanics that feel juicy or are a cute gimmick itself, it has to work in tandem with obstacles to provide interesting decision making.

Anonymous
>>5697295

This, I'm a big believer that a game (or any piece of art) should have something new or unique about it, and ideally something personal to the creator. Mike Bithell (and others I'm sure) said this, "Make a game only you could make". that Otherwise what's the point?

Anonymous

Iterate iterate iterate... Though there is one more rule to that, one of the most cruel design aspects/decisions -> at some point, you have to ship.

Anonymous
>>5697292

This. As others have said, you need a mantra of 'fail early, fail often' - you need to test test test before you become committed to a bad decision.

Sandro Dall'Aglio

Be very clear about the core mechanic of your game. Every other mechanic should support to it and no other mechanic should become so big that it compete with it.

Anonymous

Aside to what people before me said, I'd recommend to show the game to different people and type of players to see where and how you can improve. Testing comes a bit later in the development but still should be a subject to take care of properly.

Anonymous

These look good! A couple ideas for you to try, hopefully they're all general enough to apply to website designers as well: 1) These items seem concerned with idea generation. That's actually a relatively small part of a designer's job. Most ideas will come from elsewhere, the designer's job is to curate and evaluate those ideas, collect feedback, iterate, etc. 2) Designers spend a lot of time communicating. What's the current design direction? What separates the current implementation from the intended design? It takes a lot of effort to get artists, engineers, etc on the same page and all working towards the same thing. There doesn't seem to be anything in there about communication with a team. 3) You often have many options to choose among when deciding what to tackle next at any given time. Earlier in the project it helps a lot to pick the thing that will teach you the most. In my office designers often say things like, "if we do X we will learn about .." or "we already know Y because we tried ..." It's as though the process of making a game is a journey of learning about what the game is. 4) Similar to what Monica said, it helps to pick a number of 'pillars' or guiding principles around which every feature in the game should support, or else that feature should be cut. AAA games that use this technique tend to have up to 8 pillars, whereas indie games should have one or two. Also along the lines of what she said, there's no reason the two approaches can't be mutually exclusive; even small games benefit when the mechanics and the narrative/fantasy complement each other. 5) I sort of disagree with #6. It's not a designer's job do identify what's wrong with a design. They get that feedback from the team and players all the time. The problem is figuring out what to do about it. Any problem has many solutions, and often when you fix one problem you break other things. OK I'll stop there, hope it helps! Looking forward to seeing how it turns out :)

Robert Wallis

Website designers call #3 "Responsive Design" or sometimes RWD (Responsive Web Design). So using that term may hit a note with them, or they may think they already know everything about responsive design.

GameMakersToolkit

Thanks for this, made lots of changes. Will update you on how it goes later in the month. Keep the ideas coming, though!

Anonymous

Most suggestions are already mentioned, but maybe add to number 5; know your audience/players. Or maybe this one is also one for the comment talking about testing, test as early as possible, don't hold on to your ideas when they don't work.

Anonymous

UI is a Tool, not a crutch. I swear I've dropped so many open world games because they often turn into follow the dotted line in the mini-map while I miss the beautiful vistas the game the developers might as well have not made.

Anonymous

Maybe add a section on adapting tutorials to fit the game, for example mario doesn't have one as it teaches through the gameplay, but something like an rpg might need one in order to explain a new mechanic. Trying to make learning the aspects of the game interesting, and not provide the player with a mound a text as soon as they start.

Anonymous

This is a fantastic resource from the lead designer of the Magic: the Gathering card game. It is written specifically for card/board games, but I think the general ideas still apply: <a href="http://magic.wizards.com/en/articles/archive/making-magic/ten-things-every-game-needs-part-1-part-2-2011-12-19" rel="nofollow noopener" target="_blank">http://magic.wizards.com/en/articles/archive/making-magic/ten-things-every-game-needs-part-1-part-2-2011-12-19</a>

Anonymous

As an addendum to #2, talking about material design of game assets would make a great bullet point. You've talked about this before: a person approaching Mario for the first time can probably already guess that spikes are bad, coins are good, etc. Even though a designer's goal is to teach a player new mechanics, they need to work with the player's intuition and previous knowledge in their pedagogy.

Anonymous

Adjust the game's scale and amount of content to fit your budget/schedule. Lot's of games fail because developers want to cram every idea they have into the game and it ends up feeling rushed or incomplete because of this. Furthermore, a lot of the times this happens, the realisation that you may be in too deep comes late in a project and the time spent adding features and other content comes at the expense of polish.

Anonymous

Something that gets talked about all the time in writing but rarely seems to come up in game design is, always be cutting things that don't work. You've talked about this in videos about Team Ico, but it seems to me to be applicable to just about anyone -- game design, like writing, lends itself to bloat, and benefits greatly from editing. So, "never be afraid, and in fact actively force yourself, to cut things, even things you like". Edited: Just saw the very first comment said this but better. So, seconded to that!

Anonymous

I think that an extrapolation on Sanderson Laws of Magic are very well suited for game design. Specifically law #3 which could translate to: exploit the core game mechanic before adding something new. <a href="http://coppermind.net/wiki/Sanderson%27s_Laws_of_Magic" rel="nofollow noopener" target="_blank">http://coppermind.net/wiki/Sanderson%27s_Laws_of_Magic</a>

Matthew Wilmsmeyer

Edward McMillen of Binding of Isaac had a line I feel was really important in a Gamasutra opinion piece ( <a href="http://www.gamasutra.com/view/news/117521/Opinion_Indie_Game_Design_Dos_and_Donts_A_Manifesto.php" rel="nofollow noopener" target="_blank">http://www.gamasutra.com/view/news/117521/Opinion_Indie_Game_Design_Dos_and_Donts_A_Manifesto.php</a> ) - "If you're just starting out, think small, then think smaller." That may fall under "real world" stuff more than game design, but I feel it's important for those starting out. I've had a lot of projects fail because I was too ambitious out the gate with my ideas.

Anonymous

I'd add: "Let players learn new mechanics/ideas in safe environments before developing them". I don't know if you'll talk about this in another section, but it would be very useful. Also, please post the talk afterwards (or the draft) if possible :)

Matthew Wilmsmeyer

^ Seconding the above. Please record this talk if you can and post it for us!

Anonymous
>>5702405

Also, try to talk a lot about the 3rd point (it'd be nice if we could eliminate virtual controls from mobile games)

Anonymous

I think it's worth keeping in mind that this game design advice is geared towards a specific kind of mechanics-focused game. Like, "Make It Juicy" doesn't apply to Day of the Tentacle; "Get the Difficulty Right" doesn't apply to What Remains of Edith Finch; "Add Fun" doesn't apply to Passage. A lot of game design talks make sweeping statements about the "right" ways to make games that tend to sweep whole genres under the rug. &lt;3

Anonymous

One of my favorite GDC talks was by the folks at Quantic Foundry, where they build a player motivation profile. Long story short, they found that player motivations tended to cluster into 3 categories, story, strategy and excitement. Knowing what your target audience is, or isn't, interested in should help focus the game design to maximize the appeal to the users in the cluster(s) of interest, rather than trying to appeal a little bit to each.

Anonymous

You missed the most important part about game design...Fail Faster...Test Early and Often to know that you have something that adheres to all those previous points. The only way to know your game is fun and engaging is to show your project to as many people as early as possible, even if you think/know it isn't ready

Anonymous

Games are interactive and as such should be experienced primarily via mechanics and as such gameplay first is correct, but how do you know what mechanics are right for your game? In the center should always stay a VISION, everything else, especially gameplay, is supposed to support this vision. It also helps out with the point of avoiding feature creep/ packing too much in. There are different approaches out there: - Jonathan Blow does not focus on gameplay first per se, but rather r&amp;d to find a MECHANIC that excites him enough to make a game about that very mechanic. This is his vision. All other choices are designed to support this one thing. This is probably, what's most suitable for mobile/touch devices. - Darkest Dungeon was developed with a vision for a FEELING first. They exactly knew what their players should feel like and made all their decisions based on that. For example, they started out with top down, but realized that with the 2d view everything looked more cramped and uncomfortable. Since this was their goal, there was no further thinking necessary. - You can also start with a STORY in the center and as a vision. Problem is not that people focus too much on it but rather deliver it in an old fashioned way by thinking: story = film/book,... but story driven games are most powerful if their story IS the GAMEPLAY.

Anonymous

I feel like 2 important things to touch on are (forgive me for not going through everyone's comments to check for repeats) 1: that braid video that a few people are mentioning had a very interesting side point; mechanics just emerging through the creation project. If developers find some silly glitch in their code that's fun to play around with a bit, it could be fun to actually put into the game 2: game designers? more like hoarders. do you REALLY need that multiplayer mode, people? your design by subtraction video could be generalized for some neat ideas

Anonymous
>>5707400

What I'm about to say feels like it should be point in itself: Understanding application. Just because it doesn't feel intuitive if you can't add a screen shake or motion blur to day of the tentacle doesn't mean "make it juicy" doesn't apply. The jingle when you solve a puzzle. How objects highlight in a scene. How they enter you inventory. Transition between characters. Foot steps when they move around. All of these can be emphasized and made over the top. Any sense-based satisfaction is relevant to that - and 'that' is juice.

Anonymous

I'll apologize in advance for this. I think most of what I'll say will refer to this first point. - Understand your core experience - Sometimes what you add is an obstacle, other times just a distraction. If you know what you like about the game, question everything else. This actually means that gameplay doesn't necessarily come first. EG 999 is an immensely enjoyable experience, but it could actually be made more enjoyable if it was less mechanically focused and more streamlined, but would have to have been played at all for it to work. Story is often presented as dichotomous to gameplay, but, for example, in the ace attorney series, story is the gameplay; paying attention and noticing mistakes in what people say can be paralleled to doing the same when people make mistakes in chess. - Keep changing perspective, but return to the overview - Building the mechanics from scratch changes how view it, from how you see it when you play it for a long period, from how you see it when you take a step back. Every perspective helps, but it's also easy to lose track of what's important when you're in the trenches. More relevant to smaller teams than larger ones. We might actually just list off opposing or tangential design theories, because there's also: - Experience first - Miyamoto didn't decide on mechanics when he made zelda. He wanted to recreate the experience of exploring the country side and discovering things he didn't know about. Jonathan Blow's the Witness was apparently decided almost simultaneously as experience and mechanic - in that he imagined the player turning around after walking up a mountain and realizing the path made a pattern similar to "spells" they'd made earlier by drawing lines, thereby teaching them. The experience is epiphany, realization, and seeing something that was always there, and it's everywhere in the game. There's several other important things relevant closer to project management that game design. Manage the scale of the project. Keep motivation and momentum. Pace it so you have every rough element, instead of one polished piece that might not fit - it lets you get a better view of what the final product is and saves time and stops you from wasting time and resources on something that might get cut. Also, I suppose it's fine for web and mobile game developers since they tend to be small in scope and aim for much the same thing, so it's ok to simplify, but; "Remove frustration, add fun" doesn't always apply. The first bossfight in megaman x you can't win, which is frustrating, but is the point. You're supposed to be frustrated with your current strength, so you'll seek to grow. It's also a part of being disempowered which is important for horror.

Anonymous

Not sure that is still relevant, but one most important thing I have learned about game design is: prototype, prototype, prototype, prototype, prototype! Helmuth von Moltke said "No plan survives contact with the enemy." Mike Tyson said "Everyone has a plan 'till they get punched in the mouth". It is very much the same for games. Games are dynamic systems and we humans are very bad at predicting how such systems will behave without seeing them in action. Simple pen and paper prototype can teach you more about your design in an evening than thinking about it can in a week. In fact paper prototypes are the best, even if you are a programmer, because they allow you tu cut straight to working on the gameplay, without having to code any rendering, user interface, controls, AI etc. first. AND they are way easier to modify. AND processing the mechanics of your game in your head makes you understand them better. AND it makes you focus on simple, easy to understand mechanics (or you won't be able to process them in your head).