Early lessons about multiplayer game design from Conquer-on-Contact

Right now I'm working hard on a new release of Conquer-on-Contact that addresses the biggest problems the previous version had. I learned a few important lessons from the initial release that are sure to be old hat for experienced game designers, but they were new to me.

1. Most people do not read instructions. A lot of people do, but enough won't that the interface needs to be as intuitive as possible.
2. If a game allows it, some percentage of people will play for hours on end. This is why most multiplayer online games give you a fixed number of turns per day. Bandwidth isn't cheap so I need to limit use too, but I'm trying to discourage people from playing too much with game mechanics aside from strict turn limiting. This may turn out to be too difficult.
3. Test, test, test. For the new release of Conquer-on-Contact I've written scripts that simulate player actions and I use them to simulate hundreds of simultaneously active players. It gives my poor quad-core a workout, but it's the only reliable way to catch certain obscure bugs.
4. Multiplay has to be taken into account. Most online games try to limit multiplay by saying they'll ban all your accounts if they find you playing more than one. In practice this is impossible without having someone watch player actions very closely, and even then it's mostly a wash. One way to address the multiplay problem is by making it such that other players can only really hurt each other rather than help each other, but you have to be careful here too because alliances can be a lot of fun.
5. Multithreadding is hard. Especially on a platform like App Engine where there's basically infinite parallelism and limited high-speed access to shared state. Unless you're a whiz when it comes to distributed processing, it's not a bad strategy to record user intentions in queues and then use a single-threadded handler to carry out those requests in sequence periodically. You can't officially do background tasks on App Engine yet, but you can simulate them easily enough with a cron process running on another machine. There are a lot fewer edge cases to worry about when you're processing requests in a single thread rather than trying to deal with them in a massively parallel fashion as they come in, and an added bonus is that you can respond to user queries with a brief acknowledgement very quickly.
6. High scores, rankings, and other "carrots" are important. If you present a high score list, the top high score will be the goal that most players are trying to achieve. I'd like to add more intermediate carrots but there probably won't be time before the next release.

Conquer-on-Contact has been a great learning experience for me. I can hardly recommend this route enough if you want to learn what makes games fun or gain more experience with distributed programming. Be sure to check out the new version this Sunday!