next »

[Arne]

Yeah, I had trouble with this in my art tutorial. Some people went like, "stfu there are no rules in art bla bla bla." I think it's the word 'rules' as some sort of boolean absolute which irritates. To me rules are more like fuzzy logic, lots of interaction creating a very complex system.

In figurative art it really shows who knows the rules and 'breaks' (passing an intersection of curves in fuzzy logic?) them intentially, and who just doesn't know the rules ("wut? anatemoy? Uh, this is my style!"). This does not mean that amateurs can't get lucky sometimes!

[Al King]

(Brave Dwarves is an abominable example of a game that ignores this).

That makes it an excellent example of a game that recognises that. Right? 

[deadeye]

Yeah, I had trouble with this in my art tutorial. Some people went like, "stfu there are no rules in art bla bla bla." I think it's the word 'rules' as some sort of boolean absolute which irritates. To me rules are more like fuzzy logic, lots of interaction creating a very complex system.

In figurative art it really shows who knows the rules and 'breaks' (passing an intersection of curves in fuzzy logic?) them intentially, and who just doesn't know the rules ("wut? anatemoy? Uh, this is my style!"). This does not mean that amateurs can't get lucky sometimes!

Exactly.  It's that whole "you can't box me in I'M AN INDIVIDUAL" point of view that keeps people from recognizing what works and what doesn't.  If you don't want to be boxed in, that's like totally cool bro, but you should realize that the box is there to help.  Regardless of where you end up, the box should always be your starting point.  In other words, you should keep the rules in mind even if you choose not to follow them.

And yeah, amateurs can get lucky.  But if you don't know the rules then any success you might have is incidental.  You can't "break the rules" if you don't know what they are.  You've just happened to hit upon something that works, whereas if you know what to aim for you're more likely to make your target.  If breaking a rule gets you closer to your target, then by all means do it.  "Know when to break the rules" is the last and probably most important rule.

[Al King]

See, that would stand true if all of these were of the 'good idea most of the time' type of rules, rather than things which sound like good ideas to those who put them forward. Perhaps listing them at least brings them to your attention so you might consider aspects of your game more closely whether you follow them or not, but I'd definitely take them with large spoonfuls of salt. Also, I think starting out by overanalysing your methods is one fine way to kill creativity and motivation. Keep in mind I haven't made a game, so this fits into the 'large spoonfuls of salt' category 

[deadeye]

See, that would stand true if all of these were of the 'good idea most of the time' type of rules, rather than things which sound like good ideas to those who put them forward.

You do have a good point.  This thread kind of devolved into people just stating their personal tastes on what bugs them about games, which isn't really all that useful.  But I think the first two posts have a lot of good general advice, even if they don't really qualify as full-blown list of "rules."

[Alec]

If this was a thread about design principles that a large number of talented/successful designers agreed were good, then yeah, maybe it wouldn't make sense to break them. But I don't know how you could arrive at such a list without careful and deep discussion.

If its people saying "make a black game!" and other people saying "make a white game!" so then you're like, okay, I'll make it a "gray game", so then everyone is happy!

It doesn't necessarily make your game better to just try to get it to some kind of average of what everyone wants.

I just played through Half Life 2 eps 1 and 2 with commentary, and there were lots of moments where they were like "Yeah, we had this cool idea.. but then play testers had trouble with it, so we took it out" or "we made it as simple as possible".

Or like Halo 3, where the game is balanced in a lab so that there is health exactly were everyone needs it.

Those things certainly make the games easier to get through. Which definitely means less support calls, more sales, larger market etc.

I think its debatable whether they actually make the games better though.


So yeah, if people actually wanted to discuss what are important design principles to have when making a game, that'd be cool. It'd be quite a debate though, I think. I think a lot of people put the emphasis on different areas.

Right now its kind of a potshot, and some people are like "how Dare you question my wisdom!". Its just like, what works for you, might not be considered a "law" by other people. So what?

[Alec]

When you "break the rules" intentionally there should be a good reason that serves the overall design.

Or not.

Heh, yeah so true.  "Make your game crappy and piss people off on purpose."  I forgot about that rule.

I don't think too many folks make crappy games to piss people off on purpose, but some do. (or at least, hard games to piss people off on purpose)

I was no means intending that to be a rule, but it is certainly a design option, which can be quite hilarious. (I found the B-Game entry Rover Race to be really funny to try to play, Sexy Hiking was also pretty hilarious)

I think most people trying to make a game for a wide audience are trying to make their game fun, and not anymore frustrating than it has to be, within the boundaries of the experience that they're trying to create.

[Alec]

Er, but that said (sorry for triple post) I wasn't trying to bash anyone or say that discussing small things that can improve your games was a bad thing.

I just think it gets weird when it gets into subjective stuff like design.

[Guert]

Somehow, I knew a thread like that would degenerate... I know I'm partly responsible since I added 20 rules and I discussed the doc (hey what do you expect from a game designer who works with them all day? )...

But in general, whenever there's a game design discussion, it always degenerate. The problem is, game design is like politics. Each individual has its view and believes that it's the best. Even tho I try to look at many other ways to study game design, I end up with my own views and sometimes forget that I don't know everything. At this point in the development of the game world, it's somewhat natural. We don't have a long list of masterpieces (we have some but it's not that long either) to look up to, we don't have anything like an academy that sets the standards of artistic quality of our work, we don't have alot of schools that focus on the teaching of game design and we're still struggling with the acceptance of the public (but it's getting better ). So, everyone is pretty out for themselves, picking design theories here and there, deciding by themselves what makes a good game (indie or commercial).

Ah anyway, maybe I'm simply off topic... If so, I'm sorry...

[Alex May]

