Bottom-up game design - which most often happens with simulations - consists of taking a mechanism of some kind and trying to tack a game onto it. Here's how it usually happens. You begin with some interesting and complicated process - social interactions among a group of friends, for example, or optimizing elevator behavior in a crowded building. If you're a software engineer, your natural temptation is to figure out how to program it and see how it works. What are the core mechanics of the simulation? What is its internal economy? Should an elevator be smart enough to know that it's full, so it doesn't stop for people any longer until some get out? How long are people prepared to wait for an elevator, anyway? And so on.

I've been guilty of it myself, back when I was a young programmer and still thought that making computer games was about writing cool software. Your head is fizzing along with data structures for representing this and that, and algorithms for computing this and that, and the very first thing you want to do is code it up and watch it go. But this isn't a column to tell you "design your code before you write it" - that's been said a million times already. The problem with bottom -up game design, even if you don't write a line of code for months, is that you don't know if it's any fun while it's just a simulation.

This was one of the weaknesses of Black and White, as I think Peter Molyneux himself would admit. Molyneux is famous for creating amazing, hugely innovative game engines, and only then figuring out how to turn them into a game. If the gossip is right, he did it with Populous, then with Dungeon Keeper, and again with Black and White. Despite their success, all show signs of having been written as a simulation first, and only then having been turned into games.

You can get away with this if you're Peter Molyneux, and you surround yourself with brilliant talent and you innovate like crazy and work like a dog (and are able to face down - or fake out - the publisher when you're six months late). Lesser mortals are seldom so fortunate. If you start with a simulation and count on turning it into a game later, you run a serious risk that a few months before gold master, you'll suddenly be asking yourself the dreaded question: "Why isn't this more fun?" And then you're in real trouble.

Bottom-up game design is based on an assumption that any process that is subtle or interesting to program is also going to be interesting to play with. That doesn't necessarily follow. For years I was intrigued by the challenge of programming a traffic simulation. The player could widen roads, install traffic lights, and all sorts of things to see how the flow of traffic changed under different conditions. I mentioned this idea to my friend Anne Westfall, and she said politely, "And who would want to do this?" The question brought me up short. Not many people have a dream of fiddling around with traffic-light timings. What's more, even I wouldn't want to do it for very long, and I certainly wouldn't pay much money for the privilege. I had gotten all excited about the software engineering problems and ignored the fact that it needed to be enjoyable.[/quote]
http://www.designersnotebook.com/Columns/066_The_Perils_of_Bottom-Up_Ga/066_the_perils_of_bottom-up_ga.htm