next »

[mjau]

Don't let this thread detoriate into a list of "my favourite nagbits". Write easily understood, hands-on suggestions which can be done to an already completed game to remove the "freeware feeling". The suggestion to use transitions is great, the suggestion to write a design document is not, for instance. Creating a non-cheating AI is not a "little thing that will improve your work"! Raaargh *opinion overload*

Hm, yeah, perhaps I strayed a bit from the thread's purpose on that one..  However, I didn't say that people should create a non-cheating AI, I said they shouldn't create an AI that cheats.  Meaning, if you're already doing the work to make an AI for your game, go the extra mile and make it play by the rules.

[Guert]

... 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?

[Alec]

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

In some cases, a "cheating" AI is really the only kind of AI that will make the game fun.

In other news, this thread is ultimately pointless.

[TeeGee]

Don't let this thread detoriate into a list of "my favourite nagbits".

Agreed. Try to avoid hints starting with "don't". This thread won't be pointless unles we make it this way. After all we're all somehow experianced in game design - we learned on our own games and some of us work as professional designers. Sharing tips is a nice idea. Knowledge never hurts.

This is fine for a casual game perhaps, but personally I'd be really annoyed at such behaviour, like the game cheated me.  I can win the level myself, thank you!  Just give me a few more tries..

You don't know this as a gamer - you just play further without getting stuck, which is good for almost any game - casual or hardcore. A designer can't take "if I was a gamer and I would knew how this works" aproach towards his features. "What do I have to do to keep the player entertained" should be his/her main concern. Also, I'm posting things based on my experience - they worked either for me or the company I work for. These are hints - you might like them or not, implement them or ditch, they may also completely not fit the game you're making, but I don't see the point of discussing them. It's just good to know that something is done that way and worked for someone. Use at your discretion, your mileage may vary etc. etc.

Now onto more tips:

44 - Windowed Mode:
Just have it. People are often playing at work or just like making other stuff while they play. Give them an option to do so.

45 - Use the collector inside of us
Allow the player to collect and unlock stuff. Trophies, highscores and achievements are obvious solution, but you might go further. Unlocking new gameplays, stages, making you able to review already seen cut-scenes, counting kills for specific monster type, displaying total time spent on the game... you get the idea.

46 - Rewards the player:
Reward the player for doing the right thing - progressing the game, clicking on a unit in RTS, moving a tile in match-3, shooting a guy in a shooter, blocking an attack in beat'em up... everything. Remember rewards are not only points and such stuff - pleasant sound effect, particles, blood splatters, unit speeches in RTS, screen shakes, nice animations... anything nice goes here.
Also allow the player to experiment - don't punish for bad actions unless they are really contradicting the whole gameplay. Hero doesn't fall and die in Shadow of the Colossus unless you sepcifically tell him to jum of the cliff, if you get to close he just makes some animation; clicking randomny in a spotter game doesn't make you lose anything unless you click like mad.

[Alec]

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.

[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)