next »

[Nandrew]

Hi all!

I'm currently writing an article on game design, focusing primarily around the old adage:

"Good game design doesn't rely on how much you can add, but rather how much you can take away."

(EDIT)Or rather, to quote Antoine de Saint-Exupery: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

If possible, I'd love to see some devs submit their responses to this statement. Opinions, anecdotes, whatever: I feel that any good article is lent credibility by getting a wide range of opinions, and I hold this community in high regard with respect to both design feedback and actual output. So naturally, my piece wouldn't be complete without your opinions.

To elaborate with examples from some of the more regular members: I'm going to hazard a guess that for everything Derek Yu has added to Spelunky, there are loads of ideas that he's discarded because they haven't been sufficiently strong to add something important to the game. Paul Eres, I'll similarly postulate, has worked to make Immortal Defense into a system which utilises only the most important gameplay additions to create a "tighter" project than a dev who just goes "let's put everything in because people will like something." Is this guesswork correct? Have you found a similar paradigm important for your project? Or not?

If possible, I'd like you to add your "real life" name and credentials (just an example of a game that you've made) so that I can quote you in the article properly. This is par for the course, unfortunately: if I source you, I need to be able to point readers to your work so that the reference has integrity.

If you feel that this is an attempt to have you "do my homework", you're not obliged to respond, or even provide the aforementioned details if you do. I stress, however, that I'm approaching a variety of sources for feedback on this question, and I've posed it on these forums because I think that this community's collective opinion would be incredibly valuable. At the very least, I think that a discussion on this matter would provide some education and enlightenment to anybody who reads the thread later. 

I've checked the topics in the two most recent pages of the design section (traced back to about a month or two), and this question doesn't seem to have been specifically addressed. So can we play ball? 

Final publishing destination is Dev.Mag, followed by one or two secondary output streams.

[havchr]

That's a nice article, and certainly you would not be alone in addressing game design from that angle. I think I've read an article about a similar theme in game developer or something. I'll see if I can find that particular issue I'm thinking about.

The thing about game design which I find most challenging, is that it game design is incredibly focused on just that, what things and elements you choose to put on display, and what to cut.

Creating a game consists in making a silly amount of choices on how the game should work, how the world should behave, what actions give what outcome, etc.

I was game designer on our first game, and chose a pretty minimalistic approach, with few power-ups. On our playtesting sessions though, there would always be a group of people that wanted more power-ups, more modes, and others who were fine with a minimalistic game. Based on playtesting, we added two power-ups to the game.

The "paradigm" I use, is that uncertainty in design games and features is so big, that I find it useful to constrict an idea to a small game space, then decide upon basic rules that I will try out in action before writing them off.

That way, I can avoid the " and maybe you'll have lasers, then maybe you would do that, and oh, you should of course be able to fight a boss by jumping around like crazy, maybe?"
Instead, I'd be left with an idea that is, "in this game you control like this, and you do that" , and then I can run through that scenario in my head, then later prototype it and check if it it's cool to play.

Another thing that is important to have in mind, is that every implementation of an idea, is expensive. It will take time, it will need a decent prototype to figure out if it's any good, it will need assets, it might need lots of balancing work, especially if it interferes  heavily with the rest of the game. Too me, a lot of ideas is never put in the game because they would need all that extra work, and then I'd better be a bit in love with the idea to begin with :p

Sorry for all the ramblings.
Real Name: Håvard Christensen
game released: Skybound for iPhone

[poorwill]

First off:  I have never made a game before, so I don't know how useful this is going to be for you.  I'm working on one right now though!  My design is very, very complex on the macro level - in fact, if I have an overall goal in mind I guess it's that I want to make a very complex game that is simple to play, and has as few redundant choices/elements as possible.  So complexity and simplicity aren't necessarily at odds, especially in games.

I think the thesis is fundamentally correct if it's saying a game should never be overcomplex.  I think it's safe to say that nothing should ever be overanything.  But that's not saying anything interesting, and I don't think that's what it's saying - it seems to be arguing for minimalism as an imperitive. 
But things can be oversimplistic just as they can be overcomplex, and the former is arguably worse.  If a game isn't interesting on any level, it is probably because it's so simplistic as to be redundant.

