What are the biggest pitfalls to consider when developing a new game?

I actually just started tracing (thanks David Young for the nomenclature correction) a couple of new web-based games for Facebook a few weeks ago and I have just been inundated with mental blocks and time sucks from re-coding. I am working on something similar to the turn based (Vampire Wars) style RPG. I have the skills to code a game but I am slogging through trying to get the design patterns right and make the product match what I see in my mind's eye.

Normally when building a website I like to 'think in code' and I find it faster for me to just change the code/HTML to tweak it in. This is probably because I am VERY comfortable in what I do and I know what to expect as I've done it over and over again. At this point with game development I find myself starting on paper again (like I used to with websites) and I wonder if this is just my lack of focus and intuition with game logic or if this is an appropriate way to roll my thoughts out in advance of coding.

I would appreciate some advice on how to correctly attack this problem and keep myself on-task. I am quickly learning how much differently a game engine is from a standard business website! Every time I do get something in place it just feels mooshy and incomplete and it's becoming darned frustrating.

Extended

As an example, the battle engine that has been giving me so much issue recently takes a simple attack skill and then makes a random roll between -50% and +50% and then multiplies the original attack skill against that percent. The same thing is done with defense and then I mesh those to determine if any damage is done against the enemy health. I guess I should realize I am in over my head when I started asking myself if that is even the right way to do it, or if there even IS a 'right' way. One major fault I found with this is two characters around the same level can have several 'rolls' where the attack is -50% and the defense is +50% so I end up with some EXTREMELY long battle sequences where nobody does anything. FAIL

Maybe my post should have been asking for suggested links describing simple game logic.

End Extension

adding too many features. Focus on the core of the game, build it, then if everything works well then add features. People get too focused on adding cool things, and never getting anything done.

• This nearly killed one of my FB games. It's packed with features, but the whole thing feels half-assed overall. – Tesserex Oct 1 '10 at 19:14
• If I recall correctly this phenomenon is called "feature creep". A dangerous pitfall, indeed. – S. Tarık Çetin Mar 21 '18 at 13:08

This is a great article about how to prototype a game. From your question is seems like you're missing the idea of what a prototype is supposed to be.

Prototyping: You’re (Probably) Doing It Wrong

Blurb:

Mistake #4: Building a system, not a game
When you’re making a prototype, if you ever find yourself working on something that isn’t directly moving your forward, stop right there. As programmers, we have a tendency to try to generalize our code, and make it elegant and be able to handle every situation. We find that an itch terribly hard not scratch, but we need to learn how. It took me many years to realize that it’s not about the code, it’s about the game you ship in the end.

Don’t write an elegant game component system, skip the editor completely and hardwire the state in code, avoid the data-driven, self-parsing, XML craziness, and just code the damned thing.

Edit:

I'm adding this just to clarify the difference between Prototype and Tracer Code.

Always remember: A Prototype is designed to be thrown away! Tracer Code is not.

The Prototype Pitfall

...The tracer code approach addresses a different problem. You need to know how the application as a whole hangs together. You want to show your users how the interactions will work in practice, and you want to give your developers an architectural skeleton on which to hang code. In this case, you might construct a tracer consisting of a trivial implementation of the container packing algorithm (maybe something like first-come, first-served) and a simple but working user interface. Once you have all the components in the application plumbed together, you have a framework to show your users and your developers. Over time, you add to this framework with new functionality, completing stubbed routines. But the framework stays intact, and you know the system will continue to behave the way it did when your first tracer code was completed.

The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.

Tracer Bullets and Prototypes

• That is a great... I am going to have to take a look at that article. Just from the excerpt you posted it sounds like I may be looking at prototyping incorrectly, but it also sounds like it may be a common mistake. – angryCodeMonkey Oct 1 '10 at 20:14
• the mistake you quoted has been naguing me for quite a while now. – jokoon Oct 1 '10 at 21:17

Pitfalls: Not Separating your logic from your data. Not testing that your data produces the desired results.

From your comment on Joe's post:

You want me to code a battle engine for monster encounters, BOOM! I have re-written my engine at least three times this week and I never feel good about it. I mean, the math works, but when I try it out it just feels wonky. Does that make sense?

It sounds like you're conflating engine with data here. Your monster encounter engine should be driven by data. If the data that affects your game balance/fun is wrong, there should be no need to completely rewrite your engine - just tweak your balance variables until it feels right.

However, because balance variables are sometimes interdependent, changing one variable to better one scenario can have a vast (negative) effect on other scenarios.

In order to test that your newly tweaked data doesn't muck up a whole bunch of other cases, it's useful to keep a few test cases around and make sure they aren't broken after tweaking. Here's an admitedly contrived example of how you would test this.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
Player player(PlayerStats);
Monster monster(MonsterStats);

EncounterEngine.SeedRNG(seed);
while(1)
{
result = EncounterEngine.Attack(player, monster);
return TEST_FAIL;
return TEST_PASS;
// result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected.
}
}


Eg. If you call this with PlayerStats.Level == 5 and MonsterStats.Level == 3, you'd expect the player to always defeat this monster eventually.

• The advise I am getting here is great, and I can see I have been taking the wrong approach to a lot of this. The reason, though, that I have rewritten the engine is that I think I am making it too complicated. My latest version of the battle engine is a class with (at the moment) a single public function and several supports. The main function 'fight' is not only calculting the basic attack vs defense but also determining first strike, checking rolls to determine if your tactical skill gives you a second strike, etc, etc, etc. I think I have just made it too damn difficult! – angryCodeMonkey Oct 2 '10 at 0:35
• Not Separating your logic from your data. Thats a great point, which will almost always cause problems down the road, or while updating! – Spooks Jan 27 '11 at 21:54

The pitfall here, as far as I can see, is that you're treating programming and game design as the same task, when really they are separate tasks. As you suggest, this isn't a programming or algorithmic problem (you can code the battle system any way you want), it's about what is fun and interesting to the player.

The answer is, look up resources on game design and game balance. There are actually universities that devote an entire four-year program of study to the topics you're raising, so just giving you a quick-and-dirty answer is impossible (the same way that you'd probably be stumped if someone said "yeah, I've got this idea for a game but I don't know how to program it, what should I watch out for?"). There are books, courses, and online writings out there about game design; seek them out.

The biggest pitfall when writing games is to worry about whether or not you're using the right design patterns instead of just writing code you feel good about.

• The problem I am having right now is feeling good about the code I am writing. You want an accounting backend for your business, no problem... You want me to code a battle engine for monster encounters, BOOM! I have re-written my engine at least three times this week and I never feel good about it. I mean, the math works, but when I try it out it just feels wonky. Does that make sense? – angryCodeMonkey Oct 1 '10 at 19:09
• why rewrite the engine? you could implement game specific code in a scripting language like lua. Change variables or how the math is calculated and never need to recompile just to check things out. gamedev.net/reference/articles/article1932.asp – David Young Oct 1 '10 at 21:36

I would recommend Steve Pavlina's articles about time management and self-motivation: http://stevepavlina.narod.ru/

He is programmer, too. His lifestyle experiments have generated some mainstream media interest.