I have noticed I forget my own advices and make the same mistakes I already know I should not be doing So, I decided to write it all down This way I won't forget. Also, once I'm at it, it would be great to check what others find important. So, add your own things (anything related to *your* game design process which you find important - please no theories, only stuff from your personal experience & struggles). I also suggest to order these by importance.

My personal list:

- first make the basic functionality, then the extras & polish & optimization

- implement the victory condition as quickly as you can

- is the game fun? If not, redesign. Assure it at the early stage of the prototype.

- deadlines, they always pay off, yet you so frequently forget to make these... BAKA!

- make one game at a time (throw away all other games in progress)

- do not add new features to fix things, it almost never works!

- removing things can do miracles

- KISS! Do you remember one game you made that was not too complex? Just one? No! In the end you always end up throwing away the code and finished features anyway because these didn't fit or were not fun, give yourself a break and don't implement these in the first place.

- if something is not working try to remove some originality/uniqueness (especially for non primary features) and try to clone it (yes, it sounds bad, but it WORKS!), your game does not need to be 100% original (actually, it shouldn't, it will be unfun, overly complex and confusing)

When possible, get others to test your game and give feedback. Do it in the alpha stages.

- implement the victory condition as quickly as you can

this assumes a victory condition. not valid in all cases.

- is the game fun? If not, redesign. Assure it at the early stage of the prototype.

if the core aesthetic is not fun, messing with the "mechanics" seems to me to be a somewhat haphazard way of trying to stumble on something that's fun.

if it were me, i would not redesign. i'd move on to the next game concept to see if it holds more promise. only if i were out of ideas and were desperate to release something for cashflow would i return to a less than promising project to see what i could do with it.

- make one game at a time (throw away all other games in progress)

working on one project day in and day out for long periods of time can lead to burnout. having a second project (IE the next title) to work on gives you a break, yet keeps you productive.

- do not add new features to fix things, it almost never works!

new features by definition can't fix broken existing features - IE it NEVER works. they are a workaround at best.

- removing things can do miracles

don't experience that one myself much at all. i might counter with "don't add things until obviously necessary", then you never need to remove things, unless design changes make them obsolete. i'm lazy, so even the thought of having to type even one keystroke of code i don't know i need is very against my religion.

- KISS! Do you remember one game you made that was not too complex? Just one? No! In the end you always end up throwing away the code and finished features anyway because these didn't fit or were not fun, give yourself a break and don't implement these in the first place.

never happened to me. and i'm on my 35th game or so (that's all of Rockland's titles, all major versions). like i said, i'm lazy. i don't put stuff in unless i have to. and i always try to do things as simply as possible. but there was this one time in Caveman 1.0 i spent a few days figuring out how to make a top down camera zoom all the way out to space, only to realize that with top down view you couldn't see the sun to tell what time it was. so i shelved the feature and got on with it. some ideas work, some ideas don't. that's what whitepapers and rapid prototyping are for - to figure stuff out before it ever gets on the todo list, much less implemented. but i have shelved an entire project once - armies of steel II. not sure whats wrong. i think its a play balance issue. but i have many other titles on the drawing board or in the pipeline that show more promise, so i'm not desperate enough yet to revisit it.

- if something is not working try to remove some originality/uniqueness (especially for non primary features) and try to clone it (yes, it sounds bad, but it WORKS!), your game does not need to be 100% original (actually, it shouldn't, it will be unfun, overly complex and confusing)

i tend to design games from the top down, starting with a vision of a core aesthetic. this vision then naturally leads to the definition of "mechanics" necessary to implement the vision. since the vision defines the mechanics, all the mechanics, original or tried and true, tend to be necessary and proper. i have never come up with an original mechanic then tried to make a game of it. i suspect one couldn't get much further than some kind of arcade BS that way (no offense to the arcade gamedevs out there). not that such a thing might not sell well. in a universe where things like flappy birds can happen, anything is possible.

here's how i do it:

i start with a vision.

had one just the other day: bulldozers vs dinosaurs. FPS. arena combat, or better yet maybe branching storyline mission based. your crew is dropped on an island to start work on a new beach resort. but there's dino's in the jungle. then its front loaders, back hoes, and bull dozers, vs t-rex etc.

or make it a squad of mechs. dropped in from air transport to secure a supposedly deserted island for a new base. very first night, the raptors or some other critter takes or destroys the long range communications gear. either scenario, its days, or weeks til help arrives. the player must complete the missions, with best success leading to rescue. i'm thinking single player, with a crew of followers, and some character development, to give greater meaning if one of your crew dies in some branch of the story line. i have this vision of this huge dino bursting through the trees and ripping the cockpit of a mech clean off in its jaws. probably a cut scene where you lose your number 2.

so you need an island, and mechs or bulldozers, and dinos, and missions. i have terrain chunk generation and render code i can use. and skinned meshes are now part of rockland's Z game library. turn the crank - out comes another game. stuff like that's easy to do. its not historical simulation, so no in-depth research required, no stringent realism requirements. indoor outdoor shooter levels, branching storyline mission based, nothing new there. if one had assets ready to go, one could probably rough out something like that in a week in unity i would imagine - assuming one was familiar with unity of course. i could definitely do it in a week with rockland's Z game library if i already had assets.

you see how designing a game this way pretty much precludes the inclusion of contrived mechanics in the design. its not about mechanics. odds are no game more sophisticated than breakout is about the mechanics. in this case its all about the coolness factor of dinos vs mechs in realtime 3d combat. mechanics is just a means to an end. odds are mechanics should not BE the end, and odds are they should not be what a game is about / built around. once you get past stuff like tetris, mechanics are not what the game is about. they are just how it works.

i can't even think of a game built around a mechanic with no aesthetic. wolf3d: shooting nazis, pacman: eating fruit and chasing ghosts.

tetris - that's a pretty "purely game mechanics" game. but that kind of stuff (design around a mechanic) only gets you as far as arcade type stuff it seems - and no farther along the evolutionary scale of game types.

unless you use the "mixing bowl" approach to game design: throw in every cool mechanic you can think of, stir (perhaps vigorously) , and surely it'll be fun. reminds me of grabbing random ingredients from the kitchen, mixing them up, and thinking it'll automatically taste good. when we all know from real life that a random sample of ingredients in the average kitchen seldom go together - such as dry breakfast cereal and tomato ketchup, for example.

[edit] FYI two random foods that DO go together although you might not think so: of all things - believe it or not - Budweiser and cheesecake - no lie! <g>.

here's some i would put on the list:

* begin with the end in mind.

* don't dilute the vision / remain true to the vision. if you have no "vision" or don't know what the "vision" is, then just what the heck are you building? a bunch of mechanics is no more a game than a pile of bricks is a house. ref: "a pile of bricks is not a house".

* don't make arbitrary design choices. be adaptable. goes for both design and implementation.

* don't be afraid to stop work on a concept that's not working out - whether its a design or an implementation.

* when all else fails, go back to the drawing board.

Document every issue, as minor as it may seem. Lots of bugs can be forgotten because "I don't have time for that now, will look at it later"

Use programmer art for as long as possible so you can concentrate on the gameplay design and core mechanics without getting bogged down in appearance.

Document every issue, as minor as it may seem. Lots of bugs can be forgotten because "I don't have time for that now, will look at it later"

ABSOLUTELY!

can i +2 that? <g>

Use programmer art for as long as possible so you can concentrate on the gameplay design and core mechanics without getting bogged down in appearance.

i might even go farther and say use placeholder art until all gameplay code is done, and all that's left is graphics and audio. i personally try to do final graphics last.

So, I decided to write it all down

I did too, a few years back.

* worry about the stuff you DON"T know how to do, not the stuff you know how to do.

* figure out how to do everything you don't know how to do BEFORE committing to the project. if there's not a clear path from point A (original game idea) to point B (gone gold!), find a clear path before you begin your journey, or you may find yourself going down the garden path.

* always try to think through and think ahead, and extrapolate the ramifications of all design choices, including how they will interact with each other. i find that good modeling of small systems often leads to realistic dynamics between systems, without intentional design or code to do so.

an example from caveman 3.0:

1. you can butcher a kill, which requires time.

2. wilderness encounters are random.

3. predators will go for a carcass before live game.

combine 1,2 and 3 and you get predator encounters that steal your kills! just like in real life. totally unplanned. never occurred to me that "hey, predators ought to steal kills". some might consider this emergent gameplay. i just consider it good simulation modeling - as this sort of thing happens quite often when developing hard core simulations.

* only clone a game if you can do it better than the original. never make a game that's already been made, unless you can do it better.

* i find there are two good tests for whether to make a given game:

1. "wouldn't it be cool if there was a game where you could <do whatever>...." if such a game hasn't been done yet, it may be a good candidate.

2. "i could write something better than that!" if a game has been done, but you know you could do it better, it may be a good candidate (1)

* pay more attention to UI design. many games suffer from "less than best possible" UIs. understandable, easier to use is typically more work to implement, and it gets you no additional gameplay value, its just reduces player frustration when dealing with game UIs that are not "frictionless" (as Johnathan Blow would say).

(1) this is how i became a gamedev. me and my buddy downloaded and checked out all the star trek games available at the time (1989?). after checking them all out, i said "i could write something better than that!". in six weeks i had. the game was a top 10 download on AOL, and checks started rolling in.

* only clone a game if you can do it better than the original. never make a game that's already been made, unless you can do it better.

Not sure on this point. A lot of the popular app store games available right now arent technically better than what they are cloned form and just have better success due to bigger marketing budgets. Perhaps the correct statement is "don't clone unless it's going to make you money" :P