next »

[mjau]

"Cheating" AI really depends on the kind of game you make.

Well, obviously.  I thought that went without saying.

47. Avoid Being Boxed in by Long Lists of Arbitrary Rules

It'll only hamper your creativity.

What works for other people may be completely un-applicable to your situation. Make sure you think carefully about other people's suggestions before you apply them.

This is probably the best advice in this thread

[jeb]

... the suggestion to write a design document is not, for instance.

And why don't you feel like creating a document that allows you to plan ahead (like knowing how many screens you need to make the game, what functionality you'll need to put in, what kind of art style you're going to use and etc...)  and work on your core design before you start coding, as well as allowing other members to join your team (play test, testers, arists, coders, etc...)and easily tell them what the game is about as a whole before working on it will not improve your work?

I didn't mean it wouldn't improve your work, but I don't think it's a "little thing". If you don't know what art style you want in your game, for example, you probably need a list of "sledge-hammer things that will improve your work" instead, or a general guide to how to plan your development cycle.

I'm struggling with words here, but I think I'm trynig to say that if this list is going to be any useful, it needs to be more focused.

[Alec]

I find that its much easier to do a voice chat or in-person meeting to describe the game to someone than a doc. Just cause unless the doc is really well written, people will get an inaccurate perspective from it, or they'll fail to read the whole thing.

Also, it can be very dangerous thing to lay out what you think the game is going to be in the doc, because you can accidentally portray the completely wrong idea. Then later, you get into situations where people are like "but in the doc you said!" and you're like.... "oh man, no... I didn't mean it like that!"

Ultimately docs are great for keeping track of stuff, but its super helpful to have design meetings where people can talk in person and make sure everyone's on the same page. (and address concerns etc)

[Alex May]

Make your UI respond instantly to the user's action. if you must have transitions in your UI, make them catch up with the user's choice instead of happening while locking out control. If your UI doesn't adhere to this rule, change it now.

[Guert]

About the doc...

Jeb, Alec, I understand where you guys stand.

To me, the design doc must be absolutly precise and there shouldn't be any room for interpretation. A design doc doc doesn't eliminate the need to talk to others. In fact, before building a design doc, you need to brainstorm and talk it over alot. The design doc will help to keep track of the points you or your team thought of. When you get a new member it is primordial that you talk it over with him, but the design doc will be a tool for further consultation for your new member. Design docs are to me as important as design meeting and prototypes.

In all cases, I understand what you guys mean. I somewhat missed the point of the thread  and I also agree that a doc doesn't replace everything. It's a tool, not a miracle.

Later!

[ravuya]

Does a game really need a forum? I've had a forum for a few months for my games, and nobody really goes there (except spambots).

I probably need to do a better job of advertising it.

[Shoot-em-upper]

48.  Always make it possible for the player to win the first time that they play the game.  I'm not saying that it should be really easy, but games that require memorization to complete can be really annoying(case in point: Delta on the C64).

49.  Make the game's controls responsive and intuitive.  It's OK to make them difficult on purpose(as in Punishment), but it's usually best to make them easy to use.  Remember, the player character should be an extension of the player.

50.  If you're making an adventure game, do not allow the player to make choices that would make winning the game impossible, especially if they occur early on(a prime example would be not taking the junk mail in The Hitchhiker's Guide to the Galaxy).  The player doesn't know what they're doing, so why make it unfair to them?

51.  If you're making a shoot-em-up, add autofire in some form.  Players don't want to mash their fire buttons through the entire game.

52.  If your game is open-source, comment on the code whenever possible.  I guess that should be a given, but it's the best thing that you can do for anyone involved in the project.

53.  Keep a unified art and sound style.  It's hard for the player to get into a game that has style clash throughout(Brave Dwarves is an abominable example of a game that ignores this).

54.  If you have a backstory to the game or a story within it, make it well-written and interesting(Cave Story excels in this regard).  If it's generic, don't bother - nobody cares any more that the aliens are invading and that you are the only one who can stop them.  If it's an artsy-fartsy game, don't bother with one - it detracts from the expression of the subtexts.

55.  If you're developing it and hate the process, give up or start over.  It's fine to push yourself, but don't make yourself do something that you hate.  It detracts from the finished game and makes you like your completed work less.

56.  Give a decent description on your site(or forum post, if you don't have one).  Downloading a game shouldn't be like opening a birthday present - people want to know what they're getting.  Screenshots should at least be included.

[Arne]

57. Make sure there are armour-clad girls in the game.

58. When doing armour designs for female characters, remember that the shoulders and lower legs needs the most protection. A pair of tight superlow cotton panties are sufficient for mid-body coverage.

59. When using a third person camera, make it hover at about crotch level and also support different levels of zoom. Also make sure that the player avatar is easy to pose and set up for cool screenshots, it's what sells the game!

60. There are slimy tentacle beasts in your game, right? Right???

(Disclaimer: I'm actually rather faithful to these rules even if they feel like a joke to some of you *'_'*)

[Alec]

61. Grow the biggest fuckin' beard possible.

[Gazillion]

(not sure if these were mentioned)

- Don't punish the player for exploring.

- Spread out your game's features.

(I'd recommend reading "A Theory of Fun for Game Design" it's full of tips taken from a higher level perspective that help in making a game better/fun)

[Ivan]

62. DO NOT under ANY circumstances make mistakes. People really hate it when you do.

[Alec]

63. Make your game perfect. Also, its impossible for everyone to think your game is perfect.

Quit now.

[Guert]

G'ah Alec, you beat me to it 

Ok, ok... Then

64. Uses bouncing boob technology as much as possible.

[jeb]

65. Take five people, work three years, make an ambitious game. Sell 100 copies.

[Alec]

66. Four people is the exact number, thou shalt have four and no more.



(hey, why's Ebert hiding in there!)

[Ivan]

http://menwholooklikeoldlesbians.blogspot.com/

[Arne]

Actually, I think this thread has some valuable points, like, the the part where I talk about panties. Please consider the importance of panties.

...actually I think there are other points which are valuable to people. Kind of reminds me of how SMB relates to Giana... Giana had the basics down, but, imo, it was very negligent when it came to polish those little things which could really have made the game feel a lot better. I think Xexyz might be guilty of that too.

I think, maybe a more apt thread title can be:

Proposals (this word acts as a disclaimer: it's just ideas) of game design things you can do which are relatively easy to do and can really pay off.

or as a negative

Stuff which can (disclaimer word) make your game feel unpolished but you could fix rather easily

[deadeye]

47. Avoid Being Boxed in by Long Lists of Arbitrary Rules

It'll only hamper your creativity.

What works for other people may be completely un-applicable to your situation. Make sure you think carefully about other people's suggestions before you apply them.

True, but it's always helpful to be aware of the general rules.

As an allegory, when I was in design school one of the first things we learned were the Principles and Elements of design.  Things like balance, harmony, weight, use of line, etc.  Then halfway through the first semester our instructor said "now that you know these rules, you can break them as you see fit." 

It's ultimately just about good judgment, but it does help to know what bothers people about games.  When you "break the rules" intentionally there should be a good reason that serves the overall design.  It's the difference between making a mistake and making an informed decision.

[Alec]

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

Or not.

[deadeye]

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.