It's not about game design man, that's the problem we've been having since post #2. It's not about design. It's about production. Adding an option to turn off the music isn't game design. It's a little thing you can do to make your game seem more professional. Want to go one better? Make it a slider. Unfortunately people decided to use the thread to list pet peeves about games in general and talk about development.

[Alec]

Well, maybe creating a new thread that makes it clear what the subject is would make it go easier. I think currently the title leaves a lot of room for interpretation, so its quite easy for people to assume that design is on the table. Even with a distinction, it would probably still bleed into design.

[skaldicpoet9]

Well, I actually did find quite a few of these points helpful but by no means did I consider any of these points mandatory for game design. Obviously each point should be taken with a grain of salt, I don't think anyone took this as some sort of "gaming commandments" in the vein of "thou shalt not make your in this way", I think that the intention of this thread was to expose people to some suggestions that they may find helpful when making a game. Personally, nothing is going to stop me if I wanted to do or not do any of the suggestions on this list. However, the title of the post is somewhat misleading "....can do to improve your work" makes it sounds that if you followed all of these "Little things" that they would dramatically increase the quality of your work somehow. I guess in retrospect I didn't analyze that title very thoroughly, I just assumed that these were more suggestion then rule. Maybe the title should be: "Little Suggestions that May Improve your Work" thread?

[Guert]

It's not about game design man, that's the problem we've been having since post #2. It's not about design. It's about production. Adding an option to turn off the music isn't game design. It's a little thing you can do to make your game seem more professional. Want to go one better? Make it a slider. Unfortunately people decided to use the thread to list pet peeves about games in general and talk about development.

Hmmm I see... I missed the goal of the thread then. My fault.
Cool beans?

[Alec]

It just seems a bit odd to me to have a list that everyone can add things too. Like ultimately its not going to make sense and it might even contradict itself. So unless the purpose is to see what everyone thinks and whether or not it all lines up (which would be pretty interesting), why not have it as a discussion thread with the final list on the first post. Then everyone can suggest things and maybe even rank them in terms of importance somehow.

Maybe even break it up into categories if its going to get really long. Like UI, Game Testing, Release... that sort of thing.

I just feel that without some kind of more specific guidelines and an editorial process, its not going to be of much use to developers who could use such a list. (everyone?)

[skaldicpoet9]

It just seems a bit odd to me to have a list that everyone can add things too. Like ultimately its not going to make sense and it might even contradict itself. So unless the purpose is to see what everyone thinks and whether or not it all lines up (which would be pretty interesting), why not have it as a discussion thread with the final list on the first post. Then everyone can suggest things and maybe even rank them in terms of importance somehow.

Maybe even break it up into categories if its going to get really long. Like UI, Game Testing, Release... that sort of thing.

I just feel that without some kind of more specific guidelines and an editorial process, its not going to be of much use to developers who could use such a list. (everyone?)

I agree with that. I think that is the main problem with this list. It seeks to be a helpful resource for developers but ultimately someone looking at this would find a overwhelming stack of numbered, random points that he/she would have to glean for something that may or may not be helpful for their own work. As you mentioned we need some sort of distinction between topics and a clear outline of the topics covered listed in the first post of this new topic. Maybe something like this:


I. Pre-Development.
II. Development.
III. Testing.
IV. Tweaks.


and then whenever a new post is made pertaining to a particular post the format could be:

II. Development.
(Information pertaining to the topic)

and then the subsequent discussion on the previous post.

[Shoot-em-upper]

(Brave Dwarves is an abominable example of a game that ignores this).

That makes it an excellent example of a game that recognises that. Right? 

Wrong.  It's an example of a game that ignores it, and it's abominable.

[Corpus]

In that case, it's an example of an abominable games that ignores this.

Haowan, adding an option to turn off the music IS game design. In some games, the music is an integral part of the experience, so providing such an option would horribly maim the design.

Anyway, as someone (probably Alec, statistically speaking) said, game design is subjective. To be honest, I think that having a list of design rules on an indie games forum is pretty pointless. Isn't the fact that you can go against the grain and do whatever the hell you like one of the greatest advantages of indie development?

[Al King]

(Brave Dwarves is an abominable example of a game that ignores this).

That makes it an excellent example of a game that recognises that. Right? 

Wrong.  It's an example of a game that ignores it, and it's abominable.

Haha, yes, I realise that's what you meant - just playing semantics
Corpus, haowan's point was that rinkuhero's original list wasn't really focused on design, but on polish. Some are more closely linked to the design than others - particularly point 8, which led into Guert's more specific design-related advice - but they're generally 'superficial' alterations to make it more immersive and smooth. Naturally, if someone feels one of the suggestions significantly damages a player's experience - e.g. the music is particularly integral - then you might reconsider following the advice. Hell, you can ignore anything that you don't agree with.
I don't like the idea of starting designing a game using the 'rules' as a reference, but I think a list of things that can add professional polish which you can consider later on is no bad thing.

[Derek]

I think this should be in the developer's part of the forum, too (moved).

This is a good exercise, though, for a lot of reasons.  If you think about it, it's a good lesson in game design, also.

Like, as imperfect as this thread is, it came from a good place and ultimately there's a lot that can be gleaned from it.  Not all the component parts are perfect, or can be applied to everyone's situation, but it's a good discussion to be had.

[jeb]

I'm gonna take a bold move and start a new list here. The criteria for the list is "simple things that would have made this freeware game feel a lot more polished", or "the STTWHMTFGFALMP list" for short.

1. If you exit the game with the ESC key, make sure there's information on screen either before the player press ESC ("Press ESC to exit"), or with a confirmation message ("Are you sure you wish to exit? Y/N") when the key is pressed.