I define a "design dogma" as a thought or rule concerning a certain aspect of a game. It is more like a decision than an universal truth - though many such dog. The way to use them is to choose a set of them at the start of a project - and then follow your chosen dogmas throughout the project. As a benefit they more clearly define priorities, allowing you to make design decisions based on how they fit the doctrine. The doctrine ensures an unitary style of the project, and a focus in some directions which will become strong points of the project. The questions of this thread: what are the dogmas you prefer, or consider interesting? Those that worked for you or didn't? Do you even use something similar? Here's a list of mine: "Gameplay is king. Eye candy is largely irrelevant unless it benefits gameplay - otherwise, add it if it's not too much trouble. If it distracts from the gameplay, it doesn't belong in the game - cut it out. " "Don't get dragged in technical challenges if it can be helped at all. Always try to use design to go around what you could solve with the shear programming force." "User interface is king, even more so than gameplay." "The demo version limitations are of the utmost importance. The demo must show (not tell!) the player what they can expect in the full game, without actually giving much to them." - this is important for my shareware games which have little marketing exposure except the demo "The demo version must offer a lot of gameplay - as much as a freeware game. The limitations should only affect hardcore players of your game. This way you benefit from word of mouth, but you lose the impulse buyers. Since word of mouth can cause your sales to grow exponentially while losing impulse buyers only loses a (very large) percentage of your sales, this risky strategy can be a great winner. Be prepared to revert to the previous dogma if this doesn't work." "The player must have fun within five minutes. The game must promise to be fun within one minute." - again a shareware dogma "Don't expect the player to read manuals, to go through the tutorial or be responsible in any way. Do the best to make everything obvious by itself." "If it's hard to understand, the game is a failure. "Easy to learn hard to master" is king." "All the game information must be available on a single screen." "Try to remove as much from your game as possible - as long as this doesn't hurt gameplay. This is more important (and more difficult) than adding features to the game. " As I said, I don't consider these universal truths - just choices I am (more or less) likely to make (or at least consider) when making a game. So contradicting my dogmata is a little beside the point of this thread - they're only supposed to work for a very particular situation. Discussion of the merits and downside of each proposed dogma is of course very much on topic. ______________________________________ Pax Solaris [edited by - Diodor on January 8, 2004 7:20:35 AM]

Sounds like a good exercise. The principles used in directing game design depend on the niche being sought. If you try writing for a different niche, you will need to rethink the principles.

Also, I agree that marketting strategies should change depending on the popularity and age of the product.

I have a huge belief in overkill. Metal Gear Solid 2 took me less than fifteen hours to beat my first time around. I can now play and beat MGS2 in under ten. Final Fantasy X was a fifty to sixty hour game. Now, I enjoyed MGS2 a whole lot more than I did FFX. If a game is to be played for fifty to sixty hours, it should be because it''s fun, not because you''re still trying to beat it.

I agree with the points above and would add this. The installation of your game should be as effortless to the user as humanly possible. Just because we may understand the technical junk don''t mean your user base should have to.

"If you are not willing to try, you will never succeed!"

Grellin
GDUnion.com

I''d just like to add "keep your intended audience in mind at all times". Some people like complex games (particularly if they''re some form of simulator).

Oh and try not to have too many kings.

(In other words, decide on a more detailed feature importance hierarchy.)

How about the old K eep I t S imple S tupid?

[edited by - AcRiD_aCiD on January 8, 2004 11:37:53 PM]

quote:

---

Original post by orionx103
I have a huge belief in overkill. Metal Gear Solid 2 took me less than fifteen hours to beat my first time around. I can now play and beat MGS2 in under ten. Final Fantasy X was a fifty to sixty hour game. Now, I enjoyed MGS2 a whole lot more than I did FFX. If a game is to be played for fifty to sixty hours, it should be because it''s fun, not because you''re still trying to beat it.

---

The Dogma retail games seem to believe in is that "there must be a certain gameplay time for each title". Personally, I find this a big turn-off - as soon as a game starts to promise it will take forever I get out of the game. I installed a sequel to the Shogun:Total War title one of these days (I loved Shogun) : something set in Medieval Europe. I should have liked to play it, but I pressed the quit button instead, dreading the long battles ahead.

I now prefer shareware games because they have a more reasonable dogma: "make the game so it can be enjoyed when played for short periods of time". One strategy game in particular (Oasis - oasisgame.com) goes even further and imposes an upper limit on the time it takes to finish a level, not by using a time counter (the game is turn based), but by making the number of decisions the player takes while playing a level a constant - hence the player can predict with a good degree of certainty that every level can be played in say five minutes (give or take depending on the chosen speed of play). The dogma would be "make sure that the a player can always finish a level in two minutes if he plays as fast as he can." This doesn''t mean a player can''t play the same level for ten minutes while giving good thought to each decision.



______________________________________

Pax Solaris

quote:

---

Original post by Grellin GDU
The installation of your game should be as effortless to the user as humanly possible. Just because we may understand the technical junk don''t mean your user base should have to.

---

Amen to that. I think that''s not a Dogma (as defined in this thread), that''s downright a universal truth.

A dogma regarding the a game could be "The filesize of the fullversion installer should be less than 1MB." (some also use 10MB) - shareware dogmas yet again.

quote:

---

Oh and try not to have too many kings.

---

That''s dogma alright.

quote:

---

How about the old K eep I t S imple S tupid?

---

KISS is indeed a good dogma.

Of course, "make it the most complicated game in the field" is a valid dogma too (two of the best game I''ve played, ADOM and VGA Planets use this variant rather than KISS).

Meta dogmata(dogmas on dogmas):

"A doctrine made of several dogmas is necessary before starting a project"

"For each good dogma there''s a good opposite counter-dogma. It is always worth giving much thought to the counter-dogmas of established dogmas (the ones people mistake for Truth)"

How about: create the kind of game that personally excites you. One that you would enjoy, even obsess over. This will hold you attention more than working on something you think will only please others.