next »

[Paul Eres]

Here's a quick list I came up with in another thread, intended to be a list of things that a lot of indie developers forget about or neglect, which if done can really improve their game. Though obviously not all of these will fit every single game, and there are exceptions to everything etc. etc.

In part this was inspired by one of my replies thread in the Eo community started by Chronic, where he mentioned how most Game Maker games could really do with an options menu.

Feel free to add more or argue against these or whatever, I'll add more as I think of them too.

*

1 - Use room transitions of some kind, it makes a game look bad to just jump from a screen to another without transition. Even just fading to and from black is better than jumping without transition between areas of the game.

2 - Have an options menu or an options .ini file where the player can turn sound on and off, change the resolution, lower the graphical effects for slow computers, and so on. People have different preferences about that sort of thing.

3 - Use sound effects for feedback, as a rule of thumb, most actions that have some impact on the gameplay should have some type of sound effect. It feels pretty bad when this is lacking.

4 - Learn about color harmonies and try to make the screen visually appealing most of the time (I think this is the biggest mistake of programmer-artists).

5 - If the game is text-heavy, use bitmapped fonts rather than a .TTF, and texture that font somewhat, and outline the font in black, it looks much nicer.

6 - Virtually all computers have stereo speakers, so if a sound happens on the left side of the screen, make it come out of the left speaker a little louder than out of the right speaker. This is a subtle effect that goes a long way.

7 - Give your game a website and a forum or forum section, even if it's freeware. It doesn't have to be a lot, just a page with a link to its reviews, YouTube videos, a few screenshots, and so on. It's pretty helpful to people in deciding whether they want to try out the game, and is better than posting a zip file on a forum somewhere.

8 - Have a lot of playtesters, at least a dozen and preferably about a hundred. And watch them play the game in person, sit behind them and just watch, it helps you see things you'd miss otherwise.

9 - If the game is unique or complex or if there's anything your playtesters were confused about it, give it in-game help about that point. Preferably provide an in-game tutorial explaining things that some people didn't understand.