A lot of wonderful games are practically defined by their everything-and-the-kitchen-sink approach and their attention to detail, and part of what makes them work is how the various complexities interact with each other to create new complexities, tasking the player with ways of coping with new outcomes.  (I was just reading in the Spelunky thread - someone suggested that (spoiler) the pirahnas in area two be attracted to caveman corpses.  Derek thought it was a rad idea and is going to implement it.  Is this redundant?  No, it's exactly the sort of thing that makes Spelunky, and roguelikes in general, interesting.  Does it add more complexity?  It's fair to say it does, of a certain kind.  If it had never been suggested would Spelunky still be awesome?  Hells yes). 

On the other hand, because games are algorithmic, great complexities can arise from a few very simple components - and though it's the resultant complexities that make them interesting at all, often just a few simple elements are needed to make a good game (see: Asteroids).  Many great concepts have been ruined by adding redundant junk, and a lot of good games could seriously use some de-crufting or repurposing (recent Zeldas, for instance).

[Alec S.]

I definitely had that experience when working on By the Torch Light.  I started with the basic idea for the aesthetics (minimalistic 3D graphics showing a cave lit by torchlight, with vines growing on the walls).  I then began thinking of what the player would do in the cave.  I came up with quite a few ideas, but in the end, I decided to have the player encounter a large shadow beast.  That along with the twist that would follow it. (Small text to avoid spoilers for those who haven't played) The player lit up the cave and found the shadow beast to actually be a tree, which is then set on fire by the light.  The player must then escape the cave.

I realized that many of the ideas I originally had would not add anything and would generally weaken this core idea.  I still liked the other ideas I had, so I put them aside, and will probably make them into a separate game later on.

Then again, there are some games where more is better.  Although, this is generally in the content rather than in the basic gameplay.  With Dadaists Gone Wild, for example, I put most of the ideas I had into the game.  It wasn't a matter of if they fit, but rather where they fit (Although Dadaists allowed for quite a wide range of possible content).  I'll probably continue with this design philosophy for the next Dadaists Gone Wild game.

I think in longer games, you should define the basic gameplay and then create as many fun situations with which to use that basic gameplay as possible.  Of course, there is a filtering process.  You want all the content to be interesting and fun.  If there is a part of the game that is uninteresting or boring, it should definitely be either removed from the game or changed.  One thing I tried not to do in Dadaists is add areas where the player isn't facing some sort of challenge or being interested by something.

I definitely believe in a tight experience.  Probably the best way to think about it is that you need to create large amounts of content, which is an additive process, and then polish that content, which is generally a reductive process.  One of the most perfect games ever designed is the ancient board game Go, which allowed for so many possibilities and strategies, but had extremely simple rules.

Name:  Alec Stamos
Games:  By the Torch Light, Dadaists Gone Wild (and other games I didn't mention)

[Loren Schmidt]

I have a soft spot for very simple design. I really appreciate polish, and there's something very special that happens when a game has a small handful of beautifully executed elements that work together well. One of the perks of making games with fewer moving parts is that things naturally end up more polished. Simple games often also have the advantage of being more intuitive.

That said, I think it's a very subjective call. Complex games have just as much potential to be good as simple games.

One weird thing I've noticed is that simple games can have heaps of content without feeling overly complex as long as the number of elements in any given area remains low, and new content explores the core rules instead of introducing new rules.

Content without Complexity
The 2d Mario games, for instance, have dozens of types of enemies and obstacles, yet these are all outgrowths of the core rules and so the game does not feel complex or unintuitive.  Each area in the game can contain a small subset of these enemies or obstacles, keeping the total number of elements on the table at a constant low while still keeping gameplay varied.

A counterexample is items in a Castlevania / Zelda / Metroid game. Each new item expands the player's available actions. Instead of a ceiling that we stick to (which would be the Mario solution), we have boots that let us walk on certain ceiling types. Is that bad? That's a subjective call, but certainly it's more complex.

Culling
I believe in removing anything that lowers the average quality of the game. The measure of a game is not how good it is at its peak, but how bad it is at its low points. I think a game with three good vehicles and one bad one is worse than a game with three good vehicles.

I also believe in removing perfectly good content if it doesn't fit the game. For instance when playing around with enemies for my last game, I fell in love with the idea of an enemy with a shield that reflects lasers. So I implemented it, and had fun playing laser jump rope between two of them, and shooting enemies behind me with deflected shots. And then when it became evident that the new enemy didn't fit the streamlined pace of the rest of the game I put it back on the shelf. I still love them, but they don't belong in that game.

Name: Loren Schmidt
Games: Star Guard, a mountain of incomplete projects

[brog]

In Vertex Dispenser (not yet released - maybe in a month or two HAH), there are seven different energy types, used to power different abilities.  Seven's quite a few, so I've tried some things to counteract the complexity:
- Each ability uses up the full bar for its colour.
- There are only two abilities on each colour.
So you can't save powers up, there are only two states: "i can use this now" and "not ready yet", and when something's ready there's a binary choice, A or B (in addition to the question of timing and positioning).

There are actually four different abilities for each colour, but in a given game a player only has access to two (chosen before the game or selected randomly), to reduce complexity of the choices in the actual game.  I'm often tempted to add more abilities as I come up with new ideas, but 4*7=28 is already quite a few, so I only ever add one to replace something else, keeping myself to the rule of "four per colour".

So yeah, it's not a simple game overall, but I've kept some areas simple to counteract the complexity in others, making it (hopefully) manageable.

Name: Michael Brough
Games: Vertex Dispenser (unreleased), some small unimportant games

[Glaiel-Gamer]

I learned this lesson the hard way. Let me share the same example I usually share when talking about how much I learned from any single project.

Blockslide 2:
http://www.newgrounds.com/portal/view/409254

It was a block sliding puzzle game, a sequel to the first game I ever got an award for on newgrounds. I took the problems people had with the first game (too slow) and did my best to improve upon that and realize the game to its full potential. The first game had 25 levels and about 8 different ways to interact with the game, plus a couple obvious variations of those 8.

The sequel had 20-something blocks and objects to deal with, plus variations on those 20 on top of that. I also upped the graphics to isometric with 3D-models and a level editor and a database of user-made levels on my site (taught myself PHP and mySQL in the process). The editor was public for about 1.5 years as sorta of an "open beta". People sent me levels. In addition to the 75 levels I made, plus 25 tutorial levels, I also had 50 fan-made levels in the game (that's 150 levels total, not counting the server with about 800 levels in it at the moment).

Why didn't the game succeed? 2 years of work on it (admittedly a lot of procrastination and side projects in between), for a couple hundred thousand views and a small $2500 sponsorship?

I was in the mindset that "bigger was better" so I invented all sorts of crazy block types to add into the game, with no sort of restraint (hey maybe death blocks that explode when they touch and give you dynamite in return based on this formula: number of blocks in group - 1... wasn't a good idea. Or having ice slide on grass but not ice...) and the tendency for me to take "glitches" and rework that effect into a new mechanic (death blocks formula), and the extremely complicated ways of blocks interacting with each other overwhelmed the player. Most people thought the tutorial was the whole game, considering it very well should have been. Most people didn't finish the long tutorial. Only a small percentage of the ones who did tried the other levels, and an even smaller percentage of those actually cared to beat them or fiddle with the level editor.

People were overwhelmed not necessarily by the amount of stuff, but by the unintuitive ways things interacted.

My next puzzle game after that (Closure) I took a bunch of advice from that and made a small number of objects to interact with, and made their interactions obvious and logical, and built a game with 5 objects that has been my most successful game to date. Its sequel is adding more objects, but again they are remaining obvious and most of the new additions are things that could be found in typical platform games, put to new use in the universe Closure takes in. It's working wonderfully.

[Nandrew]

Wow guys, thanks for such detailed responses! There's already a great deal of interesting stuff here and I hope that the discussion continues for its own sake: I know I'm biased, but I think that it's an important question.

I've read everything here, but I just have one or two specific responses to direct at individuals:

havchr: if you do find the Game Developer article you mentioned, I'd be pleased to see it. I'm sure it has a wealth of information.

Glaiel-Gamer: I'm sorry to hear about the disappointing results on Blockslide 2, though it's a great anecdote to share. I'm also very glad that you've learned and ultimately benefitted from it! This sort of anti-success story is exactly what other devs will find useful. I'll be playing Blockslide myself to see what you meant firsthand.

[Cthulhu32]

When I used to be full time in the industry, I learned a lot about simplistic game designs and a few key points about why games fail and succeed (I mostly learned about the failing part.)

I'll discuss a game I did for this website: Action All Stars titled "Pitching Ace".

It was the first full blown Flash game I've ever written, and to date my last

Prototyping Gameplay

When my company was first contracted to work on Pitching Ace, we were given a lot of creative freedom to come up with the game-play. My boss had already submitted a game design document that outlined the basic pointers of why the game appeals to kids, but we were basically given a blank slate. Our initial thoughts were to make the pitching portion interesting and unique without a lot of fluff.

Right away I started working on a quick control scheme in Python that involved moving your mouse cursor along a ball in a specific path. Your pitch was determined by how well you traced the path. This method was slightly complicated, but I thought it felt pretty good and was simple enough to appeal to young kids. However, after having several casual gamer folk try it, I quickly realized that creating a new control system for something old and well known like baseball can confuse and anger new players.

So back to the drawing board, I started prototyping new ideas. I came up with I believe three different control schemes to challenge the player, and one by one they all were seen as too confusing or too easy to be fun to the average player. So finally, the producer came up with a timing based system. The user was given three different meters, and depending on how well you landed a meter, your pitch would be better/worse.

Too Simplistic

So the new control scheme was in place, Six Degrees were happy clams, but our game was getting bad vibes by the higher ups. Another game was being made at the same time that involved batter pinball like those old machines, and it was actually pretty fun. So why was our game failing and the other contracted game doing so well? The truth is our design was too simple. There was not enough going on to give the player that skill/reward feeling you get. When you play something like Super Mario Brothers, you are required to at least time your jumps accurately to make it past the goombas, and there is some recall factor to know where the mushrooms and stars are. Even in Tetris, the game gradually becomes harder as you stack on bricks, and you learn methods to stack new bricks. But our game was so simplified that there was no memory recall or acquired skill involved to keep the game interesting.

Taking Away Too Much

So after the game was finished and we finished our contract, I did a bit of reflection on what I would have done differently. We started with a pretty elaborate system of picking pitches, getting advice from the catcher, moving the mouse down an intricate path, and influencing the ball during the pitch. But every week a different piece of the game was taken away. It felt like working with a piece of clay, where every week someone would come by and take away a different sized chunk, until all you could make were three small clay balls.

Moral of the Story

Simple is great and you can create wonderful games with two or three rules. But you have to be careful not to get so simple that you've ripped all of the game elements out of your creation.

Oh whoops, credentials,
Name: Luke Arntson
Games: Target: Terror (Wii), Pitching Ace (PC/Flash), Ultraviolent Moon Patrol (unfinished) (PC), tons of other small projects including DS, GBA, and NES homebrew

[Montoli]

Howdy!  Best of luck with your article!


So, thoughts regarding your quote:

"Good game design doesn't rely on how much you can add, but rather how much you can take away."

So while I agree with this sentiment, I feel like it is stated in a somewhat roundabout way.  It brings to mind the image of a game creator starting with a giant game, like a flawless block of marble, and then chiseling away at it until only a pure gameplay experience remains.

This is not, however, the way in which game development is normally handled.  People hate to throw away something that is completed, and that took resources to get.  (Especially in the case of a professional company, where that resource is always, ultimately, money.)  If someone is working on a game and they realize some gameplay element isn't working, the solution is almost never to cut it.  The solution is to figure out why it isn't working, and try to fix it, or move it to someplace where it does work.

Game development is a much more additive medium than, say, sculpture.  Rather than starting with something huge and trimming it down, you frequently start with something small, and add to it as needed.  In all of the games I've worked on that turned out good, they started from a small prototype that was fun, and grew it into a game that was fun.  We added things to that prototype until it felt fleshed out, and built the rest of the game around it.

As it happens, I have some examples!
When I was working at Leapfrog, making games for their Leapster platform, during the development for launch titles, we didn't have programmers until embarrassingly late in the process.  So the first round of titles were largely top-down design.  The producers wrote up very long game design documents based around what they thought the game would look like.  Artists made all the assets.  Several months later, the programmers were given a stack of assets and design documents, and told "here, make this.  By the way, the artists are now all busy on a new project, so no art changes."  In addition, the games were fairly over-spec'd, and so a number of features ended up getting cut due to time or budget constraints, or because playtests suggested that they just weren't helping, and we shouldn't waste further dev time on them.

In contrast!

Second round of titles we did.  The programmers had had some downtime, and had made a lot of gameplay prototypes of things they thought were cool.  (We had the Leapster hardware to play on, which included a touchscreen.  And this was launching within a year of the DS, so touchscreens were relatively unexplored territory at that point.)  Also, the producers, having been stung a little by having to cut back on things that were not technically possible, used the prototypes as a starting point for games.  (Since they were obviously things that were possible - we had a prototype right there!)  Net result:  The second round of titles was a much better round of titles than our launch lineup!  The games were much more fun, and some of our best stuff came out of that time.

Of course, one could always argue "well, of course it was better, you knew the system better by then and had less kinks in the process.  Launch titles are always rough.  That doesn't prove anything!"  And that's true!  So consider..

Third round titles!

By the third round of titles, we were feeling a bit more confident all around, and producers felt like they could go back to their preferred way of designing, which was "write a giant document, and then give it to programmers, and then playtest to figure out which parts don't work or need improvement."  Long story short:  Third round was not as good as the second round!  The games were just not as good!

Over 5 years of working there, the round I still believe we produced the best games was during the 2nd year, where by a quirk of planning and schedules, we had a solid base of prototypes to start from and grow, rather than a large document full of ideas that we trimmed down.



So.  Back on the specific topic at hand.  I feel like the quote you gave is technically true, but gives the wrong impression.  Really the point that it seems to be trying to make is that "a game's quality is not directly related to how much stuff you can cram into it".  Or, another way I guess, "There is a ceiling, a point at which adding more stuff to the game makes it worse, not better."

So I'd like to propose a slightly different quote that I think sums up my personal philosophy, at least:

"Good game design doesn't rely on how much you can add, but rather knowing what to add, and equally important, when to stop adding."


That's my take on it, anyway.


Oh yeah, and you wanted credentials:
Name:  Chris Cornell  (No, not the one from sound garden)
Independant Games I done made:

• Post Apocalyptic Unicorn Uprising (Flash)
• Boss Rush (in development)

Professional Games I've worked on:

• Drawn to Life (wii)
• Booty Blocks (iPhone)
• BrainQuest (DS)
• SpongeBob SquarePants saves the day (Leapster)
• Dora the Explorer: Friends! Amigos! (ClickStart)
• Dora the Explorer: Piñata Party (L-Max)
• Letters on the Loose (Leapster)
• Disney Princesses: Enchanted Learning (Leapster)
• A day at the farm (Leapster)
• Kindergarten! (Leapster)
• First Grade! (Leapster)
• Dora the Explorer: Animal Rescue (Leapster)

[PureQuestion]

The idea here is good, but extreme-ish. While it is very important to not over do it, and having a ton of half baked ideas isn't as good as a few well done ones, A lack of content leads to eventual lack of interest from the viewer, and makes new level design more difficult.

I can say that the ultimate downfall of my metroidvania game was feature creep. I over did it. I added way to many objects without taking time to perfect them, with a few exceptions. Additionally, while a lot of the features worked well, they didn't mesh properly.

However, looking at my following and currently in development game, Mind Over Matter, I have to say that both avoiding over experimentation and taking time to make things work well has lead to a much better experience. However, I find time and again, that apart from a few staple objects, creating new ones is a constant occurrence, as I always have to keep things fresh.

While typing this, however, something came to mind: Nethack. Ah, what a ridiculous game, Nethack. The sheer depth and complexity is the main appeal, figuring out and abusing the very overdone programming and interactions. Nethack is a great example of how ridiculous amounts of content isn't bad if handled well. But unfortunately, such handling is a rare occurrence. Also of note is that the game has had a ton of work put into it. The oldest version was released in 1987, the newest in 2003. So this game has over 16 years of work in it, from a wide group of sources. Not something that comes along very often.

[ஒழுக்கின்மை (Paul Eres)]

To elaborate with examples from some of the more regular members: I'm going to hazard a guess that for everything Derek Yu has added to Spelunky, there are loads of ideas that he's discarded because they haven't been sufficiently strong to add something important to the game. Paul Eres, I'll similarly postulate, has worked to make Immortal Defense into a system which utilises only the most important gameplay additions to create a "tighter" project than a dev who just goes "let's put everything in because people will like something." Is this guesswork correct? Have you found a similar paradigm important for your project? Or not?

i think this is one among many ways to conceptualize game design, but i don't feel as if such conceptualizations have much to do with the actual process, which is largely unconscious and unfathomable. i also don't think game development is primarily about removing things, it's more about adding things. sometimes you remove something, or make it optional or hidden, but most of the time when you're developing a game you're adding something to it, not taking something away.

in general i distrust the idea of 'paradigms' -- i think they're necessarily gross simplifications of what's really going on. like simple rules for people to use to believe they think they know how something (in this case game design) works, when all they know is some simplification.

i never outright removed an enemy type or a tower type or a piece of music (etc.) from immortal defense, for example. i adjusted them, but didn't delete them. but i did plan on features which i later removed from the wishlist, certainly.

forgive the lack of caps, feel free to edit it to add them if you will use any of this.

name: paul eres
games: shareware: saturated dreamers, immortal defense; freeware: fedora spade, alphasix, missing, wingedmene, knight of the ages, rulers of the seven wonders, harlock and rinku's game which includes the game bill's 'never go west', tilde and the mask of :p, and&

[Cthulhu32]

Also quick side note since this is about your website's articles, make sure to give PyMike credit on your Python programming language article. You featured his game Bubbman 2 as an example of Pygame running, and he was really excited to see his game on the article. I think it'd be really cool if you linked to his site, http://pymike.pynguins.com/ and get him some hits.

[Nandrew]

Also quick side note since this is about your website's articles, make sure to give PyMike credit on your Python programming language article. You featured his game Bubbman 2 as an example of Pygame running, and he was really excited to see his game on the article. I think it'd be really cool if you linked to his site, http://pymike.pynguins.com/ and get him some hits.

Thanks, that was actually negligence on my part. I'll give him some link love.

[Super-Dot]

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

This is a useful adage in visual design, where the idea is to convey a concept or several. It's also useful in interface design, where you don't want to overwhelm the user. But a priority of these other types of designs is to get out of the way; you want the viewer to read or the user to interact with the content, without having to interpret a complex design or figure out an unintuitive interface. In game design, though, you're actively manipulating the content. You're also manipulating its presentation to the player. You'll want to take away when you're presenting content, maybe by practicing good interface design and visual design, but it's fine to make lots of content to begin with.

That said, ideas are a dime a dozen, and games can often become bad from having too many of them. Removing bad ideas and game mechanics can be great if there are good ideas and game mechanics that are already there. But a key part of game design is putting the good ideas and game mechanics there to begin with, and I don't think the adage helps much with that.

Name: Kelsey Higham
I'm a hobbyist/student game designer, and I've made a lot of small Game Maker games, but none of them are fit for publication.

[Derek]

I've been meaning to reply to this thread for a while now.

There were some things that I decided I wouldn't add to Spelunky, like food.  I have all the sprites done for various mushrooms that you could pick and eat - they would work like the potions and scrolls in Nethack and other roguelikes.  But every new "system" I add to Spelunky needs to work with all the other systems, so it would have been a time sink to implement it and test it out.  I thought I'd get a marginal return for the work involved.

But I don't think good game design is simple, necessarily - some of the best games are extremely complex.  The important thing is to prioritize each part of your game and make sure everything you add is promoting the best qualities.  If I had more time and resources, I wouldn't mind adding more things to my games and making them more detailed.  I'm excited to release the source for Spelunky because you know, I'd like to see people implement food and whatever else.  I don't think it would necessarily hurt the game if it, you know, made the game more detailed.

In my opinion priority, not complexity, is what most game designers get wrong, and it's usually the reason why games can feel onerous and incoherent... or maybe the game never even gets made.  In the mainstream industry they prioritize presentation so much that more often than not you end up playing very simple and boring games with really complex graphics and audio.  Quicktime events are kind of the culmination of that... I can't believe after the era of FMV that we're going back to these "glorified" movie-games.  In the indie-sphere, maybe there's too much priority put on bringing out an idea without putting enough effort into exploring the idea fully and making it believable.  I'd like to see more indie devs try to create rich and deep experiences regardless of how innovative the basic idea is.

Part of the problem, I think, is the mindset of casual players.  Not people who play Bejeweled, per se, but anyone who just plays a game to distract themselves from something else.  These people frustrate easily because they're not interested in getting good or investing any kind of energy into a game.  But they buy games, and they complain about games, and unfortunately they end up driving the priorities of the game industry all screwy.

I'd really like to avoid casual players in the future.  Not that I want to exclude them, but I want to make sure I don't bring my work down to please them if they're not going to take the time to learn how to play.  What's the point in, for example, getting my mom to play the new Super Mario Bros. if the game just plays itself (see: New Super Mario Bros. Wii "demo mode")?  I don't see the value in that and to be honest, I'd rather have her do something else other than play video games if it's not going to challenge her in some way.

[Luke]

mmm.. a lot of thoughts Derek. Given more time, I'd like to reply more exhaustively.

Focusing on the original debate, you all have well framed how minimising design has almost nothing to do with complexity in games.
Sure, detracting isn't as common as adding in game development, though I'd like to think it's an usuful tool to reveal which the pivots of your game are.
Then you can enrich those cardinal elements.

[Nandrew]

Hi again!

I'd like to thank you all again for the interesting discussion provided in this thread, I've used some of the material in this here Dev.Mag article. I wasn't able to use everything, but I've pointed to this thread as a recommended reading on the subject since there's been a lot of cool stuff said.

People of TIGSource, I salute you.