10 - Unless the game is a fan game (where it's intentional), never use graphics or music or sound effects that you didn't create yourself.

[Guert]

11-Start off by making sure what the game is all about. Make sure you know why you make the game and what kind of experience you wnat the player to have

12-Establish as soon as possible your core mechanics and try to prototype it alot to make sure it's simple, fun and allows depth. Prototyping the core mechanics will usualy make it evolve and at the same time, it will uncover problems you haven't thought of.

13-Make a design doc. It can be very simple, featuring only the rough idea you want the game to be, but having one makes a difference. it allows you to keep focus during the process of creation.

14-Plan before you code. Think about what you're gonna do and why your doing it before you start coding it. You'd be surprised of how many ideas turn out to be bad ideas while still on paper. I'm not saying to write everything down but the core logic should be on paper so you can see the general flow of your game before you start creating it.

15-Once you got your core game mechanic down, find secondary mechanics, such as variations of your main mechanic. Then, make a list of all sorts of challenges that use these mechanics. From jumping on an enemy to using a double jump. Anything you can think of. 

16-Establish an economy: think of everything the player will be able to exchange with the game while playing. Coins, points, stars, whatever... Just list them

17-Give a meaning to wahtever you give to the player to play with. Every weapon, every economical element must have it's sole purpose. If they don't have a good reason to be there then they shouldn't be there at all. Being cool is not a good reason

18-Think about goals and what the player has to do. Make sure your game has plenty of long-term and mid-term goals

19-When building the oustide of the game (menus, title screens, etc...) set a standard that you will use throughout the game. Be consistant! If Enter means yes, it means yes all the time. Follow the standard that the player is usualy used to or establish it with him as soon as possible (ex: ESC means escape or exit not Ok or Accept)

20-Always make sure the player can access the game screen within less than three to five screens.

21-Always tell the player what's going on when he's not playing. if the game is loading, say so. If it's saving, tell him.

22-Whenever you do something that could alter the player's game in a bad way and that is not part of the gameplay, ask a confirmation  (Ex: Leaving the game, overwriting, Deleting, etc...).

23-Whatever you do, make sure you don't remind the player that he's playing a game. Try to make everything part of the game. Try to find a way to make the interface look likes it a natural part of the game, not just tacked on  (this follows the transition point Rinku gave.)

24-Don't use fonts you can find in windows. Find or make a font that fits the game well and try to stick by it as much as possible. You can vary the fonts used in a game but be careful: using too much different fonts won't look good. Try to associate one font to certain events so that the player can associate the font with certan events. (ex: messages from the game always use one font but npc messages always use another)

25-Whatever happens in the game, always make sure there are at least two feedbacks: graphical and sound (like Rinku mentionned) The player has to know, in as many ways as possible, what happenned. In some case, add texts.

26-Establish your game universe before you establish your story. This will help you to come up with better levels, storyline and of course, make the game feel natural. Explain everything about the elements the player will see. Why are there goblins in the wood? Why is there water in that cave? Why would someone live in a place that looks like a maze? The player will think about those, you must provide the answers.

27-If your playtesters are confused about something, try to figure out why. Your goal is to make something that everyone should be able to pick up. You have to adapt yourself, not make the player adapt himself to the game. If your core controls aren't working well, then ask yourself why do the players don't feel like it's natural and make it natural. Find the reason behind their comments and don't follow their comments without asking why first.

28-Games are made for your player's fun, not yours.  If you're the only one understanding it or enjoying it, re-think your game. Too many times I've seen people creating a game for their own pleasure and it usualy ends up being crap. And then they cry wondering why it didn't work out.

29-A cool feature in one game doesn't mean it will be a cool in yours. It's okay to inspire yourself but just taking features from other games because they were cool might simply just spoil yours more than anything else.

30-Music is a powerful tool. Use it wisely and remember that silence can be a powerful melody when used correctly.

That's all I can think of right now... I have more but I gotta go grab a bite.
Later

[Ivan]

Here are my couple of (visual) bits of advice.

First one kind of relates to rinkuhero's point #1, but here it goes:
31. Use easing whenever possible for movement and transitions. Most languages have a library for different interpolation formulas and if not, it's quite easy to write your own. This immediately adds polish and detail to even the simplest things. i.e. bouncing a menu into view, etc.

This one actually disagrees with rinkuhero's point #5.
32. Learn some basic typographical skills and use them procedurally in your game. Most games involve quite a bit of text and unless your game is a lowbit pixel one and uses pixel fonts, using a font rendering engine like FreeType will give you quality type rendering that is impossible with bitmapped fonts. We take it for granted, but most fonts have fairly complex rules about how the type characters interact with each other and rendering them into an image and then stringing them together destroys ALOT of what a specific typeface is desgined for.

[Chris Whitman]

This one actually disagrees with rinkuhero's point #5.
32. Learn some basic typographical skills and use them procedurally in your game. Most games involve quite a bit of text and unless your game is a lowbit pixel one and uses pixel fonts, using a font rendering engine like FreeType will give you quality type rendering that is impossible with bitmapped fonts. We take it for granted, but most fonts have fairly complex rules about how the type characters interact with each other and rendering them into an image and then stringing them together destroys ALOT of what a specific typeface is desgined for.

I like the idea of producing textured fonts, fonts with outlines, etc. Does anyone know of any good APIs for rendering vector-based fonts with more... style?

Edit: I agree with the spacing and typesetting issues, by the way, I just think it'd be nice to have the best of both worlds.

[Ivan]

FreeType is pretty low-level, you could add whatever effects yourself as you render stuff. However, I must say that if there is one thing that alot of games, both indie and commercial, really suffer from it is bad use of typography, and that includes using cheesy effects to quickly make text stand out.

[Melly]

I guess one tip I can give that is related to 19 is:
33 - When designing your game's controls, make sure each button of the controller/keyboard/mouse have very specific functions and that any combination of different buttons should not go against that. One example I can give to better explain is God of War's controls. In it, the Block button (highly used) is also the button that is held when you want to make special attacks, all of which have delays in their animations and actually leave you open for attack. That goes against the block's function, is unnintuitive and a slip-up of the fingers can easily screw the player up.

23-Whatever you do, make sure you don't remind the player that he's playing a game. Try to make everything part of the game. Try to find a way to make the interface look likes it a natural part of the game, not just tacked on  (this follows the transition point Rinku gave.)

This reminds me of games that do the mistake of having the actual in-game characters tell you the controls and how to navigate menus. It's the weirdest thing and really breaks the immersion.

[moi]

34 - If it's a game where the player dies a lot, make sure he can get back to the action in less than 5 seconds if he keeps the action button pressed.

[ChevyRay]

(not sure if these have already been said, i read through them pretty quickly , but a lot of it wasn't news to me... though some of it definitely was )

35 - add gamepad functionality.

36 - record whether a cutscene has already been watched in a separate compartment from the game data, so a player doesn't have to watch a cutscene every single time they die and have to redo an event (CAVE STORY RAARRRRGG!!!)

[Chris Whitman]

FreeType is pretty low-level, you could add whatever effects yourself as you render stuff. However, I must say that if there is one thing that alot of games, both indie and commercial, really suffer from it is bad use of typography, and that includes using cheesy effects to quickly make text stand out.

You do have a point. I guess I was thinking about specific incidents when plain-coloured text can fail to stand out, for example, in a very textured and high-contrast background, but that can be designed around.

[Movius]

A small piece of advice. If after playing your game all my background windows look like this...



then I'm probably not going to want to play it again.

[TeeGee]

Ha ha ha! I actually had the same idea for a thread after reading Rinku's post . Few tricks from me:

37 - Tonal Progression:
If your game features some repetitive event that gets "better" as it goes, make the sound feedback for it increase in pitch for every consecutive processing. Few examples: combos in most casual games, shooting sound in Immortal Defense, sound for hitting a peggle in Peggle. Simple and effective.

38 - Difficulty:
While difficulty curve in most games should look like this...

...it's a good idea to mix things a bit by adding some harder/more relaxing levels/puzzle/enemies/whatever along the way. Just make sure that you don't put too many of these in a row. Other good thing is to give the player some relax after a particulary difficult challenge.

39 - Speaking on Difficulty:
You can use some more tricks here. The difficulty should be high enough for the player to be able to lose, but he/she shouldn't get frustrated by having to replay the same level over and over. People like to win. In a casual game I'm working on at the moment, I use a following trick: there are few levels that have some good chance of making the player lose, but when he/she presses "Replay this level", the stage becomes a bit easier and shorter. This makes sure that the player will have some challenge while beating the game, but shouldn't get stuck anywhere for too long. Getting stuck sucks!

More to come...

[mjau]

3 - Use sound effects for feedback, as a rule of thumb, most actions that have some impact on the gameplay should have some type of sound effect. It feels pretty bad when this is lacking.

This is specially important in action games.  The way the human brain is wired, we can react much quicker to aural feedback than to visual feedback.

22-Whenever you do something that could alter the player's game in a bad way and that is not part of the gameplay, ask a confirmation  (Ex: Leaving the game, overwriting, Deleting, etc...).

Don't overdo this though!  In a certain racing game I have on the PS2, you first have to confirm saving, select your profile (the profile you're already playing under, you can't create new ones when saving anyway), confirm overwriting your save (there is only one save slot per profile), and then confirm saving again.  Then you get a confirmation screen that you have to click through.  This is when autosave is enabled.  Asking once should be enough in any circumstance, and if autosave is enabled you shouldn't have to ask at all!  Autosave should be treated with care though, never save when the player is in a situation where the game can't be won (perhaps unless the game is designed for that, like eg permadeath in a rougelike, and multiple storylines with good/bad ending should be fine too).  If in doubt, allow multiple autosaves to exist.

36 - record whether a cutscene has already been watched in a separate compartment from the game data, so a player doesn't have to watch a cutscene every single time they die and have to redo an event (CAVE STORY RAARRRRGG!!!)

I don't think it's a good idea to actually record this except in RAM, so that it goes away when you quit the game.  What if you stop playing the game for several months for some reason?  When you come back you'd probably like to see the cutscene again, if only just once.  Ditto if you're loading an older save, restart the game, other people playing, etc.  Also, some people might not actually mind (or even enjoy) watching the cutscene multiple times, at least up to a certain point.  This, though:

36a. Make cutscenes skippable
The best of both worlds!   People tired of or not interested in the cutscene can skip it, while people who want to watch it can do that too.  If you think a cutscene is specially important for a game (tells you important passwords or somesuch perhaps), you could make it required to watch once and allow skipping it for subsequent watchings, but if you really have to do this for your game you should think hard if there's not a better way you could do it.  Which brings me to another point..

40. If vital information is only available through a cutscene or similar, make it repeatable!
Anyone here played Dreamfall?  There's this one point in the game where you need to be able to remember something that happens in a cutscene.  However, there's no indication that you actually need to remember this until a little bit later in the game, and there's no way to repeat this cutscene after you've watched it once.  When I played the game, I saved somewhere between watching that cutscene and where I had to use it, and there was a week or so before I loaded the game to continue.  I obviously became hopelessly stuck!  (Thankfully the game had autosaved not long before.)

Also:

41. Don't change input methods!
Examples of this is practically every Flash game ever made (okay, with a few exceptions).  If your game is controlled with a keyboard, make the keyboard work in the menus as well.  If your game is controlled with a mouse, make the mouse work in the menus, if your game is controlled with a joystick/joypad, make that work everywhere.  Don't even think about requiring using the mouse to go to the next level when your game is controlled entirely with a keyboard.  It completely breaks the flow of the game and only annoys the player.

[skaldicpoet9]

9 - If the game is unique or complex or if there's anything your playtesters were confused about it, give it in-game help about that point. Preferably provide an in-game tutorial explaining things that some people didn't understand.

Can I just add:

9a - Make Tutorials Skippable/Optional.
Do not shove your tutorial down the players throat. Many people don't have the patience for a long drawn out tutorial.

Which brings me to this:

42 - Make tutorials as simple and as brief as possible.
There is nothing more deterring to a player's fun then having to read a very lengthy and boring tutorial. And if it is not possible to trim the length of the tutorial at least try to make it fun.

[mjau]

39 - Speaking on Difficulty:
You can use some more tricks here. The difficulty should be high enough for the player to be able to lose, but he/she shouldn't get frustrated by having to replay the same level over and over. People like to win. In a casual game I'm working on at the moment, I use a following trick: there are few levels that have some good chance of making the player lose, but when he/she presses "Replay this level", the stage becomes a bit easier and shorter. This makes sure that the player will have some challenge while beating the game, but shouldn't get stuck anywhere for too long. Getting stuck sucks!

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

Which reminds me:

43. Don't have a cheating AI
This should speak for itself, really.  The player just ends up feeling cheated, which isn't fun.  If the AI can't play by the rules of the game, it probably shouldn't play at all.  An AI that cheats for story purposes could be an exception though..

[jeb]

43. Don't have a cheating AI
This should speak for itself, really.  The player just ends up feeling cheated, which isn't fun.  If the AI can't play by the rules of the game, it probably shouldn't play at all.  An AI that cheats for story purposes could be an exception though..

Aaargh! I had written a long post about the quality of this thread and thought, "nah, nobody wants to hear my opinions anyway" and cancelled it, but this really does it!

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*

There's a long nag-thread over at indiegamer for the interested: http://forums.indiegamer.com/showthread.php?t=10492 (it's a fun read actually, and it will also tickle your opiniosticle)